たきびAIラボ TAKIBI · AI · LAB
🛡️サイバーセキュリティ ニュース 公開 2026.05.29

NSAがMCPセキュリティ設計指針を公開

AIエージェント自動化のトラストゾーン分離・DLP・入力検証ガイダンス解説

NSA AISCが2026年5月20日に公開した公式ガイダンス「MCP Security Design Considerations」(Ver 1.0)の要点を日本語で解説。トラストゾーン分離・DLPフィルタリング・入力検証・ロギングという4つの設計原則と、IT担当者がすぐ着手できる実務アクションをまとめます。

読了 約13分
NSAがMCPセキュリティ設計指針を公開:AIエージェント自動化のトラストゾーン分離・DLP・入力検証ガイダンス解説

2026年5月20日、米国家安全保障局(NSA)の人工知能セキュリティセンター(AISC)が「Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation」を正式公開しました。文書番号 U/OO/6030316-26、バージョン1.0、全17ページのこの公式ガイダンスは、MCPを使ったAIエージェント自動化の急速な普及がセキュリティモデルの成熟を上回っているという問題意識から生まれています。

既存のMCPセキュリティ解説は「tool poisoning」「rug pull」「サプライチェーン攻撃」といった攻撃ベクターの説明が中心です。本記事はそこから視点を変えて、NSAという公的機関が推奨する具体的な防御・設計対策に何が含まれているかを企業のIT担当者・セキュリティ担当者向けに整理します。「何が危険か」より「NSAが推奨する具体的対策は何か」を優先した読み解きガイドです。

NSAがMCPのセキュリティ指針を公開した背景

MCPはAnthropicが主導するアプリケーションレベルのプロトコルで、AI対応システムにおけるサービス間通信の標準として急速に採用が広がっています。Claude Desktop・Cursor・GitHub Copilot・Microsoft 365 Copilotといった主要ツールがすでにMCPに対応しており、企業の業務システムへの組み込みも進んでいます。

NSAのガイダンスが指摘する核心は、MCPの普及速度とセキュリティ設計の成熟度のギャップです。MCPはツール呼び出し・リソースアクセス・プロンプト処理を統合的に扱うため、従来の「人間がリクエストを発行する」前提のシステム設計とは根本的に異なるトラスト境界の問題が生じます。AIエージェントが自律的にツールを連鎖呼び出しするシナリオでは、どのコンポーネントが何をどの権限で実行しているかが従来の監査手法では追いにくくなります。

NSA AISCはこれまでもAIセキュリティに関する複数の勧告を公開してきた組織であり、今回のガイダンスは米国の重要インフラ・国防組織を主な対象としていますが、MCPを業務に導入している民間企業にとっても実用的な設計指針として参照できます。

NSAが特定した3つのセキュリティ懸念

NSAのガイダンスは、MCPアーキテクチャに固有のリスクを3つのカテゴリで整理しています。

懸念1:シリアライゼーションリスク

MCPはメッセージをJSON-RPC形式でシリアライズして送受信します。シリアライズ・デシリアライズの処理は、不正なデータ構造や予期しない型が混入したときに予期しない動作を引き起こす可能性があります。AIエージェントが外部ソース(Webページ・ドキュメント・メール本文など)から取得したコンテンツをそのままMCPメッセージに組み込む場合、その外部コンテンツに悪意ある構造が含まれていると、デシリアライズ時に問題が発生します。

懸念2:トラスト境界の曖昧さ

MCPの柔軟な設計は、どのクライアントがどのサーバーを信頼してよいかの境界が実装によって大きくばらつく可能性があります。特に、AIエージェントが複数のMCPサーバーを動的に接続・切断するマルチエージェント構成では、認証・認可のチェックが一貫して行われないリスクがあります。

懸念3:エージェント悪用

AIエージェントがMCPを通じて多くのツールやリソースにアクセスできる状況では、攻撃者がエージェントそのものを「踏み台」として悪用するシナリオが現実的になります。エージェントが外部から受け取った指示(間接プロンプトインジェクション)によって意図しないツール呼び出しを行い、データの持ち出しや権限昇格につながるリスクがあります。

NSA推奨の4つの設計原則

