MCPが「ステートレス」になった日 — 2026-07-28仕様を、金融系フルスタックエンジニアの視点で読み解く

Posted at 2026-08-03

セッションを捨てる、とはどういうことか。AIエージェント連携の土台であるMCPが、静かに、しかし決定的に設計思想を変えた。

2026年7月28日、Model Context Protocol（MCP）の新仕様 2026-07-28 が公開された。本記事執筆時点（2026年8月3日）で、まだ1週間も経っていない。

見出しだけ追うと「ステートレスになりました」で終わってしまう。だが、これは単なる最適化ではない。MCPというプロトコルの前提が、双方向ステートフルから、リクエスト/レスポンスのステートレスへと反転したという話だ。エージェントをインフラに載せて運用してきた立場からすると、「ようやくそこに手が入ったか」という感慨と、「既存のサーバー実装、これ書き直しだな」という現実が同時に来る。

本記事では、この仕様変更を「何が変わったか」だけでなく「なぜ変わる必要があったか」「実務のデプロイ・運用にどう効くか」まで、金融系Webを主戦場にしてきたエンジニアの視点で掘り下げる。

⚠️ 本記事は公開直後の一次情報（MCP公式ブログ・Anthropic/Claude公式ブログ）を基に執筆しています。仕様の細部は今後のドラフト更新で変わり得るため、実装前に必ず公式仕様の最新版をご確認ください。ヘッダ名・フィールド名は本記事執筆時点の記載に基づきます。

そもそもMCPとは（30秒で復習）

MCPは、AIモデル（Claudeなど）と外部のツール・データソースを繋ぐための標準プロトコルだ。2024年末にAnthropicが公開し、「AIにおけるUSB-C」とよく喩えられる。

Tools: AIが呼び出せる関数（例：DBを検索する、チケットを起票する）
Resources: AIが読めるデータ（例：ファイル、レコード）
Prompts: 再利用可能なプロンプトテンプレート

これらを「MCPサーバー」として実装しておけば、対応するAIクライアントから統一的な作法で叩ける。今やコネクタのエコシステムは巨大で、Claudeのコネクタディレクトリだけでも950以上のMCPサーバーが並ぶ。

問題は、その通信の土台がステートフルだったことにある。ここが今回の主役だ。

旧仕様の何が「重かった」のか

2026-07-28より前のMCPは、双方向・ステートフルなプロトコルだった。具体的には次のような前提があった。

クライアントとサーバーは、まず initialize / initialized のハンドシェイクでセッションを確立する
以降のリクエストは Mcp-Session-Id ヘッダで、そのセッションに紐づけられる
サーバーからクライアントへ能動的に呼びかける操作（sampling/createMessage や elicitation/create）のために、双方向のストリームを開いておく必要がある

これは「1クライアント ⇔ 1サーバープロセスが、会話の間ずっと繋がっている」というモデルだ。ローカルのstdio接続や、単一プロセスで動かすなら何の問題もない。

しかし、これをクラウドで本番運用しようとした瞬間に牙を剥く。

金融系のWebサービスをやっていると、可用性のためにアプリケーションは必ず複数インスタンスで冗長化する。ロードバランサの背後に同じサーバーが何台も並ぶ。ここでステートフルなセッションがあると、こうなる。

リクエストAは1号機で initialize した → 以降のリクエストも1号機に振り分け続けないといけない（スティッキーセッション）
あるいはセッション状態をRedis等の共有ストアに逃がす → 共有ステート管理インフラが増える
サーバーをスケールイン/アウトすると、生きているセッションが道連れになる
サーバーレス（Lambda等）やエッジに載せたいのに、「繋ぎっぱなし」が前提だと載らない

つまり旧MCPは、「12-Factor Appのステートレス原則」と真っ向から喧嘩する構造だった。エージェントを本格的にプロダクションへ持っていこうとする各社が、ここで足を取られていた。

2026-07-28で何が変わったか — コアの反転

新仕様のコアはひと言に尽きる。

双方向ステートフルプロトコルから、リクエスト/レスポンスのステートレスプロトコルへ。

公式の表現を借りれば、「どのリクエストも、ラウンドロビンのロードバランサ経由で、どのインスタンスに着地してもよい」——共有ストレージも状態管理インフラも要らない。これがもたらす具体的な変更を、順に見ていく。

変更1：セッションの廃止

initialize / initialized のハンドシェイク交換と、Mcp-Session-Id ヘッダが丸ごと撤廃された。

