HITL（ヒューマン・イン・ザ・ループ）とは——AIに任せる業務の「どこで人が見るか」を決める考え方

AIエージェントの製品説明、ベンダーの提案資料、国のAI事業者ガイドライン。こうした資料を読んでいると、「HITL」という言葉がよく出てきます。「HITLを前提に設計しています」「HITLが重要です」と言われて、なんとなくうなずいたことはないでしょうか。

HITLは、ひとことで言うとAIの作業の途中に、人間がチェックするポイントを置くことです。この記事では、似た言葉のHOTLとの違いと、「自分の業務のどこに人のチェックを置けばいいか」の決め方を、弊社で実際に使っている社内アプリを例に説明します。

HITLとは——AIの仕事に「人の承認」を挟むこと

HITLは Human in the Loop の略で、「ヒューマン・イン・ザ・ループ」と読みます。Loopは処理の流れのこと。人間（Human）が、その流れの中（in）にいる、という意味です。

身近な例でいえば、新人が書いたメールを、上司が目を通してから送る流れです。この新人をAIに置き換えると、HITLになります。

AIが下書きする → 人が確認・修正・承認する → 実行する

ポイントは、人が承認しないと次に進まないことです。AIエージェントに作業を頼むと、ファイルの削除やメールの送信の前に「この操作を許可しますか？」と聞いてくることがあります。あれもHITLです。

誤解されやすいのですが、HITLは「AIが信用できないから、人が全部見張る」という後ろ向きの話ではありません。人が止められる場所があるから、その手前までは安心してAIに任せられます。HITLは、AIに任せる範囲を広げるための仕組みです。

HITLとHOTL——似た2つの言葉を比べる

HITLとセットでよく出てくるのが、HOTL（Human on the Loop、ヒューマン・オン・ザ・ループ）です。inとonの1文字違いですが、人の関わり方が違います。

	HITL（Human in the Loop）	HOTL（Human on the Loop）
人の位置	流れの中	流れの上
進み方	人が承認してから、AIの結果が使われる	AIが先に実行し、人は見張っていて、おかしければ止める・直す
たとえ	マニュアル車の運転	高速道路の自動運転支援（ハンドルに手を添えて見張る）
向いている業務	間違いが社外に出る、または取り返しがつかないもの	後から直せるが、放っておくと困る人が出るもの
弱点	人が確認するまで先に進まない	間違いが、一度は流れてしまう

見分け方は1つです。人の承認を待ってから実行するならHITL、先に実行してから人が見るならHOTLです。

HITLの例は、弊社の見積書アプリです。会社のURLと人数を入れると、助成金の試算まで入った見積書を作ってくれる社内アプリで、人が内容を確認して送信しない限り、見積書は顧客に届きません（詳しくは見積書づくりを丸ごと自動化——GASと生成AIで作った社内業務アプリの事例）。

HOTLの例として、問い合わせメールの自動振り分けを考えてみます。顧客からの問い合わせをAIが読んで、営業・サポート・経理などの担当部署に振り分けます。振り分けは人の承認を待たずに進みます。そのかわり、窓口の担当者が1日に何度か振り分けの一覧を見て、間違っていれば振り分け直します。

HOTLで大事なのは、「間違えても誰かが気づくだろう」で済ませないことです。別の部署に届いた問い合わせは「うちの担当じゃない」と放置されやすく、誰も気づかないまま顧客を待たせてしまいます。誰が見張るのか、どうやって直すのかを決めておく。そこまでしてはじめて、HOTLと呼べます。

参考：HOOTL（Human out of the Loop）

人がまったく関わらない、完全自動の形をHOOTL（ヒューマン・アウト・オブ・ザ・ループ）と呼ぶこともあります。自分の受信箱の自動振り分けやスパムフィルタがその例です。間違えても使う本人がすぐ気づいて直せる業務なら、これで十分な場合もあります。この記事では、人の関わり方を設計するHITLとHOTLに絞って説明します。

なぜ今、この言葉をよく見るのか

AIが「実行する」ようになった

これまでのAIは文章を提案するだけで、それを使うかどうかは人が決めていました。今はAIエージェントが、メールを送る、ファイルを消す、システムに入力するといった操作まで自分で行います。提案なら人が読んだ時点で止められますが、実行されてしまうと止められません。どこで人が止めるかを、あらかじめ決めておく必要が出てきました。

もっともらしい間違いはなくならない

AIは、事実と違うことを自信ありげに答えることがあります（ハルシネーション）。精度は上がり続けていますが、ゼロにはなりません。

ルールの側も求め始めた

総務省と経済産業省が2026年3月に公表した「AI事業者ガイドライン（第1.2版）」は、AIエージェントが外部に影響を与える操作をする前に、人が確認・承認する仕組みを設けることを求めています。EUのAI法も、リスクの高いAIについて、そのリスクや使われ方に見合った人間による監視を求めています。

どこで人が見るべき？——2つの問いで決める

では、自分の業務はHITLとHOTLのどちらにすればいいのか。次の2つの問いに、順番に答えてみてください。

問1　間違いがそのまま社外に出る、または取り返しがつかない？

• はい → HITL：出る前に人が承認する（例：見積書の送信）
• いいえ → 問2へ

問2　間違いを放っておくと、誰も気づかないおそれがある？

• はい → HOTL：見張り役と、直す手段を決める（例：問い合わせメールの自動振り分け）
• いいえ → 人の関所はいらない：使う本人がすぐ気づいて直せる（例：自分の受信箱の振り分け）

問1は、「間違いが誰に届くか」と「取り返しがつくか」をまとめた問いです。この2つは、人の関わり方を決めるときによく使われる判断軸です。ただ、社外に届いたものは、たいてい取り返しがつきません。顧客に送った見積書は、訂正はできても、送らなかったことにはできません。そこで1つの問いにまとめました。

問2は、その間違いに誰かが気づけるかを確かめる問いです。自分の受信箱の振り分けを間違えても、自分ですぐ気づきます。一方、別の部署に振り分けた問い合わせは、誰も気づかないかもしれません。気づく人がいないなら、見張る役を決めてHOTLにします。

あわせて、2つのことを覚えておいてください。

• 人が見るなら、その場で間違いに気づける状態にする。「承認しますか？」とだけ聞かれても、判断材料がなければ、人はボタンを押すしかありません。確認が形だけになってしまいます。
• 最初は厚めに見て、慣れたら緩めてよい。導入したばかりの業務は、どこで間違えるかがまだ分かりません。最初はHITLで見ておき、問題が出なければHOTLに移す、という進め方もできます。

事例で見る——見積書アプリの「3か所の関所」

ここからは、弊社の見積書アプリを例に、HITLを実際にどう設計したかを見ていきます。

このアプリは、見積書1通のために毎回やっていた6つの作業を、ほぼ自動にしたものです。ただし、6つすべてに人のチェックを入れているわけではありません。

工程	誰が処理するか	間違えたら	人のチェック
① 公式サイトから社名・住所・資本金などを拾う	ページを取ってくるのはプログラム、項目を抜き出すのはAI	金額や宛名に響く	確認画面で確認する
② 業種を1,272の分類から選ぶ	AI（選んだ理由も出させる）	1人あたりの実質負担が88,000円か194,000円かが変わる	確認画面で確認する
③ 法人番号と登記上の住所を照合する	プログラム	宛名に響く	確認画面にバッジで表示する
④ 中小企業か大企業かを判定する	プログラム	金額に響く	判定できないときだけ人が選ぶ
⑤ 助成額を計算し、備考の文章を組み立てる	プログラムとテンプレート	—	置かない
⑥ 請求書システムへの入力・PDF作成・送付	プログラムは下書きまで	社外に届き、取り消せない	人が送信する

人が入るのは、確認画面での確認、見積書が2通できたときの選択、そして送信の3か所だけです。

HITLは、全部の工程を人が見ることではありません。間違いが社外に出る直前に、人が承認しないと先に進めない関所を置くことです。見積書アプリでは、AIが調べた内容が、顧客に渡る金額や文書に変わる直前に関所を置きました。

⑤の計算に人を置いていないのは、AIを使っておらず、入力が同じなら毎回同じ結果になる処理だからです。ここに確認画面を置いても、人は中身を見ずに「はい」を押すだけになります。

関所を形だけにしない工夫

