Microsoft 365 Copilotの宣言型エージェント（Declarative Agents）を運用している組織で、MCPサーバー上のツール追加・更新・廃止をより速く反映できるようになります。今回の「Dynamic Tool Discovery」は、開発者がエージェントを再公開しなくてもMCPサーバー側のツール変更を反映できる仕組みです。つまり、エンドユーザーは新しいエージェント機能を待たずに使える一方、管理者と開発者は「いつ、どのツールが、誰に使える状態になるのか」をこれまで以上に継続管理する必要があります。Microsoft 365 Roadmap ID 561855では、対象はMicrosoft Copilot（Microsoft 365）、状態はIn development、一般提供予定はJune CY2026、対象プラットフォームはDesktop、Mobile、Web、対象クラウドはWorldwide（Standard Multi-Tenant）とされています。(Microsoft)
Microsoft 365 CopilotのDynamic Tool Discoveryで何が変わるのか
Dynamic Tool Discoveryは、Microsoft 365 Copilotの宣言型エージェントが利用するMCPサーバー上のツールを、エージェントの再公開なしで検出・反映できるようにする更新です。従来は、エージェント側のパッケージや設定に含まれるツール情報を変更するたびに、開発・検証・再公開の流れが必要になりがちでした。今回の更新では、MCPサーバー側でツールを追加、更新、廃止すると、エージェントが最新のツール構成を利用できる方向になります。(Microsoft)
重要なのは、これは単なる開発効率化ではないという点です。ツールが動的に変わるということは、ユーザー体験、運用手順、権限レビュー、問い合わせ対応のタイミングも変わります。特に、社内システムへの検索、チケット作成、CRM更新、申請処理などをMCPツール化している場合は、ツールの変更がそのまま業務手順の変更になります。
| 項目 | 公式情報上の内容 | 実務で見るべきポイント |
|---|---|---|
| 対象サービス | Microsoft Copilot（Microsoft 365） | Microsoft 365 Copilot上の宣言型エージェント運用が主な対象 |
| 変更内容 | MCPサーバー上のツール追加・更新・廃止を、エージェント再公開なしで反映 | ツール変更がユーザーに早く届くため、変更管理が重要 |
| 状態 | In development | 本番適用前に検証環境・対象グループでの確認が必要 |
| リリース段階 | General Availability | プレビュー日が空欄のため、正式な展開時期はロードマップの更新確認が必要 |
| 一般提供予定 | June CY2026 | 予定は変更される可能性があるため、管理センターやロードマップで継続確認する |
| 対象環境 | Worldwide（Standard Multi-Tenant） | GCC、GCC High、DoDなど政府系クラウドは今回の対象としては示されていない |
| 対象プラットフォーム | Desktop、Mobile、Web | クライアント別にユーザー体験を確認する |
Microsoft 365 Roadmap自体は商用機能の予定日と説明を提供するもので、情報は変更される可能性があるとMicrosoftは明記しています。展開判断では、ロードマップだけでなく、自社テナントのメッセージセンターや管理センター側の通知も合わせて確認してください。(Microsoft)
宣言型エージェントとMCPサーバーの関係を整理する
今回の更新を理解するには、「宣言型エージェント」「MCPサーバー」「ツール」の関係を押さえる必要があります。
宣言型エージェントは、Microsoft 365 Copilotを特定業務向けにカスタマイズする仕組みです。開発者は、指示、アクション、ナレッジを定義して、ITヘルプデスク、営業支援、社内規程確認、顧客対応などの用途に合わせたCopilot体験を作れます。Microsoft Learnでは、宣言型エージェントはMicrosoft 365 Copilotと同じオーケストレーター、基盤モデル、信頼できるAIサービス上で動作すると説明されています。(Microsoft Learn)
MCPサーバーは、エージェントが外部システムや業務データにアクセスするための接続口です。Microsoft 365 Agents Toolkitでは、宣言型エージェントにMCPサーバーベースのアクションを追加し、MCPサーバーが公開するツールをエージェントで利用する手順が示されています。(Microsoft Learn)
実務では、次のように考えると分かりやすいです。
| 用語 | 役割 | 例 |
|---|---|---|
| 宣言型エージェント | Microsoft 365 Copilot上で動く業務特化エージェント | 「営業提案支援エージェント」「IT問い合わせ対応エージェント」 |
| MCPサーバー | エージェントが外部機能やデータに接続するためのサーバー | CRM、在庫管理、社内ナレッジ、チケット管理システムへの接続 |
| ツール | MCPサーバー上でエージェントが呼び出す具体的な機能 | 顧客情報検索、チケット作成、注文状況取得、FAQ検索 |
| Dynamic Tool Discovery | エージェントがMCPサーバー上の最新ツール構成を動的に利用する仕組み | 新しい検索ツールをサーバー側に追加すると、再公開なしで反映される |
これまでの運用と何が違うのか
これまでのエージェント開発では、ツール追加や仕様変更があるたびに、エージェントの構成変更、パッケージ更新、検証、展開という流れを意識する必要がありました。Dynamic Tool Discoveryでは、このうち「エージェントを再公開して反映する」という工程が軽くなります。
たとえば、営業支援エージェントに次のようなツールを追加する場面を考えます。
| 変更内容 | 従来の考え方 | Dynamic Tool Discovery後の考え方 |
|---|---|---|
| CRMから商談情報を検索するツールを追加 | エージェント構成を更新し、再公開してから利用開始 | MCPサーバー側でツールを追加し、エージェントが最新機能を利用 |
| 古い価格表検索ツールを廃止 | エージェント側からツール定義を外して再公開 | MCPサーバー側で廃止し、ユーザーが古い機能を使わないようにする |
| APIの説明文や入力項目を改善 | エージェント更新と再配布が必要になりやすい | MCPサーバー側のツール定義改善をより速く反映 |
| 不具合のあるツールを一時停止 | 公開済みエージェントとの整合性確認が必要 | MCPサーバー側で退避しやすいが、ユーザー通知は必要 |
開発者にとってはスピード面のメリットがあります。一方で、管理者にとっては「承認済みエージェントだから安全」という一回限りの確認では不十分になります。MCPサーバー上のツールが継続的に変わるため、ツール単位の変更履歴、影響範囲、権限、ログ、ユーザー通知を運用プロセスに組み込む必要があります。
利用者への影響：便利になるが、機能変更に気づきにくくなる
エンドユーザーにとって最大のメリットは、エージェントの機能改善を早く利用できることです。新しい検索ツール、外部システム連携、業務アクションが追加されても、再展開を待つ必要が少なくなります。
一方で、次のような混乱が起きやすくなります。
| 起きやすい問題 | 具体例 | 対策 |
|---|---|---|
| 昨日まで使えた機能が見つからない | 「旧CRM検索」が廃止され、別名のツールに置き換わった | 変更前にユーザー向け告知を出し、会話スターターやヘルプ文を更新する |
| 回答の粒度が変わる | 新しいツールがより詳細なデータを返すようになった | 回答例を社内ポータルに掲載し、期待される使い方を示す |
| 処理結果の確認が不十分になる | チケット作成やデータ更新が自然言語で実行できる | 書き込み系アクションは確認プロンプトや承認手順を必ず確認する |
| 問い合わせが増える | 「Copilotの動きが変わった」とヘルプデスクに連絡が来る | リリースノートをヘルプデスクと共有し、FAQを先に用意する |
特に注意したいのは、検索系ツールと更新系ツールを同じ感覚で扱わないことです。検索や要約は影響が比較的小さい一方、チケット作成、データ更新、メール送信、申請登録などは外部システムに副作用を与えます。Microsoft Learnでは、MCPまたはAPIプラグインをMicrosoft 365 Copilotが初めて使う際にユーザーへ許可確認を行い、GET以外の操作では送信データを示した確認が行われること、また副作用のあるアクションはユーザーが制御できるようにすべきだと説明されています。(Microsoft Learn)
管理者が確認すべき設定とガバナンス
管理者が最初に確認すべきなのは、「どのエージェントが、どのMCPサーバーに接続し、どのユーザーやグループに公開されているか」です。今回の更新では、Microsoftがエンタープライズ向けのRAIとセキュリティ保護に支えられていると説明しつつ、顧客はエージェントの展開とユーザー・グループへの可用性を引き続き制御できるとしています。(Microsoft)
管理者向けチェックリスト
| 確認項目 | 見るべき内容 | 判断基準 |
|---|---|---|
| エージェントの棚卸し | 公開済みの宣言型エージェント、所有者、用途 | 所有者不明のエージェントは本番利用を止めて確認する |
| MCPサーバーの棚卸し | 接続先、管理者、認証方式、障害時連絡先 | 業務重要度が高いサーバーは監視と変更承認を必須にする |
| ツール分類 | 読み取り専用、書き込み、削除、外部送信 | 書き込み・削除・送信系は追加承認と確認プロンプトを確認する |
| 公開範囲 | 全社、部門、検証グループ、管理者のみ | 最初は検証グループに限定し、段階展開する |
| 権限 | Microsoft Entra IDグループ、外部システム側権限 | Copilot側だけでなく、接続元システム側の権限も確認する |
| 監査 | 操作ログ、外部APIログ、ユーザー同意の記録 | 問い合わせ時に「誰が何を実行したか」を追跡できる状態にする |
| 変更通知 | ユーザー通知、ヘルプデスク通知、リリースノート | ツール追加・廃止前に利用者へ変更点を共有する |
Dynamic Tool Discoveryでは、MCPサーバー側の変更が利用体験に直結します。そのため、MCPサーバーのツール定義を「開発者だけが自由に変えられる設定」ではなく、「本番業務に影響する構成情報」として扱うことが重要です。
開発者が注意すべき実装ポイント
開発者にとっては、エージェントの再公開なしにツールを改善できる点が大きな利点です。ただし、動的に見つかるツールほど、ツール名、説明文、入力スキーマ、戻り値、権限、エラー応答を安定させる必要があります。
ツール設計で避けたい失敗
| 失敗しやすいポイント | なぜ問題になるか | 推奨対応 |
|---|---|---|
| ツール名を頻繁に変える | エージェントが意図したツールを選びにくくなる | 既存ツール名は原則維持し、新版は別名またはバージョン管理する |
| 説明文が曖昧 | Copilotがツールの用途を誤解しやすい | 「何を取得するか」「何を変更するか」「使ってはいけない場面」を書く |
| 入力スキーマを破壊的に変更する | 既存プロンプトや自動処理が失敗する | 必須項目の追加は慎重に行い、移行期間を設ける |
| 書き込み系ツールを読み取り系のように説明する | ユーザーが影響を理解せず実行する恐れがある | 副作用の有無を説明文と確認プロンプトに反映する |
| 廃止ツールを突然削除する | ユーザーの定型業務が止まる | 廃止予定、代替ツール、終了日を事前に共有する |
| エラー時の応答が技術的すぎる | 利用者もヘルプデスクも原因を切り分けにくい | 「権限不足」「接続失敗」「入力不足」など業務用語で返す |
Microsoft Learnでは、MCPサーバーから宣言型エージェントへツールを追加する手順の中で、Microsoft 365 Agents Toolkit 6.3.x以降、Visual Studio Code、MCPサーバーURL、OAuth設定などが例示されています。開発環境では、ツールの取得、認証、プロビジョニング、利用テストまでを一連の流れとして確認するのが現実的です。(Microsoft Learn)
Federated Copilot connectorsへの影響
Roadmap ID 561855では、Federated Copilot connectorsへの対応は、宣言型エージェントの後に続く予定とされています。つまり、今回の中心は宣言型エージェントのDynamic Tool Discoveryであり、フェデレーション型Copilotコネクタについては後続対応として見ておく必要があります。(Microsoft)
Federated Copilot connectorsは、MCPを使って外部データにリアルタイムアクセスする仕組みです。Microsoft Learnでは、外部データをMicrosoft 365へインデックス化せず、元の場所に置いたまま最新データを取得できると説明されています。また、ユーザーのIDと権限でアクセスし、Microsoft 365管理センターで管理・ガバナンスできるとされています。(Microsoft Learn)
Synced connectorとの違いは、運用判断で特に重要です。
| 比較項目 | Synced connector | Federated connector |
|---|---|---|
| データの扱い | 外部コンテンツをMicrosoft Graphへ取り込み、インデックス化 | MCPでリアルタイム取得し、Microsoft Graphへインデックス化しない |
| 向いている用途 | 文書庫、ナレッジベース、検索対象として安定した業務データ | 常に最新性が必要なデータ、元システムに置いたまま扱いたいデータ |
| 認証 | 管理者設定やアプリ登録を中心に設計 | ユーザー資格情報を使うケースがある |
| 注意点 | インデックス更新の遅延、スキーマ設計 | 外部システムの可用性、API制限、ユーザー権限、接続先の管理 |
Microsoft 365 Copilot connectorsの概要では、Synced connectorsはMicrosoft Graphへ取り込んでインデックス化し、Federated connectorsはMCPでリアルタイム取得してMicrosoft Graphへ保存しない、と整理されています。(Microsoft Learn)
Federated connectorsを使う組織の管理設定
Federated connectorsをすでに評価している、または今後使う予定がある組織では、管理者向け設定も確認しておくべきです。
Microsoft Learnによると、Federated connectorsはMicrosoft 365管理センターのCopilot connectorsから管理でき、テナントレベルで有効化・無効化したり、Microsoft Entra IDグループに対して段階的に展開したりできます。また、Microsoft公開のFederated connectorが管理センターに初めて表示された場合、ユーザーに利用可能になる前に管理者向けの7日間のレビュー期間があると説明されています。(Microsoft Learn)
全体制御にはPowerShellも使えます。Microsoft Learnでは、Global AdministratorまたはAI Administrator権限、管理者として実行できるPowerShell、Connector.Cmd 2.1以降が前提として示されています。(Microsoft Learn)
Install-Module Connector.Cmd
Set-FederatedConnectorToggleSet-FederatedConnectorToggleでは、すべての既定Federated connectorsを無効化または有効化できます。Microsoft Learnでは、このテナント全体のトグル設定は今後Microsoftがリリースする既定のFederated connectorsにも適用され、変更反映には最大10分かかる場合があると説明されています。(Microsoft Learn)
展開前に決めておくべき運用ルール
Dynamic Tool Discoveryは「早く変更できる仕組み」です。しかし、本番運用では「早く変えられる」ことよりも「安全に変えられる」ことが重要です。次のルールを先に決めておくと、展開後の混乱を減らせます。
ツール変更の承認ルール
MCPサーバー上のツール変更は、少なくとも次の3段階に分けて承認すると運用しやすくなります。
| 変更区分 | 例 | 承認レベル |
|---|---|---|
| 軽微な変更 | 説明文の改善、エラー文言の修正 | 開発チーム内レビュー |
| 中程度の変更 | 入力項目の追加、戻り値の変更、新しい読み取りツールの追加 | エージェント所有者と管理者レビュー |
| 重大な変更 | 書き込み系ツール追加、削除系ツール追加、既存ツール廃止、権限範囲変更 | セキュリティ・業務部門・管理者の承認 |
特に、外部システムにデータを書き込むツールは、テスト環境での検証だけでは不十分です。ユーザーがどのような自然言語で誤操作しやすいか、確認画面に何が表示されるか、取り消し手順があるかまで確認してください。
ユーザー通知のルール
ツールの追加や廃止は、ユーザーから見ると「Copilotの動きが変わった」ように見えます。管理者や開発者が小さな変更だと思っても、現場の定型業務に影響する場合があります。
通知には、次の内容を含めると実用的です。
| 通知項目 | 書く内容 |
|---|---|
| 変更日 | いつから使えるか、いつ廃止されるか |
| 対象者 | 全社、特定部門、検証グループなど |
| 変更内容 | 追加、改善、廃止、名称変更のいずれか |
| 使い方 | 推奨プロンプトや画面上の選択方法 |
| 注意点 | 権限、確認プロンプト、処理対象データ |
| 問い合わせ先 | ヘルプデスク、エージェント所有者、開発チーム |
ロールバックのルール
Dynamic Tool Discoveryでは、MCPサーバー側の変更が早く反映される可能性があります。そのため、不具合時の戻し方もあらかじめ決めておくべきです。
| 障害パターン | 初動対応 |
|---|---|
| 新ツールが誤った結果を返す | ツールを一時停止し、旧ツールへ誘導する |
| 外部APIが不安定 | エージェントの説明に一時的な制限を表示し、代替手順を案内する |
| 権限エラーが多発 | 外部システム側の権限設定とEntra IDグループを確認する |
| 書き込み処理で誤登録が発生 | 監査ログで対象操作を特定し、業務部門と修正手順を実行する |
移行でやるべきこと：既存エージェントの棚卸しから始める
今回の更新は、現時点の公式説明だけを見る限り、すべての組織に即時の移行作業を強制するものではありません。ただし、すでに宣言型エージェントとMCPサーバーを使っている組織は、提供開始前に運用を見直す価値があります。
実務では、次の順番で進めると無理がありません。
| ステップ | 作業 | 成果物 |
|---|---|---|
| 1 | 宣言型エージェントを棚卸しする | エージェント一覧、所有者、公開範囲 |
| 2 | MCPサーバーとツールを棚卸しする | サーバー一覧、ツール一覧、認証方式 |
| 3 | ツールを分類する | 読み取り、書き込み、削除、外部送信の区分 |
| 4 | 変更承認ルールを作る | ツール追加・更新・廃止の承認フロー |
| 5 | 検証グループを決める | Microsoft Entra IDグループ、対象部門 |
| 6 | 監査と問い合わせ対応を整える | ログ確認手順、FAQ、連絡先 |
| 7 | 段階展開する | 管理者検証、部門展開、全社展開 |
この流れで重要なのは、エージェント単位ではなくツール単位で棚卸しすることです。エージェント名だけを見ても、実際にどの外部システムへ接続し、どの操作が可能かは分かりません。MCPサーバー上のツール一覧を管理台帳に入れておくと、後から変更影響を追いやすくなります。
セキュリティとコンプライアンスで確認すべきポイント
Microsoftは、今回のDynamic Tool DiscoveryがエンタープライズRAIとセキュリティ保護に支えられていると説明しています。ただし、組織側のデータ分類、接続先システムの権限、操作ログ、ユーザー教育までMicrosoftが自動的に設計してくれるわけではありません。(Microsoft)
特に確認すべきポイントは次のとおりです。
| 領域 | 確認ポイント |
|---|---|
| 権限 | ユーザーが元システムで見られないデータをCopilot経由で見られないか |
| OAuth同意 | ユーザーまたは管理者の同意範囲が過大でないか |
| データ送信 | 外部サービスへ送るデータに機密情報が含まれないか |
| 監査 | ツール呼び出し、外部API実行、ユーザー操作を追跡できるか |
| DLP・保持 | Microsoft Purviewや既存の情報保護ポリシーと矛盾しないか |
| 障害対応 | MCPサーバー停止時に業務が止まらない代替手順があるか |
| モバイル利用 | モバイル環境で同じ確認・制御が効くか |
Federated connectorsについては、Microsoft Learnが「外部データはMicrosoft 365にコピーまたは保存されない」「権限はソースシステムで適用され、ユーザーは元のデータソースでアクセスできる内容だけを見る」と説明しています。ただし、これはソースシステム側の権限設計が正しいことが前提です。(Microsoft Learn)
開発チームと管理チームの分担を明確にする
Dynamic Tool Discoveryの導入で失敗しやすいのは、開発チームが「サーバー側の更新だから開発の問題」と考え、管理チームが「エージェントは公開済みだから問題ない」と考えるケースです。実際には、両者の役割分担が必要です。
| 役割 | 主な責任 |
|---|---|
| 開発者 | ツール仕様、入力スキーマ、認証、エラー処理、後方互換性、テスト |
| エージェント所有者 | 業務要件、ユーザー向け説明、会話スターター、変更優先度 |
| Microsoft 365管理者 | 公開範囲、グループ展開、コネクタ管理、管理センター設定 |
| セキュリティ担当 | 権限、監査、DLP、外部接続、リスク評価 |
| ヘルプデスク | 問い合わせ対応、FAQ、障害時の一次切り分け |
特にエージェント所有者を明確にすることが重要です。MCPツールの変更は技術的には開発者が行いますが、その変更が業務に適しているかを判断するのは業務側の責任者です。所有者不明のエージェントは、Dynamic Tool Discoveryのような更新と相性が悪くなります。
よくある疑問
エージェントの再公開は完全に不要になるのか
公式情報では、開発者がMCPサーバー上のツールを追加、更新、廃止してもエージェントを再公開せずに最新機能を反映できると説明されています。ただし、エージェント自体の指示、会話スターター、ナレッジ、アイコン、配布設定などを変える場合まで再公開不要と考えるべきではありません。今回の中心はMCPサーバー上のツール検出です。(Microsoft)
すべてのCopilotユーザーにすぐ影響するのか
対象はMicrosoft Copilot（Microsoft 365）の宣言型エージェントと、その後続として予定されるFederated Copilot connectorsです。影響は、組織で該当するエージェントやMCPサーバー連携を使っているか、どのユーザーやグループに公開しているかによって変わります。Microsoftは顧客がエージェントの展開とユーザー・グループへの可用性を制御できると説明しています。(Microsoft)
Federated Copilot connectorsは今すぐDynamic Tool Discovery対象なのか
Roadmap ID 561855では、Federated Copilot connectorsへの対応は宣言型エージェントの後に続く予定とされています。したがって、現時点では宣言型エージェント側の準備を優先し、Federated connectorsについては管理設定、テナントトグル、段階展開、ユーザー権限の確認を先に進めておくのが現実的です。(Microsoft)
まず何から始めるべきか
最初にやるべきことは、既存の宣言型エージェント、MCPサーバー、ツールの棚卸しです。そのうえで、読み取り系と書き込み系を分け、変更承認ルールとユーザー通知ルールを作ります。Federated connectorsを利用する予定がある場合は、Microsoft 365管理センターとPowerShellによるテナント全体の制御も確認してください。(Microsoft Learn)
まとめ：Dynamic Tool Discoveryは「開発の高速化」ではなく「継続的なツール管理」への転換
Microsoft 365 CopilotのDynamic Tool Discoveryは、宣言型エージェントのMCPツール運用を大きく効率化する更新です。開発者はエージェントの再公開を待たずにMCPサーバー上のツールを追加、更新、廃止でき、ユーザーは新しい機能をより早く使えるようになります。(Microsoft)
一方で、ツール変更が早く反映されるほど、管理者と開発者には継続的なガバナンスが求められます。公開範囲、権限、監査、ユーザー通知、ロールバック手順を整えないまま本番展開すると、「便利になったのに現場が混乱する」状態になりかねません。
次に取るべき行動は明確です。まず、自社の宣言型エージェントとMCPサーバーを棚卸しし、ツールを読み取り系・書き込み系・廃止予定に分類してください。その後、検証グループで段階展開し、ヘルプデスク向けFAQと変更通知を用意します。Federated Copilot connectorsを使う予定がある場合は、管理センターでのコネクタ管理とPowerShellによるテナント全体制御も合わせて確認しておくと、今後の展開に備えやすくなります。
コメント