Dynamics 365 Customer Insights – Journeysでセグメントを作るとき、2026年4月更新で特に押さえるべき点は「リードを直接対象にできること」「関連テーブルやCustomer Insights – Dataの統合プロファイルを使った条件設計」「CSVによる大規模な静的メンバー管理」「MQLの表示・編集やAPI活用」です。単に配信対象を絞る機能ではなく、マーケティング部門、IT管理者、プロダクトオーナーが共通のルールでオーディエンスを管理するための実務基盤として見るべき更新です。
この記事では、Microsoft公式ドキュメント「Build segments in Customer Insights – Journeys」をもとに、Dynamics 365 Customer Insights – Journeysのセグメント作成で何が重要になったのか、現場でどう使うべきか、導入前に確認すべき制約まで整理します。なお、Microsoft Learn上の対象ページは2026年4月時点の更新情報として公開されており、ページ表示では最終更新日が2026年4月21日と記載されています。(Microsoft Learn)
Dynamics 365 Customer Insights – Journeysのセグメント作成は何が変わったのか
今回の更新で重要なのは、Customer Insights – Journeysのセグメント作成が「マーケターだけが画面上で条件を組む機能」から、より広い業務データを扱うターゲティング基盤へ近づいている点です。
Microsoft公式ドキュメントでは、Customer Insights – Journeys上で、複雑なデータ構造や論理演算子に詳しくなくてもセグメントを作成でき、利用前に推定サイズや含まれるメンバーのサンプルを確認できると説明されています。また、対象オーディエンスとして、contacts、leads、Customer Insights – Dataのunified profilesを選択できます。(Microsoft Learn)
実務上は、次のような意味があります。
| 変更・強化ポイント | 実務での意味 |
|---|---|
| リードを直接ターゲットにできる | 見込み客向けナーチャリングを、連絡先へのひも付け前から設計しやすい |
| 関連テーブルを条件に使える | Account、Event Registrationなど、周辺データを含めた精度の高い抽出が可能 |
| 統合プロファイルを対象にできる | Customer Insights – DataのCDPデータをマーケティング施策に活用しやすい |
| セグメントサイズとサンプルを事前確認できる | 配信前の過剰抽出・過少抽出を減らせる |
| CSVで静的メンバーを扱える | 外部システムや営業部門のリストを施策に取り込みやすい |
| MQL表示・編集、API連携が可能 | 複雑な条件の再利用、自動化、運用標準化に向く |
特にIT管理者やプロダクトオーナーは、「誰がどの条件で顧客を抽出できるか」「DataverseやCustomer Insights – Dataのどのデータを使うか」「本番配信前にどのように検証するか」を設計する必要があります。
リードを直接対象にしたセグメント作成が重要になった理由
従来のマーケティング運用では、リードを本格的なジャーニーに載せる前に、連絡先や取引先責任者との関係を整理する必要がありました。今回のドキュメントでは、親のcontactに接続しなくても、leadを直接対象にした動的セグメントを作成できることが明示されています。(Microsoft Learn)
これはBtoBマーケティングやインサイドセールス運用に大きく関係します。
たとえば、次のようなセグメントを作れます。
- 7日以内にフォローアップ予定があるリード
- 従業員規模が一定以上の企業に属するリード
- 特定業種の親取引先に関連するリード
- フォーム送信後、まだ商談化していないリード
この機能を使うと、営業担当への引き渡し前段階でも、メール、イベント案内、リマインド、営業フォロー依頼などを整理できます。
実務での判断基準
リードを直接対象にすべきか、contactを中心に設計すべきかは、次の基準で判断すると失敗しにくくなります。
| 判断軸 | leadを対象にするケース | contactを対象にするケース |
|---|---|---|
| データの成熟度 | まだ見込み客段階で、重複や資格判定が残っている | 顧客・会員・既存接点として管理済み |
| 施策の目的 | ナーチャリング、資格判定、初回接点創出 | 継続接点、既存顧客向け案内、ロイヤルティ施策 |
| 営業連携 | MQL、SQL化前後のフォローを重視 | 顧客接点履歴や購買履歴を重視 |
| データ品質リスク | 重複や未整備項目が起きやすい | 比較的安定した属性で抽出しやすい |
リード対象のセグメントは便利ですが、メールアドレス重複、ステータス未更新、担当者未割り当てなどがあると、想定外の対象者が含まれる可能性があります。初回運用では、必ずサンプル確認とテストジャーニーで検証するべきです。
関連テーブルを使ったセグメントでできること
Customer Insights – Journeysのセグメント作成では、contactsやleadsの属性だけでなく、Event RegistrationやAccountなどの関連テーブルを参照して条件を組めます。公式ドキュメントでは、Leadの親AccountがConsumer Services業界である、といった例が紹介されています。(Microsoft Learn)
これは、単純な「都道府県」「役職」「メール許諾」だけではなく、業務上の関係性を使った抽出ができるということです。
たとえば、次のようなセグメント設計が考えられます。
| 活用シーン | セグメント条件の例 |
|---|---|
| イベント後フォロー | 特定イベントに登録済みで、まだ資料請求していないcontact |
| BtoBターゲティング | 親Accountの業種が金融または製造で、企業規模が一定以上のlead |
| 休眠顧客施策 | 過去にイベント参加履歴があるが、直近のメール反応がないcontact |
| 優良顧客向け案内 | Customer Insights – Dataのメジャー値でLTVが高いunified profile |
| 営業連携 | 商談化前で、特定製品カテゴリに興味を示したlead |
関連テーブル利用時の注意点
関連テーブルをセグメント条件に使う場合は、対象テーブルでTrack changesを有効にする必要があります。Microsoft公式ドキュメントでは、関連テーブルの属性を追加するには、その関連テーブルでTrack changesを有効化する必要があると説明されています。(Microsoft Learn)
ここはIT管理者が見落としやすいポイントです。
セグメントビルダー上で項目が見えない、条件を作っても想定通り更新されない、といった問題は、マーケティング画面だけでは原因を特定しにくいことがあります。Dataverseのテーブル設定、権限、関連付け、変更追跡の有効化を事前に確認しておくべきです。
Customer Insights – Dataの統合プロファイルを使う場合の前提条件
Customer Insights – Journeysでは、Customer Insights – Dataのunified profilesを対象にしたセグメントも扱えます。ただし、統合プロファイルをターゲットにするには、Customer Insights – JourneysとCustomer Insights – Dataを同じ環境にインストールする必要があります。Customer Insights – Dataのcustomer measuresを参照する場合も同様です。(Microsoft Learn)
これはグローバル企業や複数地域展開の組織で特に重要です。
たとえば、Customer Insights – Data側で次のような情報を統合している場合、Journeys側のセグメントに活用できます。
- 複数システムを横断した顧客ID
- 購買履歴や利用履歴
- ロイヤルティランク
- 顧客生涯価値に近いメジャー
- Web、イベント、営業接点を組み合わせた顧客理解
ただし、「Data側にあるからJourneysですぐ使える」と考えるのは危険です。環境構成、データ更新頻度、プロファイル統合のキー、Dataverse上のcontactやleadとの関係を整理しておかないと、セグメント条件は作れても業務で使いにくい状態になります。
導入前に確認すべきチェック項目
| 確認項目 | 確認する理由 |
|---|---|
| Customer Insights – JourneysとDataが同一環境か | 統合プロファイルやメジャー利用の前提になる |
| contact、lead、unified profileの使い分け | 施策対象が曖昧だと重複配信や対象漏れが起きる |
| データ更新頻度 | セグメント反映タイミングが施策要件に合うか確認する |
| 権限とビジネスユニット | 作成者に見えるデータと実行時に含まれるデータの差を把握する |
| 同意管理・配信停止情報 | セグメントに含まれても、配信可否は別途制御される可能性がある |
セグメントサイズとメンバーサンプル確認は必ず使う
セグメント作成では、条件を保存してすぐジャーニーに使うのではなく、Refreshで推定サイズを確認し、View sample of included membersで含まれるメンバーのサンプルを確認できます。公式ドキュメントでは、セグメント定義に満足した段階でRefreshを選ぶと推定サイズを確認でき、含まれるメンバーの最初のセットも表示できると説明されています。(Microsoft Learn)
この確認は、マーケティングROIだけでなく、誤配信防止にも直結します。
たとえば、以下のようなミスは実務で起きやすいです。
| 失敗例 | 原因 | 事前確認で見るべき点 |
|---|---|---|
| 想定より対象者が多すぎる | ANDではなくORで条件を組んでいる | 件数が過去施策と比べて異常に大きくないか |
| 対象者がほぼゼロになる | 関連テーブルの条件が厳しすぎる | サンプルに想定する人物が含まれているか |
| 海外拠点の顧客が混ざる | 地域条件やビジネスユニット条件が不足 | 国、地域、言語、所有部門を確認する |
| テストユーザーが含まれる | 除外条件を入れていない | 社内ドメインやテストcontactを除外する |
| VIP顧客に通常施策を送る | 除外グループを使っていない | 手動除外または専用条件を追加する |
特にグローバル配信では、タイムゾーン、言語、法域、同意状態が混在しやすくなります。セグメントサイズだけで判断せず、サンプルメンバーの属性まで確認する運用が必要です。
手動の追加・除外はVIP対応やテストに使いやすい
Customer Insights – Journeysでは、条件に一致するメンバーだけでなく、手動で特定のメンバーを含める、または除外できます。公式ドキュメントでは、VIP顧客を常に含める、または別体験に回すために除外する例が示されています。(Microsoft Learn)
使いどころは明確です。
- 経営層や重要顧客を特別イベントに必ず招待する
- クレーム対応中の顧客をキャンペーンから外す
- 社内レビュー用のテストユーザーを追加する
- パイロット施策で少数の顧客だけを対象にする
- 一時的な営業判断をセグメントに反映する
ただし、手動選択リストは100メンバーに制限されています。大きなリストを扱う場合は、CSVファイルを使う方法が公式ドキュメントで案内されています。(Microsoft Learn)
手動追加・除外を使うときの運用ルール
手動追加は便利ですが、属人的に使うと「なぜこの人が含まれているのか」が分からなくなります。運用では、次のルールを決めておくと安全です。
| ルール | 目的 |
|---|---|
| セグメント名に用途を入れる | テスト用、VIP用、本番用を見分けやすくする |
| 手動追加・除外の理由を記録する | 後から監査・説明できるようにする |
| 期限付きの運用にする | 古い判断が残り続けるのを防ぐ |
| 本番配信前に除外グループを確認する | 誤って重要顧客を通常施策に含めない |
| 大量追加はCSVに切り替える | 手作業による漏れや重複を減らす |
CSVによる静的セグメントは最大200万メンバーまで扱える
2026年4月更新ポイントの中でも、実務インパクトが大きいのがCSVによる静的メンバー管理です。
公式ドキュメントでは、CSVファイルを使ってDataverse内のcontactまたはleadとメールアドレスを照合し、静的リストとしてセグメント定義に含められると説明されています。CSVにはemailaddress1というヘッダーを持つ列が必要です。(Microsoft Learn)
また、1つの静的メンバーグループには最大200,000メンバーを含められ、最大10グループまで作成できるため、合計で最大2,000,000の静的メンバーを扱えます。静的リストと動的条件を同じセグメント定義に含めることもできます。(Microsoft Learn)
CSVセグメントが役立つケース
| ケース | 具体例 |
|---|---|
| 外部システムのリストを使う | EC、ウェビナー、店舗会員、パートナー管理システムから抽出した対象者 |
| 営業部門から受け取ったリストを使う | 重点アカウント担当者が指定した見込み客リスト |
| 短期キャンペーンを実施する | 期間限定セール、招待制イベント、特定顧客向け案内 |
| 動的条件だけでは抽出できない | 属性が未整備だが、事業側が対象者を明確に持っている |
| 大量の静的対象者を扱う | 数万から数十万単位の対象者リストを施策化する |
CSV利用時に失敗しやすいポイント
CSVセグメントでは、メールアドレスをもとにDataverse内のcontactまたはleadと照合します。そのため、CSVに記載されたメールアドレスがDataverseに存在しない場合、その行は対象に含まれません。公式ドキュメントでは、Not foundリストをダウンロードし、Dataverseにレコードを作成してから再照合できると説明されています。(Microsoft Learn)
また、同じメールアドレスに複数のcontactやleadが一致する場合、重複排除されず、複数レコードが対象に含まれる可能性があります。公式ドキュメントでも、1行のメールアドレスが複数のcontactに一致すると、メンバー数がCSV行数より大きくなる例が示されています。(Microsoft Learn)
実務では、アップロード前に次の確認を行うべきです。
| 確認項目 | 理由 |
|---|---|
emailaddress1列があるか | 必須ヘッダーがないと照合できない |
| メールアドレスの表記ゆれがないか | 大文字小文字、前後スペース、古いアドレスで不一致が起きる |
| 同一メールアドレスの重複がないか | 複数レコード一致で対象数が増える可能性がある |
| Dataverse側に対象レコードが存在するか | CSVだけでは新規contactやleadは自動作成されない |
| consentや配信停止情報を確認したか | セグメント対象でも送信可能とは限らない |
| 本番用とテスト用を分けたか | 誤配信を防ぐため、検証用CSVを先に使う |
MQLのQuery Viewは上級者向けだが運用標準化に有効
セグメントビルダーでは、Query Viewを使って、セグメントを定義するMQLを表示、コピー、直接編集できます。公式ドキュメントでは、この機能を使うにはSettings > Overview > Feature switchesからSegmentationセクション内のQuery editトグルを有効にすると説明されています。(Microsoft Learn)
MQLを直接編集できるメリットは、複雑な条件を素早く調整できることです。たとえば、グローバル展開で国や言語だけを変えたセグメントを複数作る場合、画面操作だけで毎回組み直すより、既存セグメントのパターンをコピーして調整した方が効率的です。
ただし、すべてのマーケターにMQL編集権限を開放するのはおすすめできません。条件ミスがそのまま対象者ミスにつながるためです。
Query Viewを使うべき人・使うべきでない人
| 利用者 | おすすめ度 | 理由 |
|---|---|---|
| IT管理者 | 高い | セグメント定義の確認、複製、標準化に向く |
| マーケティングOps | 高い | 複雑な条件やグローバル展開のテンプレート化に役立つ |
| 一般マーケター | 中程度 | 基本はUIで作成し、MQL編集はレビュー付きが望ましい |
| 一時利用者・初心者 | 低い | 条件構造を誤ると、対象者ミスが起きやすい |
現実的には、MQL編集は「テンプレートを作る担当者」と「レビューする担当者」を分けると安全です。編集後は必ずRefreshとサンプル確認を行い、意図した対象者になっているか検証しましょう。
API連携でセグメント作成・更新・公開を自動化できる
Microsoft公式ドキュメントでは、segment builder APIがUIを支えているため、UIで行う操作をAPIでも実行できると説明されています。関連するWeb APIドキュメントでは、Customer Insights – Journeys segmentの作成、既存セグメントの編集、公開、メンバー表示が可能とされています。(Microsoft Learn)
API活用は、特に次のような組織で効果があります。
- 複数地域・複数ブランドで似たセグメントを大量作成する
- 外部システムのリスト更新に合わせて静的メンバーを追加・削除する
- キャンペーン管理システムからセグメントを自動生成する
- 開発、検証、本番環境でセグメント定義を標準化する
- 手作業による条件設定ミスを減らす
Web APIドキュメントでは、segment definitionに静的リストと動的クエリの両方を含められること、静的メンバーの追加・削除・表示、セグメント公開、メンバー一覧取得、live segmentの停止などが説明されています。(Microsoft Learn)
API運用で注意すべき点
APIで自動化すると便利ですが、配信対象に関わる処理であるため、通常のシステム連携より慎重に扱う必要があります。
| 注意点 | 実務対応 |
|---|---|
| 認証・権限 | 最小権限のアプリ登録やサービスアカウントを使う |
| 環境分離 | 開発、検証、本番でエンドポイントと対象データを分ける |
| 監査ログ | いつ誰がどのセグメントを更新したか追跡できるようにする |
| エラーハンドリング | 追加・削除失敗時に再実行や通知を設計する |
| 公開前チェック | 自動作成後もサイズ、サンプル、除外条件を確認する |
| 依存関係 | 使用中のジャーニーや他セグメントへの影響を確認する |
特に「公開」や「停止」はマーケティング施策に直結します。API連携を導入する場合は、Power Platformの環境戦略、Dataverse権限、変更管理プロセスと合わせて設計する必要があります。
サポートされない項目を理解しておく
セグメント作成で意外とつまずくのが、「条件に使いたい項目が表示されない」「選べると思ったフィールドが使えない」というケースです。
公式ドキュメントでは、real-time journeys segmentationでvirtual tablesはサポートされず、segment designerのAdd tablesダイアログにも表示されないと説明されています。また、DataverseのCalculatedおよびFormulaフィールドもreal-time journeys segmentationではサポートされず、アプリ上では無効表示されると説明されています。(Microsoft Learn)
これは設計段階で必ず把握しておくべき制約です。
| 使えない・注意が必要な項目 | 影響 | 代替案 |
|---|---|---|
| Virtual tables | セグメント条件として表示されない | 必要データをDataverse実体テーブルやCustomer Insights – Data側に取り込む |
| Calculatedフィールド | 更新信号がセグメンテーション基盤に届かない | 計算結果を永続化するフィールドや別プロセスで同期する |
| Formulaフィールド | 実行時計算のため条件に使えない | Power Automate、プラグイン、データ統合で値を保存する |
| Track changes未有効の関連テーブル | 関連属性が使えない可能性がある | テーブルプロパティで変更追跡を有効化する |
| CSV上にしか存在しないメール | Dataverseと照合できない | Not foundを確認し、必要に応じてDataverseに登録する |
「なぜ使えないのか」をマーケティング部門だけで解決しようとすると時間がかかります。データモデルを管理するIT管理者と、セグメントを使う事業部門が、利用可能なテーブルとフィールドを事前に棚卸ししておくことが重要です。
IT管理者が最初に確認すべき設定
Customer Insights – Journeysのセグメント機能を安全に使うには、画面の使い方だけでは不十分です。IT管理者は、データ、権限、環境、運用の4つを確認する必要があります。
| 項目 | 確認内容 |
|---|---|
| 環境構成 | Customer Insights – JourneysとCustomer Insights – Dataを同じ環境で使う必要があるか |
| Dataverseテーブル | contact、lead、account、event registrationなどの関連とTrack changes |
| 権限 | セグメント作成者が必要なテーブルを参照できるか |
| ビジネスユニット | 作成時に見えるデータと実行時に含まれるデータの差を理解しているか |
| Feature switches | Query editなど、必要な機能を有効にするか |
| CSV運用 | アップロード可能な担当者、ファイル形式、承認フロー |
| API利用 | アプリ登録、認証、監査、環境分離 |
| 配信ガバナンス | consent、除外条件、テスト送信、承認プロセス |
特にグローバル環境では、国・地域ごとにデータ保持ルールやコミュニケーションポリシーが異なる場合があります。セグメントに含まれることと、実際に配信してよいことは同じではありません。配信可否は、同意管理、法務要件、ローカル運用ルールと合わせて判断する必要があります。
プロダクトオーナーが見るべき業務インパクト
プロダクトオーナーにとって重要なのは、機能一覧ではなく「どの業務が変わるか」です。
今回のセグメント機能の整理により、Customer Insights – Journeysは次の業務に影響します。
| 業務領域 | 期待できる効果 |
|---|---|
| リードナーチャリング | リード段階から適切な施策に載せやすくなる |
| イベントマーケティング | 登録状況や参加履歴をもとにしたフォローがしやすくなる |
| ABM | Account情報を条件にしたターゲティングを組みやすい |
| グローバルキャンペーン | MQLやAPIで条件テンプレートを再利用しやすい |
| データ活用 | Customer Insights – Dataの統合プロファイルやメジャーを施策に接続しやすい |
| 運用統制 | セグメント定義、静的リスト、除外条件を標準化しやすい |
一方で、セグメントが作りやすくなるほど、似たようなセグメントが乱立するリスクも高まります。
たとえば、「Japan VIP contacts」「JP VIP 2026」「VIP customers Japan」「Event VIP JP」のようなセグメントが増えると、どれを本番ジャーニーで使うべきか分からなくなります。命名規則、所有者、用途、更新頻度、廃止ルールを決めることが、プロダクト運用では欠かせません。
おすすめのセグメント命名ルール
セグメント運用を安定させるには、名前だけで用途が分かるようにすることが重要です。
たとえば、次のような形式にします。
地域_対象_目的_条件_年月_状態
具体例は次の通りです。
| セグメント名の例 | 意味 |
|---|---|
JP_Lead_Nurture_Followup7days_202604_Live | 日本のリード向け、7日以内フォローアップ対象 |
Global_Contact_EventRegistered_NotAttended_202604_Draft | グローバルのイベント登録済み未参加者 |
APAC_Profile_HighLTV_VIPInvite_202604_Test | APACの高LTV統合プロファイル向けVIP招待テスト |
JP_Contact_CSV_SalesPriorityList_202604_Live | 営業部門提供CSVを使った日本向け本番リスト |
命名ルールには、最低限次の要素を含めると管理しやすくなります。
- 地域またはブランド
- 対象エンティティ
- 施策目的
- 主な条件
- 作成年月
- 状態
これにより、IT管理者、マーケター、営業担当、監査担当が同じ意味でセグメントを理解できます。
実務で使えるセグメント作成手順
Customer Insights – Journeysでセグメントを作成するときは、いきなり条件を組むのではなく、次の順序で進めると失敗を減らせます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 目的を決める | 誰に、何を、なぜ届けるのか |
| 2 | 対象を選ぶ | contact、lead、unified profileのどれを使うか |
| 3 | 必要データを確認する | 関連テーブル、Customer Insights – Data、CSVのどれを使うか |
| 4 | 条件を作る | AND/OR、グループ、除外条件を正しく設定する |
| 5 | サイズを確認する | 想定件数と大きくズレていないか |
| 6 | サンプルを確認する | 代表的な対象者が含まれ、除外対象が含まれていないか |
| 7 | テストジャーニーで検証する | 社内テストまたは限定対象で確認する |
| 8 | Ready to useにする | 承認後に本番ジャーニーで利用する |
| 9 | 運用後に見直す | 対象者数、反応、重複、除外条件を確認する |
この手順を標準化しておくと、担当者が変わっても同じ品質でセグメントを作成できます。
今回の更新で特に注目すべきポイント
2026年4月時点の「Build segments in Customer Insights – Journeys」を読むうえで、特に重要なのは次の5点です。
まず、leadを直接対象にできることで、見込み客段階の施策設計がしやすくなりました。BtoBマーケティングでは、商談化前の接点管理に使いやすい機能です。
次に、関連テーブルやCustomer Insights – Dataのunified profilesを使えることで、単純な属性ベースではなく、イベント参加、取引先属性、顧客メジャーなどを含めたセグメント設計が現実的になっています。
3つ目に、CSVによる静的メンバー管理は、現場でよくある「外部リストをすぐ施策に使いたい」という要望に応えます。最大2,000,000メンバーまで扱えるため、大規模なキャンペーンやグローバル配信にも対応しやすい設計です。(Microsoft Learn)
4つ目に、MQLのQuery ViewやAPIにより、セグメント作成はノーコード操作だけでなく、標準化・自動化の対象になりました。大規模運用では、ここが運用品質の差になります。(Microsoft Learn)
最後に、virtual tables、Calculatedフィールド、Formulaフィールドなど、使えない項目を理解しておくことが重要です。機能が強化されても、データモデル設計が不十分だと、必要な条件を作れません。
まず何から始めるべきか
Dynamics 365 Customer Insights – Journeysでセグメント機能を活用するなら、最初にやるべきことは新機能を試すことではありません。自社のセグメント運用を棚卸しすることです。
具体的には、次の3つから始めると効果的です。
- 現在使っているcontact、lead、account、event関連データを整理する
- よく使うセグメント条件をテンプレート化する
- CSV、手動追加、MQL編集、API利用の権限ルールを決める
そのうえで、小さなテストセグメントを作り、サイズ確認、サンプル確認、テストジャーニーまで実施します。特にリード対象セグメントやCustomer Insights – Dataの統合プロファイルを使う場合は、データの関連付けと更新タイミングを必ず確認してください。
Customer Insights – Journeysのセグメント機能は、単なる配信対象の絞り込みではありません。正しく設計すれば、営業、マーケティング、データ管理をつなぐ実行基盤になります。2026年4月更新のポイントを踏まえ、まずは「誰が、どのデータで、どの条件を使い、どう検証してから本番利用するか」を明文化することが、最も実践的な第一歩です。
コメント