MCP 2026-07-28移行、消えるセッションと壊れやすい再試行

MCP 2026-07-28への移行では、initializeハンドシェイクとMcp-Session-Idを廃止し、どのサーバーインスタンスでも処理できる自己完結型の要求へ切り替える。ただし、ヘッダーを削るだけでは足りない。接続やセッションに隠れていた文脈を要求、ツール引数、永続ストアへ移さなければならない。

同時に、切断後の再送で課金、送信、作成といった副作用が重複しないよう、書き込み系ツールを冪等化する。実装は、通信形式の分離、状態の棚卸し、再試行対策、MRTR、認可、旧版との段階移行の順に進めると、破壊的変更の影響を切り分けやすい。

1. 新旧のHTTP交換を分離する

旧版では、クライアントがinitializeを送り、サーバーから受け取ったMcp-Session-Idを後続要求へ付けていた。MCPの2026-07-28仕様解説 では、この交換とセッションヘッダーが廃止され、各要求がプロトコル版、クライアント識別情報、能力を伴う自己記述型へ変更されたことが示されている。クライアントは最初からtools/callなどを送信でき、事前確認が必要な場合だけ任意のserver/discoverを呼ぶ。

Streamable HTTPでは、MCP-Protocol-Versionに2026-07-28を指定し、Mcp-Methodと、対象がある場合はMcp-Nameを送る。JSON-RPC本文のmethod、paramsとヘッダーの内容が食い違う要求は拒否し、ゲートウェイでも同じ値を使って経路選択や制限を行う。

最初の合格条件は、連続する要求を別々のインスタンスへ送っても処理できることである。メモリー上のセッションに利用者、権限、選択中のリソース、作業途中の値が残っているなら、通信形式だけが新しく、処理はまだ旧構造のままだ。

2. セッション状態の置き場所を決め直す

プロトコルのステートレス化は、業務データまで無状態にするという意味ではない。買い物かご、ブラウザー操作、下書き、長時間ジョブなど、呼び出しをまたぐ状態には明示的な識別子を発行し、後続のツール引数として受け取って永続ストアから復元する。

その識別子は認可トークンではない。要求ごとに認証主体、テナント、対象データの所有関係、有効期限、失効状態を確認する。モデルのコンテキストを経由する値は改変や取り違えが起こり得る入力として扱い、識別子を知っているだけでアクセスを許可しない。

移行前に、Mcp-Session-Idをキーにした保存領域、スティッキーセッション、接続単位のキャッシュ、インスタンス内の変数を列挙する。それぞれを、要求内で再構成する情報、所有者確認付きで永続ストアから読む業務状態、MRTRの継続状態、廃止できる通信管理情報に分類する。旧セッションを新しい名前の共有キャッシュへ移すだけでは、任意のインスタンスが独立して要求を処理できる設計にはならない。

3. 再試行で副作用を増やさない

2026-07-28ではストリーム再開がなくなり、応答が途中で失われた場合はクライアントが呼び出しを再送する。サーバー側の処理だけが完了して応答が届かなかった場合、単純な再実行は二重作成や二重送信につながる。AWSのステートレスMCP設計解説 も、壊れた呼び出しを再送できるようツールを冪等化し、旧版の通信が残る間はセッション基盤を維持するよう求めている。

副作用のあるツールには、再送しても変わらない操作IDを持たせる。サーバーは操作ID、認証主体、ツール名、正規化した入力、処理結果を対応付け、同じ組み合わせの再送には保存済み結果を返す。同じ操作IDで入力が異なる場合は、新規処理として受け入れず競合として拒否する設計が妥当だ。

業務更新の後に重複防止レコードを書く二段階処理には、障害の隙間が残る。可能なら両方を同じトランザクションへ入れ、外部決済などには提供側の冪等キーを渡す。メール送信のように単一トランザクションへ収められない処理では、outboxに実行予定を永続化し、配送側でも同じキーによる重複抑止を行う。

