Microsoft 365 CopilotのSales agent会議準備が拡張｜データソース追加の条件・管理策

Microsoft 365 CopilotのSales agentでは、顧客との会議前に作成する準備情報へ、サービスチケットなどの追加データソースを反映できるようになる予定です。これにより、商談や過去のメールだけでなく、未解決の問い合わせや障害対応を把握したうえで会議に臨めます。

今回の更新「Microsoft Copilot (Microsoft 365): Enrich Sales agent meeting prep with more data sources」は、2026年7月9日時点で開発中です。プレビューは2026年9月、ロールアウト開始は2027年3月が予定されています。ただし、Microsoft 365 Roadmapの日程は変更される可能性があります。(Microsoft)

結論として、すでにSales agentとCRMを利用している企業は、機能公開を待つだけでは不十分です。問い合わせ履歴をどこまで営業担当者へ見せるか、顧客とチケットを正しく関連付けられるか、地域間データ移動を許可できるかを、プレビュー前に整理しておく必要があります。一方、Sales agentや対応CRMを導入していない企業では、現時点で設定変更を急ぐ必要はありません。

対応が必要な企業と、まだ様子を見てよい企業

今回の更新に対する優先度は、Microsoft 365 Copilotの契約有無だけでは判断できません。Sales agentの利用状況、CRM、サービスチケットの管理方法を組み合わせて考えます。

現在の環境	対応優先度	今から行うこと
Sales agentを利用し、CRMと問い合わせ管理システムに顧客データがある	高	データ項目、アクセス権、顧客との関連付けを整理する
Sales agentを利用しているが、会議インサイトを無効にしている	中	無効化の理由を確認し、限定ユーザーでの検証可否を判断する
Microsoft 365 Copilotは利用しているが、Sales agentは未導入	中	営業部門の会議準備業務と導入効果を確認する
対応CRMを利用していない、またはオンプレミス環境のみ	低	対応範囲の拡大を監視し、現時点では大規模な変更を行わない
独自の会議準備AIを開発・運用している	高	重複機能と、独自開発を残すべき要件を整理する

特に優先度が高いのは、営業部門とサポート部門で情報が分断されている企業です。営業担当者がアップセルを提案した直後に、顧客から「重大障害が解決していない」と指摘されるような状況を減らせる可能性があります。

Sales agentの会議準備で何が変わるのか

Microsoftの公式説明では、Sales agentの会議準備に、サービスチケットなどの追加データソースを利用できるようになるとされています。管理者はSales agentの管理画面を通じて、会議準備へ反映するデータソースを設定できる予定です。(Microsoft Learn)

現行の会議準備はCRMと過去のコミュニケーションが中心

現行のSales agentは、会議参加者をCRMの連絡先と照合し、関連する営業案件を特定します。そのうえで、CRMに保存された過去のメールや会議、関連する営業情報から、リスクや推奨アクションを生成します。複数の案件が関連する場合は、一定のルールに基づいて一つの案件が選択されます。(Microsoft Learn)

この仕組みは商談の経緯を把握するには役立ちますが、サポート部門が管理している次のような情報が見えない場合があります。

未解決の問い合わせ
重大な障害やエスカレーション
回答期限やSLAの超過
顧客が繰り返し報告している問題
サポート部門が約束した次回対応
製品への不満や解約につながる兆候

CRM上では商談が順調に見えても、サポート側では深刻な問題が続いていることがあります。今回の更新は、このような「営業から見える顧客像」と「サポートから見える顧客像」の差を縮めるものです。

更新後はサービス状況を含めて会議を準備できる

想定される変化を整理すると、次のようになります。

観点	現行の会議準備	データソース拡張後
主な参照情報	CRM、営業案件、過去の会議やメール	左記に加え、サービスチケットなど
顧客理解	商談や営業活動が中心	商談と利用後の問題を横断して把握
会議アジェンダ	提案、契約、次回アクションが中心	未解決問題への説明や担当者同席も検討可能
リスク検知	商談上の停滞や懸念	障害、問い合わせ、対応遅延も判断材料になる
管理	CRM情報と会議インサイトの設定	会議準備へ反映するデータソースの選択が加わる予定

