エージェントが扱うコンテキストは、数年後も価値を持ち続ける。いま傍受された暗号化通信は、将来の量子コンピュータで復号される恐れがある。

この記事では、Model Context Protocol（MCP）向けの量子耐性セキュリティ設計を解説する。Harvest Now, Decrypt Later（HNDL）の脅威、Gatewayを中心としたアーキテクチャ、NIST標準アルゴリズムの選び方まで、実務で使える観点に絞って整理する。

この記事でわかること

  • HNDLがAIエージェントの通信を標的にする理由
  • MCP Gatewayが担う役割とゼロトラストの実装方法
  • ML-KEM・ML-DSAを使ったハイブリッド暗号化の考え方
  • Shadow MCPの棚卸しと運用上の注意点

HNDLがMCP通信を狙う理由

HNDL（Harvest Now, Decrypt Later）は、いま暗号化された通信を保存し、将来の計算能力で復号する攻撃だ。攻撃者は今日の通信を解読する必要はない。数年後に量子コンピュータが実用化されれば、保存済みのデータを一気に読み出せる。

通常のWebトラフィックは短命だが、MCP経由のAIコンテキストは違う。ソースコード、個人情報（PII）、社内の戦略文書など、長期間機密性を保つデータがエージェントのセッションに流れる。Cloud Security Allianceの調査でも、こうしたデータは「将来日付の負債」として位置づけられている（参考）。

MCPの通信がRSAや楕円曲線ディフィー・ヘルマン（ECDH）などの古典暗号に依存している場合、保存されたパケットは将来の標的になる。エージェントが本番運用に入った今、このリスクは実験段階の話ではない。

プロンプト注入以外の脅威

MCPのセキュリティ議論はプロンプト注入に偏りがちだ。しかし実務上は、Confused Deputy問題の方が深刻になることがある。高い権限を持つエージェントが、不正なツール呼び出しを実行してしまうケースだ。

輸送層の設計も攻撃面を広げる。STDIO（標準入出力）トランスポートはローカル開発向きで、ゼロトラストに必要なきめ細かい認証を備えない。リモートのネットワークトランスポートに切り替えると、暗号化が弱い場合は中間者攻撃のリスクが増える。OWASP AI Security Projectでも、ツール呼び出しインターフェースの悪用が整理されている。

誰が・何がツールを起動したかを検証しないままエージェントを動かすと、エージェントは事実上の人形になる。

MCP Gatewayを中心に据える

ピアツーピアの直接接続に頼る設計は、本番のエージェント環境には向かない。Security Boulevardが提示する設計図では、MCP Gatewayを暗号化のバッファとして配置する案が推奨されている。

GatewayはエージェントとMCPサーバーを分離し、すべてのやり取りを量子耐性のある暗号で包む。エージェント側のロジックやツール定義を書き換えなくても、輸送層だけを安全化できる点が大きい。Tykの技術解説でも、Gatewayは認証・認可・監査を一元化する「コントロールプレーン」として位置づけられている（参考）。

MCP公式仕様は、プロトコル単体ではセキュリティ原則を強制できないと明記している。ユーザーの同意、データプライバシー、ツールの安全性は実装側の責任だ。Gatewayは、その実装責任を一箇所に集約する手段になる。

PQC実装の3つの柱

量子耐性化はラベル貼りでは済まない。設計図では次の3点を同時に満たすことが求められる。

1. アイデンティティ（Identity）

すべてのハンドシェイクは暗号的に検証可能でなければならない。量子コンピュータで破られうる証明書に依存したままでは、長期運用の前提が崩れる。

2. 認可（Authorization）

バイナリの許可・拒否では足りない。Gatewayがツール呼び出しの意図をセキュリティポリシーと照合し、属性ベースのアクセス制御（ABAC）で粒度を上げる必要がある。

3. 暗号化（Encryption）

ここでNIST標準アルゴリズムが入る。2024年8月13日、NISTはポスト量子暗号（PQC）の3規格を最終承認した（参考）。

規格 アルゴリズム 用途
FIPS 203 ML-KEM（旧CRYSTALS-Kyber） 鍵カプセル化
FIPS 204 ML-DSA（旧CRYSTALS-Dilithium） デジタル署名
FIPS 205 SLH-DSA（旧SPHINCS+） ハッシュベース署名

鍵交換にはML-KEM、通信の完全性と送信者認証にはML-DSAが使われる。ML-KEMにはML-KEM-512、ML-KEM-768、ML-KEM-1024の3パラメータセットがあり、セキュリティ強度と性能のトレードオフで選ぶ（参考）。

ハイブリッド暗号で段階的に移行する

既存のエージェント基盤をすべて作り直す必要はない。設計図が示すのは、古典暗号とPQCを重ねるハイブリッド方式だ。

具体的には、楕円曲線暗号（ECC）とML-KEMを併用する。古典層と量子耐性層のどちらか一方が破られても、もう一方が通信を守る。いわば「ベルトとサスペンダー」の構成だ。

研究用のMCPサーバー post-quantum-mcp では、X25519とML-KEM-768を組み合わせたハイブリッド鍵交換（mlkem768-x25519-sha3-256）が実装されている。ただしこのプロジェクトはliboqsベースの試作であり、本番利用は想定していない点に注意が必要だ（参考）。

本番向けには、BridgeBaseの pqc-gateway のようにML-KEM-768でエージェントを登録し、3段階のハンドシェイク後にセッショントークンを発行するGatewayも公開されている（参考）。

移行の焦点はハンドシェイクだ。エージェントのビジネスロジックではなく、鍵交換の層を先に量子耐性化する。

Shadow MCPの棚卸し

セキュリティ強化の前に、接続点をすべて把握する必要がある。Shadow MCPとは、開発者がテスト用に立ち上げたローカルサーバーが、意図せず本番エージェントと通信している状態を指す。

ネットワーク上でMCPのハンドシェイクパターンをスキャンし、中央Gatewayに未登録のサーバーを洗い出す。登録されていないサーバーへの通信は遮断する。これが「Secure-by-Design」のインベントリになる。

規制対応と長期運用の視点

量子安全通信は、Sovereign AIフレームワークやFedRAMP、NATO系の指針でも要求が進んでいる。いま対応を始めれば、監査時に「今日だけの安全」ではなく「次の10年を見据えた設計」と説明できる。

NISTは、組織にPQC標準への移行開始を求めており、高リスクシステムは2035年より前の移行が想定されている（参考）。MCPインフラも、このタイムラインに組み込んで計画するのが現実的だ。

導入時の注意点

標準のTLS 1.3は古典攻撃には強いが、HNDLには無力だ。RSAやECCで交換したセッション鍵は、将来復号される可能性がある。TLS設定にPQC対応のハイブリッド鍵交換スイートを入れる必要がある。

PQC鍵はサイズが大きく、レイテンシがわずかに増える。高頻度の金融系ワークロードでは計測が必要だが、将来の漏えいリスクと比べれば許容範囲に収まることが多い。

MCP自体はオープン標準であり、量子耐性はプロトコル仕様に組み込まれていない。開発者かインフラ提供者が実装層で設定する。Gateway導入、NIST標準アルゴリズムの採用、Shadow MCPの排除——この3点を押さえれば、エージェント基盤は「必要になってから直す」段階から脱却できる。