NSAが警告する、AIエージェント導入の落とし穴 — 米国家安全保障局の公式ガイダンス17ページを完全読解【社内導入チェックリスト付き】

2026年5月、アメリカのNSA(国家安全保障局)が、AIエージェントの中核技術「MCP」のセキュリティについて17ページの公式ガイダンスを公開しました。

NSAといえば、世界最大級のシグナル情報機関。そのNSAのAIセキュリティセンター(AISC)が、カーネギーメロン大学ソフトウェア工学研究所(SEI)の協力を得て、「AIエージェントを業務システムにつなぐとき、何がどう危ないのか」を政府機関の視点で体系的にまとめた文書です。

英語圏ではセキュリティベンダー各社がこぞって反応した大ニュースですが、実務向けにまとまった日本語の解説は、執筆時点では主要媒体(Zenn/Qiita/note/企業ブログ)でまだごく限られています。

本記事では、原文PDF(U/OO/6030316-26)を全ページ読み込み、

• NSAが挙げる8つの構造的リスク

• 実際に起きた攻撃事例(NSAが実名で挙げたもの+2026年上半期の最新事例)

• NSAの推奨対策9項目の「日本企業向け実務翻訳」

• そのまま社内のセキュリティレビューや稟議に使える導入チェックリスト

• 誰に何を説明するか(利害関係者ごとの視点)、今このタイミングで入れるべきかの論評、この先3年の予測

まで、一気に解説します。「ウチもAIエージェントを入れたいが、セキュリティ部門を説得できない」「情シスとして何をチェックすればいいか分からない」という方は、この1本で、NSAガイダンスを土台にした社内議論の材料が手に入ります。

※本記事は、AI(Anthropic Claude)を用いてNSA原文の読解・下調べを行い、公開前に人間が構成・出典・表現をレビューしています。

この記事で出てくる用語(先に3分で)

専門用語には最初に一言の説明をつけます。迷ったらここに戻ってきてください。

（用語 ／ 一言でいうと）

• MCP … AIを外部のツールやデータにつなぐ「共通の配線規格」。AIエージェントのUSB-Cと呼ばれる

• AIエージェント … 質問に答えるだけでなく、ファイル操作・検索・送信などを自分で「実行」するAI

• LLM … ChatGPTやClaudeのような大規模言語モデル。AIエージェントの「頭脳」

• ツール … AIが呼び出せる機能(ファイル読取、DB照会、メール送信など)

• トークン … サービスにアクセスするための「鍵」。漏れると本人になりすませる

• RBAC … 役割ベースのアクセス制御。「この役割の人はここまで」と権限を分ける仕組み

• プロンプトインジェクション … AIへの指示文に悪意ある命令を紛れ込ませ、AIを乗っ取る攻撃

• サンドボックス … プログラムを隔離された箱の中で動かし、外に影響を出させない仕組み

• SIEM … 各所のログを1か所に集めて異常を監視するセキュリティ基盤

• エージェント・ウォッシング … 従来のチャットボット等を、実態が伴わないまま「AIエージェント」と名前だけ付け替えて売ること(Gartnerの指摘)

本記事の読み方 — 「事実」と「筆者の考察」を分けています

本記事の記述を実務の判断に使っていただけるよう、次のルールで書き分けます。

• 【事実】: 出典・NSA原文に基づく記述。特に「NSAの指摘」と明記した箇所は原文の要約です

• 【考察】: 「日本企業ならこう読む」「筆者は〜と見る」などは、事実をもとにした筆者(原典ケイ)の解釈・予測です。事実そのものと区別してお読みください

特に第11章(賛成・反対の論評)と第12章(将来予測)は考察の比重が高いため、段落単位で【事実】【考察】を明示します。

第1章 MCPとは何か — 3分でわかる「AIエージェントのUSB-C」

MCP(Model Context Protocol)は、AIが外部のツールやデータにつながるための共通規格です。2024年11月にAnthropic社がオープンソースとして公開しました。

「AIエージェントのUSB-C」とたとえられるのは、つなぎ方を1つに決めておけば、相手が何であっても同じ差し口で扱えるからです。 これまではツールごとに個別の接続方法を作る必要がありました。普及の度合いは、公開レジストリ上のMCPサーバーが6.7万個規模で確認されている(第2章で後述)ことからうかがえます。

NSAの文書自身が挙げている例がわかりやすいので、そのまま紹介します。

登場人物は4つだけ覚えれば十分です。

（登場人物 ／ 役割 ／ 例えるなら）

• ユーザーアプリ(UI) … 人間との窓口　→　受付

• LLM(AIモデル) … 意図を解釈し、指示を組み立てる　→　司令塔

• MCPクライアント … 指示をMCPメッセージに変換　→　通訳

