Microsoft Copilot Studioで既存のMCPサーバーをエージェントに接続する場合、最初に押さえるべき結論は3つです。推奨ルートはMCPオンボードウィザード、対応トランスポートはStreamable、そして本番展開前に認証方式とPower Platformのデータポリシーを必ず確認する必要があります。
この記事では、2026年5月16日時点で確認したMicrosoft Learnの公式情報を基に、Copilot Studioのエージェントを既存のModel Context Protocol（MCP）サーバーへ接続する際の変更点、影響範囲、管理者・開発者が見るべき設定を整理します。なお、該当するMicrosoft Learn英語版ページでは最終更新日が2026年5月15日と表示されており、日本語版ページとは更新日や記載範囲が異なる場合があります。実装時は英語版の最新情報も確認してください。 (Microsoft Learn)
Microsoft Copilot StudioのMCPサーバー接続で何が変わるのか
今回のポイントは、Copilot Studioのエージェントから既存のMCPサーバーを使いやすくするための接続手順が整理されたことです。既にMCPサーバーを構築している組織は、エージェントにそのサーバーを追加し、外部システムのツールやリソースをCopilot Studioから呼び出せるようになります。
公式情報で特に重要なのは、接続方法が大きく2つに分かれている点です。1つ目はCopilot Studio内のMCPオンボードウィザードを使う方法で、Microsoftはこれを推奨しています。2つ目は、Power Appsでカスタムコネクタを作成して接続する方法です。 (Microsoft Learn)
| 確認項目 | 公式情報の要点 | 実務上の判断ポイント |
|---|---|---|
| 接続方法 | MCPオンボードウィザード、またはPower Appsのカスタムコネクタ | まずはウィザードを優先。既存のOpenAPI定義や独自パラメーター管理が必要ならカスタムコネクタを検討 |
| トランスポート | Copilot StudioはStreamableトランスポートをサポート | 既存MCPサーバーがSSE前提なら移行が必要 |
| 認証 | なし、APIキー、OAuth 2.0を選択可能 | 業務データやユーザー単位の権限が関わる場合はOAuth 2.0を優先的に検討 |
| データポリシー | MCPサーバーへの接続はPower Platformコネクタに依存 | DLPやコネクタ制御でMCPツールがブロックされる可能性がある |
| 管理対象 | サーバーURL、説明、認証、接続、コネクタ、環境 | 開発者だけでなくPower Platform管理者の確認が必要 |
特に注意したいのは、SSEトランスポートです。公式ドキュメントでは、SSEが非推奨になったことを受け、Copilot Studioは2025年8月以降MCPのSSEをサポートしないと説明されています。既存MCPサーバーがSSEで動いている場合、Copilot Studio連携の前にStreamable対応を確認してください。 (Microsoft Learn)
MCPサーバー接続でできること
MCPは、エージェントが外部のデータソースやツールにアクセスするための仕組みです。Copilot Studioでは、MCPサーバーから公開されるツールやリソースを利用して、エージェントの機能を拡張できます。
たとえば、次のような用途が考えられます。
| 活用シーン | MCPサーバー側の役割 | Copilot Studioエージェントでの利用例 |
|---|---|---|
| 社内CRM連携 | 顧客情報や商談情報を取得するツールを公開 | 営業担当が「A社の直近商談を要約して」と聞く |
| チケット管理 | 障害チケットの検索・更新機能を公開 | サポート担当が問い合わせ内容から関連チケットを探す |
| 在庫・受注確認 | 商品IDや注文番号を基に業務データを返す | 担当者が「この注文の出荷予定を確認して」と聞く |
| 開発支援 | リポジトリ情報やAPI仕様をリソースとして提供 | 開発者が仕様確認や影響範囲調査に使う |
Copilot StudioのMCP連携では、接続されたMCPサーバーが公開するツールやリソースが利用可能になります。また、MCPサーバー側でツールやリソースを更新・削除すると、Copilot Studio側にも動的に反映されると説明されています。便利な一方で、本番環境では「サーバー側の変更がエージェントの挙動に影響する」点を運用ルールに含める必要があります。 (Microsoft Learn)
接続前に必ず確認すべき前提条件
生成オーケストレーションが有効か確認する
Copilot StudioでMCPを使うには、生成オーケストレーションが必要です。MCPサーバーを追加しても、エージェントが適切にツールを選択して呼び出せなければ、実務では使いものになりません。 (Microsoft Learn)
確認すべきポイントは次の通りです。
| 確認内容 | 見るべき理由 |
|---|---|
| エージェントで生成オーケストレーションが使える状態か | MCPツールをエージェントが実行時に選択する前提になる |
| ツールの説明が具体的か | 説明が曖昧だと、エージェントが呼び出すべきタイミングを判断しにくい |
| テスト用ユーザーで認証・同意フローを確認したか | 管理者では動くが一般ユーザーでは失敗するケースを防ぐ |
| データポリシーに抵触しないか | 公開時にエラーになったり、接続済みツールが使えなくなったりする可能性がある |
サーバー説明は「短く具体的に」書く
MCPオンボードウィザードでは、サーバー名、サーバーの説明、サーバーURLを入力します。公式情報では、サーバーの説明は簡潔かつ明確に書く必要があり、エージェントのオーケストレーターが実行時にそのサーバーを呼び出すかどうかの判断に使うと説明されています。 (Microsoft Learn)
悪い例と良い例を比べると、違いが分かりやすくなります。
| 種類 | 説明文の例 | 問題点・良い点 |
|---|---|---|
| 悪い例 | 社内データを取得します | 対象データ、入力条件、用途が分からない |
| 良い例 | 顧客IDを指定して、CRM上の会社名、担当営業、直近商談、契約更新日を取得します | いつ呼び出すべきかを判断しやすい |
| 良い例 | 商品SKUを基に、国内倉庫の在庫数、入荷予定日、出荷可否を返します | 入力と出力が明確で業務利用に向く |
MCP連携では、ツールの技術的な接続だけでなく、エージェントが「どの場面で使うべきか」を判断できる情報設計が重要です。説明文を軽く扱うと、意図しないツール呼び出しや、逆に必要な場面で呼び出されない問題が起きやすくなります。
MCPオンボードウィザードで既存MCPサーバーを接続する手順
既存MCPサーバーを接続する最もシンプルな方法は、Copilot StudioのMCPオンボードウィザードを使う方法です。公式手順では、エージェントのツール画面から新しいツールを追加し、Model Context Protocolを選択して設定します。 (Microsoft Learn)
| 手順 | 操作 | 事前に準備するもの |
|---|---|---|
| 1 | 対象エージェントの「ツール」ページを開く | 接続先エージェント |
| 2 | 「ツールの追加」から「新しいツール」を選択 | 編集権限 |
| 3 | 「Model Context Protocol」を選択 | MCPサーバーの接続情報 |
| 4 | サーバー名、説明、URLを入力 | サーバーURL、用途説明 |
| 5 | 認証方式を選択 | なし、APIキー、OAuth 2.0の判断 |
| 6 | 新しい接続を作成、または既存接続を使用 | 接続の所有者・利用者 |
| 7 | 「エージェントに追加」で完了 | テスト用ユーザー、検証シナリオ |
接続後は、すぐに本番公開せず、まずはテスト環境で「想定した質問でツールが呼ばれるか」「呼ばれてはいけない質問で呼ばれないか」を確認してください。MCPサーバーの説明やツール定義が曖昧な場合、エージェントが不要な場面で外部ツールを呼び出す可能性があります。
認証方式の選び方
MCPサーバー接続では、認証方式の選択が運用負荷とセキュリティに直結します。公式情報では、認証なし、APIキー、OAuth 2.0が選択肢として示されています。APIキーはシンプルな方式で、エージェントのユーザーがAPIキーを提供し、エージェントがMCPサーバーへのリクエストに含めます。OAuth 2.0は、ユーザーが資格情報を共有せずにアプリケーションへアクセス許可を付与できる方式です。 (Microsoft Learn)
| 認証方式 | 向いているケース | 注意点 |
|---|---|---|
| なし | 検証環境、公開情報だけを返す内部テスト | 業務データや個人情報を扱う本番用途では慎重に判断 |
| APIキー | サーバー単位で単純に保護したい場合 | キーの保管、ローテーション、漏えい時の無効化手順が必要 |
| OAuth 2.0 | ユーザー単位の権限管理や同意が必要な場合 | IDプロバイダー設定、コールバックURL登録、スコープ設計が必要 |
APIキーはヘッダー送信を基本に検討する
公式手順では、APIキーをヘッダーまたはURLのクエリパラメーターとして送信する選択肢が示されています。実務では、サーバー仕様が許すならヘッダー送信を優先して検討するとよいでしょう。クエリパラメーターはログや監視ツールに残りやすく、キー管理上のリスクが高くなりがちです。 (Microsoft Learn)
もちろん、最終的には接続先MCPサーバーの仕様に従う必要があります。既存サーバーがクエリパラメーターしか受け付けない場合は、ログのマスキング、キーの短期ローテーション、利用範囲の限定をセットで検討してください。
OAuth 2.0はDynamic Discovery、Dynamic、Manualを使い分ける
OAuth 2.0を選ぶ場合、Copilot Studioでは次の3つの構成方法が示されています。
| OAuth 2.0の種類 | 使う場面 | 確認すべき設定 |
|---|---|---|
| Dynamic Discovery | MCPサーバーがDCRと探索メカニズムに対応している場合 | Discovery endpoint、IDプロバイダー側のDCR対応 |
| Dynamic | DCRには対応しているが、探索メカニズムには対応していない場合 | Authorization URL、Token URL template |
| Manual | 手動でOAuth設定を登録する必要がある場合 | Client ID、Client secret、Authorization URL、Token URL template、Refresh URL、Scopes |
Manual構成では、Copilot Studioでサーバーを追加した後に表示されるコールバックURLを、IDプロバイダー側のアプリ登録へ追加する必要があります。ここを忘れると、ユーザーのサインイン後に認可コードを戻せず、接続テストや本番利用で失敗します。 (Microsoft Learn)
Power Appsのカスタムコネクタを使うべきケース
MCPオンボードウィザードが推奨ですが、すべてのケースで最適とは限りません。Power AppsでカスタムMCPコネクタを作成する方法は、既存のコネクタ管理ルールやOpenAPI定義を使いたい場合に向いています。
公式手順では、Power Appsでカスタムコネクタを作成する場合、MCPサーバーのAPIを記述したOpenAPI仕様のYAMLファイルが必要です。サンプルではStreamableトランスポート向けに x-ms-agentic-protocol: mcp-streamable-1.0 が使われています。 (Microsoft Learn)
paths:
/mcp:
post:
x-ms-agentic-protocol: mcp-streamable-1.0
operationId: InvokeMCP
responses:
'200':
description: Successカスタムコネクタ方式が向いているのは、たとえば次のようなケースです。
| ケース | カスタムコネクタを使う理由 |
|---|---|
| 既にPower Platformでコネクタ管理を標準化している | 管理者レビューやDLP設定に乗せやすい |
| OpenAPI定義をCI/CDで管理している | スキーマ変更のレビューや差分管理がしやすい |
| 接続パラメーターを細かく管理したい | ウィザードより柔軟な構成を取りやすい |
| 複数環境で同じ接続定義を展開したい | 開発・検証・本番の分離に向く |
一方で、カスタムコネクタ方式はPower Apps、Power Automate、Power Platform管理センター側の知識が必要です。開発者だけで完結させず、Power Platform管理者と一緒に設計するのが安全です。
管理者が確認すべきデータポリシーと影響範囲
Copilot StudioのMCPサーバー接続で最も見落としやすいのが、Power Platformのデータポリシーです。公式情報では、Copilot StudioのMCPサーバーへのアクセスはPower Platformコネクタに依存するため、データポリシーがPower Platformコネクタを制御している場合、MCPサーバーとそのツールへのアクセスにも影響すると説明されています。 (Microsoft Learn)
さらに、Copilot Studioのデータポリシー適用はすべてのテナントで有効になっており、以前のようなエージェント単位の適用除外はサポートされないとされています。データポリシー違反がある場合、作成者やユーザーにエラーが表示され、違反時には公開ボタンが利用できなくなるケースもあります。 (Microsoft Learn)
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| Power Platform管理者 | コネクタ制御やDLPがMCPツール利用を左右する | Business、Non-business、Blockedの分類、対象環境、テナントスコープ |
| Copilot Studio作成者 | 追加したMCPツールが公開時にブロックされる可能性がある | ツール追加後に公開テスト、エラー詳細の確認 |
| 開発者 | サーバー仕様だけでなくコネクタ仕様も影響する | OpenAPI定義、認証、Streamable対応 |
| セキュリティ担当者 | 外部MCPサーバー経由のデータ持ち出しリスクを見る必要がある | 接続先ドメイン、認可範囲、ログ、最小権限 |
| 利用者 | ツール実行時に認証や同意が必要になる場合がある | 初回利用時の認証手順、権限不足時の問い合わせ先 |
特に、Power Platformコネクタをツールとして使うことをブロックしているデータポリシーでは、接続されたMCPサーバー内のツールへのアクセスもブロックされると説明されています。MCP接続だけを見て「設定は正しい」と判断せず、Power Platform側のポリシーまで確認してください。 (Microsoft Learn)
開発者向けの移行・展開チェックリスト
SSEからStreamableへの移行を先に片付ける
既存のMCPサーバーがSSE前提で作られている場合、Copilot Studio連携ではまずStreamable対応が必要です。接続画面でURLや認証を設定する前に、サーバーのトランスポート仕様を確認してください。
移行時は、次の順で進めると手戻りを減らせます。
| 順番 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 既存MCPサーバーの通信方式を棚卸し | SSE、Streamable、その他のどれか |
| 2 | Streamable対応エンドポイントを用意 | Copilot Studioから到達可能なURLか |
| 3 | 認証方式を再設計 | APIキーで十分か、OAuth 2.0が必要か |
| 4 | OpenAPI YAMLを更新 | x-ms-agentic-protocol がStreamable向けになっているか |
| 5 | Copilot Studioに接続 | ウィザードまたはカスタムコネクタ |
| 6 | テストユーザーで検証 | 権限、同意、トークン更新、DLP違反を確認 |
| 7 | 本番展開 | 環境ごとの接続先、シークレット、監視を確認 |
ツール定義は「AIが迷わない粒度」にする
MCPサーバー上のツールは、単にAPIを公開すればよいわけではありません。AIエージェントが使う前提では、ツール名、説明、入力、出力の粒度が重要です。
たとえば、getData のような汎用名より、getCustomerRenewalDate や searchOpenSupportTickets のように用途が分かる名前の方が、エージェントは適切に選びやすくなります。入力も id だけではなく、customerId、ticketId、sku のように業務上の意味が伝わる名称にしましょう。
本番展開前にテストすべきプロンプト
MCP接続のテストでは、成功パターンだけでなく、呼び出してはいけないパターンも確認します。
| テスト種別 | プロンプト例 | 見るべき結果 |
|---|---|---|
| 正常系 | 「顧客ID C-1001 の契約更新日を確認して」 | 正しいMCPツールが呼ばれる |
| 入力不足 | 「あの会社の契約日を調べて」 | 追加情報を聞き返す |
| 権限不足 | 「他部署の顧客情報を全部出して」 | 権限や範囲に応じて拒否・制限される |
| 不要呼び出し | 「契約更新日の意味を教えて」 | 外部MCPツールを呼ばず一般説明で返す |
| DLP確認 | ブロック対象コネクタを含む操作 | エラー内容や公開可否を確認する |
このテストを省くと、技術的には接続できていても、業務で使った瞬間に「意図しない外部呼び出し」「権限不足」「公開不可」といった問題が出やすくなります。
よくある失敗と対策
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| サーバー説明が曖昧 | エージェントがMCPサーバーを呼ぶべき場面を判断しにくい | 入力、出力、業務用途を1〜2文で明確に書く |
| SSE前提のまま接続する | Copilot Studioで利用できない | Streamable対応を先に確認する |
| OAuthのコールバックURLを登録し忘れる | サインイン後に認証が完了しない | Copilot Studioで表示されたURLをIDプロバイダーに登録する |
| APIキーをクエリで送る | ログにキーが残るリスクが高まる | 可能ならヘッダー送信にし、ログマスキングを行う |
| DLPを確認せず公開する | 公開ボタンが無効化されたり、ツールが使えなかったりする | Power Platform管理センターでコネクタ分類と対象環境を確認する |
| 日本語版ページだけを見る | 最新の英語版と記載差がある可能性がある | 実装前に英語版Microsoft Learnも確認する |
| MCPサーバー側の変更を無管理で行う | エージェントの挙動が突然変わる | サーバー側ツール変更にもレビュー・リリース手順を設ける |
まず実施すべきアクション
Copilot Studioで既存MCPサーバーを接続するなら、最初にやるべきことは「接続」ではなく「棚卸し」です。MCPサーバーのURL、トランスポート、認証方式、公開ツール、Power Platformデータポリシーを確認してから、MCPオンボードウィザードで接続するか、Power Appsのカスタムコネクタで管理するかを決めてください。
実務では、次の順番で進めると安全です。
- 既存MCPサーバーがStreamableトランスポートに対応しているか確認する
- サーバー名、説明、URL、認証方式を整理する
- Power Platform管理者にデータポリシーとコネクタ分類を確認してもらう
- Copilot Studioのテスト環境でMCPオンボードウィザードを使って接続する
- テストユーザーで認証、ツール呼び出し、DLP違反、公開可否を確認する
- 本番環境では変更管理、ログ確認、シークレット更新手順を決めてから展開する
MCPサーバー接続は、Copilot Studioエージェントを業務システムとつなぐ強力な手段です。一方で、外部ツール呼び出し、ユーザー認証、データポリシーが一体で動くため、開発者だけで進めると本番直前で止まりやすい領域でもあります。管理者、開発者、業務担当者で「どのデータを、誰が、どの権限で、どのエージェントから使うのか」を先に決めることが、安定した展開への近道です。
コメント