MCPガバナンスとは｜許可リスト・Entra認証・最小権限でエージェントを制御する【2026年9月】

【結論】MCPガバナンスとは、Model Context Protocolでエージェントが触れるサーバー・ツール・データを、発見・認証・権限・監査の4つの面から組織として制御することです。

• MCPは接続規格にとどまらず、企業では「エージェントに何を触らせるか」を決める制御面になっている
• 2026年7月のMCP仕様改定でEnterprise-Managed Authorization（EMA）が安定版になり、既存の社内ID基盤で従業員のMCPアクセスを一元管理できるようになった
• 未知サーバーの遮断、最小権限、短命トークン、ゲートウェイでの監査ログが実務の4本柱

この記事では社内にMCPを広げる情報システム・セキュリティ・開発責任者向けに、2026年9月時点の公開情報に基づいて解説します。

---

MCPガバナンスとは

MCPガバナンスとは、エージェントがModel Context Protocol経由で呼ぶツールとデータ源について、誰が・どのサーバーに・どの権限でアクセスできるかを組織として決めて運用することです。接続手順そのものはMCPサーバー自作ガイドやMCP連携の選定に譲り、本記事は制御の設計に集中します。

なぜ今「つなぐ」だけでは足りないか

MCPはエージェントとツールをつなぐ共通プロトコルとして急速に広がっています。一方で、社員やチームが個別にMCPサーバーを繋ぐと、IT部門が把握していないツール実行が生まれます。Microsoft自身が公開するAzure向けセキュリティガイドも、「発見可能なサーバーの許可リスト」「ツール単位の権限」「短命トークン」「監査ログ」を企業導入の必須要件として挙げています（出典：OWASP MCP Top 10 Security Guidance for Azure）。導入が簡単になるほど、未知ツールや過剰権限のリスクが比例して増える点が、通常のAPI導入と異なる注意点です。

2026年のMCP仕様改定と企業向け認可

MCP仕様は2026年に入って3月・6月・7月と続けて大きな更新がありました。7月28日版では、ステートレス化、`Mcp-Method`／`Mcp-Name`ヘッダーによるボディを解析せずに済むルーティング、認可の強化、拡張機能の形式化が導入されています（出典：The 2026-07-28 Specification – Model Context Protocol Blog）。認可面では、RFC 9207に基づく発行者検証や、動的クライアント登録（DCR）からクライアントID metadataドキュメント（CIMD）への移行が明記されました。

特に企業導入への影響が大きいのが、2026年6月に安定化したEnterprise-Managed Authorization（EMA）です。既存の社内ID基盤（Microsoft EntraやOkta等）が、従業員がどのMCPサーバーを使えるかを一元的に決める仕組みで、サーバーごとの同意画面を都度出す必要がなくなります。ただしEMAは「人がクライアント経由でアクセスする」場面向けであり、ユーザーが不在で動く自律エージェント自体のワークロードIDや権限委譲は、2026年9月時点でも仕様の次サイクルに向けた検討課題として残っています（出典：Enterprise at Scale: MCP’s Emerging Identity and Governance Foundation）。エージェント自体のIDが必要な場面は次章のEntra Agent IDで補います。

Microsoft Entraでの基本形

公式手順では、MCPサーバーをEntraに登録し、トークンを検証してからツールを実行します。エージェント側はMicrosoft Entra Agent IDで自らのIDを使い、resourceパラメータでサーバーを指定してトークンを取得します（出典：Secure a Model Context Protocol (MCP) server with Microsoft Entra ID／What is Microsoft Entra Agent ID?）。エージェントID全般の設計はMicrosoft Entra Agent IDとはで詳しく解説しています。

ゲートウェイと多層防御の設計

複数チームがMCPサーバーを増やす段階になったら、個別サーバーごとの制御だけでは追いつきません。Microsoftの公開ガイドは、ゲートウェイ・サーバー・データの3層で防御を重ねる設計を推奨しています。

重要な教訓は「ゲートウェイだけを信頼しない」ことです。ゲートウェイが唯一の防御点になっていると、内部からの迂回や設定ミスで一気に突破されます。クレームとスコープの検証をAPI・MCPサーバー自身にも重ねて実装するのが公式の推奨です。組織運営としては、中央のポリシーを決めつつ、実装は各チームに委ねる「フェデレーテッドモデル」が現実的とされています。

MCPガバナンスと既存のAI統制の関係

NIST AI RMFのような既存のAI統制フレームワークは、MCP固有のリスクをまだ詳細には扱っていません。実務上は、既存のIT統制・AI統制を拡張して当てはめるのが現実的です。NIST AI RMFの4機能（Govern／Map／Measure／Manage）に当てはめると、Governで方針と責任者を決め、Mapで社内のMCPサーバー・ツール・所有者を棚卸しし、Measureでアクセスパターンと制御の効果を測り、Manageで改善と承認を回す、という整理になります（出典：MCP Governance: Part2）。

設計チェックリスト

FoundryではMCP接続にAgenticIdentityToken等を使う公式説明があります（出典：Agent identity concepts in Microsoft Foundry）。本番観測の土台は本番運用の基盤設計、実装はMCPサーバー支援を参照してください。

---

よくある質問（FAQ）

---

参考文献・出典

• Secure MCP server with Microsoft Entra ID
• What is Microsoft Entra Agent ID?
• Agent identity concepts in Microsoft Foundry
• The 2026-07-28 Specification – Model Context Protocol Blog
• OWASP MCP Top 10 Security Guidance for Azure – Enterprise Patterns

本記事は2026年9月時点の公開情報に基づいています。MCP仕様は改定が速いため、最新は各公式ドキュメントをご確認ください。

---

x3d株式会社では、本記事で解説したMCPガバナンスとエージェント権限設計に関する企業研修・導入支援・システム開発を提供しています。
まずはお気軽にご相談ください。

→ 無料相談・お問い合わせはこちら