MCPがステートレスに——新仕様「2026-07-28」でセッション管理の複雑さが激減、サーバーレス環境での運用が大幅に簡素化

8月6日、Cloudflareが「The next generation of MCP」と題した記事を公開した。この記事では、MCP（Model Context Protocol）の新仕様「2026-07-28」によってプロトコルが大幅にステートレス化され、AIエージェント向けMCPサーバーの構築・運用が簡素化されたことについて詳しく紹介されている。

ステートレス化——MCPの最大の設計変更

MCP（Model Context Protocol）はここ1年半でAIエージェントが外部サービスと連携するための事実上の標準プロトコルとなった。しかし、その最大の批判の一つが「クライアントとサーバー間でステートフルな接続を維持しなければならない」という設計にあった。

もともとMCPはローカルアプリケーション向けのSTDIOトランスポートから始まり、リモート環境へ移行する際にもそのステートフルな接続モデルを引き継いだ。その結果、スティッキーセッションへのルーティング、ストリームの維持、メッセージのリプレイといった複雑な仕組みが必要となり、サーバーレス環境での運用に大きなオーバーヘッドを生んでいた。

新仕様「2026-07-28」はこの問題を根本から解決する。 従来のinitialize/initializedハンドシェイクとMcp-Session-Idヘッダーによるセッション管理がコアのリクエストパスから完全に除去された。各リクエストはプロトコルバージョン、クライアントID、クライアントのケイパビリティを自己完結的に持ち、ツールを呼び出して結果を返すだけで済む。保存すべきセッション状態は存在しない。

この変更によって、Cloudflare WorkersのようなリクエストスコープのサーバーレスインフラだけでMCPサーバーが動作するようになった。従来はセッション状態の管理にCloudflare Durable Objectsが必要だったが、ステートレスなユースケースでは必須でなくなった。なお、ツール実行をまたいで状態を保持する必要があるステートフルなユースケースでは、引き続きDurable Objectsが有効な選択肢となる。Cloudflare自身のAPIを公開するMCPサーバーはすでに非公式のステートレスモードで動作しており、毎秒数千リクエスト、累計数十億回のツール呼び出しをこなしている。

`createMcpHandler`が公式SDKに

Cloudflareが2025年11月に独自に導入したcreateMcpHandler関数が、今回の新仕様に合わせて公式のMCP TypeScript SDKに取り込まれた。

最小構成のサーバーは以下のコードで書ける（インポートパスは公式SDKのバージョンによって異なる場合がある。最新の推奨パスは公式リポジトリで確認されたい）：

import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";
import { z } from "zod";

function createServer() {
  const server = new McpServer({
    name: "hello-server",
    version: "1.0.0",
  });

  server.registerTool(
    "hello",
    {
      description: "Return a greeting",
      inputSchema: { name: z.string().optional() },
    },
    async ({ name }) => ({
      content: [{ type: "text", text: `Hello, ${name ?? "World"}!` }],
    }),
  );

  return server;
}

export default {
  fetch(request, env, ctx) {
    return createMcpHandler(createServer)(request, env, ctx);
  },
};

Durable Objectsを使ったMcpAgentと比べると、インフラ面の複雑さが大幅に下がっているのがわかる。/mcpエンドポイントは旧仕様の2025年型Streamable HTTPクライアントとの後方互換性も維持しており、多くのクライアントは設定変更なしに再接続できる。

既存のMcpAgentからの移行手順は公式マイグレーションガイドにまとめられている。

ユーザー入力（Elicitation）の仕組みも刷新

デプロイ承認や決済確認など、ツール実行の途中でユーザー入力が必要になるケース——MCP用語ではElicitation——も設計が変わった。

従来はオープンなストリームが必要だったが、新仕様ではMulti Round-Trip Requests（MRTR）という仕組みを採用した。MRTRとは、一連のやり取りを単一ストリームで維持する代わりに、複数の独立したHTTPリクエスト／レスポンスとして分割してやり取りする方式だ。サーバーはinput_requiredという結果を返してクライアントに追加情報を要求し、クライアントがその情報を付けて再リクエストする。セッションを保持し続ける必要がないため、ストリーム管理やタイムアウトの問題から解放される。旧方式とは非互換の変更だが、実装の複雑さは大幅に下がる。

HTTPインフラからMCPメソッドが見えるようになった

従来、MCPリクエストはHTTP上のJSON-RPCとして送られていたが、どのメソッドが呼ばれているかはJSONボディを解析しないとわからなかった。新仕様では**Mcp-MethodとMcp-Nameヘッダー**がStreamable HTTPリクエストに必須となった。

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

これによりゲートウェイ、レートリミッター、WAFがJSONをパースせずにメソッドレベルのルーティングやアクセス制御を適用できる。ツール単位のメトリクス収集も既存のHTTPインフラで実現できる。

認証の強化とライフサイクルポリシーの導入

認証まわりでは、従来のDynamic Client Registration（DCR）が非推奨となり（2027年夏以降に削除予定）、Client ID Metadata Documents（CIMD）が推奨方式になった。CIMDはDCRのような動的な登録フローを不要とし、クライアントメタデータをURLで静的に参照できる仕組みだ。あわせてRFC 9207によるissuer識別も採用され、認可レスポンスのなりすましを防ぐ仕組みが追加されている。

また今回の仕様からは機能のライフサイクルポリシーが正式に導入された。廃止（Deprecated）とマークされた機能は最低12ヶ月は維持されたうえで削除される。今回のリリースで非推奨扱いとなった機能・仕様は以下のとおりだ：

Roots：サーバーがクライアントのファイルシステム構造を参照するための機能
Sampling：サーバー側からLLMの推論を呼び出す機能
Logging：MCP経由でのログ送受信機能
DCR（Dynamic Client Registration）：上述の動的クライアント登録方式
旧来のHTTP+SSEトランスポート：Server-Sent Eventsを用いた旧トランスポート層

元記事ではこれらが「非推奨（Deprecated）」として列挙されているが、機能ごとに削除時期や代替手段が異なる。詳細は仕様の変更履歴で確認されたい。

本番環境での評価

Sentryの共同創業者兼CPOのDavid Cramerは次のようにコメントしている：

「SentryのMCPはCloudflareのSDKで構築した。大いに気に入っている。7-28仕様が確定する前に新バージョンを本番に投入したが、プロダクションは壊れなかった。それも気に入っている。この新仕様は認証とツールまわりのノイズを整理してくれた。エージェントが本当に役に立つのは、配管工事が主役でなくなってからだ。」

本番環境での移行もスムーズだったという点は、後方互換性への配慮と合わせて、今回の仕様改訂の実用的な成熟度を示している。

詳細はThe next generation of MCPを参照していただきたい。