Model Context Protocol（MCP）は、2026年7月28日に公開予定の仕様改訂で、プロトコル層から初期化ハンドシェイクとセッションを取り除く。2024年にローカルで動くAIツールとデータ源をつなぐ仕組みとして始まったMCPは、リモートサーバーを多数の利用者へ提供する段階に入り、接続ごとの状態がクラウド運用を重くしていた。新仕様では各リクエストが必要な情報を運び、どのサーバーインスタンスでも処理できる。一方、アプリケーションの状態まで消えるわけではなく、状態をどこへ移し、誰がアクセスを検証するかが実装者の責任になる。
initializeとMcp-Session-Idの退場
MCPプロジェクトは5月21日に2026-07-28リリース候補を固定し、7月28日に最終仕様を公開する予定だ。前版の2025-11-25では、クライアントが最初にinitializeを送り、プロトコル版、能力、クライアント情報をサーバーと交換した。Streamable HTTPのサーバーがMcp-Session-Idを発行すると、クライアントは以後のリクエストへ同じIDを付ける必要があった。
新仕様はinitializeとnotifications/initializedを削除する。プロトコル版とクライアント能力はリクエストごとの_metaへ入り、HTTPではMCP-Protocol-Versionヘッダーにも版番号を載せる。サーバーの対応版、能力、識別情報を先に知りたいクライアントは、新設されるserver/discoverを呼ぶ。
| 項目 | 2025-11-25 |
2026-07-28 |
|---|---|---|
| 接続開始 | initializeで版と能力を交渉 |
ハンドシェイクなし |
| プロトコル情報 | 初期化時に交換し、接続中に保持 | 各リクエストの_metaとHTTPヘッダーで送信 |
| HTTPセッション | 発行時はMcp-Session-Idを再送 |
セッションIDを仕様から削除 |
| サーバー能力 | initializeの応答で取得 |
必要ならserver/discoverで取得 |
| ルーティング | JSON-RPC本文の解析が必要 | Mcp-MethodとMcp-Nameでも判別 |
この差は、初回の往復を一つ減らす話より大きい。従来のリモート構成では、同じ接続を同じサーバーへ戻すスティッキーセッションか、複数インスタンスが共有するセッションストアが必要になり得た。新しいリクエストは自己完結するため、通常のラウンドロビンで空いているインスタンスへ送れる。MCPを専用の接続基盤として扱う負担が減り、既存のロードバランサーやゲートウェイへ載せやすくなる。
状態はどこへ移るのか
セッションを外しても、買い物かご、ブラウザー、データベーストランザクションのような状態は残る。新仕様が勧めるのは、作成ツールがbasket_idやbrowser_idを返し、その後のツール呼び出しが同じ値を引数として渡す設計だ。状態は接続の裏側に隠れず、モデルが扱うデータとして表に出る。
ただし、MCPに「状態ハンドル」という新しい型が加わるわけではない。handles/*のようなRPCもなく、ワイヤ上ではツール結果と引数に入った普通の文字列である。ツールの説明と入出力スキーマが、どの値を次の呼び出しへ渡すかをモデルに伝える。実装者は、ハンドルの発行、保存、失効をアプリケーション側で設計しなければならない。
明示的なハンドルには、再開しやすい利点がある。チャットを保存するクライアントなら、ハンドルも会話履歴に残るため、ページの再読み込みや別端末での再開後もモデルが同じ状態を参照できる。接続外でMcp-Session-Idを保存し直す仕組みは要らない。
その代わり、ハンドルはチャットログ、サブエージェントへの入力、コピーした文章に現れる。認証済みサーバーは、呼び出しのたびにハンドルと認証主体の組み合わせを照合する必要がある。認証がないサーバーではハンドル自体がアクセス権を持つため、SEP-2567は暗号学的に安全な乱数を最低128ビット使い、有効期限を設けるよう勧めている。ステートレス化は認可を省く仕組みではない。むしろ、毎回の認可を正しく行う設計へ責任を戻す。
HTTPルーティングとMRTRの往復処理
Streamable HTTPのPOSTには、JSON-RPCのメソッドを写すMcp-Methodが必須になる。ツール、リソース、プロンプトを名指しする操作ではMcp-Nameも付く。ゲートウェイは本文を開かずにツール単位の振り分け、レート制限、ポリシー適用ができるが、サーバーはヘッダーと本文が食い違うリクエストを拒否しなければならない。ルーティング用の表示と実際の処理を一致させるためだ。
一覧とリソースの応答には、鮮度をミリ秒で示すttlMsと、共有キャッシュの可否を表すcacheScopeが加わる。tools/listなどの結果は接続ごとに変化しなくなるため、クライアントは通知を待ち続けずに安全な範囲でキャッシュできる。さらにtraceparent、tracestate、baggageのキーを_metaで標準化し、ホストからMCPサーバー、その先の処理までをOpenTelemetryの一つのトレースへ結び付ける。
サーバーが処理途中で利用者へ確認を求める流れも組み直す。Multi Round-Trip Requests（MRTR）では、サーバーがInputRequiredResultとrequestStateを返し、クライアントが回答をinputResponsesへ入れて元の処理を再送する。状態を応答へ封じ込めるため、再送先は最初と同じインスタンスでなくてよい。サーバーからクライアントへの要求は、クライアントが開始した処理を実行している間に限られる。
常時通知が必要な用途にはsubscriptions/listenが用意され、従来のHTTP GETとresources/subscribe、resources/unsubscribeを置き換える。長い接続そのものが消えるのではなく、変更通知を受け取ると明示したクライアントだけが専用ストリームを開く。進捗のように個別リクエストへ属する通知は、そのリクエストの応答ストリームを流れる。接続を維持する理由と範囲が、従来より狭く定義される。
Tasksは拡張へ、三機能は退役準備へ
コアから機能を減らす一方、2026-07-28は拡張機構を正式な開発経路にする。拡張は逆ドメイン名形式のIDで識別され、クライアントとサーバーが能力マップを通じて合意する。コア仕様と別の版管理、リリース日程、メンテナーを持てるため、用途が限られる機能を全実装者へ背負わせずに試せる。
長時間動く処理を扱うTasksは、2025-11-25で試験的にコアへ入ったが、今回io.modelcontextprotocol/tasks拡張へ移る。旧APIとはワイヤ互換ではなく、tasks/resultとtasks/listは削除される。新しい流れではサーバーがタスク化を決め、クライアントがtasks/get、tasks/update、tasks/cancelで追跡する。セッションがない状態で呼び出し元ごとの一覧を安全に区切れないため、tasks/listは残らなかった。
Roots、Sampling、LoggingはDeprecatedへ移る。Rootsは作業対象のディレクトリをサーバーへ知らせ、Samplingはサーバーからクライアント側のモデルへ生成を依頼し、Loggingはプロトコル内で構造化ログを送る機能だった。代替先は、ツール引数やリソースURI、LLM事業者のAPI、stderrまたはOpenTelemetryである。
Deprecatedは削除済みという意味ではない。三機能は少なくとも12カ月の移行期間中も仕様に残り、削除には別のSpecification Enhancement Proposal（SEP）が必要だ。新しい実装は採用せず、既存実装は移行を始めるという合図である。Active、Deprecated、Removedという状態と最低期間を定めたことで、今後のコア機能は今回のような一斉改修を待たずに退役手続きを進められる。
7月28日は停止日ではない
新仕様には互換性を壊す変更があるが、7月28日に既存サーバーが停止するわけではない。この日は規範となる仕様本文の公開予定日であり、利用者が旧プロトコルを強制的に切り替えられる日ではない。新しいクライアントはserver/discoverを試し、旧サーバーならinitializeへ戻る実装を選べる。
6月29日には、Python、TypeScript、Go、C#という4つのTier 1 SDKでベータ対応が始まった。ただし移行方法は揃っていない。Python v2は一つのエンドポイントで新旧両方へ応答し、TypeScript v2とGoは新プロトコルを明示的に有効にする。C#のプレビュー版はHTTPをステートレスモードで始める。TypeScriptではSDKのv2移行と、2026-07-28をワイヤ上で話す変更も別工程だ。
仕様の変更点はセッション周辺に集中しているものの、移行試験では周辺の差も効く。ツールの入出力スキーマはJSON Schema 2020-12へ広がり、リソースが見つからない場合のエラーコードは-32002から-32602へ変わる。認可では、応答に含まれるissと記録済み発行者の一致を検証し、OpenID Connectのapplication_typeを登録時に明示する。保存したクライアント資格情報は発行者へ結び付け、別の認可サーバーへ使い回せない。
独自実装のクライアントやサーバーほど、SDKを更新する作業では済まない。実トラフィックで新旧の版交渉を試し、暗黙のセッション状態をハンドルへ移し、呼び出しごとの認可を確認する必要がある。Tasksとサーバー・クライアント間の往復処理も、旧版のメソッド名が通るかではなく、新しい状態遷移で検証すべきだ。7月28日に公開予定の最終仕様で確認したいのは、リリース候補から変わった点とTier 1 SDKの安定版対応である。そこが、MCPを通常のHTTP基盤へ載せ替える時期を決める。