Dynamics 365 Sales Qualification Agent の2026年4月更新でまず押さえるべき結論は、「設定手順そのもの」だけでなく、本番展開前の環境移行、権限、メール送信、ナレッジソース、モード選択を管理者が事前に設計する重要性が高まっているという点です。
Sales Qualification Agent は、Dynamics 365 Sales 上でリード調査、ターゲット顧客プロファイル評価、初回メールのアウトリーチを支援するAIエージェントです。販売担当者が使い始める前に、管理者が会社情報、製品情報、選定条件、引き渡し条件、ナレッジソースなどを設定する必要があります。Microsoft Learnの現在の該当ページは「Last updated on 2026-04-27」と表示されており、GitHub履歴では2026年4月22日に更新サイクルを180日に戻す差分も確認できます。そのため、4月22日更新を追っている管理者は、単なる機能追加としてではなく、4月後半に行われたドキュメント整理と本番展開手順の明確化として読むのが実務的です。(Microsoft Learn)
Dynamics 365の最新動向: Set up and configure the Sales Qualification Agentで何が変わったか
2026年4月更新のポイントは、Sales Qualification Agent の設定項目が突然大きく変わったというより、管理者が導入前に確認すべき運用面がより明確になったことです。特に注目したいのは、エージェントをある環境で構成した後、ソリューションとしてエクスポートし、別環境へインポートできる「環境移行」の説明が追加された点です。MicrosoftのGitHub差分では、Sales Qualification Agentのページに「Migrate agents across environments」セクションが追加され、サンドボックスやテスト環境で検証した設定を本番環境へ展開する流れが明示されています。(GitHub)
| 更新ポイント | 管理者への影響 | 取るべき対応 |
|---|---|---|
| ドキュメントの更新サイクルが180日に変更 | Microsoft Learn上のメタ情報変更であり、Dynamics 365環境の動作設定そのものではない | 機能の可用性や制限は、Microsoft Learn本文とリリース情報を併せて確認する |
| 環境移行の説明が追加 | 検証環境から本番環境へ移す導線が明確化 | いきなり本番で作らず、サンドボックスで構成・検証してから移行する |
| 前提条件の確認が重要 | Copilot Studio、Dataverse、Exchange、DLP、通知設定が絡む | Sales管理者だけでなく、Power Platform管理者、Exchange管理者、セキュリティ担当を巻き込む |
| Research-onlyとResearch and engageの選択が重要 | 自動メール送信やBANT評価を使うかどうかでリスクが変わる | 最初はResearch-onlyで検証し、体制が整ってからResearch and engageへ進む判断をする |
| カスタムロールの権限確認が必要 | 引き渡されたリードを営業担当が扱えない可能性がある | 本番前にSalesperson、Sales Manager、カスタムセキュリティロールを棚卸しする |
ここで誤解しやすいのは、「2026年4月22日更新＝すぐに本番機能が変わった」と受け止めてしまうことです。実際には、4月22日の差分は主に ms.update-cycle の変更であり、後続の4月27日更新で環境移行に関する本文が追加されています。IT管理者は、更新日だけで判断せず、本文差分と運用上の影響を分けて確認する必要があります。(GitHub)
Sales Qualification Agentとは何を自動化するAIエージェントか
Sales Qualification Agent は、営業担当者がすべてのリードを手作業で調査する負荷を減らすためのAIエージェントです。主な役割は、割り当てられたリードを調査し、企業情報や公開情報、設定済みのナレッジソースをもとに、顧客適合度や購買意欲を評価することです。モードによっては、初回アウトリーチやフォローアップメールの作成・送信まで自律的に行います。(Microsoft Learn)
| モード | 主な動作 | 向いている組織 |
|---|---|---|
| Research-only mode | リードを分析し、調査結果、アウトリーチメール案、推奨アクションを提示する | AIによる自動送信は避け、営業担当者が最終判断したい組織 |
| Research and engage mode | リードを分析し、顧客と自律的にメールでやり取りし、条件に合うリードを営業担当へ引き渡す | メール送信、コンプライアンス、BANT評価、監視体制まで整備できている組織 |
重要なのは、組織内で展開できるモードは一方のみであり、Research-only mode から Research and engage mode へは後からアップグレードできますが、その逆はできない点です。また、エージェントを停止しても、すでに処理パイプラインに入っている既存リードは、営業担当への引き渡しまたはスーパーバイザーダッシュボードへの追加まで処理が継続します。構成済みのエージェントを削除する場合はMicrosoftサポートへの連絡が必要とされています。(Microsoft Learn)
導入前に確認すべき前提条件
Sales Qualification Agent の導入は、Dynamics 365 Sales の画面だけで完結する作業ではありません。Microsoft Learnでは、共通前提条件として、Power Platform管理者ロール、Copilot Studio容量、リージョンをまたぐデータ移動の許可、AIプロンプト、AI insight cards、AI Agents機能などの確認が示されています。AI agentsページのCreateオプションは、必要な前提条件が完了するまで無効になります。(Microsoft Learn)
Sales Qualification Agent固有の前提としては、Dynamics 365 Salesの管理者権限、Copilot Studioライセンス、Sales HubアプリのモダンUI、必要なコネクタを許可するデータポリシー、Exchangeとのサーバー側同期、アプリ内通知の有効化が挙げられています。特にサーバー側同期が設定されていない場合、エージェントはアウトリーチメールを生成したり、リードとやり取りしたりできません。(Microsoft Learn)
| 確認項目 | なぜ重要か | 実務での確認先 |
|---|---|---|
| Copilot Studioライセンス・容量 | エージェント構築と実行の基盤になる | Power Platform管理センター |
| Data policy / DLP | Copilot Studio、Dataverse、公開Web、SharePointなどの接続可否に影響する | Power Platform管理センター |
| Dataverseアプリユーザー | エージェントが独立してレコード操作を行うために必要 | Power Platform管理センター、Dataverse |
| Exchangeサーバー側同期 | Research and engage modeでメール送受信に必要 | Dynamics 365、Exchange管理センター |
| アプリ内通知 | リード引き渡しを営業担当やスーパーバイザーへ知らせるために必要 | Dynamics 365 Sales |
| カスタムセキュリティロール | 引き渡されたリードを営業担当が操作できるかに直結する | Dynamics 365のセキュリティ設定 |
導入プロジェクトでは、Sales管理者だけで進めると詰まりやすくなります。少なくとも、Dynamics 365 Sales管理者、Power Platform管理者、Exchange管理者、セキュリティまたはコンプライアンス担当、営業部門のプロダクトオーナーを初期段階から含めるべきです。
設定の流れ：小さく始めてから本番展開する
Sales Qualification Agent の設定は、画面上では順番に進められますが、実務では「設定を埋める作業」ではなく「営業プロセスをAIエージェントにどこまで任せるかを設計する作業」と考えるべきです。Microsoft Learnでは、Sales HubアプリのApp SettingsからDynamics 365 AI hubへ進み、Agent managerでCreate and manage agentsを選択して作成する流れが説明されています。作成時にはSales Qualification Agentを選び、Researchは既定で選択され、必要に応じてEngage機能を追加します。(Microsoft Learn)
| 手順 | 設定内容 | 失敗しやすいポイント |
|---|---|---|
| AI Hubから作成 | Sales Qualification Agentを選択し、モードを決める | Research and engageを選ぶ前に、メール送信・法務・監視体制を確認していない |
| 前提条件の構成 | Entraアプリ、Dataverseアプリユーザー、共有メールボックス、サーバー側同期を設定 | アプリユーザーにAISalesPersonロールを付与し忘れる |
| 一般設定 | エージェント名、目的、会社情報、製品情報、言語、署名、AI免責文を設定 | 製品価値提案が抽象的で、リード評価やメール内容が弱くなる |
| 選定条件 | どのリードをエージェントに処理させるかを定義 | 営業担当への通常割り当てセグメントと重複し、エージェントに渡らない |
| メール設定 | AIパーソナライズまたはメールテンプレート、検証用メール項目を設定 | テンプレート側に署名を残し、二重署名になる |
| 引き渡し条件 | ターゲット顧客プロファイル、BANT、カスタム条件を定義 | テスト時から条件を細かくしすぎ、該当リードが見つからない |
| 割り当てルール | 営業担当者、チーム、スーパーバイザーを指定 | 引き渡し先ユーザーに必要な権限がない |
| ナレッジソース | 公開Web、SharePoint、競合資料、事例、製品情報などを追加 | 広すぎるWebサイトや古い資料を追加し、回答品質が落ちる |
| シミュレーション | Research and engageで送信前にメール案を検証 | Copilot容量や対象リード不足で実行できない |
| 開始 | すべての構成が完了してからStart agentを実行 | 開始後に設定を大きく変え、処理結果の一貫性が崩れる |
一般設定では、エージェントプロファイル、会社情報、製品情報を設定します。製品やサービスの価値提案は、アウトリーチメールや引き渡し条件の自動生成にも使われるため、「当社の業務効率化ツール」ではなく、「中堅製造業向けに、見積承認プロセスを短縮し、営業と生産管理の情報共有を改善するクラウドサービス」のように、対象業種、課題、提供価値を具体化しておくと効果が出やすくなります。(Microsoft Learn)
選定条件では、どのリードをエージェントに処理させるかを定義します。Microsoft Learnでは、既定条件として、StatusがOpen、RatingがCold、Lead SourceがEmployee ReferralおよびPartnerではない、Emailにデータがある、といった条件例が示されています。また、条件はグループや関連エンティティを含めて最大10件までで、エージェント用セグメントが既存の営業割り当てセグメントと重複すると、リードが営業担当へ割り当てられてしまう可能性があります。(Microsoft Learn)
モード選択の判断基準
最初に悩むのは、Research-only modeで始めるか、Research and engage modeまで有効にするかです。判断軸は「AIがメールを送ることを組織として許容できるか」です。機能面だけを見るとResearch and engage modeの方が強力ですが、共有メールボックス、サーバー側同期、コンプライアンスプロファイル、BANT条件、ナレッジソース、監視プロセスまで整っていない状態では、営業現場や法務部門との調整コストが高くなります。
| 判断軸 | Research-only modeが向く場合 | Research and engage modeが向く場合 |
|---|---|---|
| メール送信のリスク許容度 | AIの下書きを人が確認して送信したい | AIによる初回接触やフォローアップを許容できる |
| 営業プロセスの成熟度 | リード評価基準がまだ曖昧 | BANTや購買意欲の判定基準が明文化されている |
| コンプライアンス | AI免責文やオプトアウト設計が未整備 | メール送信ポリシー、同意管理、監査対応が整理済み |
| ナレッジソース | まず調査結果の品質を確認したい | 製品仕様、価格、FAQ、事例、営業プレイブックを整備済み |
| 導入ステップ | パイロット導入向き | 運用設計後の拡張向き |
安全に進めるなら、サンドボックスでResearch-only modeを作成し、営業マネージャーと調査結果の品質を確認します。その後、対象リード、BANT条件、メール文面、オプトアウト、監視プロセスを固めてからResearch and engage modeへ拡張する流れが現実的です。
メール設定では「AIで書かせるか、テンプレートを使うか」を分けて考える
Sales Qualification Agentのメール設定では、AIパーソナライズとメールテンプレートのどちらを使うかを選べます。AI-personalizationを使う場合、エージェントは設定された指示やナレッジソースをもとに、リード企業に合わせたアウトリーチメールを生成します。一方、Email templateを選ぶと、リードテーブル用の既存テンプレートを使って一貫した形式のメールを作れます。固定テンプレートを使う場合、生成AIや設定済みナレッジソースはメール本文作成に使われず、固定テンプレートによるアウトリーチメールではCopilotクレジットが消費されないと説明されています。(Microsoft Learn)
ここで多い失敗は、「テンプレートを使いながら、AIが事例や競合情報を反映してくれる」と期待してしまうことです。ブランド統制や法務レビュー済み文面を優先するならテンプレート、個別企業に合わせた提案力を優先するならAIパーソナライズ、というように使い分ける必要があります。
また、テンプレート内の署名は削除しておきます。エージェントは送信者の署名をアウトリーチメールに自動追加するため、テンプレートに署名が残っていると二重署名になりやすいからです。Research and engage modeでは、コンプライアンス設定を有効にし、組織の要件に合わせたプロファイル、目的、トピックを指定します。(Microsoft Learn)
引き渡し条件はBANTだけでなく、ターゲット顧客プロファイルを具体化する
Handoff criteriaでは、ターゲット顧客プロファイルとBANTを設定します。ターゲット顧客プロファイルはResearch-only modeとResearch and engage modeの両方で使われますが、BANT条件はResearch and engage modeで、リードと自律的にやり取りするかどうかの判断に使われます。Microsoft Learnでは、BANTの評価順としてNeed、Timeline、Budget、Authorityが示されており、購買意欲シグナルとBANTスコアによって、営業担当へ引き渡すか、失格扱いにするかが決まります。(Microsoft Learn)
実務では、最初から条件を細かくしすぎないことが重要です。Microsoft Learnでも、テスト時は業種や役職など少数の条件で始め、成功後に条件を追加する例が示されています。例えば、初期テストでは「Industry = Technology」「Job title contains Manager」のように、検証用リードを作りやすい条件にします。その後、本番では従業員規模、地域、売上規模、利用中システム、意思決定者の役割などを段階的に追加すると、原因分析がしやすくなります。(Microsoft Learn)
カスタム条件を使う場合は、Dataverseのカスタムフィールドや公開URLを参照できます。ただし、Lookup、Owner、PartyList、Customerなど一部の属性タイプは引き渡し条件でサポートされていません。カスタムフィールドを後から削除すると、エージェントがサマリー生成やリード引き渡しをできなくなる可能性があるため、削除前に条件側を更新または削除しておく必要があります。(Microsoft Learn)
ナレッジソースは「量」より「用途別の精度」が重要
Sales Qualification Agentは既定で公開Webデータを使って企業やリードを調査できますが、組織固有の文脈を反映するには、ケーススタディ、顧客事例、製品資料、競合比較資料、営業プレイブックなどのナレッジソースを追加する必要があります。Microsoft Learnでは、ナレッジソースを追加するとMicrosoft Copilot Studioへリダイレクトされ、研究、アウトリーチメール、フォローアップメールなど用途別のマイクロエージェントに追加されると説明されています。(Microsoft Learn)
注意したいのは、ナレッジソースを増やせば品質が上がるとは限らない点です。広すぎる公開サイト、古い価格表、改訂前の製品仕様、営業現場で使われていない資料を追加すると、メールや調査結果の精度が落ちます。Microsoft Learnでも、説明は具体的にする、広すぎる公開サイトを制限する、セキュリティを確認する、AIクレジットの消費を監視するといったベストプラクティスが示されています。(Microsoft Learn)
| 用途 | 追加すると有効なナレッジソース | 避けたい例 |
|---|---|---|
| 会社調査 | 年次報告書、決算資料、業界レポート、公開Webページ | 内容が古い企業紹介PDF |
| 競合インサイト | バトルカード、競合比較表、ポジショニング資料 | 営業現場で未承認の個人メモ |
| アウトリーチメール | 顧客事例、導入効果、ユースケース | 汎用的すぎるマーケティング文面 |
| フォローアップメール | FAQ、価格体系、製品仕様、営業プレイブック | 更新されていない価格表 |
| グローバル展開 | 地域別の製品説明、言語別の営業資料 | 日本語資料だけで海外リードを処理する設定 |
SharePoint上のファイルを使う場合も注意が必要です。Microsoft Learnでは、エージェントが使うファイルや文書はSharePointフォルダーに置く必要があり、OneDriveなど他のファイルソースはサポートされないと説明されています。また、Copilot StudioでSharePointファイルを追加する際は、FeaturedセクションのSharePointオプションを使う必要があるとされています。(Microsoft Learn)
2026年4月更新で特に重要な「環境移行」の考え方
今回の更新で管理者が最も実務に活かしやすいのは、Sales Qualification Agentをソリューションとして別環境へ移行する説明です。Microsoft Learnでは、サンドボックスまたはテスト環境でエージェントを構成し、Power PlatformのALM機能を使ってソリューションとしてエクスポートし、本番などのターゲット環境へインポートする流れが説明されています。(Microsoft Learn)
| 移行フェーズ | 実施内容 | 注意点 |
|---|---|---|
| ソリューション設計 | 1つのエージェントプロファイルにつき1つのソリューションを作成 | 複数プロファイルを同一ソリューションに入れると、未検証の変更を含めるリスクがある |
| エクスポート | SalesAgentProfile、SalesAgentConfigurationV2、Sales Qualification Agent用のSequenceを追加 | SequenceはAgenticSequenceという名前のレコードを選択する |
| ナレッジソース追加 | 関連するAgentコンポーネントをソリューションに追加 | ナレッジソースの実体や参照先が環境ごとに異なる場合がある |
| 本番インポート | Power Apps maker portalでソリューションをインポート | インポート後のエージェントはドラフト状態 |
| 適用確認 | インポートしたエージェントを開き、Apply changesを選択 | コンポーネントが正しく反映されるよう確認する |
| 環境固有設定 | アプリユーザー、アプリ登録、前提条件、割り当てルール、ナレッジソースを確認 | ユーザー、チーム、SharePointライブラリなどは環境差分が出やすい |
| 起動 | 環境固有設定を修正後、保存してStart agent | 本番起動前に営業担当の権限とビューを確認する |
移行時に特に見落としやすいのは、アプリユーザー、アプリ登録、割り当て先ユーザーまたはチーム、SharePointライブラリです。これらは環境固有の値になりやすく、ソリューションとして移してもそのまま使えるとは限りません。Microsoft Learnでも、インポート後はアプリユーザーの再選択、割り当てルールや選定条件の見直し、ナレッジソースの確認を行うよう説明されています。(Microsoft Learn)
実務では、「検証環境で動いたから本番でも動く」と考えず、移行後に次の4点を必ず確認します。
- 引き渡し先の営業担当またはチームが本番環境に存在するか
- 参照しているSharePointライブラリや公開URLが本番運用に適しているか
- Dataverseアプリユーザーと必要なアプリ登録を本番環境で作成済みか
- インポート後にApply changesを実行し、ドラフト状態から開始できる状態になっているか
権限とセキュリティで確認すべきポイント
Sales Qualification Agentの導入では、AIの精度以上に権限設計が重要です。標準のSalespersonやSales Managerロールを使っている場合、引き渡されたリードを扱うための追加権限は不要とされています。一方、営業チームでカスタムセキュリティロールを使っている場合は、Sales Copilot Insight、Sales Agent Handover、Email Activity、Lead、Notificationなど、複数のテーブルに対する権限が必要です。リードを別ユーザーへ再割り当てする運用がある場合、その再割り当て先ユーザーにも必要な権限がないと割り当てに失敗します。(Microsoft Learn)
セキュリティ面では、Sales Qualification AgentはMicrosoft Entra ID認証を使い、Dataverseのアプリユーザーとして設定されます。エージェントの出力を営業担当が閲覧できるかどうかは、営業担当自身のセキュリティロールに基づいて制御されます。これにより、営業担当が本来読めない情報まで見えてしまうことを防ぐ設計になっています。(Microsoft Learn)
データ処理については、Microsoftのアーキテクチャ説明で、データはエージェント呼び出しまでPower Apps境界内に残り、Sales Qualification Agentはデータのコピーを作成・保持せず、必要なフィールドだけをCopilot Agentsへ渡すと説明されています。また、Azure OpenAIへの最小限の制御されたペイロードは基盤モデルの学習には使われないとされています。(Microsoft Learn)
Bing検索についても確認が必要です。Sales Qualification Agentは公開Web上のリード企業情報を調査するためにBingを使いますが、Microsoftの説明では、Bingへ送信されるのは動的に生成された検索クエリであり、ユーザー識別子、テナントID、認証情報、社内機密情報は送信されないとされています。グローバル環境で運用する場合は、公開Web調査、データレジデンシー、リージョン間データ移動の許可を、各地域のコンプライアンス要件に照らして確認しておくべきです。(Microsoft Learn)
シミュレーションと開始前チェック
Research and engage modeでは、アウトリーチメール送信前にシミュレーションを実行できます。この機能はResearch and engage、つまり完全自律モードでのみ利用でき、リードを調査したうえでメール案を生成し、送信前に内容を確認できます。シミュレーションはCopilot容量のトークンを消費するため、実行前に十分な容量があるか確認が必要です。(Microsoft Learn)
シミュレーションが実行できない場合は、対象リードが選定条件に一致していない、構成項目がすべて緑のチェックになっていない、前提条件が未完了、といった原因が考えられます。テスト用リードを意図的に作成し、選定条件、引き渡し条件、メール生成、営業担当への引き渡しまで一連の流れを確認してから本番開始しましょう。(Microsoft Learn)
Start agentを実行する前には、すべての構成セクションが完了し、Research and engage modeではアウトリーチメールのシミュレーションが完了している必要があります。また、Bing SearchとMove data across regionsの条件受諾も確認事項として示されています。エージェント開始後は、設定済みの選定条件に一致するリードの処理が始まります。(Microsoft Learn)
よくある失敗と回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 最初からResearch and engage modeで本番投入する | AIメール送信、同意管理、監視体制が追いつかない | Research-onlyで調査品質を確認してから拡張する |
| 既存の営業割り当てセグメントと重複する | リードがエージェントではなく営業担当へ割り当てられる | 選定条件をPreview leadsで確認し、既存セグメントとの重複を避ける |
| 製品情報が抽象的 | メールや評価結果が一般論になる | 対象業種、課題、導入効果、差別化要素を具体的に書く |
| 固定テンプレートでAI活用を期待する | ナレッジソースがメール本文に反映されない | AI-personalizationとEmail templateの用途を分ける |
| 署名をテンプレートに残す | メール署名が重複する | テンプレート側の署名を削除する |
| カスタムロールの権限不足 | 引き渡しリードを開けない、再割り当てできない | 本番前に営業担当、チーム、スーパーバイザーの権限を検証する |
| OneDriveの資料をナレッジソース前提にする | エージェントが期待どおり処理できない | SharePointフォルダーを使い、Copilot Studio側で正しい追加方法を選ぶ |
| ソリューション移行後に環境固有設定を確認しない | 本番でアプリユーザー、チーム、ナレッジソースが解決できない | インポート後にApply changes、アプリユーザー再選択、割り当てルール確認を行う |
管理者が次に取るべき行動
Dynamics 365 Sales Qualification Agentを導入するなら、まずは本番環境で作り始めるのではなく、サンドボックスで小さく検証するのが最も安全です。最初のスコープは、特定の地域、特定の製品ライン、低優先度または未対応のリードなどに絞ると、効果とリスクを測定しやすくなります。
次に、Research-only modeでリード調査結果と推奨アクションの品質を確認します。営業マネージャーに、企業調査の妥当性、ターゲット顧客プロファイルの精度、引き渡しサマリーの使いやすさをレビューしてもらいます。そのうえで、メール文面、AI免責文、オプトアウト、共有メールボックス、BANT条件、ナレッジソースが整った段階でResearch and engage modeへの拡張を検討します。
2026年4月更新の実務的な意味は、Sales Qualification Agentを「試す機能」から「管理された営業AIエージェントとして展開する機能」へ位置付け直すことにあります。IT管理者は、前提条件、権限、DLP、サーバー側同期、ナレッジソース、環境移行、監視をチェックリスト化し、営業部門のプロダクトオーナーは、どのリードをAIに任せ、どのタイミングで人に引き渡すかを明文化しましょう。
本番展開前にやるべきことは明確です。サンドボックスで構成し、選定条件と引き渡し条件を検証し、メールシミュレーションを確認し、Power Platform ALMで本番へ移行し、環境固有設定を再確認してからStart agentを実行します。この順序を守れば、Dynamics 365 Sales Qualification Agentを単なるAI機能ではなく、営業プロセスに組み込める実用的な自動化基盤として活用できます。
コメント