NSAのガイダンスは、上記のリスクに対して4つの設計原則を推奨しています。これが本ガイダンスの実務的な核心です。

原則1:データ分類ゾーンの整合

公開ツールは公開データのみにアクセスできるように設計し、機密データへのアクセスは明示的に制御・分離することを推奨しています。

実装方針として意識すべきは、ツールと扱えるデータの対応関係を設計段階で定義することです。「このMCPサーバーはどの分類のデータを扱うか」を明文化し、分類外のデータへのアクセスリクエストが来た場合に拒否する仕組みを作ります。

設計の整理例(データ分類ゾーンのマッピング)

[公開ゾーン] MCPサーバーA
  - アクセス可能: 公開Webページ、製品マニュアル(社外公開済)
  - アクセス不可: 社内文書、顧客情報、認証情報

[社内一般ゾーン] MCPサーバーB
  - アクセス可能: 社内Wiki(一般公開)、会議資料(特定部署向けを除く)
  - アクセス不可: 人事情報、財務詳細、セキュリティ設定情報

[機密ゾーン] MCPサーバーC
  - アクセス可能: 明示的に承認済みのリソースのみ
  - 追加要件: アクセスのたびに承認ログを記録

原則2:外部MCP接続に対するフィルタリングプロキシまたは企業DLP

外部のMCPサーバーに接続する場合、リソースURLとアクセスメソッドを厳格に固定したフィルタリングプロキシ、または企業のDLP(Data Loss Prevention)ポリシーを経由させることを推奨しています。

社内のAIエージェントが外部のMCPサーバーを呼び出す際、そのトラフィックがDLPの監視対象から外れることは避けるべきです。既存のWebフィルタリングやDLPが「人間のWebブラウズ」を前提に設計されている場合、エージェントのMCP通信が抜け穴になる可能性があります。

原則3:すべてのツール呼び出し・モデル実行リクエストの入力検証

MCPを経由してツールに渡されるすべての入力を、スキーマ・期待値範囲・意図されたコンテキストに対して検証することを推奨しています。

これは単純な「危険な文字列のサニタイズ」を超えた概念です。「この引数は今のコンテキストで要求されるべき値の範囲内か」という検証が含まれます。たとえば、ファイル読み取りツールへの引数がユーザーの業務コンテキストから逸脱したパス(/etc/passwd や社外向けストレージのパス等)を指している場合、それを実行前に検知・拒否する仕組みが求められます。

# 入力検証の概念例(スキーマ + コンテキスト検証)
from pydantic import BaseModel, validator
from typing import Literal

class FileReadRequest(BaseModel):
    path: str
    context_user_id: str

    @validator('path')
    def validate_path_scope(cls, path, values):
        # ユーザーがアクセス可能なディレクトリのみ許可
        allowed_prefixes = [f"/workspace/users/{values.get('context_user_id')}/"]
        if not any(path.startswith(p) for p in allowed_prefixes):
            raise ValueError(f"パスがユーザーのスコープ外です: {path}")
        return path

原則4:ロバストな可観測性(全ツール・モデル呼び出しのログ記録)

すべてのツール呼び出しとモデル実行リクエストをログに記録することを推奨しています。NSAはこれを「可観測性(observability)」という言葉で表現しており、単なるエラーログではなく正常時も含めた全呼び出しの記録を求めています。

インシデント発生時に「エージェントが何をいつ誰のリクエストで呼び出したか」を遡って調査できることが、MCPを使ったシステムのセキュリティ運用の基礎となります。

ログに記録すべき最小限の項目(NSAガイダンスに基づく整理)

- タイムスタンプ(UTC)
- リクエスト元のエージェントID / セッションID
- 呼び出したMCPサーバーとツール名
- 渡した引数(機密情報はマスキング)
- 受け取ったレスポンスのサイズとステータス
- 認可チェックの結果(許可 / 拒否)

企業のIT担当者がすぐ着手できる実務アクション

NSAのガイダンスを参照しながら、今すぐ着手できる確認・対応のポイントを整理します。

Step 1:MCP導入状況の棚卸し

社内でMCP対応ツール(Claude Desktop・Cursor・GitHub Copilot・Microsoft 365 Copilot等)を業務利用しているユーザー・部署を把握します。個人がPCに導入しているケースも含めて把握できているかを確認してください。

