HITLとは｜取り消せない操作だけ確認したら、手間は3分の1で事故はゼロになった

HITLとはどういう仕組みなのか

AIが実行しようとする操作を、人が承認してから通す仕組みです。誤りが起きる前提で、被害の大きい操作だけを止めます。

HITL（人間承認）は、AIの判断と実行のあいだに人を挟む設計です。AIが「この操作をします」と示し、人が承認して初めて実行されます。

誤りが起きる前提で組む

この仕組みが要る理由は、OWASPの定義がそのまま示しています。想定外・曖昧・操作された出力に応じて有害な操作が実行されてしまう問題があり、原因がAIの誤作動でも攻撃でも同じことが起きる、とされています。

つまり、攻撃されていなくても事故は起こりえます。検査で入力を止めるだけでは足りないため、実行の直前に別の関門を置くことになります。

全部を止めるわけではない

ただし、すべての操作に確認を挟むと自動化の意味が薄れます。検索や下書きの保存まで承認を求めるのは過剰です。間違えても戻せるためです。

分ける基準は単純で、取り消せるかどうかになります。次の節で、この線引きによる差を数字で見ます。

取り消せない操作だけ確認したら手間が3分の1になった

100件を処理したときの確認回数と事故を3構成で計算しました。対象を絞っても、防げる事故は変わりません。

HITL（人間承認）の効果を確かめるため、計算しました。1件の処理に6つの操作が含まれる想定です。検索3回、下書き保存1回、メール送信1回、注文の確定1回。

このうち取り消せないのは、メール送信と注文の確定の2つです。操作1回あたり3%で誤ると仮定しました。

100件を処理したときの、確認回数と防げなかった事故

構成                  確認回数  取り返しのつかない事故
確認なし                  0回  6.0件
取り消せない操作だけ     200回  0.0件
全操作を確認             600回  0.0件

全操作: 600回 / うち取り消せない操作: 200回（33%）

結果が分かれました。確認なしでは6.0件の事故が起きる計算です。メールの誤送信と注文の誤確定が、100件のうち6件発生します。

対象を絞っても効果は同じ

注目してほしいのは、下2行がどちらも0.0件である点です。全操作を確認しても、取り消せない操作だけ確認しても、防げる事故の数は変わりません。

理由は単純で、取り消せる操作は誤っても戻せるからです。検索を間違えればやり直せばよく、下書きは書き直せます。事故として数える必要がありません。

手間は3分の1で済む

一方で確認回数は大きく違います。600回と200回、3分の1です。同じ効果を3分の1の手間で得られることになります。

確認が形骸化しないためには何が要るのか

承認画面に判断できる情報を出すことです。回数を減らし、1回あたりの情報を厚くします。逆をやると押すだけの作業になります。

HITL（人間承認）で最も起きやすい失敗が、確認が形だけになることです。押せば進むボタンが並ぶと、内容を見なくなります。

回数が多いと見なくなる

前の節の計算で、全操作を確認する構成は600回でした。1件につき6回、判断を求められます。しかもそのうち4回は取り消せる操作です。

この状態が続くと、確認は作業になります。押すことが目的になり、本当に見るべき2回も同じ勢いで押されます。回数を絞るのは、手間の問題であると同時に、注意力の問題でもあります。

画面に何を出すか

もう1つが、承認画面の中身です。「この操作を実行しますか」だけでは判断できません。何を、どこに、どれだけが読める必要があります。

1. 実行しようとしている操作の名前。メール送信なのか、削除なのか
2. 対象。宛先のアドレス、削除するファイル名、注文番号
3. 影響の大きさ。金額、件数、取り消せるかどうか
4. なぜそう判断したか。AIが根拠にした情報

4つ目があると、判断の質が変わります。「未発送だからキャンセル可能と判断」と書いてあれば、その前提が正しいかを人が確かめられます。

承認したことを記録する

承認は誰がいつ行ったかを記録します。後から経緯を説明するときに必要になるためです。記録の設計はエージェント監査ログの記事で扱っています。

また、確認を挟む前提として、そもそも実行できる操作を絞っておくことも重要です。エージェントのセキュリティの記事とガードレールの記事で扱っています。