MCPサーバーがツール実行中に「本当に削除しますか」とユーザーへ確認を求める——この一時停止処理が2026-07-28仕様で作り直された。Sampling・Roots・Elicitationという従来のクライアント呼び出し方式は非推奨となり、Multi Round-Trip Requests（MRTR）という新パターンに統一された。問題は、この新パターンの中核にあるrequestStateフィールドを、実装者が単なる継続トークン程度に軽く扱ってしまう点にある。
なぜMCPはSampling/Roots/Elicitationの呼び出し方式を変えたのか
MCPはサーバーからクライアントへの割り込みリクエストを廃止し、2026-07-28仕様でMRTR（SEP-2322）に統一した。ステートレスな水平スケールを実現するためだ。
2026-07-28仕様はセッション概念（Mcp-Session-Id）とinitializeハンドシェイクを撤廃し、MCPをステートレスなリクエスト/レスポンス型プロトコルへ転換した。しかし旧来のSampling・Roots・Elicitationは、いずれもサーバーが接続を保持したままクライアントへ割り込みリクエストを送る「サーバー起動」方式だった。接続を保持できないステートレスサーバーではこの方式が成立しない。公式チェンジログはSampling・Roots・Loggingの3機能を非推奨に指定し、新規実装はMRTRパターンへの統一を求めている。従来のElicitation実装はelicitation/createを直接送る前提で解説したが、現行仕様ではこの直接呼び出しがMRTRの枠組みに置き換わっている。
MRTRの基本フローはどう動くか
MRTRはクライアントの
tools/call等に対しサーバーがresultType: "input_required"を返し、クライアントがinputResponses付きで再送する2往復設計です。
フローは4段階。(1) クライアントが通常のリクエストを送る。(2) サーバーが追加情報を要すると判断し、InputRequiredResultでinputRequests（Elicitation・Sampling・Rootsのいずれか）とrequestStateを返す。(3) クライアントはユーザーや他の手段から回答を集め、inputResponsesとrequestStateを添えて同じリクエストを新しいJSON-RPC idで再送する。(4) サーバーはrequestStateから文脈を復元し、処理を完了する。対応するのはtools/call・resources/read・prompts/getの3リクエストのみで、他のリクエストへのInputRequiredResultは仕様違反となる。Tasks拡張のinput_required状態と似るが、MRTRは単発リクエスト内の往復であり、長時間タスクのポーリングとは別チャンネルである点に注意したい。
requestStateはなぜ「攻撃者制御入力」として扱うべきなのか
requestStateはクライアントが不透明として扱うべき値だが、サーバー視点では悪意あるクライアントが改変しうる攻撃者制御入力として扱う必要がある。
仕様はクライアント側に「requestStateの内容を検査・解釈・変更してはならない」と課す一方、サーバー側には逆の要求を課す。クライアントを経由して往復する値である以上、悪意あるクライアントや侵害されたクライアントが値を書き換えて再送してくる可能性を排除できない。この非対称性——クライアントには不透明、サーバーには攻撃者制御——を理解していないと、requestStateに認可判断やリソースアクセスの前提条件をそのまま平文で埋め込む実装に陥る。これはスコープ付き認証情報設計で避けるべきとされる「暗黙の信頼境界」と同じ失敗パターンだ。
requestStateの改ざん防御はどう実装するか
requestStateが認可・リソースアクセス・業務ロジックに影響する場合、サーバーはHMACやAEADで整合性保護し、検証失敗時は必ず拒否しなければならない。
仕様の要求は明確だ。requestStateが認可判断・リソースアクセス・業務ロジックに影響を与える場合、サーバーはHMACまたはAEADで整合性保護を実装し、検証に失敗した状態は拒否しなければならない。整合性保護を省略できるのは、改ざんの結果がリクエスト失敗以上の実害を生まない場合に限られる。実装としては、サーバー内部のJSONを平文でBase64エンコードするのではなく、暗号化JWTやAEAD保護済みバイナリとしてrequestStateを発行し、復号・検証の失敗を即座にエラー終端させる設計が要る。
リプレイ防御は何を組み込むべきか
改ざん防御だけでは不十分で、整合性保護されたペイロード内に認証プリンシパル・短いTTL・元リクエストの識別子を含め検証すべきだ。
仕様はリプレイ対策として3要素を推奨する。認証済みプリンシパル（異なるユーザーが提示した状態を拒否）、短いTTL（期限切れ状態を拒否）、元リクエストの識別子（メソッド名とパラメータのダイジェストなど。異なるリクエストに対する状態を拒否）の3点だ。ただしこれらはリプレイの時間窓とクロスユーザー再利用を防ぐに留まり、単発利用の保証にはならない。一度しか使えないべきrequestState（ワンタイム処理等)はサーバー側で別途その制約を強制する必要がある。
参考
- Multi Round-Trip Requests - Model Context Protocol
- Key Changes - Model Context Protocol
- The 2026-07-28 Specification
まとめ
MRTRはMCPのステートレス化に不可欠な設計変更だが、requestStateを単なる継続トークンとして軽視すると、認可バイパスや業務ロジック改ざんの入口になる。サードパーティMCPサーバーを組み込む際は、requestStateの整合性保護方式（HMAC/AEAD）とリプレイ対策の3要素が実装されているかをベンダー評価の必須項目に加えるべきだ。複数チームでMCPサーバーを運用する体制整備については、Kuu株式会社のRDEが設計レビューから支援する。