Opsfield
Human in the Loop（HITL）は、AIの処理の流れの途中に人の確認や承認を挟み、最終的な判断を人が担う仕組みです。生成AIを業務に入れた企業ほど、出力をそのまま使ってよいのか、どこまでを人が見るべきかという線引きに悩みます。
すべてを人が確認し直せば導入前より手間が増え、逆にすべてを任せれば誤った文面が顧客に届きかねません。つまり、HITLで問われているのは人を増やすことではなく、どの工程に人を残すかという設計です。
本記事では、HITLの定義とHuman on the Loop・Human out of the Loopとの違いを整理したうえで、人の判断を残す工程の決め方、4つの設計パターン、業務別の取り入れ方までを具体的に解説します。あわせて、承認が形だけになる原因と、人をループから外してよいかを見極める基準も扱います。
目次
Human in the Loop（HITL）とは？AIの処理に人の判断を組み込む仕組み
Human in the Loop（HITL）とは、AIによる処理の流れ（ループ）の中に人が入り、出力の確認・修正・承認を担う仕組みを指します。日本語ではヒューマンインザループ、あるいはヒューマン・イン・ザ・ループと表記され、人間参加型、人間介在型と言い換えられることもあります。
もともとは機械学習やシミュレーションの分野で使われてきた言葉で、学習用のデータに人が正解を付ける、モデルの出力を人が評価して学習に反映させるといった設計を指していました。そして生成AIの普及以降は、日々の業務でAIの出力を人が確かめてから使う運用全般を指す言葉としても定着しています。
ここで押さえておきたいのは、HITLが人の作業を増やすための仕組みではないという点です。AIに任せる範囲と、人が責任を持つ範囲を工程ごとに切り分ける考え方だといえます。作業はAIが担い、判断は人が持つ。その境界線をどこに引くかを決めるのがHITLの役割です。
Human on the Loop・Human out of the Loopとの違い
AIと人の関わり方は、HITLの一択ではありません。人がどこまで関与するかによって呼び分けがあり、選び方しだいで運用の負荷もリスクも変わります。3つの型を順に見ていきましょう。
Human in the Loop｜工程の途中で人が確認してから次へ進む
1つ目のHuman in the Loopは、AIが作った出力を人が確認し、承認してから次の工程へ進める形です。人の承認がなければ処理は止まったままになります。
例えば、問い合わせへの返信をAIが下書きし、担当者が内容を確かめてから送信するケースが当てはまります。請求書の内容をAIが読み取り、金額と取引先を経理担当が突き合わせてから支払処理に回す流れも同じ型です。誤りが外に出る前に必ず一度止まるため、影響が取り返しのつかない処理に向いています。
一方で、人が見るまで先に進まない構造そのものが弱点にもなります。承認する人が不在なら業務は止まり、件数が増えれば確認が追いつきません。そのため、どの処理をこの型にするかは絞り込む必要があります。
Human on the Loop｜人は監視役に回り、異常時だけ介入する
2つ目のHuman on the Loopは、AIが一連の処理を実行し、人はその様子を見守って異常があったときだけ割って入る形です。1件ずつの承認は行いません。
具体的には、AIが在庫の発注量を自動で算出して発注まで進め、担当者は発注実績の一覧を眺めて、普段と桁の違う数量が出たときだけ止める運用が当てはまります。件数が多く、1件ずつ止めていては処理量に見合わない業務で選ばれる型です。
ただし、この型は人の集中力に依存します。異常がめったに起きない処理ほど画面は素通りされ、いざ異常が出ても気づけません。監視を機能させるには、人が目視で探すのではなく、何を異常とみなすかを条件として定義し、システム側から知らせる仕組みが要ります。
Human out of the Loop｜人が関与せず、AIが最後まで実行する
3つ目のHuman out of the Loopは、人が処理に一切関与せず、AIが判断から実行までを完結させる形です。いわゆる完全自動化がこれにあたります。
迷惑メールの振り分け、社内チャットの要約、フォーム入力内容の分類など、間違えても被害が小さく、後からやり直せる処理はこの型で十分です。むしろ、こうした処理にまで承認を挟むと、確認の手間だけが積み上がります。ただし、人がまったく責任を負わないわけではありません。結果を定期的に点検し、必要なら設定を直す役割は残ります。
このほか、AIに方針を与える人の立場を強調したHuman above the Loopや、Human in Commandといった呼び方も見かけますが、業務設計の実務で使い分けるのは上記の3つで足ります。
HITLが2026年に注目されている背景
HITLという考え方自体は新しくありません。それが改めて注目されているのは、AIが業務の中で担う範囲が、この1〜2年で大きく変わったからです。
1つは、生成AIが日常業務に入り込んだことです。パーソル総合研究所が2026年2月に公表した生成AIとはたらき方に関する実態調査では、業務で生成AIを使う人が就業者の32.4%、およそ1,840万人にのぼると報告されています。生成AIは事実と異なる内容をもっともらしい文章で出すハルシネーションを起こしますが、文面が自然なだけに誤りは見落とされがちです。扱う件数が増えるほど、誰がどこで確かめるのかという設計が必要になります。
もう1つは、AIエージェントの普及です。下書きを作るだけだった段階から、メールの送信、システムへの登録、データの更新といった実行まで任せる段階に入りました。そのため、出力を読んで判断する場面だけでなく、実行する手前で止めるという設計が新たに問われています。
加えて、制度の側からも人の関与が求められるようになりました。EUのAI法は高リスクとされるAIシステムについて、人による監督に関する規定を設け、AIの出力を無視・上書きできる権限や停止手段を確保するよう定めています。国内でも総務省と経済産業省がAI事業者ガイドラインを継続的に更新し、2026年3月には第1.2版が公表されました。HITLは、いまや現場の工夫にとどまらず、説明を求められたときの拠りどころになりつつあります。
HITLはAI開発と業務運用の2つの場面で使われる
HITLという言葉は、AIを作る側と使う側の両方で使われています。同じ言葉でも人が担う役割はまったく違うため、ここでは2つの場面を分けて整理します。
AI開発の場面｜アノテーションやRLHFでモデルの精度を上げる
1つ目は、AIモデルそのものを育てる場面です。ここでの人の役割は、AIに正解を教えることにあります。
代表的なのがアノテーションです。画像のどこに何が写っているか、この文章は問い合わせか苦情かといったラベルを人が付け、その積み重ねが学習データになります。さらに、AIが出した複数の回答に人が順位を付け、好ましい出力を学ばせるRLHF（人間のフィードバックによる強化学習）も同じ発想です。AIが自信を持てなかったデータだけを人に回して効率よく学習させるアクティブラーニングという手法もあります。
つまり開発の場面では、人は品質の基準そのものを供給する立場に立ちます。IBMやDatabricksといったベンダーがHITLを語るとき、多くはこの文脈を指しています。
業務運用の場面｜日々の業務でAIの出力を人が確認・承認する
2つ目は、すでにあるAIを日々の業務で使う場面です。人の役割は正解を教えることではなく、目の前の出力を使ってよいかを決めることに移ります。
AIが作成した見積書の金額を確認してから送る、採用候補者の要約を読んだうえで面接の可否は人が決める、といった判断がこれにあたります。開発の場面と違い、特別な体制は要りません。必要なのは、どの工程で誰が確認するかを業務のルールとして決めておくことだけです。
検索でHITLという言葉にたどり着く人には、この2つの立場が混ざっています。自社でモデルを作らない企業にとって、アノテーションやRLHFの知識は直接は役立ちません。必要なのは、手元の業務のどこに確認を挟むかという判断です。
本記事でこれから扱うのも、主にこちらの業務運用の場面です。AIの活用を前提に業務やビジネスモデル、組織のあり方そのものを変革するAX（AIトランスフォーメーション）を進めるうえで、人の役割をどこに残すかを決める作業にあたります。
HITLを業務に取り入れる4つのメリット
HITLは安全のための仕組みだと思われがちですが、得られる効果はそれだけではありません。業務に組み込むことで生まれる利点は、大きく4つあります。
誤りが顧客に届く前に止められる
1つ目は、AIの誤りが社外に出る前に食い止められることです。これがHITLの最も直接的な効果になります。
生成AIは、実在しない機能を製品説明に混ぜたり、古い料金を現行のものとして書いたりします。文章として自然なため、受け取った側は誤りだと気づきません。送信の手前に人の確認を1つ置くだけで、こうした誤りは社内で止まります。
特に、見積書の金額、契約条件の記載、求人票の労働条件のように、いったん外に出ると訂正の手間が大きい情報ほど効果が大きくなります。誤った金額を提示した後の値引き交渉や、条件の訂正に伴う社内調整まで含めれば、失う時間は元の作業時間を大きく超えます。
その点で、確認にかかる数分は保険料に近い性質を持ちます。何も起きなければ無駄に見えますが、一度防げば十分に元が取れる投資です。
判断の根拠が記録に残り、後から説明できる
2つ目は、誰がいつ何を確認したのかが記録として残ることです。承認という工程には、記録を生むという副次的な効果があります。
AIが出した結果をそのまま使っていると、なぜその判断になったのかを後から説明できません。取引先から根拠を求められたとき、あるいは社内で問題が起きたときに、AIが出したからという説明は通用しないでしょう。承認者と承認日時、修正した箇所が残っていれば、経緯をたどれます。
この記録が効くのは、対外的な説明の場面だけではありません。どの種類の出力が頻繁に修正されているかを見れば、AIに渡す指示のどこが不足しているかが見えてきます。例えば、見積書の備考欄ばかりが直されているなら、記載すべき条件をAIに伝えきれていないということです。
人の修正がそのまま精度改善の材料になる
3つ目は、人が直した内容が、AIの出力を良くするための材料になることです。確認は、単なるチェック作業では終わりません。
例えば、AIが作った問い合わせへの返信を担当者が毎回同じように直しているなら、そこには言語化されていない社内の基準があります。この表現は使わない、この場合は必ず折り返しの期限を書く、といった暗黙のルールです。修正の傾向を集めて指示文やマニュアルに反映すれば、次からはAIが最初からその形で出すようになります。
この積み重ねは、汎用のAIを自社仕様に近づけていく作業でもあります。同じ業務であっても、会社ごとに独自の進め方が積み重なっているものです。修正の履歴は、それを可視化してくれる唯一の材料です。
その点で、HITLは人が我慢して尻拭いをする仕組みではありません。確認の手間を、AIを育てるための投資に変える仕掛けだと捉えると、続ける意味が見えてきます。
現場が安心して使えるようになり、利用が定着する
4つ目は、現場の心理的な抵抗が下がり、AIの利用が定着しやすくなることです。意外に見えますが、導入の成否を分ける要素になります。
AIの導入が止まる原因の多くは、機能への不満ではなく、間違っていたら自分の責任になるという不安です。最終的な判断は人が持ち、確認の手順が決まっていると分かれば、担当者は下書きを作らせる段階から気軽に使えます。
実際、AIの利用が広がらない職場では、使ってよい業務の範囲が曖昧なまま放置されている例が目立ちます。承認の手順を決めることは、裏を返せば、ここまでは使ってよいと示すことでもあります。
もちろん、確認の負担を現場に押し付けるだけでは逆効果になります。どこまで見ればよいかを具体的に示し、見なくてよい範囲も同時に伝える。この2つがそろって初めて、使ってみようという空気が生まれます。
HITLのデメリットと見落とされやすい運用コスト
人の確認を挟むことには相応の代償もあります。しかも、その多くは導入の計画段階では見積もられません。見落とされやすいデメリットを4つ挙げます。
承認待ちが新しいボトルネックになる
1つ目は、AIによって短くなった作業時間が、承認を待つ時間に置き換わってしまうことです。作業は速くなったのに、業務全体はまったく速くなっていないという状態が起こります。
例えば、提案書の作成が3時間から30分になっても、上長の承認が翌日まで下りなければ、顧客に届くまでの時間は以前と変わりません。ボトルネックがAIの性能ではなく、承認の段取りに移っただけです。中小企業ほど承認者が少数に集中しており、この詰まりは起きやすくなります。
そのため、効果を測るときは作業時間と承認待ち時間を分けて記録してください。前者はAIで縮み、後者はフローの設計でしか縮みません。承認の階層を1段減らす、金額の小さい案件は承認を不要にするといった見直しは、AIの入れ替えより効きます。
確認する人の時間が増え、削減効果が相殺される
2つ目は、AIが浮かせた時間を、確認の時間が食いつぶしてしまうことです。数字で見ると、この相殺は決して珍しくありません。
先に挙げたパーソル総合研究所の調査では、生成AIを使ったタスクの所要時間は平均16.7%短くなった一方で、実際に業務時間が減ったと答えた人は利用者の約25%にとどまりました。作業単位では速くなっても、業務全体の時間には表れていない人が多数を占めます。
見積もり方は単純で、確認1件あたりの時間×件数×担当者の時間単価を、削減できた作業時間の価値と比べるだけです。月に500件の下書きを1件3分ずつ確認すれば25時間になります。この計算を先にしておけば、全件確認のままでは割に合わない業務がどれかを、導入前に把握できます。
承認できる人が限られ、業務が属人化する
3つ目は、確認の質が特定の人に依存し、その人がいないと業務が回らなくなることです。AIを入れたのに属人化が進むという、本末転倒な事態が起こります。
AIの出力が正しいかを判断するには、業務そのものを知っていなければなりません。結果として、ベテラン1人に承認が集中しがちです。その人が休めば処理が滞り、退職すれば誰も引き継げません。しかも承認者を増やそうにも、判断の基準が本人の頭の中にあるうちは育成もできず、教える時間だけが積み上がります。
この問題を解くには、承認者を増やす前に判断の基準を書き出す順序が要ります。新人に引き継げない業務は、AIにも引き継げません。何を見て可否を決めているのかを言葉にする作業は、属人化の解消とAIへの指示の改善を同時に進めてくれます。
人が確認したという事実が、誤りの免罪符になる
4つ目は、確認済みという記録だけが残り、実質的な点検が行われなくなることです。承認欄が埋まっていることと、中身が見られたことは別物になります。
人の目を通したという事実があると、後工程の担当者はその出力を信用します。ところが承認した側も、AIが作ったのだから大きな間違いはないだろうと考えている場合、誰も実質的に中身を見ていない状態が生まれます。責任の所在は曖昧なまま、形式だけが整うわけです。
これはHITLに特有の落とし穴で、運用を始めて数か月してから表面化します。AI導入全般でつまずきやすい点はAI導入で失敗しない方法で整理していますが、承認の形骸化はその中でも発見が遅れやすい部類に入ります。防ぐ手立ては、承認者の選び方と、確認する条件の決め方の2つです。
HITLで人の判断を残す工程の決め方
HITLの成否は、人を何人置くかではなく、どこに置くかで決まります。介在点を見極めるための考え方を4つ紹介します。
職種や業務でなく、工程単位で介在点を決める
1つ目は、営業はAI向き、経理は不向きといった職種単位の問いを捨てることです。この問いの立て方をしている限り、答えは出ません。
1つの業務は、実際には数十の工程の束です。例えば請求業務なら、伝票の読み取り、金額の計算、取引先マスタとの突き合わせ、承認、送付、入金の消込と分かれます。このうち読み取りと計算はAIに任せられますが、取引先との個別の取り決めを踏まえた判断は人に残ります。同じ業務の中に、渡せる工程と持つべき工程が混在しているわけです。
そこで最初にやるべきなのは、対象の業務を工程に分解して書き出す作業です。分解の粒度は、それぞれが誰かの手を離れて次に渡る単位まで下げます。この一覧ができて初めて、どこに人の承認を置くかという議論が成立します。なお、業務を洗い出す手順そのものはAI導入は何から始めるかで解説しています。
やり直せない工程の手前に承認を置く
2つ目は、間違えたときにやり直せるかどうかで、承認の位置を決めることです。工程を分解したら、取り消せない操作に印を付けていきます。
社内の下書きフォルダに保存する操作は、後から消せます。一方、顧客へのメール送信、請求データの確定、求人媒体への掲載、外部システムへの登録は取り消せません。承認を置くべきなのは、この取り消せない一歩の直前です。AIに手前の工程をすべて任せたうえで、最後の引き金だけを人が引く形にします。
逆に言えば、やり直せる工程にまで承認を置く必要はありません。下書きの保存や社内メモの作成にまで確認を挟むと、チェックの回数だけが増えて肝心の箇所が薄くなります。承認は、置くほど安全になるものではないと考えてください。
社外に出る出力は、社内で止まる出力と分けて扱う
3つ目は、その出力が誰の目に触れるかで扱いを変えることです。やり直せるかどうかと並ぶ、もう1つの軸になります。
社内の会議メモや議事録の要約は、多少の誤りがあってもその場で訂正できます。ところが提案書、契約書の草案、SNSへの投稿、採用の合否連絡は、社外の相手に届いた時点で自社の見解として受け取られます。誤りの影響が、届く範囲の広さに比例して大きくなるわけです。
この2つの軸を組み合わせると、優先順位がはっきりします。やり直せず、かつ社外に出る工程には必ず人の承認を置く。やり直せて社内に留まる工程はAIに任せる。残る2つの象限は、件数と確認にかかる時間を見て決めるのが現実的です。
なお、社内向けだから軽く扱ってよいとは限りません。役員会の資料や人事に関する連絡のように、社内でも影響の大きい出力はあります。届く範囲の広さと、届いた相手が受ける影響の重さは、あわせて見てください。
承認を置く工程は、確かめられる出力の形とセットで決める
4つ目は、介在点を決めるときに、その工程の出力をどう見せるかまで一緒に決めることです。置く場所だけを決めても、確かめようがなければ承認は機能しません。
例えば、社内規程についての回答文だけを出されても、正しいかどうかは規程を読み直さなければ分かりません。参照した規程名と該当箇所を回答に添えさせれば、確認は数十秒で済みます。請求書の読み取りなら、読み取った数値と原本の該当部分を並べて見せる形にすると、突き合わせが目視で完結します。
言い換えると、AIに求めるべきなのは答えだけではなく、答えの確かめ方までを含んだ出力です。この設計を省くと、確認の負担が重くなり、やがて中身を見ない承認へ滑っていきます。承認が機能するかどうかは、実のところ出力の形式で半分が決まります。
HITLの4つの設計パターン
人の介在のさせ方には、いくつか定型があります。どれを選ぶかで現場の負荷も変わるため、代表的な4つの型を、向き不向きとあわせて説明します。
レビュー型｜AIの出力を人が確認してから使う
1つ目はレビュー型で、AIが作った成果物を人が読み、必要なら直してから使う形です。最も導入しやすく、多くの企業が最初に選びます。
議事録の要約、提案書の下書き、記事案の作成など、成果物が文章になる業務と相性がよい型です。システムの改修も要らず、AIに下書きを作らせて担当者が仕上げるという運用ルールを決めるだけで始められます。
ただし、この型は強制力を持ちません。急いでいるときに確認を飛ばしても、誰にも止められない構造だからです。月末や繁忙期など、時間に追われる時期ほど素通りが増えます。
そのため、重要度の高い出力については、次に挙げる承認型へ切り替えてください。切り替えが難しい場合でも、確認した担当者の名前を成果物に残す運用を重ねると、素通りは目に見えて減ります。
承認型｜人が承認するまで次の処理に進ませない
2つ目は承認型で、人が承認ボタンを押すまで処理そのものが先に進まない形です。レビュー型との違いは、確認を飛ばせない点にあります。
金額が動く処理、社外に送る通知、契約に関わる書面はこの型が適しています。ワークフローツールの申請経路にAIの出力を載せる、あるいは送信処理の前に承認待ちの状態を作るといった作り込みが必要です。例えば、AIが作成した見積書を申請として起票し、上長が承認するまで顧客への送付を保留する形が挙げられます。
一方で、止める箇所を増やしすぎると業務全体が滞ります。すべての出力を承認型にするのではなく、やり直せない一歩の手前だけに絞ってください。また、承認者が1人に固定されていると不在時に止まるため、代理の承認者をあらかじめ決めておくと安全です。
エスカレーション型｜AIが判断できない案件だけ人に回す
3つ目はエスカレーション型で、AIが自信を持って処理できる案件はそのまま進め、判断に迷う案件だけを人に回す形です。件数の多い業務で効いてきます。
問い合わせ対応なら、よくある質問への回答はAIが完結させ、解約や請求に関する内容、感情的な表現を含む内容は人へ引き渡すといった振り分けになります。設計の勘所は、AIに渡す条件ではなく、人に回す条件を先に書き出すことです。金額が一定以上、過去に同じ相手からクレームがある、規程に該当箇所が見つからないといった具合に、具体的な条件として定義します。
また、回された案件を誰が受けるかも決めておいてください。戻し先が曖昧だと、宙に浮いた案件が滞留します。一次は担当チーム、判断がつかなければ責任者へ、という二段構えにしておくと止まりません。
フィードバック学習型｜人の修正を次の出力に反映させる
4つ目はフィードバック学習型で、人が直した内容を集め、AIの出力を継続的に良くしていく形です。前の3つと組み合わせて使います。
仕組みとしては、修正前後の文面を記録し、頻度の高い修正を指示文や参照資料に反映していきます。例えば、社名の表記を毎回直しているなら表記ルールを渡す、根拠の記載漏れが多いなら出力形式に参照元の欄を足す、といった改善です。記録は専用の仕組みを用意しなくても、差し戻すときに理由を一言コメントで残す運用があれば材料として足ります。
注意したいのは、その場の思いつきで指示を書き足し続けると、かえって出力が安定しなくなる点です。個別の修正をすぐ反映するのではなく、月に一度まとめて傾向を見て、再現性のある修正だけを取り込む。この頻度のほうが、結果的に早く精度が上がります。
業務別に見るHITLの取り入れ方
ここまでの考え方を、実際の業務に当てはめてみます。中小企業でも発生頻度が高い4つの業務と、公開されている企業の取り組みを紹介します。
顧客対応｜AIが一次回答を作り、人が送信前に確認する
顧客対応では、返信の下書きまでをAIに任せ、送信の直前に人が確認する形が基本になります。送信は取り消せないため、承認を置く位置はここで決まりです。
具体的には、問い合わせ内容をAIが分類し、過去の対応履歴とFAQを参照して返信案を作ります。担当者は、案内した内容が最新の仕様と合っているか、相手の状況に合っているかだけを見て送信します。ゼロから書くより速く、しかも表現の水準がそろう点が利点です。
加えて、解約や返金など金銭に関わる問い合わせは、エスカレーション型で責任者に回す条件を決めておきます。回す条件は、解約の申し出を含む、返金の金額が一定を超えるといった形で、判断の要らない表現に落としてください。同じ顧客対応という業務の中でも、渡せる工程と持つべき工程は分かれます。
経理・請求｜AIが読み取り、人が金額と取引先を確認する
経理では、請求書や領収書の読み取りをAIに任せ、人は金額と取引先の2点に絞って確認する形が現実的です。すべての項目を見直していては、手入力と変わりません。
読み取り結果と原本の画像を並べて表示させ、担当者は数字と社名だけを突き合わせます。そのうえで、支払いの実行という取り消せない工程の手前に承認を置く形です。金額が一定以下の少額な支払いについては承認を省くと決めておけば、確認の総量はさらに減らせます。
なお、経理は社内の取り決めが多い領域です。締め日の扱い、値引きの処理、取引先ごとの支払条件など、AIが知らない前提は指示文や参照資料として先に渡しておく必要があります。前提を渡さないまま読み取りだけを任せると、確認する側が毎回その差分を埋めることになり、結局は手作業に戻ってしまいます。
採用・人事｜AIが書類を要約し、合否は人が決める
採用では、応募書類の要約や質問案の作成までをAIに任せ、合否の判断は必ず人が行います。ここは効率より、判断の性質で線を引く領域です。
人の処遇や評価に関わる判断をAIに委ねると、なぜその結果になったのかを説明できなくなります。学習データの偏りが特定の属性に不利に働く可能性も拭えません。EUのAI法が雇用分野のAIを高リスクに位置づけ、人による監督を求めているのも同じ理由からです。
その一方で、書類の要点整理、日程調整、面接内容の文字起こしと要約は、AIに任せて差し支えありません。人が読む前の準備をAIが引き受け、人は候補者と向き合う時間に集中する。この分け方が、採用におけるHITLの形になります。
マーケティング・制作｜AIが下書きを作り、人が事実と表現を確認する
制作の領域では、AIが下書きを作り、人は事実関係と表現の2点を確認します。確認の観点を分けておくと、見落としが減ります。
事実関係の確認とは、書かれている数値や仕様、他社に関する記述に根拠があるかを見る作業です。表現の確認は、自社の言葉づかいに合っているか、誇大な言い回しになっていないかを見ます。AIに出力させる段階で参照した情報源を併記させておけば、前者の確認は大幅に短くなります。
公開という工程は、SNSであれ自社サイトであれ取り消しが効きません。そのため、下書きの生成と推敲はAIに任せつつ、公開の直前には人の承認を必ず挟む設計にします。予約投稿を使う場合も、日時の設定までをAIに任せ、予約の確定だけを人が行う形にすれば停止点は保てます。
公開されている企業の取り組み
実際に公表されている取り組みを見ると、工程を切り分けて人とAIの担当を分けている例が確認できます。ここでは2社を取り上げます。
ソフトバンクは2025年11月、Y!mobileのカスタマーサポートに音声対応の自律思考型AIを導入したと発表しました。同社が自動化の対象としたのは、暗証番号の照会という手順が定まった照会業務です。窓口全体を一度に無人化するのではなく、定型の照会から切り出した形になります。
ベネッセコーポレーションは、TMJ・Hmcommと共同で次世代型コンタクトセンタープロジェクトを開始し、人とAIで役割を分ける方針を掲げています。待ち時間の用件ヒアリングや応対履歴の要約はAIが担い、複雑な問い合わせには人が向き合う構成です。どちらも、業務を丸ごと自動化の対象にはしていない点が共通しています。
承認が形骸化する理由と、防ぐための4つの工夫
HITLを組み込んでも、承認が形だけになれば意味がありません。なぜ中身を見ない承認が生まれるのかという理由と、防ぐための工夫を4つ取り上げます。
自動化バイアス｜AIの出力が正しく見えてしまう
形骸化の根っこにあるのは、自動化バイアスと呼ばれる心理的な傾向です。機械が出した結果を、人が過度に信用してしまう現象を指します。
生成AIの出力は、体裁が整い、自信のある口調で書かれています。そのため読み手は、内容を検証する前に正しいものとして受け取りがちです。しかも自分で一から作っていないぶん、どこが怪しいかという当たりもつきません。確認が数回続けて問題なしだった後は、警戒のハードルがさらに下がります。
この傾向は個人の注意力の問題ではなく、人間に共通する認知の特性です。EUのAI法が人による監督の要件として、自動化バイアスへの自覚を持てるようにすることを挙げているのも、意識だけでは抗えないと考えられているためです。だからこそ、次に挙げる仕組みの側の工夫が要ります。
その工程を判断できる人を承認者にする
1つ目の工夫は、その工程の可否を実際に判断できる人を承認者に据えることです。役職の高さと、判断できるかどうかは別の話になります。
取引条件の妥当性は営業の担当者にしか分からず、仕訳の正しさは経理担当にしか見えません。形式的に部長が承認する形にすると、中身が分からないまま押印する工程が生まれます。承認者は、その出力の誤りに気づける人という基準で選んでください。役職で決めてしまうと、承認の列は増えるのに誤りを見つけられる確率は上がらない、という状態に陥ります。
あわせて、承認者が中身を判断できる材料を渡す設計も要ります。AIがその結論に至った根拠、参照した資料名、自信の度合いを出力に添えるだけで、判断の精度は変わるはずです。材料のない承認は、どれほど適任の人が担当しても勘に頼ることになります。
見るべき観点を書き出し、人による判断のブレを減らす
2つ目の工夫は、何を見て可否を決めるのかを言葉にして共有することです。観点が人によって違うと、同じ出力でも通る日と戻る日が生まれます。
例えば、見積書の承認なら、単価が価格表と一致しているか、値引率が決裁範囲に収まっているか、納期が生産の予定と矛盾していないかという3点に絞ります。この一覧があれば、担当が代わっても判断の水準はそろうはずです。さらに、観点を決める過程そのものが、ベテランの頭の中にある基準を表に出す作業になります。
この言語化は、AIへの指示を改善する材料としても使えます。人が見るべき観点は、裏を返せばAIが満たすべき条件です。新人に説明できない基準は、AIにも渡せないと考えてください。
全件確認をやめ、確認する条件を先に決める
3つ目の工夫は、すべてを見ようとせず、確認する対象を条件で絞ることです。全件確認は、一見すると安全に思えて、実際には形骸化を招きます。
人が集中して確認できる件数には限りがあります。1日に200件の下書きをすべて目視する運用では、数日で流し読みに変わるでしょう。それよりも、金額が10万円を超える、新規の取引先が含まれる、AIの自信度が低いといった条件に当てはまるものだけを確実に見るほうが、見落としは減ります。
条件から外れた案件は、サンプリングで定期的に点検します。例えば週に1度、20件を抜き出して誤りの有無を確かめる。この抜き取り結果が、条件の設定が妥当だったかを検証する材料にもなります。抜き取った中から誤りが続けて見つかるようなら、条件を緩めて確認の対象を広げる合図だと判断してください。
承認の記録を残し、後から見直せるようにする
4つ目の工夫は、誰がいつ何を承認し、どこを直したのかを記録に残すことです。記録は責任の所在を明確にするだけでなく、運用を改善する材料になります。
承認者と日時に加えて、差し戻した理由と修正した箇所まで残しておくと、後から傾向が読めます。特定の類型で修正が集中していれば、AIへの指示を直すべき箇所が特定できます。逆に半年間まったく差し戻しが出ていない工程は、承認を外す候補です。
とはいえ、記録のために新しいシステムを入れる必要はありません。承認の履歴が残るワークフローツールや、業務システムの更新履歴があれば十分に足ります。記録が複数の場所に散っている場合だけ、どれを正とするかを先に決めておいてください。大切なのは、記録を定期的に見返す時間を業務の中に置くことです。
AIエージェントに承認を組み込むときの注意点
AIが下書きを作るだけでなく、送信や登録まで自ら実行する段階になると、承認の置き方そのものが変わります。人が出力を見てから止めるのでは間に合わず、処理が走り出す前に止める場所を決めておかなければならないからです。
ここで効くのは、指示文に「送信する前に確認して」と書き添えることではありません。エージェントに渡すツールやアカウントの権限を絞る方法です。顧客データベースは参照のみ、下書きフォルダへの保存は可、メールの送信とマスタの更新は不可、というように、操作の可否を環境の側で固定します。指示は解釈しだいで揺れますが、権限のない操作はそもそも実行できません。
どの操作を止めるかの基準自体は、人が承認する場合と変わりません。やり直せない操作と、社外に届く操作の手前が停止点になります。違うのは、その線引きをエージェントが動き出す前に済ませておく点です。エージェントに渡しているのは個別の指示ではなく業務の手順そのものです。手順を書く時点で、どこで人に戻すかまで書き込んでおきます。あわせて、止めたときに何をしようとしているのかを平易な文で示させると、中身を見ないまま通す事態を避けられます。
権限の範囲は、導入の初期ほど狭く設定してください。運用しながら問題の起きない範囲を確かめ、少しずつ広げるほうが安全です。最初から広く与えると、何かあったときにどこまで戻せばよいかの基準を失います。
人をループから外してよいかを判断する基準
HITLは、いったん組み込んだら永久に人が見続ける仕組みではありません。精度が安定してきたら、全件の確認からサンプリングへ、さらに例外の検知だけへと、人の関わり方を段階的に軽くしていきます。
そもそも、冒頭で挙げた3つの型のどれを選ぶかも、この基準で決まります。判断の分かれ目は3つです。誤りが起きたときに後から気づく手段があるか。影響が社内に留まるか、それとも社外まで届くか。そして、間違いに気づいた後でやり直せるか。3つともに当てはまる工程は、Human on the Loopへ、さらにはHuman out of the Loopへ移していけます。
移行の判断材料になるのが、承認の記録です。例えば過去3か月で差し戻しが1件も出ていない類型があれば、全件確認をやめてサンプリングに切り替える候補になります。その際も、いきなり確認をゼロにはしません。週次の抜き取り点検と、異常を知らせる条件を残したうえで、人が見る件数だけを減らしていきます。
一方、どれだけ精度が上がっても人を外してはいけない工程もあります。採用の合否や人事評価のように人の処遇を決めるもの、金銭が動くもの、社外に出て取り消せないもの。これらは効率の問題ではなく、説明責任を誰が負うのかという問題だからです。AIの精度が99%になったとしても、残る1%の説明を求められるのは人になります。
このように考えると、HITLの設計とは人を減らす計画ではなく、人が見る場所を絞り込んでいく計画だと分かります。確認の総量は減らしながら、責任の所在だけは人に残す。この2つを両立させることが、運用を続けられるHITLの条件になります。
まとめ
Human in the Loop（HITL）は、AIの処理に人の確認や承認を組み込み、判断の責任を人が持ち続けるための設計です。人を増やす仕組みではなく、どの工程に人を残すかを決める考え方だといえます。
取りかかりとして有効なのは、AIに任せている業務を1つ選び、その工程を書き出してみることです。そのうえで、やり直せない操作と社外に出る操作に印を付け、その直前に1か所だけ承認を置きます。まずはここから始めてください。
運用を始めたら、確認1件あたりの時間と差し戻しの割合を2〜4週間記録します。差し戻しが起きない類型が見えてきたら、そこは承認の対象から外す。この絞り込みを繰り返すことで、確認の負担を増やさずにHITLを続けられます。