重要なのは、今回示されているのが会議準備に利用する情報の拡張である点です。サービスチケットの自動更新、問い合わせへの自動返信、障害の自動解決、CRMへの書き戻しが行われるとは発表されていません。

Sales agentが問題を解決するのではなく、営業担当者が問題を見落としにくくする更新と考えるのが適切です。

提供時期と現在のステータス

2026年7月9日時点の公式ロードマップ情報は次のとおりです。

項目	内容
Roadmap ID	567003
ステータス	開発中
プレビュー予定	2026年9月
ロールアウト開始予定	2027年3月
対象サービス	Microsoft 365 Copilot
主な変更	Sales agentの会議準備で追加データソースを利用可能にする

Microsoft 365 Roadmapに掲載される時期は予定であり、プレビューやロールアウトが延期される可能性があります。社内プロジェクトの確定日として扱わず、プレビュー開始後に対象テナント、対応地域、ライセンス条件を再確認してください。(Microsoft)

また、ロードマップ上の「ロールアウト開始」は、すべてのテナントで同じ日に利用可能になることを意味しません。段階的な展開では、テナントによって利用開始時期が異なる場合があります。

利用前に満たす必要がある条件

今回の更新だけを有効にしても、Sales agentの会議準備は利用できません。前提となるライセンス、CRM接続、管理者設定、ユーザー権限が必要です。

Microsoft 365 CopilotとSales agentが必要

現行の公式ドキュメントでは、Sales agentを利用するために、少なくとも次の準備が必要とされています。

ユーザーがMicrosoft 365 Copilotを利用できること
Sales agentが導入されていること
OutlookおよびTeamsからSales agentを利用できること
Sales Chatが有効であること
対応するCRMへ接続されていること
CRM側でユーザーと管理者に必要な権限があること

現在、Sales agentの接続先として案内されているCRMは、Dynamics 365 SalesとSalesforceです。(Microsoft Learn)

正式提供までにライセンス条件が変更される可能性もあるため、プレビュー参加時にはMicrosoftの製品条項と管理センター上の表示を改めて確認する必要があります。

現行の会議準備には対象会議の条件がある

Sales agentの会議準備カードは、すべての予定に対して作成されるわけではありません。現行仕様では、外部参加者を含む将来の会議であることに加え、非公開会議、終日予定、定期的な会議、キャンセル済み会議などは対象外になる場合があります。

また、会議の作成時に準備カードが生成され、後から予定を変更しても新しいカードが生成されないという制約があります。(Microsoft Learn)

追加データソースの設定が正しくても、会議自体が対象条件を満たしていなければ情報は表示されません。検証時には、設定だけでなく会議の種類も確認してください。

顧客、連絡先、営業案件、チケットの関連付けが必要

追加データソースを活用するには、チケットが存在するだけでは不十分です。Sales agentが会議参加者から顧客企業を特定し、その企業に関連するチケットを取得できるデータ構造が必要です。

最低限、次の関係をたどれる状態が望まれます。

会議の外部参加者
  ↓
CRMの連絡先
  ↓
取引先・顧客企業
  ↓
営業案件
  ↓
サービスチケット

連絡先の重複、異なる表記の企業名、共有メールアドレス、販売代理店を経由した契約などがあると、別の顧客情報を参照したり、必要なチケットを見落としたりする可能性があります。

今回の更新で重要なのは、生成AIのプロンプトを工夫することよりも、顧客データの識別子と関連付けを整えることです。

データ境界とアクセス権で確認すべきこと

サービスチケットには、営業案件よりも機密性の高い情報が含まれやすくなります。機能の利便性だけでなく、「誰が、どの情報を、どの経路で参照できるのか」を確認する必要があります。

Sales agentは既存のCRM権限を引き継ぐ

現行のSales agentは、CRMに設定されているアクセス制御とユーザー権限を適用します。原則として、ユーザーがCRM上で参照できない情報を、Sales agent経由で自由に参照できる仕組みではありません。(Microsoft Learn)

ただし、元の権限設定が広すぎれば、Sales agentから見える範囲も広くなります。営業担当者が本来確認する必要のない次の情報が含まれていないか確認してください。

