Model Context Protocol（MCP）は2026年7月28日、最終仕様「2026-07-28」を正式公開した。中心にあるのはメタデータ項目の追加ではない。クライアントとサーバーが接続時に行ってきたinitializeハンドシェイクと、HTTP上のMcp-Session-Idを廃止し、MCPをリクエスト／レスポンス型のステートレスなプロトコルへ組み直したことだ。
この改訂によって、各リクエストは自分が使うプロトコル版と能力情報を運ぶ。どのサーバーインスタンスでも同じ要求を処理できるため、スティッキーセッションやプロトコル専用の共有セッションストアを外し、通常のラウンドロビン構成へ載せやすくなる。運用面では、MCPが特殊な双方向接続から、既存のHTTP基盤で扱えるワークロードへ近づいた。
ただし、状態もセキュリティ上の責任も消えたわけではない。状態を示すIDはツールの入出力へ移り、認可は要求ごとに確かめる必要がある。今回の改訂は、MCPを単純化したというより、暗黙だった接続状態を明示的なデータと既存のWeb標準へ分解したものだ。
initializeとMcp-Session-Idの廃止
前版の2025-11-25では、クライアントが最初にinitializeを送り、プロトコル版、クライアント情報、利用可能な機能を交換していた。Streamable HTTPのサーバーがMcp-Session-Idを発行した場合、クライアントは後続の要求へ同じIDを付ける。サーバーを複数台で運用するには、そのIDを見て同じインスタンスへ戻すか、全インスタンスから参照できる状態置き場が必要になり得た。
2026-07-28はinitializeとnotifications/initializedを取り除いた。プロトコル版とクライアント能力は各リクエストの_metaへ入り、HTTPではMCP-Protocol-Versionヘッダーも使う。サーバー側の対応版や能力を先に知りたいクライアントにはserver/discoverが用意されたが、実際の処理に先立って必ず呼ぶものではない。
| 項目 | 2025-11-25までの流れ |
2026-07-28 |
|---|---|---|
| 接続開始 | initializeで版と能力を交換 |
各要求が必要情報を運ぶ |
| HTTPセッション | 発行されたMcp-Session-Idを再送 |
プロトコルセッションを廃止 |
| 能力の事前取得 | initialize応答 |
任意のserver/discover |
| ルーティング | 接続状態やJSON本文へ依存 | HTTPヘッダーで操作を識別可能 |
この変更で、ロードバランサーは要求を任意のインスタンスへ振り分けられる。障害が起きたサーバーへ接続が固定される構成を避けやすく、台数を増減するときもMCP固有のセッション移送を考えずに済む。公式プロジェクトは、4つのTier 1 SDK全体で月間約5億ダウンロード、TypeScriptとPythonはそれぞれ累計10億ダウンロードを超えたと説明している。利用者数を示す数字ではないが、この規模でリモートMCPを運用する開発者にとって、水平展開の制約を外す意味は大きい。
リクエストは軽くなり、運用情報は増える
接続時の状態を減らす一方、ゲートウェイが判断に使える情報は増えた。Streamable HTTPのPOST要求にはMcp-Methodが必須となり、ツールやリソースなど対象名がある操作ではMcp-Nameも付く。ロードバランサー、レートリミッター、WAFはJSON-RPC本文を開かず、操作や対象ごとに経路とポリシーを選べる。サーバーはヘッダーと本文が食い違う要求を拒否するため、検査側と実行側が別の操作を見てしまう状態も防ぐ。
一覧取得とリソース読み出しにはttlMsとcacheScopeが加わった。前者は鮮度をミリ秒で示し、後者は共有キャッシュへ置けるpublicか、利用者ごとに分けるprivateかを伝える。tools/listの並び順も決定的にすることが推奨される。再接続のたびにツール定義の順序が変わらなければ、LLMへ渡すプロンプトも安定し、上流のプロンプトキャッシュを再利用しやすい。
処理途中に利用者の確認や追加情報が必要になる場面は、Multi Round-Trip Requests（MRTR）が担う。サーバーはクライアントへ直接要求を送り続けるのではなく、resultType: "input_required"とinputRequests、再開用のrequestStateを返す。クライアントは回答をinputResponsesへ入れ、元の要求を再送する。必要な状態がペイロードにあるので、再送先は最初と同じインスタンスでなくてよい。
長い接続が全面的に消えるわけではない。ツール一覧やリソースの変更通知は、クライアントが購読するsubscriptions/listenへ集約された。進捗のように一つの要求へ属する通知は、その要求の応答ストリームを流れる。常時開く接続と一時的な処理を分け、何のためのストリームかを狭く定義した設計である。
ステートレス化で認可責任はどこへ移るか
買い物かご、ブラウザー操作、長時間処理の状態までなくすことはできない。新仕様が勧めるのは、basket_idやbrowser_idのような識別子をツールが返し、後続の呼び出しで通常の引数として渡す方法だ。これはMCPに新しい「状態ハンドル型」を追加する話ではない。ワイヤ上では普通の文字列であり、状態の保存、失効、アクセス制御はアプリケーションが実装する。
状態IDがモデルから見えると、別のツールへ引き継ぎやすく、会話を再開したときも同じ状態を参照できる。しかし、そのIDはチャットログ、コピーした文章、サブエージェントへの入力にも現れる。SEP-2567は、認証済みサーバーに対し、呼び出しのたびにハンドルと認証主体の組み合わせを検証するよう求めている。認証がないサーバーではハンドル自体がアクセス権になるため、最低128ビットの暗号学的に安全な乱数と有限の有効期限を推奨する。
認可仕様も同じ方向へ締め直された。認可応答にissが含まれる場合、クライアントは記録した発行者と一致するかを確かめてから認可コードを交換する。これは、クライアントが複数のMCPサーバーと認可サーバーを扱う環境で、応答を別の発行者へ取り違えるOAuth mix-upを防ぐための検査だ。保存したクライアント資格情報も発行者へ結び付け、別の認可サーバーへ使い回してはならない。
Dynamic Client Registration（DCR）ではapplication_typeを明示し、デスクトップやCLIクライアントがweb扱いされ、localhostへのリダイレクトを拒否される問題を避ける。もっとも、DCR自体はClient ID Metadata Documents（CIMD）を優先する方針の下でDeprecatedになった。後方互換のため動き続けるが、新規実装が向かう先はCIMDである。
HTTPヘッダーが増えても、認証は別に必要だ。Mcp-MethodとMcp-Nameは経路選択やポリシー評価の材料である。認可判断には少なくとも、受け取ったトークンが正当か、発行者と対象リソースが一致するか、スコープがその操作を許すかという確認が要る。ステートレス化は認可を不要にするものではなく、接続の裏に隠れていた判断を各要求へ戻す。
UI、長時間処理、企業認可を分ける拡張群
2026-07-28では、用途別の機能をコアへ詰め込まず、任意の拡張として進化させる枠組みも正式になった。公式拡張はio.modelcontextprotocolから始まるIDを持ち、クライアントとサーバーが能力情報で合意した場合だけ動く。片方が対応しなければ、その拡張を使わずに基礎プロトコルで通信できる。
今回並ぶ3つの代表的な拡張は役割が異なる。MCP Appsはチャート、フォーム、動画などのUIを会話内へ表示する。Tasksは、数分から数時間かかる処理を永続的なタスクとして作り、tasks/getで状態を取得し、途中入力をtasks/updateで渡す。Enterprise-Managed Authorization（EMA）は企業のIdPを認可判断の中心に置き、従業員ごと、サーバーごとの許可を管理者が集中管理する。
特にTasksは、前版の試験的なコア機能をそのまま昇格させたものではない。新しいio.modelcontextprotocol/tasks拡張は旧方式とワイヤ互換がなく、tasks/resultとtasks/listを廃止した。長時間処理の結果はtasks/getでポーリングし、取り消しにはtasks/cancelを使う。セッションのない環境で安全な一覧範囲を暗黙に決められないため、tasks/listは残らなかった。
反対に、Roots、Sampling、Loggingと旧HTTP+SSE transportはDeprecatedへ移った。Rootsはツール引数やリソースURIへ、SamplingはLLM事業者のAPIへ、LoggingはstderrかOpenTelemetryへ役割を移す。Deprecatedは削除済みという意味ではない。少なくとも12カ月は機能し続け、実際の削除には別の提案と手続きが必要になる。
拡張と廃止猶予は技術機能に加え、仕様の育て方も変える。用途が限られる機能は独立した版で更新し、コアから外す機能には予告期間を置く。今回のような大規模なワイヤ変更を繰り返さずに済むかは、この運用が守られるかにかかっている。
4つのTier 1 SDKと移行の現実
正式公開時点で、TypeScript、Python、Go、C#の4つのTier 1 SDKが2026-07-28に対応し、Rust SDKもベータ対応した。ただし、仕様日付は切り替え期限ではない。旧版のクライアントとサーバーが7月28日に停止したわけではなく、対応SDKは新旧の版を交渉する経路を持つ。
例えばTypeScript SDKでは、新しい版を話すかどうかは明示的に選ぶ。自動交渉ではserver/discoverを試し、2025-11-25までしか扱えないサーバーなら従来のinitializeへ戻れる。新仕様へ固定する設定ではフォールバックしない。SDK自体のメジャー更新と、実際に新しいワイヤ形式を有効にする作業を分けて試験できるわけだ。
移行ではセッション以外も確認する。全ての結果にresultTypeが必須となり、リソースが見つからない場合のエラーコードは-32002からJSON-RPC標準の-32602へ変わった。古い数値を直接判定しているクライアントは修正が要る。試験的Tasksを使っていた実装は、メソッド名を合わせても足りない。新しいタスク状態遷移へ組み直さなければならない。
したがって、本番移行の判断材料は「最新版SDKを入れたか」では足りない。サーバーがセッションIDへ結び付けていた状態を洗い出し、明示的ハンドルを認証主体へ結合する。新旧版の交渉、MRTRの再送、キャッシュの利用者境界、認可サーバーの発行者検証を実トラフィックで確かめる。MCPは通常のHTTP基盤へ近づいたが、その利点を得るには、接続に預けていた責任を一つずつアプリケーションへ移す必要がある。
