AIエージェントの活用が進む中、AIと外部のツール・データソース・業務システムをつなぐ共通プロトコル「MCP（Model Context Protocol）」の普及が加速しています。
企業内のAIセキュリティの議論はAIモデルそのものの管理が先行しており、MCPについては利便性の高さから採用が進む一方で、ガバナンスの仕組みが十分に整備されていないケースがあるのではないでしょうか。
AIエージェントが業務システムへアクセスする環境では、MCPサーバを新たな管理対象として捉え、「どのMCPを利用しているか」「誰が管理するか」「どのようなルールで利用するか」「操作を追跡できるか」といった観点から統制することが重要です。
本記事では、MCPの導入形態ごとのガバナンス上の特性を整理したうえで、企業が整備すべき「可視化」「責任体制」「ポリシー設計」「監査・継続的監視」の4つの観点と、リスクに応じた現実的な管理方法について解説します。
MCPガバナンスとは、AIエージェントが接続するMCPサーバについて、誰が何を管理し、どのように承認・監督・監査するかを組織として定めることです。
2026年7月28日、MCPの新仕様が公開されました[i]。本バージョンはプロトコルのステートレス化（セッション管理を前提としない通信方式）など大きな構造変更が中心ですが、認証・認可についても、認可レスポンスの発行元検証（RFC 9207）の要件化や、動的クライアント登録に代わるClient ID Metadata Documents（CIMD）の採用など、実装の安全性と正確性を高める改定が加えられています。
一方で、どのクライアントがどのMCPに接続でき、どのスコープを与えるかという判断は、組織のガバナンス設計として別途必要です。
本記事では個別の技術対策ではなく、技術仕様が変化しても組織として問い続けるべきガバナンス設計の観点から整理します。
サーバ・API・SaaSをアクセス制御で管理してきた従来の枠組みに、MCPサーバという新しい管理単位が加わります。従来のAI向けAPI（関数呼び出し）では、利用するツールをあらかじめ個別に定義・連携しますが、MCPでは、MCPサーバが公開するツールの情報をAIエージェントが実行時に取得し、呼び出します。認可の経路も、ユーザ→エージェント→MCPサーバ→外部システムと連鎖します。
どのMCPサーバへの接続を許可し、どのスコープをAIエージェントに委ねるかを設計時に管理することが、従来のAPIアクセス管理とは別に求められます。2026年5月に公表されたアメリカ国家安全保障局（NSA）のガイダンスも、MCPのリスクは個々のインターフェースやエンドポイントだけでは捉えきれず、エージェントを含むシステム全体として俯瞰的に評価する必要があると指摘しています[ii]。
MCPの管理が難しい理由は、既存のガバナンスの枠組みに自然にはまらないためです。
これらを踏まえて、次章から具体的な管理策を検討します。
MCPサーバは、どこで動作し、誰が管理するかという導入・運用形態によって分類できます。ガバナンスを設計するため、リモートMCPをさらに「社内リモート」と「社外リモート」に分けて考えます。
この分類は「組織からの見えやすさ・制御のしやすさ・ログの取りやすさ」を整理するものです。実際のリスクの大小はMCPの導入形態だけでなく、扱うデータの機密性・操作の影響度・付与された権限の大きさによって決まります。
最後の「シャドーMCP」は特定の導入形態ではなくガバナンス上の状態を指す概念であるため、各分類の後に独立して取り上げます。
開発者のPC・開発環境・ローカルサーバ上で動作するMCPです。導入が容易で開発スピードに貢献する反面、組織のITシステムや認証基盤を経由しない構成になりやすく、ガバナンス上の課題が生じます。
| 評価軸 |
内容 |
|
ガバナンスの難易度 |
誰がどのMCPを使っているか組織が把握できない。認証・認可・ログが組織的に管理されない |
|
リスクの性質 |
組織のITシステムを経由しないため把握・制御が難しい。扱うデータや付与権限によってはローカルファイル・認証情報・社内システムへの重大なアクセスリスクが生じる |
組織が自社のサーバ上で構築・運用するMCPです。業務システムなどエンタープライズシステムとの接続では、認証・認可やログを組織側で管理できることから、通常このリモート型が採用されます。仕様上、MCPサーバはOAuth 2.1のリソースサーバとして位置づけられ、認可サーバと連携してアクセス制御を行います。この仕組みを用いて、社内の認証・認可基盤と統合することも可能です[iii]。
| 評価軸 |
内容 |
|
ガバナンスの難易度 |
認証・認可・ログを集中管理でき、セキュリティポリシーを一元適用できる。一方で構築・運用コストと導入までのリードタイムがかかる |
|
リスクの性質 |
組織が直接管理するため、データ持ち出しや不正アクセスのリスクは相対的に低い。ただし仕様上、認可の実装は必須要件ではないため、組織側で明示的に有効化する前提で設計する。エンタープライズシステムと高権限で接続するため、設定ミスや権限過剰には注意が必要 |
外部の事業者やサービスが提供するMCPサーバで、インターネット経由でアクセスするものです。SaaSが提供するMCPがこれにあたります。社外リモートMCPを組織として承認せずに放置すると、後述するシャドーMCPと同じ状態になります。具体的な管理方法は最後の章で整理します。
| 評価軸 |
内容 |
|
ガバナンスの難易度 |
誰がどの外部サービスに接続しているかの把握が必要（SaaS管理と同等の仕組みが必要）。組織のセキュリティポリシーを外部サーバ側に強制できない。接続先MCPサーバの審査・承認プロセスの整備が必要 |
|
リスクの性質 |
AIが人間の介在なしに外部サーバを操作できるため、扱うデータや付与権限によっては重大なリスクになりうる。組織データが外部サーバに送信・保存されるリスクがある。接続先MCPサーバのセキュリティ品質が組織で制御できない |
シャドーIT（組織の承認なく利用されるITシステム・サービス）と同様のリスクがMCPにも存在します。OWASPのMCP Top 10ではこの概念をShadow MCP Servers（MCP09:2025）として取り上げています[iv]。
本記事ではこれを参考に「シャドーMCP」という言葉を用い、組織のガバナンス外に置かれたMCPの状態を指します。ローカルMCPを個人が無断で導入した場合も、社外リモートMCPを組織の承認なく接続した場合も、シャドーMCPに当たります。
シャドーITと同様の構造ですが、AIエージェントに高い権限が付与され、人間による都度確認を介さず操作できる構成では、シャドーIT以上に影響が拡大する可能性があります。
| 評価軸 |
内容 |
|
ガバナンスの難易度 |
存在自体を把握できない。把握後も「未承認状態の解消」「未統制状態の解消」と段階的な整備が必要 |
|
リスクの性質 |
誰も把握していないMCPを通じてAIが業務データにアクセスし続けるリスク。不正なMCPへの接続による情報漏えい・データ改ざんのリスク。責任の所在が不明確になり、インシデント発生時に対応が遅れるリスク |
複数のガイダンスを横断すると、立場や対象範囲は異なりながらも共通するガバナンスの考え方が見えてきます。本記事では、これを4つの観点に整理します。
| 観点 |
内容 |
|
可視化（Inventory） |
どのMCPが、誰に、何の目的で利用されているか把握する |
|
責任体制（Ownership） |
各MCPの所有者とセキュリティ上の責任主体を明確にする |
|
ポリシー設計（Policy） |
導入・権限・更新・廃止のルールを定める |
|
監査・継続的監視（Audit/Observability） |
MCP経由の操作を追跡し、異常を検知できる状態にする |
以下では、それぞれの観点について、具体的にどのような管理が必要になるかを整理します。
ガバナンスの出発点は現状把握です。リスクの評価や責任の所在の明確化のために、まず社内で使われているMCPの全体像を把握します。この把握がInventoryであり、次の「責任体制」で各MCPに所有者を割り当てる土台になります。
把握する項目：
MCPに関するインシデントが発生したとき、「そのMCPを誰が管理していたか」が即座に答えられる状態を作ることが目的です。責任の空白があると、問題の検知・対応・是正のいずれも遅れます。各MCPについて所有者を明確にします。また、MCP管理に関するリスク評価やインシデント対応のセキュリティ担当者を明確にします。
MCPの導入・運用・廃止に関するポリシーを定めます。ポリシーには以下の要素が含まれます。
承認プロセス：
廃止・更新の管理：
権限設計（Least Privilege）：
AIエージェントが複数のMCPを経由して下流システムにアクセスする多段委譲では、権限の継承関係が不透明になりやすく、統制が効きにくくなります。仕様上、MCPサーバは自身に対して発行されていないトークンを受け入れることも中継することも認められておらず、各経路で権限を適切に絞り直す設計が前提となります[iii][vi]。
技術的な仕組みが整っても、どの経路にどの権限を委ねるかという設計・承認判断は、エージェント間の呼び出し経路と権限の流れの把握も含めて、組織のガバナンスとして別途必要です。
五か国共同ガイダンス（米・英・豪・加・ニュージーランド）は、追跡が困難になることを「説明責任リスク」として指摘しています[v]。また、NSAも、ログ記録と継続的監視を推奨しています[ii]。これらを踏まえ、いつ・誰のエージェントが・どのMCPを使い・何を実行し・どのデータにアクセスしたかを追跡可能な状態に維持します。
加えて、一定のパターンを逸脱した操作を検知する仕組み（異常なデータ量のアクセス・通常と異なる時間帯の実行など）を設けることで、問題の早期発見につなげます。
4つの観点は独立したものではなく、継続的に見直す管理サイクルとして機能します。可視化した情報を基に責任体制やポリシーを見直し、監査・監視で得た結果を次の改善につなげることが、MCPガバナンスの実効性を維持するうえで重要です。
MCPガバナンス設計の4つの観点はMCPを構築・管理する側が設計すべき事項ですが、Human-in-the-loop（HITL）はMCPを利用するAIエージェント側の設計責任です。MCPサーバはツール定義や説明文を通じてエージェントの判断に影響を与えうるため、高リスクな操作（データの一括削除・外部送信・権限変更など）の前に人間の確認・承認を求めるプロセスをAIエージェントのアプリケーション層で実装します。
あわせて、AIエージェントの行動範囲を設計段階で明確に定義し、業務目的を超えた操作が起動できないようガードレールを設けることも、エージェント側の設計として重要です。
どの操作をHITLまたはガードレールによる制限の対象とするかは、五か国共同ガイダンス[v]が示す影響度・不可逆性の考え方を参考に、以下のように整理できます。
|
判断軸 |
問い |
該当例 |
|
影響の大きさ |
処理が高影響・広範囲に及ぶか |
一括処理、複数システム連携、多数ユーザへの通知 |
|
不可逆性 |
元に戻しにくい操作か |
ファイル削除、メール送信、権限変更、DB更新 |
|
エラーコスト |
誤作動時の回復コストが大きいか |
システムリセット、ネットワーク外部送信、重要レコードの削除 |
対応の強度はリスクの大きさに応じて段階的に設計することが現実的です。
|
リスクレベル |
目安 |
対応例 |
|
低 |
判断軸に非該当、または読み取り専用・影響範囲が限定的 |
自動実行＋ログ記録 |
|
中 |
判断軸に一部該当するが影響が限定的 |
事後レビュー・例外時の確認 |
|
高 |
複数の判断軸に該当、または影響度が大きい |
実行前のHITL承認またはガードレールによる制限 |
MCPガバナンスを設計する際は、エージェント側にこの観点が組み込まれているかも確認事項として含めることが望ましいです。
これまで整理したリスクの性質を踏まえ、ここでは種別ごとに優先すべき管理対策を示します。
ローカルMCPは組織のITシステムを経由しないため、ポリシーと申告ルールによる管理が中心となります。組織が審査したMCPを一覧化した社内レジストリや、クライアント製品が提供する許可リスト・管理設定などを活用し、「使ってよいMCP」を明確にすることで、開発者が申告・選定しやすい環境を作れます。
社外リモートMCPについても、MCP RegistryやSaaSベンダーが公開しているレジストリを審査の起点として活用したうえで、承認したものを社内レジストリに登録することで、ローカルMCPと同じ仕組みで一元管理できます。
|
課題 |
対応策 |
留意点 |
|
未把握 |
申告・掲載がInventoryを兼ねる（社外リモートMCPは社外レジストリで発見後に登録） |
レジストリを経由しない導入は依然として不可視 |
|
未承認 |
掲載MCPが組織承認済みのカタログとして機能する。社外リモートMCPはクライアント設定ファイルとネットワーク層で未承認接続を技術的にブロック |
審査が重いと開発者が迂回してシャドーMCP化するリスク |
|
未統制 |
所有者・アクセス範囲・廃止管理を社内レジストリで一元管理する |
ログはエージェント側で別途取得が必要 |
また、五か国共同ガイダンスが推奨するとおり[v]、AIエージェントとMCPの展開は段階的に進めることが現実的です。まず業務影響の小さい領域（例：読み取り専用の操作、社内限定のシステム）から始め、知見を積み重ねながら展開範囲を広げていくアプローチが、持続可能なガバナンス設計につながります。
MCPガバナンスは、技術的な設定の問題というよりも、組織として誰が何を管理し、どう意思決定するかというガバナンス設計の問題です。本記事で整理したポイントを2点にまとめます。
AIエージェントが実際に業務システムにアクセスする時代には、「AIが何にアクセスできるか」を統制することがセキュリティの核心になります。MCPサーバを、サーバ・API・SaaSと並ぶ管理単位として位置づけます。
すべてを一度に整備することは難しいですが、まず「可視化（Inventory）」と「責任体制（Ownership）」から始め、承認プロセス・監査ログの仕組みを段階的に加えていくことが現実的なアプローチです。あわせて、MCPを利用するAIエージェント側でHuman-in-the-loopが適切に設計されているかを確認することも忘れずに行います。
AIエージェントの活用はさらに広がっていくと考えられます。技術的な変化のスピードに遅れを取らないよう、MCPガバナンスの基盤を早期に整えることが、AI活用の推進と安全性の両立につながります。
[i]Model Context Protocol, "Specification(2026年7月28日版)",
https://modelcontextprotocol.io/specification/2026-07-28
[ii]NSA, "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation(2026年5月)",
https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF
[iii]Model Context Protocol, "Authorization(2026年7月28日版)",
https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
[iv]OWASP, "OWASP MCP Top 10",
https://owasp.org/www-project-mcp-top-10/
[v]ASD's ACSC, CISA, NSA, Cyber Centre, NCSC-NZ, NCSC-UK, "Careful Adoption of Agentic AI Services(2026年4月)",
https://media.defense.gov/2026/Apr/30/2003922823/-1/-1/0/CAREFUL%20ADOPTION%20OF%20AGENTIC%20AI%20SERVICES_FINAL.PDF
[vi]Model Context Protocol, "MCP Security Best Practices(2026年7月)",
https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices