AIエージェントが下書きを作るだけなら、誤りはレビューで戻せます。しかし、メール送信、CRM更新、ファイル削除、権限変更、支払いまで自動実行すると、誤った推論が外部作用になります。すべてを人に確認すると自動化の価値が消え、すべてを許可すると事故が増えます。
承認ゲートは、モデルの自信ではなく、失敗時の影響と可逆性で決めます。
操作を4段階に分類する
1. 読み取り
公開情報や許可された社内情報の検索です。外部通信や機密データの取得範囲は別途制限しますが、通常は都度承認せず、権限と監査で管理します。
2. 内部の可逆更新
下書き保存、タグ付け、仮ステータス変更などです。元に戻せ、影響範囲が限定される場合は、事後レビューとundoを条件に自動化できます。
3. 外部への送信・共有
顧客メール、公開投稿、ファイル共有、フォーム送信です。組織を代表する行為になるため、宛先、本文、添付、送信理由を人が確認します。
4. 高影響・不可逆操作
削除、支払い、権限付与、契約確定、医療・採用・与信などの判断です。原則として明示承認を必須にし、場合によってはエージェントの操作対象から外します。
承認画面で差分を見せる
「実行しますか？」だけでは判断できません。承認者には次を一画面で示します。
- 実行するtoolと操作種別
- 対象、宛先、変更前後の差分
- 送信するデータと機密区分
- エージェントが使った根拠
- 取り消し可否と影響範囲
- 承認期限
モデルが生成した長い説明は、説得力があっても安全性の証明ではありません。OWASPのAgentic AI Top 10は、人が権威性や説明に過度に依存するHuman-Agent Trust Exploitationを扱っています。承認画面は理由文より、具体的な差分と境界を優先します。
承認対象を固定する
承認後に本文、添付、宛先、金額が変わると、承認した操作と実行した操作が異なります。承認要求へpayload hashとversionを付け、実行直前に一致を確認します。違えば再承認へ戻します。
承認tokenは一回限り、短い期限、対象操作限定にします。別操作への流用や、古い承認の再利用を防ぎます。
timeoutはfail-closeにする
承認者が応答しなかった場合、「業務を止めないため自動実行」は危険です。高影響操作は期限切れで停止し、必要なら再申請します。低リスクの可逆更新だけ、明示したpolicyに基づく代替動作を許可します。
Cloudflare WorkflowsのwaitForEvent()のようなdurableな待機を使えば、processを開き続けずに承認eventを待てます。ただし、eventを送れる主体の認証・認可と、承認対象versionの検証はアプリ側の責任です。
承認疲れを測る
承認件数が多すぎると、人は内容を読まずに通します。次を計測します。
- 操作別の承認件数、却下率、修正率
- 申請から判断までの時間
- 承認後の取消・事故
- 同じ理由で繰り返される申請
- 承認なしで止まった高リスク操作
却下がほぼない場合も安全とは限りません。画面が分かりにくい、承認者が適切でない、業務上拒否できない可能性を調べます。
監査ログを残す
request ID、agent/version、tool、対象、payload hash、risk class、承認者、判断、日時、実行結果を記録します。機密本文を無制限に保存せず、必要なら暗号化・保持期限・閲覧権限を設定します。
NIST AI RMFは、人とAIの役割・責任を明確にし、appeal、override、incident response、change managementを含む運用監視を求めています。承認ゲートをUI部品ではなく、責任・復旧・学習の仕組みとして設計します。
AIエージェントの外部作用を確認したい方へ
TechWorkerでは、toolごとの権限、承認条件、監査ログ、fail-close、復旧手順をレビューします。外部通信の境界はAIエージェントのSSRF対策、法人審査の実装はAI SaaSが情シス審査を通るために実装したことも参照してください。
一次情報と確認範囲
確認日：2026年9月1日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。数値や研究結果は対象・条件を超えて一般化せず、反証可能性と限界を本文に併記しています。