Microsoft ecosystemで営業データ活用をMicrosoft 365 Copilotに広げたい管理者にとって、2026年4月の「Set up Sales agent in Microsoft 365 Copilot (preview)」更新で最も注目すべき点は、Salesforce向けのグロッサリー設定が実務レベルで案内されるようになったことです。これにより、Salesforceを使う組織でも、自社独自の営業用語や略語をSales agentに理解させやすくなります。
ただし、Sales agent in Microsoft 365 Copilotはまだプレビュー機能です。Microsoftのドキュメントでも、プレビュー機能は本番利用を目的としたものではなく、機能制限や変更の可能性があると説明されています。導入する場合は、全社展開ではなく、CRM権限・対象ユーザー・検索対象データ・用語定義を整理したうえで、限定グループから検証するのが現実的です。(Microsoft Learn)
Microsoft ecosystemの最新動向: Set up Sales agent in Microsoft 365 Copilot (preview)で何が変わったか
2026年4月更新のポイントは、単なる画面手順の追加ではありません。Microsoft 365 Copilot、Dynamics 365 Sales、Salesforce、Power Platform、Copilot Studioをまたぐ「営業AIエージェントの管理方法」が、より具体的に整理された点にあります。
特に2026年4月22日のGitHub履歴では、Salesforce向けのグロッサリー設定ページが追加され、従来「Salesforce CRMではグロッサリー用語は現在サポートされていない」とされていた記述が、Salesforce向け設定記事への案内に置き換えられています。なお、Microsoft Learn上の該当ページは確認時点で2026年4月28日付にも更新されています。(GitHub)
| 更新ポイント | 影響を受ける読者 | 実務での対応 |
|---|---|---|
| Salesforce向けグロッサリー設定の案内が追加 | Salesforce管理者、Microsoft 365管理者 | 自社用語、略語、カスタム項目名をDataverse上のグロッサリーとして整備する |
| CRMエンティティ設定の重要性が明確化 | Workplace IT、CRM管理者 | Sales agentが参照できるテーブル・オブジェクトを必要最小限にする |
| 要約生成のカスタムAI指示が整理 | 営業企画、RevOps、IT部門 | アカウント要約・商談要約に含める項目や見せ方を業務に合わせて調整する |
| アクセス制御と権限設計の重要性が増加 | Microsoft 365 admins | セキュリティグループ、CRM権限、Microsoft 365 Copilot側のエージェント管理をセットで確認する |
Sales agent in Microsoft 365 Copilotとは
Sales agentは、Microsoft 365 Copilot内で使える会話型エージェントです。営業担当者が自然言語で質問し、CRMや顧客対応データを検索・要約・活用できるようにすることを目的としています。Microsoft公式ドキュメントでは、現時点でDynamics 365 SalesとSalesforceをサポートすると説明されています。利用にはMicrosoft 365 Copilotライセンスが必要で、Sales agentのインストールも必要です。(Microsoft Learn)
たとえば、営業担当者は次のような質問を想定できます。
| 利用シーン | プロンプト例 |
|---|---|
| 商談前の準備 | 「この取引先の直近の商談状況と注意点を要約して」 |
| パイプライン確認 | 「今週フォローすべきオープン商談を優先度順に教えて」 |
| 顧客理解 | 「このアカウントの主要な意思決定者と過去のやり取りを整理して」 |
| 営業活動の振り返り | 「過去4週間のミーティング内容から次のアクションを抽出して」 |
ポイントは、Sales agentが「AIチャット単体」ではなく、CRM接続と権限設計に依存することです。CRMデータに接続していない状態では、営業データを前提にした価値は出にくくなります。
管理者が最初に確認すべき前提条件
Sales agentを設定する前に、Microsoft 365管理者、CRM管理者、営業部門の責任者が同じ認識を持っておく必要があります。特に、ライセンスだけで利用可否を判断しないことが重要です。
| 確認項目 | 見るべきポイント |
|---|---|
| Microsoft 365 Copilotライセンス | 対象ユーザーにMicrosoft 365 Copilotライセンスがあるか |
| Sales agentのインストール | OutlookとTeamsの両方にSales agentが導入されているか |
| Sales Chatの有効化 | Sales agentのAccess settingsでSales Chatがオンになっているか |
| CRM接続 | Dynamics 365 SalesまたはSalesforceに正しく接続されているか |
| CRM権限 | 管理者とユーザーに必要なCRM権限・セキュリティロールがあるか |
| エージェント管理 | Microsoft 365管理センターでエージェントが許可・展開されているか |
Microsoft公式ドキュメントでは、Sales agentの前提条件として、OutlookとTeamsへのインストール、環境レベル設定へのアクセス、Sales Chatの有効化、CRM接続、CRM側の適切な権限付与が挙げられています。(Microsoft Learn)
また、Microsoft 365 CopilotのエージェントはMicrosoft 365管理センターから管理でき、組織内で有効化・無効化・割り当て・ブロック・削除などの操作が可能です。全社でエージェント利用を制御している場合は、Sales agent側の設定だけでなく、Microsoft 365管理センター側のエージェント設定も確認してください。(Microsoft Learn)
CRMエンティティ設定で「AIが見てよいデータ」を決める
Sales agentの設定で最初に重要なのが、CRMエンティティの構成です。Dynamics 365ではテーブル、Salesforceではオブジェクトに相当します。
Sales agentは、管理者が設定したCRMエンティティをもとに営業データへアクセスします。標準エンティティだけでなく、カスタムエンティティも追加できます。一方で、不要なエンティティは削除できます。(Microsoft Learn)
ここで注意したいのは、追加したエンティティのすべての列にSales agentがアクセスできると説明されている点です。営業現場から見ると「取引先情報を参照できるようにする」だけに見えても、実際にはそのエンティティ内の項目全体が対象になります。個人情報、評価情報、機密性の高い社内メモ、未公開価格条件などが含まれる場合は、事前に見直しが必要です。(Microsoft Learn)
CRMエンティティ設定の判断基準
| 判断軸 | 推奨される考え方 |
|---|---|
| 使う頻度 | 営業担当者が日常的に質問するデータから追加する |
| 機密性 | 機密項目が多いエンティティは慎重に扱う |
| データ品質 | 古いデータや未整備の項目が多い場合は先にCRMを整備する |
| 業務価値 | 商談判断、顧客理解、次アクション決定に直結するものを優先する |
| 管理負荷 | カスタムエンティティを増やしすぎると検証範囲が広がる |
最初から多くのエンティティを追加するより、Account、Contact、Opportunityなど営業上の中核データから始め、利用ログや現場フィードバックを見ながら広げる方が安全です。
初回設定で見落としやすい「Sales Chat settingsページの初期化」
今回の設定手順で見落とすと致命的になりやすいのが、Sales Chat settingsページの初回読み込みです。
Microsoftのドキュメントでは、Sales agentを初期化しCRM接続を設定するために、Sales agent administrator settingsからSales Chat settingsページを少なくとも一度開く必要があると説明されています。初回読み込みによって初期化プロセスがトリガーされ、Sales agentで使うサポート対象エンティティが読み込まれます。この手順を省略すると、自動的には初期化されません。(Microsoft Learn)
実務では、次のようなトラブルにつながります。
| 症状 | 考えられる原因 | 対応 |
|---|---|---|
| Sales agentがCRMデータを参照しない | 初期化が完了していない | Sales Chat settingsページを管理者で開く |
| 設定したエンティティが反映されない | 読み込みや反映の遅延 | 設定後に時間を置き、テストユーザーで再確認する |
| ユーザーにはSalesが見えるが営業データが返らない | アクセス設定またはCRM権限の問題 | Access settings、CRMロール、Microsoft 365側のエージェント設定を確認する |
同義語とグロッサリーで「現場の言葉」をAIに理解させる
Sales agentは自然言語でCRMデータにアクセスできます。しかし、営業担当者が使う言葉とCRMの項目名は一致しないことがよくあります。
たとえば、CRM上の項目名が「Account」でも、現場では「会社」「顧客」「取引先」「クライアント」と呼ばれることがあります。Sales agentがこうした言い換えを正しく理解できないと、回答精度が下がります。
Microsoftのドキュメントでは、このギャップを補うために、同義語とグロッサリー用語を追加できると説明されています。Dynamics 365では、Copilot Studioで追加した同義語がSales agentとCopilot in Dynamics 365 Salesの両方に反映されます。一方、Salesforce CRMでは現時点で同義語はサポートされていないため、グロッサリー設定の活用が重要になります。(Microsoft Learn)
同義語とグロッサリーの使い分け
| 項目 | 主な用途 | 例 |
|---|---|---|
| 同義語 | CRM項目の別名をAIに教える | Account = 会社、顧客、Client |
| グロッサリー | 組織固有の言葉や業務ルールを説明する | 「重点商談」は金額1,000万円以上かつ今四半期クローズ予定 |
| カスタムAI指示 | 要約の構成や出力方針を制御する | リスク、次アクション、意思決定者を必ず含める |
同義語は「言葉の置き換え」、グロッサリーは「意味の説明」、カスタムAI指示は「出力の設計」と考えると分かりやすくなります。
Salesforce利用企業に大きい、2026年4月更新の意味
SalesforceをCRMとして使う企業にとって、2026年4月更新の実務的な意味は大きいです。Microsoft LearnのSalesforce向けグロッサリー記事では、グロッサリー用語はユーザーがプロンプトで使う語句をDataverseテーブル上の特定の意味にマッピングするものと説明されています。また、各用語には説明とSkillが関連付けられ、特定のSalesforce組織または環境にスコープされます。(Microsoft Learn)
Salesforce向けの設定では、Power AppsでSales agentがインストールされているmsdyn_viva環境にアクセスし、CopilotGlossaryTermsテーブルを使うモデル駆動型アプリを作成・公開して、用語、説明、Skillを登録します。設定には対象Dataverse環境へのアクセスと、Copilot glossary tableへの表示・作成権限が必要です。(Microsoft Learn)
Salesforce向けグロッサリー設定で優先したい用語
| 優先度 | 用語の種類 | 具体例 |
|---|---|---|
| 高 | 営業部門で頻出する略語 | VP、ARR、SQL、MQL |
| 高 | カスタム項目に紐づく言葉 | 商談ランク、更新確度、契約種別 |
| 高 | 独自の業務ルール | 重点顧客、要フォロー商談、失注リスクあり |
| 中 | 組織内だけで使う呼称 | エンタープライズ案件、戦略顧客、赤信号案件 |
| 低 | 一般的すぎる語句 | 顧客、売上、商談 |
重要なのは、用語を多く登録することではありません。営業担当者が実際に入力する言葉と、CRM上の項目・レコード条件を結びつけることです。
たとえば「overdue task」を「TaskテーブルでState codeがopen、Scheduled end dateが今日より前のレコード」と説明するように、単なる翻訳ではなく、条件や参照先を具体的に書くと精度改善につながります。Microsoftの例でも、略語、所有者の定義、カスタム項目、複雑な条件付きフィルターがグロッサリー例として示されています。(Microsoft Learn)
アカウント要約・商談要約はカスタムAI指示で業務に合わせる
Sales agentでは、アカウントや商談の要約を取得できます。Microsoftのドキュメントでは、AccountおよびOpportunityテーブルの一般的なフィールドやリレーション、自然言語の指示を使って、意味のある形式で要約を生成すると説明されています。(Microsoft Learn)
管理者は、Sales agent admin settingsのCustom AI instructionsから、Account summaryやOpportunity summaryの既定プロンプトを編集できます。説明欄では、情報の整理方法、表示方法、含めたいフィールドや関連レコードを自然言語で指定できます。(Microsoft Learn)
カスタムAI指示の実用例
| 目的 | 指示の例 |
|---|---|
| 商談リスクを見たい | 「失注リスク、競合、顧客の懸念点、次回アクションを優先して要約する」 |
| マネージャー確認用にしたい | 「商談金額、クローズ予定日、ステージ変更、担当者の次アクションを箇条書きで示す」 |
| 引き継ぎに使いたい | 「過去のやり取り、主要担当者、未完了タスク、意思決定者を含める」 |
| 日本語営業チームで使う | 「営業担当者が次の打ち手を判断できるよう、簡潔な日本語で出力する」 |
注意点として、カスタムAI指示は保存前にテストできないと説明されています。Microsoftは、運用環境に適用する前にテストCRM環境へ接続して検証することを推奨しています。また、メモややり取りの要約対象期間は既定で過去4週間、最大12週間まで設定できます。(Microsoft Learn)
この仕様を踏まえると、いきなり本番環境で「全営業部門向けの要約ルール」を変更するのは避けるべきです。まずは少数の営業マネージャーに検証してもらい、要約に含める項目と出力形式を調整してから展開しましょう。
Meeting insightsはSales agent専用設定ではなくAccess settingsで管理する
過去の顧客ミーティングに関するインサイトもSales agentから利用できます。ただし、Microsoftのドキュメントでは、Sales agent専用の個別設定はなく、Sales agent access settingsを通じてMeeting insightsへのアクセスを管理すると説明されています。(Microsoft Learn)
Meeting insightsを使う場合は、録画・文字起こし・AI生成メモ・アクションアイテムの扱いが社内ポリシーに合っているかを確認してください。営業データだけでなく、会話内容そのものがAI要約の対象になるため、情報管理の観点ではCRMエンティティ設定以上に慎重な確認が必要です。
Dynamics 365利用企業はモデル駆動型アプリ内のCopilot利用も確認する
Dynamics 365をCRMとして使っている場合、Microsoft 365 Copilotをモデル駆動型アプリで有効にすると、ユーザーはDynamics 365アプリ内からSales agentへアクセスできるようになります。この手順はDynamics 365を使う場合のみ該当します。(Microsoft Learn)
実務上は、TeamsやOutlookだけでなく、営業担当者が日常的に使うDynamics 365画面からアクセスできるかどうかが定着率に影響します。導入効果を出したい場合は、単に機能をオンにするのではなく、営業プロセス上どの画面で使うのが自然かまで設計しましょう。
アクセス制御は「Copilot」「Sales agent」「CRM」の3層で考える
Sales agentの導入で失敗しやすいのは、1つの管理画面だけを見て「設定済み」と判断してしまうことです。実際には、少なくとも次の3層を確認する必要があります。
| レイヤー | 管理対象 | 確認ポイント |
|---|---|---|
| Microsoft 365 Copilot | エージェントの表示・利用可否 | Microsoft 365管理センターでSales agentが許可されているか |
| Sales agent | Sales Chat、Meeting insightsなど | Access settingsで対象機能がオンか、セキュリティグループ制限が適切か |
| CRM | データ参照・作成・更新権限 | Dynamics 365またはSalesforce側のロール・権限が正しいか |
Sales agentのAccess settingsでは、Sales agent in Microsoft 365 Copilotは既定で全ユーザーに対してオンと説明されていますが、管理者は特定のセキュリティグループに制限したり、完全にオフにしたりできます。また、Sales agentをオフにしても、インストール済みユーザーにはMicrosoft 365 Copilot内でSalesエージェントが表示される場合があり、その場合でも営業データを含む回答は得られないと説明されています。(Microsoft Learn)
つまり、「ユーザーの画面にSalesが見えている」ことと「CRMデータを使った回答が返る」ことは別です。ヘルプデスクへの問い合わせを減らすには、表示状態、アクセス設定、CRM権限の違いを管理者向け手順書に明記しておきましょう。
権限変更は即時反映されない場合がある
Sales agentは、組織の既存のCRMアクセス制御とユーザー権限を適用します。管理者にはCRMをカスタマイズするための権限が必要で、ユーザーにはSales agentからCRMレコードを表示・更新・作成するための権限が必要です。(Microsoft Learn)
CRM側でユーザー権限やセキュリティロールを変更した場合、OutlookのSales agentではサインアウトして再サインインするよう促す必要があります。また、TeamsのSales agentでは権限変更の反映に最大15分かかる場合があると説明されています。(Microsoft Learn)
導入検証では、次のような確認を必ず入れてください。
| テスト観点 | 確認内容 |
|---|---|
| 管理者権限 | 管理者がエンティティ、グロッサリー、要約指示を設定できるか |
| 一般ユーザー権限 | 営業担当者が自分に許可されたCRMデータだけを参照できるか |
| 権限変更後の挙動 | ロール変更後、OutlookとTeamsで反映タイミングが想定どおりか |
| 制限ユーザー | アクセス制限対象のユーザーに営業データが返らないか |
| 監査観点 | 誰がどの環境で設定変更したか追跡できるか |
導入すべき組織、まだ待つべき組織
Sales agent in Microsoft 365 Copilotは魅力的ですが、すべての組織がすぐ導入すべきとは限りません。プレビュー機能であることを踏まえ、導入判断は慎重に行うべきです。
| 状況 | 判断 |
|---|---|
| Microsoft 365 Copilotを既に導入し、営業部門で利用が進んでいる | 限定ユーザーで検証する価値が高い |
| Dynamics 365 SalesまたはSalesforceのデータ整備が進んでいる | CRMエンティティとグロッサリーを設計すれば効果を出しやすい |
| カスタム項目や独自営業用語が多い | グロッサリー整備を前提に検証すべき |
| CRM権限が属人的で整理されていない | 先にCRM権限とデータ分類を見直すべき |
| 本番営業プロセスをAI回答に強く依存させたい | プレビュー段階では慎重に扱うべき |
| グローバル拠点で用語やCRM運用が大きく異なる | 国・地域・事業部ごとの用語設計が必要 |
特にグローバル企業では、日本語、英語、現地語で同じ営業概念を異なる言葉で表すことがあります。「案件」「商談」「Opportunity」「Deal」が混在する環境では、グロッサリーや同義語を部門横断で設計しないと、AI回答のばらつきが大きくなります。
よくある失敗と回避策
Microsoft 365 Copilotライセンスだけで使えると思ってしまう
Sales agentを表示・利用するには、Microsoft 365 Copilotライセンスだけでなく、Sales agentのインストールや管理者側のアクセス設定が必要です。組織でMicrosoft 365 Copilotのすべてのエージェントを無効化している場合、ライセンスがあってもSales agentは一覧に表示されません。(Microsoft Learn)
CRMエンティティを広げすぎる
「便利そうだから」と多くのエンティティを追加すると、AIが参照する範囲が広がり、検証すべきデータも増えます。追加したエンティティの全列にアクセスできる点を踏まえ、最初は必要最小限にしましょう。
Salesforceで同義語設定を探してしまう
Dynamics 365ではCopilot Studioで同義語を設定できますが、Salesforce CRMでは現時点で同義語はサポートされていないと説明されています。Salesforce環境では、まずグロッサリー設定を活用する方が現実的です。(Microsoft Learn)
グロッサリーを単なる用語集にしてしまう
グロッサリーには「この言葉は何を意味し、どのデータと関係するのか」を書く必要があります。「重点顧客 = 重要な顧客」のような説明では不十分です。
たとえば、次のように定義します。
| 悪い例 | 良い例 |
|---|---|
| 重点顧客は重要な顧客 | 重点顧客はAccountテーブルでCustomer TierがStrategic、または年間売上見込みが1億円以上の顧客 |
| 停滞商談は止まっている商談 | 停滞商談はOpportunityのStageが変更されておらず、Last Activity Dateが14日以上前の商談 |
| 更新リスクは契約更新のリスク | 更新リスクはRenewal Dateが60日以内で、直近30日間にMeetingまたはEmail活動がないアカウント |
本番環境でカスタムAI指示をいきなり変更する
カスタムAI指示は保存前にテストできません。まずテストCRM環境で検証し、営業担当者とマネージャーの両方からフィードバックを集めてから本番に反映しましょう。(Microsoft Learn)
管理者向けの実装チェックリスト
導入時は、次の順序で進めると手戻りを減らせます。
| ステップ | 作業内容 | 完了条件 |
|---|---|---|
| 1 | 対象CRMを確認する | Dynamics 365 SalesまたはSalesforceのどちらで検証するか決まっている |
| 2 | 対象ユーザーを絞る | 営業部門全体ではなく、検証グループが決まっている |
| 3 | Microsoft 365 CopilotとSales agentを確認する | ライセンス、インストール、エージェント管理が整っている |
| 4 | Sales Chatを有効化する | Access settingsで対象ユーザーに許可されている |
| 5 | CRMエンティティを設定する | 必要なテーブル・オブジェクトだけが追加されている |
| 6 | 用語設定を整備する | Dynamics 365は同義語とグロッサリー、Salesforceはグロッサリーを設計している |
| 7 | 要約指示を調整する | Account summary、Opportunity summaryの出力方針が業務に合っている |
| 8 | 権限テストを行う | 許可ユーザーと制限ユーザーの挙動が確認済み |
| 9 | 営業部門で検証する | 実際の商談準備、顧客確認、会議後フォローで使えるか確認済み |
| 10 | 展開判断を行う | 利用価値、誤回答リスク、運用負荷を踏まえて次の展開範囲を決めている |
ビジネスユーザーが使い始める前に伝えるべきこと
Sales agentを営業担当者に展開する際は、「何でも聞けるAI」として案内しない方がよいです。CRMに接続された営業支援エージェントであり、回答はCRMデータ、会議情報、設定された用語、権限の影響を受けます。
ユーザー向けには、次のように伝えると定着しやすくなります。
| 伝えること | 説明例 |
|---|---|
| CRMデータを前提に回答する | 「Sales agentは、許可されたCRMデータをもとに回答します」 |
| 質問は具体的にする | 「この顧客について教えて」より「この顧客の直近4週間の活動と次アクションを教えて」がよい |
| 回答は確認して使う | AI要約をそのまま顧客に送らず、CRMやメール履歴と照合する |
| 用語の改善に協力する | 伝わらない社内用語があれば管理者に共有する |
| 権限外データは表示されない | 見えないデータがある場合は、CRM権限や対象設定を確認する |
Sales agentの価値は、設定後に一度で完成するものではありません。営業担当者の質問、回答のズレ、足りない用語、要約に含めたい項目を継続的に改善していくことで、現場に合うエージェントになります。
2026年4月更新を踏まえて、今やるべきこと
2026年4月の更新で、Sales agent in Microsoft 365 Copilotは、特にSalesforce利用企業にとって検証しやすくなりました。これまでSalesforce環境で課題になりやすかった独自用語の扱いについて、グロッサリー設定の道筋が示されたためです。
一方で、Sales agentはまだプレビューです。全社展開や本番業務の中核に置く前に、CRM権限、対象エンティティ、グロッサリー、要約指示、アクセス制御をセットで確認する必要があります。
まずは次の3つから始めてください。
| 最初にやること | 理由 |
|---|---|
| 検証対象の営業チームを決める | 全社展開前に業務価値とリスクを確認するため |
| CRMエンティティと機密項目を棚卸しする | AIが参照できるデータ範囲を明確にするため |
| 現場用語を20〜30個に絞ってグロッサリー化する | 回答精度の改善効果を短期間で確認するため |
Microsoft ecosystemでSales agentを活用する鍵は、AI機能そのものよりも、CRMデータと営業現場の言葉をどれだけ丁寧に接続できるかにあります。2026年4月更新は、そのための設定項目がより実務に近づいたアップデートと捉えるとよいでしょう。
コメント