8月12日、Steef-Jan Wiggersが「MCP Goes Stateless, and Developers Ask Whether That Just Makes It an API Again」と題した記事を公開した。MCPの最新仕様がセッションを廃止してステートレス化を採用したことで、「ステートフルな独自プロトコルがREST APIと何が違うのか」という問いが開発者コミュニティで改めて浮上している。スケーリングの改善という実利と、プロトコルとしての存在意義への疑念が交錯する、現時点でのMCPをめぐる最も核心的な論争の一つだ。
MCPがセッションを廃止した
2026年7月28日付けのMCP仕様は、プロトコルセッションを廃止した。
従来のMCPは、initializeとinitializedのハンドシェイクでセッションを確立し、Mcp-Session-Idヘッダーで追跡する仕組みだった。すべてのリクエストは、そのセッションに紐付いた状態を持つインスタンスに届く必要があり、ロードバランシングは事実上不可能で、オートスケールやデプロイ時のセッション引き継ぎが大きな運用上の課題となっていた。
新仕様はハンドシェイクもセッションヘッダーもコアのリクエストパスから取り除いた。各リクエストは自分が必要なプロトコルバージョン・クライアントID・ケイパビリティを自己申告し、どのインスタンスにでも届けられる。
ボディパース不要でゲートウェイがツール単位で制御できるようになった
スケーリングの話は既に広く伝えられているが、記事が指摘する本質はそこではない。
MCPのメッセージはHTTP上のJSON-RPCであり、これまでリクエストの情報はJSONボディの内部にしかなかった。つまりゲートウェイは、あるリクエストがツールの一覧取得なのか、ツールの呼び出しなのか、リソースの読み取りなのかを判断するためにボディをパースする必要があった。
新仕様ではStreamable HTTPリクエストに2つのヘッダーが必須化された：
- **
Mcp-Method**：例）tools/call - **
Mcp-Name**：例）search
CloudflareのMatt Careyはこの意味を明確に説明している。ゲートウェイ、レートリミッター、WAFがこれらのヘッダーを読み、メソッド単位・ツール単位でトラフィックを制御できる。既存のAPIインフラがHTTPヘッダーに対してすでに持っているプリミティブをそのまま適用できる。さらに仕様では、ツールの引数もヘッダーにコピーしてカスタムルーティングに使うことが可能とされている。
エージェントのガバナンス制御はこれまで、CloudflareのエージェントトレーシングやAzure API ManagementのAI Gatewayティアのようにプロトコルの上位に別レイヤーとして置かれていた。今回の変更でメタデータがトランスポート層に降り、インフラチームが既存の仕組みで読めるようになった。
その他の仕様変更
エリシテーション（elicitation）の見直し：サーバーからクライアントへのリクエスト（例：ユーザー入力の要求）は、これまで接続を維持し続けるストリームを必要としていた。新仕様では「Multi Round-Trip Requests」として、サーバーが
input_requiredを返し、クライアントが回答を収集してリクエストをリトライする形になった。人間の承認が単一の接続の中に収まらなくなった分、デプロイは簡素化される。認可の強化：Dynamic Client Registrationが非推奨となり2027年夏以降に削除予定。Dynamic Client Registrationはクライアントが動的にOAuthクレデンシャルを取得できる仕組みだが、MCP環境では信頼境界の管理が複雑になりやすく、セキュリティ上のリスクが指摘されていた。削除後は、RFC 9207のissuer識別とRFC 8707のリソース指定が採用され、トークンが意図した宛先にのみ受け入れられるよう厳格化される。この変更は既存の動的登録に依存したクライアント実装に破壊的変更をもたらす可能性があり、移行期間中の対応が求められる。
Hacker Newsでは「結局ただのPOSTじゃないか」
Hacker Newsのスレッドでは、ステートレス化が改善かどうかではなく、「その改善が何を意味するか」をめぐって議論が割れた。
ステートレス化を評価する側は、そもそもステートフルだったことが誤りだったと見る。コメント投稿者drdexebtjlはこう書いた：
振り返ると、ステートフルなMCPは明らかに間違いだった。これは本質的にMCPをただのRESTエンドポイントにするものであり、ロードバランサーやAPIゲートウェイ、プログレッシブロールアウトなど、すでにRESTで使っているインフラをそのまま使えるようにする。
コメント投稿者luciana1uはより率直だった：
ステートフルなプロトコルを発明して、状態はスケールしにくいと気づいて、それを取り除いたら「ただPOSTを送ればいい」に辿り着いた。RESTの陣営はこの瞬間を20年間ほくそ笑みながら待っていた。
一方、MCPを擁護する側はその結論に異を唱えた。コメント投稿者vidarh：
MCPが与えた本質的な優位性は、AIプロバイダーが承認したことで、人々が実際に実装する強いインセンティブを持った標準が存在したことだ。
SentryのCPOであるDavid Cramerは、かつてMCPを批判的に評価していたが、今回の仕様についてはCloudflareに次のようにコメントしている：
エージェントが本当に役立つのは、配管が話の中心でなくなったときだ。
普及の実態
Anthropicの発表によれば、MCPは月間SDKダウンロード数4億回を超え、今年だけで4倍になった。ただしそれが個々のサーバーへの実際の利用に繋がっているかは別の話で、あるコンサルタントのr/AI_Agentsへの投稿では、あるクライアントのMCPサーバーを監査したところ3ヶ月で61回のツール呼び出しがあり、うち58回は自社エンジニアからだったと報告されている。
金が流れているのはゲートウェイ、レジストリ、認可レイヤーであって、サーバー自体ではない。
移行対応
本番でMCPを稼働させているチームには実質的な移行作業が発生する。プロトコルセッション、サーバー起点のリクエスト、スタンドアロンストリームに依存しているサーバーは、既存のセッションフルなルートと並行してステートレスルートを立ち上げ、アクティブセッションをドレインしてから旧パスを削除する手順が推奨されている。仕様と更新済みのTypeScript・Python・Go・C# SDKはすでに公開されている。
詳細はMCP Goes Stateless, and Developers Ask Whether That Just Makes It an API Againを参照していただきたい。
