おはようございます。室長こと吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

キリンカップ、日本代表勝ちましたねー。ニュージーランド相手に2－1。とてもいい試合でした。エースが決めると勝てますね。次はリベンジ、ブラジル戦ですか。楽しみです。ワールドカップでいじられた塩貝選手を使ってあげて欲しいですね。

さて、前回はDynamics 365 Customer Insights – Dataを、Golden DataからCustomer 360を組み立てるCustomer Intelligence層として考えました。誰を顧客として統合するのか。どのRelationship、Activity、Measure、Segmentで状態を表すのか。そして、その理解をどの業務やAgentへ渡すのか。Customer 360は一枚の画面ではなく、顧客を理解し続ける運用能力だと整理しました。

しかし、顧客を理解できても、企業の行動が変わらなければ顧客体験は変わりません。点検時期が近いことも、最近の問い合わせで不満が残っていることも、顧客がWebで新しい製品を見ていることも分かっている。それでも、部門ごとに別々のメッセージを送り、同じ日に何度も連絡し、顧客がすでに行動した後も古い案内を続けるなら、Customer 360は「よく見える顧客台帳」で止まります。

今回の主役はDynamics 365 Customer Insights – Journeysです。ただし、メール配信やキャンペーン管理の機能一覧を書くつもりはありません。考えたいのは、Customer 360の顧客理解を、適切なメッセージ、適切なタイミング、適切なチャネル、必要な人への引き継ぎへ変える設計です。そして2026年、Journey Creation AgentとOutreach Optimization Agentが登場したことで、マーケティングの設計と運用を、人とAgentがどう分担するかという問いが現実になりました。

 

第1回では、CRMが顧客台帳から顧客変革基盤へ進む全体像とAI Native CRM 6層モデルを整理しました。第2回では、Customer Identityが崩れると、AIは優秀でも顧客を間違えることを考えました。第3回では、FabricのMedallionアーキテクチャを使ってGolden Dataをどう育てるかを整理しました。第4回では、Golden DataからCustomer 360を組み立てるCustomer Intelligence層の設計を考えました。今回はさらに進み、その顧客理解を顧客接点と業務行動へ変える仕組みを考えます。

今回を書くにあたって、Agentic Engineering #03「エージェントはデータをどう使うか—CRMとERPのデータモデル」が引き続き基点にあります。AgentがデータをContextとして使う設計論は、JourneyがCustomer 360の理解を顧客接点の行動へ変える今回の議論と直結します。また、第4回で整理したCustomer 360の設計——Unified Profile、Measures、Segments、MCP Server——が、今回のJourneyへ渡すContextと同意評価の前提となります。さらに、マーケティング編｜Customer Insights – JourneysのCopilotとAgentで整理したJourney Creation AgentとOutreach Optimization Agentの現在地が、今回のAgent設計判断の直接的な前提になっています。

※ 本稿は2026年9月時点の情報をもとに執筆しています。Journey Creation AgentおよびOutreach Optimization AgentはPreviewであり、提供地域・言語・前提ライセンス・管理者設定は変更になる場合があります。対象環境で最新情報をご確認ください。

---

Customer 360が整っても、顧客接点は自動では変わらない

AI Native CRMの地図で見るJourney

第4回までで、Customer Identity、Golden Data、Unified Profile、Measures、Segmentsを積み上げてきました。ここまで来ると、「誰に連絡すべきか」は以前より正確になります。しかし、実際の顧客接点には、もう一段の設計が必要です。

誰を対象にするかだけでは足りません。なぜ連絡するのか。今は連絡してよいのか。どのチャネルが適切か。すでに別の部門が対応していないか。顧客が反応したら何を止め、何を始めるのか。反応がなければ、次に送るのか、人へ戻すのか。この判断を一つの流れとして表したものがJourneyです。

したがって、Journeyは企業が決めたメッセージを顧客へ押し出すベルトコンベアではありません。顧客の状態変化を受け取り、企業側の行動を組み替えるオーケストレーションです。マーケティングの自動化というより、顧客関係の意思決定を実行可能な形へ翻訳する仕組みと考えた方が本質に近いと思います。

---

Customer Insights – Journeysを「誰・何・いつ」の先まで読む

Customer Insights – Journeysでは、セグメントを起点にするJourneyと、顧客や業務の出来事を起点にするTriggerベースのJourneyを設計できます。メール、SMS、Push通知、カスタムチャネル等を組み合わせ、待機、条件分岐、終了条件、業務レコードの作成などを通じて、顧客接点を編成します。

製品を理解する入口としては、「誰に」「何を」「いつ」が分かりやすいでしょう。しかし、実務設計では、その前後に少なくとも四つの問いが加わります。

表1：Journeyは「誰・何・いつ」に、目的、許可、文脈、行動、学習を加えて初めて業務設計になる。

---

SegmentベースとTriggerベースをどう使い分けるか

