Microsoft 365 Copilotの複数チャネル顧客対応とは？利用条件・データ境界・管理策

Microsoft 365 Copilotの「Engage customers across multiple channels（web, voice, SMS & email）」は、Webチャット、音声通話、SMS、メールをまたいで顧客との接点を継続しやすくする更新です。単一チャネルで反応が途切れても別のチャネルへ引き継ぎ、見込み顧客の離脱を減らし、営業担当者への受け渡しを円滑にすることが狙いです。

ただし、Microsoft 365 Copilotを契約していれば、直ちに電話やSMSを送れるようになるわけではありません。実務上は、Sales agentの導入状況、Dynamics 365 SalesまたはSalesforceとのCRM連携、Dataverseの管理、顧客の同意情報、チャネルごとの運用ルールまで含めて判断する必要があります。

公式ロードマップID 567001は、UTCでは2026年7月8日、日本時間では2026年7月9日に登録されています。プレビュー予定は2026年7月、一般提供予定は2026年8月ですが、ステータスは「In development」です。すでにSales agentとCRMを利用している組織は検証準備を始めるべきですが、Sales agentを導入していない組織に緊急対応は不要です。(Microsoft)

まず結論：対応要否はSales agentとCRMの利用状況で決まる

今回のMicrosoft 365 Copilot更新への対応優先度は、次のように判断できます。

現在の利用状況	対応優先度	取るべき対応
Microsoft 365 Copilotのみ利用し、Sales agentは未導入	低	今後の正式ドキュメントと管理センターの更新を確認する
Sales agentを導入しているが、顧客対応はメール中心	中	SMS・音声・Webチャットを加える必要性と同意管理を整理する
Sales agentとDynamics 365 SalesまたはSalesforceを連携済み	高	対象ユーザーを限定したプレビュー検証を計画する
すでにSMS、電話、メールを組み合わせた営業活動を実施	高	既存システムとの重複、CRM記録、配信停止処理を確認する
独自CRMや国内独自の通信サービスを利用	中	標準連携で対応できるかを確認し、必要なら外部連携方式を検討する
金融、医療、公共分野など機微情報を扱う	高	データ移動、保存先、録音、同意、監査を先に審査する

Sales agentは、Microsoft 365 Copilot内で営業データを検索・要約・活用する会話型エージェントです。現行ドキュメントでは、接続先CRMとしてDynamics 365 SalesとSalesforceがサポートされています。利用にはMicrosoft 365 Copilotライセンスだけでなく、Sales agentのインストール、CRM接続、Sales Chatの有効化、適切なCRM権限が必要です。(Microsoft Learn)

そのため、今回の更新を「WordやExcelから直接電話やSMSを送れる機能」と捉えるのは適切ではありません。ロードマップ本文はSales agentという名称を明記していませんが、見込み顧客の選別や営業プロセスへの引き継ぎを目的としていることから、Sales agentを中心とした営業エンゲージメント機能の拡張として評価するのが実務的です。(Microsoft)

公式ロードマップ567001で何が変わるのか

公式ロードマップに掲載されている内容を整理すると、次のとおりです。

項目	公式情報
ロードマップID	567001
対象製品	Microsoft Copilot（Microsoft 365）
対象チャネル	Webチャット、音声、SMS、メール
主な目的	顧客が好むチャネルで接点を持ち、反応率を高める
期待される効果	会話の継続、離脱の削減、見込み顧客の選別迅速化、営業への円滑な引き継ぎ
プレビュー予定	2026年7月
一般提供予定	2026年8月
開発状況	In development
クラウド	Worldwide（Standard Multi-Tenant）
プラットフォームタグ	Web

現時点の対象タグには、GCC、GCC High、DoDなどの政府機関向けクラウドは含まれていません。また、プレビュー月や一般提供月は確定日ではありません。Microsoft 365ロードマップの掲載内容は変更される可能性があり、延期、内容変更、提供中止もあり得るため、2026年8月を固定的な本番移行日として計画すべきではありません。(Microsoft)

本質はチャネルの追加ではなく「会話の継続」

今回の更新で重要なのは、利用可能な連絡手段が4種類に増えることだけではありません。

例えば、見込み顧客がWebチャットで問い合わせた後、すぐに商談予約をしなかった場合を考えます。従来は、Webチャット、メール配信、SMS通知、電話対応が別々のシステムで動き、担当者が履歴をつなぎ直さなければならないケースがありました。