• MCPサーバー+ツール群 … 実際の作業(検索、DB照会、実行)　→　現場の作業員

便利さの源泉は「AIが実行時に新しいツールを自分で見つけて呼び出せる」柔軟性にあります。そして、NSAが問題視するのもまさにその柔軟性です。

NSAは重要な指摘をしています。MCPは従来のWebと通信の向きが逆転しているのです。従来は「クライアントがサーバーにデータを要求する」のが基本でしたが、MCPでは「サーバー側がクライアントに問い合わせ、時にはクライアントのためにアクションを実行する」ことが期待される。この逆転が、これまでの防御では追跡しきれない新しい攻撃経路を生んでいる——これが文書全体を貫く問題意識です。

⚠️ここで誤解しやすい点を2つ補っておきます。

ひとつは、これは「社外のサーバーが社内のPCへ新しく通信を張ってくる」という意味ではありません。 ファイアウォールで外からの接続を止めれば済む、という話ではないのです。すでにこちらから張った接続の上で、やり取りの主導権が逆を向く——だから境界防御をすり抜けます。

もうひとつは、「MCPサーバー」は自社が立てるものとは限らないことです。ベンダーが提供するもの、有志が公開しているもの、社内で立てたもの、いずれもMCPサーバーです。そして本記事の後半で扱うリスクの多くは、「外部の誰かが用意したMCPサーバーを信用して繋いだ場合」に生じます。 先ほどの表の「現場の作業員」という例えは役割の説明であって、身内であることを意味しません。

「通信の向きが逆転する」とは、具体的に何か — sampling と elicitation

抽象的に聞こえるので、MCPの公式仕様で確認できる2つの機能を挙げます。どちらもサーバー側から働きかける仕組みです。

① sampling(サンプリング) — サーバーが、クライアント経由でAIモデルに推論を要求できる

公式仕様はこう書いています。

つまりMCPサーバーが、クライアントを経由してAIモデルへの推論を要求できるということです。サーバー側はAPIキーを持つ必要がありません(with no server API keys necessary)。

ただし、勝手に使われるわけではありません。 同じ仕様に次の一文があります。

主導権はクライアント側に残る設計です。 サーバーが「このモデルを使いたい」と希望(hints)を出すことはできますが、最終的にどのモデルを使うかはクライアントが決めます。そのうえで仕様は「LLM呼び出しがサーバー機能の内側に入れ子で起きる」と説明しています。

なお、この先に出てくる「SHOULD」「MUST NOT」は、規格文書で意味が定められた用語です(RFC 2119)。SHOULD＝「そうすべきだが、正当な理由があれば従わなくてよい」／MUST NOT＝「してはならない」。日常英語の「〜すべき」より弱い意味で、SHOULDに従わなくても仕様違反にはなりません。 ここを取り違えると、製品の安全性を過大に見積もることになります。

⚠️そのうえで、ここが実務上の分かれ目です。 人間の関与について、仕様には次の記述があります。

「SHOULD」であって「MUST」ではありません。 人間の承認画面を挟まない実装でも、仕様違反にはならないということです。使っているクライアントがこれをどう実装しているかは、製品ごとに確認するしかありません。

② elicitation(エリシテーション) — サーバーが、クライアント経由でユーザーに追加入力を求められる

2025年6月版の仕様で新しく入った機能です(仕様自身が「今後変わりうる」と注記しています)。

サーバーがユーザーに直接つながるのではなく、あくまでクライアントを通じて要求が届く点はsamplingと同じです。サーバーがJSONスキーマで入力フォームの形を指定し、ユーザーは「承諾(accept)/拒否(decline)/取消(cancel)」の3つで応答します。

この3つが分かれていることには、実務上の意味があります。 サーバー側からは「はっきり拒否された」のか「画面を閉じられただけ」なのかが区別できます。仕様は後者について「あとで再び尋ねる」実装例を挙げています(Cancel: Handle dismissal (e.g., prompt again later))。キャンセルは明示的な拒否ではないため、実装によっては後から再提示される扱いが可能ということです。「面倒だから閉じる」で済ませていると、同じ要求に何度も向き合うことになりえます。

そして機微情報の扱いは、こちらでは「MUST NOT(してはならない)」と書かれています。

【考察】この2つを並べると、NSAの言う「通信の向きの逆転」が具体的な形で見えてきます。MCPサーバーはもはや「呼ばれて答えるだけの相手」ではなく、こちらのAIを動かし、こちらのユーザーへの問いかけを起こせる存在です(いずれもクライアントを経由します)。第4章で見る8つのリスクは、この構造から生まれています。

