9月25日、Leela Kumiliが「Stateless MCP Removes Session Affinity Requirements for AWS Server Deployments」と題した記事を公開した。2026年7月28日付けのMCP仕様更新により、プロトコルレベルのセッション管理が完全に撤廃され、スティッキーセッションなしに通常のロードバランサーでMCPサーバーを水平スケールできるようになった。 AWS LambdaをMCPサーバーの実行環境として使うことも現実的な選択肢になる——この変更はAIエージェント基盤のインフラ設計に直接影響する。

セッション管理の概念が根本から変わった

Model Context Protocol（MCP）は、Anthropicが策定しAIエージェントが外部ツールやデータソースと通信するためのオープンプロトコルだ。Claude等のLLMと外部システムを繋ぐ標準インターフェースとして急速に普及しており、AWSをはじめ主要クラウドベンダーがMCPサーバーのホスティングや統合サポートを強化している。

これまでのMCP仕様では、クライアントとサーバー間で初期化ハンドシェイク（initialize / initialized）を行い、Mcp-Session-Idヘッダーでセッションを維持する必要があった。これがロードバランサー配下での水平スケーリングを複雑にしていた最大の原因だ——リクエストを同じサーバーインスタンスに届けるスティッキーセッション（セッションアフィニティ）か、共有セッションストアが必要だったからである。

2026年7月28日付けの仕様更新でこの制約が撤廃された。 initializeハンドシェイクとMcp-Session-Idヘッダーが削除され、各リクエストは通常のロードバランサーで任意のインスタンスにルーティングできるようになった。

LinkedInでこの仕様変更を解説したMichael Madsenは、変化の本質をこう表現している：

The protocol is stateless. Your application doesn't have to be.
（プロトコルはステートレスだ。アプリケーションがそうである必要はない。）

プロトコルレベルのセッション管理が不要になるだけで、アプリケーション側の状態管理はこれまで通り実装できる——この区別が重要だ。

AWS環境への具体的な影響

AWSアーキテクチャブログでAnand Komandooru、Steven DeVries、Haleh Najafzadehの3名が解説した内容によると、この変更によって以下の構成変更が可能になる。

• スティッキーセッション設定の削除：ALB（Application Load Balancer）等でセッションアフィニティ設定が不要になる
• MCP専用セッションストアの撤廃：プロトコル状態のためだけに維持していたElastiCacheやDynamoDBのセッションテーブルが不要になる
• AWS Lambdaの利用が現実的になる：持続的なセッション接続が不要になったため、リクエスト・レスポンス型のLambdaがMCPサーバーの実行環境として適切な選択肢になった

AWSによる図：MCPの変更点がWell-Architected Agentic AI Lensにどう対応するかを示している。Well-Architected Agentic AI LensはAWSの設計フレームワーク「AWS Well-Architected Framework」のAIエージェント向け拡張レンズであり、信頼性・スケーラビリティ・セキュリティ等の観点から設計を評価するためのガイドラインだ。出典：AWS Architecture Blog

新仕様で追加・変更された主な要素

ステートレス化に伴い、仕様には複数の変更が加えられている。

MRTR（Multi-Round Tool Request）の導入：従来のMCP仕様では、サーバーがクライアントに追加の入力を求める場合、ストリームを張り続けながら双方向通信を維持する必要があった。この設計はサーバーインスタンスとの持続的な接続を前提とするため、ステートレスな水平スケーリングと根本的に相性が悪かった。新たに導入されたMRTRでは、サーバーがinput_requiredレスポンスを返すことで「続きが必要」であることをクライアントに通知し、クライアントが必要な情報を付与した後続リクエストを送る形で複数ステップのやり取りを実現する。ストリームを保持しないリクエスト・レスポンス型の設計になっており、各ラウンドトリップが独立したHTTPリクエストとして完結するため、どのサーバーインスタンスが処理しても構わない。

ゲートウェイルーティングとトレーシングの強化：新たにMcp-MethodとMcp-Nameヘッダーが追加され、APIゲートウェイでのルーティングやスロットリングが可能になった。分散トレーシングにはW3C Trace Contextが採用されている。

キャッシュ制御：ttlMsとcacheScopeによるキャッシュ制御も導入された。

一方、ストリーム再開（Stream Resumability）機能は削除された。中断された操作はクライアント側でリトライする必要があり、副作用を伴うツール呼び出しにおける冪等性（idempotency）の実装が重要性を増す。

移行は段階的に——旧バージョンとの共存が必要

既存環境では即座の移行は難しい。ApifyのMCPサーバープロジェクトでは、ステートレス対応とセッションフル（旧仕様）のサーバーを並行実装し、両プロトコルバージョンに対応したルーティングと適合性テストを整備している。

AWSは以下の移行戦略を推奨している：

• ゲートウェイでプロトコルバージョンを識別・記録する
• 旧バージョンのクライアントからのトラフィックが消えるまでセッションインフラを維持する

MCPプロジェクト側でも、廃止予定の機能に対して移行期間を設けるフィーチャーライフサイクルポリシーを策定している。

MCPステートレス化が示す、AIインフラ設計の方向性

今回の変更はAWSに限った話ではない。MCPはAnthropicが策定したものの、すでにGoogle CloudやAzureもMCPサーバーのホスティング・統合対応を進めており、仕様のステートレス化はクラウドを問わず同様のアーキテクチャ簡素化をもたらす。AIエージェント基盤を「普通のWebアプリと同じスケーリング戦略で運用できる」状態に近づける方向性は、MCPの普及をさらに加速させる可能性がある。

MCPをAWS上で本番運用している、もしくは検討しているエンジニアには直接影響するアーキテクチャ変更だ。Lambdaでの実行やシンプルなロードバランサー構成が選択肢に入ってきた今、インフラ設計を見直す価値がある。

詳細はStateless MCP Removes Session Affinity Requirements for AWS Server Deploymentsを参照していただきたい。