MCP新仕様「2026-07-28」でプロトコルがステートレス化｜変更点と移行の実務

2026年7月28日、Model Context Protocol(MCP)の新しい仕様バージョン「2026-07-28」が公開されました。公式サイトのバージョニングページでも、現行(Current)のプロトコルバージョンは2026-07-28と記載されています。目玉は新機能の追加ではなく、プロトコルの土台の作り直しです。initializeハンドシェイクとプロトコルレベルのセッションが取り除かれ、MCPは双方向でステートフルなプロトコルから、リクエスト/レスポンス型のステートレスなプロトコルへと形を変えました。公式ブログに掲載されたMCP共同考案者David Soria Parra氏のコメントでは、今回の更新は「リモートMCPが登場して1年あまりのなかで、もっとも重要なリリース」と表現されています。この記事では、一次情報で確認できた範囲に絞って、何が変わったのか、なぜ変わったのか、そして立場ごとにいつまでに何をすべきかを整理します。

何が変わったのか:プロトコルコアのステートレス化#

2025-11-25までのStreamable HTTPでは、ツールを1回呼ぶために、まずinitializeを送って初期化を済ませる必要がありました。セッションIDの発行は任意で、サーバーは初期化時にMcp-Session-Idを割り当ててもよい(MAY)と定められており、割り当てられた場合はクライアントが以降のすべてのリクエストに付けなければなりません(MUST)。ステートフルに作られたサーバーではこのセッションIDが、クライアントを「それを発行したインスタンス」に固定していました。

2026-07-28では、この2つが取り除かれています。変更点一覧(changelog)によれば、initialize/notifications/initializedのハンドシェイクは削除され、プロトコルバージョン・クライアント情報・クライアント能力は各リクエストの_metaで運ばれます。Mcp-Session-Idヘッダとプロトコルレベルのセッションも削除されました。同じツール呼び出しは次のような1本のリクエストになります。

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

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28",
 "io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"},
 "io.modelcontextprotocol/clientCapabilities":{}}}}

MCP-Protocol-Versionヘッダの値は、ボディの_metaにあるio.modelcontextprotocol/protocolVersionと一致していなければなりません。片方だけを書いても通らないので、手で組み立てる場合は両方を必ず入れてください(理由は後述します)。

サーバーの能力を先に知りたいクライアントのために、server/discoverという新しいRPCが用意されました。仕様上、サーバーはこれを実装しなければなりません(MUST)が、クライアント側から呼ぶかどうかは任意です。呼ばずにいきなり目的のRPCを投げ、バージョンが合わなければUnsupportedProtocolVersionErrorを受け取って再試行する、という進め方も許されています。

プロトコルはステートレス、アプリケーションはステートフルでよい#

誤解しやすいのはここです。RCの発表記事は「プロトコルレベルのセッションを外すことは、あなたのアプリケーションがステートレスでなければならないという意味ではない」と明記しています。呼び出しをまたいで状態を持ちたいサーバーは、HTTP APIが昔からやってきたことをすればよい、というのが公式の説明です。つまり、ツールから明示的なハンドル(basket_idやbrowser_idのようなID)を発行し、モデルにそれを次の呼び出しの引数として渡させます。

同記事はこのパターンを、単なる代替手段ではなくしばしばより強力な選択肢だと述べています。モデルがハンドルを見て、複数のツールをまたいで受け渡せるからです。トランスポートのメタデータに隠れたセッション状態にはできなかったことだ、という整理です。

なぜ変わったのか:スティッキーセッションという運用コスト#

背景は2026年3月に公開されたロードマップに書かれています。Streamable HTTPはMCPサーバーをリモートサービスとして動かす道を開いた一方で、規模を出そうとすると同じ問題が繰り返し表面化した、という説明です。ロードマップの表現では「ステートフルなセッションはロードバランサと衝突し、水平スケールには回避策が必要になる」とされています。

RCの発表記事は、変更後の効果をより具体的に書いています。これまでスティッキーセッション、共有のセッションストア、ゲートウェイでのディープパケットインスペクションを必要としていたリモートMCPサーバーが、素のラウンドロビン負荷分散の背後で動かせるようになり、Mcp-Methodヘッダでトラフィックをルーティングでき、tools/listの応答をサーバーが許すttlMsの間クライアントにキャッシュさせられる、という内容です。

ゲートウェイ側で効く3つの変更:ヘッダ・キャッシュ・トレース#

インフラ担当の目線でいちばん影響が大きいのはこの3つです。

第一に、必須ヘッダです。Streamable HTTPのPOSTにはMCP-Protocol-Versionが必須で、Mcp-Methodは全リクエスト、Mcp-Nameはtools/call・resources/read・prompts/getで必須と規定されています。これによりロードバランサやレートリミッタは、JSONボディを開かずに操作単位で振り分けや計測ができます。ただし、ヘッダとボディの値が食い違う場合、リクエストを処理するサーバーは400 Bad RequestとJSON-RPCエラーコード-32020(HeaderMismatch)で拒否しなければならないと定められています。ヘッダを見る中間装置と、ボディを見るサーバーが別々の真実を持つ状態を防ぐための規定です。

第二に、キャッシュです。tools/list・prompts/list・resources/list・resources/read・resources/templates/listの結果にttlMs(鮮度のヒント、ミリ秒)とcacheScope(publicまたはprivate)が必須で載るようになりました。cacheScopeは共有の中間装置がキャッシュしてよいかを制御します。あわせて、サーバーはtools/listのツールを決定的な順序で返すことが推奨(SHOULD)されました。順序が安定すると、クライアント側のキャッシュだけでなく上流のプロンプトキャッシュのヒット率も保ちやすくなる、というのが理由として挙げられています。

第三に、トレースです。W3C Trace Contextの伝搬規約が_metaのキー名として文書化され、traceparent・tracestate・baggageが固定されました。ホストアプリで始まったトレースが、クライアントSDK、MCPサーバー、その先の呼び出しまで1つのスパンツリーとして見える、という狙いです。

なお、ツールのパラメータ値をHTTPヘッダへ写すx-mcp-headerという仕組みも追加されています。サーバー側での利用は任意ですが、クライアントは対応が必須(MUST)とされており、注釈が付いていれば指定された値をMcp-Param-{Name}ヘッダに載せます。テナントIDやリージョンでゲートウェイ側の制御をかけたい場合に効く仕組みです。

双方向ストリームからMRTRへ#

ステートレス化でいちばん実装が変わるのは、サーバーがクライアントに何かを尋ねる経路です。従来はサーバー側からelicitation/create・sampling/createMessage・roots/listといったリクエストを送るために、SSEストリームを開いたままにする必要がありました。

2026-07-28では、これがMulti Round-Trip Requests(MRTR)に置き換わりました。サーバーはresultType: "input_required"を持つ結果(InputRequiredResult)を返し、そのinputRequestsに必要な問い合わせを載せます。クライアントは答えを集めたうえで、元の呼び出しをinputResponses付きで再送します。サーバーが自分で発行した識別子はrequestStateに入れてやり取りできるため、再送を受け取ったインスタンスが最初の呼び出しを処理したインスタンスと違っても処理を続けられます。

あわせて、次の点も変わっています。

• すべての結果にresultTypeフィールドが必須になりました。通常の結果は"complete"です。旧バージョンのサーバーが返す、このフィールドの無い結果は"complete"として扱わなければならない(MUST)と規定されています。
• 変更通知の受け取り口がsubscriptions/listenという1本のストリームに集約されました。HTTP GETのエンドポイントとresources/subscribe/resources/unsubscribeは置き換えられ、クライアントはtoolsListChangedなどの種類ごとにオプトインします。
• SSEストリームの再開機能(Last-Event-IDとイベントID)が削除されました。ストリームが切れた場合、クライアントは新しいリクエストIDで発行し直さなければなりません。
• ping、logging/setLevel、notifications/roots/list_changedが削除されました。ログレベルはリクエストごとに_metaのio.modelcontextprotocol/logLevelで指定します。

認可の引き締めとDynamic Client Registrationの非推奨#

公式ブログは「実装者が統合作業でもっとも時間を使うのは認可の部分だ」と述べており、今回の版でもここに手が入っています。