⛔そしてここで、最も重要な注意があります。「MUST NOTだから機微情報は要求されない」とは考えないでください。 仕様の禁止規定が効くのは、仕様を守る相手に対してだけです。本章の前半で述べたとおり、リスクの多くは外部の誰かが用意したMCPサーバーを信用して繋いだ場合に生じます。悪意あるサーバーは、当然この「MUST NOT」を守りません。

つまり実務上はこうなります。

SHOULDは実装確認、MUST NOTは違反検知が必要で、どちらも「仕様に書いてあるから安心」にはなりません。

どちらも「仕様に書いてあるから安心」にはなりません。 前者は実装を確認する話、後者は違反を検知する話であり、やるべきことが違うだけです。

そしてもう1点、同じ仕様書の中で「SHOULD」と「MUST NOT」が使い分けられていることは実務では見落とせないと筆者は考えます。samplingの人間の関与は推奨にとどまり、elicitationの機微情報要求は明確な禁止です。ベンダーに確認するときは「仕様に沿っています」という回答では足りず、SHOULDの項目を自社製品でどう実装したかまで聞く必要があります(第8章に、これを確認するための質問を用意しています)。

第2章 なぜNSAが動いたのか — 実際に起きたこと

「理論上の懸念でしょ?」と思うかもしれません。違います。NSAの文書は「これらのリスクは既に具体化した(These theoretical risks have now been made concrete)」と断言しています。実際、2025年から2026年にかけて、MCP関連のセキュリティ事故は立て続けに起きています。

代表的なものを時系列で挙げます。

• 2025年4月: WhatsApp連携MCPで、悪意あるMCPサーバーがツール説明文を使ってAIの挙動を乗っ取り、チャット履歴を外部に送信。しかもインストール時は無害なふりをして、2回目の使用後に悪意ある動作に切り替わる巧妙さでした(NSA文書も実名で言及/実証したInvariant Labsの報告)

• 2025年5月: GitHub連携MCPで、公開Issueに仕込まれた指示文(プロンプトインジェクション)によりAIが操られ、プライベートリポジトリの中身が公開リポジトリに流出(NSA文書も実名で言及/Invariant Labsの報告)

• 2025年7月: mcp-remote(43.7万ダウンロード)にOSコマンドインジェクション脆弱性(CVE-2025-6514、深刻度9.6)。ダウンロード数の出典は、下記9月の項に挙げるAuthZedの侵害タイムラインです(CVE情報そのものには利用規模の記載がないため)

• 2025年9月: メール送信サービスを装った「偽Postmark MCPサーバー」が、経由する全メールを攻撃者にBCC送信していたことが発覚(AuthZedの侵害タイムラインに整理あり)

• 2025年10月: MCPホスティング大手のビルド設定の穴から、クラウド基盤(Fly.io)のAPIトークンが1本流出し、3,000超のアプリ(その多くがホスト型MCPサーバー)を攻撃者が制御できる状態に(同タイムライン)。鍵が3,000本漏れたのではなく、1本の鍵が3,000超を開けられたという構造です

• 2026年2月: 健康管理サービスの正規MCPプロジェクトを装った偽物が、情報窃取マルウェア(StealC)を配布(同タイムライン)

• 2026年3月: nginx-ui のMCP統合に認証なしのコマンド実行穴(CVE-2026-33032、深刻度9.8)

さらに研究者による大規模調査では、6つの公開レジストリ上の6.7万個のMCPサーバーを調べたところ833個に脆弱性が確認されています(arXiv:2510.16558)。

ポイントは、これらの多くが「高度なハッキング」ではないことです。正規の機能が、設計上の想定不足によってそのまま攻撃経路になっている。だからこそNSAは「エンドポイントで個別にパッチを当てれば済む問題ではなく、設計から運用まで全ライフサイクルの見直しが必要」と警告しました。

社内でAIエージェントの話が出たら、まず自分にこう問うてみてください。

いま即答できなくても大丈夫です。この記事を読み終える頃には、この問いに答えるための材料が一式揃います。

この先では、NSA文書の中身を全項目読み解きます。

• NSAが構造的リスクとして挙げた8項目の正体(あなたの会社のどこに刺さるか付き)

• 推奨対策9項目を「日本企業で明日から何をするか」に翻訳

• 社内導入チェックリスト30項目(コピペでセキュリティレビュー・稟議資料に使える形式)

• 完璧を待たずに始める「30日ガードレール」導入ロードマップ

• AIエージェント製品の選定でベンダーに聞くべき14の質問(曖昧な回答なら本番導入は見送り)

• NSAの警告を商機に変えつつある「エージェントファイアウォール」市場の最新地図

• 利害関係者ごとの視点(誰にどの章を渡すか)、「今入れるべきか」の賛否論評、この先3年の予測