8月8日、Techstrong.AIが「The MCP & AI Governance Gap: Eight Problems Enterprises Are Scrambling to Solve」と題した記事を公開した。企業でのMCP（Model Context Protocol）導入が急加速する一方、IT・セキュリティ部門が「何が何につながっているか」すら把握できないガバナンスの空白が広がっており、記事はその実態を8つの問題として整理している。技術の普及速度がガバナンス整備を大幅に追い越した今、このギャップは単なる管理上の不備ではなく、データ流出・コンプライアンス違反・サプライチェーン攻撃につながりうる深刻なリスクとして認識されつつある。

技術の普及がガバナンスを追い越した

MCP（Model Context Protocol）は、AIエージェントが社内のSaaSツールやデータと連携するための標準プロトコルだ。2026年に入り採用が急加速しており、さらに最近の仕様アップデートでステートレスMCPサーバーが導入され、任意のサーバーが任意のリクエストを処理できるようになったことでスケーラビリティが向上し、普及に拍車がかかっている。

問題は、技術の普及速度がガバナンスの整備速度を大幅に上回っている点だ。エンジニアが静かにAIエージェントと社内システムをMCPで接続し続けた結果、IT・セキュリティ・エンジニアリングのリーダーたちが「何が何につながっているか、誰が承認したか、データがどこに流れたか」を把握できない状況が生まれている。記事ではこれを「ガバナンスギャップ」と呼んでいる。

以下、企業が今まさに対処しようとしている8つの問題を紹介する。

最も深刻な問題：ツール自体が改ざんされうる

8つの中でセキュリティチームが最も頭を悩ませているのが「Problem 5: ツールの改ざんリスク」だ。記事の著者はこの問題を特に強調しており、他の問題が「管理不備」の範疇にとどまるのに対し、Problem 5は能動的な攻撃ベクターになりうる点で質的に異なると指摘している。

MCPサーバーが提供するツールは静的ではなく、接続後に変更されることがある。軽微な場合は「コンテキストドリフト」によるパフォーマンス低下にとどまるが、深刻なケースではMCPラグプル攻撃が発生する。これは、サーバーがAIクライアントに接続した後にツール定義を悪意ある内容に書き換え、エージェントにユーザーが意図しない操作（データ窃取、正規に見える経路を使ったデータ流出、複数の呼び出しを連鎖させた制御回避など）を実行させる攻撃だ。

オープンソースのMCPサーバーのサプライチェーンリスクはまだほとんどレビューされていない。記事は対策として「ツール定義の変更監視」「サーバーの既知の安全な状態へのピン留め」「プロンプトインジェクション検出」の3点を挙げている。

残り7つの問題：一覧

Problem 1: 何が動いているか誰も把握していない
ほとんどのIT・セキュリティチームは自組織で使われているMCPサーバーのリストを出せない。MCPサーバーは開発者のローカルマシン、クラウド、オープンソースと散在しており、内部MCPレジストリ（承認済みサーバーの一元管理）が必要だ。

Problem 2: 可視性がない
MCPはフォレンジック分析に使えるログをデフォルトで提供しない。「どのツールが呼ばれたか」「PII（個人識別情報）がAIモデルに流れたか」といった基本的な問いに答えられず、GDPR・HIPAA・EU AI Actといったコンプライアンス要件に対応できない。

Problem 3: アクセスが「全か無か」
MCPには「このチームはこのツールを使えるが、あのチームは使えない」というロールベースの制御機構が組み込まれていない。結果として、CRMに幅広い権限を持つ社員がAIエージェントに接続すると、そのエージェントが意図せずデータを破壊的に編集してしまう可能性がある。

Problem 4: 移動する機密データが無保護
PII・PHI（医療情報）などの機密データがAIクライアントに流れることを防ぐ仕組みがない。2026年のUsercentrics「Digital Trust Report」によれば、**グローバル消費者の47%**が、企業のAIデータ取り扱いへの懸念を理由に過去6カ月でサービス解約などの行動を取っている。データはソースシステムを出る前にフィルタリング・匿名化・ハッシュ化すべきだという。

Problem 6: アイデンティティ管理がスケールしない
MCPはOAuthをオプションとして提供しているに過ぎず、共有サービスアカウントが使われると個人のアクションを追跡できない。既存のSSO・SCIM・Okta・EntraなどのアイデンティティインフラとMCPを接続する必要がある。

Problem 7: 非エンジニアが管理されないまま放置される
営業・財務・カスタマーサクセスなどの非技術系ユーザーも急速にMCPを使い始めている。エンジニアと異なり、彼らには「何が安全か」の判断基準がない。ITが承認済みサーバーへのアクセスをプロビジョニングし、「安全に探索できる範囲（bounded freedom）」を提供する必要がある。

Problem 8: コストが突然顕在化する
MCPサーバーの利用が増えると、不要なデータやツール呼び出しによるトークン消費が膨らみ、AI予算を圧迫する。チームやワークフローへのコスト帰属と使用量上限の設定が必要だ。

解決策の方向性：MCPゲートウェイ

記事は8つの問題に共通する根本原因として「MCPを安全に大規模展開するためのインフラが、ほとんどの組織に存在しない」点を挙げる。

対応が進んでいる組織の共通点は、AI採用を遅らせたことではなく、人とMCPインテグレーションの間にガバナンスレイヤー（MCPゲートウェイ）を構築したことだ。このゲートウェイがインベントリ・可視性・アクセス制御・データ保護・セキュリティ・アイデンティティ・コスト管理を一元的に提供する。記事の著者はゲートウェイの役割を「セキュリティ機能を提供するだけでなく、企業がAIにYesと言える自信を与えるもの」と表現している。

具体的な実装アプローチとしては、すべてのMCPトラフィックを単一の制御ポイントに集約するリバースプロキシ型のゲートウェイが現実的な選択肢として挙げられる。この構成により、既存のOPA（Open Policy Agent）などのポリシーエンジンや、SIEMへのログ転送、既存IdPとの統合が可能になる。※編集部の考察：オープンソースの実装としてはEnvoy Proxyベースの拡張や、MCP仕様に対応したカスタムミドルウェアの開発事例が海外コミュニティで報告されはじめているが、エンタープライズ向けの成熟したOSS製品はまだ黎明期にある。

APIとの重要な違いとして、MCPはバージョンが固定されておらずサーバーが動的に変化することも、ガバナンスを複雑にする要因の一つだ。従来のAPIゲートウェイがスキーマの静的な検証を前提としているのに対し、MCPゲートウェイはツール定義の変化を継続的に監視する動的な検証機構を持つ必要がある点で、設計上の要件が根本的に異なる。

詳細はThe MCP & AI Governance Gap: Eight Problems Enterprises Are Scrambling to Solveを参照していただきたい。