MCPガバナンスとは｜AIエージェント時代に企業が整備すべき4つの観点

AIエージェントの活用が進む中、AIと外部のツール・データソース・業務システムをつなぐ共通プロトコル「MCP（Model Context Protocol）」の普及が加速しています。

企業内のAIセキュリティの議論はAIモデルそのものの管理が先行しており、MCPについては利便性の高さから採用が進む一方で、ガバナンスの仕組みが十分に整備されていないケースがあるのではないでしょうか。

AIエージェントが業務システムへアクセスする環境では、MCPサーバを新たな管理対象として捉え、「どのMCPを利用しているか」「誰が管理するか」「どのようなルールで利用するか」「操作を追跡できるか」といった観点から統制することが重要です。

本記事では、MCPの導入形態ごとのガバナンス上の特性を整理したうえで、企業が整備すべき「可視化」「責任体制」「ポリシー設計」「監査・継続的監視」の4つの観点と、リスクに応じた現実的な管理方法について解説します。

MCPガバナンスとは——MCPの仕様変化と本記事のスコープ

MCPガバナンスとは、AIエージェントが接続するMCPサーバについて、誰が何を管理し、どのように承認・監督・監査するかを組織として定めることです。

2026年7月28日、MCPの新仕様が公開されました^[i]。本バージョンはプロトコルのステートレス化（セッション管理を前提としない通信方式）など大きな構造変更が中心ですが、認証・認可についても、認可レスポンスの発行元検証（RFC 9207）の要件化や、動的クライアント登録に代わるClient ID Metadata Documents（CIMD）の採用など、実装の安全性と正確性を高める改定が加えられています。

一方で、どのクライアントがどのMCPに接続でき、どのスコープを与えるかという判断は、組織のガバナンス設計として別途必要です。

本記事では個別の技術対策ではなく、技術仕様が変化しても組織として問い続けるべきガバナンス設計の観点から整理します。

なぜMCPは「ガバナンスの問題」なのか

MCPという新しい管理対象

サーバ・API・SaaSをアクセス制御で管理してきた従来の枠組みに、MCPサーバという新しい管理単位が加わります。従来のAI向けAPI（関数呼び出し）では、利用するツールをあらかじめ個別に定義・連携しますが、MCPでは、MCPサーバが公開するツールの情報をAIエージェントが実行時に取得し、呼び出します。認可の経路も、ユーザ→エージェント→MCPサーバ→外部システムと連鎖します。

どのMCPサーバへの接続を許可し、どのスコープをAIエージェントに委ねるかを設計時に管理することが、従来のAPIアクセス管理とは別に求められます。2026年5月に公表されたアメリカ国家安全保障局（NSA）のガイダンスも、MCPのリスクは個々のインターフェースやエンドポイントだけでは捉えきれず、エージェントを含むシステム全体として俯瞰的に評価する必要があると指摘しています^[ii]。

既存のITガバナンスでは捉えきれない理由

MCPの管理が難しい理由は、既存のガバナンスの枠組みに自然にはまらないためです。

• 開発者が個人で導入できる：SaaSの野良利用と似ているが、AIエージェントがツール実行まで担う場合、意図しない操作の影響範囲が大きくなる
• AIが動的にツールを選択する：事前の認可ルールだけでは把握しきれない操作が発生しうる
• ログが分散する：AI操作履歴・MCP呼び出し記録・接続先ログが別々に管理されやすく、全体像の把握が難しい
• 責任の所在が不明確になりやすい：AIが自律的に判断した操作について「誰が承認したか」が曖昧になり、エージェントが多段階で連鎖する場合は権限の引き継ぎも不透明になる

これらを踏まえて、次章から具体的な管理策を検討します。

MCPの導入形態による分類とガバナンス特性

MCPサーバは、どこで動作し、誰が管理するかという導入・運用形態によって分類できます。ガバナンスを設計するため、リモートMCPをさらに「社内リモート」と「社外リモート」に分けて考えます。

この分類は「組織からの見えやすさ・制御のしやすさ・ログの取りやすさ」を整理するものです。実際のリスクの大小はMCPの導入形態だけでなく、扱うデータの機密性・操作の影響度・付与された権限の大きさによって決まります。

最後の「シャドーMCP」は特定の導入形態ではなくガバナンス上の状態を指す概念であるため、各分類の後に独立して取り上げます。

ローカルMCP：管理が見えにくい

