『いいですね、では予約します』の誤解を防ぐ──LLMを経由しない人間確認プロトコルCHEQを読む

当サイトでは以前、Claude Codeのautoモードで「人間の承認は危険コマンドの13.6%しか止めていない」という調査を扱った。IETFに提出された個人ドラフト「CHEQ」は、この「人間の確認」という工程そのものを、LLMを経由しない別経路のプロトコルとして標準化しようとする提案だ。著者はJonathan Rosenberg氏(Five9)、Pat White氏(Bitwave)、Cullen Jennings氏(Cisco)の3名で、2025年10月19日提出、2026年4月22日に失効している。

3行まとめ

1. CHEQは「Confirmation with Human in the Loop (HITL) Exchange of Quotations」の略。AIエージェントが提案した行動を、LLMを経由しない専用の「Confirmation Server(確認サーバー)」を通じて人間に確認させ、署名付きオブジェクトとして記録する
2. 設計要件として「LLM自体に依存してはならない(LLMの精度に左右されない)」「暗号学的な非否認性(あとから確認していないと言い張れない)」「LLMに口座番号などの機微情報を渡さずに済むプライバシー保護」が明記されている
3. MCP・A2A・N-ACTといった既存のツール呼び出しプロトコルに、URLのやり取りとして比較的簡単に組み込める設計だが、ドラフト自体は2026年4月に失効し、本記事の確認時点(8月27日)で後継は出ていない

出発点になった2つの具体例

ドラフトの冒頭は、CHEQが解決しようとする問題を2つの具体例で説明している。1つ目は、旅行予約エージェントとの長い会話が、最後の一言で誤解されるケースだ。

The user is discussing with the AI Agent whether to take business or coach. There is a long back and forth conversation about this. Finally the user says, "go ahead and book it". The AI Agent misinterprets the conversation, and chooses business class, despite the user's desire for coach.

(ユーザーはAIエージェントと、ビジネスクラスにするかエコノミークラスにするかを話し合っている。長いやり取りが続いた末、ユーザーは「じゃあ予約して」と言う。AIエージェントはこの会話を誤解し、ユーザーがエコノミークラスを望んでいたにもかかわらずビジネスクラスを選んでしまう)

2つ目は、より深刻な例として、銀行送金でのハルシネーションを挙げている。

A more troubling use case is when a user interacts with a banking AI Agent, and requests transfer of funds. [...] The LLM hallucinates the account number, and results in funds being deposited into the wrong account. This use case is doubly troublesome - not only has the user lost money, but they have leaked sensitive information (their account number) to an LLM.

(さらに厄介な例は、ユーザーが銀行のAIエージェントとやり取りし、送金を依頼する場合だ。[中略]LLMが口座番号をハルシネーションし、間違った口座に資金が振り込まれてしまう。この事例が二重に厄介なのは、ユーザーがお金を失っただけでなく、機微な情報(自分の口座番号)をLLMに漏らしてしまったことにもある)

この2つ目の例は、単に「人間の確認を挟めばよい」という話にとどまらず、「そもそも口座番号のような機微情報をLLMに渡さないで済む設計にできないか」という、もう一段踏み込んだ問題意識を示している。

LLMを迂回する、という設計要件

CHEQが掲げる要件のうち、最も特徴的なのは次の一文だ。

The protocol must not depend on the LLM itself, so that it is not subject to LLM accuracy for proper operation

(プロトコルはLLM自体に依存してはならない。正しく動作するためにLLMの精度に左右されてはならない)

つまり、「LLMに『本当にこれでいいですか』と聞かせて確認を取る」という設計では、確認そのものがLLMのハルシネーションで歪みうるため不十分だという立場だ。他にも次のような要件が並ぶ。

The protocol must provide cryptographic assurances that the human being approves the action [...] The protocol must protect against AI agents replaying past confirmations [...] The protocol must enable resource servers to collect information from users needed to complete a tool call, without disclosing that information to an LLM (privacy)