試験では、処理完了直後の切断、処理中のインスタンス停止、同一操作IDの並行送信を注入する。確認すべき結果はHTTP応答の成功だけではなく、永続データと外部副作用が一度だけ発生し、再送側が同じ結果を受け取れることである。

4. サーバー起点の要求をMRTRへ移す

従来のelicitation、sampling、roots取得は、開いたストリームを通じてサーバーからクライアントへ要求を送れた。Multi Round-Trip Requests（MRTR）では、サーバーがresultTypeをinput_requiredとして終了し、必要な依頼をinputRequestsに格納する。クライアントは回答をinputResponsesへ入れ、requestStateとともに元の処理を新しい要求として再送する。

requestStateはMRTRの継続用であり、一般的な業務セッションの代用品ではない。初回、回答待ち、追加確認、完了という段階を明示し、再開に必要な最小限の状態だけを持たせる。クライアントを往復する未信頼入力なので、サーバー側のランダムな参照キーにするか、認証主体、元のメソッドと引数、有効期限に結び付けて完全性を保護する。

MRTRの再入場でも同じ要求が重複し得る。確認回答の直後に副作用を実行する場合は、requestStateそのものを冪等キーにせず、独立した操作IDと完了記録を使う。また、複数ラウンドではinputResponsesが毎回置き換わるため、それ以前に得た情報は検証済みのrequestStateまたはサーバー側の状態へ引き継ぐ。

5. 認可強化を明示的に有効化する

認可では、認可応答のissを検証してからコードを交換し、クライアント資格情報を発行者ごとに分離する。Dynamic Client Registration（DCR）は後方互換のため動作するが、Client ID Metadata Documents（CIMD）への移行対象である。デスクトップやCLIではapplication_typeとredirect URIの組み合わせも確認する。

SDKを更新しただけで新しい通信と認可要件が有効になるとは限らない。公式TypeScript SDKの移行手順 では、2026-07-28の送受信は明示的なオプトインであり、認可強化もプロトコル版とは別のSDK設定として有効化すると説明されている。issの受け渡し、保存資格情報へのissuerの保持、認可サーバー探索状態、insufficient_scope時の再認可またはエラー処理を個別に実装する。

試験には、異なる発行者の認可コード、別テナントの状態識別子、期限切れのrequestState、不足スコープを含める。正常なログインだけでなく、取り違えた資格情報が拒否され、必要な場合に限って再認可へ進むことを確かめる。

6. 旧版を計測しながら段階的に閉じる

既存環境では、旧版と2026-07-28を別経路として扱う。ゲートウェイでプロトコル版を記録し、旧版はinitializeとセッションを使う処理へ、新版は自己完結型の処理へ振り分ける。エラー率、再試行数、重複抑止件数、MRTR完了率を版別に観測すれば、障害が通信形式、業務状態、再送処理のどこにあるかを切り分けられる。

少量の新仕様トラフィックから始め、異なるインスタンスへの分散、停止、タイムアウト、並行再送を確認して対象クライアントを増やす。ロールバックもアプリケーション全体ではなく、プロトコル版の経路単位で行えるようにする。旧版トラフィックがゼロになり、復帰予定もないと確認してから、スティッキー設定、セッションストア、initialize専用処理を撤去する。

リリース前の確認項目は次の通りだ。

• 2026-07-28の各要求を任意のインスタンスで処理できる
• プロトコル版、メソッド、対象名、必要なクライアント文脈を要求ごとに検証する
• 業務状態の識別子について認証主体と所有関係を毎回確認する
• 副作用のあるツールが同一操作IDの再送と並行実行に耐える
• サーバー起点の要求をMRTRへ移し、requestStateを未信頼入力として検証する
• iss、発行者別の資格情報、不足スコープ、再認可を試験する
• 旧版トラフィックが残る限り、必要なセッション経路を維持する

移行完了の基準は、Mcp-Session-Idが通信から消えたことではない。インスタンスが交代しても要求を再構成でき、応答消失後に再送しても副作用を増やさず、認可境界を越えずに処理を再開できることが完了条件となる。