Summary

  • AACP草案では、確認サービスがconfirm=trueとされた項目を言語モデルの推論を介さずに表示し、利用者の承認または拒否を受け取って署名する。
  • 実行側は署名だけでなく、実際に行う操作の要約値、宛先、使い捨てのチャレンジ、有効期限を検査する。明確な拒否と連絡不能は別の結果になる。

AIエージェントが「了承済みです」と報告したとする。肝心なのは流暢な報告ではなく、利用者がどの金額、どの相手、どの削除対象を見て決めたかだ。2日に公開されたAgent Action Confirmation Protocol草案は、その証拠を代理の発話から切り離す。行動する代理が操作内容を構造化して送る。確認サービスは人に必要な項目を表示し、承認と拒否の操作を用意し、受け取った判断に署名する。確認サービスは利用者のアプリ内でも、企業の認可基盤内でもよい。大事なのは確認の画面と決定が言語モデルの推論経路から独立していることだ。

草案は表示の細部を権限の問題として扱う。人が確認すべき値にはconfirm=trueを付け、画面で読める名前を添える。確認サービスはその全項目を示してから判断ボタンを出す。項目名や値に紛れたリンク、命令、装飾は実行せず、ただのデータとして表示する。代理が気の利いた要約を作っても、支払額や送金先を見えなくする権限までは与えられない。

署名済みの確認証拠を受け取る側は、これから実行するAPI要求を基に操作の要約値を計算し直す。確認サービスの鍵を自らの信頼方針で検証し、証拠がどの代理に向けられたか、チャレンジが新しいか、期限内か、同じ要求が使い回されていないかも調べる。別の代理向けに得た確認証拠は転用できない。取り消しが難しい操作では、利用者に実際に表示された項目の要約値も照合するよう草案は勧める。ボタンを押した事実と、必要な条件を見て押した事実の差を、機械が点検できる形にする。

拒否の扱いにも設計思想が出る。deniedは署名付きの拒否で、再試行を始められるのは利用者本人だけだ。unobtainableは回答を集められなかった状態で、署名付きの判断ではない。期限切れ、再利用、操作との不一致、宛先違い、検証不能な鍵にも個別の結果がある。失敗した証拠を一部だけ受け入れて処理を進める道は閉じられている。決済や台帳更新では、この分類が自動再試行の可否を決める。

IETFの記録では、11月2日版は個人提出の草案だ。次に必要なのは、表示後に操作の値を変える、必須項目を画面から外す、古い証拠を再送するといった試験で、別々の実装が同じように拒否するという記録である。そこまで示されれば、「承認済み」という代理の言葉を、実行時に検証できる行為へ変えられる。