AIエージェント がトランザクションを組み立てる時代、一番怖いのは「変なtxを作られること」です。

説明文は正しそうに見えるのに、実際の実行内容が全く違う。こういう事故を前提に設計する必要があります。

本記事の結論は、AI時代のHITLは『都度承認 + delegate強制ルール』の二重ガードで設計するです。

問題設定: 都度承認だけでは弱い

Human-in-the-Loop（HITL）の基本は「人間が毎回確認して承認する」ことです。

ただし、これだけだと次の弱点があります。

• 人間が読み間違える
• UIの説明文と実際の実行が違っても気づけない
• 承認後に実行内容が差し替えられる可能性

要するに、人間の注意力だけに依存する設計は脆いです。

解決策: EIP-7702のdelegate強制ルールで二重化

EIP-7702 を使うと、次の二重ガードを作れます。

1. 1段目: 人間が都度承認で止める
2. 2段目: delegateの実行条件で機械的に弾く（条件外はrevert）

最小限の用語整理

• authorization: 「この実行を許可する」署名
• delegate: 実際の実行ルールを書くコントラクト
• authority: 署名する人（EOA）
• revert: 条件を満たさず実行を失敗させること
• trace: トランザクション内部の実行手順を追跡すること

7702では、署名だけで細かい制限を表現するのではなく、delegate側のルールで判定します。

つまり、署名が入口、制限の本体はdelegateです。

設計の核心: 運用ウォレットは常にdelegate経由

ガードレールを効かせるには、運用用ウォレットの実行を常にdelegate経由に寄せる必要があります。

具体的には次の3点を徹底します。

1) 直接実行を運用ルールで禁止

delegate経由以外の実行を許すと、ガードレールが素通りされます。

運用上、直callを禁止し、全実行をdelegate経由に統一します。

2) delegateで縛る項目を明確化

delegate側で強制する条件を先に固定します。

• 金額制限: 1回上限 + 日次累計上限
• 宛先制限: 許可済みコントラクトのみ
• 操作制限: swapのみ許可、transferは禁止
• 期限制限: authorization有効期限

3) delegate変更は別承認フローに分離

delegate自体を変更する操作は、通常実行とは別の承認フローに分けます。

これにより、「delegateを悪意あるものに差し替える」攻撃を防ぎます。

実装上の注意点

nonce管理が重要

7702のauthorizationはauthorityのnonceに結びついています。

ユーザーが別件でトランザクションを送ってnonceが進むと、古いnonce前提で作ったauthorizationは無効になります。

実務では次をやります。

• 署名してすぐ送る（長く寝かせない）
• nonce管理を1箇所に集約する
• 自動化用アカウントを分ける（人手送信と混ぜない）

事前判定で無駄な署名を減らす

閾値/ルール内かどうかは、事前シミュレーション（eth_call / trace）で機械判定できます。

判定NGなら即中止、判定OKなら署名要求へ進む、という流れにすると、無駄な署名を減らせます。

例えば、送信前にeth_callでルール判定を行う最小例は次のとおりです。

1

cast call "$DELEGATE_CONTRACT" "validate(bytes)(bool)" "$ENCODED_TX" --rpc-url "$RPC_URL"

この呼び出しが失敗（revert）する場合は、送信せず中止します。

flowchart TD
    P["AIがtx候補を作成"] --> V["事前シミュレーション"]
    V --> C{"delegateルール判定"}
    C -->|ルール内| H["人間のauthorization署名"]
    C -->|ルール外| Stop["即中止"]
    H --> TX["delegate経由で送信"]

ハマるユースケース

7702 + HITLが向いているのは、頻度は低めでも1回の失敗が重い処理です。

• 高額送金・高額スワップ
• 新規コントラクト初回実行
• 権限変更系（delegate変更・大きいapproveを伴う操作）
• 法務/監査が必要な経費実行
• 共同運用ウォレットでの例外処理
• 事故コストが高い運用（DeFi運用金・トレジャリー資金）

逆に、高頻度・小額の定型処理は都度承認と相性が悪いです。

まとめ

AIエージェントが変なtxを作る前提で考えると、都度承認だけでは不十分です。

EIP-7702を使うことで、人間の承認 + delegate強制ルールの二重ガードを実現できます。

設計の要点は次の3つです。

1. 運用ウォレットは常にdelegate経由に統一
2. delegate側で金額・宛先・操作・期限を強制
3. nonce管理を厳密化し、署名在庫の失効を防ぐ

この設計により、「人間が読み間違えても、ルール外ならチェーン上で失敗する」という安全網を作れます。

参考リンク

• EIP-7702: Set EOA account code for one transaction
• EIP-4337: Account Abstraction
• ethereum/EIPs GitHubリポジトリ
• EIP-7702時代のAccount Abstraction: 4337が必要なケース
• AI×Web3から見える2026年の大胆予測: エージェントがウォレットを持つ時代