Claude Desktop や独自の AI エージェントから MCP（Model Context Protocol、AIモデルと外部ツール・企業データをつなぐための標準規格）サーバーを呼び出す実装を持っているなら、この変更は無視できません。MCP の新しいリリースでは、プロトコルレベルのセッション管理が廃止され、ステートレス（サーバー側が状態を保持しない）なアーキテクチャに切り替わります。既存のセッション前提のサーバー実装は、そのままでは本番のクラウド環境でスケールしなくなる可能性があります。
何が起きるか
従来の MCP は、クライアントとサーバーの接続ごとに永続的なセッション情報を保持する設計でした。クライアントが一度サーバーに接続すると、そのサーバーが会話の文脈（コンテキスト）を覚え続ける仕組みです。
この仕組みはローカル開発では問題になりません。しかし複数サーバーにまたがるデプロイでは、リクエストを常に「セッションを開始した特定のマシン」へ戻す必要が出てきます。ロードバランサーの背後に複数の MCP サーバーを並べても、セッション ID に紐づくサーバーへ固定的にルーティングしなければならず、水平スケールの妨げになっていました。
ZopDev のクラウドアソシエイトである Muskan Bandta 氏は、このセッション前提のモデルが本番環境で運用上の負担になっていたと指摘しています。インフラチームから「他のクラウドアプリケーションと同じようにスケールできるのか」と問われたとき、明確に「できる」と答えられない状況があったとのことです。
なぜ起きるか（設計変更の背景）
原因を段階的に分解すると、次の3点に整理できます。
1つ目は、MCP がもともとローカル環境でのツール連携を主眼に設計された経緯です。AI アシスタントが手元のファイルシステムや DB に接続するユースケースでは、1接続1サーバーで完結するため、セッションを維持する設計が自然でした。
2つ目は、AI 初期構想の実運用フェーズへの移行です。エンタープライズが MCP サーバーを本番投入し始めたことで、複数インスタンスによるオートスケーリングやゼロダウンタイムデプロイが必須要件になりました。ステートフル（状態を保持する）なサーバーは、こうした一般的なクラウドネイティブの運用パターンと相性が悪い設計です。
3つ目は、状態管理の責任範囲の移動です。新しいステートレス設計では、リクエストごとに処理に必要な情報をすべて含める形になります。複数リクエストにまたがる文脈が必要なアプリケーションは、その状態管理をプロトコル側ではなく開発者側が明示的に担う必要があります。Kanerika の AI 開発マネージャーである Amit Jena 氏は、これは単なるインフラの簡素化ではなく、AI アプリケーションが複数ツール間でコンテキストを共有・管理する方法そのものを変える変更だと説明しています。
自分のプロジェクトが該当するか確認する方法
まず、利用している MCP SDK のバージョンを確認します。
npm list @modelcontextprotocol/sdk
# もしくは Python なら
pip show mcp次に、自作の MCP サーバー実装で以下のパターンがないか探します。
- サーバープロセス内のグローバル変数やインスタンス変数にクライアントごとの状態を保持している
- セッション ID をキーにした辞書やキャッシュでリクエスト履歴を管理している
- ロードバランサーの設定で「スティッキーセッション（同一クライアントを同一サーバーに固定するルーティング）」を前提にしている
- WebSocket や Server-Sent Events の長時間接続に依存し、接続断で状態が失われる設計になっている
該当する項目が1つでもあれば、新しいステートレス版へのアップグレード時に動作確認が必要です。加えて、リバースプロキシや API ゲートウェイの設定ファイルで、MCP リクエストのルーティングルールがセッション単位になっていないかも見ておく価値があります。
対策の手順
状態の外部化
最初にやるべきことは、サーバー内部で保持していた状態を外部ストアに移すことです。Redis や DynamoDB のような外部キャッシュに、会話履歴やツール実行結果を保存する形に変更します。リクエストにはコンテキスト取得用のキー（トークンやリファレンス ID）を含め、サーバー側はそのキーを使って毎回外部ストアから状態を引く構成にします。
MRTR（Multi Round-Trip Requests）への移行
新しい MCP では、持続的な接続の代わりに MRTR という仕組みが導入されます。エージェントが追加情報を必要とする場合、通常のリクエスト・レスポンスの往復でやり取りする方式です。長時間接続を維持するコードをすでに書いている場合は、この標準的な往復パターンへの置き換えを検討します。
ルーティングヘッダーの活用
ルーティング可能なトランスポートヘッダーが新設され、API ゲートウェイがリクエストの中身を検査せずに MCP リクエストを識別・ルーティングできるようになります。既存の API ゲートウェイ（Kong や AWS API Gateway など）の設定を見直し、ヘッダーベースのルーティングルールに切り替えられるか確認します。これによりレート制限やセキュリティポリシーを既存の API 管理基盤で統一的に扱えるようになります。
認可まわりの棚卸し
新しい認可フレームワークは OAuth 2.1 と OpenID Connect（業界標準の認証・認可プロトコル）を軸に構築されます。独自の認証をラップしている実装があれば、この標準への準拠状況を棚卸ししておくと移行がスムーズです。
ツール一覧のキャッシュ設計の見直し
ツールやリソースの一覧を決定的にキャッシュする仕組みも追加されるため、毎回全ツール一覧を取得し直すような実装は、キャッシュ利用に切り替えられないか確認します。レイテンシ削減とサーバー負荷軽減の両面で効果があります。
導入前に確認すること
- 利用中の SDK バージョンとリリースノートで、ステートレス対応がいつから有効になるかを確認する
- 自作 MCP サーバーがセッション ID やスティッキーセッションに依存していないかコードレビューする
- 状態が必要な処理は Redis 等の外部ストアに切り出し、リクエストにキーを含める設計へ移行する
- API ゲートウェイの設定とロードバランサーのルーティングルールをヘッダーベースに更新できるか検討する
この変更は破壊的に見えますが、狙いは明確です。ローカル開発の便利さのために犠牲にしていたクラウドスケーラビリティを、プロトコルレベルで取り戻す設計です。自作サーバーの棚卸しを早めに済ませておくと、本番移行のタイミングで慌てずに済みます。