次世代MCPをCloudflareが実装：Durable Objects なしでMCPサーバーが書けるようになった

要約

Cloudflare が 2026-08-06、MCP の新仕様 2026-07-28 に対する実装側の対応をまとめて発表しました。仕様そのものは 2026-07-28 に確定済みで、Anthropic が Claude への反映を同日に発表しています。今回の発表は「その仕様で実際に MCP サーバーをどう書き、どこで動かすか」を Cloudflare の実装として示すものです。

中心にあるのはステートレス化です。従来の MCP はハンドシェイクと Mcp-Session-Id ヘッダーによるセッション管理を前提としていました。新仕様ではこれらがリクエストパスから外れ、各リクエストが独立して成立します。Cloudflare にとってこの変更が大きいのは、これまで Workers 上で MCP サーバーを動かすには Durable Objects でセッション状態を保持する構成が事実上必須だったからです。ステートレスになったことで、素の Workers に置ける — つまり常駐プロセスも状態保持レイヤーも要らなくなりました。

実装面での目玉は createMcpHandler の扱いです。これは Cloudflare が提供してきたヘルパーですが、MCP の TypeScript SDK 本体へ正式に取り込まれました。ベンダー固有のラッパーではなく、公式 SDK の API としてステートレスサーバーを書けるようになったという意味です。あわせて MCP SDK 自体が Web 標準ベースへ載せ替えられ、Node 依存が外れて Bun / Deno / Workers で動くようになりました。

移行の現実的な問題にも手当てがあります。2025 年仕様のクライアントはしばらく残るため、Cloudflare は1つの /mcp エンドポイントで新しいステートレスクライアントと旧仕様クライアントの両方を受ける後方互換を用意しています。サーバー側を先に新仕様へ移し、クライアント側の入れ替えを待てる構成です。

仕様側の変更で運用に効くのが、Mcp-Method と Mcp-Name という HTTP ヘッダーの追加です。これまでゲートウェイやセキュリティ製品が「どのツールがどう呼ばれたか」を知るには JSON 本文を解析する必要がありました。ヘッダーに出ることで、本文を開かずにリクエスト内容を判別できます。地味ですが、ツール単位のレート制限・監査・ブロックを既存のネットワーク機器層で組めるようになる変更です。

他にも、ストリーム依存だった elicitation は Multi Round-Trip Requests（MRTR） に置き換えられ、サーバーが input_required を返すリクエスト/レスポンス型になりました。ツール・プロンプト・リソースのカタログには ttlMs と cacheScope のキャッシュヒントが入ります。認可では Dynamic Client Registration が非推奨化され、事前登録クライアントと Client ID Metadata Documents へ移行、RFC 9207 の issuer 識別が採用されました。

非推奨まわりでは、削除の12か月以上前に予告するというライフサイクルポリシーが正式に定められています。対象は Roots、Sampling、Logging、Dynamic Client Registration、旧 HTTP+SSE トランスポート。SDK は TypeScript / Python / Go / C# が更新済みで、即日利用できます。

何が変わったか

• Durable Objects を使わず、素の Workers 上にステートレスな MCP サーバーをデプロイできる
• createMcpHandler が MCP TypeScript SDK 本体の公式 API として取り込まれた
• MCP SDK が Web 標準ベースへ載せ替えられ、Bun / Deno / Workers で動作する（Node 依存の解消）
• 1つの /mcp エンドポイントで、新ステートレスクライアントと 2025 年仕様クライアントの両方を受けられる
• Mcp-Method / Mcp-Name ヘッダーにより、JSON 本文を解析せずツール単位の制御・監査ができる
• elicitation が Multi Round-Trip Requests（サーバーが input_required を返す形式）へ置き換わった
• カタログに ttlMs / cacheScope のキャッシュヒントが追加された
• Dynamic Client Registration が非推奨化され、事前登録クライアントと Client ID Metadata Documents へ移行
• 非推奨機能には12か月以上の予告期間を置くライフサイクルポリシーが定められた
• Cloudflare API を提供する Code Mode MCP サーバーが運用実績として示された（数十億回のツール呼び出し）

