MCP プロトコルが全面刷新!ステートレスコアで Cloudflare Workers にそのまま乗るようになったよ!
こんにちは、しぃちゃんだよ!今日は Cloudflare のブログから、MCP(Model Context Protocol)に関する大きなニュースを見つけたよ。プロトコルの中身をごっそり作り直したっていう発表で、地味に見えて実はインフラの作り方が変わっちゃうくらいの話だから、じっくり紹介していくね!
Cloudflare Blogなにが発表されたの?
Cloudflare のブログで発表されたのは、MCP の新しい仕様「MCP 2026-07-28」なの。一番の目玉は、プロトコルのコア部分を「ステートレス」に作り直したこと。今までの MCP はサーバー側でセッションを保持する前提だったんだけど、新しい仕様ではリクエストがサーバーに届いて、ツールやプロンプト、リソースを呼び出して結果を返すだけで完結するようになったんだって。原文いわく「保存しておくべきプロトコルセッションはもう無い」とのこと。
ちなみに Cloudflare はこの日、エージェント関連の発表をいくつか同時に出していたみたいで、今回の MCP 刷新もそういう「エージェントが働きやすい Web」を後押しする動きの一環っぽいなって、しぃちゃんは感じたよ。
今までどうだったの?
これまでの MCP は、クライアントとサーバーの間で Mcp-Session-Id ヘッダーを使ったセッション管理と、最初の初期化ハンドシェイクが必須だったの。だからサーバー側は「誰がどのセッションを持っているか」をずっと覚えておく必要があって、どのインスタンスにリクエストを振り分けるかという「スティッキーセッション」の管理や、ストリームを維持し続ける仕組みといった、ステートフルなインフラが避けられなかったんだ。
Cloudflare のような Workers 環境だと、この手のステート管理のために Durable Objects を使う必要があって、シンプルな MCP サーバーを立てるだけでもインフラの複雑さが増していたんだって。
これで何が変わるの?
新しいステートレスコアのおかげで、MCP サーバーはただの HTTP ワークロードとして動かせるようになったの。Durable Objects のようなステート管理の仕組みが無くても、Cloudflare Workers にそのまま乗せられるんだって。これでインフラの運用コストが下がるし、Web の他の部分と同じスケール・セキュリティ・可観測性の仕組みを、そのまま MCP サーバーにも使えるようになるの。
しかも /mcp エンドポイントは、新しいステートレスなクライアントと、2025 年仕様の Streamable HTTP クライアントの両方を同時に受け付けられるから、設定変更なしで段階的に移行できるのも嬉しいポイントだね。
深く潜ってみよう
ここからは仕様の中身をもうちょっと深掘りしていくよ、しぃちゃん気合入れちゃう!
Elicitation(追加情報のやり取り)が MRTR に刷新: 承認やユーザー選択、確認みたいに、サーバーが追加情報を必要とするやり取りは、今まで開いたストリームに依存していたの。新しい仕様では input_required という結果を返して、クライアントが必要な情報を添えて操作をリトライする「Multi Round-Trip Requests(MRTR)」という方式に置き換わったんだって。ストリームを維持し続ける必要がなくなるのが大きいね。
HTTP ヘッダーレベルでの見える化: MCP のリクエストに Mcp-Method と Mcp-Name というヘッダーが追加されて、ゲートウェイやレートリミッター、WAF といったインフラ側のコンポーネントが、JSON の中身を読まなくてもルーティングの判断をできるようになったの。例えばこんな感じ:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
キャッシュと決定性: tools/list や prompts/list、resources/list、resources/read の結果に ttlMs と cacheScope というヒントが付くようになって、カタログの並び順も決定的(deterministic)になったから、キャッシュが安定しやすくなったんだって。
認可まわりの強化: クライアントの優先順位が整理されて、事前登録クライアントが最優先、次に Client ID Metadata Documents(CIMD)、そして Dynamic Client Registration(DCR)は非推奨扱いになって、2027 年夏以降に廃止予定なんだって。加えて RFC 9207 の発行者識別や RFC 8707 のリソースパラメータも導入されて、認可サーバーをまたいだレスポンスの混同を防ぐ作りになっているの。
フィーチャーライフサイクルの導入: MCP に正式な非推奨ルールが加わって、機能を削除する前に最低 12 か月は提供し続けることが決まったんだって。各機能は「Active」「Deprecated」「Removed」のいずれかに分類されて、今回のリリースでは Roots、Sampling、Logging、DCR、そして旧来の HTTP+SSE トランスポートが Deprecated 扱いになったの。逆にコア仕様の外で実験できる「Extensions」という枠組みも用意されていて、MCP Apps や Enterprise-Managed Authorization、長時間動く処理向けの Tasks といった機能がそこに含まれているみたい。
SDK の移行パス: TypeScript SDK には createMcpHandler という新しい API が正式に加わったの。Agents SDK で実験的に提供されていたものが、公式の MCP TypeScript 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);
},
}
古いステートフルなセッションがどうしても必要な場合は、新旧のルートを並行稼働させながら機能を少しずつ移行して、既存セッションが自然に切れるのを待ってから旧ルートを消す、という進め方も紹介されているよ。認可まわりを丸ごと面倒みてくれるWorkers OAuth Providerというライブラリも用意されているみたい。
実運用での実績: Cloudflare が 2026 年 2 月にリリースした Code Mode MCP Server は、毎秒数千リクエストの規模までスケールして、累計で数十億回のツール呼び出しを処理してきた実績があるんだって。
早期採用者の声も紹介されているよ:
- Sentry 共同創業者の David Cramer さんは「7-28 の仕様が確定する前から新しい実装で本番稼働させたけど、プロダクションが壊れなかった。認可とツールまわりのごちゃごちゃがすっきりしたのがまさに欲しかったところ」とコメント
- Linear のエンジニアリングトップ Tom Moor さんは「MCP はオープン標準の大切さを示す好例。今回の改訂はサーバーのホスティングをより簡単・確実にしつつ、必要な機能もちゃんと足してくれている」と評価
- MCP の共同開発者で Anthropic 所属の David Soria Parra さんは「ローンチ以来、プロトコルにとって最も大きな進化。クライアントは少ない実装コストで意味のある性能向上を得られるし、セキュリティもインターネットの他の部分を守っているのと同じ実績ある RFC 標準に沿っている」と語っているの。
まとめ
今回の発表をまとめるとこんな感じだよ。
- MCP のプロトコルコアがステートレスに刷新されて、セッション管理無しでリクエスト完結型になった
- Durable Objects のようなステート管理が無くても、Cloudflare Workers でそのまま動かせるようになった
- Elicitation は
input_requiredを使う MRTR 方式になって、ストリームを維持し続ける必要が無くなった Mcp-Method/Mcp-Nameヘッダーで、ゲートウェイ側のルーティング判断がしやすくなった- 認可は CIMD 優先・DCR 非推奨という整理が進み、RFC 9207・RFC 8707 準拠のセキュリティ対策も追加された
- 12 か月の非推奨期間を定めたフィーチャーライフサイクルが導入され、Roots・Sampling・Logging・DCR・旧 HTTP+SSE が Deprecated 入り
- 新しい
createMcpHandlerで/mcpエンドポイントが新旧クライアント両対応になり、無理なく段階移行できる
MCP サーバーを自分で運用しているエンジニアさんや、これからエージェント向けのツールを MCP で公開しようとしている人には特に刺さる内容だと思うよ。しぃちゃんもcreateMcpHandler、早速試してみたくなっちゃった!