開発者のPC・開発環境・ローカルサーバ上で動作するMCPです。導入が容易で開発スピードに貢献する反面、組織のITシステムや認証基盤を経由しない構成になりやすく、ガバナンス上の課題が生じます。

社内リモートMCP：管理性が高いが導入コストがある

組織が自社のサーバ上で構築・運用するMCPです。業務システムなどエンタープライズシステムとの接続では、認証・認可やログを組織側で管理できることから、通常このリモート型が採用されます。仕様上、MCPサーバはOAuth 2.1のリソースサーバとして位置づけられ、認可サーバと連携してアクセス制御を行います。この仕組みを用いて、社内の認証・認可基盤と統合することも可能です^[iii]。

社外リモートMCP：組織による制御が及びにくい

外部の事業者やサービスが提供するMCPサーバで、インターネット経由でアクセスするものです。SaaSが提供するMCPがこれにあたります。社外リモートMCPを組織として承認せずに放置すると、後述するシャドーMCPと同じ状態になります。具体的な管理方法は最後の章で整理します。

シャドーMCP：ガバナンスの外側にある見落とされやすいリスク

シャドーIT（組織の承認なく利用されるITシステム・サービス）と同様のリスクがMCPにも存在します。OWASPのMCP Top 10ではこの概念をShadow MCP Servers（MCP09:2025）として取り上げています^[iv]。

本記事ではこれを参考に「シャドーMCP」という言葉を用い、組織のガバナンス外に置かれたMCPの状態を指します。ローカルMCPを個人が無断で導入した場合も、社外リモートMCPを組織の承認なく接続した場合も、シャドーMCPに当たります。

シャドーITと同様の構造ですが、AIエージェントに高い権限が付与され、人間による都度確認を介さず操作できる構成では、シャドーIT以上に影響が拡大する可能性があります。

MCPガバナンス設計の4つの観点

複数のガイダンスを横断すると、立場や対象範囲は異なりながらも共通するガバナンスの考え方が見えてきます。本記事では、これを4つの観点に整理します。

以下では、それぞれの観点について、具体的にどのような管理が必要になるかを整理します。

観点1：可視化（Inventory）

ガバナンスの出発点は現状把握です。リスクの評価や責任の所在の明確化のために、まず社内で使われているMCPの全体像を把握します。この把握がInventoryであり、次の「責任体制」で各MCPに所有者を割り当てる土台になります。

把握する項目：

• MCPサーバの名称・種別（ローカル／社内リモート／社外リモート）・接続先システム
• 有効化されているツール・操作の種別（読み取り／書き込み／削除／外部送信の別）
• 接続先データの分類（公開情報／社内情報／個人情報・機密情報）
• 利用しているAIエージェントと利用目的
• 承認の有無
• 所有者の割り当て状況（未割り当ての場合は要対応）

観点2：責任体制（Ownership）

MCPに関するインシデントが発生したとき、「そのMCPを誰が管理していたか」が即座に答えられる状態を作ることが目的です。責任の空白があると、問題の検知・対応・是正のいずれも遅れます。各MCPについて所有者を明確にします。また、MCP管理に関するリスク評価やインシデント対応のセキュリティ担当者を明確にします。

観点3：ポリシー設計（Policy）

MCPの導入・運用・廃止に関するポリシーを定めます。ポリシーには以下の要素が含まれます。

承認プロセス：

• 新規MCPの導入には誰の承認が必要か
• 未承認MCPの利用をどのように抑制するか

廃止・更新の管理：

• 利用されなくなったMCPの廃止基準と手順
• セキュリティアップデートの適用ルール

権限設計（Least Privilege）：

• 各MCPには業務上必要な最小限の権限のみを付与する
• 権限の定期的な見直しサイクルを定める

多段委譲（Multi-Hop Delegation）の管理

AIエージェントが複数のMCPを経由して下流システムにアクセスする多段委譲では、権限の継承関係が不透明になりやすく、統制が効きにくくなります。仕様上、MCPサーバは自身に対して発行されていないトークンを受け入れることも中継することも認められておらず、各経路で権限を適切に絞り直す設計が前提となります^[iii][vi]。

技術的な仕組みが整っても、どの経路にどの権限を委ねるかという設計・承認判断は、エージェント間の呼び出し経路と権限の流れの把握も含めて、組織のガバナンスとして別途必要です。

観点4：監査・継続的監視（Audit/Observability）

