BLOG

ヒューマン・イン・ザ・ループ(HITL)とは?人を置く位置で変わる運用設計

HITLのご相談でまず確認するのは、人を置く目的がAIを育てることなのか、日々の業務で誤りを外に出さないことなのかです。ここが曖昧なまま出力の確認だけを人に任せると、確認と差し戻しに時間がかかるわりに同じ誤りが出続けます。止めたい失敗を一つ決めてから、その手前に人を置く順番をおすすめします。

AIの処理の流れの途中に人の判断が差し込まれ、そのまま進む経路と人が確認してから進む経路に分かれている様子を示した図。

「human in the loop」という言葉に行き着く方の多くは、AIを業務に入れる直前か、入れてみたものの思うように任せきれない場面にいるのではないでしょうか。生成AIの出力は速い。ただ、そのまま外に出せるかと問われると、うなずけない。だから人が確認する。ここまでは誰でも思いつきます。

問題は、その「人が確認する」をどう設計するかです。全部を人が見れば安全ですが、それでは自動化した意味が薄れます。かといって確認を減らせば、誤りが素通りします。ヒューマン・イン・ザ・ループ(HITL)は、この二つの要求に設計で折り合いをつける考え方です。

本記事では、AIを使った記事制作を日常的に運用している立場から、HITLの意味を二つの文脈に分けて整理し、人をどこに置くと結果が変わるのか、導入の手順、そして運用が形だけになる原因までをお伝えします。

この記事でわかること
  • ヒューマン・イン・ザ・ループ(HITL)が指すものと、二つの使われ方
  • 人が関わる三つの型(HITL・HOTL・HOOTL)の違いと選び分け
  • 入口・途中・出口のどこに人を置くと差し戻しが減るのか
  • 導入の手順と、承認が形だけになるのを防ぐ方法

ヒューマン・イン・ザ・ループ(HITL)とは

ヒューマン・イン・ザ・ループ(Human in the Loop、略してHITL)とは、AIや自動化されたシステムの処理の流れ(ループ)のなかに、人間の判断を意図的に組み込む設計を指します。AIに全部任せるのでも、人が全部やるのでもなく、両者を一つの工程としてつなぐ考え方です。

定義そのものに大きな異論はありません。運用・監督・意思決定への人間の関与という点で、主要な解説はおおむね一致しています。

ヒューマン・イン・ザ・ループ(HITL)とは| IBM
ヒューマン・イン・ザ・ループ(HITL)とは、自動化されたシステムやAI駆動型システムの運用、監督、または意思決定に人間が積極的に関与するシステムやプロセスを指します。
🌐 www.ibm.com
外部リンク

それでも実務でHITLの話が噛み合わなくなるのは、同じ言葉が二つの違う目的で使われているからです。ここを分けないまま議論を始めると、精度の話をしている人と、承認フローの話をしている人が、同じ会議で別のことを検討する状態になります。

AIを育てるHITLと、業務を進めるHITL

一つは、AIモデルそのものを育てるための関与です。学習データに正解を付ける作業(アノテーション)、モデルが判断に迷ったデータだけを人に回す能動学習、人間による評価を学習に反映させるRLHF(人間のフィードバックによる強化学習)が代表例になります。目的はモデルの精度と傾向を変えることにあります。

人間参加型とは | Google Cloud
人間参加型(HITL)は、人間が AI システムのトレーニングに積極的に関与する設計アプローチです。Google Cloud で詳細をご確認ください。
🌐 cloud.google.com
外部リンク

もう一つは、日々の業務のなかでAIの出力を人が確認し、必要なら手を入れてから先へ進める関与です。請求書の読み取り結果を担当者が確かめる、AIが下書きした文面を編集者が見てから送る、といった運用が当てはまります。目的はモデルではなく、その日その案件の結果を正しくすることにあります。

観点

AIを育てるHITL

業務を進めるHITL

目的

モデルの精度・傾向を変える

目の前の出力を正しくする

人の役割

正解付け、評価、選別

確認、修正、承認

結果が出る時点

学習を経てから

その場で

負担が減るか

学習が進めば減らせる

設計しない限り減らない

現場で起きる混乱の多くは、この二つを分けずに「HITLをやろう」と決めてしまうところから始まります。とくに後者だけを走らせた場合は要注意です。出力を直すだけの運用では、人の作業量は減りません。半年後も同じ人数が同じ時間だけ確認している、という状態になりやすいところです。

※ 定義の整理にあたり、IBMおよびGoogle Cloudが公開するヒューマン・イン・ザ・ループの解説を参照しました。

人が関わる三つの型を見分ける

HITLの周辺には、ヒューマン・オン・ザ・ループ(HOTL)やヒューマン・アウト・オブ・ザ・ループ(HOOTL)という言葉もあります。違いは単純で、人がループの「中」にいるか、「上」から見ているか、そもそもいないかです。