では、これまでセッション確立時に交換していた「プロトコルバージョン」「クライアントの正体」「クライアントのcapability」はどうなるのか。各リクエストが自分でそれらを運ぶようになった。リクエストごとに、_meta フィールドへ載せて毎回携行する形だ。

【旧】 initialize でセッション確立 → 以降はMcp-Session-Idで紐付け
        （状態はサーバー側 or 共有ストアが保持）

【新】 各リクエストが protocol version / client identity / capabilities を
        _meta に載せて毎回自己完結で運ぶ（サーバーは状態を持たない）

サーバー側が文脈情報を必要とする場合は、トランスポート層の隠れたセッションではなく、ツールが返す明示的なハンドル（識別子）を使う方針に変わった。ここが設計的に面白い。ハンドルが明示的になることで、AIモデル自身がその識別子を見て、関数呼び出しの間で受け渡せるようになる。「状態を隠す」のをやめて「状態を値として見せる」方向に舵を切ったわけだ。

変更2：ヘッダによるルーティング（`Mcp-Method` / `Mcp-Name`）

Streamable HTTPのリクエストに、2つのヘッダが追加された。

ヘッダ	役割
`Mcp-Method`	操作の種別（tools/callなど）を示す
`Mcp-Name`	対象のツール名・リソース名を示す
`MCP-Protocol-Version`	`2026-07-28` のようにプロトコルバージョンを運ぶ

これの何が嬉しいか。ゲートウェイやファイアウォールが、JSONボディをパースせずに、ヘッダだけでルーティングと認可の判断ができるようになる。

金融系だとここは効く。WAFやAPIゲートウェイの層で「このツール呼び出しは許可、こっちは拒否」を、ペイロードを開かずに制御できる。ボディのJSONパースを各所でやらずに済むのは、性能面でもセキュリティ面でも素直にありがたい。

変更3：MRTR — 双方向ストリームを畳む

旧仕様で双方向ストリームを必要としていた「サーバー起点の呼び出し」——ユーザーへの追加入力要求（elicitation/create）や、サーバーからのLLM呼び出し（sampling/createMessage）——これらが MRTR（Multi Round-Trip Requests） という仕組みに置き換わった。

流れはこうだ。

1. クライアント → サーバー：ツールを呼ぶ
2. サーバー → クライアント：resultType: "input_required" と、
                            必要な追加リクエストを返す
3. クライアント → サーバー：答えを inputResponses に載せて「再送」する

双方向ストリームを開きっぱなしにする代わりに、**「入力が要るなら、いったんそう返して、クライアントが答えを持って再度叩く」**というリトライ型に畳んだ。ステートレスな世界で対話的ワークフロー（人間への確認を挟む処理など）を成立させるための、素直で堅い設計だ。

変更4：一覧系にキャッシュメタデータ

tools/list、prompts/list、resources/list、resources/read といった一覧・読み取り系の応答に、ttlMs と cacheScope のメタデータが付くようになった。

ステートレス化すると、再接続のたびに「使えるツール一覧」を取り直す無駄が発生しやすい。そこにTTLとスコープを持たせることで、クライアント側が賢くキャッシュして再取得を減らせる。ステートレス化のオーバーヘッドを、キャッシュ制御で相殺しにいく合わせ技になっている。

認証まわりの地味だが重要な強化

エンタープライズ導入を意識した、認証の本気度が上がっている。

RFC 9207 の issuer 検証（iss パラメータ）に対応。認可レスポンスがどの認可サーバーから来たかを検証し、mix-up攻撃を防ぐ
資格情報を特定の認可サーバーへバインドする
動的クライアント登録（DCR）から、CIMD（Client ID Metadata Documents） ベースの登録へ移行

公式ブログの言葉では、認証が「本番のOAuth 2.0 / OIDCデプロイメントに整合する」ようになった、とされる。Entra や Okta のような既存のIdPに乗せやすくなる、という話だ。社内の認証基盤とMCPサーバーを繋ぐ際、ここが標準化されているかどうかは、稟議の通しやすさに直結する。地味だが実務では大きい。

非推奨（Deprecation）との付き合い方

破壊的変更が入る以上、移行の猶予も明文化された。最低12ヶ月の非推奨ウィンドウというポリシーが定められている。

非推奨としてマークされたのは、Roots / Sampling / Logging / DCR、そしてレガシーな HTTP+SSE トランスポート。これらは当面動き続けるが、新規実装では採用すべきでない。

