Microsoft Copilot Studioで作成するエージェントのワークフローに、MCP（Model Context Protocol）準拠ツールを組み込めるようになります。要点は、社内システム、動的なナレッジソース、独自アクションを個別に作り込むのではなく、MCPサーバー経由で再利用しやすくなることです。Microsoft 365 Roadmap ID 562221では、対象製品が「Microsoft Copilot（Microsoft 365）」と「Microsoft Copilot Studio」、対象クラウドがWorldwide、プラットフォームがWeb、ステータスがIn development、プレビューが2026年5月、一般提供が2026年6月とされています。ロードマップAPI上の作成・更新時刻は2026年5月15日18:00 UTCで、日本時間では2026年5月16日です。(Microsoft)
この更新は、Microsoft 365 Copilotの利用者にとっては「Copilotから実行できる業務アクションが増える」可能性がある一方、管理者と開発者にとっては、DLP、認証、接続先、容量、監視、展開手順を見直すべき変更です。特に、MCPサーバーを追加すると複数のツールやリソースがエージェントから利用可能になるため、「便利だから接続する」ではなく、「どのエージェントが、どの権限で、どのツールを呼べるのか」を先に設計することが重要です。
Microsoft Copilot StudioのMCP対応で何が変わるのか
今回の「Use MCP-compliant tools in agent workflows」は、Microsoft Copilot Studioのエージェントワークフローで、MCP準拠ツールやナレッジサーバーをワークフローのステップとして検出・呼び出せるようにする機能です。Microsoftのリリース計画では、エージェントワークフローがMCPツールへ構造化された入力を渡し、その出力を後続処理で使えるため、エージェント拡張機能をより決定的なワークフローに組み込めると説明されています。(Microsoft Learn)
従来、社内API、SaaS、基幹システム、独自ナレッジをエージェントから使うには、個別のコネクタ、カスタムアクション、Power Automateフロー、API連携を用途ごとに作ることが多くなりがちでした。MCP対応が進むと、ひとつのMCPサーバーに複数のツールやリソースをまとめ、複数のエージェントやワークフローで再利用する設計がしやすくなります。Microsoftは、この機能により統合の重複を減らし、エージェントとワークフロー横断で再利用性を高める狙いを示しています。(Microsoft)
ただし、ロードマップ情報は予定であり、リリース時期や内容は変更される可能性があります。Microsoft 365 Roadmap自体も、商用機能の予定日と説明は変更される場合があると明記しています。(Microsoft)
公式情報から見た更新内容の整理
| 項目 | 公式情報の内容 | 実務上の見方 |
|---|---|---|
| 機能名 | Microsoft Copilot Studio: Use MCP-compliant tools in agent workflows | Copilot StudioのワークフローからMCP準拠ツールを使う機能 |
| 対象製品 | Microsoft Copilot（Microsoft 365）、Microsoft Copilot Studio | Microsoft 365 Copilotに公開されるエージェントにも影響し得る |
| 対象環境 | Worldwide（Standard Multi-Tenant） | まず商用標準テナントで確認すべき更新 |
| プラットフォーム | Web | Copilot StudioのWeb管理・作成画面での対応が中心 |
| リリース段階 | Preview、General Availability | 検証環境で先に試し、業務展開は管理方針に合わせて判断 |
| 予定時期 | Preview: 2026年5月、GA: 2026年6月 | テナントのMessage CenterとRoadmapを併せて確認 |
| ステータス | In development | 仕様・日程の変更に注意 |
今回のポイントは「MCPという新しい接続方式が追加される」だけではありません。エージェントのワークフロー内で、外部システム呼び出し、動的な情報取得、カスタムアクションをより再利用しやすい形で扱えるようになる点が実務上の価値です。(Microsoft)
MCPとは何か：Copilot Studioでの位置づけ
MCPは、Copilot Studio内のエージェントを既存のナレッジサーバーやデータソースに接続するためのプロトコルです。Microsoft Learnでは、MCPサーバーに接続すると、エージェントが読み取れる「リソース」、言語モデルがアクション実行のために呼び出せる「ツール」、タスク用の「プロンプト」にアクセスできると説明されています。現時点のCopilot Studioでは、MCPツールとリソースがサポート対象です。(Microsoft Learn)
Copilot Studioでは、接続済みMCPサーバーが公開するツールやリソースが自動的に利用可能になります。MCPサーバー側のツールやリソースが更新・削除されると、その変更はCopilot Studioにも動的に反映されます。これは便利な一方で、MCPサーバー側の変更がエージェントの動作に直接影響することを意味します。(Microsoft Learn)
また、MCPを使うには生成オーケストレーションを有効にする必要があります。MCPを導入しても、エージェント側のオーケストレーション設計が不十分だと、意図しないツール呼び出しや不要な外部アクセスが発生する可能性があります。(Microsoft Learn)
影響を受ける利用者・管理者・開発者
利用者への影響
一般利用者にとっては、Microsoft 365 CopilotやCopilot Studioで公開されたエージェントが、より多くの業務システムと連携できるようになる可能性があります。
たとえば、次のような使い方が想定されます。
- 顧客名を入力すると、CRMや契約管理システムから最新の契約状況を取得する
- 注文番号を指定すると、在庫、配送、請求の状態をまとめて確認する
- 社内規程の質問に対し、静的なFAQだけでなく最新の承認ルールやワークフロー状態を参照する
- 問い合わせ内容に応じて、チケット作成、担当者割り当て、通知送信まで実行する
利用者側のメリットは、Copilot上の自然な会話から業務アクションへつなげやすくなることです。ただし、エージェントがどのデータを参照し、どの操作を実行できるのかは、管理者と作成者の設計に依存します。
管理者への影響
管理者は、MCPを「新しい外部接続経路」として扱う必要があります。Microsoft Learnでは、Copilot Studioのデータポリシーによって、エージェントが組織内外のデータやサービスへどのように接続・操作できるかを管理できると説明されています。Power Platform管理センターでCopilot StudioやPower Platformのデータポリシーを構成することが前提です。(Microsoft Learn)
特に注意すべきなのは、MCPサーバーへのアクセスがPower Platformコネクタに依存する点です。Microsoft Learnでは、Power Platformコネクタをブロックすると、接続されたMCPサーバー内のツールへのアクセスもブロックされると説明されています。(Microsoft Learn)
開発者・作成者への影響
開発者やエージェント作成者は、単にMCPサーバーを接続するだけでなく、ツール名、説明、入力、出力、認証方式、エラー時の挙動を明確に設計する必要があります。
Copilot StudioのMCPオンボードウィザードでは、サーバー名、説明、URLを入力します。Microsoft Learnでは、サーバーの説明はエージェントオーケストレーターが実行時にサーバーを呼び出すべきか判断するために使われると説明されています。曖昧な説明は誤呼び出しの原因になります。(Microsoft Learn)
MCP、Power Platformコネクタ、ナレッジソースの使い分け
MCPが使えるようになると、「既存のコネクタやナレッジソースは不要になるのか」と考えがちですが、そうではありません。用途に応じて使い分けることが大切です。
| 選択肢 | 向いている用途 | 注意点 |
|---|---|---|
| ナレッジソース | FAQ、社内規程、製品マニュアルなど、主に回答生成に使う情報 | 更新頻度が高い業務データや実行アクションには向かない場合がある |
| Copilotコネクタ | Microsoft Graphへ外部データを取り込み、Microsoft 365全体で検索・活用したい情報 | インデックス設計、権限、更新間隔を考慮する |
| Power Platformコネクタ | APIをリアルタイムに呼び出し、読み取り・書き込み・アクションを実行したい業務処理 | DLP、接続、環境単位の管理が必要 |
| MCPサーバー | 複数のツールやリソースをまとめ、複数エージェントやワークフローで再利用したい処理 | ツールの公開範囲、認証、変更管理を厳密に設計する必要がある |
Microsoft Learnでは、Copilotコネクタは非MicrosoftデータをMicrosoft Graphにインデックスして広く検索・セマンティックグラウンディングに使う方式、Power Platformコネクタは実行時にAPIを呼び出して最新データやトランザクションに適した方式として説明されています。(Microsoft Learn)
判断基準はシンプルです。読むだけの知識ならナレッジソース、Microsoft 365全体で検索したい外部情報ならCopilotコネクタ、特定APIのリアルタイム操作ならPower Platformコネクタ、複数ツールを標準化してエージェント横断で使いたいならMCPを検討します。
管理者が確認すべき設定
DLPとデータポリシー
最初に確認すべきなのは、Power Platform管理センターのデータポリシーです。Copilot Studioでは、コネクタをBusiness、Non-business、Blockedに分類し、組織データの意図しない持ち出しを防ぐために利用できます。Microsoft Learnでは、データポリシー違反がリアルタイムに適用され、作成者やユーザーにエラーが表示されると説明されています。(Microsoft Learn)
MCP導入前に、少なくとも次を確認してください。
| 確認項目 | 確認する理由 |
|---|---|
| MCPサーバー接続に使うコネクタの分類 | BusinessとNon-businessの混在でデータ共有がブロックされる可能性がある |
| Power Platformコネクタのブロック設定 | ブロックされるとMCPサーバーツールも使えない可能性がある |
| HTTPリクエストの許可・拒否 | 外部エンドポイントへの不要な接続を防ぐ |
| Microsoft 365 / Teamsチャネルへの公開可否 | エージェントをどこに公開できるかを制御する |
| イベントトリガーの制限 | 人が操作しなくても動く処理によるデータ流出や容量消費を防ぐ |
| 認証なしチャットの禁止 | 外部公開や匿名利用によるリスクを下げる |
MCPは「接続できるようになったら終わり」ではありません。むしろ、接続後にどのデータ境界を越えるかを管理することが本題です。
認証方式
Copilot Studioから既存のMCPサーバーへ接続する方法として、Microsoft LearnではMCPオンボードウィザードの利用が推奨されています。認証方式としては、認証なし、APIキー、OAuth 2.0が選択肢として示されています。OAuth 2.0では、動的検出、動的、手動の構成方式があります。(Microsoft Learn)
実務では、次のように判断すると失敗しにくくなります。
| 認証方式 | 向いている場面 | 注意点 |
|---|---|---|
| 認証なし | 検証用、社内閉域の限定テスト | 本番利用ではデータ漏えいリスクを慎重に評価する |
| APIキー | 単純なサーバー認証、PoC | 利用者ごとの権限差を表現しにくい |
| OAuth 2.0 | ユーザー権限でデータを扱う業務システム連携 | スコープ、同意、トークン更新、失効時の動作を設計する |
顧客情報、人事情報、契約情報、チケット情報など、ユーザーによって見える範囲が異なるデータを扱う場合は、ユーザー単位の認可を表現できる設計を優先すべきです。
対応トランスポート
MCPではクライアントとサーバーの通信方式としてトランスポートが使われます。Copilot Studioは現在、Streamable transport typeをサポートしており、SSE transportは2025年8月以降サポートされないとMicrosoft Learnに記載されています。(Microsoft Learn)
既存のMCPサーバーを流用する場合は、次を確認してください。
| 確認項目 | 実務上のチェック |
|---|---|
| Streamable対応 | Copilot Studioから接続できる形式か |
| SSE前提の実装 | そのままでは利用できない可能性がある |
| HTTPS/TLS | 本番で安全に通信できるか |
| タイムアウト | 長時間処理がワークフローを詰まらせないか |
| 再試行 | 重複実行しても問題ない設計か |
| ログ | いつ誰がどのツールを呼んだか追跡できるか |
容量と実行コスト
エージェントワークフローは、実行するアクションごとにCopilot Studio容量を消費します。Microsoft Learnでは、環境の前払い済みCopilot Studio容量を使い切ると、新しいエージェントフローまたはワークフロー実行が容量利用可能になるまでブロックされると説明されています。一方、デザイナーやテストチャットからのテスト実行は容量を消費しないとされています。(Microsoft Learn)
MCPツールをワークフローに組み込むと、便利さの反面、呼び出し回数が増える可能性があります。特に、ユーザーの質問ごとに複数ツールを連続実行する設計では、容量、応答時間、外部API制限の影響を受けやすくなります。
本番展開前に、1回の会話で何回MCPツールが呼ばれるか、ピーク時に何人が利用するか、失敗時に再試行が何回走るかを見積もってください。
開発者が設計時に確認すべきポイント
ツール名と説明は「人間向け」ではなく「オーケストレーター向け」に書く
MCPサーバーのツール説明が曖昧だと、エージェントが適切なタイミングでツールを選べません。
悪い例は「顧客データを取得する」です。何を入力し、何を返し、いつ使うべきかが分かりません。
良い例は「顧客IDを入力として受け取り、契約ステータス、最終更新日、担当営業IDを返す。顧客名のみでは呼び出さない」です。
このように、ツール説明には次を含めると安定します。
- 何をするツールか
- 必須入力は何か
- 返す値は何か
- 使ってはいけない場面
- 書き込み処理か読み取り処理か
- 承認が必要な処理か
入力と出力は構造化する
今回の機能では、エージェントワークフローがMCPツールへ構造化入力を渡し、構造化出力を後続処理で利用できることが重要な価値です。自由文だけで連携すると、後続の条件分岐、承認、通知、監査が不安定になります。(Microsoft Learn)
たとえば、契約確認ツールなら、出力は「契約あり/なし」「契約終了日」「更新要否」「リスク区分」のようにワークフローで使える項目に分けます。文章の要約だけを返すより、後段の処理が安定します。
すべてのツールを有効にしない
MCPサーバーをエージェントに追加すると、初期状態ではすべてのツールが有効になる設計があります。Microsoft Learnでは、Allow allをオフにして個別ツールを無効化でき、Allow allをオフにした場合はMCPサーバーに後から追加された新しいツールが既定でオフになると説明されています。(Microsoft Learn)
本番エージェントでは、必要なツールだけを有効化するのが安全です。たとえば、問い合わせ回答エージェントに「顧客情報の参照」は必要でも、「契約変更」「返金処理」「アカウント停止」は不要な場合があります。
リソースはツールの出力として扱えるようにする
MCPサーバーがリソースを持っていても、エージェントが使える形になっていなければ活用できません。Microsoft Learnでは、Copilot Studioエージェントがリソースを使用するには、MCPサーバー所有者がそのリソースをMCPツールの出力として構成する必要があると説明されています。(Microsoft Learn)
社内文書、API応答、ファイル内容を使わせたい場合は、「リソースが存在する」だけでなく、「どのツールのどの出力として返すか」まで設計してください。
破壊的変更を避ける
MCPサーバーのツールやリソースの変更はCopilot Studioに動的に反映されます。これは、古いツールをすばやく廃止できる利点がある一方で、既存ワークフローの入力・出力が変わると障害につながるリスクもあります。(Microsoft Learn)
次のような変更は特に注意が必要です。
| 変更内容 | 起きやすい問題 | 推奨対応 |
|---|---|---|
| 入力項目名の変更 | ワークフローから値が渡らない | 新旧パラメーターを一定期間併存 |
| 出力形式の変更 | 条件分岐や後続処理が失敗 | バージョン付き出力を用意 |
| ツール名の変更 | エージェントがツールを選べない | 旧名を非推奨化して段階移行 |
| ツール削除 | 本番エージェントが実行不能 | 影響エージェントの棚卸し後に削除 |
| 権限スコープ変更 | 利用者ごとに失敗が増える | 事前告知と再同意フローを準備 |
移行・展開の進め方
まず既存連携を棚卸しする
MCP対応が入ったからといって、既存のPower PlatformコネクタやPower Automateフローをすぐ移行する必要はありません。まず、現在エージェントやフローで使っている外部連携を一覧化します。
棚卸しでは、次を確認します。
| 棚卸し項目 | 確認内容 |
|---|---|
| 接続先システム | CRM、ERP、チケット管理、在庫管理、社内DBなど |
| 連携方式 | Power Platformコネクタ、HTTP、カスタムコネクタ、Power Automateなど |
| 操作種別 | 読み取り、書き込み、承認、通知、削除 |
| 利用エージェント | どのエージェント・ワークフローが使っているか |
| 権限 | ユーザー権限か、共有接続か、サービスアカウントか |
| 監査要件 | 誰がいつ何を実行したか記録が必要か |
| 障害時影響 | 業務停止につながるか、回答品質低下に留まるか |
MCP化の候補は、複数エージェントで重複している連携、複数ツールをまとめて提供したい領域、今後変更が多い社内APIです。単発の処理や既存コネクタで安定している処理は、無理に移行しない方がよい場合もあります。
検証環境でMCPサーバーを追加する
既存のMCPサーバーがある場合、Copilot StudioではMCPオンボードウィザードで追加する方法が推奨されています。まだMCPサーバーがない場合は、新規作成やカスタムコネクタ経由の構成も選択肢になります。(Microsoft Learn)
検証環境では、次の順番で確認します。
| 手順 | 作業 | 合格基準 |
|---|---|---|
| 1 | MCPサーバーを登録 | 接続エラーが出ない |
| 2 | 認証方式を設定 | 想定ユーザーで認証できる |
| 3 | エージェントに追加 | ToolsタブにMCPサーバーが表示される |
| 4 | 必要ツールだけ有効化 | 不要な書き込み系ツールが無効 |
| 5 | ワークフローに組み込む | 構造化入力・出力が使える |
| 6 | DLP確認 | データポリシー違反がない |
| 7 | エラー試験 | 認証失敗、API失敗、タイムアウト時の挙動が分かる |
| 8 | 負荷・容量確認 | 想定利用量で容量や外部API制限に収まる |
プレビュー段階では本番依存を避ける
Copilot Studioのワークフロー関連ドキュメントでは、プレビュー機能は変更される可能性があり、本番利用を目的としたものではないと説明されています。(Microsoft Learn)
プレビュー段階で行うべきことは、本番業務を全面移行することではなく、次の検証です。
- 既存エージェントのどの連携がMCP化に向いているか確認する
- DLPや環境ポリシーで想定どおり制御できるか確認する
- 監査ログやエラー情報から原因追跡できるか確認する
- 利用者の質問から適切なツールが呼ばれるか確認する
- 1回の会話でのツール呼び出し回数と応答時間を測る
本番展開は、Message Center、Roadmap、Microsoft Learnの更新状況を確認し、管理ポリシーと運用手順が整ってから進めるのが安全です。
失敗しやすいポイントと対策
| 失敗しやすいポイント | 何が起きるか | 対策 |
|---|---|---|
| MCPサーバーを広く作りすぎる | エージェントが不要なツールまで呼べる | エージェントごとに必要ツールだけ有効化する |
| ツール説明が曖昧 | 誤ったツール選択や呼び出し漏れが起きる | 入力、出力、利用条件、禁止条件を明記する |
| DLPを後回しにする | 公開時にエラー、または本番で動かない | 検証初期からPower Platformデータポリシーを確認する |
| APIキーを共有接続にする | 利用者ごとの権限制御が弱くなる | ユーザー別データはOAuth 2.0を優先する |
| SSE前提のMCPサーバーを使う | Copilot Studioで接続できない可能性がある | Streamable対応を確認する |
| 出力が自由文だけ | 後続ワークフローで条件分岐できない | JSONなど構造化された出力にする |
| 容量見積もりをしない | 利用拡大時に実行がブロックされる | アクション数、再試行数、利用者数を見積もる |
| MCPサーバー側を無告知で変更 | 既存ワークフローが壊れる | バージョン管理と段階的廃止を行う |
| 外部MCPサーバーの責任範囲が曖昧 | データ漏えい・監査不足のリスクが残る | 接続先、ログ、権限、契約条件を事前確認する |
業務シナリオ別の活用例
社内問い合わせエージェント
人事、総務、情報システムの問い合わせエージェントでは、静的なFAQだけでなく、申請状況やユーザー属性に応じた回答が求められます。
MCPサーバーに「申請ステータス取得」「対象規程取得」「承認者取得」などのツールをまとめると、複数部門のエージェントで同じ基盤を再利用できます。ただし、人事情報を扱う場合は、利用者本人の権限で参照できる範囲に絞る必要があります。
営業支援エージェント
営業担当がMicrosoft 365 Copilot上で「この顧客の次の打ち手を整理して」と依頼したときに、CRM、契約管理、サポート履歴から情報を取得できると、提案準備が速くなります。
この場合、MCPサーバーには「顧客サマリー取得」「契約一覧取得」「未解決チケット取得」などの読み取り系ツールを用意します。書き込み系の「商談更新」「見積作成」は、承認や確認ステップを挟むワークフローに分けると安全です。
IT運用エージェント
IT運用では、インシデント管理、資産管理、アカウント管理、監視ツールなど複数システムを横断します。
MCPサーバーに「端末情報取得」「チケット作成」「影響ユーザー取得」「ナレッジ検索」などを集約すれば、エージェントが一次切り分けを支援できます。ただし、アカウント停止、権限変更、設定変更のような高リスク操作は、人間の承認を必須にする設計が望ましいです。
カスタマーサポートエージェント
顧客対応では、注文状況、配送状況、契約プラン、過去問い合わせを参照する必要があります。
MCPサーバーを使えば、サポート担当者向けエージェントが複数の業務システムから情報を取得し、回答案や次の対応を提示できます。返金、契約変更、配送先変更などの実行処理は、本人確認や承認ログを残すワークフローに接続する必要があります。
FAQ
MCP対応でMicrosoft 365 Copilotの利用者は何か設定が必要ですか
通常、一般利用者がMCPサーバーを直接設定するわけではありません。Copilot Studioの作成者や管理者がMCPサーバーをエージェントに追加し、必要なツールを有効化して公開します。利用者は、公開されたエージェントをMicrosoft 365 CopilotやTeamsなどの許可されたチャネルから使う形になります。
既存のPower AutomateフローはMCPに移行すべきですか
すべて移行する必要はありません。既に安定しており、単一の業務処理として完結しているPower Automateフローは、そのまま維持する方が安全な場合があります。MCP化に向いているのは、複数エージェントで重複している連携、複数ツールをまとめて提供したいAPI群、今後エージェント横断で再利用したい業務機能です。
MCPサーバーを追加すれば、エージェントは自動で賢くなりますか
自動で業務品質が上がるわけではありません。MCPサーバーはツールやリソースへの接続口を提供しますが、どのツールをいつ呼ぶか、出力をどう使うか、失敗時にどう返すかはエージェントとワークフローの設計次第です。
外部MCPサーバーを使うときの責任は誰にありますか
Microsoft Learnでは、外部MCPサーバーを含むMicrosoft以外の製品に接続する場合、Copilot Studio内からアクセスするツールとリソースについては利用側が責任を持つと説明されています。外部MCPサーバーを使う場合は、データ保護、認証、ログ、契約、障害対応を事前に確認してください。(Microsoft Learn)
本番展開前に最低限確認することは何ですか
最低限、次の5点を確認してください。
- Power PlatformデータポリシーでMCP関連コネクタが適切に許可・制限されている
- 認証方式が業務データの権限要件に合っている
- 不要なMCPツールがエージェントで無効化されている
- ワークフローの入力・出力が構造化され、エラー時の分岐がある
- 容量、監視、ログ、変更管理の運用手順が決まっている
管理者と開発者が次にやるべきこと
今回のMicrosoft Copilot StudioのMCP対応は、Microsoft 365 Copilotのエージェントをより業務システムに近づける更新です。社内システム、動的ナレッジ、カスタムアクションをMCPサーバーとして再利用できれば、エージェントごとに同じ連携を作り直す負担を減らせます。
一方で、MCPサーバーは複数のツールやリソースをまとめて提供できるため、権限設計を誤ると影響範囲も広がります。まずは既存連携を棚卸しし、MCP化すべき領域を選び、検証環境でDLP、認証、ツール選択、容量、監視を確認してください。
管理者は「接続を許可するか」だけでなく、「どのエージェントに、どのMCPツールを、どのユーザー権限で使わせるか」を定義する必要があります。開発者は、MCPサーバーを単なるAPI集合にせず、エージェントが安全に選択できるツール名、説明、入力、出力、バージョン管理を設計しましょう。
コメント