人がループの中にいるHITL、外から監視するHOTL、関与しないHOOTLの位置の違いを示した図

言葉の定義だけでは選び分けができないため、判断に使う観点で並べます。

ヒューマン・イン・ザ・ループヒューマン・オン・ザ・ループヒューマン・アウト・オブ・ザ・ループ
人の位置処理の途中に入り、進める判断をする処理の外から監視し、必要時に介入する関与しない
処理の進み方人が承認するまで止まる止まらずに進む止まらずに進む
向く場面誤りの影響が大きい、件数が限られる件数が多く、速度が必要誤っても後から取り消せる
向かない場面大量処理、即時応答が必要な用途一件の誤りが致命的になる用途説明責任が問われる用途

三つは優劣ではなく使い分けです。ただし、生成AIの出力を外部に出す文章や金額の判断に使う場面では、いまのところHITLを選ぶのが妥当でしょう。誤りが起きたときに「誰がその出力を通したのか」を答えられる状態にしておく必要があるためです。

なぜいま、HITLが求められているのか

自動化そのものは新しい話ではありません。それでもHITLがあらためて語られるのは、生成AIの誤り方が、従来のシステムの誤り方と性質から違うからです。

従来のプログラムは、想定外の入力を受け取ると止まるかエラーを返しました。異常は目に見える形で現れたわけです。ところが生成AIは、知らないことを問われても、それらしい文章を返します。処理は止まらないまま、断定的な文章で誤りが出てきます。人が見なければ、誤りは誤りのまま次の工程へ進みます。

品質だけの問題でもありません。誤った出力が外部に出たとき、責任を負うのは組織です。EUのAI法(AI Act)には、リスクの高い用途のAIについて人間による監督を求める条項が置かれています。規制の細部はさておき、AIの判断に人の承認を通す設計は、説明責任を果たすための前提になりつつあります。

もう一つ、導入が進まない理由として大きいのが「精度が十分でないから本番に出せない」という判断です。ここは考え方を変えたほうが早い。精度が100%になるのを待っていると、いつまでも実運用に踏み出せません。HITLは、精度が足りない段階のAIを条件付きで実務に出す仕組みでもあります。

💡

HITLを「AIの精度が上がるまでの一時的な措置」とだけ捉えると、設計が雑になります。誤りの影響が大きい判断は、精度が上がっても人が関わり続けます。一時的に人が担う工程と、恒久的に人が引き受ける判断を、最初に分けておいてください。

関連記事:AIの倫理的問題とは?主な論点と企業がとるべき対策を事例で解説

HITLで得られるものと、割に合わなくなる条件

HITLの効果は、出力の精度が上がることだけではありません。実務で価値が出るのは、誤りが起きたときに経緯をたどれる状態が保たれる点にあります。一方で、人を置けば必ず良くなるわけでもない。導入前に、両方を並べて見ておく価値があります。

HITLで得られるもの
  • 誤りが外部に出る前に止まり、修正の履歴が残る
  • 人の判断が記録として蓄積され、次の学習や指示に反映できる
  • 誰が通したかを説明できるため、監査や問い合わせに答えやすい
  • AIが不得意な例外だけを人に寄せ、処理全体を止めずに済む
割に合わなくなる条件
  • 処理件数が増えるほど、確認する人の数と時間が比例して必要になる
  • 確認が単調な作業になると見落としが起き、かえって精度が下がる
  • 確認者ごとに判断がぶれ、出力の品質が安定しない
  • 人が扱う分だけ、機密情報に触れる範囲が広がる

注目したいのは、右側の項目の多くが「人を置いたこと」ではなく「置き方を決めていないこと」から生まれている点です。件数に比例して人手が必要になるのは、確認する対象を絞っていないため。判断がぶれるのは、判断基準が言語化されていないことに原因があります。となると、次に見ていく設計の話が、そのまま解決策になります。

成果を分けるのは、人をどこに置くか

HITLと聞くと、多くの方はAIが出力した後に人が確認する図を思い浮かべます。実際、それが最も一般的な形です。ただ、AIを使った記事制作を続けてきた実感として言えば、人を出口だけに置くと、差し戻しの回数が増えます

理由は単純です。出口で見つかる問題の多くは、出力の途中ではなく、入力の段階ですでに決まっているからです。前提となる情報が足りない、判断基準が渡っていない、参照すべき資料が指定されていない。こうした欠けは、AIがどれだけ賢くても埋まりません。出口の確認者は、その欠けの結果だけを見て「違う」と言うことになります。

AIの処理の入口・途中・出口のどこに人が関わるかを示した図

人を置ける場所は、大きく三つに分かれます。順に見ていきます。

入口に置く(前提と判断基準を渡す)

