ヒューマンインザループ（HITL）とは？AIの承認フローと実装の考え方

ヒューマンインザループ（HITL）とは、AIや自動処理の途中に、人の判断や修正を組み込む考え方です。業務で使うときは、AIが作った案を人が確認し、承認した内容だけを次の処理へ進める形が一つの使い方になります。

ただし、承認ボタンを置くだけでは、何を承認したかが曖昧になります。本文を確認した後に宛先が変わった場合、その承認で配信してよいのでしょうか。この記事ではHITLの意味と関与の仕方を整理し、架空の社内告知を題材に、承認の対象・有効期限・再承認を具体化します。

ヒューマンインザループは、学習と業務運用の両方で使う考え方

HITLは、Human-in-the-Loopの略です。IBMの解説では、自動化された処理の操作や判断に人が関わる仕組みとして説明されています。AIの学習に使うデータへ正解ラベルを付けることや、出力を人が評価することも、その関わり方に含まれます。

会社で導入するときは、次の二つを分けると目的が明確になります。

• 学習に人の評価を使う：人が付けたラベルや評価を、モデルを訓練する工程へ渡す。
• 業務の実行を人が判断する：AIが作った通知案や変更案を確認し、その一件を進めるか決める。

今回扱うのは後者です。通知案を修正して承認したことと、その修正を使ってモデルを再学習させたことは別の工程です。「担当者が承認するほど、AIが自動で学習する」という前提にはせず、改善に使う記録と反映方法を別に決めます。

HITLとヒューマンオンザループの違いは、人が関与するタイミング

AIエージェントの運用では、HITLに加えて、Human-on-the-Loop（HOTL）やHuman-out-of-the-Loopという言葉も使われます。Atlassianの整理をもとに、実行時の関与を比べると次のようになります。

関与の形	処理が進む条件	人の役割
HITL	決めた箇所で止まり、人の判断を受けて進む	実行前に承認・修正する
HOTL	自動で進み、人が稼働中の状態を監視する	必要なときに介入・停止する
Human-out-of-the-Loop	個々の処理では人の判断を待たず、常時監視も前提にしない	事後のログ確認や点検を設計する

たとえば、社内告知を人の確認後に配信するのは事前承認のHITLです。配信中の状況を監視して異常時に止める方法とは、止められるタイミングが異なります。配信後のログを週に一度読むだけなら、配信前の確認にはなりません。

用語を選ぶ前に、「誰の判断が届くまで、どの操作を止めるか」を書いてください。送信先の間違いなど、実行後に取り戻しにくい問題がある作業では、その操作の直前を確認点の候補にします。すべての文章生成のたびに承認を求める必要があるかは、作業ごとに判断します。

承認対象は、本文・宛先・添付・根拠をひとまとまりにする

ここからはMakeAI独自の設計例です。架空の会社で、AIが「社内ポータルの操作説明会」の告知案を作る場面を考えます。AIは下書きを用意し、業務支援部の担当者が内容を確認してから配信へ進める運用です。

承認画面に「告知を送ってよいですか」とだけ表示しても、判断材料が足りません。何が、どこへ、どの資料に基づいて送られるかを、同じ画面で確認できるようにします。

確認するもの	今回の架空例
依頼番号と版	告知依頼N-01、第1版
実行する操作	社内ポータルの対象部署へ告知を配信する
本文の全文	「社内ポータルの操作説明会は10月20日14時に開催します。」
宛先・公開範囲	業務支援部
添付資料	操作案内v1の、実際に配布するファイル
根拠資料	説明会要領v1の日時・対象者を確認できる箇所
承認者と期限	業務支援部の承認担当A。期限は業務側で設定

承認は「この一式を実行してよい」という記録にします。「この依頼番号なら、後から何を変えてもよい」という許可にはしません。本文・宛先・添付のいずれかが変わったら、新しい確認依頼を出す設計です。

「操作案内v1」という名前だけで同じファイルと判断するのも避けます。実装では、確認したファイルの版や内容を識別できる情報を残します。根拠資料が更新された場合も、その変更が告知に影響するか確認してから進めます。

担当者には、日付が根拠資料と一致するか、宛先の人に必要な内容か、添付を開けるかを確認してもらいます。AIの要約だけで判断せず、必要な原文へ移れることを承認画面の条件に含めます。

承認待ち・差し戻し・失効・実行結果を分ける

基本の流れは、下書き作成 → 承認依頼 → 人の確認 → 承認対象の再照合 → 実行 → 結果の確認です。途中の状態が違えば、次にできることも変わります。

状態	次に行うこと
承認待ち	対象の操作を止めて待つ。期限までに回答がなくても自動承認しない
差し戻し	修正理由を残して下書きへ戻す。修正後は新しい依頼として確認する
承認済み	承認した版、実行内容、期限、承認担当の資格を実行直前に照合する
変更・期限切れで失効	古い承認で進めず、現在の内容と担当者で再依頼する
取り消し	まだ実行していない依頼を終える。古い承認操作が届いても再開しない
実行に引き渡した	配信処理などの結果を確認する。引き渡しだけで配信完了とは表示しない

担当者が古い通知メールから承認を押す場合もあります。そのため、依頼番号に加えて確認対象の版を照合し、修正前の依頼への返答を修正後の本文に適用しないようにします。画面には「この依頼は更新されています。現在の内容を確認してください」と案内する設計が考えられます。

