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

いま続編で再び日本中を熱狂させているドラマ『VIVANT』、皆さんは観ていますでしょうか。 あの物語の始まりは、1本の誤送金データという「単なる数字のシグナル」でした。 しかし、野崎や乃木が暴いていったのは、その数値の裏に潜む「なぜ送金されたのか」「誰が裏で糸を引いているのか」という生々しい相関図と文脈でした。 システムが検知したログそのものには意味がなく、それを解釈して次の一手を打つインテリジェンスがあって初めて巨大な事態が動いていく。 この「シグナルから文脈へ」という構造は、まさにエンタープライズの顧客接点設計そのものです。

さて、前回はDynamics 365 Customer Insights – Journeysを、Customer 360の顧客理解を顧客接点と業務行動へ変える意思決定ループとして考えました。誰を対象にするのか。何が起きたら始めるのか。送ってよいのか。いつ、どのチャネルで届けるのか。どこで人へ戻し、何が起きたら止めるのか。Journeyは、この一連の判断を実行可能な形へ落とします。

しかし、顧客がメールを開いた、資料をダウンロードした、イベントへ参加した、問い合わせをしたというシグナルがSalesへ渡っても、それだけでは商談は動きません。営業担当者が必要なのは「反応があった」という通知だけではなく、なぜ今なのか、誰が関係しているのか、何を求めているのか、何が未解決なのか、次に何をすべきかという文脈です。

今回の主役はDynamics 365 Salesです。ただし、Lead、Opportunity、Quoteの機能一覧を書くつもりはありません。考えたいのは、Customer 360、Journey、メール、会議、活動履歴に散在するシグナルを、営業担当者が実行できる次の行動へ変え、商談の前進を「入力件数」ではなく「顧客の意思決定が進んだ証拠」で捉える設計です。

第1回では、CRMが顧客台帳から顧客変革基盤へ進む全体像とAI Native CRM 6層モデルを整理しました。第2回では、Customer Identityが崩れると、AIは優秀でも顧客を間違えることを考えました。第3回では、FabricのMedallionアーキテクチャでGolden Dataを育てる方法を整理しました。第4回では、Golden DataからCustomer 360を組み立てるCustomer Intelligence層を設計しました。第5回では、Customer 360の顧客理解を顧客接点と業務行動へ変えるJourneyの設計を考えました。今回はさらに進み、JourneyやCustomer 360から届いたシグナルを、営業担当者が実行できる商談の次の一手へ変える設計を考えます。

今回を書くにあたって、Agentic Engineering #03「エージェントはデータをどう使うか—CRMとERPのデータモデル」が引き続き基点にあります。AgentがCRMのLead、Opportunity、Account、ActivityをContextとして使う設計論は、Sales Qualification AgentやSales Opportunity AgentがどのCRMデータにアクセスし、何を判断材料にするかを考える今回の議論と直結します。また、第5回で設計したJourneyのContext—Trigger反応、Consent確認、Segmentの状態—が、今回の引継ぎ品質と商談前進の議論の前提になります。

---

Salesへシグナルが届いても、商談は自動では動かない

AI Native CRMの地図で見るSales

第5回のJourneyは、顧客の反応に応じてSalesへ仕事を渡せます。しかし、Leadを作り、Taskを登録し、担当者へ通知するだけでは、部門間のバトンは渡ったことになりません。営業担当者がゼロから顧客を調べ、過去のメールを探し、会議メモを読み、問い合わせ履歴を確認するなら、単に仕事の入口を移しただけです。

営業のAI活用で最初に変えるべきは、メール文章の生成ではなく「判断の準備」です。今日どの商談を見るべきか。何が変わったのか。誰が意思決定へ影響するのか。競合やリスクは何か。次の会話で何を確かめるのか。AIがこの準備を支援し、人が顧客との対話へ時間を使えるようにします。

---

Dynamics 365 SalesをSystem of Recordの先で読む

従来のCRMでは、Lead、Opportunity、Account、Contact、Activityが正しく登録されていることが重視されました。もちろん記録は必要です。しかし、記録が最新でも、次に何をするかが分からなければ、営業活動は進みません。反対に、現場がCRMへ入力しないと、AIもマネージャーも現実を誤って理解します。

Dynamics 365 Salesは、記録をなくすのではなく、記録と会話の間にある摩擦を減らす方向へ進んでいます。Copilotは営業案件やリードの要約、最近の変更、会議準備、メール支援、取引先企業の情報把握を支援します。さらに、Sales Qualification Agent、Sales Opportunity Agent、Sales Research Agent、Recommended Actions Agent等が、営業プロセスの異なる判断を支援します。

---

CopilotとSales Agentは同じものではない

