AIエージェントのツールが、処理の途中で「ユーザー名を確認したい」「モデルに追加判断を頼みたい」となったら、どう対話を続けるべきでしょうか。
Model Context Protocol（MCP）の2026年7月28日版は、サーバーから新しい要求を送り返す従来方式を廃止し、Multi Round-Trip Requests（MRTR）を導入しました。変更の本質は、会話を接続に覚えさせず、必要な情報を持って元の要求をやり直すことです。
従来の「サーバー発の要求」は使えなくなりました
新仕様では、すべてのやり取りをクライアントが開始します。サーバーはJSON-RPCの要求を開始してはならず、roots/list、sampling/createMessage、elicitation/createもMRTRで扱います。公式仕様は、これを互換性に影響する変更と位置づけています。
MRTRの流れは4段階です。
- クライアントが最初の要求を送ります。
- 情報が足りなければ、サーバーは
resultType: "input_required"の結果を返します。 - クライアントはユーザー入力などを集め、
inputResponsesを付けて元の要求を再送します。 - 情報がそろえば、サーバーは
resultType: "complete"の最終結果を返します。
最初の要求と再送は別の要求なので、JSON-RPCのIDも別にする必要があります。一本の接続を往復し続けるというより、必要事項を書いた伝票を差し戻し、記入後に新しい受付番号で出し直す設計です。
requestStateは「開けない引継ぎ封筒」です
サーバーはInputRequiredResultに、追加要求を示すinputRequestsと、処理の引継ぎに使うrequestStateを含められます。クライアントはrequestStateを解析・変更せず、再送時に同じ値を返さなければなりません。
これにより、再送を別のサーバーインスタンスが受けても、要求内の情報だけで処理を再構成できます。スティッキーセッションや共有セッションストアを前提にしない水平分散と相性がよい仕組みです。
ただし、クライアントを経由して戻る値は信用できません。公式仕様は、認可や業務ロジックに影響する場合、サーバーにHMACやAEADなどによる改ざん検知を求めています。リプレイ対策として、少なくとも次を保護対象へ入れる設計が有効です。
- 認証済み利用者の識別子
- 短い有効期限
- 元のメソッド名と重要パラメータのダイジェスト
一回だけ使えることを保証したい処理は、署名だけでは足りません。クーポン利用や送金確定のような処理では、使用済みかどうかをサーバー側で管理する必要があります。
移行時に外せない4つの確認
1. 「未完了」をエラー扱いしない
input_requiredは失敗ではなく、追加情報を待つ正常な中間結果です。クライアントはresultTypeで分岐し、古い仕様のサーバーがこの項目を返さない場合はcompleteとして扱います。
2. 対応する入口を限定する
InputRequiredResultを返せるのは、prompts/get、resources/read、tools/callです。ほかの要求へ独自に広げると相互運用性を壊します。
3. 再送されない前提も持つ
ユーザーは入力を拒否でき、クライアントが元の要求を再送する保証もありません。最初の要求を受けた時点で、外部システムへ取り消せない副作用を起こさない設計が安全です。
4. 再送を重複実行と区別する
再送時のIDは変わります。課金、通知、データ更新を伴うツールでは、業務上の冪等キーを別に持ち、同じ操作を二重実行しないようにします。
考察：対話の状態は「接続」ではなく「検証可能な要求」に置く
MRTRは通信形式の変更に見えますが、設計思想はフェイルオーバーに近いものです。接続が続くことや、同じプロセスが次も担当することを前提にせず、別の担当でも検証して再開できる情報を要求へ持たせます。
一方、何でもrequestStateへ詰めればよいわけではありません。個人情報を増やせば漏えい時の影響が広がり、長い有効期限は再利用の危険を高めます。状態は最小限にし、完全性、期限、利用者、元の要求との結び付きを検証することが重要です。
まとめ
- MCP 2026-07-28では、サーバー発の要求をMRTRが置き換えました。
- 追加情報が必要なら
input_requiredを返し、クライアントが元の要求を再送します。 requestStateは不透明なまま返送し、サーバー側で改ざんと再利用を防ぎます。- 未完了、拒否、再送、重複実行を別々の状態として設計します。
良い対話型エージェントは、一本の接続にしがみつきません。途中で止まっても、必要な情報を安全に引き継ぎ、別の実行環境で再開できることが運用品質になります。