複数チャネルをまたぐエージェントが機能すれば、次のような流れを一つの顧客対応として扱いやすくなります。

Webチャットで質問
→ メールで資料を送付
→ SMSで予約日時を通知
→ 必要に応じて音声対応へ切り替え
→ CRMの情報とともに営業担当者へ引き継ぐ

公式ロードマップも、単一チャネルが機能しないときの離脱を減らし、最初の関心から成約まで常時対応できる状態を目標として挙げています。(Microsoft)

公式情報だけでは分からない項目も多い

2026年7月9日時点のロードマップには、次の情報が掲載されていません。

• 日本語のWebチャット、音声、SMS、メールがすべて正式対応するか
• SMSや音声で利用する通信事業者、電話番号、送信者ID
• 対応する国や地域ごとの制限
• 着信と発信の両方に対応するか
• 通話録音や文字起こしの有無
• チャネルごとの料金やエージェント利用量
• 一斉送信件数やレート制限
• 公開API、SDK、Webhookの提供有無
• 新機能専用の管理者設定と監査項目
• 顧客の同意や配信停止をどのシステムで管理するか

これらを推測で設計すると、プレビュー開始後に大幅な修正が必要になります。特に日本語の音声品質やSMSの国内対応は、ロードマップのタイトルだけで対応済みと判断してはいけません。

関連するSales agentの「Lead Research and Outreach」は、現行ドキュメントで英語のみの対応とされています。これは今回の複数チャネル機能が英語限定であることを意味しませんが、日本語対応を当然の前提にできない理由にはなります。(Microsoft Learn)

利用条件はライセンスだけでは満たせない

公式ドキュメントから確認できる前提条件

今回のロードマップ項目に固有の詳細条件はまだ示されていません。一方、Sales agentを利用するための現行条件は明確です。

確認項目	現行のSales agentにおける条件
ライセンス	Microsoft 365 Copilotライセンスへのアクセス
エージェント	Sales agentのインストール
CRM	Dynamics 365 SalesまたはSalesforceとの接続
機能設定	Sales Chatの有効化
管理権限	Sales agentの環境レベル設定へアクセスできること
ユーザー権限	CRMデータを閲覧・更新するための権限
データ対象	管理者がSales agentへ公開するCRMエンティティを設定
Outlook・Teams	現行セットアップでは両方への導入が前提

Sales agentはCRMに接続されて初めて実用的に機能します。Microsoft 365 Copilotのライセンスが割り当てられていても、Sales agentがインストールされていない、Sales Chatが無効、CRM接続がないといった状態では、今回の更新を利用できる環境とはいえません。(Microsoft Learn)

管理センターから対象者を限定して展開する

Sales agentは、Microsoft 365管理センターの「Agents」から展開できます。現行手順では「All agents」でSalesを選び、対象ユーザーまたはグループを指定してDeployします。

Outlookなどへの反映には通常数時間かかり、状況によっては最大48時間かかる場合があります。Teamsへの導入は別途Teams管理センターのセットアップポリシーが必要です。プレビュー検証では、展開遅延も考慮して事前にパイロットグループを作成しておく必要があります。(Microsoft Learn)

なお、ロードマップ項目のプラットフォームタグは「Web」ですが、Sales agentの現行セットアップはOutlookとTeamsへの導入を前提としています。プレビューでは、複数チャネル機能の設定画面、実行画面、管理画面がそれぞれどこに表示されるのかを確認しましょう。

CRMエンティティを安易に追加しない

Sales agentでは、管理者がDynamics 365のテーブルやSalesforceのオブジェクトを追加し、エージェントが参照できるCRM情報を設定します。

注意したいのは、公式ドキュメントに「追加したエンティティのすべての列へアクセスする」と記載されている点です。実際に表示できるレコードは利用者のCRM権限に従いますが、機微情報を含む大規模なカスタムエンティティを安易に追加するのは避けるべきです。必要な列だけを安全に公開できるデータ構造へ整理するか、専用ビューや連携用テーブルの作成を検討してください。(Microsoft Learn)

データ境界は「Microsoft 365内だけ」と考えない

複数チャネル対応を導入する際は、Microsoft 365 Copilotの保護だけでなく、CRM、Dataverse、Web検索、通信チャネルを含むデータフロー全体を確認する必要があります。

