Human Checkを「承認ボタン」ではなくApproval Bindingへ 人が確認した操作と、実際に実行される操作を同じものにする

🎥 YouTubeでも公開しています

Approval Binding：AI Agentの承認を「責任ある実行許可」に変える設計原則

Books: Runtime AI Governance 実践ガイド: Knowledge Flow・Trust Engine・Decision Traceによる動的AIガバナンス設計

AI Agentに送金、デプロイ、権限変更、外部メッセージ送信、顧客通知のような重要操作を任せるとき、多くのシステムは最後に「承認」ボタンを置く。

AIが提案し、人が画面で内容を確認して、Approveを押す。これで人間が関与したため、安全になったように見える。

しかし本当に問うべきなのは、承認したかどうかではない。

人が画面で確認した操作と、システムが実行しようとしている操作は、本当に同じものか。

2026年9月に公表された Loopjacking: Hijacking Human-in-the-Loop Approval は、この問題を明確にしている。人間が理解して承認した操作を A、承認後に実際に実行される別の操作を B とする。製品の処理が、Aへの承認をBの実行に使える構造になっていれば、そこには承認のすり替えが起きる。

画面に承認ボタンが存在することは、安全境界を意味しない。安全境界になるのは、承認が対象・条件・実行内容・ポリシー版に結び付けられ、実行直前に再び照合されるときである。

ここでは、この設計を Approval Binding と呼ぶ。

approved = true では何も結び付いていない

もっとも単純な承認実装は、レコードに approved = true という状態を置く方法である。しかしこのフラグだけでは、何に対する承認なのかが残らない。

承認後に、次のような要素が変わり得る。

• 送信先、宛先URL、対象アカウント
• 金額、数量、権限の範囲
• 実行するTool、API、コマンド、引数
• 参照した顧客情報、文書、在庫、状態
• 実行時点で適用されるポリシーや委任権限
• 承認を要求したAgent、依頼者、セッション

たとえば「顧客Aに、承認済みの案内を送る」という操作を人が確認したあと、実行直前の処理で宛先が顧客Bに変わったとする。あるいは、権限変更の対象グループやロールが展開時に追加されたとする。承認済みフラグだけを見て実行すれば、人間が承認していない操作が実行される。

これは攻撃者がいる場合だけの問題ではない。非同期ワークフロー、再試行キュー、外部APIの状態変化、Agent間の引き継ぎ、テンプレートの差し替え、設定の更新でも起こる。人が確認した時点の世界と、実行時点の世界が同じとは限らないからである。

Approval Bindingとは何か

Approval Bindingは、人が理解して承認した操作の記述を固定し、実行時に再構成した現在の操作と比較して、両者が実質的に同一である場合だけ実行を許す仕組みである。

承認は、単なる操作状態ではなく、次のような**承認記述子（approved descriptor）**に対して発行する。

この記述子を正規化した上でハッシュ化し、承認者、承認時刻、Decision Trace IDと結び付ける。重要なのはハッシュそのものではない。ハッシュで固定すべき対象を、業務上の「実質的に重要な差分」が逃げない形で定義することである。

ハッシュは「人が見たもの」を固定するために使う

Approval Bindingでは、次の二つを分けて扱う必要がある。

1. 機械が実行する正規化済み操作
2. 人が画面で理解した操作の説明

前者だけをハッシュ化しても、人間に重要な情報が省略されていれば意味がない。逆に、画面表示だけを保存しても、内部のAPI引数や実行対象が結び付いていなければ不十分である。

そこで、承認時には以下を同じTraceに記録する。

• 実行予定の正規化済み操作とそのハッシュ
• 人に表示した承認画面の内容とそのハッシュ
• その操作を導いた根拠、入力、ポリシー評価
• 承認者・権限・承認時刻・有効期限
• 一度だけ使うためのnonce、またはPermit ID

これにより、後から「何を表示し、何を承認し、何を実行したか」を一続きで説明できる。

実行の直前に、もう一度同じ操作を再構成する

Approval Bindingの核心は、承認時ではなく実行直前にある。

実行ワーカーやAgentは、古い承認フラグを信頼してそのまま外部APIを呼んではならない。まず、現在の入力、対象状態、ポリシー、委任権限から実行予定の操作を再構成する。そして承認記述子と比較する。

Evidence / Input
      ↓
Normalized Operation
      ↓
Human-visible Descriptor
      ↓
Human Decision + Approval Binding
      ↓
Pre-execution Reconstruction
      ↓
Equivalence Check
      ↓
Permit → Execution → Outcome Trace

再照合では、少なくとも次を確認する。

• Action / Toolが同じか
• 重要な引数、金額、対象、宛先が同じか
• 実行主体と委任範囲が同じか
• セッション、案件、対象範囲が承認時の範囲内か
• ポリシー版と評価結果がなお有効か
• 承認が期限内で、未使用か
• 人に表示した説明と機械操作の対応が維持されているか

一つでも実質的な差異があれば、実行を拒否するか、再承認を要求する。差異を自動的に「小さな変更」とみなして進めないことが重要である。判断が変わり得る変更なら、新しい判断が必要である。

Modifyは承認の更新ではなく、新しいDecisionにする

