ヒューマン・イン・ザ・ループ——AI付き業務の統制を設計する

LLMベースの自動化を本番で運用しはじめると、必ず出てくる論点がある。「全部AIに任せていいのか。どこで人が見るべきか」——ヒューマン・イン・ザ・ループ（HITL）の設計だ。

「AIの補助として、人が最終確認する」という一般的な説明では、実運用の設計指針にはならない。この記事では、編集部が観測してきた具体的な考え方を整理する。

確認点は、モデルの確信度ではなく、損害額で決める

「モデルの確信度が閾値を下回ったら人手確認」——最も直感的な設計だが、実運用ではしばしば期待通りに機能しない。理由は単純で、確信度が高くても被害の大きい判断はあるし、確信度が低くても直しやすい判断もあるからだ。

編集部が推奨するのは、「間違えたときの損害額」×「間違える確率（=1-確信度）」の期待損害でしきい値を設計することだ。契約金額の分岐、患者情報の判定、金銭を動かす操作は、確信度が高くても人手確認を通す。一方、社内問い合わせの初期分類のような、間違えても差し戻しできる領域は、低確信度でも自動処理に流して構わない。

確認画面を、Yes / Noにしない

HITL運用でよく見るのは、「AIが提案した結果を、担当者が承認 or 却下する」タイプのUIだ。これは短期的には動くが、長期的には運用の情報を失っている。

より良いのは、担当者が「訂正した内容」を記録できるUIだ。単に却下ではなく、「AIはXと出したが、正解はY」を残す。これは3つの意味で強力になる。エラーの原因を後から分析できる。将来モデルを再学習・調整するときの高品質な学習データになる。担当者にとっても「自分が何をしたか」が可視化され、責任所在が明確になる。

1件あたりの確認時間を、30秒以内に

「AIが提案 → 人が確認」の設計は、確認負荷が現実的でないと機能しない。1件あたり数分かかる確認プロセスは、担当者が「まあ大丈夫だろう」と流し始めるまでの時間を測っているようなものだ。

編集部が観測した運用チームは、以下のような工夫をしていた。判断に必要な情報を1画面に集約する（別画面を開かせない）。差分表示（前回との違い、テンプレートとの違い）を強調する。ワンクリック承認・訂正・エスカレーションの3ボタンに絞る。1件あたり30秒以内で判断できる状態を目標にする。

HITLは減らせるものと考える

HITLは、恒久的な運用形態ではなく、段階的に緩めていく仕組みと考えたほうがよい。運用開始時は全件確認から始め、以下の条件が揃ったら自動化率を上げていく。ゴールデンセットでの評価精度が3ヶ月継続して安定している。運用ログから、特定の入力パターンでは訂正がほぼ発生していない。担当者からの「これは自動化していい」というフィードバックがある。

ただし、逆方向も想定しておく。モデルベンダーの更新や上流データの変化で品質が下がった場合、自動化率を戻すルートも設計に含める。「自動化率を下げる」は失敗ではなく、正常な安全弁だ。

もっとも、HITLは万能ではない

ただし、HITLが常に正解というわけではない。人手確認を挟むことで判断が遅くなり、ビジネス上の応答時間要件を満たせなくなるケースもある。金融取引の即時判定、医療の救急トリアージ、リアルタイムの詐欺検知などがそうだ。

これらの領域では、HITLを「確認」ではなく「事後監査」に移す設計もある。すべてのAI判断をログに残し、専門家チームが後日サンプリング検査する。異常があれば遡及的にモデルを止める。反応速度を犠牲にせず、ガバナンスを保つ工夫だ。

参考にした一次資料

• Amershi, S. et al. “Guidelines for Human-AI Interaction.” Proceedings of CHI 2019.
• NIST. “AI Risk Management Framework (AI RMF 1.0).” nist.gov, 2023.

関連する話題として、バックオフィス自動化の設計とエージェント運用の観測性もあわせてお読みください。