重要ポイント
2026年7月28日、モデルコンテキストプロトコル（MCP）は正式にエンタープライズレベルのステートレスアーキテクチャへと移行します。
ステートレスモデルへの移行やリッチなUIアプリケーション、非同期処理の導入により、重要なセキュリティ境界の構築責任は完全に開発者側に委ねられるようになります。
このアップデートにより、プロトコルレベルのセッション乗っ取り、不正なサーバーからの通知、脆弱な認証方法など、過去の重大なセキュリティリスクが効果的に解消されました。
しかし、アプリケーションが管理する状態の導入、豊富なインタラクティブなAIインターフェース、および長時間実行される非同期タスクは、新たな悪用機会を生み出す可能性があります。
これらの新機能が適切に保護されていない場合、顧客データの不正アクセスや、信頼できるAI体験を悪用したフィッシング攻撃、企業セキュリティ対策の回避、バックグラウンド処理ワークフローの悪用によるサービス障害などが発生する可能性があります。
2026年7月28日に公開予定のMCP仕様は、Model Context Protocol（MCP）が誕生して以来、最も重要なアーキテクチャ上の進化を遂げるものです。ローカル環境で単一ユーザー向けに開発されたAI統合ツールが、企業規模のクラウドネイティブなデプロイメントをサポートできるプラットフォームへと進化を遂げています。
2026年5月21日にリリース候補版が公開された後、最終仕様書は2026年7月28日に公開される予定です。これに伴い、一部の旧機能については正式に12か月の廃止期間が設定されます。
攻撃対象領域の進化
このエンタープライズ対応の基盤を実現するため、アップデートではプロトコルのデータ処理と実行方法が一新されました。これは、複数回の往復リクエストによって実現されるステートレスアーキテクチャ、新たに標準化されたHTTPヘッダー、およびコンテキストメッセージングのための汎用的な_metaオブジェクトを導入しています。さらに、この仕様ではMCPアプリと非同期タスクが正式に定義され、OAuth統合が主要な機能として位置付けられました。
これらの機能に関する議論の多くは、スケーラビリティや相互運用性に焦点を当てていますが、それらがプロトコルの攻撃対象領域に与える構造的な影響も同様に大きなものです。セキュリティモデルが変化するにつれ、長年存在していたプロトコルレベルのリスクの一部は軽減または完全に解消されますが、新たな責任はMCPアプリケーション開発者に明確に委ねられることになります（図1）。最終的には、これらの変更により基盤が強化されますが、全体のセキュリティ体制は実装方法の選択に左右されることになります。
図1：新仕様におけるMCPアタックサーフェスの進化
攻撃対象領域が削減または排除された。
以前のバージョンのMCPでは、プロトコル管理セッション、サーバー主導の通信、および不十分な認証要件により、複数のセキュリティリスクが明らかになっていました。新しい仕様では、これらのメカニズムのいくつかを再設計または削除することで、プロトコルレベルの攻撃対象領域を縮小しています。これらのメカニズムには、
プロトコルレベルのセッション乗っ取り
予期せぬサーバーからの通知
認証方式の脆弱性
プロトコルレベルのセッション乗っ取り
以前のMCPバージョンでは、Mcp-Session-Idヘッダーを使用して長期セッションを確立する状態管理型の初期化プロセスに依存していました。これらのセッション識別子は、攻撃者が入手すると認証済みユーザーに成りすますことが可能となるため、通常は重要な標的となります。
新しい仕様では、プロトコルで管理されるセッションが完全に削除され、この特定の攻撃ベクトルが排除されます。しかし、開発者は今や独自の安全な状態管理メカニズムを構築する必要があります（この点については、このブログ記事の後半で詳しく説明します）。
予期せぬサーバーからの通知
以前のMCPバージョンでは、サーバーがサーバー送信イベントを介して任意のタイミングでクライアントに予期せぬリクエストやプロンプトを送信することが可能でした。
新しいルールは、この行為を厳格に制限し、侵害されたサーバーがユーザーに対して悪意のある不意打ちの干渉を行うことを防ぎます。
認証方式の脆弱性
このアップデートにより、OAuth 2.1の厳格な要件への移行が必須となり、認証リスクが大幅に軽減されます。従来の固定パスワードや暗黙的な権限付与を廃止し、Proof Key for Code Exchange（PKCE）などの最新セキュリティ対策を必須とすることで、このプロトコルは認証情報やトークンの漏洩や悪用を大幅に防ぎます。
これらの変更を総合的に適用することで、従来のMCP導入時に存在していた認証関連の攻撃対象領域とセッション爆発範囲を大幅に縮小することができます。
仕様によって新たに生じた攻撃対象領域
このプロトコルはいくつかの脆弱性クラスを排除しますが、一方で、セキュリティが実装の品質に大きく依存する新たな領域も生み出します。例えば、以下のような点が挙げられます：
クロスエージェントワークフローの乗っ取り
クライアントによるメタデータ操作
ヘッダーの混乱とヘッダーを介したデータ漏洩
MCPアプリと保存されたクロスサイトスクリプティング
長時間実行されるバックグラウンドタスクにおける脆弱性のリスク
クロスエージェントワークフローの乗っ取り
無国籍状態の推進は、微妙なセキュリティ上の課題をもたらす。企業環境では、AIとのやり取りは必ずしも単一の単純なリクエストで済むとは限らず、しばしば一連のプロセスが必要となります。例：
明確にしてほしい。ツールがタスクの途中で一時停止して、不足している詳細をユーザーに確認する場合がある
進捗状況を確認中：長時間の作業では、システムが定期的に更新を要求する必要があるかもしれません。
ワークフローの一時停止：複雑なプロセスは、人間の承認を待つ間に1時間ほど一時停止し、その後、以前の状態から正確に実行を再開することがあります。
新しいMCPはステートレスであるため、誰が誰かを記憶するために永続的なセッションを使用しません。その代わりに、サーバーがクライアントに渡す追跡識別子と状態オブジェクトが導入されています。クライアントは、実行フローを再開する準備ができた時点でこれらの情報を返却します。これにより、クライアントはタスクの状態をほぼ完全に制御できるようになります。
セキュリティ上の懸念は明確です。これらのトラッキングIDや状態オブジェクトはクライアントから直接送信されるため、サーバーは安易に信頼することはできません。図2は、MCPサーバーが予測可能なトラッキングIDを使用したり、受信した状態オブジェクトの整合性を厳密に検証しなかったりした場合、攻撃者がこれらの値を推測または改ざんできることを示しています。
他のユーザーの実行中のワークフローを乗っ取る
別のエージェントが所有する情報にアクセスする。
不正なクロステナント操作を誘発する
図2：トラッキングIDの推測と状態改ざんの図解
公式MCP仕様では、開発者に対してこれらのオブジェクトの整合性を確認するよう明示的に警告していますが、具体的な基準や実装方法は定められておらず、セキュリティレイヤーの構築は個々のサーバー開発者に委ねられています。
クライアントによるメタデータ操作
新しい仕様では、クライアントがほぼすべてのMCPメッセージにカスタムメタデータを追加できる_metaオブジェクトが導入されました。たとえシンプルな単一のリクエストであっても、攻撃者は悪意のあるキーと値のペア（例：{"tenant":}）を送り込む可能性があります。「管理者」、「認証済み：true」}。
これらのフィールドには暗号署名がないため、サーバーがこのメタデータを安易に信頼してルーティングや認証の判断を行うと、悪意のある単一のリクエストによって即座に権限昇格や他テナントへのデータアクセスが発生する可能性があります。
ヘッダーの混乱とヘッダーを介したデータ漏洩
この仕様では、Mcp-MethodやMcp -NameなどのMCP固有のHTTPヘッダーが導入されており、これにより中間サーバー、プロキシ、ゲートウェイ、サーバーがMCPリクエストを統一的に理解し、適切にルーティングできるようになります。
しかし、これらのヘッダーには、2つの新たなセキュリティリスクが伴います。
プロトコル混乱（デシンク）攻撃：攻撃者は、HTTPヘッダーとJSON-RPCリクエストボディの間で矛盾する値を送信し、HTTPとJSON-RPCという2つの異なる通信プロトコル間の不整合を利用して、バックエンドインフラを混乱させることができます。この不整合により、プロキシやバックエンドサーバーが同じリクエストを異なる方法で解釈する可能性があり、攻撃者がセキュリティ対策を回避したり、監視をすり抜けたり、悪意のある行動を隠蔽したりすることが可能になります。
x-mcpヘッダーを介したデータ漏洩：この新しい機能により、開発者は特定のツール引数を直接HTTPヘッダーにマッピングできるようになります。これにより、プロキシはリクエスト本文全体を解析することなく、より迅速にトラフィックをルーティングできるようになります。しかし、開発者が誤ってAPIキーやトークン、個人を特定できる情報（PII）などの機密情報をマッピングしてしまうと、それらの機密データは直接ヘッダーに送信されてしまいます。そこに到達すると、パス上のすべてのロードバランサー、プロキシ、ログ記録システムから可視化されるようになります。
MCPアプリと保存されたクロスサイトスクリプティング
MCPの最もエキサイティングなアップデートの一つは、MCPアプリをファーストクラスのプロトコル拡張機能に変更することです。MCPアプリは、Claude DesktopなどのAIアプリケーション内で使用されるインタラクティブな視覚パネル（例：インタラクティブフォームやダッシュボード、ドキュメントビューアー、ワークフローやタスク管理画面など）を指します。
これらの豊富なインターフェースはユーザー体験を大きく向上させますが、従来のウェブブラウザに存在するリスク、例えば保存されたクロスサイトスクリプティング（XSS）をAIエコシステムにも持ち込んでしまいます。例えば、攻撃者がMCPツールを利用して悪意のあるHTMLやJavaScriptを保存する可能性があります。他のユーザー（またはAIエージェント）がそのコンテンツを閲覧すると、悪意のあるスクリプトがアプリのインターフェース内で自動的に実行されます。
MCPの仕様では、悪意のある攻撃者がAIエージェントを完全に支配するのを防ぐため、エージェントはサンドボックス化された<iframe>内でこれらのスクリプトを実行する必要があります。しかし、ユーザーには依然としてリスクが残っています。攻撃者は、侵害されたパネルを悪用して、偽の情報を表示したり、偽のメッセージで機密情報を盗むフィッシング攻撃を実行したり、そのパネルに表示されているユーザーデータを盗んだり、盗んだ情報を自身のサーバーに送信したりすることが可能です（図3）。
図3：保存されたXSSを通じたMCPアプリの悪用の図解
長時間実行されるバックグラウンドタスクにおける脆弱性のリスク
長時間実行されるタスクを導入すると、片方向の通信に依存した大規模なDoS（サービス拒否）攻撃の脆弱性が生じます。タスクの作成はクライアント側では低コストですが、サーバー側ではリソースを多く消費します。そのため、攻撃者は単一のリクエストを送信して高負荷な処理（CPU、メモリ、データベースストレージの消費など）を実行させ、すぐに接続を切断することが可能です。
この片方向非同期型攻撃手法では、クライアントが切断された後もサーバーが大量の処理を強制され、サーバーリソースが容易に枯渇してしまいます。
結論
MCP 2026-07-28仕様は、このプロトコルがローカル利用からエンタープライズ規模での導入へと移行する節目を表しています。セキュリティの観点から見ると、これらの変更は単なる段階的な改善ではありません。彼らはセキュリティ責任の所在を根本的に変革します。従来、プロトコルによって強制されていたセキュリティに関する決定は、MCPサーバーの開発者やプラットフォーム運営者に委ねられるケースがますます増えています。
クラウド環境におけるMCPの採用が加速する中、最も重要なセキュリティ上の課題は、もはやプロトコル自体の安全性ではなくなっています。その代わりに、セキュリティチームは、その上に構築されたアプリケーションが、仕様で導入された新しい信頼境界、状態管理メカニズム、実行モデルを正しく実装しているかどうかを確認する必要があります。
これらの新たな攻撃対象領域を適切に保護するためには、セキュリティチームは、クライアントから提供されたすべての状態データおよびメタデータを信頼できない入力として扱い、厳格な暗号検証、AI生成の視覚パネルに対する出力エンコーディング、および非同期タスクに対する強力なリソースクォータの適用を実施する必要があります。
この変化に対応するには、バックエンドインフラに攻撃が届く前にそれを阻止する、積極的な防御体制の構築が不可欠です。
今すぐ問い合わせる
アカマイは、企業が今すぐ行動を起こせるよう支援します。既存のセキュリティプラットフォーム（エッジ、API、アプリケーション）を強化し、MCP対応のインテリジェンス機能を追加することで、チームがMCPの発生箇所を特定し、実験中に適切な対策を講じ、リスクを効果的に管理できるように支援します。
このアプローチにより、組織は現在MCPを導入しつつ、MCPの利用が拡大するにつれて、Akamaiが提供する保護、可視性、制御機能の進化を活用することができます。
タグ
