ヒューマンインザループとは

ヒューマンインザループとは

ヒューマンインザループはAIの処理の途中に人の確認や承認を組み込み、人が承認、修正、却下のいずれかを選択するまで処理を停止する設計です。
略称はHITLです。
AIが作成した下書きや操作の内容を人が確認し、承認か修正なら処理を再開し、却下なら実行しません。
目的は、AIの誤りを含む出力の公開や操作の実行を、その前に人の判断で停止することです。
誤りの影響が深刻で取り消しが困難な操作ほど、実行前に停止する効果が増大します。

たとえば、問合せに回答するAIエージェントが返金を処理する場合、AIは返金の対象と金額を提示した時点で停止します。
担当者が内容を確認して承認すると、返金を実行します。
却下すると返金は実行されず、却下の結果と担当者が記入した理由をAIに返却する設計にすれば、AIは別の対応を検討します。
OpenAIのエージェント開発キットでは、ツールに承認が必要と指定すると、承認または却下されるまで実行を中断します。

経費の精算で、申請の作成は担当者が行い、支払いの前にだけ上長が承認する仕組みに近い設計です。

AIの出力を事前に定めた規則で自動判定するAIガードレールとは、判定するのが人である点で異なります。
人が処理の途中に関与せず、結果を後から監視するだけの設計は、ヒューマンオンザループと呼んで区別することがあります。
機械学習の分野では人が付与した正解や修正をモデルの学習に利用する仕組みも同じ名前で呼びます。
この記事はAIが作業する前に人が確認する意味を対象にします。

AIに業務を委任するときに人の判断が必要になる理由

AIは指示の誤解、事実と異なる内容の生成、プロンプトインジェクションによって、意図しない操作をすることがあります。
AIエージェントには人の意図しない商品の注文やファイルの削除をするリスクがあります。

Anthropicの社内で記録したAIエージェントの誤動作には、誤解した指示による共有のブランチの削除や、本番のデータベースへの変更の試みがありました。
ブランチの削除や本番のデータベースへの変更は、実行した後では取り消しが不可能か、取り消しに大きな手間がかかることがあります。
実行の直前で人が内容を確認すれば、誤りを含む操作を実行させずに停止できます。

規制も人の関与を求めています。
EUのAI規則（AI Act）の第14条は、採用や与信などで利用する高リスクに分類されるAIシステムを、人が効果的に監督できるように設計することを提供者に求めています。
第14条では、監督を担当する人が、状況に応じて適切かつ比例的に、AIの出力を無視、上書き、取り消しでき、システムを安全な状態で停止できる必要があります。
第14条が求めるのは監督できる設計で、毎回の承認に限りません。
Annex IIIに列挙された高リスクAIへの規則は、2027年12月2日から適用されます。
EU域内で該当するAIシステムを提供する場合は、この時期までに監督の仕組みの設計が必要です。

承認を配置する操作の選び方

承認は取り消し不能な操作と社外に影響する操作の直前に配置します。
参照、検索、下書きの作成のように、結果を人が後から確認して破棄できる操作には、原則として配置しません。
取り消し可能でも件数や金額が多い操作は、上限を超えた場合だけ承認します。

操作の種類	例	承認
取り消し不能、または社外に影響する	社外へのメールの送信、支払いと返金、データの削除、本番環境への反映、権限の変更	実行の直前に毎回
取り消し可能だが、件数や金額が多い	一括の更新、上限の金額を超える購入	上限を超えた場合だけ
取り消し可能で、影響が社内に限定される	社内の文書の下書き、検索、集計	不要。結果を抜き取りで確認する

金額の上限は同じ操作を人が行うときの社内の決裁権限の金額と一致させます。
1件を複数の操作に分割して上限を回避されないよう、同じ依頼に属する操作は金額を合算して判定します。
人なら上長の決裁が必要な金額の操作を、AIだけで実行させない設計にします。