• 認可サーバーはRFC 9207に従って認可レスポンスにissパラメータを含めるべき(SHOULD)であり、MCPクライアントは認可コードを引き換える前に、issが含まれている場合はそれが記録済みのissuerと一致するかを検証しなければなりません(MUST)。changelogの規定は「present(存在する)issの検証」であり、現時点ではissが無いレスポンスを拒否することまでは求められていません。RCの発表記事では、将来のバージョンで欠落レスポンスの拒否が求められる見込みだと述べられています。1つのクライアントが多数のサーバーに接続するというMCP特有の形で起きやすい、認可サーバーの取り違え攻撃への対策です。
• クライアントは動的クライアント登録(DCR)の際に適切なapplication_typeを指定しなければなりません(MUST)。省略するとOIDCでは"web"が既定になり、デスクトップやCLIのlocalhostリダイレクトが弾かれます。心当たりのあるredirect_uriエラーの原因はこれかもしれません。
• クライアント資格情報は、それを発行した認可サーバーに紐づけて保存しなければならず(MUST)、別の認可サーバーで使い回してはいけません(MUST NOT)。移った場合は再登録が必要です。

そして方針として大きいのが、DCR(RFC 7591)そのものの非推奨です。後継はClient ID Metadata Documents(CIMD)で、クライアントは自分のメタデータをHTTPSのURLで公開し、そのURL自体をclient_idとして使います。仕様の登録方式のページでは、事前登録された情報があればそれを使い、無ければ認可サーバーがCIMDに対応していればCIMD、対応していなければDCRにフォールバックする、という優先順位が示されています。CIMDのクライアントIDは自己ホストのHTTPS URLなので認可サーバー間で持ち運べ、認可サーバーが変わっても再登録が要らない、という利点も明記されています。DCRは後方互換のために残りますが、新規実装は避けるべき機能に分類されました。

拡張フレームワークの正式化:TasksとMCP Apps#

拡張機能は2025-11-25にも存在していましたが、正式なプロセスがありませんでした。今回、拡張は逆引きDNS形式のID(例:io.modelcontextprotocol/tasks)で識別され、クライアントとサーバーの能力にあるextensionsマップで交渉し、独自のext-*リポジトリで仕様本体とは別のペースでバージョン管理される、という枠組みが定義されました。片方が対応していない場合は、コアの挙動に戻すか適切なエラーで拒否しなければなりません(MUST)。

この枠組みの最初の住人がTasksとMCP Appsです。Tasksは2025-11-25で実験的なコア機能として提供されていましたが、本番運用で判明した課題を受けて拡張へ移りました。ブロッキング型のtasks/resultはポーリング型のtasks/getに置き換わり、クライアントからの入力用にtasks/updateが追加され、セッション無しでは安全にスコープを切れないという理由でtasks/listは削除されています。2025-11-25の実験的Tasks APIに対して実装した場合は、新しいライフサイクルへの移行が必要だと明記されています。

MCP Appsは、サーバーが対話的なHTMLインターフェースを提供し、ホストがサンドボックス化したiframeで描画する拡張です。ツールがUIテンプレートを事前に宣言するため、ホストが実行前にプリフェッチ・キャッシュ・セキュリティレビューを行える設計になっています。描画されたUIからの操作も、通常のツール呼び出しと同じ監査・同意の経路を通ります。

非推奨になったものと、いつまでに移行するか#

今回の版では、機能ごとのライフサイクル方針(Active/Deprecated/Removed)が正式に採用されました。方針の文面では、非推奨から最短の削除までに最低12か月を置くこと、その期間は「その機能が最初にDeprecatedと記された仕様リビジョンのリリース」から数えることが定められています。セキュリティ上の実害がある場合に限って短縮できますが、その場合でも最低90日は空けなければなりません。

非推奨レジストリに載っている内容を整理すると次のとおりです。

もう一点、レジストリのページ自身が明記しているとおり、最短の削除時期は「削除が可能になる時期」であって削除日ではありません。実際の削除はリリース準備の際にコアメンテナが判断するもので、それより後になることもあります。逆に言えば、この日付を過ぎたら必ず消えると身構える必要も、まだ消えていないから大丈夫と油断する必要もありません。