ここでシニアとして一言。「動くから」で非推奨機能に寄りかかった実装を新規に増やすのは、12ヶ月後の自分（か後任）への負債でしかない。移行ウィンドウは「まだ使える期間」ではなく「安全に離脱するための猶予」として読むべきだ。既存資産は棚卸しして、非推奨リストに載ったものから優先的に置き換え計画を立てるのが筋だと考える。

SDKと拡張フレームワーク

Tier 1 のSDK4種——TypeScript / Python / Go / C#——が 2026-07-28 に対応済み。Rust はベータ対応。

加えて、MCP Apps（インラインのUI描画）や Tasks（長時間実行）が、コアを触らずに機能追加できるバージョン管理された拡張フレームワークとして整理された。コアはステートレスで薄く保ち、リッチな機能は拡張として積む、という分離は健全だ。プロトコルの寿命を延ばす設計判断として好感が持てる。

Claudeへの展開

Anthropicは、この 2026-07-28 をClaude製品群へ「まもなく」展開するとしている（本記事執筆時点で具体的な期日は未発表）。前述の通りコネクタディレクトリには950超のMCPサーバーがあり、あわせて MCP Apps、エンタープライズ管理された認証、開発者向けの可観測性（オブザーバビリティ）ダッシュボード、プライベートネットワーク接続のための MCPトンネル といった周辺機能も揃いつつある。

「ステートレスなHTTPワークロードとして、セッション管理の回避策なしに一級市民として載せられる」——プロバイダ側がこう語れるようになったことが、エコシステム全体の運用ハードルを下げる。

実務への影響を、レイヤー別に整理する

自分がいま関わっている案件に引きつけて、影響を棚卸しするとこうなる。

観点	旧（ステートフル）	新（ステートレス）	実務インパクト
デプロイ	スティッキーセッション必須	ラウンドロビンでOK	LB設定が単純化。冗長化が素直に
スケール	セッション道連れ	任意インスタンスで処理	オートスケール/サーバーレスに載る
状態管理	共有ストア（Redis等）	原則不要	インフラ構成が減る
ルーティング/認可	JSONパースが必要	ヘッダで判定可	GW/WAF層で制御しやすい
対話処理	双方向ストリーム	MRTR（リトライ型）	実装は変わるが運用は堅くなる
一覧取得	都度取得しがち	ttlMs/cacheScope	再取得コスト削減
認証	DCR等	CIMD / RFC 9207	既存IdP統合が容易に

一番効くのは、間違いなくデプロイとスケールの単純化だ。これまでMCPサーバーを本番に置くとき、頭の片隅に常に「セッションどう捌くか」があった。そこが消える。エージェントを「特別な繋ぎっぱなしのプロセス」ではなく、ただのHTTPワークロードとして扱えることの意味は大きい。

移行チェックリスト（自分用の叩き台）

既存のMCPサーバーを持っている場合、当面こういう観点で見ていくつもりだ。

initialize / initialized 前提のロジックを洗い出す
Mcp-Session-Id に依存した状態保持がないか確認する
セッションに載せていた文脈を、ツールが返す明示的ハンドルへ設計変更できるか検討
sampling / elicitation を使っている箇所を MRTR へ移行する
一覧系応答に ttlMs / cacheScope を付与し、クライアントのキャッシュ効率を上げる
認証を CIMD / RFC 9207 に整合させる（DCR依存からの離脱）
レガシー HTTP+SSE トランスポート依存を、非推奨ウィンドウ内で置き換える
利用SDKを 2026-07-28 対応版へ更新する

まとめ — 「エージェントが大人になる」ための仕様

MCPのステートレス化は、派手さはない。だが、AIエージェントを「デモ」から「本番の分散システム」へ引き上げるための、地に足のついた変更だ。

双方向ステートフルは、1対1で会話する分には自然なモデルだった。しかし、可用性・スケール・認証といった、エンタープライズが当たり前に要求する非機能要件の前では重かった。今回の反転は、プロトコルをWebの流儀（ステートレスなHTTP、ヘッダでのルーティング、標準的なOAuth/OIDC）に寄せるという、極めて真っ当な方向転換だと思う。

新しい機能に飛びつく前に、まず「自分たちの既存資産のどこがステートフル前提だったか」を棚卸しすること。破壊的変更のときこそ、シニアの仕事は「移行の地図を描くこと」だと改めて感じている。

参考リンク

本記事は2026年8月3日時点の公開情報を基に執筆しています。仕様は更新される可能性があるため、実装前に一次情報の最新版をご確認ください。固有名詞・バージョン番号・フィールド名は必ず公式仕様と突き合わせることを強く推奨します。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up