(プロトコルは、人間がその行動を承認したことについて暗号学的な保証を提供しなければならない。[中略]プロトコルは、AIエージェントが過去の確認を再利用(リプレイ)することを防がなければならない。[中略]プロトコルは、ツール呼び出しの完了に必要な情報をリソースサーバーがユーザーから収集できるようにしなければならない。その際、その情報をLLMに開示することなく)

「過去の確認のリプレイを防ぐ」という要件は、一度承認された操作の署名を使い回して、別の(未承認の)操作を通してしまうような攻撃を想定したものと読める。

4者構成のアーキテクチャと、確認だけを担う第三者サーバー

CHEQのアーキテクチャは、ユーザー・AIエージェント(LLMと実行エンジンに分離)・確認サーバー・リソースサーバー(APIを提供する側)という4つの要素で構成される。ドラフトが示す図の骨子は次の通りだ。

CHEQ introduces a new server, the Confirmation Server. The Confirmation Server is responsible for rendering the information to be confirmed to the user, collecting their confirmation, and memorializing it by signing an object (the CHEQ object, which can then be passed back to the resource server.

(CHEQは新しいサーバー、確認サーバーを導入する。確認サーバーは、確認すべき情報をユーザーに提示し、その確認を収集し、オブジェクト(CHEQオブジェクト)に署名することでそれを記録する役割を担う。このオブジェクトはリソースサーバーへ返送できる)

興味深いのは、この確認サーバーがAPIを提供する事業者自身である必要はなく、ユーザーが信頼する第三者であってもよいと想定している点だ。

We anticipate that users may desire to have this function centralized across many different API services, so that users have a single point of accountability and audit of decisions that have been confirmed. As an example, a trusted third party - something like Lets Encrypt - might run such a service

(ユーザーは、この機能が複数の異なるAPIサービスをまたいで一元化されることを望むかもしれない。そうすれば、確認された決定について単一の説明責任・監査の窓口を持てるようになる。例えば、Let's Encryptのような信頼された第三者が、こうしたサービスを運営することもありうる)

証明書発行の非営利機関Let's Encryptを引き合いに出しているのは、「特定の1社に閉じない、業界横断のインフラとして確認サービスが成立しうる」という将来像の比喩だと読める。ただしドラフト自身も「これは物議を醸しうる要件だ(This is a potentially controversial requirement)」と注記しており、著者自身がこの設計の野心を自覚していることがうかがえる。

実際の流れ:予約から確認までのシーケンス

ドラフトが示すシーケンス図を要約すると、次のような流れになる。

1. ユーザーがAIエージェントに「フライトを予約して」と伝える
2. LLMがツール呼び出し(航空会社APIへの予約リクエスト)を生成し、実行エンジンがAPIへPOSTする
3. APIサーバーは即座に予約を確定させず、202 Acceptedとともに「確認用URI」を返す
4. 実行エンジンはこのURIをユーザーのブラウザへ渡す
5. ユーザーは確認サーバーにログインし、内容を確認して「確認」ボタンを押す
6. 確認サーバーが署名済みのCHEQオブジェクトをAPIサーバーへ送り、予約が確定する
7. 実行エンジンは結果URIをポーリングし、確定結果をLLMのコンテキストへ渡し、「予約が完了しました」とユーザーに伝える

このシーケンス図が示す設計上の要点は、AIエージェント(LLM側)はステップ3で「202 Accepted」を受け取った時点で処理を止め、確認が終わるまでの間、実際の予約確定操作からは締め出されるという点だ。ドラフトはこの分岐について次のように説明している。

The resource server - the airline here - would be configured with policies that specify which API requests, when invoked by an AI Agent, require human confirmation. [...] For example, the airline website might serve a UI which has radio buttons indicating that flight booking for flights over $100 require confirmation.

(リソースサーバー——この例では航空会社——は、AIエージェントによって呼び出された際にどのAPIリクエストが人間の確認を必要とするかを指定するポリシーを設定できる。[中略]例えば、航空会社のWebサイトが「100ドルを超えるフライト予約には確認が必要」というラジオボタンのUIを提供することもありうる)

「金額がいくらを超えたら人間の確認を必須にするか」を決めるのはAIエージェント側ではなく、APIを提供するリソースサーバー側(あるいはその設定を行うユーザー自身)だという設計だ。

3つの既存プロトコルへの組み込み方

ドラフト第6章「Usage with MCP and A2A and N-ACT」は、CHEQを既存のツール呼び出しプロトコルへどう組み込むかを短く説明している。

第7章「Usage with Voice Interfaces」では、音声インターフェース経由の場合の流れにも触れている。ユーザーアプリケーション（音声ゲートウェイ）がURI packを受け取った際、Webブラウザへ渡す代わりに確認サーバーへ接続して「生の」CHEQを取得し、音声で読み上げてユーザーの承認を音声で得る、という設計だ。ただしこの場合、確認サーバー側がHTMLではなく音声向けのレンダリングに対応したフローを持つ必要がある、という条件付きだと明記されている。

同じ著者らの関連ドラフト群も軒並み失効・アーカイブ済みだった

CHEQが依拠する「N-ACT（Native Agent Calling Tools）」というドラフトをIETF Datatrackerで確認したところ、これも「Expired Internet-Draft (individual)」「Expired & archived」だった。さらに調べると、N-ACT自体が「draft-rosenberg-aiproto」という、より古い名義の後継であり、N-ACTはその後「draft-rosenberg-aiproto-a2t」という別の後継ドラフトに置き換えられていた。このa2tドラフトも、Datatracker確認時点で同じく失効・アーカイブ済み(最新版2025年11月6日、失効表示2026年5月10日)だった。

整理すると、CHEQも含め、Jonathan Rosenberg氏・Pat White氏らによるAIエージェント関連の個人ドラフト群は、名前を変えながら提出が続けられてきた形跡があるものの、この記事で確認できた範囲ではいずれも失効・アーカイブされており、IETFの正式なワーキンググループの成果物にはなっていない。CHEQ本文が「LLMを迂回する確認プロトコル」という一つの明確なアイデアを提示していたこと自体は変わらないが、その提案が置かれているエコシステム全体の実装・標準化の進み具合は、この記事の確認時点ではまだ個人ドラフトの域を出ていない。

未完成のまま失効している部分

ドラフトの目次には「8.1. URI Pack Syntax and Semantics」「8.2. CHEQ Object Syntax and Semantics」「8.3. CHEQ Protocol Details」という、まさにプロトコルの核心にあたる具体的な仕様のセクションが並んでいる。だが本文を実際に確認すると、この3節はいずれも次の一文だけで終わっていた。

Details to be filled in.

（詳細は今後記入）

3節すべてが一字一句この同じ文で終わっている。要件と全体アーキテクチャ、そして運用シーケンスまでは書き込まれているが、「実際にこれを実装できるだけの詳細な仕様書」としてはまだ手前の段階で止まっている、という印象は推測ではなく本文そのものの記述として確認できた。このドラフト自体、2026年4月22日に失効しており、詳細仕様の章が埋まらないまま更新が止まっている。

実装や採用の実例は確認していない

本記事は、IETFのドラフト本体(draft-rosenberg-aiproto-cheq-00.txt)を2026年8月27日にcurlで取得した全文にもとづく。Section 8(詳細プロトコル仕様)の記述が実際にどこまで書き込まれているかは、目次の見出しと、確認できた本文の範囲から判断したものであり、ページ全体を一字一句読み込んだわけではない。MCPの「elicitation(情報収集)」モデルとの統合について「specifically designed to fit(適合するよう specifically 設計されている)」という記載があるが、実際にAnthropicのMCP仕様側がこの統合を採用しているかどうかは確認していない。実装したライブラリやSDKの存在も、今回の調査範囲では見つけられなかった。

普段からAIエージェントに実際の送金や予約といった不可逆な操作を任せた経験はなく、「人間の確認をどこに挟むべきか」という設計判断について、実務者としての土地勘は持ち合わせていない。Claude Codeのautoモードで「危険コマンドの承認が13.6%しか機能していない」という当サイトの過去記事を踏まえると、CHEQが目指す「LLMを経由しない確認経路」という発想自体は、素朴に筋が通っているように読めた。

感想・指摘はコメント欄へ。