承認担当が異動したときの扱いも決めます。この設計例では、実行時点で担当から外れていたら、新しい担当者へ確認を回します。単に「誰かが承認した」という履歴だけで実行を続けないルールです。

14ケースのローカル検証で、承認後の変更を確かめた

2026年9月8日、上の考え方を確かめるため、Pythonの標準機能で承認処理の小さな模型を作成し、実行しました。対象は架空の告知一件です。AIや社内ポータルには接続せず、実行が許可された内容をローカルの受け渡し用リストへ入れるところまでを試しています。

まず、承認したかどうかの真偽値だけを持つ単純な処理では、承認後に宛先を「業務支援部」から「全社員」へ変えても、変更後の内容がリストへ入りました。承認時の内容と照合する仕組みがないためです。

次に、承認対象の内容、依頼番号、担当、期限を照合する模型で、次の14ケースを実行しました。「実行へ渡す」は外部への配信完了を意味しません。

試した条件	期待した動作	模型の結果
1. 承認が届いていない	承認待ちを維持	一致・引渡し0件
2. 期限内に同じ内容を承認	実行へ渡す	一致・引渡し1件
3. 差し戻した	実行しない	一致・引渡し0件
4. 承認後に本文を変更	下書きへ戻す	一致・引渡し0件
5. 承認後に宛先を拡大	下書きへ戻す	一致・引渡し0件
6. 承認後に添付の識別値を変更	下書きへ戻す	一致・引渡し0件
7. 根拠資料の現行版が更新	再確認へ回す	一致・引渡し0件
8. 承認待ちのまま期限切れ	失効させる	一致・引渡し0件
9. 担当外の人が承認	承認を受け付けない	一致・引渡し0件
10. 古い依頼番号で承認	現在の依頼には適用しない	一致・引渡し0件
11. 修正した本文を新しい依頼で再承認	修正後の本文を渡す	一致・引渡し1件
12. 承認後に依頼を取り消し	実行しない	一致・引渡し0件
13. 実行前に承認担当から外れた	再確認へ回す	一致・引渡し0件
14. 承認後、実行前に期限切れ	失効させる	一致・引渡し0件

設定した14ケースでは、期待する状態と引き渡し件数が一致しました。これは自作模型の条件分岐を確かめた結果です。AIが内容を正しく判断できる割合、実サービスの安全性、送信の成功率を測定したものではありません。添付は識別値で扱っており、実ファイルの中身を読み取る処理も試していません。

実装では「承認を待つ」と「実行する」を別の処理にする

仕組みを作る際は、文章の指示で「確認してください」と書くことに加えて、承認が届くまで対象の操作へ進めない制御が必要です。たとえばLangGraphの公式資料は、処理を止めて状態を保存し、外部からの入力を受けて再開する方法を説明しています。

同資料では、再開時に停止した処理単位の先頭から動き直す点も説明されています。通知や登録の処理を停止前に置くと、再開時に重複して実行される場合があります。承認対象の作成、承認待ち、実行への受け渡し、実行結果の確認を分けて設計してください。

利用中のワークフローツールを選ぶときも、次の動作を実際の画面で確認すると判断しやすくなります。

• 待っている依頼の内容と版を保存できるか。
• 承認できる担当者を限定し、回答した人と時刻を記録できるか。
• 本文・宛先・添付の変更後に、古い承認を無効にできるか。
• 期限切れや取り消しを扱い、返答のない依頼を担当者が見つけられるか。
• 実行へ渡した後の成功・失敗・結果不明を確認できるか。

今回の模型は一つの処理の中で順番に実行しています。実システムでは、照合してから実行する間の更新、複数担当者の同時操作、再起動や再試行も考慮が必要です。承認した一式を固定して実行処理へ渡し、別の場所から変更されないことまで、実装側と確認します。

こうした条件を業務仕様に落とす部分は、AI導入支援・業務自動化で扱う、入力・確認・例外を含めた設計につながります。

確認する人の負荷まで含めて、最初の一業務を決める

承認を入れると、実行前に誤りを直す機会と、判断した内容の記録を作れます。一方で、誰も見られない量の依頼を流せば、確認待ちが増えたり、内容を読まずに承認する運用になったりします。承認の件数だけでなく、確認にかかった時間と差し戻し理由を残してください。

たとえば確認に平均4分、1日30件なら、単純計算で1日120分です。これは仮定の計算で、今回の検証で測った時間ではありません。AIの生成時間が短くても、人の確認と修正に必要な時間を含めて担当を決める必要があります。

最初は、根拠資料と承認担当が明確な社内業務を一つ選びます。確認者には同じ判断基準を渡し、差し戻し例も一緒に読んでもらいます。AIの自己申告の「自信がある」という言葉だけで承認を省く基準にはしません。

【自社用の承認仕様メモ】
対象業務：
人の判断が届くまで止める操作：
確認する本文・宛先・添付・根拠資料：
依頼番号と、確認対象の版の残し方：
承認担当と不在時の担当：
承認の期限、期限切れ時の戻し先：
変更後に再承認が必要になる項目：
差し戻し・取り消し時の動作：
実行後に成功を確認する記録：
試したい通常例と例外：

このメモを埋め、承認する例と止める例の両方を試せる状態にすると、導入するツールや開発の相談も具体的になります。HITLを業務に取り入れる際は、確認する人を決めるところから、その人が判断した内容を実行まで保つところまでを一続きで設計しましょう。