Microsoft Copilot StudioのMCPサーバー連携では、既存のModel Context Protocol（MCP）サーバーをエージェントの「ツール」として追加し、サーバーが提供するツールやリソースをエージェントから利用できるようになります。2026年5月16日に更新された公式情報で特に重要なのは、追加時点ではMCPサーバー内の全ツールが既定で有効になること、そしてPower PlatformのデータポリシーがMCPサーバー経由のアクセスにも影響することです。管理者はDLP・認証・環境スコープを確認し、開発者はMCPサーバー側のツール定義、リソースの出力設定、不要なツールの無効化を本番展開前に必ず確認する必要があります。(Microsoft Learn)
Microsoft Copilot StudioのMCPサーバー連携で何が変わるのか
Microsoft Copilot Studioでは、MCPサーバーをエージェントに追加することで、外部システムの機能やデータをエージェントから扱いやすくなります。MCPは、AIエージェントが外部のツール、データソース、ユーザー環境と一貫した方法でやり取りするためのインターフェースとして説明されています。(Microsoft Learn)
今回の「Add tools and resources from a Model Context Protocol (MCP) server to your agent」で整理されている中心は、接続済みのMCPサーバーを、Copilot Studioのエージェントにツールとして追加する手順と運用上の注意点です。
従来のAPI連携では、エージェントごとにアクションや入力項目を細かく定義し、API仕様が変わるたびに個別調整が必要になることがあります。一方、MCPサーバーを使うと、サーバー側が公開するツール名、説明、入力、出力をCopilot Studio側で利用できます。MCPサーバー上でツールやリソースが更新・削除された場合、Copilot Studioにも動的に反映されるため、複数のエージェントで同じ連携基盤を使う構成に向いています。(Microsoft Learn)
ただし、便利になった分だけ、エージェントが使える外部機能の範囲も広がります。特に、顧客情報、社内文書、チケット管理、営業データ、メール、Dataverseなどに接続するMCPサーバーでは、「追加できるか」だけでなく「どのツールを使わせるか」「誰の権限で実行されるか」「データポリシーで制御できているか」を確認することが重要です。
2026年5月16日更新の主なポイント
2026年5月16日に更新された公式ページでは、接続済みMCPサーバーをエージェントに追加する流れ、ツールとリソースの確認方法、個別ツールの有効・無効化、データポリシーとの関係が説明されています。(Microsoft Learn)
| 確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| MCPサーバーの追加方法 | エージェントのToolsページからModel Context Protocolを選び、利用するMCPコネクタを追加する | 既存のMCPサーバーやMicrosoftの事前構築済みMCPコネクタをエージェントに組み込める |
| ツールとして表示 | MCPサーバーはエージェントのToolsタブにツールとして表示される | 管理対象が「個別API」ではなく「MCPサーバー単位」になる |
| ToolsとResourcesの確認 | MCPサーバーが提供するツール名・説明、リソース名・説明を確認できる | どの機能やデータがエージェントに見えているかを展開前に確認できる |
| 既定では全ツールが有効 | MCPサーバー追加時はAllow allがオンになり、全ツールが有効になる | 不要な操作系ツールまで使える可能性があるため、最小権限の観点で見直しが必要 |
| 個別ツールの無効化 | Allow allをオフにすると、ツールごとにオン・オフを切り替えられる | エージェントの用途に合わないツールを除外できる |
| データポリシーの影響 | MCPサーバーへのアクセスはPower Platformコネクタに依存する | Power PlatformのDLP・データポリシー設定がMCP連携にも影響する |
特に見落としやすいのは、Allow allをオフにした後にMCPサーバーへ新しいツールが追加された場合、その新規ツールは既定でオフになるという点です。これは安全側の挙動ですが、機能追加後に「エージェントから新機能が使えない」と見える原因にもなります。(Microsoft Learn)
MCPサーバーをエージェントに追加する基本手順
Copilot Studioで接続済みのMCPサーバーをエージェントに追加する流れは、次のとおりです。公式手順では、Microsoftの事前構築済みMCPコネクタを追加する場合も、自分で接続設定したMCPサーバーを追加する場合も、基本的な流れは同じです。(Microsoft Learn)
| 手順 | 操作 | 確認すべきこと |
|---|---|---|
| 1 | 対象エージェントのToolsページを開く | 本番エージェントではなく、まず検証用エージェントで試す |
| 2 | Add a toolを選択する | 追加先の環境が正しいか確認する |
| 3 | Model Context Protocolを選択する | 利用可能なMCPコネクタ一覧が表示される |
| 4 | 追加したいMCPコネクタを選択する | サーバー名と説明が用途に合っているか確認する |
| 5 | 必要な認証情報を入力して承認する | API key、OAuth 2.0など認証方式に応じて確認する |
| 6 | Add and configureを選択する | 追加後に設定ページでツールとリソースを確認する |
追加後、MCPサーバーはエージェントのToolsタブに表示されます。そこから設定ページを開くと、通常のツール詳細に加えて、MCP固有の「Tools」と「Resources」を確認できます。(Microsoft Learn)
実務では、追加直後にそのまま公開するのではなく、少なくとも次の3点を確認してください。
- エージェントの目的に合わないツールが有効になっていないか
- 説明文が曖昧で、オーケストレーターが誤って呼び出しそうなツールがないか
- リソースがツールの出力として正しく返されるようにMCPサーバー側で構成されているか
MCPのToolsとResourcesの違いを理解する
MCPサーバーを安全に使うには、「Tools」と「Resources」の違いを理解しておく必要があります。
Copilot StudioのMCPでは、Toolsはエージェントが呼び出せる関数のようなものです。たとえば「顧客情報を検索する」「チケットを作成する」「在庫を確認する」「承認ワークフローを開始する」といった処理が該当します。
Resourcesは、エージェントが文脈として読み取れるファイル状のデータです。APIレスポンス、ファイル内容、データベースレコードのような情報が例として挙げられています。Copilot Studioは現在、MCPのToolsとResourcesをサポートしています。(Microsoft Learn)
| 種別 | 役割 | 例 | 注意点 |
|---|---|---|---|
| Tools | エージェントが実行する機能 | 顧客検索、チケット登録、GitHub Issue作成、Dataverseレコード取得 | 誤実行や過剰権限に注意 |
| Resources | エージェントが参照するデータ | APIレスポンス、ファイル内容、レコード情報 | Copilot Studioで使うには、MCPサーバー側でツールの出力として構成する必要がある |
| Prompts | 事前定義されたプロンプトテンプレート | 特定タスク向けの指示テンプレート | 公式情報ではCopilot Studioは現在ToolsとResourcesをサポートするとされている |
重要なのは、Resourcesが一覧に見えていても、それだけでエージェントが自由に利用できるとは限らない点です。公式情報では、Copilot Studioのエージェントがリソースを使用するには、MCPサーバー所有者がそのリソースをMCPツールの出力として構成する必要があると説明されています。(Microsoft Learn)
たとえば、社内ナレッジ検索MCPサーバーを作る場合、単に「FAQリソース」を公開するだけではなく、「FAQを検索するツール」の出力として該当リソースを返す設計にしておく必要があります。ここを誤ると、設定画面ではリソースが確認できても、実際の会話では期待した回答に使われない可能性があります。
既定で全ツールが有効になる点に注意
MCPサーバーをエージェントに追加すると、既定ではAllow allがオンになり、MCPサーバーが提供するすべてのツールが有効になります。(Microsoft Learn)
これは検証時には便利ですが、本番運用ではリスクになります。たとえば、次のようなMCPサーバーを追加するケースを考えてみます。
- 顧客情報を検索するツール
- 顧客情報を更新するツール
- 契約情報を取得するツール
- 契約ステータスを変更するツール
- 社内通知を送信するツール
- 外部チケットを作成するツール
問い合わせ対応エージェントに必要なのは「検索」と「参照」だけかもしれません。それにもかかわらず、更新、送信、作成系のツールまで有効なままにすると、誤操作や想定外の自動実行につながる可能性があります。
本番公開前は、Allow allをオフにし、エージェントの役割に必要なツールだけを有効にするのが安全です。
ツール選定の判断基準
| 判断項目 | 有効にしてよい例 | 無効化を検討すべき例 |
|---|---|---|
| エージェントの目的に直結するか | サポートエージェントのFAQ検索、注文状況確認 | サポート用途なのに契約変更や返金処理ができる |
| 読み取り専用か、書き込みを伴うか | 顧客情報の参照、在庫照会 | レコード更新、削除、送信、承認、決済 |
| 誤実行時の影響が小さいか | 一覧取得、候補提示 | 外部メール送信、チケット大量作成、権限変更 |
| ユーザー権限と整合するか | ユーザー本人のデータだけ参照 | 認証ユーザーの範囲を超えた全社データ参照 |
| ログで追跡できるか | 実行履歴や監査ログで確認できる | 実行者や入力値を追跡しづらい |
MCPサーバーは複数のツールをまとめて管理できるため、開発効率は上がります。一方で、エージェント単位で「どの機能まで許可するか」を丁寧に設計しないと、MCPサーバーの便利さがそのまま権限過多につながります。
管理者が確認すべきデータポリシーとガバナンス
Copilot StudioにおけるMCPサーバーへのアクセスは、Power Platformコネクタに依存します。そのため、Power Platformコネクタを制御するデータポリシーは、MCPサーバーとそのツールへのアクセスにも影響します。(Microsoft Learn)
管理者が最初に確認すべきなのは、Power Platform管理センターのデータポリシーです。Copilot Studioのデータポリシーでは、コネクタをBusiness、Non-business、Blockedなどのデータグループに分類できます。また、データポリシー違反はリアルタイムで適用され、作成者やユーザーにエラーメッセージが表示されます。(Microsoft Learn)
管理者向けチェックリスト
| 確認項目 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| 対象環境 | MCP連携を許可する環境と禁止する環境を分けているか | 検証用の緩い設定が本番に影響する |
| コネクタ分類 | MCPサーバーに関係するコネクタが適切なデータグループにあるか | 業務データが外部サービス側へ流れる可能性 |
| Blocked設定 | 利用禁止のコネクタや外部接続がブロックされているか | 作成者が意図せず危険な連携を追加できる |
| 認証要件 | エージェントにMicrosoft認証や適切な手動認証を求めているか | 匿名ユーザーが機密データに触れる可能性 |
| 公開前検証 | データポリシー違反時にPublishが止まるか確認したか | 公開後に利用者側でエラーが発生する |
| 管理者連絡先 | エラー時に作成者が問い合わせる窓口を把握しているか | 現場が原因を特定できず展開が止まる |
特に、MCPサーバーが外部SaaSや自社APIを経由して機密情報にアクセスする場合は、単にMCPの設定画面だけを見るのでは不十分です。Power Platform側のDLP、Microsoft Entra IDの認証、MCPサーバー側の認可、外部サービス側の権限設計をセットで確認してください。
開発者が確認すべきMCPサーバー側の設定
開発者は、Copilot StudioにMCPサーバーを追加できるかだけでなく、エージェントが正しくツールを選択できるようにサーバー側の定義を整える必要があります。
Copilot Studioでは、MCPサーバーが公開するツールやリソースの名前、説明、入力、出力が利用されます。つまり、ツール説明が曖昧だと、エージェントが適切なタイミングで呼び出せない、または本来不要な場面で呼び出す可能性があります。(Microsoft Learn)
ツール定義で意識すべきポイント
| 項目 | 悪い例 | 良い例 |
|---|---|---|
| ツール名 | processData | searchCustomerByEmail |
| 説明 | 「データを処理します」 | 「メールアドレスを使って顧客の基本情報を検索します。更新や削除は行いません」 |
| 入力 | id, valueだけで意味が不明 | customerEmail, ticketId, orderNumberなど用途が分かる |
| 出力 | 生のAPIレスポンスをそのまま返す | エージェントが回答に使いやすい項目名と形式で返す |
| 権限 | 参照・更新・削除を1つのツールにまとめる | 参照用、更新用、削除用を分けて制御する |
また、Copilot Studioで既存MCPサーバーへ接続する場合、現在サポートされるTransportとしてStreamableが説明されており、SSEは2025年8月以降MCP向けにはサポートされないとされています。既存実装を流用する場合は、Transportの対応状況も確認してください。(Microsoft Learn)
認証方式はAPI keyとOAuth 2.0の違いを理解して選ぶ
MCPサーバーを作成・接続する際、認証を実装する場合はAPI keyまたはOAuth 2.0を選択できます。API keyはシンプルな方式で、OAuth 2.0はユーザーごとの認証と権限付与に向いた方式です。(Microsoft Learn)
| 認証方式 | 向いている場面 | 注意点 |
|---|---|---|
| None | 社内検証、認証不要の公開情報のみ扱う場合 | 本番の業務データ連携では慎重に判断する |
| API key | サービス単位で固定キーを使うシンプルな連携 | キー共有・ローテーション・漏えい時の影響範囲を設計する |
| OAuth 2.0 | ユーザーごとの権限で外部サービスへアクセスする場合 | アプリ登録、Client ID、Client secret、Callback URL、Scopesなどの設定が必要 |
OAuth 2.0を使う場合、Copilot StudioでMCPサーバーを追加した後にCallback URLが表示されます。このURLは、ユーザーがサインインして権限付与した後、IDプロバイダーが応答を返す先としてアプリ登録側に追加する必要があります。(Microsoft Learn)
実務では、次のように使い分けると判断しやすくなります。
- 社内の検証用MCPサーバーで、機密データを扱わない場合：Noneまたは限定的なAPI key
- 部門共通の業務APIを呼び出す場合：API key。ただしキー管理と接続元制限を必ず設計
- ユーザー本人のメール、チケット、CRMデータなどを扱う場合：OAuth 2.0
- 監査や権限分離が必要な本番システム：OAuth 2.0を第一候補にし、最小権限のScopesを設定
MCPを使うべきケースと、使わない方がよいケース
MCPは強力ですが、すべての連携をMCPに置き換える必要はありません。公式ガイダンスでも、MCP、Power Platformコネクタ、REST API呼び出しは使い分けが重要だとされています。MCPは、複数エージェントへ標準化された方法でツールやリソースを公開したい場合、特に有効です。(Microsoft Learn)
| 連携方法 | 向いているケース | 向いていないケース |
|---|---|---|
| MCPサーバー | 複数エージェントで同じツール群を使う、API変更が多い、中央管理したい | 単発の試作、単純なAPI呼び出しだけで済む |
| Power Platformコネクタ | 既存コネクタで業務SaaSやMicrosoftサービスに接続する | ツール定義を頻繁に変える、複数ツールを標準化して配布したい |
| REST API直接連携 | 1つのエージェントで限定的にAPIを呼ぶ | 多数のエージェントで同じAPI定義を再利用したい |
| AIプロンプト | 出力形式やモデル挙動を細かく制御したい | 外部システムの実行やデータ取得が主目的 |
MCPを選ぶべき典型例は、社内で共通利用する「顧客情報MCP」「チケット管理MCP」「製品マスターMCP」「GitHub運用MCP」などです。これらは複数のエージェントが同じ機能を使う可能性があり、API仕様や業務ルールの変更も中央で管理した方が効率的です。
一方、1回限りの検証や、特定エージェントだけが単純なHTTP APIを1つ呼ぶだけのケースでは、MCPサーバーを立てること自体が過剰になる場合があります。
展開前にテストすべきシナリオ
MCPサーバーを追加したら、公開前に「接続できるか」だけでなく、「正しく使われるか」「使ってはいけない場面で呼ばれないか」まで確認してください。
推奨テスト項目
| テスト項目 | 確認する内容 | 例 |
|---|---|---|
| 正常系 | 必要なツールが正しく呼び出されるか | 「このメールアドレスの顧客情報を確認して」 |
| 不要ツールの抑制 | 無効化したツールが使われないか | 更新系ツールをオフにした状態で変更依頼を出す |
| 権限不足 | 権限のないユーザーでエラーになるか | 他部署のデータを参照しようとする |
| 認証更新 | トークン期限切れや再認証時の挙動 | OAuth 2.0の再同意、Refresh URLの動作 |
| DLP違反 | データポリシーにより公開や実行が止まるか | ブロック対象コネクタを含む状態でPublishする |
| リソース参照 | リソースがツール出力として使われるか | FAQ検索ツールが該当リソースを返す |
| サーバー更新 | MCPサーバー側のツール追加・削除が反映されるか | 新ツール追加後、Allow allオフ時に無効のままか確認 |
データポリシーが適用される操作では、違反時にエラーバナーが表示され、詳細ファイルから違反内容を確認できます。また、データポリシー違反がある場合、Publishボタンが利用できなくなるとされています。(Microsoft Learn)
移行・運用で失敗しやすいポイント
MCPサーバー連携は、導入直後よりも運用開始後に問題が出やすい領域です。特に次の点は、移行・展開時に注意してください。
既存API連携をMCP化するときに権限が広がる
既存のREST API連携では、エージェントごとに呼び出すAPIが限定されていたかもしれません。MCPサーバーへ移行すると、同じサーバー内の複数ツールがまとめて見えるため、意図せず利用範囲が広がることがあります。
移行時は、既存エージェントが実際に使っていたAPI操作を棚卸しし、MCP側で有効にするツールを最小限に絞ってください。
ツール説明が曖昧で誤呼び出しが起きる
MCPでは、ツール名や説明がエージェントの判断材料になります。「データを取得する」「情報を処理する」のような曖昧な説明では、似たツールがある場合に誤選択されやすくなります。
説明には、少なくとも次の情報を含めると実務で扱いやすくなります。
- 何をするツールか
- 何をしないツールか
- どの入力が必要か
- 読み取り専用か、更新を伴うか
- どの業務シナリオで使うか
Resourcesを公開しただけで使えると思い込む
リソースは、MCPサーバー所有者がツールの出力として構成しないと、Copilot Studioエージェントが期待どおりに使えない可能性があります。リソース一覧に表示されることと、会話で有効に使われることは別です。(Microsoft Learn)
検証では、リソース名が見えるかだけでなく、ユーザーの質問に対してそのリソースが回答生成に反映されるかを確認してください。
データポリシーの確認を後回しにする
MCPサーバーはPower Platformコネクタに依存するため、DLPやデータポリシーの設定次第で、追加できても公開できない、特定環境でだけ動かない、といった問題が発生します。(Microsoft Learn)
開発者だけで検証を進めるのではなく、Power Platform管理者、セキュリティ担当、MCPサーバー所有者を早い段階で巻き込むことが重要です。
本番展開前の実務チェックリスト
Microsoft Copilot StudioでMCPサーバーをエージェントに追加する前に、次のチェックリストを使って確認してください。
| 対象 | チェック項目 | 完了の目安 |
|---|---|---|
| エージェント設計 | MCPサーバーを使う目的が明確か | 「何の業務を自動化・支援するか」が説明できる |
| ツール選定 | Allow allを見直したか | 必要なツールだけがオンになっている |
| MCPサーバー | ツール名・説明・入力・出力が分かりやすいか | エージェントが誤解しにくい定義になっている |
| リソース | Resourcesがツール出力として構成されているか | 会話テストで参照されることを確認済み |
| 認証 | API keyまたはOAuth 2.0の方式が適切か | 権限・ローテーション・再認証の設計がある |
| データポリシー | Power Platform管理センターで制御されているか | Business、Non-business、Blockedの分類を確認済み |
| 環境 | 開発・検証・本番の分離ができているか | 本番前に検証環境でテスト済み |
| 監査 | 実行ログやエラー時の確認方法があるか | 問題発生時に追跡できる |
| 変更管理 | MCPサーバー側のツール追加時の確認フローがあるか | 新規ツールの有効化判断者が決まっている |
まず取るべき対応
今回の更新で、Microsoft Copilot StudioのMCPサーバー連携は、エージェントに外部ツールやリソースを追加する実用的な手段として整理されました。特に、複数エージェントで共通の業務機能を使う組織では、MCPサーバーを中心に連携を標準化するメリットがあります。
一方で、MCPサーバーを追加すると既定で全ツールが有効になるため、本番環境ではそのまま公開しないことが重要です。まずは検証環境でMCPサーバーを追加し、ToolsとResourcesの一覧を確認します。そのうえでAllow allをオフにし、エージェントの目的に必要なツールだけを有効化してください。
管理者はPower Platformのデータポリシーと環境スコープを確認し、開発者はMCPサーバー側のツール説明、認証方式、リソース出力、Transport対応を見直します。最後に、正常系だけでなく、権限不足、DLP違反、不要ツールの抑制、サーバー更新時の反映までテストすれば、Copilot StudioのMCP連携を安全に展開しやすくなります。
コメント