五か国共同ガイダンス（米・英・豪・加・ニュージーランド）は、追跡が困難になることを「説明責任リスク」として指摘しています^[v]。また、NSAも、ログ記録と継続的監視を推奨しています^[ii]。これらを踏まえ、いつ・誰のエージェントが・どのMCPを使い・何を実行し・どのデータにアクセスしたかを追跡可能な状態に維持します。

加えて、一定のパターンを逸脱した操作を検知する仕組み（異常なデータ量のアクセス・通常と異なる時間帯の実行など）を設けることで、問題の早期発見につなげます。

4つの観点は独立したものではなく、継続的に見直す管理サイクルとして機能します。可視化した情報を基に責任体制やポリシーを見直し、監査・監視で得た結果を次の改善につなげることが、MCPガバナンスの実効性を維持するうえで重要です。

AIエージェント側で考慮すべき観点：Human-in-the-loop

MCPガバナンス設計の4つの観点はMCPを構築・管理する側が設計すべき事項ですが、Human-in-the-loop（HITL）はMCPを利用するAIエージェント側の設計責任です。MCPサーバはツール定義や説明文を通じてエージェントの判断に影響を与えうるため、高リスクな操作（データの一括削除・外部送信・権限変更など）の前に人間の確認・承認を求めるプロセスをAIエージェントのアプリケーション層で実装します。

あわせて、AIエージェントの行動範囲を設計段階で明確に定義し、業務目的を超えた操作が起動できないようガードレールを設けることも、エージェント側の設計として重要です。

どの操作をHITLまたはガードレールによる制限の対象とするかは、五か国共同ガイダンス^[v]が示す影響度・不可逆性の考え方を参考に、以下のように整理できます。

対応の強度はリスクの大きさに応じて段階的に設計することが現実的です。

MCPガバナンスを設計する際は、エージェント側にこの観点が組み込まれているかも確認事項として含めることが望ましいです。

リスクベース管理という現実的なアプローチ

これまで整理したリスクの性質を踏まえ、ここでは種別ごとに優先すべき管理対策を示します。

ローカルMCP：まず把握する

• 利用ルールとして、導入・利用を組織に申告することを義務付ける
• 社内システムやデータへのアクセス権限の範囲を確認する
• 本番環境への接続を伴う場合は事前確認を義務付ける

ローカルMCPは組織のITシステムを経由しないため、ポリシーと申告ルールによる管理が中心となります。組織が審査したMCPを一覧化した社内レジストリや、クライアント製品が提供する許可リスト・管理設定などを活用し、「使ってよいMCP」を明確にすることで、開発者が申告・選定しやすい環境を作れます。

社内リモートMCP：集中管理する

• 個人での無断導入を禁止し、所有者と責任主体を明確にする
• OAuth 2.1ベースの認証・認可基盤と統合し、ログ・監査を厳密に実施する

社外リモートMCP：許可制で管理する

• クライアントの設定ファイルをMDMなどで配布し、承認済みMCPへの接続のみを許可する
• 未承認の社外MCPへの接続はネットワーク層（プロキシ・ファイアウォール）でも原則ブロックする
• SaaSのシャドーIT対策と同じ枠組みで管理対象に含める

社外リモートMCPについても、MCP RegistryやSaaSベンダーが公開しているレジストリを審査の起点として活用したうえで、承認したものを社内レジストリに登録することで、ローカルMCPと同じ仕組みで一元管理できます。

また、五か国共同ガイダンスが推奨するとおり^[v]、AIエージェントとMCPの展開は段階的に進めることが現実的です。まず業務影響の小さい領域（例：読み取り専用の操作、社内限定のシステム）から始め、知見を積み重ねながら展開範囲を広げていくアプローチが、持続可能なガバナンス設計につながります。

まとめ

MCPガバナンスは、技術的な設定の問題というよりも、組織として誰が何を管理し、どう意思決定するかというガバナンス設計の問題です。本記事で整理したポイントを2点にまとめます。

第1に、MCPをAIモデル管理とは別の独立した管理対象として位置づける

AIエージェントが実際に業務システムにアクセスする時代には、「AIが何にアクセスできるか」を統制することがセキュリティの核心になります。MCPサーバを、サーバ・API・SaaSと並ぶ管理単位として位置づけます。

第2に、ガバナンスの4つの観点（可視化・責任体制・ポリシー設計・監査）を段階的に整備する

すべてを一度に整備することは難しいですが、まず「可視化（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