AIに処理を始めさせる前に、人が前提を整える関与です。対象データの範囲を決める、参照させる資料を指定する、してはいけないことを明示する。地味な工程ですが、ここに人の時間を寄せると、出口での修正が目に見えて減ります。

弊社の制作現場でも、記事の下書きをAIに任せる前に、扱う範囲と使ってよい情報源を人が固めます。この工程を省いて生成に進んだ回のほうが、結果として編集にかかる時間は長くなりました。前工程を飛ばした分は、後工程で返ってくると考えたほうが実態に近いはずです。

途中に置く(例外だけを人に回す)

処理の途中で、AIが判断に迷った案件や、あらかじめ決めた条件に当てはまる案件だけを人に回す関与です。金額が一定以上、過去に類例がない、AIの確信度が低い。こうした条件で振り分ければ、全件を人が見なくても、危うい案件だけを人の目に通せます。

条件の作り方には順序があります。最初から「確信度が低いものだけ」といった機械的な条件にすると、何を取りこぼしているのか分かりません。まずは人が全件を見て、実際に問題が出た案件の共通点を条件に変えていくほうが確実でしょう。

出口に置く(承認して次へ渡す)

最後に、出力を人が確認して先へ進める関与です。外部に出る文章、金銭の動く処理、人の評価に関わる判断は、ここを外せません。重要なのは、出口の役割を「直す場所」ではなく「通すかどうかを決める場所」に寄せることです。

出口の確認者が黙って手直しして通してしまうと、その修正内容はどこにも残りません。同じ誤りが翌日も翌週も出てきます。直すのであれば、何をどう直したかを記録し、入口の指示か設定に反映するところまでを一つの作業として扱ってください。

三つのうちどこか一つを選ぶ話ではありません。入口で減らし、途中で振り分け、出口で通す。この配分を決めることが、HITL設計の中身です。

人を置く位置を決めきれないまま、確認だけが増えていませんか

どの工程をAIに任せ、どこに人の判断を残すかは、業務の中身を見ないと決められません。Writers-hubでは、AIに任せる範囲と人が確認する条件を切り分けるところから、業務への組み込みをご支援しています。

関連記事:AI記事はペナルティの対象なのか?順位が落ちる本当の原因と安全な作り方

HITLを業務に組み込む手順

考え方が固まったら、実際の組み込みに移ります。大がかりな仕組みを先に作る必要はありません。止めたい失敗を一つ決めるところから始めるほうが、早く形になります。

1
STEP
止めたい失敗を一つ決める

「AIの品質を上げる」では設計に落ちません。事実と違う数値が外部資料に載る、社外秘の情報が回答に混ざる、といった具体的な失敗を一つ選びます。ここが決まると、人を置く位置は自動的に絞られます。

2
STEP
全件を人が確認する状態から始める

最初から抜き取り確認にすると、どんな誤りがどの頻度で出るのか分かりません。件数が多い場合は対象業務を絞ってでも、一定期間は全件を見る形にしてください。

3
STEP
誤りを種類で記録する

修正の有無だけでは次につながりません。数値の誤り、指示の読み落とし、表現の不適切さ、といった種類で分類し、件数を数えます。記録は表計算ソフト一枚で足ります。

4
STEP
種類ごとに、人を外すか指示に戻すかを決める

発生しなくなった種類は確認から外します。繰り返し出る種類は、確認を増やすのではなく、入口の指示やシステム側の制約に反映します。ここが手順の中心です。

5
STEP
確認の対象を条件で絞る

記録が溜まったら、問題が出た案件の共通点を条件に変え、その条件に当たるものだけを人に回します。全件確認から条件付き確認へ移るのは、この段階です。

肝心なのは四番目です。確認で見つけた誤りを、その場の修正で終わらせるか、指示や設定に反映するか。直した内容を指示に戻さない限り、同じ誤りは出続けます

確認で見つけた誤りを記録し指示に反映することで確認対象が絞られていく循環の図

前者を続ける限り、人の負担は減りません。逆に後者を続けると、確認する項目は少しずつ減っていきます。HITLが割に合う運用になるかどうかは、この一点で分かれると考えています。

運用で形だけにならないために

設計を整えても、数か月経つと確認が形式的になることがあります。原因はいくつかありますが、現場で繰り返し見るのは次のような状態です。

  • 確認者が全件に同じ密度で目を通し、後半になるほど注意が続かない
  • 「特に問題なし」で承認する回が続き、承認そのものが手続きになっている
  • 確認者に修正の権限だけがあり、AIの指示や設定を変える権限がない
  • 誤りを見つけても、報告先と反映先が決まっていない
  • 確認にかかった時間だけが管理され、何を防げたかは測られていない