立場別:いま何をやるか#

対応の重さは立場でまったく違います。3つに分けて整理します。

慌てなくてよい理由と、それでも確認すべきこと#

煽らずに書いておきたいのは、7月28日を境に既存の実装が止まるわけではないという点です。SDKベータの告知記事(2026年6月29日)は「既存のクライアントとサーバーにとって、今日壊れるものは何も無いし、7月28日にも何も壊れない。あの日は規範的な仕様テキストが公開される日であって、現行バージョンに依存している実装のスイッチが切られる日ではない」と明記しています。非推奨になったRoots・Sampling・Loggingについても、注釈のみの非推奨であり、このリリースおよびその後1年以内に公開されるすべての仕様バージョンで動作し続けると書かれています。

一方で、放置してよいという意味でもありません。仕様の互換性マトリクスは、組み合わせによっては単純に失敗すると明記しています。新仕様のみのクライアント(Modern)が旧仕様のみのサーバー(Legacy)につないだ場合、および旧仕様のみのクライアントが新仕様のみのサーバーにつないだ場合は、いずれも失敗します。ただし失敗の理由は別物です。前者はサーバーがモダンなリクエストを解さないため、実装依存のエラーを返す・無反応になる・era(世代)の判別がつかないメソッドをレガシー解釈で処理してしまう、といった結果になります(マトリクスはstdioならserver/discoverを先に送って確実に失敗させることを推奨しています)。後者は、HTTPなら必須ヘッダが無いためサーバー検証で400になり、stdioならinitializeが未知のメソッドとして拒否されるという形で、旧クライアントには前へ進む手段(フォールフォワード)が無いために復帰できません。逆に、新旧両方に対応した実装(dual-era)を挟めばどちらとも通信できます。つまり、自社が提供する側なら、しばらくは両対応にしておくのが実務的な落としどころです。

SDKについては、公式ブログの記載どおりTier 1の4つ(TypeScript・Python・Go・C#)が2026-07-28に対応済みで、Rust SDKはベータとして対応しています。ベータ告知の時点では、PythonとTypeScriptがメジャーバージョンv2へ移行し、GoとC#はパッケージ分割やAPIの作り直しなしで対応する方針とされていました。SDKのメジャーバージョン更新は仕様の更新とは別物で、自分のスケジュールで進めてよい、という説明も同記事にあります。実際に使うバージョン番号と各SDKの対応範囲は、更新が続く部分なので必ず現在のリリースノートで確認してください。

本記事の事実関係は次の一次情報で確認しました。仕様バージョン・ステートレス化・MRTR・必須ヘッダ・キャッシュ・SDK対応状況は2026-07-28の公式リリース発表、設計意図と拡張フレームワーク・Tasks・MCP AppsはRCの発表記事、削除された機能やエラーコードの詳細はKey Changes、非推奨と最短削除時期は非推奨レジストリとライフサイクル方針、ヘッダ検証と後方互換はStreamable HTTPとVersioning and Compatibility、CIMDとDCRの優先順位はClient Registration、ステートレス化の背景は2026年のロードマップ、「7月28日に何も壊れない」の記述はSDKベータの告知記事によります。個別SDKのバージョン番号は更新が続くため本文では扱っていません。

よくある質問#

まとめ#

2026-07-28は、新機能で盛り上がるタイプの更新ではありません。むしろ、リモートMCPを本番で運用してきた人たちが回避策で埋めてきた穴を、プロトコル側で塞ぎにいった更新です。スティッキーセッションが不要になり、ゲートウェイがヘッダで判断でき、ツール一覧をキャッシュできる。どれも地味ですが、運用の手触りに直接効きます。

同時に、破壊的変更を含む版でもあります。公式自身が「これを常態にするつもりはない」と述べ、12か月の最小ウィンドウを持つライフサイクル方針と拡張フレームワークを同じリリースで導入したのは、今回のような作り直しを最後にしたいという意思表示だと読めます。だからこそ、いま慌てて全面移行するより、自社の構成のうちどこがセッション前提になっているかを把握し、SDKの対応を見ながら順に外していくのが妥当な進め方です。まずは棚卸しからで十分に間に合います。