データの種類	主な保存・処理先	確認すべき点
Copilotへのプロンプトと応答	Microsoft 365	保持期間、監査、秘密度ラベル、ユーザー権限
顧客・商談情報	Dynamics 365 SalesまたはSalesforce	閲覧権限、更新権限、データ品質
Sales agentのインサイト	Dataverse	環境、保持、削除、バックアップ、DLP
公開Web情報の検索語	Bing検索サービス	Microsoft 365とは異なるデータ処理
SMS・音声・メールの本文とメタデータ	今後示されるチャネル基盤、CRM、Dataverseなど	保存先、通信事業者、地域、保持期間
自律実行用のCRM接続情報	CRMの統合ユーザーなど	サービスアカウント権限、監査、停止手順

Microsoft 365 Copilotの保護は適用される

Microsoft 365 Copilotのプロンプトと応答には、エンタープライズデータ保護が適用されます。保存時・転送時の暗号化、テナント分離、既存のIDとアクセス権、秘密度ラベル、保持、監査などが適用され、プロンプト、応答、Microsoft Graph経由で参照したデータは基盤モデルの学習には使われません。(Microsoft Learn)

ただし、これだけを確認して「顧客対応データはすべてMicrosoft 365内にある」と判断するのは不十分です。

Sales agentのデータはDataverseにも保存される

Sales agentはMicrosoft Power Platform上に構築され、接続したCRMに加えてDataverseにもデータを保存します。

Dynamics 365 Salesを利用する場合は、同じDynamics 365 SalesのDataverse環境が使われます。SalesforceなどDynamics 365以外のCRMを利用する場合は、テナント内に「msdyn_viva」というSales agent用Dataverse環境が用意され、CRMとDataverseの両方に関連データが保存されます。(Microsoft Learn)

Sales agentのデータ保持は、一般的なMicrosoft 365データと同じではありません。Microsoft 365サブスクリプション終了後の90日間という削除ルールが、Sales agentのDataverseデータにそのまま適用されるわけではないと公式ドキュメントに記載されています。導入前に、Dataverse側の保持、削除、環境廃止、退職者データの取り扱いを決めておく必要があります。(Microsoft Learn)

日本では地域外データ移動への同意確認が必要

Sales agentはAzure OpenAI Serviceを利用します。CRM環境の地域によっては、プロンプトや生成結果を含むデータが、選択したデータ所在地とは異なる地域のAzure OpenAIエンドポイントへ送信される可能性があります。

公式ドキュメントでは、日本にあるCRM環境は地域間データ移動への同意が必要な地域として記載されています。同意しない場合、販売担当者向けのCopilot AI機能や会議インサイトが利用できません。また、Salesforce接続ではCRMの地域にかかわらず同意が必要です。(Microsoft Learn)

管理者は「Microsoftのサービスだから国内だけで処理される」と推測せず、次の点を確認してください。

• 現在のCRM環境の地域
• Sales agent管理設定における地域外データ移動の同意状態
• 社内規程や顧客との契約で地域外処理が許容されるか
• SMS、音声、メール事業者を含めた処理地域
• 個人データを入力する範囲とマスキング方針

Web検索はMicrosoft 365と異なるデータ処理になる

Microsoft 365 Copilotが公開Web情報を参照する場合、生成された検索語はBing検索サービスへ送信されます。ユーザー名やテナントIDなどは除かれますが、Web検索語にはMicrosoft 365のプロンプトや応答とは異なるデータ処理が適用されます。

Microsoftは、生成されたWeb検索語にはMicrosoft 365のDPAやEU Data Boundaryが適用されないと説明しています。管理者は「Allow web search in Copilot」ポリシーにより、ユーザーまたはグループ単位でWeb検索を制御できます。(Microsoft Learn)

Sales agentの関連機能では、CRMデータと公開Web情報を組み合わせて見込み顧客を調査する場合があります。複数チャネル機能でWeb調査がどの範囲まで使われるかはまだ明示されていないため、プレビューで実際の検索語、監査ログ、引用元を確認することが重要です。

対話型と自律型ではCRMへのアクセス方法が異なる

管理者が見落としやすいのが、エージェントが「誰の権限」で動くかという点です。

対話型のSales agentで利用者がCRMを検索する場合、CRMクエリは現在の利用者のセキュリティアクセスレベルに従います。利用者に閲覧権限がないCRM情報はSales agentにも表示されません。(Microsoft Learn)

