Human-in-the-loopとは？AIの処理に人の承認を挟む仕組みと、どこに挟むかの決め方

社内でAIの自動化を組んでいると、「ここは人が見なくて大丈夫か」と手が止まる場面があります。

メールの送信、請求データの更新、社外向け文書の公開。AIに任せきってよいのか迷う操作は、業務のあちこちにあります。

こうした場面で出てくるのが「Human-in-the-loop」、略してHITLという言葉です。ただ、資料を読んでも「人が確認する」以上のことがつかみにくいかもしれません。

この記事では、Human-in-the-loopが実際にどういう仕組みなのか、どこに確認を挟むのか、承認フローで何を決めるのかを解説します。

Human-in-the-loopとは、AIの処理を途中で止めて人が判断する仕組みのこと

Human-in-the-loopとは、AIの処理を最後まで自動で走らせず、途中で止めて人の判断を挟む仕組みのことです。日本語では「人間による確認」と訳されます。

止まったあとに人がとれる行動は、大きく3つです。そのまま承認して先へ進める、内容を直してから進める、却下して前の工程へ戻す、のいずれかです。

大事なのは、確認する人の心構えではなく、処理の流れそのものに停止点が組み込まれているという点です。

ワークフロー作成ツールのDifyには、この停止点を置くための「Human Input」というノードがあります。公式ドキュメントによると、このノードはワークフローを一時停止し、確認用のフォームを相手に届けます。

受け取った人は内容を見て、あらかじめ用意されたボタンを押します。押したボタンによって、その先どの経路へ進むかが変わります。

AIエージェントのように、AIが自分で次の行動を決めて実行する使い方では、この停止点をどこに置くかが設計の論点になります。

出力を読んで人が使うだけなら、確認は読む人の手元にあります。AIが自分でメールを送ったりファイルを書き換えたりするなら、実行の前に止める場所をこちらで決めておく必要があります。

どこに人の確認を挟むか、判断材料は4つある

すべての処理に確認を挟むと、自動化した意味がなくなります。かといって、どこにも挟まないと事故が起きたときに止められません。

今回参照した資料に出てくる条件を、この記事では4種類に整理します。出典側がこの4分類を定めているわけではありません。

取り消しにくい操作の直前

1つ目は、やり直しがきかない操作です。

OpenAIのエージェント開発者向けドキュメントでは、承認を要求する対象の例として、取り消し処理、編集、シェルコマンド、機微なMCP操作が挙げられています。

いずれも、実行したあとで元に戻すのが難しい操作です。自社の業務でも、送信・公開・支払い・削除・権限変更あたりが同じ性質を持ちます。

AIが自信を持てていない出力

2つ目は、AIの出力そのものが不確かなときです。

AWSのAmazon Augmented AI（A2I）のドキュメントには、確信度の低い予測を人のレビューへ回す使い方が書かれています。スキャンした申込書からの情報抽出のように、画質や手書きのせいで読み取りが怪しくなる例が挙がっています。

確信度をスコアで出せる仕組みなら、しきい値を下回ったものだけを人へ回す形にできます。全件ではなく、怪しいものだけを見る構成です。

ただし、生成AIの文章のように確信度が数値で出ない場合もあります。もっともらしい誤りが混ざるハルシネーションは、スコアでは弾けません。

権利や公平性に関わる判断

3つ目は、人の権利や評価に影響する判断です。

総務省と経済産業省のAI事業者ガイドライン（第1.2版）は、公平性の項目で、AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を介在させる利用を検討するよう示しています。

これは法的な義務ではなく、事業者が自主的に取り組む指針として書かれています。

EUのAI法（Regulation (EU) 2024/1689）は、もう一段はっきりしています。第14条は、高リスクAIシステムについて、使用中に人が実効的に監督できるよう設計・開発することを義務づけています。

対象は高リスクに分類されたシステムに限られます。すべてのAI利用にこの義務がかかるわけではありません。

自社に適用されるかどうかは、所在地だけでは決まりません。提供者なのか導入者なのかという立場と、EUでの提供や利用とどう関わるかによって変わるため、個別の確認が要ります。

何も起きていない処理も、抜き取りで見る

4つ目は、問題が見つかっていない処理の抜き取り確認です。

先ほどのA2Iのドキュメントには、確信度による振り分けと並んで、無作為に抜き出したサンプルを人のレビューへ回す使い方も書かれています。