承認を求めるかどうかはAIの判断やプロンプトの指示に依存させず、操作するツールやシステムの側で決定します。
AIが承認は不要と判断した場合や、プロンプトインジェクションで指示が改変された場合にも、承認を省略させないためです。

承認の画面にはAIの説明文ではなく、実際に実行する内容を表示します。
メールなら宛先と本文、返金なら対象の注文と金額、削除なら対象のデータの一覧です。
承認した内容と異なる内容を実行させないように、承認の後に内容を変更できない仕組みにします。

承認する担当者は操作の結果に責任を負う立場の人を指名し、不在時の代理も指名しておきます。
AIに作業を依頼した人と承認する人は別の人にします。
一定時間内に承認されない操作は実行せず、却下として処理し、案件を担当者に引き継ぎます。

承認の件数と形骸化

承認を求める件数が多すぎると、担当者が内容を確認せずに承認するようになるおそれがあります。
承認を求められる回数が多いと、利用者が承認する内容を注視しなくなる状態を承認疲れと呼びます。
Anthropicはこの承認疲れを問題にしており、同社のコーディング支援のAIでは、利用者が承認を求められた操作の93%が承認されていました。
同じAIでは安全な範囲を事前に限定して操作を許可するサンドボックスの導入で、社内での利用時に承認を求める回数が84%減少しました。

承認の件数は担当者が確保できる時間で上限を設定します。
1件の確認に必要な時間と1日の件数の積が、担当者の確保できる時間を超過する場合は、承認の対象を限定します。
たとえば1件2分の確認が1日150件あれば、確認だけで5時間になります。

承認の件数の削減には次の手段を併用します。

• 最小権限の原則に従い、AIに付与する権限を業務に必要な範囲に限定して、承認が必要な操作を削減する
• 送信先や操作の対象を許可リストで事前に限定し、その範囲内の操作は承認なしに実行する
• 形式や金額の上限はAIガードレールのような規則で自動判定し、人は規則で判定できない操作だけを確認する

AI事業者ガイドライン第1.2版は、人の判断を介在させる際に、自動化されたシステムを過度に信頼する自動化バイアスへの対策を実施すべきだとしています。

運用を開始した後は承認率、承認までの時間、却下と修正の理由を記録します。
却下や修正がほとんどない操作のうち、取り消し可能な操作から承認を廃止し、結果の抜き取り確認に移行します。
取り消し不能な操作は実績が増加しても承認を維持します。
承認率が100%に近く承認までの時間が極端に短い場合は、担当者が内容を確認せずに承認している可能性があります。

効果とコスト・リスク

効果

• 取り消し不能な操作の誤りを、実行の前に停止できる
• 誤りの事例と却下の理由が記録され、AIの改善や評価の課題に利用できる
• 承認した担当者が記録されるため、操作の責任の所在を追跡できる

コストとリスク

• 担当者の確認の時間。件数に比例して増加する
• 処理の遅延。承認されるまで処理が停止するため、夜間や休日には完了までの時間が延長する
• 形骸化。件数が多い、表示する内容が不十分といった場合、内容を確認せずに承認する
• 運用の設計。承認者の指名、代理、期限切れの扱い、承認の記録の保存を設計する手間が発生する

よくある誤解

人が承認すれば誤りは防止できる

承認は担当者が表示された内容を確認して可否を決定できる場合に限り機能します。
件数が多い場合や、表示される内容がAIの説明文だけの場合は、誤りを含む操作も承認されやすくなります。
承認の対象を取り消し不能な操作や社外に影響する操作に限定し、実際に実行する内容を表示します。

AIに承認を求めるよう指示すれば承認の仕組みになる

プロンプトで重要な操作の前に確認するよう指示しても、AIが指示に従わない場合や、処理した文書に混入した指示で改変された場合には承認を省略します。
承認の仕組みはツールやシステムの側で、承認されるまで操作を実行できない形で実装します。