SegmentベースのJourneyは、共通条件を満たす顧客集合へ継続的または計画的に働きかける場面に向きます。点検期限が一定期間内に到来する顧客、イベント対象地域の会員、一定期間購入がない顧客などです。対象はCustomer Insights – DataやDataverseの状態に応じて変化します。

TriggerベースのJourneyは、フォーム送信、イベント登録、購入、ケース解決、商談状態の変化など、顧客や業務で何かが起きた瞬間から始めます。ここでは、出来事の速さだけでなく、Triggerへ誰を結び付けるのか、重複イベントをどう扱うのか、同じ顧客が何度参加できるのか、既に目的を達成した顧客をどう終了させるのかが重要です。

表2：Segmentは「状態」を、Triggerは「出来事」を起点にする。どちらもIdentity、Consent、終了条件が必要である。

---

同意は最後のチェックではなく、Journeyの設計条件

対象Segmentへ入っていることと、メッセージを送ってよいことは同じではありません。Customer Insights – Journeysでは、メールアドレスや電話番号等のContact Pointを基準に同意を管理し、Compliance Profile、Purpose、Topic、適用モデルを使って、送信可否を評価します。

これは単なる法務チェックではありません。顧客が、どのブランドから、どの目的で、どの話題を、どの宛先とチャネルで受け取ることを望んでいるかを、Journeyへ実装する設計です。同じ人物でも、業務連絡は受け取りたいが販促は不要、メールはよいがSMSは不要、製品情報はよいがイベント案内は不要という選択があり得ます。

AIが魅力的なコンテンツや最適なタイミングを提案しても、利用目的と同意が合わなければ送るべきではありません。Agentへ渡す自由度を高めるほど、変更できない境界を先に決めます。

---

Journey Creation Agentは何を変えるのか

Journey Creation Agentは、自然言語で目的、対象、期間、チャネル等を説明すると、既存のSegment、Trigger、Content Assetを参照し、Journeyの構造、待機、分岐、チャネルの並びを提案するAI支援機能です。2026年9月時点ではPreviewであり、利用地域、バージョン、権限、AI HubやCopilot容量等の前提を対象環境で確認する必要があります。なお2026年9月時点では日本語非対応、英語のみです。

重要なのは、Agentがマーケティング戦略を代わりに持つわけではないことです。目的が曖昧なら、作られるJourneyも曖昧です。対象SegmentやTriggerの意味が不明なら、正しそうに見える構造でも、顧客と業務の意図がずれます。既存コンテンツが古ければ、古い内容をきれいに並べるだけです。

Journey Creation Agentの価値は、キャンバス操作を短縮することだけではありません。マーケターが頭の中に持っていた目的、開始条件、待機、分岐、終了条件を会話として外へ出し、レビュー可能な構造へ変えることです。Agentが不足情報を問い返し、人が提案を確認・修正してから公開する。この過程そのものが、マーケティング設計を標準化する入口になります。

---

Outreach Optimization Agentは「いつ送るか」をどう変えるか

Outreach Optimization Agentは、過去のエンゲージメントパターンを分析し、メールの送信タイミングを最適化するJourney Stepです。2026年9月時点ではPreviewです。履歴が十分でない環境ではフォールバックを使い、設定されたQuiet TimeとContact Point Consentを尊重します。

ここでも過大評価は禁物です。現在の中心は、定義されたJourneyの中でメールを送るタイミングを調整することです。顧客の自由記述を理解してブランド戦略を変えるものでも、メッセージ内容の妥当性を保証するものでもありません。最適化したいGoal、対象、終了条件、フォロー回数、コンテンツ品質は人が決めます。

送信時間を最適化することは、単に開封率を上げる話でもありません。不要な時間帯の接触や過剰なフォローを減らし、顧客の生活時間を尊重しながら、必要な情報が届く可能性を高めることです。KPIも、開封やクリックだけでなく、商談化、予約、解決、配信停止、苦情、顧客疲労まで含めて読みます。

表3：Agentは候補と最適化を担う。目的、許可、ブランド、例外、公開、停止の責任は人が持つ。

---

Customer 360とJourneyを同期する「三つの時計」

Customer Insights – DataのProfile、Measure、Segmentは更新処理を通じて変化します。Customer Insights – Journeysは、実行時にそれらを読み取り、PersonalizationやConsent評価へ使います。更新途中にJourneyが顧客を処理すると、ProfileやMeasureがまだ書き込まれていない、Segmentの状態とProfileの時点がそろっていない、といった不整合が起こり得ます。

さらに、データが最新でも、顧客にとって不適切な時間なら送るべきではありません。企業の更新時間、Journeyの実行時間、顧客の生活時間は別々に動きます。これが「三つの時計」です。

Quiet Timeは、夜間や休日の配信を避けるだけでなく、Customer Insights – Dataの更新ウィンドウを覆うように設定する使い方もできます。ただし、更新時刻は固定の開始時刻だけでなく、処理時間や依存ノードによって変わります。開始前とHydration完了後にBufferを置き、実績を監視しながら調整します。