なお、A2Iは新規の受付を終了したサービスです。ここで参考にしているのは製品そのものではなく、低確信度だけ人へ回す、無作為抽出で継続的に見る、という2つの条件の立て方です。

承認フローで決めるのは「誰に・何を・どの選択肢で・いつまでに」

挟む場所が決まっても、承認フローはまだ作れません。止めたあとの段取りを決める必要があります。

DifyのHuman Inputノードの設定項目は、この段取りを4つに分けています。届け方、フォームの内容、選択肢のボタン、時間切れの扱いです。

1製品の仕様ですが、自社で承認フローを組むときに決めるべきことの一覧としても使えます。

誰に届けるか

Difyの届け方は2種類あります。アプリの画面にそのまま出す方法と、メールで送る方法です。

公式ドキュメントは、操作している本人がその場で答えるなら画面、操作する人と決める人が別ならメール、という使い分けを説明しています。

社内の承認では、この2つが混ざりがちです。誰が押すのかを先に決めないと、止まったまま誰も気づかない状態になります。

何を見せるか

承認する人に、AIの出力だけを見せても判断できません。

AI事業者ガイドラインの脚注には、承認する際に人間自身が承認の理由や根拠を独自に考えてから承認すべきだ、という提案が紹介されています。

そのためには、出力だけでは足りません。元になった入力、参照した情報、これから実行される操作の中身を見せることを、この記事では検討の出発点として挙げます。

どの選択肢を出すか

「承認」と「却下」の2択で足りるとは限りません。

DifyのHuman Inputノードでは、押したボタンごとに別の経路へ進みます。公式ドキュメントの例では、投稿へ進むボタンと、LLMのノードへ戻して作り直させるボタンが挙げられています。

差し戻して作り直させるのか、人が直して進めるのか。この違いを選択肢として用意しておくと、却下したあとに作業が宙に浮きません。

返事が来なかったらどうするか

見落とされやすいのが、時間切れの扱いです。

Difyの場合、リクエストの有効期限は既定で3日です。期限内に誰も応答しなければ、ノードの時間切れ用の経路へ進みます。その経路がつながっていなければ、そこで終了します。

自社で組むときも、無応答を承認扱いにするのか、却下扱いにするのか、別の人へ回すのかを決めておく必要があります。決めていないと、忙しい時期に黙って素通りします。

承認したあと、処理はどこから再開するか

止めた処理を続きから動かす方法も、設計に含まれます。

OpenAIの開発者向けドキュメントによると、承認が必要なツール呼び出しは実行されずに中断として記録され、結果には中断の一覧と再開可能な状態が返ります。

承認または却下したあとは、新しい会話を始めるのではなく、同じ実行をその状態から再開します。レビューに時間がかかりそうなら状態を保存しておき、あとで再開しても同じ実行のままだと書かれています。

承認を挟むと処理が最初からやり直しになる作りでは、承認者の負担より先に、システム側が実務に耐えません。

人を挟んでも、承認が形だけになることがある

停止点を置き、承認フローを整えても、それで安心とは言えません。

AI事業者ガイドラインは、自動化バイアスを、人間の判断や意思決定において自動化されたシステムや技術への過度の信頼や依存が生じる現象だと説明しています。

同じガイドラインは、人間の判断を介在させる際に、その判断が自動化バイアスに左右されないような対策を講じるべきだとしています。

EUのAI法第14条も、監督を任された人が自動化バイアスの傾向を自覚できるようにすることを求めています。特に、人が下す判断のために情報や推奨を提供する高リスクAIシステムで注意すべきだと書かれています。

対策として資料に挙がっているのは、AIの欠点を含む特性を理解するための訓練を受けることと、承認する理由や根拠を自分で考えてから承認することです。

同じ第14条は、高リスクAIシステムを監督する人が出力を無視したり、上書きしたり、取り消したりできること、停止の手続きで安全な状態に止められることも求めています。

承認ボタンしかない画面を見ただけでは、これらの手当てがあるかどうかは分かりません。介入や停止がどこで担保されているかは、画面単体ではなくシステム全体で確認することになります。

なお第14条には、生体識別のシステムについて、必要な能力と訓練と権限を持つ2人以上による別々の確認を求める規定もあります。

これはEUのAI法の付属書IIIに挙がった特定の用途に対する上乗せで、法執行や国境管理などには例外があります。AI全般に二人確認が要るという話ではありません。