一方、バックグラウンドで動作するLead Research and Outreachなどのエージェントは、サーバー間接続を利用します。Salesforceでは専用の接続アプリ、統合ユーザー、権限セットが作成され、利用者が操作していない時間にもCRMデータへアクセスできます。(Microsoft Learn)

今回の複数チャネル機能が、各処理で利用者本人の権限を使うのか、統合ユーザーを使うのかはロードマップに記載されていません。プレビューでは、次の処理ごとに実行主体を確認してください。

• 顧客情報の読み取り
• メール、SMS、音声の送信
• CRM活動履歴の作成
• 連絡先情報の更新
• 営業担当者への割り当て
• エラー時の再送
• 配信停止情報の反映

特に統合ユーザーへ広い権限を与えると、一般ユーザーの閲覧範囲を超えて顧客データを処理する可能性があります。最小権限、認証情報のローテーション、監査ログ、緊急停止手順を設計しておくべきです。

管理者が事前に用意すべき制御

パイロットでは次の管理策を設定する

管理対象	推奨する初期設定
利用者	営業企画、CRM管理者、情報システム担当を含む少人数グループに限定
CRMデータ	必要最小限のエンティティだけを公開
顧客	テスト用または社内検証用の連絡先から開始
チャネル	まずメールとWebなど、リスクの低い組み合わせから開始
SMS・音声	同意状態、番号、録音、営業時間、担当者への転送条件を明確化
Web検索	利用可否をセキュリティ・法務部門と決定
Dataverse	環境管理者、保持期間、DLP、バックアップ、削除担当者を設定
自動送信	初期段階では人による承認を必須にする
監査	送信内容、宛先、使用チャネル、実行主体、参照データを記録
緊急停止	エージェント、CRM接続、各チャネルを個別に停止できる状態にする

Sales agentの管理設定では、機能を有効または無効にし、セキュリティグループで利用範囲を制限できます。関連するLead Research and Outreachは既定で無効であり、有効化時に利用グループを指定できます。今回の複数チャネル機能にも同様の制御が提供されるかは、正式ドキュメントで確認が必要です。(Microsoft Learn)

Sales Chatを無効にしても表示が消えるとは限らない

Sales agentがインストールされている利用者について、Sales Chatを無効にしても、Microsoft 365 Copilot内のSales agent自体は表示され続ける場合があります。この状態では質問はできますが、応答に営業データが含まれません。

利用者から見ると「Salesが表示されるのにCRM情報を取得できない」という状態になるため、ヘルプデスクへの問い合わせが発生しやすくなります。完全に非表示にする場合と、営業データだけを無効にする場合を区別して運用してください。(Microsoft Learn)

管理権限も環境ごとに確認する

Sales agentの管理設定は、接続しているCRM環境ごとに適用されます。Dynamics 365ではSystem AdministratorまたはSystem Customizer、SalesforceではModify All DataまたはManage Data Integrationsなどの管理権限が必要です。

CRMの権限変更は即時反映されない場合があり、Teamsでは反映まで最大15分かかることがあります。権限変更後にSales agentからサインアウトし、再度サインインする手順も運用に含めておきましょう。(Microsoft Learn)

業務で効果が出やすい使いどころ

Web問い合わせから商談予約までの離脱防止

Webサイトで資料請求した見込み顧客に対し、メールで資料を送り、反応がなければ同意済みのSMSで予約ページを案内します。優先度の高い見込み顧客だけを営業担当者の電話対応へ引き継ぎます。

この用途では、次の条件を満たすほど効果が期待できます。

• WebフォームとCRMの顧客IDが一致している
• メールとSMSの同意状態が記録されている
• 営業担当者への割り当てルールが標準化されている
• 問い合わせから初回対応までの目標時間が決まっている
• 送信失敗や返信をCRMへ戻せる

セミナーや展示会後のフォロー

イベント申込時に取得した希望チャネルを基に、メールで資料を送り、SMSで個別相談の日程を通知します。質問内容や閲覧状況を営業担当者へ渡せれば、同じ説明を繰り返さずに商談を始められます。

ただし、イベント申込への同意を、その後の継続的な営業連絡へ無条件に流用するのは避けるべきです。利用目的、対象チャネル、連絡期間を明確にし、配信停止を一元管理します。

休眠案件の再開

一定期間更新のない商談について、CRMの過去履歴を要約し、適切な内容とチャネルで再接触します。すべての休眠顧客へ一律に連絡するのではなく、契約更新時期、過去の反応、担当者変更、製品利用状況などを条件に対象を絞ります。

