MCP はステートレス化へ：仕様がついに最後のエンタープライズ障壁をクリア

新しいModel Context Protocolの改訂版では、ステートフルなセッション要件が廃止されました。これはMCPを負荷分散装置の背後でスケーリングする際に扱いにくかった要素でした。紙上では小さな変更ですが、実装においては大きな変化です。

簡単に言えば。AIアシスタントが外部ツールを呼び出すための仕様であるModel Context Protocol（MCP）が改訂され、クライアントとサーバー間の状態を維持する接続が必須ではなくなりました。これはエンタープライズインフラチームが待ち望んでいた変更です。

状態維持が抱えていた問題

当初のMCPトランスポートは永続的なクライアント・サーバーセッションを前提としていました。アシスタントがツールを呼び出す際、アシスタントとツールはその間のやり取りにライブチャネルを共有していました。これはラップトップでは問題ありませんでしたが、大規模展開では扱いにくくなります。

この扱いにくさは、ロードバランサーを導入するとすぐに表面化します。状態維持セッションでは、その後のすべての呼び出しが同じバックエンドインスタンスに到達する必要があります。これにより、エンタープライズインフラで最も安価な展開パターンである「ステートレスなプールにリクエストを分散し、負荷に応じてオートスケールし、ノードの損失に耐える」という手法が台無しになります。その結果、セッション固定化の手法やスティッキーなルーティング、さらにはスポット障害の原因となるコネクションマネージャーの構築につながります。

新しい仕様で実際に変わること

報告によると、改訂されたトランスポートではサーバーがステートレスモードを広告できるようになります。実際には以下のようになります：

# 以前（要約）
POST /mcp/session → session_id
POST /mcp/call { session_id, tool, args } # 同じノードに到達する必要あり
POST /mcp/close { session_id }

# 以後 - ステートレスモード
POST /mcp/call { tool, args, ctx } # 任意のノード、セッション不要

ctxは、サーバーが過去のやり取りに関する必要な情報を保持するためのもので、クライアントが提供します。これは20年前にREST APIが採用したのと同じパターンであり、若干大きなリクエストサイズと引き換えにステートレス性を獲得しています。

内部的なトレードオフ：今やあなたが負うコスト

ステートレスにはコストがかかります。以下の2点がクライアント側に移動します：

• コンテキスト管理。クライアントが、ツールが必要とする会話ごとの状態の唯一の真実の源となります。ペイロードが大きくなり、新たなバグの原因にもなります：伝播を忘れることです。
• 冪等性。任意のノードが任意の呼び出しを処理できるようになると、リトライがより多くの場所で可能になります。ツール作成者は、呼び出しを冪等にするか、二重実行に対処する必要があります。

ほとんどのエンタープライズ展開ではこのトレードオフは価値があります。ただし、レイテンシが重要なアシスタントでは、これは実際のコストとなります。

これが示すこと

MCPエコシステムの議論は、「プロトタイプ品質」から「実際にSREチームが運用できる」段階へと成熟しつつあります。ステートレスなトランスポートはその具体的な一歩です。また、仕様作成者が成長の見込みをどこに見ているかも示しています：個々の開発者のマシンではなく、エンタープライズ内、プロキシの背後です。

結論

• ビルダー向け：MCP統合を構築してセッション固定化の痛みに悩まされていた場合、その解決策が今や仕様として認められました。
• 意思決定者向け：MCPが調達に適したものになりました。ベンダーは今後「MCPネイティブ」を宣伝するようになるでしょう。かつてRESTネイティブを宣伝していたのと同じように。