確認を増やしすぎると、かえって守られなくなる

心配な操作を洗い出していくと、停止点はいくらでも増やせます。

EUのAI法第14条は、高リスクAIシステムへの監督の手当てを、そのシステムのリスク、自律性の水準、利用される文脈に見合ったものにするよう求めています。

自動化か人の確認かという二択ではなく、重さを合わせる話として書かれています。

承認が多すぎると、押す側は中身を読まずに通すようになります。前の節で触れた自動化バイアスは、ここでも効いてきます。

もう1つの副作用は、正規の経路が使われなくなることです。承認待ちが長い社内ツールを避けて手元の無料ツールで済ませてしまえば、記録も残りません。この状態はシャドーAIと呼ばれます。

出発点として考えやすいのは、取り消しにくい操作から順に停止点を置き、事故も差し戻しも起きていない箇所は抜き取り確認へ落とす進め方です。

会社全体として誰が決め、誰が確認し、誰が止めるのかという体制づくりは、AIガバナンスの側の話になります。Human-in-the-loopは、その体制を個々の処理の中に落とし込んだ形だと考えると、位置づけがはっきりします。

Human-in-the-loopについてよくある質問

Human-in-the-loopとAIガバナンスは何が違いますか

AIガバナンスは、会社としてAIをどう使うかを決め、守られているかを確認する体制の話です。

Human-in-the-loopは、個別の処理の流れの中で、どこで止めて誰が判断するかという設計の話です。体制を実際の処理に落とし込む部分にあたります。

承認を挟めば、AIの間違いは防げますか

防ぎきれません。承認する人が中身を読まずに通してしまう自動化バイアスが起きるためです。

判断の根拠を見せること、無視や取り消しができるようにすること、訓練を行うこと。これらとセットで考える必要があります。

法律で人の確認が義務づけられていますか

EUのAI法は、高リスクAIシステムについて、人が実効的に監督できる設計を義務づけています。対象は高リスクに分類されたシステムで、AI全般ではありません。

自社に適用されるかどうかは、所在地だけでは決まりません。提供者か導入者かという立場と、EUでの提供や利用との関わり方によって変わります。

日本では、総務省と経済産業省のAI事業者ガイドラインが人間の判断を介在させる検討を促していますが、これは自主的な取組の指針です。自社が守るべき規制は、業界と提供先によって変わります。

全部の処理に確認を挟むべきですか

そうすると自動化の効果が失われ、承認も形だけになりやすくなります。

EUのAI法は、高リスクAIシステムへの監督の手当てを、リスク、自律性の水準、利用文脈に見合わせるよう求めています。取り消しにくい操作から順に挟み、それ以外は抜き取り確認へ落とす形が出発点になります。

まとめ

Human-in-the-loopとは、AIの処理を途中で止めて、人が承認・修正・却下してから先へ進める仕組みのことです。心構えではなく、停止点を処理に組み込む設計を指します。

挟む場所を決める判断材料は4つあります。取り消しにくい操作、AIが自信を持てていない出力、権利や公平性に関わる判断、そして問題が見つかっていない処理の抜き取りです。

承認フローでは、誰に届けるか、何を見せるか、どの選択肢を出すか、返事が来なかったらどうするか、承認後にどこから再開するかを決めます。

ただし、人を挟めば安心にはなりません。自動化バイアスで承認が形だけになるため、判断の根拠を見せることと、無視や取り消しができることが要ります。

EUのAI法が高リスクAIシステムに求めているのも、この実効的に監督できる状態です。適用されるかどうかは、提供者か導入者かという立場と、EUでの提供や利用との関わり方によって変わります。

日本のAI事業者ガイドラインは、公平性の観点から人間の判断を介在させる検討を、自主的な取組として促しています。

自社の業務のどこに停止点を置き、誰が承認する形にするかを整理したい場合は、お問い合わせはこちらからご相談ください。

この記事の出典

• AI事業者ガイドライン（第1.2版）（総務省・経済産業省、令和8年3月31日公表）
• Regulation (EU) 2024/1689（EU AI法）第14条 Human oversight（EU官報、2024年7月12日掲載）
• Human Input｜Dify Docs（Dify公式ドキュメント、2026年9月12日確認）
• Guardrails and human review｜OpenAI（OpenAI公式開発者ドキュメント、2026年9月12日確認）
• Using Amazon Augmented AI for Human Review（AWS公式ドキュメント、2026年9月12日確認）