営業担当者が商談を判断するための情報は、CRMだけに収まっているとは限りません。未解決の問い合わせ、契約更新日、請求状況、製品の利用率などが別システムに分散していると、Microsoft 365 CopilotのSales agentが生成する要約だけでは重要なリスクを見落とす可能性があります。
2026年7月9日時点のMicrosoft 365 Roadmapで示された「Microsoft Copilot (Microsoft 365): Add custom insights to record summaries in Sales agent」は、こうしたCRM外の情報をSales agentの取引先・商談要約へ追加できるようにする更新です。
結論として、すでにSales agentを利用し、営業判断に必要なデータがCRM以外にもある組織は、API、認証、アクセス権、データ保持方針の整理を始めるべきです。一方、Sales agentを導入していない組織や、必要な情報がCRM内で完結している組織に、直ちに設定変更が必要な更新ではありません。プレビューは2026年9月、一般提供フェーズの展開開始は2027年3月が予定されていますが、ロードマップの日程は変更される可能性があります。(Microsoft)
Microsoft 365 CopilotのSales agentで何が変わるのか
今回の更新では、Sales agentが生成するCRMレコードの要約に、自社や外部サービスのアプリケーションから取得したカスタムインサイトを追加できるようになります。
Sales agentは従来、Dynamics 365 SalesやSalesforceの取引先、商談、活動などを基に要約を生成します。新機能では、Power PlatformのカスタムコネクタとCopilot Studioのアクションを介して外部APIを呼び出し、その結果を取引先や商談の要約内に表示できます。営業担当者は複数のシステムを開かずに、案件の状況を一か所で確認しやすくなります。(Microsoft Learn)
| 比較項目 | 従来のレコード要約 | カスタムインサイト追加後 |
|---|---|---|
| 主なデータ源 | Dynamics 365 SalesまたはSalesforce | CRMに加えて自社・外部アプリケーション |
| 表示できる情報 | CRM項目、関連レコード、メモ、活動など | 契約、請求、サポート、利用状況などの独自情報 |
| 情報確認の流れ | 必要に応じて別システムを開く | Sales agentの要約から確認し、必要時のみ元システムへ移動 |
| 実装方法 | 管理画面でCRM項目やAI指示を設定 | API、カスタムコネクタ、Copilot Studioアクションを構築 |
| 主な管理課題 | CRMの項目・レコード権限 | CRM権限に加え、外部API、認証、ログ、データ保持の管理 |
既存の「カスタムAI指示」とは役割が異なる
Sales agentにはすでに、取引先要約や商談要約の生成方法を管理者が調整する「Custom AI instructions」があります。これは、CRMのどの項目や関連レコードを含めるか、どのような順序や表現で要約するかを自然言語で指定する機能です。
今回のカスタムインサイトは、要約方法を変えるだけではありません。CRMの外にあるデータをAPI経由で要約へ持ち込むための拡張機能です。
たとえば、CRM内の「商談金額」と「受注予定日」を強調するだけなら既存のカスタムAI指示で対応できます。一方、契約管理システムにしかない「法務審査の未完了」や、サポートシステムにしかない「重大インシデントの未解決」を表示するには、カスタムインサイトの実装が必要です。(Microsoft Learn)
公開時期と対象環境
公式ロードマップID 567002では、次の予定が示されています。
| 項目 | 公式情報の内容 |
|---|---|
| Roadmap ID | 567002 |
| 状態 | 開発中 |
| プレビュー提供予定 | 2026年9月 |
| 一般提供フェーズの展開開始予定 | 2027年3月 |
| クラウド | Worldwide（Standard Multi-Tenant） |
| プラットフォーム | Web |
| リリースフェーズ | Preview、General Availability |
ロードマップ上の「Rollout start」は、すべての対象テナントで同日に利用可能になることを意味しません。対象リリースから段階的に展開される場合があり、日程や仕様も変更される可能性があります。(Microsoft)
また、ロードマップのプラットフォーム欄はWebとなっています。既存のSales agentはMicrosoft 365 Copilot、Outlook、Teamsなどで利用できますが、カスタムインサイトが各クライアントで同じタイミング、同じ表示形式で利用できるとは限りません。2026年9月のプレビュー開始後に、実際の対応クライアントを確認する必要があります。
自社で対応が必要かを判断する基準
今回の更新は、すべてのMicrosoft 365 Copilot利用組織に影響するものではありません。次の条件で対応優先度を判断できます。
| 自社の状況 | 対応優先度 | 推奨する対応 |
|---|---|---|
| Sales agentを利用中で、重要情報がCRM外にある | 高い | プレビュー前にデータ源、API、認証、管理責任者を整理する |
| Sales agentを利用中だが、営業情報はCRM内で完結している | 中程度 | ロードマップを監視し、具体的な追加価値があるか検討する |
| Sales agentを試験導入中 | 中程度 | 既存の評価項目に「外部データ統合の必要性」を加える |
| Microsoft 365 CopilotはあるがSales agentを利用していない | 低い | Sales agent自体の導入効果を先に評価する |
| Dynamics 365 SalesやSalesforceを使用していない | 低い | 現時点では直接の導入対象になりにくい |
| Dynamics 365 Customer Engagementオンプレミスを利用している | 対象外 | クラウド移行や別の連携方法を検討する |
| GCC、USG、DoD環境を利用している | 対象外 | 最新の提供地域情報を継続確認する |
Sales agentが現在対応しているCRMはDynamics 365 SalesとSalesforceです。Microsoft 365 Copilotライセンスが必要で、Dynamics 365 Customer Engagementオンプレミスおよび一部の政府向けクラウドは現在のサポート対象外です。(Microsoft Learn)
カスタムインサイトを利用するための条件
Microsoft 365 CopilotとSales agentの利用環境
利用者にはMicrosoft 365 Copilotライセンスが必要です。さらに、Microsoft 365管理センターからSales agentを対象ユーザーまたはグループへ展開し、CRMとの接続やSales Chatの設定を完了しておく必要があります。(Microsoft Learn)
現在のSales agent設定ドキュメントでは、主に次の準備が求められています。
- Microsoft 365 Copilotライセンスの割り当て
- Sales agentの展開
- Dynamics 365 SalesまたはSalesforceへの接続
- Sales Chatの有効化
- CRM側の管理者権限と利用者権限の設定
- 取引先・商談要約の構成
- Sales agentが参照できるCRMエンティティの設定
Sales agentを展開しただけでは、取引先や商談の要約が自動的に最適化されるとは限りません。CRM管理者が要約設定や参照対象を構成していない場合、利用者に必要な要約が表示されないことがあります。(Microsoft Learn)
外部アプリケーションとAPI
カスタムインサイトを追加するには、Sales agentから呼び出せるAPIが必要です。既存システムにAPIがない場合は、データベースを直接公開するのではなく、必要な情報だけを返す中継APIを用意するのが安全です。
現在公開されているSales agent拡張ドキュメントでは、次の構成が示されています。
- 自社またはパートナーアプリケーションのAPIを用意する
- Microsoft Power Platformでカスタムコネクタを作成する
- OAuth 2.0とMicrosoft Entra IDで認証する
- Copilot Studioでコネクタを使用するアクションを作成・公開する
- Sales管理者がアクションを有効化する
現行のプレビュー向け手順では、Dynamics 365アプリが有効なPower Platform環境を使用すること、認証方式としてOAuth 2.0とMicrosoft Entra IDを使用することが案内されています。既定環境など、Dynamics 365アプリが有効でない環境は、このカスタムコネクタ用途ではサポートされていません。これらはプレビュー文書に基づく条件であり、正式提供までに変更される可能性があります。(Microsoft Learn)
データ境界はMicrosoft 365だけでは完結しない
カスタムインサイトを導入すると、Sales agent、CRM、Dataverse、Power Platform、外部APIという複数のデータ境界をまたぐ構成になります。
営業担当者
↓
Microsoft 365 Copilot / Sales agent
├─ CRMから取引先・商談情報を取得
├─ Copilot Studioのアクションを選択
↓
Power Platformカスタムコネクタ
↓
自社または外部サービスのAPI
↓
構造化されたカスタムインサイトを返却
↓
Sales agentのレコード要約に表示Sales agentはPower Platform上に構築されており、接続先CRMだけでなくDataverseにもSales agent関連データを保存します。Dynamics 365 Salesを利用する場合はそのDataverse環境が使われ、SalesforceなどDynamics 365以外のCRMでは、Sales agent用のmsdyn_viva環境がテナントに用意されます。(Microsoft Learn)
| データの場所 | 主なデータ | 管理時の確認事項 |
|---|---|---|
| CRM | 取引先、商談、連絡先、活動など | CRMのロール、レコード権限、項目権限 |
| Dataverse | Sales agentが利用する各種データやインサイト | 環境管理、容量、削除、保持期間 |
| カスタムコネクタ | API要求と応答 | 接続先、認証方式、利用者範囲 |
| 外部API | 契約、請求、サポート、利用状況など | API権限、ログ、保存先、委託先規約 |
| Sales agentの画面 | APIから返された要約情報 | 表示対象ユーザー、機密情報の混入、元データへのリンク |
CRMレコードIDも保護対象として扱う
レコード要約を拡張するAPIでは、recordTypeとrecordIdが必須パラメーターです。必要に応じて、CRMの種類を表すcrmTypeや、CRM組織を識別するcrmOrgUrlも渡されます。(GitHub)
これらは単なる技術的な識別子に見えますが、外部API側で顧客情報と結び付けられるため、保護対象として扱うべきです。APIログへ無制限に記録せず、保存期間、閲覧権限、マスキングの要否を決めておく必要があります。
カスタムインサイトの保持期間は個別確認が必要
Microsoftのデータ処理ドキュメントでは、Sales agentのメール関連インサイトは30日、会議関連インサイトは90日で削除されると説明されています。一方、カスタムAPIから返されたレコード要約用インサイトについては、現時点の公開文書で同じ保持期間が適用されると明記されていません。(Microsoft Learn)
したがって、「カスタムインサイトも自動的に30日または90日で消える」とは判断できません。プレビュー時には次の点を確認する必要があります。
- API応答がDataverseに保存されるのか、その場で表示されるだけなのか
- 保存される場合のテーブルと保持期間
- Microsoft側の診断ログに含まれる項目
- Power Platformの接続履歴に残る情報
- 外部APIやAPI Management側のログ保存期間
- 利用停止時や契約終了時の削除方法
管理者が設定・確認すべき制御
Sales agentを全社一斉に展開しない
Microsoft 365管理センターでは、Sales agentを展開するユーザーやグループを選択できます。カスタムインサイトを試す段階では、営業企画、情報システム、セキュリティ担当、少数の営業担当者からなる検証グループに限定するのが安全です。(Microsoft Learn)
Sales Chatのアクセスをセキュリティグループで制限する
Sales agentのSales Chatは既定で全ユーザー向けに有効ですが、管理者は特定のセキュリティグループだけに許可したり、機能自体を無効にしたりできます。
無効化後もSales agentのアイコンが残る場合がありますが、その状態ではSalesデータを含む回答は返されません。検証対象者を限定する場合は、アプリの展開対象とSales Chatのアクセス対象を一致させておくと、利用者の混乱を防げます。(Microsoft Learn)
CRMエンティティを安易に追加しない
Sales agentの管理設定では、標準またはカスタムのCRMエンティティを追加できます。ただし、公式ドキュメントでは、エンティティを追加するとSales agentがそのエンティティのすべての列へアクセスできると説明されています。(Microsoft Learn)
そのため、「将来使うかもしれない」という理由で顧客、契約、請求、従業員情報を含むエンティティをまとめて追加するのは避けるべきです。まず次の観点で棚卸しします。
- 営業担当者が本来閲覧できるデータか
- 要約に必要な項目だけで構成された専用エンティティを作れないか
- 個人情報や機微情報が列に含まれていないか
- テストユーザーと一般営業担当者で見える結果が異ならないか
- 退職者や異動者の権限が残っていないか
コネクタの有効化を独立したセキュリティ審査にする
特に注意したいのが、Sales agent向けコネクタアクションの有効化です。Microsoftは、同じコネクタアクションをMicrosoft 365から直接使用できないよう制限していても、Sales agent向けに有効化すると、Sales agentを通じて外部ソースとのデータ送受信が可能になる場合があると説明しています。(Microsoft Learn)
そのため、「既存のMicrosoft 365側設定でブロック済みだから安全」と判断してはいけません。Sales agent向けアクションごとに、次の項目を確認します。
- 送信されるパラメーター
- APIが返す情報
- 接続先ドメイン
- OAuthのアクセス許可
- 利用者本人の権限で動くか、共通サービスアカウントで動くか
- 外部サービスの利用規約とプライバシーポリシー
- API障害時の挙動
- ログと監査証跡
Sales agentとCRMの接続によるデータ共有は、管理者と利用者がMicrosoftの職場アカウントをCRMアカウントへ接続することに同意するまで有効になりません。外部アプリ連携についても、同様に利用者へ目的と対象データを明示する運用が必要です。(Microsoft Learn)
業務での具体的な使いどころ
以下はカスタムインサイトの実装例です。特定の製品やコネクタが標準搭載されることを示すものではなく、自社APIを使って実現できる用途を整理したものです。
| 外部データ源 | Sales agentへ表示するインサイト例 | 営業担当者が取る行動 |
|---|---|---|
| サポート管理 | 優先度の高い未解決問い合わせ、SLA超過 | 提案前にサポート責任者へ状況を確認する |
| 契約管理 | 更新日、法務審査、未署名文書 | 更新交渉や署名依頼を前倒しする |
| 請求・会計 | 支払期限超過、与信保留、請求差異 | 追加提案前に経理担当へ確認する |
| SaaS利用状況 | アクティブ率低下、利用部門減少、容量逼迫 | 解約リスク対応や追加ライセンス提案を行う |
| カスタマーサクセス | ヘルススコア、オンボーディング進捗 | 商談前に利用定着の課題を整理する |
| 見積・承認 | 値引き承認待ち、見積有効期限 | 承認者へ催促し、失注リスクを下げる |
| パートナー管理 | 代理店の活動状況、共同提案の進捗 | 直接営業と代理店の重複対応を防ぐ |
重要なのは、外部システムの全データを要約へ詰め込むことではありません。営業担当者の次の判断を変える情報だけを返します。
たとえば、「サポートチケットが12件あります」だけでは行動につながりません。次のように、重要度と具体的な次の行動が分かる表現にします。
優先度1の未解決インシデントが1件あります。最終更新から18時間経過しているため、次回提案前にサポート責任者へ状況を確認してください。
開発時に押さえるAPI仕様
現行のSales agent拡張ドキュメントでは、レコード要約用APIの操作種別としてGETが指定されています。
主な入力パラメーターは次のとおりです。
| パラメーター | 必須 | 用途 |
| ————— | -: | ———————————— |
| recordType | 必須 | accountやopportunityなど、CRMレコードの種類 |
| recordId | 必須 | 対象CRMレコードの一意なID |
| startDateTime | 任意 | インサイト検索期間の開始日時 |
| endDateTime | 任意 | インサイト検索期間の終了日時 |
| top | 任意 | 取得件数 |
| skip | 任意 | ページング時に読み飛ばす件数 |
| crmType | 任意 | Dynamics 365またはSalesforce |
| crmOrgUrl | 任意 | CRM組織を識別するホスト名 |
APIの応答にはvalue配列が必要です。各インサイトではtitle、description、UTC形式のdateTimeが必須で、urlとadditionalPropertiesは任意です。続きのデータがある場合はhasMoreResultsを返せます。(GitHub)
応答JSONの実装例
次は、契約管理システムから更新リスクを返す架空の例です。
{
"value": [
{
"title": "契約更新の対応が必要",
"description": "契約更新まで28日ですが、法務確認が完了していません。",
"dateTime": "2026-07-18T01:30:00Z",
"url": "https://contracts.example.com/contracts/ABC-123",
"additionalProperties": {
"契約状態": "法務確認中",
"担当部門": "法人営業部",
"更新期限": "2026-08-15"
}
}
],
"hasMoreResults": false
}urlを返しておけば、営業担当者は要約から元システムの該当画面へ移動できます。additionalPropertiesは詳細カードに補足情報を表示する用途で使用されます。また、Accept-Languageヘッダーに応じて、タイトル、説明、追加項目を利用者の言語で返す設計が求められます。(GitHub)
APIは「正しい情報を短く返す」ことを優先する
レコード要約はデータ閲覧画面ではありません。API応答は、次の基準で絞り込みます。
- 営業判断に影響しない情報は返さない
- 重要度の高いインサイトを先に返す
- 1件の説明を短くする
- 更新日時を明確にする
- 元システムへのディープリンクを付ける
- 古いデータには「最終更新日」を表示する
- データがない場合は空配列を正常応答として返す
- タイムアウト時にCRM要約全体を失敗させない
- 利用者が閲覧権限を持たない情報は返さない
また、メール要約向けAPIとレコード要約向けAPIは、入出力が似ていても別々のコネクタアクションとして登録する必要があります。(GitHub)
導入までの実務手順
営業判断に必要な外部情報を洗い出す
最初にシステム一覧を作るのではなく、「どの判断を改善したいか」から考えます。
たとえば、商談前の準備時間を減らしたい場合は、営業担当者が現在確認している画面や担当部署への問い合わせを調べます。そのうえで、次のような優先順位を付けます。
- 見落とすと失注や顧客不満につながる情報
- 営業担当者が頻繁に別システムで確認している情報
- 更新頻度が高く、CRMへ手作業で転記しにくい情報
- 元システムでアクセス権を適切に管理できている情報
最小限のユースケースを一つ選ぶ
初回から契約、請求、サポート、製品利用状況をすべて統合すると、権限設計とテストが複雑になります。
最初の検証では、たとえば「商談に関連する優先度1の未解決問い合わせを最大3件表示する」のように、データ源と出力を限定します。これならAPIの正確性、表示の有用性、権限差、応答速度を評価しやすくなります。
認証と権限を設計する
APIの認証にはMicrosoft Entra IDとOAuth 2.0を使用し、可能な限り利用者本人の権限を引き継ぐ構成にします。
共通サービスアカウントでAPIを実行すると、本来閲覧できない顧客情報がSales agent経由で表示されるおそれがあります。サービスアカウントが必要な場合は、API側で利用者ID、部署、担当顧客などを再確認し、返却範囲を制限します。
カスタムコネクタとアクションを作成する
APIをOpenAPI定義として整理し、Power Platformでカスタムコネクタを作成します。その後、Copilot Studioでアクションを作成し、Sales agentが適切な場面で選択できるよう、アクション名と説明を具体的に記述します。
「顧客情報を取得する」といった曖昧な説明ではなく、「指定された取引先または商談に関連する未解決の重大サポートインシデントを取得する」のように、対象と目的を明示します。
管理者が限定ユーザーへ有効化する
Copilot Studioで公開したアクションは、Sales管理者が有効化する必要があります。Microsoftのドキュメントでは、有効化したアクションがSales agentへ取り込まれるまで最大7日かかる場合があるとされています。反映されない場合は、Sales agentからサインアウトして再度サインインすることで更新を促せます。(Microsoft Learn)
反映待ちを実装不具合と誤認しないよう、検証日程には余裕を持たせてください。
本番導入前に権限差をテストする
少なくとも次の利用者パターンで確認します。
- 担当営業
- 営業マネージャー
- 別部門の営業担当者
- 特定顧客へのアクセス権がない利用者
- 退職予定または異動後の利用者
- APIの追加権限を持たない利用者
- SalesforceとDynamics 365で異なるロールを持つ利用者
表示内容だけでなく、エラー時にレコードIDや内部URLが画面へ露出しないかも確認します。
導入時に失敗しやすいポイント
要約を外部システムの一覧画面にしてしまう
要約へ10件、20件と情報を並べると、重要なインサイトが埋もれます。件数上限を決め、緊急度、金額、期限などで優先順位を付けてください。
元データへのリンクを返さない
要約だけでは、営業担当者が詳細や根拠を確認できません。可能な限りurlを返し、権限確認後に元レコードを直接開けるようにします。
CRMの権限だけを見て安全と判断する
カスタムインサイトは、CRMとは別のAPI権限で取得されます。CRMで見えない情報が、共通サービスアカウント経由で表示されないかを確認する必要があります。
プレビューを本番前提で導入する
関連するSales agent拡張ドキュメントはプレビューまたはプレリリースとして公開されており、仕様が変わる可能性があります。API契約を自社コードへ固定的に埋め込まず、パラメーターや応答項目の変更に対応できる中間層を設けると安全です。(Microsoft Learn)
外部APIの障害を考慮しない
外部APIが遅い、停止している、対象データがないといった状況は必ず発生します。空の結果と障害を区別し、Sales agentのCRM要約自体は利用できるように設計します。
データの鮮度を表示しない
「法務確認中」と表示されても、情報が3か月前のものでは判断を誤ります。dateTimeにはインサイトが発生または更新された時刻を設定し、必要に応じて説明にも最終更新日を含めます。
対応要否の最終チェック
次の質問に上から順番に答えると、自社の対応方針を決めやすくなります。
| 確認事項 | 「はい」の場合 | 「いいえ」の場合 |
|---|---|---|
| Microsoft 365 Copilotライセンスを営業担当者へ割り当てているか | 次へ進む | ライセンスと導入目的を先に検討 |
| Sales agentを利用または試験導入しているか | 次へ進む | Sales agent自体の評価を優先 |
| Dynamics 365 SalesまたはSalesforceを使用しているか | 次へ進む | 現時点では経過観察 |
| 営業判断に必要な情報がCRM外にあるか | 連携候補を整理 | 直ちに実装する必要性は低い |
| 対象システムにAPIがあるか | 認証と応答仕様を確認 | 中継APIの開発可否を検討 |
| 利用者単位でアクセス制御できるか | 限定検証を計画 | 権限設計を先に修正 |
| ログと保持期間を説明できるか | セキュリティ審査へ進む | データ管理方針を確定 |
| 業務効果を測る方法があるか | プレビュー検証を実施 | 評価指標を決めてから着手 |
Microsoft 365 Copilotの「Add custom insights to record summaries in Sales agent」は、単に要約文章を詳しくする機能ではありません。CRM外の業務システムをSales agentへ接続し、営業担当者の判断に必要な情報を一つの画面へ集約する拡張機能です。
対応が必要な組織は、まず「営業担当者が商談前に確認しているCRM以外の情報」を3つ程度に絞ってください。その後、対象データの権限、API、認証、ログ、保持期間を確認し、一つのユースケースだけで限定的な検証を行います。2026年9月のプレビューでは、クライアント対応状況、カスタムインサイトの保存方法、管理画面の実装を確認したうえで、2027年3月以降の本格展開を判断するのが現実的です。
コメント