Step 2:外部MCP接続の可視化

現在のネットワーク監視・DLP設定が、AIエージェントのMCP通信を捕捉できているか確認します。「人間のブラウザ通信」と同じ扱いになっているか、エージェント固有のトラフィックパターンが識別できているかが確認ポイントです。

Step 3:ツール権限の整理

社内で運用中のMCPサーバー(社内ツール連携・ファイルシステム接続等)について、どのエージェントがどの権限でアクセスできるかを明文化します。LLMエージェントの過剰権限設計の観点から、不要な権限が付与されていないかを確認してください。

Step 4:ログ・監査証跡の確認

MCPツール呼び出しのログが現在の監査ログに含まれているかを確認します。含まれていない場合は、どのレイヤー(MCPサーバー側・ゲートウェイ側・エンドポイント側)でログを取得するかを設計します。

よくある質問(FAQ)

FAQ

NSA MCP セキュリティガイダンス FAQ

企業のIT・セキュリティ担当者からよく寄せられる質問

MCPとは何ですか?

MCP(Model Context Protocol)は、Anthropicが提案しAI業界に広く採用されているアプリケーションレベルのプロトコルです。AIエージェントと外部ツール・データソース・APIをつなぐ「共通言語」として機能し、Claude Desktop・Cursor・GitHub CopilotなどのAIツールが外部サービスと連携する際に使われています。MCPを使うことで、AIエージェントはWeb検索・ファイル操作・データベースクエリ・外部APIコールなどを標準化された方法で実行できます。

どの製品がMCPを使っていますか?

2026年5月時点で、Claude Desktop(Anthropic)・Cursor・GitHub Copilot・Microsoft 365 Copilot・VS Code(Copilot拡張)・Zed エディタなど、主要AIツール・エディタの多くがMCPに対応しています。また、社内ツールをMCPサーバーとして公開する形で業務システムにAIエージェントを統合するケースも増えています。自社でどのMCP対応ツールが使われているかは、情報システム部門による棚卸しが必要です。

NSAの勧告は日本企業も対象になりますか?

NSAのガイダンスは米国政府・重要インフラ向けの文書ですが、MCPというプロトコルの技術的な設計上のリスクと対策を論じているため、日本企業にも等しく適用できる内容です。日本ではIPAやJPCERT/CCが類似のガイダンスを公開するケースもありますが、本ガイダンスが先行して公開されている現時点では、NSA文書を参照しながら社内ポリシーへの反映を検討することが有効です。

MCPサーバーを社内に構築している場合、何を優先すべきですか?

NSAガイダンスに基づくと、まず「どのデータ分類ゾーンのリソースにアクセスできるか」をMCPサーバーごとに明文化することが出発点です。次に、全ツール呼び出しのログ記録(可観測性)を実装します。ログがなければ、インシデント後の調査が困難になります。最後に、入力検証をMCPサーバー側に組み込むことで、不正なパラメータが渡された際に実行前に拒否できるようにします。

まとめ

NSA AISCが公開した「MCP Security Design Considerations」(2026年5月20日、Ver 1.0)は、MCPの急速な普及がセキュリティ設計の成熟を上回っている現状への警告です。ガイダンスが特定した3つの懸念(シリアライゼーションリスク・トラスト境界の曖昧さ・エージェント悪用)に対して、データ分類ゾーン整合・DLPフィルタリング・入力検証・ロバストな可観測性という4つの設計原則を推奨しています。

MCPを使ったAIエージェント自動化は今後さらに広がっていきます。「既存のセキュリティ対策で十分」という前提を見直し、MCP固有のトラスト境界設計と可観測性の確保を優先的に着手することが、企業のIT・セキュリティ担当者に求められる対応です。

関連記事

参考リンク

次はこれ!

この記事でMCPセキュリティの基本方針をつかんだら、次は実際のAIツール選びの判断基準を整理しておくことをおすすめします。Claude・ChatGPT・Geminiをはじめ、主要AIツールの自腹検証レポートを note で公開しています。セキュリティ設計と並行してツール選定の軸を固めておくと、業務導入の判断がスムーズになります。

noteで続きを読む