MCP、セッションを廃止してエージェントサーバを通常のHTTPのようにスケールさせる

なぜ重要なのか

MCPは基本的なエージェントインフラになりつつある。ステートレスなリクエストはデプロイの複雑さを低減する一方、破壊的な移行は、本番での運用モデルが定まる前に広まった技術を標準化することのコストを示している。

メンテナーである David Soria Parra と Den Delimarsky に率いられた Model Context Protocol プロジェクトは、7月28日に 最終仕様（2026-07-28）を公開 し、エージェント統合標準のハンドシェイクとトランスポートレベルのセッションを自己完結型のHTTPリクエストに置き換えた。

この変更により、MCPは Soria Parra が当初開発者自身が拡張できるようにしたかったインフラに近づいた。彼は 2025年のインタビューで語った とおり、このアイデアはAnthropicに参加した後、Claude Desktopとコードエディタ間で素材をコピーすることへの苛立ちから生まれた。Soria Parra はその概念を Justin Spahr-Summers に持ち込み、二人はクライアントとサーバのプロトタイプを作成した後、Anthropic が 2024年11月にMCPを公開 した。

プロトコルはそのローカルなデスクトップ用途をはるかに超えて広がった。リモートサーバは、当初のステートフルな設計が扱いにくかった要件――スティッキー・ルーティング、共有セッションストレージ、持続的接続――をもたらした。MCPの 2026年ロードマップ では、メンテナーがこれらの制約を水平方向のスケーリングの障壁と特定している。

その答えが 最終仕様（2026-07-28） だ。仕様は initialize と initialized のやり取りを取り除き、Mcp-Session-Id ヘッダーを廃止する。代わりにすべてのリクエストはプロトコルのバージョン、クライアントの識別、および能力を携えて送られる。クライアントは、サーバを呼び出す前にサーバを検査する必要がある場合に任意の server/discover メソッドを呼び出すことができる。

A protocol redesigned around load balancers

運用上の帰結は明快だ：MCPリクエストはラウンドロビンのロードバランサの背後にある任意の利用可能なサーバインスタンスに到達し得る。オペレーターはもはやプロトコル層に、クライアントの前回のリクエストを処理したインスタンスを記憶させたり、クラスタ全体で共有されるセッションストアを維持したりする必要がない。

この区別は、MCPが開発者の実験からマネージドなエージェントインフラへ移行するにつれて重要になる。ステートフルな接続はオートスケーリング、復旧、トラフィック分配を複雑にする。サーバが故障すればそのセッション状態を失う可能性がある一方、ステートレスなリクエストは周辺のアプリケーションが許容する設計であれば別のインスタンスに対して再試行できる。

MCPがアプリケーションの状態を排除したわけではない。継続性を必要とするサーバは、バスケットやブラウザ識別子などの明示的なハンドルを発行し、モデルにそれを後続のツール呼び出しに渡すことを要求できる。状態は隠れたトランスポートメタデータではなく、モデルが検査して再利用できる引数になる。

この設計は Soria Parra の MCP に関するより広いアプローチに従う：仕様を狭く保ち、有用な振る舞いをその上位で合成可能にすることだ。2025年のインタビューで彼は MCP を、言語モデルを介した相互作用のための API 経済に似た何かを支えることを意図した「意図的に退屈な仕様」と表現していた。

The hard part moves up the stack

持続的なセッションを取り除くには、以前は開かれた双方向ストリームに依存していたフローの再設計が必要だった。Multi Round-Trip Requests（略称 MRTR）は、サーバがツール呼び出し中に追加の入力を必要とする場合を処理するために導入された。サーバは input_required の結果を返すことができ、クライアントは要求された回答を付けて元のリクエストを再送する。

この仕組みは、ユーザーの確認や欠落しているパラメータを扱うが、サーバがいつでも関連のないリクエストを開始できることを許すものではない。

