AIエージェントに人間の承認｜止める5条件
目次
はじめに
見積書を作るところまでは速い。ところが「送信」だけは怖くて、担当者が毎回チャットを開き、内容を読み直し、承認ボタンを押す。AIエージェントを導入したのに、承認待ちの列が伸びていく。そんな設計は珍しくない。
反対に、承認を外しすぎると誤送信を止められない。必要なのは全面自動化でも全面承認でもない。事故の影響が大きい場面だけ、人へ制御を戻す分岐である。
その境界は「念のため承認」と書くだけでは決まらない。AIエージェントの作り方で扱った承認シーケンスを一段掘り下げ、止めた後を承認、入力差し戻し、障害通知、自動拒否に分けて仕様化する。
人間承認はブレーキではなく分岐である
Human-in-the-loop（HITL）は、人がAIの全出力を校正する運用ではない。AIエージェントが一定条件に触れたときに実行を止め、判断権を人へ渡す仕組みだ。
OpenAIのエージェント構築ガイドは、人が介入する代表的な契機として「失敗回数などの閾値超過」と「高リスクな操作」を挙げている。注文キャンセル、大きな返金、支払いのように、戻しにくく影響の大きい操作が例だ。
住所表記の正規化や社内向け下書きは自動で進める。一方、顧客への送信や基幹データの確定は止める。操作ごとに自動範囲を変えられる。
AIエージェントに人間の承認を組み込む5条件
1. 元に戻せない、または社外へ影響する
最初の条件は不可逆性である。メール送信、公開、削除、契約確定、振込などが当たる。取り消せても相手に通知済みなら、実務上は元に戻せない。
たとえば見積書のPDF生成は自動でよい。顧客アドレスへの送信は止める。作成と実行を分けるだけで、承認件数を抑えながら事故の出口を塞げる。
2. 金額や権限の閾値を超える
次は業務ルールで切れる条件だ。「10万円以上の返金」「管理者権限の付与」「重要顧客のステータス変更」のように数値と対象を決める。
Microsoft Learnのマルチステージ承認の解説でも、金額条件による経路分岐と、人による最終決定が例示されている。プレビュー機能の資料なので採用時は仕様確認が要るが、分岐の考え方は参考になる。閾値は設定値として管理し、変更履歴を残す。
金額だけでは足りない。8万円でも、新規取引先への初回支払いは承認する。金額、データ区分、相手先、実行者権限を組み合わせる。
3. 入力が足りない、矛盾する、確信を持てない
AIに迷わせたまま実行させない。請求先コードがない。契約書と申請フォームの金額が違う。根拠資料が古い。これは承認ではなく `input_required` へ移し、入力者へ差し戻す。
確信度の数値だけに頼るのは危うい。モデルが出す0.8に業務上の保証はないからだ。必須項目の欠落、複数資料の不一致、参照日時の期限超過など、検査できる条件を先に置く。曖昧さが残るときだけ担当者へ回す。
Microsoftの同資料には、指示が矛盾してAIが判断できない例もある。「500ドル未満は承認」「300ドル超は却下」なら400ドルが両方に当たる。モデル性能よりルール設計の問題だ。条件の重なりを受入テストで洗い出したい。
4. 再試行回数や処理時間の上限を超える
AIエージェントは、失敗しても別の手段を試せる。便利だが、終わらない再試行はAPI費用と二重処理を生む。外部APIが3回失敗した、同じ検証を2回やり直した、開始から10分を超えた。そこで止める上限を決める。
上限超過は承認者ではなく運用担当への `ops_alert` にする。試行回数、入力、最後の応答をまとめる。担当者が最初からログをたどるなら丸投げだ。
5. 想定外の例外やポリシー外へ出る
業務フローにない値、新しい取引種別、未知のツール要求は自動実行しない。たとえば国内住所だけを扱う設計に海外住所が来たら、推測で補わず停止する。
ポリシー外は原則 `blocked` とし、例外責任者だけが解除できるようにする。発生した例外は毎週分類し、処理ルールとテストが揃ったものだけ通常経路へ移す。
5条件を全部同じ承認キューへ送ってはいけない。1と2は業務承認、3は入力差し戻し、4は障害通知、5は自動拒否か例外承認である。業務部門が閾値と承認者を決め、開発側は遷移、権限、通知、テストを実装する。
承認画面には判断材料を6点出す
承認者はAIの推論全文を読みたいわけではない。数十秒で「実行してよいか」を判断できる材料が必要だ。最低でも次の6点を一画面に揃える。
- 何を、誰に対して実行するのか
- 変更前と変更後の差分
- 判断に使った入力と参照元
- 影響する顧客、金額、データ件数
- 検出したリスクと、実行しない代替案
- 承認の期限と、期限切れ後の動作
見積メールなら、宛先、件名、添付ファイル、金額、前回見積との差分を出す。「承認しますか？」だけでは、承認者が別画面を何度も往復する。
承認待ちを壊さない状態設計
画面より先に状態を決める。少なくとも `pending`、`approved`、`rejected`、`expired`、`cancelled` を区別する。承認済みと期限切れを同じ「完了」にすると、後から実行可否を判定できない。
OpenAI Agents SDKの人間介入ガイドは、承認が必要なツール呼び出しで処理を中断し、実行状態を保存してから承認・拒否後に再開する流れを示している。LangGraphのinterruptも、状態を保存して後から再開する考え方を取る。フレームワークが違っても、停止地点を保存する設計は共通する。
再開時には同じ操作を二度実行しない仕組みも要る。承認要求ごとに一意なIDを 付け、外部APIへ渡す冪等キーと結びつける。画面の二度押しや通信再送があっても、送金やメール送信は一回に限定する。
承認が翌日になるなら、権限と入力の再確認も必要だ。申請時には在籍していた担当者が異動しているかもしれない。価格表が更新されているかもしれない。長時間停止した処理は、そのまま再開せず、期限、権限、参照データの版を検証する。
監査ログには、申請者、承認者、時刻、対象、変更差分、判断理由、実行結果を残す。ログ設計はAIエージェントの受入テストともセットで考えると抜けを見つけやすい。
そのまま使える承認仕様テンプレート
承認条件を実装へ渡すときは、一操作を次の8項目で書く。
- 操作IDと目的
- 停止条件と閾値
- 停止後の遷移先
- 画面に出す判断材料
- 承認者と代行者
- 拒否、期限切れ、取消後の動作
- 二重実行を防ぐ冪等キー
- 正常、拒否、期限切れ、再送の受入条件
見積メール送信なら、「値引き率10%以上または新規宛先で `approval_pending`」と書く。画面には宛先、金額、値引き理由、見積差分、添付を出す。承認は24時間で期限切れとし、再申請には 新しい要求IDを発行する。ただし送信処理の冪等キーは見積IDと版番号から作り、同じ版を二度送らない。
業務部門は値引き率、例外責任者、期限を決める。開発側は状態遷移、権限検査、冪等性、監査ログを実装し、4種類の受入テストを示す。この分担まで書けば、承認機能の見積と検収ができる。AIエージェントとチャットボットの違いで整理した外部操作の有無も、停止条件を決める起点になる。
2週間のPoCで承認を減らす
最初から最適な閾値は決められない。2週間だけ安全側に寄せ、承認率、拒否率、差し戻し理由、承認待ち時間、誤実行件数を測る。
100件中80件が承認対象で、拒否が1件なら止めすぎかもしれない。逆に承認は10件でも3件が拒否なら、その分岐は有効だ。件数だけでなく、事故時の影響額も見る。発生確率が低くても、影響が大きい操作は承認を残す。
目標は承認ゼロではない。人が判断する価値の低い承認を減らし、高リスクな判断へ集中させることだ。AIエージェントの開発標準で扱う受入基準や運用責任とつなげると、本番化の判断もしや すい。
承認条件を実装前の仕様にする
AIエージェントに人間の承認を組み込む作業は、ボタンを付ければ終わるものではない。業務フローには停止地点、権限表には承認者、状態遷移には拒否と期限切れ、テストには二重実行や長時間停止を入れる。
実装後に承認条件を足すと設計変更が大きい。ツール呼び出しの前後、状態保存、通知、権限確認を組み直すからだ。PoCの前に5条件を業務担当者と決めておけば、自動化できる範囲も明確になる。
Atsumellでは、業務フローの整理から権限、停止条件、受入テストまでを一続きの仕様として設計している。どこを自動化し、どこで人へ戻すか迷っているなら、現在の承認業務を1つ選び、分岐条件から一緒に整理できる。
