政府がMCPに『待った』——NSAのセキュリティ指針が示す、エージェント接続の新しい脅威モデル

MCP（Model Context Protocol）は、この1年でAIエージェントとツール／データをつなぐ事実上の標準になりました。その普及に、いま政府機関が正面から注意を促しています。2026年5月、米国NSA（国家安全保障局）の AIセキュリティセンター（AISC） が、サイバーセキュリティ情報シート（CSI）「Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation」を公開しました（NSAプレスリリース）。

homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日々 MCP の導入設計を詰めています。本稿では、この指針が名指しした「MCP特有の新しいリスク」と推奨事項を分解し、日本企業が本番導入の前に何を統制設計へ落とすべきかを整理します。基礎解説の焼き直しではなく、**「政府がなぜ今わざわざ警告したのか」**に焦点を当てます。

「従来のセキュリティ対策では足りない」という警告

NSA の指針で最も重要なのは、その前提の置き方です。認証（authentication）・認可（authorization）・入力検証（input validation）といった従来のサイバーセキュリティ原則は依然として必要である——ここまでは当然です。しかし指針は、それだけでは不十分だと明言します。

エージェント型AI、とりわけMCPを備えたシステムは、次のような新しく、システミックな（構造的な）リスクを持ち込むからです。

• 動的なツール呼び出し（dynamic tool invocation）: どのツールをいつ呼ぶかを、事前定義ではなくモデルが実行時に決める。
• 暗黙の信頼関係（implicit trust relationships）: エージェントがツールの返り値を「正しい入力」として受け取り、次の判断に反映する。
• 文脈共有（context sharing）: 一つのMCP環境内で共有された情報が、接続された複数のサービスへ意図せず伝播しうる。

指針は、確立された既存の防御戦略ではこれらの新しいリスクを十分に扱えないと指摘します。MCPは業務・金融・法務・ソフトウェア開発など幅広い領域で使われ始めており、個人情報（PII）の照会のような機微な処理にも入り込んでいる——だからこそ、本番・高リスク環境で使う前に埋めるべきギャップがある、というのが政府側の立場です。

核心概念：「MCPサーバーは信頼境界である」

指針の考え方を一言で言えば、「MCPサーバーは信頼境界（trust boundary）である」という視点です。エージェントがMCP経由でツールを呼び出すとき、返ってきた結果をその後の推論と行動を左右する権威ある入力として受け入れています。つまりツールの出力は、単なるデータではなく「エージェントの意思決定に食い込むもの」です。

ここが従来のAPI連携との決定的な違いです。人間が使うAPIなら、返り値がおかしければ人が気づいて止められます。しかしエージェントは、汚染された出力・偽装された指示（間接プロンプトインジェクション）をそのまま次の行動計画に取り込み、権限を持ったまま実行に移す恐れがあります。「どのツールを信頼し、その出力をどこまで権威あるものとして扱うか」を設計しないまま接続を増やすことが、最大の危険だという指摘です。

NSAが名指しした具体的リスク

指針および実務家の分析が整理する主なリスクは、次のとおりです。

英ReedSmith も、この指針を**「本番・高リスク環境でMCPを採用する組織向けの実務的推奨」**と位置づけ、コンプライアンス上の含意を強調しています（解説）。セキュリティ実務の側では、この指針を OWASP MCP Top 10 の項目にマッピングして「どう検査するか」に落とす動きも始まっています（Equixlyの整理）。

推奨されるのは「信頼レベルで分ける」設計

指針が示す対策の軸は、信頼レベルによる分離（segmentation）と最小権限です。実務に落とすと次のようになります。

1. 信頼レベルで系統を分ける: 公開情報を扱うツールと、機微・機密・規制対象データに触れるツールを明確に分離する。同じエージェントに何でもつながせない。
2. 不要なアクセスは明示的に遮断する: MCPツールが機微なファイル・内部ネットワーク・その他リソースにアクセスする必要がないなら、そのアクセスは明示的にブロックする（最小権限の徹底）。
3. ツールを最も厳格なレビュー対象にする: MCPツールは、デプロイ前にコード監査を含む最も厳しいレビュー工程を通す。
4. 高影響アクションに人の承認を挟む: 影響の大きい操作には human-in-the-loop の承認ゲートと、粒度の細かい権限境界を設ける。
5. 認証情報のライフサイクルを制御する: トークンに期限と失効を持たせ、使い回しを避ける。