Dynamics 365 SalesのAIを一括して「Copilot」と呼ぶと、役割が曖昧になります。営業担当者の問いに応じて要約や準備を支援するCopilotと、定義された対象、評価基準、知識、権限、引継ぎ条件に基づいて継続的に処理するAgentは、同じAIでも働き方が異なります。

表1：Copilotは人の仕事の流れで支援し、Agentは構成された目的と境界の中で継続的に働く。どちらも、顧客との約束や売上責任を所有するわけではない。

---

Sales Qualification Agentは、Leadの「調査待ち」を減らす

Leadが多い組織では、営業担当者がすべてを同じ深さで調べることはできません。その結果、見込みの高いLeadが未対応のまま残る一方で、適合度の低いLeadへ時間を使うことがあります。Sales Qualification Agentは、この入口の調査と評価を支援します。

Research-onlyモードでは、Leadを調査し、Target Customer Profileへの適合を評価し、初期アウトリーチメールを生成します。Research and engageモードでは、調査に加えてメールによる初期接触とフォローアップを行い、購入意向やBANT等の条件を確認し、構成された引継ぎ条件に達したLeadを営業担当者へ渡します。

重要なのは、Lead ScoringをAIへ置き換えることではありません。どの市場、製品、地域、企業規模を狙うのか。既存顧客、競合、パートナー、問い合わせ中の顧客をどう扱うのか。どの表現と頻度で接触できるのか。何をもって人へ渡すのか。この営業戦略を、Agentが実行できる評価基準とPlaybookへ翻訳します。

---

引継ぎはLead名とTaskではなく、Context Packageで行う

Sales Qualification AgentやJourneyから営業担当者へLeadを渡すとき、最も重要なのは「引継ぎの質」です。顧客名、会社名、メールアドレス、Taskだけでは、営業担当者は会話を最初からやり直します。顧客側から見れば、すでに企業へ伝えたことをもう一度説明させられます。

引継ぎには、少なくとも、なぜ今対象なのか、何に反応したのか、どの顧客課題が見えているのか、誰が関係しているのか、どの質問に回答済みか、何が未解決か、どの根拠から適合と判断したのか、次に推奨される行動は何かを含めます。さらに、情報の出所と更新時刻を残し、営業担当者が確かめるべき仮説と事実を分けます。

表2：良い引継ぎはレコードの移動ではなく、会話を継続するための文脈の移管である。

---

Sales Opportunity Agentは「止まり始めた商談」を見つける

商談が止まる兆候は、StageやClose Dateだけには表れません。顧客からの返信が遅くなる。重要な関係者が会議へ参加しない。次回アクションが曖昧になる。競合が話題に上がる。提案後の質問が増える。Serviceの問題が未解決のまま残る。こうした変化は、メール、会議、活動、CRMレコードに分散します。

Sales Opportunity Agentは、Opportunityを継続的に調査し、発生し始めたリスクや有望な機会を可視化し、商談を進めるための示唆を提供します。ただし、リスクを検出することと、商談戦略を決めることは同じではありません。AIが示した変化を、顧客の事情、組織政治、契約条件、競合状況と照らし合わせ、人が意味を判断します。

ここで必要なのは、すべての商談へ同じPlaybookを適用することではありません。高額・複雑な案件、短期・定型的な案件、既存顧客の更新、クロスセルでは、見るべきリスクも次の行動も異なります。Agentの対象と評価基準は、営業モーションごとに分けます。

---

商談はStageではなく「顧客の意思決定が進んだ証拠」で動かす

Opportunity Stageは営業管理に必要ですが、Stageを更新したこと自体は商談の前進ではありません。提案書を送った、会議を実施した、見積を提出したという活動も、それだけでは顧客の意思決定が進んだ証拠になりません。

顧客課題が合意された。意思決定者が確認された。評価基準が明らかになった。予算と時期の前提が共有された。顧客側の次の行動が決まった。未解決のリスクにOwnerと期限が付いた。このようなEvidenceを、Stage、Forecast、Next Stepの根拠として残します。

表3：AIが優先順位を支援するほど、StageやForecastを支えるEvidenceの定義が重要になる。

---

Recommended Actionsは「やることリスト」ではない

次の行動を提示する機能は、Taskを増やすだけでは価値になりません。営業担当者の一日は有限であり、重要なのは、なぜその行動が今必要なのか、顧客の何を変えたいのか、実行しなかった場合に何が起きるのか、誰が最も適切なOwnerなのかを示すことです。

Recommended Actions Agentは、複数のシグナルから優先順位付きの行動を提示します。営業組織は、優先度を売上金額だけで決めないようにします。顧客影響、期限、関係性、解決していないService問題、戦略的重要性、リスク、実行可能性を含めて考えます。

---

会議の前後をCopilotで一つの営業ループにする