• 値の出どころを見せる。確認画面では、それぞれの値に「どこから取ってきた値か」のバッジを付け、公式サイトの原文と該当ページへのリンクを並べています。
• AIの判断理由を見せる。業種には、AIが選んだ理由を30字以内で添えています。結果だけでなく、なぜそう判断したかを見て納得できます。
• 迷ったらAIに決めさせない。資本金も従業員数も分からず中小企業か判定できないときは、推測で1通作らず、中小企業版と大企業版の2通を作ります。どちらを送るかは人が選びます。
• 送信はアプリにさせない。アプリが作るのは下書きまでです。「誰かが確認するはず」という運用ルールに頼らず、仕組みとして止まるようにしています。
• 関所を増やしすぎない。確認を求める回数が増えるほど、人は確認しなくなります。人にしか判断できないことと、間違えると社外に出てしまうことに絞りました。

AIに任せる範囲を狭めるのも、設計のうち

開発の途中で、AIにURLを渡して「このページを読んで会社情報を教えて」と頼んだことがあります。するとAIはページを読みにいかないまま、実在しない会社の情報を、社名から資本金までそろえて返してきました。

そこで、ページを取ってくるのはプログラムの仕事にして、AIは渡された文章から項目を抜き出すだけにしました。AIの担当を狭めると、間違いが起きる場所も限られ、人が確認する負担も軽くなります。どこに人を置くかを考える前に、AIに何をさせるかを絞る。これもHITL設計の一部です。

この事例から持ち帰る判断基準

やり直せない場所の手前にだけ、人を置く。迷ったら、AIに決めさせず人に渡す。

※金額は人材開発支援助成金「事業展開等リスキリング支援コース」で、弊社研修（実訓練時間12時間・単価400,000円）を受講する場合の試算です。助成率や上限額はコースや年度によって変わり、受給できるかどうかは管轄の労働局の判断によります。

業務シーン別の早見表

よくある業務を、2つの問いに当てはめるとこうなります。

業務	問1 社外に出る／取り返しがつかない	問2 誰も気づかないおそれ	人の関わり方
顧客へのメール・見積書・提案書	はい	—	HITL：送信前に承認
AIエージェントによる削除・送金・外部送信	はい	—	HITL：実行直前に承認
問い合わせメールの自動振り分け	いいえ	はい	HOTL：窓口担当が一覧を見張る
ナレッジの自動収集（社内でしか使わず、使う人が出典を確かめる）	いいえ	いいえ	関所なし（HOOTL）
自分用の下書き・メモ	いいえ	いいえ	関所なし：本人がその場で確認
自分の受信箱の自動振り分け	いいえ	いいえ	関所なし（HOOTL）

落とし穴——「人が見ている」のに役に立たないパターン

• ハンコを押すだけになる。AIの出力に慣れると、中身を読まずに承認するようになります（ラバースタンプ化と呼ばれます）。確認する場所を絞り、1回ごとの確認に意味を持たせます。
• 判断材料がない。結論だけ見せて「承認しますか？」と聞いても、人は判断できません。根拠や元データを一緒に見せます。
• 「誰かが見るはず」で終わっている。HITLなら、仕組みとして処理を止めます。HOTLなら、見張り役を名指しで決めます。見張り役のいないHOTLは、ただの放置です。
• 全部を見ようとする。全件を細かく確認していると、AIで速くなった分が人の確認で消えてしまいます。
• 社内用のものを社外に流用する。自分用のメモやAIの下書きを、確認しないまま社外向けの資料に貼ると、関所をすり抜けてしまいます。

まとめ——人を置く場所を、2つの問いで決める

• HITLは、AIの流れの中に人の関所を置くこと。HOTLは、先に流して見張ること
• どちらにするかは、「社外に出る、または取り返しがつかないか」「誰も気づかないおそれがあるか」の2つの問いで決める
• 関所は全部の工程に置くのではなく、間違いが社外に出る直前に置く

まずは、いまAIを使っている業務を1つ選んで、2つの問いに答えてみてください。問1が「はい」なのに人の承認が入っていなければ、そこに確認を1つ入れる。それがHITLの最初の一歩です。

参考・出典

• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」
• EU AI Act Article 14: Human Oversight
• 見積書づくりを丸ごと自動化——GASと生成AIで作った社内業務アプリの事例