セキュリティ事故の詳細
認証情報や秘密情報
顧客担当者の私的な情報
社内限定の法務判断
補償や返金に関する未承認の検討内容
他社や他部署に関する内部メモ
サポート担当者による主観的な評価

「AIへ見せてよいか」ではなく、「その営業担当者が業務上参照してよいか」を基準に判断します。

現行設定では追加したCRMエンティティの全列に注意する

現在のSales Chatの管理ドキュメントでは、管理者がCRMのエンティティやテーブルを追加すると、Sales agentがそのエンティティに含まれるすべての列へアクセスすると説明されています。(Microsoft Learn)

今回追加される会議準備用データソースにも同じ仕様が適用されるかは、ロードマップの説明だけでは確認できません。プレビューでは、次の単位で制御できるかを必ず検証してください。

データソース単位
テーブルやオブジェクト単位
レコード単位
列やフィールド単位
セキュリティグループ単位
会議やユーザー単位

フィールド単位の制御ができない場合は、Sales agent専用のビュー、連携用テーブル、要約済みの安全なデータセットを用意する方法も検討します。

生成された会議インサイトはDataverseに保存される

現行仕様では、生成された顧客会議インサイトはDataverseに保存され、保持期間は90日とされています。会議参加者や、関連するCRM営業案件へのアクセス権を持つユーザーが参照できます。非公開会議のインサイトはDataverseへ保存されません。(Microsoft Learn)

今回の追加データソースから生成された内容についても同じ保存ルールが適用されるか、プレビュー時に確認が必要です。特に確認したいのは次の点です。

元のチケット本文が保存されるのか
要約結果だけが保存されるのか
保存先と保持期間を変更できるのか
元データを削除した後も要約が残るのか
監査ログで参照や生成を追跡できるのか

ロードマップだけでは、これらの詳細は公表されていません。

日本の環境では地域間データ移動の同意を確認する

現行の公式情報では、日本を含む一部地域のCRM環境でSales agentのCopilot AI機能を使用する場合、管理者による地域間データ移動への同意が必要とされています。同意しない場合、Copilot AI機能を利用できず、会議インサイトも生成されません。(Microsoft Learn)

日本企業では、管理者が設定を有効にする前に、情報システム部門だけで判断しないことが重要です。法務、セキュリティ、個人情報保護、データ管理の担当者と、次の項目を確認してください。

対象となるデータの種類
処理される可能性がある地域
社内のクラウド利用基準
顧客との契約や秘密保持義務
越境移転に関する社内手続き
利用停止時のデータ取り扱い

公開情報の検索にはBingが利用される

Sales agentは会議準備のために公開情報を取得する際、Bing Searchを利用します。外部参加者のメールドメイン、氏名、企業名などを基に検索クエリを作成する場合があり、クエリはBingのデータセンターで処理される可能性があります。

Microsoftは、Bingへ個人を特定できる情報を渡さず、公開Web情報の取得に限定すると説明しています。(Microsoft Learn)

CRMやサービスチケットのデータ境界だけでなく、公開情報検索の経路もセキュリティレビューの対象に含めてください。

管理者が確認すべき設定

Sales agentには、テナント、環境、機能の複数階層に管理設定があります。今回の機能が追加されたときは、新しいデータソース設定だけを見るのではなく、既存の設定と組み合わせて確認します。(Microsoft Learn)

設定・制御	確認内容
Copilot AI	テナントまたは環境でAI機能が許可されているか
Sales Chat	有効か、対象ユーザーが適切か
Meeting insights	会議インサイトの生成と保存が許可されているか
セキュリティグループ	検証対象者だけに機能を限定できているか
CRM権限	営業担当者が必要以上の情報を参照できないか
CRMエンティティ	対象テーブルと列の範囲が過剰でないか
地域間データ移動	日本の環境で必要な同意と社内承認が完了しているか
新しいデータソース設定	どのチケット情報を会議準備へ含めるか
保存・監査	生成内容の保存先、保持期間、監査方法が明確か

現行のSales Chatは既定で全ユーザーに有効となる場合があります。管理者がSales Chatを無効にすると、Sales agent自体が画面に残っていても、回答へ営業データが含まれなくなることがあります。(Microsoft Learn)