改訂ではまた、Mcp-Method と Mcp-Name の HTTP ヘッダーが必須になった。ゲートウェイ、レートリミッター、ウェブアプリケーションファイアウォールはこれらのフィールドを使って各JSONボディを解析せずにルーティング、認可、計測を行える。ツール、プロンプト、リソースのリストレスポンスにはキャッシュスコープと TTL のヒントが含まれるようになり、カタログ要求の繰り返しを減らし、クライアントが安定したプロンプト入力を保持するのに役立つ。

これらの選択は、企業が既に運用しているインフラに MCP を組み込みやすくする。同時に、正直なメソッド命名、正しい認可ポリシー、およびツール間で渡される識別子の慎重な取り扱いの重要性を高める。ステートレスなトランスポートは運用上の依存関係の一つのクラスを取り除くが、エージェントが外部システムを呼び出せる場合に生じる信頼に関する判断を取り除くものではない。

Security work follows adoption

7月のリリース投稿 で、MCPのメンテナーは Tier 1 SDKs が月間で5億ダウンロードに近づいており、TypeScript と Python の SDK は累計10億ダウンロードを超えたと述べている。これらはパッケージの取得回数であり、ユニークな開発者や稼働中のサーバ、製品顧客数を示すものではないが、MCP コンポーネントが開発およびデプロイシステムを通じてどれだけ頻繁に流れているかを示している。

その配布が進むにつれてセキュリティ上の露出も拡大した。National Security Agency は警告している とおり、MCP のデプロイは信頼境界、シリアライゼーション、コンテキスト共有、エージェントの誤用に関するリスクをもたらし、特にエージェントが機密データに到達したりツールを実行したりする場合に問題となる。

Delimarsky は MCP のステアリンググループでの活動や認可とセキュリティに焦点を当てたコアメンテナーとしての経験を経て、2026年1月に Anthropic に参加した。彼の移籍に関する記述 では、この仕事をエージェントと外部サービスの間の相互運用性をより安全かつスケールしやすくすることへの賭けだと説明している。

7月の仕様は RFC 9207 に基づく発行者検証を追加し、クライアント資格情報をそれを発行した認可サーバに結び付け、Dynamic Client Registration を正式に非推奨とし Client ID Metadata Documents を推奨する。これらの変更は具体的な OAuth 展開上の問題に対処するが、ツールを信頼すべきか、エージェントがどのデータを見るべきか、あるいは侵害された統合をオペレーターがどう封じ込めるべきかといったより広範な疑問を解決するものではない。

Breaking once to break less often

メンテナーはトランスポートの書き換えを、将来の移行ショックを減らすことを意図したルール群と組み合わせている。Roots、Sampling、Logging は非推奨となり、レガシーな HTTP および server-sent events トランスポートも同様だが、プロジェクトは非推奨から削除まで少なくとも12か月の猶予を約束している。

タスクは実験的なコアからポーリングと更新メソッドを持つ拡張へ移された。拡張フレームワークにより、Tasks、MCP Apps、エンタープライズ管理の認可といった機能は、すべての実装がベースプロトコルに取り込むことを強制されることなく進化する余地を与えられる。

TypeScript、Python、Go、C# の SDK は新仕様をサポートしている。セッション識別子に依存していた開発者は依然として移行作業に直面しており、広範な互換性はクライアントとサーバがバージョン交渉を行い、メンテナーが実装を更新することに依存するだろう。

MCP のガバナンスも Anthropic の直接的所有を越えて移行した。Anthropic は 2025年12月にプロジェクトを Linux Foundation 傘下の Agentic AI Foundation に 寄贈した。プロジェクトの ガバナンスページ には Soria Parra と Delimarsky がリードメンテナーとして、Spahr-Summers がリードメンテナー名誉職として記載されている。

その構造は個人に最終的な技術権限を残しつつプロトコルに中立的な居場所を与える。ステートレスへの書き換えはこれまでで最も明確な試練であり、コミュニティ主導の標準が、それを取り巻くプロダクションシステムに適合させるために短期的な破壊を受け入れるという姿勢を示している。