承認者が「金額を下げる」「宛先を変更する」「条件を一つ追加する」と修正した場合、元のDecisionを単に上書きしてはいけない。

修正は、新しいDecisionを作る操作である。新しい入力、対象、条件からポリシーとBoundaryを再評価し、新しい承認記述子と新しいApproval Bindingを発行する。

この設計では、承認の結果を少なくとも次に分けられる。

• Approve：承認記述子の範囲でPermitを発行する
• Reject：実行を不許可とし、理由をTraceに残す
• Modify：子Decisionを生成し、再評価・再承認へ戻す
• Timeout：期限切れとして無効化し、必要に応じてEscalationする
• Override：権限、理由、範囲、期限を明示した別のDecisionとして扱う

この区別により、Human Checkは曖昧な例外処理ではなく、責任を伴う意思決定の状態遷移になる。

Runtime OSでは、Approval BindingはHuman GateとExecution Boundaryをつなぐ

Runtime OSの最小ループは、次のように捉えられる。

Event → Signal → Decision → Boundary → Human Gate → Execution → Trace

AIの出力はSignalであり、それ自体はDecisionでもExecution Permissionでもない。Runtimeが文脈、ポリシー、権限、影響を評価してDecisionを作り、必要なときにHuman Gateへ上げる。

Approval Bindingは、このHuman GateとExecutionの間にある、欠けてはならない接続部である。

ここでHuman Gateは、最終画面のボタンではない。AIの提案を人間のAuthority、責任、実行権限、追跡可能性へ接続する意味的な判断境界である。

実装の最小形：短命・単回利用のCommand Permit

実装では、Approval Bindingを満たしたときだけ、短命のCommand Permitを発行する形が扱いやすい。

Permitには、少なくとも次を含める。

• decision_id と trace_id
• 正規化済み操作のハッシュ
• 人間表示記述子のハッシュ
• 対象、宛先、スコープ、最大実行回数
• ポリシー版、委任ID、承認者
• 発行時刻、失効時刻、nonce
• 消費済み状態

Execution BoundaryはPermitを受け取っても、そのまま信頼しない。現在の操作を再構成し、Permitの対象・条件・ハッシュ・期限・消費状態と照合する。一致した場合だけ、対応するToolや外部APIへ渡す。不一致、失効、重複利用、ポリシー変更時は、外部へ到達する前に停止する。

これはトークンを持つAgentに万能な権限を与える設計とは逆である。Agentができる行為を、あるDecisionに対する一回の、限定された実行にまで狭める。

Decision Traceはログではなく、承認の因果関係を残す

Approval Bindingがあっても、承認、実行、結果が別々のログに散らばれば、事故後に因果関係を追えない。

Decision Traceには、少なくとも次の連鎖を残す。

Evidence
 → Signal
 → Policy / Boundary Evaluation
 → Decision
 → Human-visible Descriptor
 → Approval Binding
 → Command Permit
 → Pre-execution Check
 → Execution
 → Outcome

これにより、監査や障害調査で「誰が承認したか」だけでなく、次の問いに答えられる。

• 承認者は何を見て判断したのか
• その時点でどのポリシーと根拠が使われたのか
• 実行直前に対象や条件は変わっていなかったか
• Permitは何回、どの範囲で消費されたか
• 不一致が起きたとき、システムは止まったか

Traceは単なる操作ログではない。判断が現実の行為へ変換された因果関係と責任境界を保持する、Runtime OSの記憶である。

まず防ぐべき失敗パターン

導入時には、次の設計を見つけたら優先して見直すべきである。

• 承認済みフラグだけを見て、非同期ワーカーが実行する
• 承認画面の表示内容とAPIリクエストが別系統で組み立てられる
• 承認後のパラメータ更新で再承認が起きない
• Policyや権限が変わっても、古い承認を使える
• 承認トークンに対象・範囲・期限・回数制限がない
• 同じ承認を複数回使える
• 実行ログにはあるが、何を承認したかが復元できない

最初からすべての操作を高度に署名する必要はない。まずは、送金、権限付与、外部送信、公開、削除、本番デプロイといった高影響操作で、承認記述子、実行直前の比較、短命Permit、Traceの四点を必須にする。

まとめ：Human Checkを責任ある実行許可へ変える

人が承認ボタンを押したという事実だけでは、安全な実行を保証できない。人が確認した対象・条件・実行内容・ポリシー版と、実際に実行する操作が結び付いて初めて、Human Checkは安全境界になる。

Approval Bindingは、その結び付きを実現する。

• 承認対象を正規化して固定する
• 人が見た説明と機械操作の両方をTraceに残す
• 短命・単回利用のPermitに実行権限を限定する
• 実行直前に現在の操作を再構成して照合する
• 差異、失効、権限変更があればfail-closedで止め、再承認する

AI Agent時代のHuman Checkは、最後に置くUIではない。AIのSignalを、人間のAuthorityと責任を伴う実行許可へ変換し、その過程を後から検証可能にするApproval Bindingである。

Runtime OSにおいて、それはHuman Gateを本当の判断境界にし、Loopjackingのような承認のすり替えを、実行前に止めるための実装原則となる。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance