本ブログのポイント
- 2026年7月28日、Model Context Protocol（MCP）はエンタープライズ向けのステートレスアーキテクチャへ正式に移行します。
- ステートレスモデルへの移行と、リッチなUIアプリや非同期タスクの導入により、重要なセキュリティ境界を構築する責任は開発者へと移ります。
- このアップデートにより、プロトコルレベルでのセッションハイジャック、サーバーからの予期せぬプロンプト、脆弱な認証手法といった従来の主要なセキュリティリスクが解消されます。
- 一方で、アプリケーション側で状態を管理する仕組み、リッチでインタラクティブなAIインターフェース、長時間実行される非同期タスクなどが導入されることで、新たな攻撃経路を生み出す可能性もあります。
- 適切に保護されていなければ、こうした新機能を通じて、顧客データへの不正アクセス、信頼できるAI体験を悪用したユーザー標的型フィッシング、企業セキュリティ制御の回避、バックグラウンド処理ワークフローの悪用によるサービス中断などが引き起こされる恐れがあります。
MCPは単一ユーザーのローカル環境（PC上など）でAIが外部ツールやデータ（ファイルシステムなど）を安全かつ簡単に操作できるようにするためのツールとして始まりましたが、今回の仕様アップデートにより、エンタープライズ規模のクラウドネイティブ展開に対応できるプラットフォームへと変貌を遂げようとしています。
2026年7月28日にリリース予定の「MCP 2026-07-28」仕様は、Model Context Protocol（MCP）にとって過去最大のアーキテクチャの進化となります。本記事では、この仕様変更がプロトコルのアタックサーフェス（攻撃対象領域）にどのような影響を与えるのかを紐解き、セキュリティチームが対応すべき新たな課題を明らかにします。 （なお、この正式リリースに伴い、一部のレガシー機能については12ヶ月間の非推奨期間が設けられます。.
仕様変更に伴うアタックサーフェスの変化
企業環境への導入に耐えうる基盤を実現するため、今回のアップデートではプロトコルのデータ処理と実行方法が全面的に見直されています。複数回のラウンドトリップリクエスト、標準化された新たなHTTPヘッダー、そしてコンテキストメッセージング用の汎用的な _meta オブジェクトによって支えられるステートレス・アーキテクチャが導入されました。さらに、本仕様ではMCP Appsと非同期タスクが正式に定義され、OAuth統合が主要な要素として格上げされています。
こうした新機能については、スケーラビリティや相互運用性の観点から語られることが多いものの、プロトコルのアタックサーフェスにもたらす構造的な影響も同じくらい深刻です。セキュリティモデルの移行により、プロトコルレベルで長年存在していたリスクのいくつかが緩和、あるいは完全に排除される一方で、新たなセキュリティ責任がMCPアプリケーション開発者に直接のしかかることになります（図1）。つまり、基盤自体は改善されるものの、システム全体のセキュリティポスチャは今後の実装の選択に大きく左右されるのです。
図1：新仕様におけるMCPのアタックサーフェスの変化
バックグラウンドタスク悪用によるリソース枯渇
以前のバージョンのMCPでは、プロトコル管理のセッション、サーバー主導の通信、未熟な認証要件に起因するセキュリティリスクが存在しました。新仕様ではこれらのメカニズムが再設計または排除され、プロトコルレベルのアタックサーフェスが縮小しています。解消される具体的な要素は以下の通りです。
- プロトコルレベルのセッションハイジャック
- サーバーからの予期せぬプロンプト
- 脆弱な認証手法
セッションハイジャックの排除
これまでのMCPは、Mcp-Session-Id ヘッダーを用いて長期間有効なセッションを確立する、ステートフルな初期化プロセスに依存していました。こうしたセッション識別子は、取得できれば認証済みユーザーになりすませるため、攻撃者にとって格好の標的でした。
新仕様では、こうしたプロトコル管理のセッションが完全に削除されたことで、この攻撃ベクトルは排除されています。ただしその代わりとして、開発者は独自のステート管理メカニズムを構築する必要があります（後述）。
予期せぬプロンプトの制限
以前のMCPでは、Server-Sent Eventsを利用して、サーバーからクライアントへ任意のタイミングで予期せぬリクエストやプロンプトを送信することが可能でした。
新しいルールではこの挙動が厳格に制限されており、侵害されたサーバーがユーザーに無断で悪意あるインタラクションを仕掛け、操作を妨害するのを防ぎます。
認証要件の厳格化
今回のアップデートにより厳密なOAuth 2.1への準拠が求められるようになり、認証リスクが大幅に削減されました。レガシーなパスワードやImplicit Grantが排除され、PKCE（Proof Key for Code Exchange）などの最新の保護手法が義務付けられたことで、認証情報やトークンが漏えい・悪用される可能性は著しく制限されます。
総じて、これらの変更により、以前のMCP展開に存在していた認証関連のアタックサーフェスとセッション侵害時の影響範囲は劇的に縮小します。
新機能がもたらす新たなアタックサーフェス
プロトコルからいくつかのクラスの脆弱性が取り除かれた一方で、実装の品質に大きく依存する新たなセキュリティの懸念事項も生じています。具体的には以下の点が挙げられます。
- クロスエージェントでのワークフローハイジャック
- クライアント制御によるメタデータの操作
- HTTP Desyncとデータ漏えい
- MCP Appsと蓄積型クロスサイトスクリプティング（XSS）
- 長時間実行されるバックグラウンドタスクの悪用
ワークフローハイジャックのリスク
ステートレス化への移行は、見えにくいセキュリティ上の課題をもたらします。企業環境において、AIとのやり取りは常に「1回のリクエストで完結するシンプルな会話」とは限りません。多くの場合、次のような一連のイベントが連続して発生します。
- 確認の要求：ツールがタスクの途中で一時停止し、ユーザーに不足している詳細情報を求める
- 進捗の確認：時間のかかるジョブを実行中、システムが定期的に更新を要求する
- ワークフローの停止：複雑なプロセスにおいて、人間の承認を待つために1時間停止し、その後、元の状態から正確に実行を再開する
新しいMCPはステートレスであるため、恒久的なセッションを使って「誰が誰であるか」を記憶することはありません。その代わり、サーバーは追跡用の識別子やステートオブジェクトをクライアントに渡します。クライアントは、実行フローを再開する準備ができた際にこれらをサーバーに送り返します。これは実質的に、タスクのステートをクライアントが完全に制御できることを意味します。
ここでのセキュリティ上の懸念は明白です。これらの追跡IDやステートオブジェクトはクライアントから直接送られてくるため、サーバーはそれを無条件に信頼するわけにはいきません。図2が示すように、MCPサーバーが予測可能な追跡IDを使用したり、受け取ったステートオブジェクトの完全性を厳密に検証しなかったりした場合、攻撃者はこれらの値を推測または改ざんすることで、次のような行動に出る可能性があります。
- 他のユーザーのアクティブなワークフローを乗っ取る
- 別のエージェントに属する情報にアクセスする
- 権限のないクロステナントでの操作を引き起こす
図2：追跡IDの推測とステート改ざんのイメージ
公式のMCP仕様は、こうしたオブジェクトの完全性を検証するよう開発者に明確に警告していますが、具体的な標準や実装方法については規定していません。つまり、このセキュリティレイヤーを構築する責任は個々のサーバー開発者に完全に委ねられているのです。
メタデータ操作による権限昇格
新仕様では、クライアントがほぼすべてのMCPメッセージにカスタムメタデータを付与できる汎用的な _meta オブジェクトが導入されました。たとえ単純な単一のリクエストであっても、攻撃者が {"tenant": "admin", "authenticated": true} のような悪意のあるキー・バリューのペアを送り込む可能性があります。
これらのフィールドには暗号化による署名がありません。そのため、サーバーがルーティングや認可の判断においてこのメタデータを安易に信頼してしまうと、たった1回の悪意あるリクエストで瞬時に権限昇格やクロステナントでのデータアクセスを許してしまう恐れがあります。
ヘッダーを利用した攻撃と情報漏えい
本仕様では、 Mcp-Method や Mcp-Name といったMCP固有のHTTPヘッダーが導入されました。これにより、仲介となるプロキシ、ゲートウェイ、サーバーなどがMCPリクエストを一貫して理解し、正しくルーティングできるようになります。
しかし、これらのヘッダーは2つの新たなセキュリティリスクももたらします。
HTTP Desync攻撃：
攻撃者がHTTPヘッダーとJSON-RPCリクエスト本文との間に矛盾する値を送信し、HTTPとJSON-RPCという2つの異なる通信プロトコル間の不一致を悪用して、バックエンドインフラの同期を狂わせる可能性があります。この不一致により、プロキシやバックエンドサーバーが同じリクエストを異なって解釈するよう仕向けられ、攻撃者はセキュリティ制御を回避したり、監視をすり抜けたり、悪意のある行動を隠蔽したりすることができます。
x-Mcp-headerによるデータ漏えい：この新しいディレクティブにより、開発者は特定のツールの引数をHTTPヘッダーに直接マッピングできるようになります。これを利用すれば、プロキシはリクエスト全体を解析することなく高速にトラフィックをルーティングできます。しかし、開発者がAPIキー、トークン、個人を特定できる情報（PII）などの機微な情報を誤ってマッピングしてしまうと、それらのシークレット情報がそのままヘッダーに押し出されてしまいます。一度ヘッダーに記載されると、経路上のすべてのロードバランサー、プロキシ、ログシステムから丸見えになってしまいます。
MCP Appsがもたらすクロスサイトスクリプティングのリスク
MCPのアップデートの中でも特に注目すべき点の1つは、MCP Appsが主要なプロトコル拡張として扱われるようになったことです。MCP Appsとは、Claude DesktopなどのAIアプリケーション内で目にするインタラクティブな視覚的パネル（インタラクティブなフォームやダッシュボード、ドキュメントビューア、ワークフローやタスクの追跡画面など）のことです。
これらのリッチなインターフェースはユーザー体験を大幅に向上させますが、同時に、蓄積型クロスサイトスクリプティング（XSS）のような従来のWebブラウザー特有のリスクをAIエコシステムに持ち込むことにもなります。たとえば、攻撃者がMCPツールを通じて悪意のあるHTMLやJavaScriptを保存したとします。他のユーザー（またはAIエージェント）がそのコンテンツを閲覧すると、アプリのインターフェース内で悪意のあるスクリプトが自動的に実行されてしまいます。
MCP仕様では、悪意のある攻撃者がAIエージェントを完全に制御できないよう、これらのスクリプトをサンドボックス化された <iframe> 内で実行することを義務付けています。しかし、それでもユーザーはリスクにさらされています。攻撃者は侵害されたパネルを利用して偽のコンテンツを表示したり、偽のプロンプトで機微な情報を狙うフィッシング攻撃を実行したり、そのパネル内に表示されているユーザーデータを盗み出して自身のサーバーに送信したりすることが可能です（図3）。
図3：蓄積型クロスサイトスクリプティングによるMCP Apps悪用のイメージ
バックグラウンドタスク悪用によるリソース枯渇
長時間実行されるタスクの導入は、一方向のインタラクションに依存した大規模なサービス妨害（DoS）のベクトルを生み出します。タスクの作成はクライアントにとっては低コストですが、サーバーにとってはリソースを大量に消費します。そのため、攻撃者は単一のリクエストを送信して高負荷な操作（CPU、メモリ、データベースのストレージを消費する操作など）を発生させ、即座に接続を切断することができます。
この一方向の非同期的な悪用手法は、クライアントがいなくなった後もサーバーに重いワークロードを処理し続けることを強要し、サーバーのリソースを簡単に枯渇させてしまいます。
セキュリティ境界を見極め、防衛を固める
MCP 2026-07-28仕様は、このプロトコルがローカルでの利用から企業規模の展開へと移行する転換点となります。セキュリティの観点から見ると、今回の変更は単なる段階的な改善ではありません。セキュリティ責任の所在を根本から定義し直すものです。以前はプロトコルによって強制されていたセキュリティの決定事項が、ますますMCPサーバー開発者やプラットフォームの運用担当者に委ねられるようになっています。
クラウド環境全体でMCPの導入が加速する中、最も重要なセキュリティの問いは、「プロトコル自体が安全かどうか」ではありません。セキュリティチームは「その上に構築されたアプリケーションが、仕様によって導入された新しい信頼境界、ステート管理のメカニズム、実行モデルを正しく実装しているかどうか」を見極める必要があります。
これらの新たなアタックサーフェスを適切に保護するために、セキュリティチームは、クライアントから提供されるすべてのステートデータやメタデータを「信頼できない入力」として扱う必要があります。具体的には、厳格な暗号化による検証、AIが生成する視覚パネルでの出力のエンコーディング、および非同期タスクに対する堅牢なリソース制限を適用することが求められます。
この変化を乗り切るには、攻撃がバックエンドのインフラに到達する前にブロックする事前対応型の保護アーキテクチャが必要です。
これからの展開に備えて
Akamaiは、企業が今すぐ対応を始められるよう支援します。既存のEdge、API、およびアプリケーションのセキュリティプラットフォームを基盤とし、そこにMCPを認識するインテリジェンスを組み込むことで、お客様のチームがMCPの利用箇所を特定し、実験段階で実用的なガードレールを適用し、利用の拡大に伴うリスクを管理できるようになります。
このアプローチにより、企業は現在からMCPの導入を進めつつ、今後のMCP利用の発展に合わせて、保護、可視性、および制御の進化をAkamaiに任せることができます。
Tags