「アイコンが表示されているから利用可能」と判断せず、対象ユーザー、Sales Chat、会議インサイト、CRM接続をそれぞれ確認してください。

会議準備へ含める情報の判断基準

サービスチケットの全情報をSales agentへ渡す必要はありません。会議前の意思決定に必要な情報を絞ることが重要です。

含める価値が高い情報

チケットの状態
重要度や優先度
発生日時と最終更新日時
担当部門
対応期限
エスカレーションの有無
顧客へ伝達済みの次回アクション
同じ問題の発生回数
製品、契約、営業案件との関連

原則として除外を検討する情報

パスワード、トークン、秘密鍵
詳細な脆弱性情報
個人の健康状態や私生活に関する情報
社内調査中の人事情報
未承認の補償額や法務方針
他の顧客に関する情報
営業担当者が判断に利用できない生ログ
顧客へ開示できない内部コメント

判断に迷う場合は、次の質問を使います。

この情報が会議準備の要約に表示され、その画面を営業担当者が共有したとしても問題ないか。

答えが明確に「はい」でなければ、その項目を直接連携しない方が安全です。

業務で効果が出やすい活用シーン

契約更新前に未解決問題を確認する

契約更新の会議前に重大なチケットが残っていれば、価格や追加契約の提案より先に、問題の説明と解決計画を用意できます。

必要に応じて、サポート責任者や技術担当者へ同席を依頼する判断も早くなります。

アップセル提案のタイミングを判断する

チケットが多いからといって、必ずしもアップセルを見送るべきとは限りません。

たとえば、容量不足や利用者数の増加による問い合わせが繰り返されている場合、上位プランや追加リソースの提案が問題解決につながる可能性があります。一方、製品不具合が未解決なら、先に信頼回復を優先すべきです。

Sales agentの要約は提案の可否を決定するものではなく、営業担当者が状況を判断するための材料として使います。

営業とカスタマーサクセスの認識を合わせる

営業、カスタマーサクセス、サポートで異なるシステムを使っていると、同じ顧客を見ていても認識がずれます。

会議準備で共通の問題状況を確認できれば、次のような調整を会議前に行えます。

顧客へ伝える説明内容を統一する
誰が問題を説明するか決める
約束済みの期限を再確認する
新規提案と問題対応の順序を決める

営業マネージャーが準備品質を標準化する

経験豊富な営業担当者は、会議前に複数のシステムを確認します。しかし、担当者ごとに確認範囲が異なると、重要な問題を見落とす可能性があります。

Sales agentを利用すれば、最低限確認すべき顧客情報を共通化しやすくなります。ただし、AIの出力には誤りが含まれる可能性があるため、元データの確認を前提とした運用ルールが必要です。Microsoftも生成された内容を確認するよう案内しています。(Microsoft Learn)

開発・運用チームが準備すべきこと

今回の更新に対して、最初から新しいアプリを開発する必要はありません。まず、標準機能でどこまで要件を満たせるかを確認します。

プロンプトより先にデータモデルを整える

開発チームが優先すべきなのは、プロンプトの調整ではなく次の整備です。

顧客企業を一意に識別するキーを決める
CRMの取引先とサービス管理側の顧客を対応付ける
連絡先の重複を統合する
チケットと製品、契約、営業案件を関連付ける
終了済みチケットを適切に除外できる状態にする
最終更新日時とデータの鮮度を確認できるようにする
機密項目を分類し、アクセス権へ反映する

顧客名の文字列一致だけに依存すると、同名企業、グループ会社、表記揺れで誤った関連付けが発生します。CRM IDや統合済みの顧客IDを利用する設計が望まれます。

独自開発を残すべきケース

標準機能のプレビュー後も、次の要件がある場合は独自連携や専用エージェントが必要になる可能性があります。

対応していないサービス管理システムを利用している
数分以内のリアルタイム反映が必要
会議準備からチケット更新や担当者変更まで実行したい
自社独自の顧客リスクスコアを使いたい
出力に必ず情報源や証跡を付けたい
特定業界向けの厳格な保存・監査要件がある
複数の顧客IDを独自ロジックで統合する必要がある