承認が形だけになった時点で、HITLは機能していません。人は置かれているのに誤りが通る。この状態は、人を置いていない場合より危うい面があります。承認済みという記録が残るため、後の検証で疑われにくくなるからです。

防ぎ方は難しくありません。確認の対象を絞って一件あたりの時間を確保すること、確認者に指示や設定を変える権限を渡すこと、そして防げた誤りの件数を記録すること。三つのうち最も効果があるのは二つ目でしょう。見つけた人がその場で直せる立場にいるかどうかで、改善が進む速さは変わります。

経営者経営者

確認する人の負担が増えるばかりで、AIを入れた効果が見えないという声が社内から出ています。どう説明すればよいでしょうか。

Writers-hub編集部Writers-hub
編集部

負担が減らないのは、確認の結果が次の生成に反映されていない場合がほとんどです。見つかった誤りを種類ごとに数え、そのうち何種類を指示や設定の変更で止められたかを記録してみてください。件数が減っていく経過が見えると、社内での説明も具体的になります。記録がないままだと、確認は終わりの見えない作業として扱われてしまいます。

AIを使う人が、自分で指示を直せる状態まで持っていきたい方へ

確認する人が指示や設定を変えられるようになると、同じ誤りの再発は目に見えて減ります。Writers-hubでは、AIの使い方の研修から、社内で改善を続けられる体制づくりまでをご支援しています。

関連記事:AIの情報漏洩はなぜ起こる?事例と原因、企業が取るべき対策

ヒューマン・イン・ザ・ループについてよくある質問

最後に、導入前によくいただく質問をまとめます。

ヒューマン・イン・ザ・ループとヒューマン・オン・ザ・ループは、どちらを選ぶべきですか。

一件の誤りがどこまで影響するかで決めます。外部に出る文章や金銭の動く処理のように、誤ってから取り消しにくい業務は、人が承認するまで進めないHITLが向きます。処理件数が多く、後から修正できる業務であれば、監視にとどめるHOTLで足りる場合が多いです。

HITLを入れると、結局コストは増えるのでしょうか。

導入直後は増えます。全件を人が確認する期間があるためです。その後に減らせるかどうかは、確認で見つけた誤りを指示や設定に反映する工程があるかで決まります。反映しないまま確認だけを続けると、件数に比例して人手が必要になります。

小さな組織でも取り組めますか。

取り組めます。対象業務を一つに絞りやすい分、むしろ進めやすい面もあるでしょう。専用のツールを用意しなくても、誤りの種類と件数を記録する表が一枚あれば始められます。

どの業務から始めるのが無難ですか。

誤りが起きたときの影響が中程度で、件数が数えられる業務が向きます。影響が小さすぎると改善の必要性が共有されず、大きすぎると試す前に止まります。社内向けの文書作成や、既存データの分類あたりが着手しやすいでしょう。

まとめ

ヒューマン・イン・ザ・ループは、AIに人を添える話ではなく、どの判断を人が引き受けるかを決める設計です。要点は三つあります。

一つ目は、AIを育てる関与と業務を進める関与を分けること。二つ目は、人を出口だけでなく入口にも置き、前提と判断基準を渡すこと。三つ目は、確認で見つけた誤りを指示に戻し、確認の対象を条件で絞っていくこと。三つが揃うと、人の負担は運用のなかで下がっていきます。

逆に、確認する人を増やすだけの対応は長続きしません。人手が足りなくなるか、承認が形式的になるかのどちらかに落ち着きます。最初に決めるべきは、人を何人置くかではなく、どの判断だけは人が引き受けるかです。

合同会社Writers-hubは、AIを使った記事制作と業務の自動化を、人の確認をどこに残すかまで含めて設計してきました。AIに任せる範囲と人が引き受ける判断の線引きに迷われている場合は、いまの工程をお聞かせいただくところからご相談を承ります。

自社の業務のどこに人の判断を残すべきか、整理するところから

どの工程をAIに任せ、どこに人の確認を残すかは、業務の内容と誤りの影響範囲によって変わります。まずは現状の進め方をお聞かせください。何を自動化でき、どこに人を置くべきかを整理してお伝えします。

この記事を書いた人

米山拓真

米山拓真

合同会社Writers-hub 代表社員

滋賀県立大学工学研究科の修士課程を修了後、大手制作会社の編集部を経て2019年にWebライターとして独立。2020年に記事制作を手順化した「ハブ式SEOライティングメソッド」を開発し、これまでに200人以上のライターを育成しました。2022年3月に合同会社Writers-hubを設立し、会社として累計8,000記事以上のSEO記事制作に携わっています。2024年にAIライティングシステム「一気通貫Pro」、2025年から書き手の文体を再現するAI編集者「Edico」を開発。このブログでは、クライアント案件と自社サイトで実際に試したことを書いています。

記事一覧に戻る