休眠案件では、古い電話番号、退職済み担当者、重複レコードが残っていることがあります。AIによる文章生成より先に、CRMのデータ品質を改善する必要があります。

向いている業務と向いていない業務

向いている業務	向いていない業務
問い合わせ件数が多く、初動の遅れが課題	CRMの連絡先が古く重複も多い
メールだけでは反応率が低い	チャネルごとの同意を記録していない
営業手順がある程度標準化されている	担当者ごとに営業手順が大きく異なる
CRMへ活動履歴を記録している	顧客対応を個人のメールや電話だけで管理
人への引き継ぎ条件が明確	AIへ高リスクな判断を全面的に任せたい
配信停止や苦情対応の責任者がいる	問い合わせ窓口や停止手順が決まっていない

複数チャネル化は、CRMデータや営業プロセスの問題を自動的に解決するものではありません。データ品質が低い状態で自動化すると、誤送信や重複連絡を高速化する結果になりかねません。

開発・連携では「送信機能」よりデータ設計が重要

ロードマップID 567001は、公開API、SDK、Webhook、カスタムチャネルの追加方法を発表していません。そのため、現段階で新機能の内部APIを前提に開発計画を立てるのは避けるべきです。

開発担当者が先に整備すべきなのは、次の領域です。

顧客IDをチャネル間で統一する

Webチャット、メールアドレス、電話番号、SMS送信先が別々の顧客として登録されると、会話を継続できません。

CRMには少なくとも、次の情報を保持します。

• 顧客を一意に識別するID
• メールアドレスと確認状態
• 電話番号と国番号
• 利用可能なチャネル
• チャネルごとの同意状態
• 同意を取得した日時、方法、文面の版
• 配信停止日時
• 優先する連絡手段
• 連絡可能な時間帯
• 担当営業と所属組織

同意情報を一つの正本にする

メールシステム、SMSサービス、CRMがそれぞれ別の同意情報を持つと、停止済みの顧客へ別チャネルから連絡する事故が起こります。

同意情報の正本をCRMまたは専用の同意管理基盤に定め、各チャネルが送信直前に最新状態を確認する設計にします。古いキャッシュやバッチ連携だけに依存しないことが重要です。

CRM記録の重複を防ぐ

同じ顧客へメール、SMS、電話を順番に実行すると、再試行やタイムアウトによって同じ活動履歴が複数回作成される可能性があります。

各処理に一意のイベントIDを付け、次の情報を記録します。

• 実行日時
• 使用チャネル
• 宛先
• 送信結果
• 返信の有無
• 参照したCRMレコード
• 生成に使用した情報
• 実行したユーザーまたはエージェント
• 人による承認者
• 再送回数
• エラー理由

人への引き継ぎを例外処理として扱わない

AIで解決できなかったときだけ人へ回す設計では、引き継ぎ時に必要な情報が不足しやすくなります。

最初から、次の条件では人へ引き継ぐルールを用意します。

• 顧客が担当者との会話を希望した
• 苦情、解約、返金に関する内容
• 金額や契約条件の個別交渉
• 本人確認が必要
• 同意状態を確認できない
• 顧客の特定に複数候補がある
• AIが参照した情報に矛盾がある
• 同じ顧客への連絡回数が上限に達した

引き継ぎ時には、会話の要約だけでなく、原文、使用チャネル、本人確認状態、CRMレコードへのリンクも渡せるようにします。

プレビュー開始前に進める導入手順

手順	実施内容	完了の判断基準
現状確認	Microsoft 365 Copilot、Sales agent、CRMの利用状況を確認	ライセンス、導入先、CRM環境、管理者が一覧化されている
対象業務の選定	離脱が多い一つの顧客対応フローを選ぶ	開始点、終了点、担当者、KPIが明確
データフロー作成	Microsoft 365、CRM、Dataverse、Web検索、通信サービスを図示	保存先、処理地域、実行主体を説明できる
同意管理の確認	メール、SMS、電話の同意と停止方法を整理	送信直前に最新の同意状態を確認できる
パイロット設定	セキュリティグループで少人数に限定	対象外ユーザーが機能や営業データを利用できない
テスト実施	テスト用連絡先で正常系と異常系を検証	誤送信、重複、停止漏れ、権限超過がない
日本語評価	日本語の文面、固有名詞、音声、敬語を検証	担当者が業務利用可能と判定できる
監査確認	CRM、Dataverse、Microsoft 365のログを確認	誰が何を送ったか追跡できる
本番判断	効果とリスクを関係部門で評価	導入、延期、中止の判断根拠が文書化されている