プロトコル側も動いている：7月28日の仕様更新

見落としてはならないのは、NSAが脅威を整理したのとほぼ同時期に、MCPプロトコル自身のセキュリティ強化も進んでいる点です。2026年7月28日に公開予定の次期仕様のリリース候補（RC）には、認可（authorization）ハードニングとして、iss パラメータの検証必須化（RFC 9207準拠）や OAuth 2.0／OpenID Connect 実務との整合など6件のSEPが含まれます（MCP公式ブログ）。ステートレス化を含む仕様側の変化は、別稿「MCPの2026年進化」で扱ったとおりです。

つまり、いまMCPのセキュリティは**「政府の設計指針」と「プロトコルの認可強化」の両輪で成熟に向かっています。ただし重要なのは、仕様が認可を固めても、「そのツールで何をしてよいか」という運用レベルの認可・承認・監査は企業側で設計し続ける必要がある**ことです。プロトコルは接続の入口を固めますが、業務上の意思決定境界を引くのは、依然として導入する側の責任です。

homulaの観点：指針を「統制の設計図」に変える

NSAの推奨は、homula が Agens で設計している統制と正面から重なります。読み替えると、こう対応します。

• 信頼レベルで分ける／不要アクセスを遮断する → どのエージェントが、どのツール・データに到達できるかを共通基盤で一元管理する。homula の Agens は、MCPを活用したエンタープライズ向け統合プラットフォームとして 200以上のツールと構築ゼロで接続し、接続点を場当たり的に増やさず、信頼境界を設計可能な形にまとめます。
• 高影響アクションに承認を挟む／認証情報を制御する／監査する → これはまさに Agens Control の領分です。承認フロー・DLP・5年分の監査ログ・RBAC をセットで提供し、「誰が・何に・どの権限で・何をしたか」を横断的に追える状態をつくります。NSAが言う「人の承認ステップ」「トークンの失効・期限」「信頼レベルの分離」を、個別実装ではなく組織の統制レイヤーとして実装できます。

この論点は過去記事とも地続きです。トークンや秘密の扱いは無人エージェントの秘密管理で、企業管理の認可はMCPの企業管理認可（EMA）で、それぞれ掘り下げています。

導入の順序としては、(1) 1業務でMCP接続のPoCを回し、そのツールが触るデータの信頼レベルを棚卸し → (2) 機微データに触れる系統だけ分離し、高影響操作に承認ゲートと監査を Agens Control で設計 → (3) 横展開、が無理のない道筋です。homula の AIエージェント・ブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で行い、この「信頼境界の棚卸し」を最初の一歩として素早く形にします。

まとめ

NSAのMCPセキュリティ指針が突きつけたのは、シンプルですが重い事実です——従来の認証・認可・入力検証は必要だが、エージェントとMCPには十分ではない。動的なツール呼び出し・暗黙の信頼・文脈共有という新しいリスクは、「MCPサーバーは信頼境界である」という視点と、信頼レベルによる分離・最小権限・人の承認・トークンの失効・厳格なレビューという、地に足のついた設計でしか埋められません。

プロトコル側の認可強化（7月28日の仕様）と、政府の設計指針。この両輪が同時に動いている今こそ、接続を増やす前に「何を信頼し、誰が何をしてよいか」を統制として設計し直すタイミングです。MCPを本番・全社へ進める日本企業にとって、この設計こそが安全な拡張の前提になります。

---

MCPの導入は「つなぐ」から「安全に統制する」フェーズへ移りました。自社のどのツールが、どの信頼レベルのデータに触れているか——その棚卸しと境界設計を早めに始めることが、安全な全社展開への近道です。

無料相談を予約する

Agens Controlで承認・監査・ガバナンス設計を見る

MCP活用支援の詳細を見る