営業活動の多くは会議の前後で分断されます。会議前はCRM、過去メール、資料、ニュースを探し、会議中はメモを取り、会議後は要約、Task、フォローアップメール、Opportunity更新を行います。この分断が大きいほど、顧客との対話より記録作業へ時間を使います。

Dynamics 365 SalesのCopilotとMicrosoft 365側のSales agentを組み合わせると、OpportunityやLeadの概要、最近の変更、会議準備、会議後のSales Insights、フォローアップメール、CRM Taskやメモへの接続を、Outlook、Teams、Dynamics 365等の仕事の流れで扱えます。

ただし、会議要約が自動生成されても、顧客の合意を勝手に確定してはいけません。AIが取り違えやすい固有名詞、金額、期限、否定、皮肉、条件付き発言を人が確認します。特に、顧客の約束、自社のCommit、価格・契約条件、法務・信用に関わる内容は、人のレビュー後に正式記録へ反映します。

---

自動車業界で考える法人フリート更新商談

自動車業界の一般例で考えます。法人顧客がWebでEVフリートの資料を閲覧し、Customer Insights – Journeysのウェビナーへ参加しました。既存車両のリース更新時期が近く、Service側では一部車両の稼働停止時間が増えていることも分かっています。

ここで「資料閲覧あり」というLeadだけを営業へ渡しても弱いでしょう。Sales Qualification Agentが企業情報、対象地域、保有台数の手掛かり、Target Customer Profileへの適合、購入意向を調べます。Journeyの反応、既存Account、VehicleとのRelationship、Service履歴をContext Packageへまとめ、営業担当者へ渡します。

営業担当者は、その情報を事実として鵜呑みにせず、車両更新の目的、充電環境、稼働条件、財務条件、調達プロセス、意思決定者を確認します。Sales Opportunity Agentは、その後の会議、メール、活動、Opportunityの変化から、関係者不足、返信停滞、競合、Close Dateの不整合等を示します。Recommended Actions Agentは、充電設備担当者との会議、TCO試算、Service専門家の参加等を候補として提示します。

表4：自動車の法人商談でも、Agentは判断準備と継続監視を担い、人は顧客理解、価値提案、交渉、約束、責任を担う。

---

Sales Agentを安全に動かすガードレール

Sales Agentが顧客と直接やり取りするほど、従来のCopilotより強いガードレールが必要です。営業メールを生成できること、送信できること、顧客の意図を推定できること、Leadを不適格と判断できることは、それぞれ異なるリスクを持ちます。

表5：Agentの自由度は、目的、対象、権限、Knowledge、Handoff、監視を強く設計した範囲でのみ広げる。

---

商談を動かすAgentで失敗しやすい十の設計

表6：Agentが賢くても、営業戦略、Evidence、Context、承認、学習がなければ商談は強くならない。

---

Dynamics 365 Sales × AIを設計する十二の原則

---

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

表7：Sales × AIは営業部門だけの機能導入ではない。マーケティング、データ、IT、ガバナンス、経営を商談の判断へ接続する。

---

Dynamics 365 Salesは、商談記録を「次の一手」へ変える

Dynamics 365 Salesは、LeadやOpportunityを管理する場所であることをやめるわけではありません。むしろ、記録の品質と顧客文脈がAgent時代にはこれまで以上に重要になります。違いは、CRMが営業担当者に入力を求めるだけではなく、その記録と会話から次の行動を返すことです。

Sales Qualification AgentはLeadの調査と評価を支援し、Sales Opportunity Agentは商談のリスクと機会を見つけ、Recommended Actions Agentは優先行動を提示し、CopilotとMicrosoft 365のSales agentは日々の仕事の流れで要約、準備、フォローを支援します。しかし、顧客の課題を理解し、価値を提案し、関係をつくり、交渉し、約束し、結果へ責任を持つのは人です。

AIが営業を置き換えるのではありません。営業担当者が情報を探し、転記し、要約し、漏れを確認する時間を減らし、顧客との対話と判断へ戻す。そのために、CRMを顧客台帳から、顧客シグナルを商談の次の一手へ変えるSystem of Actionへ進化させます。

次回は、Dynamics 365 Customer Service × AIへ進みます。問い合わせを要約するだけでなく、Knowledge、Case Context、Routing、Resolution、Escalationをどう組み合わせ、Agentと人が「解決」に責任を持つのかを考えます。

---

Let’s Enjoy our DX365LIFE!

---

次回以降：第7回「Dynamics 365 Customer Service × AI — 問い合わせを解決するAgentの設計」。Knowledge、Case Context、Routing、Resolution、Escalationをどう組み合わせ、AgentとCopilotが人と「解決」の責任をどう分担するかを考えます。
※Recommended Actions AgentはPreviewです（2026年9月時点）。提供地域、言語、バージョン、権限、ライセンス、前提設定は対象環境で最新情報を確認してください。