ロードマップでは、今回の機能に専用APIや開発者向け拡張ポイントが提供されるとは示されていません。公開されていないAPIを前提に設計を始めず、プレビューで標準機能と管理画面を確認してから開発範囲を決めるべきです。

パイロットでは精度と安全性を数値で確認する

「便利だった」という感想だけでは、本番展開の判断材料として不十分です。次の指標を用意すると、効果とリスクを比較できます。

評価指標	確認する内容
チケット反映率	会議前に必要な未解決チケットが表示された割合
顧客誤判定率	別企業や別案件の情報が表示された割合
古い情報の表示率	更新済み・終了済み情報が残った割合
重大問題の見落とし率	重要度の高いチケットが要約されなかった割合
会議準備時間	導入前後で準備にかかった時間
元データ確認率	営業担当者が要約だけでなく情報源を確認した割合
機密情報の露出件数	表示すべきでない項目が含まれた件数
会議後の修正件数	誤った要約により説明や記録を修正した回数

最初の検証では、機密性の低い顧客またはテストデータを使い、限定したセキュリティグループへ展開します。

導入時に失敗しやすいポイント

チケットを追加すれば自動的に有用になると考える

データ量が増えても、顧客との関連付けが不正確なら誤情報が増えます。まず、取引先、連絡先、案件、チケットの関係を確認してください。

営業担当者へ内部メモまで公開してしまう

サービスチケットには、顧客へ伝える内容と社内だけで共有する内容が混在します。テーブル単位で追加する前に、列単位の制御可否を確認する必要があります。

終了済み・更新前の情報を会議で使用する

AIが正しく要約していても、元データが古ければ結論は誤ります。最終更新日時、状態、対応期限を必ず含め、古い情報を識別できるようにします。

AIの要約を正式記録として扱う

会議準備の文章は意思決定を支援する情報であり、チケットやCRMの正式記録そのものではありません。重要な判断を行う前に元データを確認します。

日本のテナントで地域間データ移動を確認していない

必要な同意がないと、設定やライセンスがそろっていても会議インサイトが生成されない可能性があります。技術検証の前に、管理設定と社内承認を確認してください。

プレビュー開始日を本番導入日として計画する

プレビューでは仕様、対応データソース、管理機能が変更される可能性があります。本番展開、利用者教育、監査手順の確定は、検証結果を確認してから行います。

プレビューまでに行う実務チェックリスト

2026年9月のプレビューに備える企業は、次の順番で準備すると手戻りを減らせます。

Roadmap ID 567003を追跡する担当者を決める
Microsoft 365 CopilotとSales agentの利用者を確認する
CRM接続、Sales Chat、会議インサイトの設定を確認する
顧客とサービスチケットの関連付け方法を図にする
会議準備へ含めたいデータ項目を決める
機密項目と除外項目を分類する
CRM、Dataverse、サービス管理システムの権限を見直す
日本の環境に必要な地域間データ移動の承認状況を確認する
限定ユーザーによるパイロット計画を作る
精度、安全性、業務時間の評価指標を決める
問題発生時にデータソースを無効化する手順を用意する
プレビュー開始後に対応システム、保存条件、制御単位を再確認する

Microsoft 365 Copilotの更新にどう対応するべきか

今回の更新は、Sales agentの会議準備を「営業活動の振り返り」から「顧客の現在の状況を横断的に把握する仕組み」へ近づけるものです。未解決のサービスチケットを会議前に確認できれば、提案の順序を変えたり、技術担当者を同席させたりと、顧客対応を具体的に改善できます。

一方で、サービスチケットには機密情報や内部メモが含まれます。利便性を優先してデータソースを広げると、過剰な情報公開、誤った顧客への関連付け、古い情報の利用といった問題が起こります。

すでにSales agentを利用している企業は、まず顧客とチケットの関連付け、アクセス権、公開可能な項目を整理してください。そのうえで、2026年9月以降のプレビューで対応データソースと管理単位を確認し、少人数から検証を始めるのが現実的です。

Sales agentをまだ利用していない企業は、機能のためだけに導入を急ぐ必要はありません。自社の会議準備で、営業とサポートの情報分断がどれだけ問題になっているかを確認し、解決したい業務課題が明確になってから導入を判断してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。