Frequency Capは複数Journeyにまたがる過剰接触を抑える重要なガードレールです。顧客は社内のキャンペーン単位を知りません。販売、サービス、イベント、会員、ブランドが別々に最適化すると、顧客には「同じ企業から何度も来る」と見えます。チャネル、Purpose、ブランド、地域を横断して、顧客一人の接触量を考える必要があります。

---

リアルタイムとは「すぐ送る」ことではない

リアルタイムJourneyという言葉から、Triggerが発生したら即座にメッセージを送る姿を想像しがちです。しかし、本当に重要なのは速度ではありません。顧客の状態が変わったとき、正しいIdentityと文脈を使い、許された目的とチャネルで、意味のある時間に行動することです。

例えば、顧客がサービス予約を完了した直後に、同じ予約を促すメールを送れば、システムは速くても体験は遅れています。苦情対応中の顧客へ販促を続ければ、Segmentが正しくても企業としては顧客を理解していません。商談が成立したのにナーチャリングを止めなければ、Journeyの終了条件が業務結果とつながっていません。

---

自動車業界で考えるService Recovery Journey

自動車業界の一般例で考えます。高価値顧客の車両が長期間入庫しておらず、直近の問い合わせでは不満が残り、コールセンターの接触回数も増えている。Customer Insights – Dataでは、Unified Profile、VehicleとのRelationship、最終入庫日のMeasure、ネガティブなFeedback、要フォローSegmentが作られています。

ここで単純に割引メールを送ると、顧客の不満を無視した販促に見える可能性があります。Journeyの目的は「点検予約を増やす」だけではなく、「未解決の不満を確認し、信頼を回復し、安全な車両利用へつなぐ」と置くべきです。

表4：Journeyの目的を「配信」ではなく顧客状態の改善に置くと、マーケティング、営業、サービスの役割が一つの流れへつながる。

---

JourneyからSales、Serviceへ仕事を渡す

Customer Insights – Journeysの価値は、デジタルメッセージだけで閉じません。顧客の反応や条件に応じて、Lead、Opportunity、Case等の業務レコードを作成し、営業・サービス側の人やAgentへ仕事を渡せます。

この接続で重要なのは、レコードを作れることではなく、何を引き継ぐかです。顧客がどのJourneyのどのStepにいたのか。何を見て、何をクリックし、何に反応しなかったのか。どのProfile、Measure、Segmentを根拠に対象となったのか。何を説明し、何を繰り返してはいけないのか。単なる「新規Task」ではなく、次の担当者が顧客との会話を継続できるContextを渡します。

次回のDynamics 365 Salesでは、この接続をさらに進め、マーケティングシグナルを商談の次の行動へどう変えるか、Sales Agentと営業担当者の境界を考えます。

---

AgentとJourneyで失敗しやすい十の設計

表5：Agentを追加しても、目的、同意、時間、終了、人への引き継ぎが設計されていなければ顧客体験は改善しない。

---

マーケティングをAgentと設計する十二の原則

---

読者別に、何が変わるのか

表6：マーケティングをAgentと設計するとは、マーケターだけでなく、データ、業務、AI、経営の責任を接続することである。

---

Customer Insights – Journeysは、顧客理解を企業の行動へ変える

Customer 360が「顧客を理解し続ける能力」だとすれば、Customer Insights – Journeysは、その理解を顧客接点と社内業務の行動へ変えるオーケストレーションです。

誰を対象にするか。何が起きたら始めるか。送ってよいか。どの文脈を使うか。今送るべきか。どのチャネルで届けるか。どこで人へ戻すか。何が起きたら止めるか。その結果を次のCustomer 360へどう返すか。Journeyは、この一連の判断を実行可能な形へ落とします。

Journey Creation AgentとOutreach Optimization Agentは、その設計と運用を変え始めています。ただし、Agentがマーケティングの目的と責任を引き受けるわけではありません。Agentは人の意図を構造とタイミングへ翻訳し、反復を速くします。人は、顧客価値、ブランド、同意、例外、公開、停止、結果への責任を持ちます。

次回は、Dynamics 365 Sales × AIへ進みます。Journeyで生まれた顧客シグナルを、商談の優先順位、次の行動、会議、フォローへどう変えるのか。営業担当者を置き換えるのではなく、Sales Agentと人が商談をどう動かすかを考えます。

---

Let’s Enjoy our DX365LIFE!

---

次回以降：第6回「Dynamics 365 Sales × AI — 商談を動かすAgent」。Journeyで生まれた顧客シグナルを商談の優先順位と次の行動へどう変えるか。Sales AgentとCopilot for Salesが営業担当者とどう仕事を分担するかを考えます。
※Journey Creation AgentとOutreach Optimization AgentはPreviewです（2026年9月時点）。提供地域、言語、バージョン、権限、AI Hub、Copilot容量、ライセンス、前提設定は対象環境で最新情報を確認してください。