プレビュー機能は、本番業務での利用を前提としない場合があります。Microsoftも、Sales agentの関連プレビュー機能について、機能制限があり変更される可能性があると説明しています。実在する顧客への大量送信から始めず、テスト環境または限定的な社内検証から進めてください。(Microsoft Learn)

効果測定では反応率だけを見ない

Microsoftのロードマップでは、反応率の向上、見込み顧客の迅速な選別、営業への円滑な引き継ぎが期待効果として示されています。(Microsoft)

しかし、反応率だけを目標にすると、連絡回数を増やしすぎる可能性があります。次の指標を組み合わせて評価してください。

指標	確認する目的
初回応答までの時間	対応速度が改善したか
見込み顧客の選別時間	営業担当者の作業が減ったか
営業への引き継ぎ時間	有望案件を放置していないか
チャネル別反応率	顧客に適した連絡方法を選べているか
配信停止率	連絡頻度や内容が過剰でないか
苦情率	顧客体験を損ねていないか
CRM記録成功率	活動履歴が欠落していないか
重複連絡率	システム間連携に問題がないか
人による修正率	AIの文章や判断品質が十分か
誤った顧客特定率	同姓同名や重複レコードの問題がないか

反応率が上がっても、配信停止や苦情が増えているなら成功とはいえません。営業効率、データ品質、顧客体験、コンプライアンスを同時に評価する必要があります。

失敗しやすいポイント

Microsoft 365 Copilotライセンスだけで使えると思う

Sales agentのインストール、CRM接続、Sales Chat、CRM権限、Dataverse環境など、複数の前提があります。ライセンス割り当てだけで導入完了とは判断できません。

4チャネルへ同じ文章を送る

メールの長文をそのままSMSへ送ったり、Webチャット用の短い回答を音声で読み上げたりしても、顧客体験は改善しません。チャネルごとに文章量、緊急度、呼びかけ方、返信方法を設計します。

同意を顧客単位の一つのフラグで管理する

メールには同意していても、SMSや電話には同意していない顧客がいます。「営業連絡可」という一つの項目だけではなく、チャネル別に状態を管理します。

Dataverseの存在を見落とす

Salesforceを利用している場合でも、Sales agentの関連データはDataverseのmsdyn_viva環境にも保存されます。CRMだけを監査・バックアップしても不十分です。(Microsoft Learn)

日本語対応をロードマップの掲載だけで判断する

ロードマップの対象チャネルにSMSや音声が含まれていても、日本語音声、日本国内の電話番号、国内SMS事業者への対応を保証するものではありません。プレビューで実際の対応範囲を確認します。

プレビューで実在顧客へ一斉送信する

誤送信、重複送信、配信停止漏れ、誤った顧客特定が起きた場合の影響が大きくなります。最初はテスト連絡先、社内ユーザー、少数の同意済み顧客に限定します。

AIの調査結果を確認せず送信する

同名企業、古いニュース、別人の情報を参照する可能性があります。重要な営業連絡では、参照元とCRM情報を人が確認してから送信する運用を残します。

今やるべきこと

Microsoft 365 Copilotの複数チャネル顧客対応は、単なるメール作成支援から、顧客との接点を継続的に動かすエージェントへ進む重要な更新です。一方で、2026年7月9日に登録されたロードマップ情報だけでは、国内対応、チャネル事業者、料金、API、専用管理設定などは確定していません。

Sales agentを利用していない組織は、現時点で設定変更を急ぐ必要はありません。まず、将来的にWeb、音声、SMS、メールを連携させたい業務があるかを整理しましょう。

Sales agentとDynamics 365 SalesまたはSalesforceをすでに利用している組織は、次の4点を確認してください。

• Microsoft 365管理センターでSales agentの展開対象を確認する
• CRMでSales agentが参照できるエンティティと権限を確認する
• Power Platform管理センターでDataverse環境とmsdyn_vivaの管理状態を確認する
• 地域外データ移動、Web検索、チャネル別同意、配信停止の方針を決める

本番展開は、正式ドキュメントで日本語対応、対応地域、通信サービス、料金、保持期間、監査、管理者制御を確認してから判断するのが安全です。まずは一つの業務フローと少人数のパイロットグループに絞り、データフローと停止手順を整えることが、最も現実的な初動になります。