業務インパクト（一般企業向け）

社内向けに MCP サーバーを立てている、あるいは立てようとしている組織にとって、これは運用コストの構造が変わる話です。

これまで MCP サーバーの提供は「常駐する何か」を用意する前提でした。セッション状態を持つため、コンテナなり Durable Objects なりを維持する必要があり、利用が少ない時間帯もリソースを確保し続ける形になります。社内の一部門だけが使うツール群を MCP で出す、といった小さな用途では、この固定コストと運用負荷が導入のハードルになっていました。ステートレスになると、リクエストが来たときだけ動く形にできます。利用が散発的な社内ツールほど恩恵が大きい変更です。

一方で、既存実装がある組織には移行作業が発生します。セッションに状態を溜める設計 — 認証状態、会話コンテキスト、進行中の処理 — をしている場合、その状態をどこに置くかを設計し直す必要があります。後方互換エンドポイントがあるためクライアント側は急がなくてよいものの、サーバー側の書き換えは避けられません。稼働中の MCP サーバーがあるなら、まず棚卸しして「セッションに何を持たせているか」を洗い出すところから始めるのが妥当です。

情シス・セキュリティ観点では、Mcp-Method / Mcp-Name ヘッダーの追加が効きます。社内のエージェントがどの MCP ツールをどれだけ呼んでいるかを、アプリケーションのログではなくネットワーク層で把握できるようになります。「エージェントに何を許可しているか」を統制する仕組みを、既存の API ゲートウェイやプロキシの延長で組める見通しが立つということです。これまでは MCP サーバー自体にログと制限を実装するしかなく、サーバーごとに実装品質がばらつく問題がありました。

Dynamic Client Registration の非推奨化も、企業導入では歓迎すべき方向です。クライアントが動的に自己登録できる仕組みは開発中は便利ですが、「誰がこのサーバーに繋がっているか」を管理側が把握できない構造でもありました。事前登録前提になることで、接続元の棚卸しが可能になります。ただし非推奨機能に依存している実装がある場合、12か月という予告期間は「余裕がある」というより「その間に計画を立てろ」という長さです。

副業・個人活用視点

個人で MCP サーバーを作って公開している、あるいは受託で納品している場合、ホスティングコストの話が一番直接的に効きます。

これまで「MCP サーバーを作りました、使ってください」を実現するには、動かし続ける環境が必要でした。趣味や実験で作ったものを常時稼働させるのは、金額としては小さくても心理的な負担があります。Workers 上でステートレスに置けるなら、使われないときはコストがほぼ発生しない形にできます。作ったものを公開したまま放置しやすくなる、というのは個人開発者にとって実務的な意味を持ちます。

受託の観点では、提案の幅が広がります。「社内ツールを MCP 化してエージェントから使えるようにする」という案件で、これまでは常駐環境の用意がセットでした。運用を誰が見るのか、という話になった時点で止まる商談もあったはずです。サーバーレスで完結する構成なら、初期構築だけで納品して運用負荷をほぼゼロにできるパターンが作れます。小規模な案件ほど成立しやすくなる方向です。

技術的な学習投資としては、createMcpHandler が公式 SDK に入ったことの意味を押さえておく価値があります。Cloudflare 固有のヘルパーを覚えるのではなく、MCP 公式 SDK の使い方を覚えれば Bun / Deno / Workers のどこでも通用する、という構図になりました。特定ベンダーに寄せた学習ではなくなったぶん、身につけたことの持ちが良くなります。

注意点として、仕様がここまで動くということは、今後も動く可能性があるということです。非推奨予告が12か月と明示された点は歓迎すべきですが、逆に言えば「12か月で消えるものがある」前提で作る必要があります。納品物に MCP を組み込むなら、仕様バージョンを明示し、更新が必要になる時期の目安を提案書に書いておくのが誠実です。