HITLとはAI運用で人間が判断する境界を業務別に決める

この記事の要点

HITL（Human-in-the-loop、ヒューマン・イン・ザ・ループ）は、AIが自動で処理していく流れの中に「必ず人間が判断する」というチェックポイントを残す設計思想です。全部AIに任せるHOOTLでも、全部人間がやる旧来型でもない、その間の落としどころとして、2026年に規制対応（EU AI法8月2日本格適用）と現場運用の両方で必須になっています。

• HITL・HOTL・HOOTLの3種類の違いを、AIとの距離感のスペクトラムとして整理します
• 業務類型を「リスク×可逆性×頻度」の3軸で分類し、対応するループを判定する意思決定ツリーを提示します
• みずほ銀行、セブンイレブン、メルカリ、パナソニックコネクトの実装事例を4象限マップに落とし込みます
• EU AI法と経産省・総務省のAI事業者ガイドライン v1.2の5委任原則（Observe/Judge/Propose/Execute/Revoke）をチェックリスト化します
• 月曜日から始める3ステップとして、Snorbeで調査業務の反復ループを回す方法を紹介します

主読者はAI運用担当・DXマネージャー・AI導入検討者。読了後、自組織の業務10個を採点し、どこから HITL を入れるかの初期設計ができる状態を目指します。

HITLとはAIの流れに判断できる人間を必ず一人残す設計です

HITL（Human-in-the-loop、ヒューマン・イン・ザ・ループ）は、AIが自動で処理していく流れの中に、「必ずここで人間が判断する」というチェックポイントを残しておく設計思想です。AIが下書きを作ったり候補を出したりして、最終確定の直前に人間がレビュー・修正・承認・エスカレーションのいずれかを行う。これがHITLの基本形になります。

大事なポイントは、HITLは「人間がすべての決定を下すこと」ではないというところです。JAPAN AI ラボの解説がわかりやすく整理しているのですが、HITLの本質は「人間が最終的な行動の直前に必ず介入できる能力を持っていること」にあります。全部を人間がやるなら、そもそもAIを入れる意味がありません。かといって全部AIに任せると、後で「なぜこの判断をしたのか」を誰も説明できなくなる。この間のちょうどいい落としどころが、HITLです。

AIとの距離感で3種類に分かれる：HITL・HOTL・HOOTL

HITLの話をするときに、必ずセットで理解しておきたいのが、その少しゆるいバージョンと、完全自動の対極です。全部で3つの立ち位置があって、これを「AIとの距離感」のスペクトラムとして並べると理解しやすくなります。Noon Daltonの整理を参考に、日本語で並べ直してみます。

略称	呼び方	人間の役割	イメージ
HITL	Human-in-the-loop	AI出力後、確定前に必ず人間が確認・承認	AIが下書き、人間が確定判子
HOTL	Human-on-the-loop	人間はダッシュボードで監視、異常時のみ介入	AIが実行、人間が交通監視員
HOOTL	Human-out-of-the-loop	完全自動、人間の関与なし	AIが単独で走り切る

3つの違いは、意思決定サイクルのどこに人間がいるか、と考えるとイメージしやすいです。HITLは1件ずつ人間が判断するので精度は高いですが、量を捌けません。HOTLはAIが自律的に動きますが、人間は仕組みそのものを監視しているので、変な挙動が出たら止められます。HOOTLは速いですが、間違いが起きても止められません。

多くの現場でありがちな失敗は、「AIを入れたのだから全部自動化したい」とHOOTLを目指してしまうことです。ただ、業界研究によると、最良のモデルでも複雑な多段階タスクで5〜15%の誤り率が出ることが知られています。つまり100件走らせれば5〜15件はどこかで間違える。金融や医療のように1件の間違いが致命的になる領域では、HOOTLは選べません。

なぜ2026年にこの話が急に重要になっているのか

HITLという言葉自体は、機械学習の教科書には10年以上前から出ています。ではなぜ今、AI運用担当やDXマネージャーがこぞってHITL設計を検討し始めているのでしょうか。

理由は3つあります。1つ目は市場そのものの拡大です。Research and MarketsのHITL AI市場レポート2026によれば、HITL AI市場は2025年の54億ドルから、2026年には67.3億ドルへ、そして2030年には164億ドルへと成長する見込みです。年平均成長率（CAGR）で言うと24.7〜24.9%になります。ITスタックの中で急速に伸びている領域と言えます。

2つ目は規制の締め切りです。EU AI法は2026年8月2日から高リスクAIシステムに対する規制が本格適用されます。高リスクに分類されるAIシステムには「人間による効果的な監督（Human Oversight）」が第14条で義務付けられていて、日本企業がEU市場向けにAIサービスを提供する場合、域外適用の対象になります。この規制対応のためだけでもHITLの整備が必要になる企業がかなり出てきます。

3つ目はAIエージェントの本番投入が現実になってきたことです。Gartnerの予測では、2026年末までにエンタープライズアプリケーションの40%がタスク特化型のAIエージェントを含むようになるとされています。エージェントが自律的にツールを叩いて仕事をこなす時代になると、「どこで人間が止めるか」の設計は避けて通れません。

日本のガイドラインもHITL前提で整備されている

日本国内でも、経済産業省と総務省が策定したAI事業者ガイドラインのv1.2が、AIエージェントの外部アクションについてHITL設計を明示的に推奨しています。5つの委任原則として、Observe（監視のみ）、Judge（監査ログ付き判断）、Propose（高リスク行動は人間承認）、Execute（中低リスク行動は自律実行）、Revoke（取り消し権限）が整理されています。

この5原則は、後ほど第4章で詳しく紹介しますが、要は「AIに何を任せて、何を任せないか」を業務ごとに5段階で線引きしましょう、という考え方です。EU AI法の第14条と方向性は同じで、日本企業もそろそろこのフレームで自社業務を整理しておかないと、規制対応と現場運用の両方でつまずくことになります。

HITLは「人間が全部やる」の反対側にある考え方でもある

もう1つ、HITLを理解するときに大事なのは、HITLは「AIを入れる前の状態」の反対側にもある、ということです。多くの日本企業では、既存の業務は全部人間がやっています。稟議承認、契約書レビュー、顧客対応、レポート作成。すべて人間が最初から最後までやっている。

HITLは、この状態から「AIに前処理を任せて、人間は判断と最終確認だけに集中する」への移行を意味しています。だから、HITLを導入するということは、「AIを入れる」だけの話ではなくて、「既存の人間の役割を、判断側にシフトさせる」という業務再設計を伴います。ここが、単なるツール導入とHITL導入の一番大きな違いです。

次のセクションでは、この理屈を実際の業務に落とすための道具として、業務類型別の意思決定ツリーを紹介します。自組織のどの業務にHITLを入れるべきか、どのループを選ぶべきかを、リスクレベル・可逆性・頻度の3軸で判定できる形にしていきます。

業務類型別に「どのループを選ぶか」を判定する意思決定ツリー

HITLを実際に導入するときに一番悩ましいのは、「どの業務にどのループを入れるか」の線引きです。全業務にHITLを入れると監督コストが跳ね上がって現場が疲弊しますし、逆に軽い監視だけで済ませると、事故が起きたときに責任を取れる人がいなくなります。

このセクションでは、業務類型ごとの意思決定ツリーを提示します。使う判定軸は3つ、リスクレベル・可逆性・頻度です。この3軸で業務を分類すれば、HITL・HOTL・サンプリング監査のどれを選ぶべきかが見えてきます。

判定に使う3軸を先に定義する

3軸の中身を、日本の実務でよくある業務例を頭に置きながら整理します。

リスクレベルは、間違えたときにどれだけ大きな影響が出るかです。高リスクは金融取引や医療診断のように、1件の誤りで会社や顧客の生命・財産に関わる業務。中リスクは発注業務や契約書ドラフトのように、間違えても内部で修正可能だが手戻りが発生する業務。低リスクは議事録や要約のように、間違えても影響範囲が狭く、後からいくらでも直せる業務です。

可逆性は、AIが実行してしまった結果を後から巻き戻せるかどうか。融資の実行や契約書の送信は不可逆、社内メモの共有は可逆、といった具合に分けます。

頻度は、その業務が1日に何件発生するか。融資審査は1日数件、コンテンツモデレーションは1日数万件、といったスケール感です。頻度が高い業務にHITLをかけると、人間のレビュー担当が回らなくなるので、信頼度閾値による自動分岐やHOTLへの切り替えが必要になります。

4象限マップと業務のマッピング

3軸のうち「リスクレベル×可逆性」を主軸に、頻度を色分けとして扱う4象限マップを作ります。実際の業務を落とし込むとこうなります。

象限	リスク	可逆性	推奨ループ	代表業務
高リスク × 不可逆	高	低	HITL事前承認	融資審査、医療診断、契約締結
高リスク × 可逆	高	高	HITL事前承認＋信頼度閾値	コンテンツモデレーション、SNS投稿
中リスク × 可逆	中	高	HOTL事後監査	発注数量提案、稟議ドラフト、メール返信
低リスク × 可逆	低	高	サンプリング監査	議事録、要約、社内Q&A、コード補完

このマップを頭に入れておくと、新しい業務にAIを入れるとき、まず「これはどの象限か」を判定してから、対応するループを選ぶ、という流れで設計できます。

高リスク×不可逆：融資審査型の事前承認HITL

融資審査や医療診断のように、1件の判断が顧客の生活や生命に直接影響し、しかも実行してしまうと巻き戻せない業務は、必ずHITL事前承認型を選びます。

具体的には、AIがスコアリングや診断候補を提示するところまでは自動化して、最終判断は必ず担当者が下す設計です。SIGNATE総研の解説でも、金融の融資審査で「AIのスコアリング結果を担当者がレビューする運用」が典型例として挙げられています。医療診断支援システムも同じ形で、医師がAIの解析結果を確認してから最終診断を下します。

この象限で重要なのは、「AIの提案を人間が承認する」というワークフローを、業務システムの中に組み込んでしまうことです。AIの提案画面と担当者の承認画面を分けて、承認しなければ次のステップに進めない設計にする。これで、うっかりAI提案がそのまま実行される事故を防げます。

高リスク×可逆：モデレーション型の信頼度閾値付きHITL

コンテンツモデレーションのように、リスクは高いけれど後から取り消し可能で、しかも頻度が非常に高い業務は、事前承認HITLだけでは回りません。1日に数万件の投稿を全部人間がレビューするのは不可能だからです。

ここで登場するのが、信頼度閾値による自動分岐です。Strataの2026年ガイドやElementumの実装ガイドが推奨しているベストプラクティスで、AIの判定信頼度が閾値以上なら自動処理、閾値未満なら人間にエスカレーションする設計です。

メルカリの実装が典型例です。SIGNATE総研によると、メルカリはブランド偽造品や販売禁止商品を検出するモデルをカテゴリごとに構築していて、AIが違反と判定した出品物のうち、信頼度が高いものは即削除、判定が微妙なものはカスタマーサポートのオペレーターが目視で確認してから削除するかを決めています。全件人間目視ではなく、AIが1次フィルタをかけてから人間が最終判断する形です。

中リスク×可逆：稟議ドラフト型のHOTL事後監査

みずほ銀行が生成AIで稟議資料のドラフトを自動作成しているのは、この象限の代表例です。稟議資料そのものは、AIが下書きしてもすぐに人間が編集して直せますし、そのまま経営会議に出るわけでもありません。ドラフトの品質が多少低くても、担当者が磨いてから出せば良いだけです。

こういう業務はHOTL事後監査型が向きます。AIが提案を出し、担当者が使いながら直していく。数週間に一度、ドラフトの品質が落ちていないかをサンプリングでチェックする。担当者が「このドラフトはひどい」と感じたら、その場でフィードバックを入れて、AIのプロンプトや参考資料を調整する。この運用ができれば、担当者の作業時間を数分の1に減らせます。セブンイレブン・ジャパンは発注数量提案AIで発注時間を4割削減しましたが、これも同じHOTL事後監査型の運用です。

低リスク×可逆：議事録型のサンプリング監査

議事録作成やドキュメント要約、社内Q&Aのようなタスクは、間違えても実害が少ないので、AIに自動処理させて、月次で品質をサンプリング監査する程度で十分です。

ただし、ここで注意したいのは「低リスクだから何も見なくていい」ではないということです。エイトハンドレッドのブログが指摘しているように、AIには構造的にハルシネーション（事実誤認）のリスクがあります。低リスク業務でも、月に1回程度は10件抜き取って人間が読み、明らかにおかしい出力が混じっていないかをチェックしておく必要があります。この監査結果を、AIの改善サイクル（プロンプトの見直しや参考資料の更新）に回す仕組みを作っておくと、時間が経つほどAIの品質が上がっていきます。

3ステップで自組織の業務をマッピングする

理屈は分かったとして、実際に自組織で線引きするには何をすればいいか。3ステップで整理できます。

ステップ1：AI化候補の業務を10個リストアップする。今週の業務日誌を見返して、「AIに任せられそう」と感じたタスクを片っ端から書き出します。稟議ドラフト、メール返信、議事録、契約書レビュー、社内問い合わせ対応、レポート作成、翻訳、要約、コード生成、リサーチなどが典型です。

ステップ2：各業務を3軸で採点する。リスク（高中低）、可逆性（可逆・不可逆）、頻度（低頻度/中頻度/高頻度）の3つで、各業務を採点します。10業務を採点表に並べると、自然と象限が見えてきます。

ステップ3：象限に対応するループを割り当てる。高リスク不可逆はHITL事前承認、高リスク可逆はHITL＋信頼度閾値、中リスク可逆はHOTL事後監査、低リスク可逆はサンプリング監査。この割り当てだけで、10業務それぞれに「どういう形でAIを入れるか」の初期設計ができます。

この採点表を、AI運用担当が経営会議や部門会議に持ち込めば、「うちはこの業務からHITLを入れる」という議論のスタート地点が作れます。次のセクションでは、日本企業がすでにこの設計で動かしている実装事例を、稟議文化との接続まで含めて紹介します。

日本企業の実装事例と稟議文化との接続

前のセクションで整理した意思決定ツリーが、実際の日本企業でどう動いているのかを見ていきます。ここでは4社の事例を、象限マップと対応させながら並べます。そのあとで、日本企業に固有の課題である「稟議文化とHITLのミスマッチ」をどう解くかを扱います。

みずほ銀行：稟議ドラフトを生成AIで作らせる

みずほ銀行は、生成AIを使って稟議資料のドラフトを自動作成する運用を進めています。Japan IT Weekの解説によれば、社員が稟議書を書く際、AIが下書きを作成し、担当者がそれを編集・修正して提出するという流れです。

これは前セクションの4象限マップで言うと「中リスク×可逆」の稟議ドラフト型に完全に当てはまります。稟議書のドラフトそのものは、内容が甘くても担当者が編集して直せますし、最終的に稟議として通るかどうかは既存の承認プロセスでチェックされます。だからAIに下書きをさせても大きな事故は起きません。

面白いのは、みずほ銀行のように稟議文化が根強い金融機関が、あえてこの領域から生成AIを入れ始めているところです。稟議文書という「型が決まっているが埋めるのが面倒な文書」は、生成AIが最も得意とする領域の一つです。しかも、稟議は必ず人間の承認プロセスに乗るので、AIの誤りが表に出る前に必ずキャッチできる。HITL事後修正の理想的な適用先と言えます。

セブンイレブン・ジャパン：発注数量提案で作業時間を4割削減

セブンイレブン・ジャパンは、発注数を提案するAIを導入し、発注時間を約4割削減しています。同じくJapan IT Weekの解説で紹介されている事例です。

コンビニの発注業務は、店長やアルバイトが毎日、店舗ごとの過去の販売データ・天気・イベント情報などを踏まえて数量を決める作業です。AIが過去データから最適発注数を提案し、担当者が画面上で確認して微調整するだけで済むようになりました。

この事例のポイントは、「AIの提案をゼロベースで承認するのではなく、AIが80%作った土台を人間が20%調整する」という運用に切り替えたことです。担当者は、天気予報や店舗の直近イベント（近隣の学校で運動会があるなど、AIには読めない文脈）だけを追加して調整すればいいので、頭を使う部分に集中できます。これも4象限マップの「中リスク×可逆」で、HOTL事後監査型の運用です。

メルカリ：コンテンツモデレーションのHITL

メルカリの事例は、SIGNATE総研が典型例として紹介しているように、コンテンツモデレーションでのHITL運用です。ブランド偽造品や販売禁止商品の検出モデルをカテゴリごとに構築し、AIが違反と判定した出品物をカスタマーサポートオペレーターが目視で確認したうえで、最終的な削除判断を人間が行う設計になっています。

ここで大事なのは、AIが「削除」の実行者ではなく「候補提示」の実行者であるという分担です。実際に商品を削除するのは常に人間で、AIはあくまで「これは怪しい」というアラートを上げる役割に留まっています。この分担があるから、AIが誤検知をしても、まっとうな出品者の商品が誤って削除される事故を最小限にできます。

高リスクだが可逆で、しかも1日に数万件の投稿を捌く必要がある。この象限では、AIの信頼度に応じて自動処理と人間確認を振り分ける設計が現実解になります。信頼度99%以上なら自動削除、80〜99%なら人間確認、80%未満なら見送り、といった閾値設計が典型的なパターンです。

パナソニックコネクト：全社員に生成AIを配る先進事例

パナソニックコネクトは、生成AIを国内の全社員向けに導入した、日本の大企業としては異例に早い事例です。Japan IT Weekの解説で紹介されています。

全社員に配るというアプローチの意味は、単にツールを配って終わりではなく、「HITL運用を全社員に体験させる」ことにあります。生成AIが下書きした文書やメール、要約を、社員一人ひとりが自分の業務でレビュー・修正して使う。これを1年間続ければ、全社員が「AIの下書きを人間が磨いて最終品にする」というワークフローを、身体で覚えることになります。

これは組織学習の観点で非常に効いてきます。HITLは仕組みだけ整えても、現場が「AIに任せきり」か「AIを全く使わない」かのどちらかに振れると機能しません。全社員がAIとの適切な距離感を体得している状態が、次の段階（AIエージェントの本番投入）で決定的に効きます。

日本企業に固有のハードル：稟議とAIエージェントのスピードのミスマッチ

ここまで4社の事例を紹介しましたが、日本企業がHITLを本格導入するときに必ずぶつかる壁があります。稟議文化とAIエージェントのスピードのミスマッチです。

aileadのガイドライン解説が鋭く指摘しているのですが、AIエージェントがもたらす意思決定のスピードと、日本企業の「稟議」による多階層承認プロセスの間には、構造的なミスマッチが存在します。AIエージェントが数秒で提案してくる意思決定を、部長→本部長→役員と順に回覧して数週間かけて承認する。これでは、AIの速度メリットが全部失われます。

解決の方向性は、大きく2つです。1つ目は「小さな決裁権限を現場に委譲する」こと。少額の発注や社内文書の確定判断など、リスクが限定的な業務については、稟議を通さずに現場担当者がAIの提案を即承認できる形に業務規程を変える。これができれば、HITL事後修正型の運用がスピードを保ったまま回せるようになります。

2つ目は「稟議そのものをHITL化する」こと。稟議書のドラフト作成、関連資料の収集、過去類似案件の検索といった稟議準備作業をAIに任せ、承認者は判断ポイントだけをレビューする。承認速度そのものは変えないけれど、準備にかかる時間を数時間から30分程度に短縮できます。みずほ銀行の稟議ドラフト事例は、この方向性の先駆けと言えます。

どちらを選ぶかは、業務のリスクプロファイルによります。決裁権限の委譲は組織的な意思決定が必要で時間がかかるので、まずは稟議自体のHITL化から始めて、その中で「これはリスクが低いから現場委譲でいい」と判定できる業務を切り出していく、というステップが現実的です。

事例に共通する成功パターン

4社の事例に共通するのは、「AIに全部を任せず、判断の直前で人間が必ずタッチする」設計を業務プロセスに組み込んでいることです。特にみずほ銀行とセブンイレブン・ジャパンの事例は、既存の業務プロセスを大きく変えずに、その中のドラフト作成や数量提案という「頭を使わない部分」だけをAIに任せている点が優れています。

失敗事例の多くは、「AIが業務全体を巻き取ってくれるはず」という過剰な期待から始まっていて、実際にはAIに任せた業務でハルシネーションや誤判定が頻発し、監督コストが跳ね上がって元に戻す、というパターンを踏みます。逆に成功事例は、最初から「AIは下書き役、人間が判断役」と割り切っているので、期待値と実装がぶれません。

次のセクションでは、この日本の現場感覚と、EU AI法や技術実装（LangGraphのHITLパターン）との接続を扱います。規制対応と現場運用の両方を、5つの委任原則というシンプルなチェックリストで整理できる形にしていきます。

EU AI法・5委任原則・LangGraphの一時停止パターン

このセクションでは、規制対応と技術実装の両輪で、HITLの具体的な実装ラインを整理します。多くの記事は「規制が来るから対応しましょう」で止まってしまいますが、AI運用担当者に必要なのは、規制と技術と現場運用をつなぐ実装レシピです。順に見ていきます。

EU AI法：2026年8月2日からの本格適用と域外適用

EU AI法は、高リスクAIシステムに対する規制が2026年8月2日から本格適用されます。法律のミカタの解説によれば、この規制は「EU域内でAIシステムを提供する事業者」を対象としていて、日本企業がEUに製品・サービスを輸出したり、EU域内の顧客に対してAIを提供したりする場合、域外適用の対象になります。

高リスクに分類されるAIシステムは、医療機器、雇用選考、教育、公共サービス、司法、法執行など、人の権利や生命に関わる領域で使われるものです。これらのシステムに対しては、次の要件が課されます。リスク評価と緩和策の文書化、データセット品質の管理、詳細ログの保存、透明性の確保、そして中核となる「人間による効果的な監督（Human Oversight）」です。

EU AI法の第14条は、この人間監督について具体的に「人間が理解・監督できる形で設計されていること」「重要判断で人間が介入・停止できること」「AIの出力を人間が正しく解釈できるように支援する仕組みがあること」を求めています。これはHITLそのものの要件を規制文書に落とし込んだもの、と言えます。

規制対応のためのHITL設計として最低限おさえるべきは、次の3点になります。1つ目は、AIが出力した結果を人間が確認・修正・却下できるインターフェースがあること。2つ目は、いつ誰がどのAI判断を承認したかを追跡できるログが残っていること。3つ目は、AIの誤動作を人間が即座に検知し、システムを停止できる仕組みがあること。この3点は、EU AI法対応の必須要件と考えて設計に入れておく必要があります。

AI事業者ガイドライン v1.2の5委任原則

日本国内では、経済産業省と総務省が策定した「AI事業者ガイドライン v1.2」が、AIエージェントの外部アクションに対するHITL設計を5つの委任原則として整理しています。aileadの解説に基づいて、日本語で並べ直します。

原則	内容	適用例
Observe	AIの挙動を監視のみ、行動権限なし	ログ収集、異常検知アラート
Judge	監査ログ付きで判断だけ実行	内部レポート生成、要約
Propose	高リスク行動は人間の承認が必要	契約、支払い、公開投稿
Execute	中低リスク行動は自律実行OK	社内メール返信、スケジュール調整
Revoke	実行された行動を人間が取り消せる	誤送信メールの取消、公開の巻き戻し

この5原則は、そのままチェックリストとして使えます。新しいAIエージェントを本番投入するときに、各業務を5原則のどこに当てはめるかを事前に決めておけば、後から「これはAIにやらせていい行動だったのか」を再判定する手間が省けます。

特に大事なのがProposeとExecuteの線引きです。契約締結や外部発表のように会社の対外的な意思表示となる行動は必ずPropose（人間承認必須）、社内で完結する日常業務はExecute（自律実行OK）、と割り切っておくと、実装がシンプルになります。判断に迷う中間領域は、Executeにしつつも実行後に必ずJudge（監査ログを残す）を組み合わせる、というハイブリッド設計が現実解です。

技術実装：LangGraphのチェックポイントで一時停止→承認→再開

規制と原則の話をしてきましたが、実際にAIエージェントに「一時停止して人間承認を待つ」動作をさせるには、技術的な仕組みが必要です。ここで役立つのがLangGraphというフレームワークです。

LangGraphは、AIエージェントの実行を「フローチャート」として表現し、その途中で処理を一時停止して人間の承認を待ってから再開できるようにする仕組みを提供しています。alicelabsの解説によれば、LangGraph 1.2が2026年5月11日にリリースされ、Klarna、LinkedIn、Uber、Replitなどの企業がすでに本番AIエージェントのバックボーンとして採用しています。

技術的に何が新しいかというと、「チェックポイント」という仕組みです。エージェントが処理の途中まで進んだ状態を保存しておき、人間の承認を待つ間、システムは他のリクエストを処理できます。承認が下りたら、保存した状態から続きを再開する。この「一時停止と再開」が、実装レベルで綺麗にできるようになったのが大きなポイントです。

具体的なイメージとしては、こんな流れになります。AIエージェントがユーザーの依頼を受けて、まず調査を実施します。調査結果から「では契約書を発送しましょう」と判断したところで、エージェントは自動的に一時停止し、担当者の承認画面に「発送してよいか」を表示します。担当者が承認ボタンを押すと、エージェントは続きから再開して発送処理を実行します。承認されなければ、エージェントはそこで停止し、担当者のフィードバックを次回以降の判断に反映します。

このパターンは、前セクションで紹介した5原則のうち、ProposeとExecuteの境界を実装するときに必須の技術になります。全業務でLangGraphを使う必要はありませんが、AIエージェントに複数ステップの作業を任せる場合には、事実上の標準実装になりつつあります。

信頼度閾値による自動分岐：監督コストを軽くする仕掛け

HITLを入れると、監督コストが跳ね上がるという不満をよく聞きます。全件人間が確認すると、当然作業量は増えます。これを軽くする仕掛けが、信頼度閾値（Confidence Threshold）による自動分岐です。

考え方はシンプルで、AIが自分の判断にどれだけ自信があるかをスコア化しておき、スコアが高ければ自動処理、低ければ人間にエスカレーションする、というルールを実装します。Elementumの解説やStrataのガイドが2026年のベストプラクティスとして紹介している設計パターンです。

たとえばコンテンツモデレーションであれば、AIが「99%違反」と判定したものは自動削除、「80〜99%」は人間確認、「80%未満」は見送り、という3層構造にする。融資審査であれば、「AIの信用スコアが900点以上」なら担当者は最低限のチェックで済ませ、「600〜900点」なら通常審査、「600点未満」なら詳細審査、という具合に、信頼度に応じて人間の関与度を段階的に変えます。

この閾値の設計は、業務ごとに何度もチューニングして最適点を見つける必要があります。閾値を上げすぎるとほぼ全件人間確認になって効率が上がりませんし、下げすぎるとAIの誤判定を素通しにしてしまいます。導入初期は保守的に高めの閾値からスタートして、運用データが溜まってきたら徐々に緩めていく、というアプローチが安全です。

ハルシネーション対策としてのHITL

生成AIを業務で使う上で、避けて通れないのがハルシネーション（事実誤認）の問題です。エイトハンドレッドのブログが指摘しているように、参照文書を渡すRAG（検索拡張生成）で減らすことはできますが、完全にゼロにはなりません。医療・法律など致命的な用途では、人間によるファクトチェックを必ずセットにする必要があります。

HITLは、このハルシネーション対策として最も直接的な仕組みです。AIの出力を人間が読んで、事実と照合し、間違いを指摘する。この作業を継続的にすることで、AI単独では検知できない事実誤認を、業務の中で必ずキャッチできる状態を作れます。

さらに一歩進めた対策として、「LLM as a Judge」と呼ばれる手法もあります。EXA Corpの解説によれば、これは別のAIを評価者として使い、生成AIの出力を機械的にチェックする仕組みです。全件人間確認するのは非現実的ですが、AI同士のクロスチェックで1次フィルタをかけ、疑わしいものだけ人間にエスカレーションする形にすれば、実運用可能な監査コストに収まります。

規制対応、技術実装、監督コストの3つの観点で、HITLの実装ラインを整理してきました。ここまでで、HITLは「単に人間がAIを見張る仕組み」ではなく、「どこで、誰が、何を、どの信頼度でチェックするか」を明示的に設計する枠組みだ、ということが見えてきたと思います。次の最終セクションでは、この設計を「月曜日から」自組織で試すための具体的な3ステップと、調査業務からHITLを始めるアプローチを紹介します。

月曜日から始めるHITL：調査業務をSnorbeで反復ループにする

ここまでで、HITLの定義、業務類型別の意思決定ツリー、日本企業の実装事例、規制・技術・監督コストの話を整理してきました。最後のセクションでは、この設計を自組織で「月曜日から」試すための現実的なアプローチを提案します。結論を先に言うと、最初のHITL導入対象として一番向いているのは、業務レポートや競合分析といった「調査業務」です。その理由と、具体的な運用の作り方を見ていきます。

なぜ調査業務がHITL導入の入口に向くのか

HITLを本格的に社内展開するとき、いきなり融資審査や医療診断のような高リスク業務から始めるのは、失敗リスクが高すぎます。逆に議事録や要約のような低リスク業務では、HITLらしさが実感しにくいので、社内の関心も上がりません。

その中間として、調査業務がちょうどよい入口になります。理由は3つあります。

1つ目は、リスクが中程度で可逆性が高いことです。AIが引いてきた情報源を人間がレビューする作業は、間違えても社外に出る前に修正できます。しかも、レビューの過程で「AIがどんなソースを引きに行くか」の癖が見えるので、HITLの本質を実感しやすい業務です。

2つ目は、頻度が中程度で反復サイクルが回りやすいことです。稟議準備、競合調査、市場動向レポート、業界ニュース確認など、週1回〜月数回のペースで実施される調査業務は、フィードバックループを回して継続的に改善するのに向いています。

3つ目は、結果が組織の知的資産になることです。調査結果とその判断根拠が蓄積されていくと、次回以降の意思決定の質が上がります。この「判断が資産になる」感覚が、HITLの醍醐味です。

調査業務でHITLをどう構成するか

調査業務にHITLを入れるとき、押さえるべきポイントは3つです。

まず、AIが1次調査をこなす部分と、人間が判断する部分を明示的に切り分けます。AIには、キーワードの候補洗い出し、関連する一次ソースの収集、要約、時系列整理を任せます。人間は、そのソースが本当に信頼できるか、事業判断にどう効くかを判定し、次回の調査に反映する指示を出す役割になります。

次に、その判断結果をシステムに戻す仕組みを用意します。担当者が「このソースは採用、こちらは却下」と判定したら、その判定結果を次回の調査でAIが参考にできる形で保存する。この蓄積があるかないかで、3カ月後の調査品質が全く違ってきます。

最後に、レビューの負担を軽くする仕掛けを組み込みます。全ソースを人間が精査すると疲弊するので、AIの信頼度が高いソースは軽く目を通すだけ、信頼度が低いソースは詳細確認、といった閾値運用を最初から入れておきます。

Snorbeを調査業務のHITL実装として使う

この3つを揃えたHITL調査環境として、Snorbeというリサーチエージェントを紹介します。Snorbeは、ナレッジグラフをベースにした調査AIエージェントで、複数の専門データベースを自然言語で横断的に問い合わせられる設計になっています。

Snorbeが押さえている専門データベースには、次のようなものがあります。

• 特許：JPO（日本特許庁）、EPO（欧州特許庁）、Google Patents
• 学術：arXiv、PubMed、Semantic Scholar
• 統計：e-Stat（政府統計）、Statista、CB Insights
• 一般Web：Tavily、Google検索

たとえば「うちの業界のAIエージェント導入事例を、直近半年の学術論文と特許出願で調べたい」と自然な日本語で投げれば、Semantic Scholarで論文を、Google Patentsで特許を、Statistaで市場データを、それぞれ引きに行ってくれます。担当者が普段使うキーワード検索の作業を、AIに任せられます。

Snorbeの一番の特徴は、完全記憶型のナレッジグラフです。従来のチャットツールは会話ごとに文脈が切れる設計ですが、Snorbeは「AIエージェントに関する調査」というノードを保持しつつ、関連する調査結果を継続的に蓄積していけます。担当者が「このソースは信頼できる」「これは古いので除外」と判定した情報は、その判断ごと記憶されるので、次回の調査でAIが同じ判定を再現できます。この蓄積が積み上がることで、AIが担当者の目線を学習していく形になります。

月曜日から3ステップで始める

Snorbeを使って調査業務のHITLを回すとき、月曜日から始められる3ステップを整理します。

ステップ1として、Snorbeにワークスペースを作り、最初の調査テーマを1つ登録します。「競合A社の生成AI関連の直近1年の動向」「自業界における生成AI導入事例」など、来週の会議で使う予定のテーマが一番モチベーションが続きます。

ステップ2として、初回調査をAIに実行させて、結果をレビューします。ここでは全ソースを確認し、「採用・却下・保留」の3段階でラベルを付けていきます。この最初のレビューが、後々のHITL品質を決める重要なタッチポイントになります。担当者が10〜30分かけて丁寧に判定した結果は、そのままナレッジグラフに残ります。

ステップ3として、翌週以降の追加調査をAIに任せます。前回の判定結果を踏まえて、AIが「前回採用したソースの延長線上にある新しい情報」を優先的に収集します。担当者は差分だけをレビューすれば良くなるので、時間が経つほど効率が上がります。

この3ステップを最初の1テーマで回してみると、HITLの本質である「AIが下書き、人間が判断、判断が資産になる」というサイクルを体験できます。ここで手応えが得られれば、次のテーマとして稟議準備や市場動向レポートに拡張していく、という流れが自然に進みます。

汎用チャットとの役割分担

Snorbeを使うとしても、ChatGPTやClaudeのような汎用チャットツールを捨てる必要はありません。むしろ役割分担で使い分けるのが実務的です。

汎用チャットは、思考の壁打ち、要約、ブレインストーミング、単発のリサーチに向いています。Snorbeは、継続観察、専門DB横断、ナレッジグラフ蓄積、差分検出に向いています。

たとえば、汎用チャットで「この調査結果から、うちの戦略にどう影響しそうか」を壁打ちしつつ、Snorbeで「その戦略テーマの一次ソースと過去の類似事例」を蓄積された文脈から引き出す、という組み合わせです。両者は競合する道具ではなく、補完しあう別軸の武器です。汎用チャットは思考の速さを、Snorbeは調査の深さと継続性を、それぞれ担当する役割分担になります。

今後のトレンド：HITLからHOTLへの移行

最後に、少しだけ将来の展望に触れておきます。現在は多くの企業がHITL（1件ずつ人間が承認）から始めていますが、AIの精度が上がり、業務データが蓄積されていくと、次のフェーズはHOTL（人間が全体を監視、異常時のみ介入）への移行になります。

Hyperscienceの分析によれば、Gartnerは2026年末までにエンタープライズアプリケーションの40%がタスク特化型AIエージェントを含むようになると予測しています。エージェントが自律的に業務を回す時代が来ると、全件人間承認では回らなくなるので、HOTLへの移行が必然になります。

ただし、この移行を安全に進めるには、まずHITLで業務データと判断ロジックを蓄積しておく必要があります。判断の癖もフィードバックの型も蓄積せずにいきなりHOTLへ飛ぶと、AIの誤動作を検知するダッシュボードそのものが機能しません。HITLは移行の準備段階として、今のうちにしっかり組み込んでおくべき仕組みです。この意味で、2026年〜2027年は「HITLでデータと判断を蓄積し、HOTLへの土台を作る」時期と考えると位置付けが整理しやすくなります。

この記事のまとめ

HITL（Human-in-the-loop）は、AIが動く流れの中に、判断できる人間を必ず一人残す設計思想です。全部AIに任せるHOOTLでも、全部人間がやる旧来型でもない、その間のちょうどいい落としどころとして、多くの企業で導入が進んでいます。

AI運用担当・DXマネージャー・AI導入検討者にとっての実務ポイントは、次の3つに集約できます。

• 業務類型を「リスク×可逆性×頻度」の3軸で分類し、対応するループ（HITL事前承認・HITL＋閾値・HOTL事後監査・サンプリング監査）を選ぶ
• EU AI法とAI事業者ガイドライン v1.2の5委任原則（Observe/Judge/Propose/Execute/Revoke）を、業務プロセスのチェックリストとして組み込む
• 最初の導入対象は調査業務が向いていて、Snorbeのようなナレッジグラフ型リサーチエージェントで反復ループを回すと、HITLの本質を1〜2週間で体験できる

読者の方が月曜日から試すとしたら、まず自組織の業務を10個リストアップし、3軸で採点して4象限マップに落とし込むのが最初の一歩です。その中で「調査業務」を切り出せたら、Snorbeで最初の1テーマから運用に載せてみる、という順序で進めるとリスクが低く進められます。規制対応の締め切りは2026年8月に迫っていますが、この記事の骨組みで自組織のHITL設計を整理していけば、規制対応と現場運用の両立は十分間に合います。

よくある質問

Q1. HITLとHOTLの違いは何ですか？

HITL（Human-in-the-loop）は、AIが出力した結果を確定する前に、人間が必ず1件ずつレビュー・承認する設計です。融資審査や医療診断のように高リスクな業務に向いています。HOTL（Human-on-the-loop）は、人間はダッシュボードで全体を監視するだけで、異常が出たときにだけ介入する設計です。稟議ドラフトや発注数量提案のように、中リスクだが件数が多い業務に向いています。同じ「人間が関わる」でも、関与のタイミングと粒度が違います。

Q2. HITLを入れると監督コストが増えませんか？

全件を人間がレビューすると確かに監督コストは増えます。この対策として2026年のベストプラクティスは「信頼度閾値（Confidence Threshold）による自動分岐」です。AIの判定信頼度が高いものは自動処理、低いものだけ人間にエスカレーションする設計にすれば、実運用可能なコストに収まります。閾値は業務ごとにチューニングが必要ですが、導入初期は保守的に高めからスタートして、運用データが溜まってから緩めていくのが安全な進め方です。

Q3. EU AI法で日本企業は何をすべきですか？

EU AI法は2026年8月2日から高リスクAIシステムに対する規制が本格適用され、日本企業もEU域内向けにAIサービスを提供する場合は域外適用の対象になります。最低限おさえるべきHITL要件は3点あります。1つ目はAIの出力を人間が確認・修正・却下できるインターフェース、2つ目はいつ誰が何を承認したかを追跡できるログ、3つ目はAIの誤動作を人間が即座に検知・停止できる仕組みです。この3点を業務プロセスに組み込んでおけば、規制対応の土台になります。

Q4. 生成AIのハルシネーション対策になりますか？

なります。ハルシネーション（事実誤認）は生成AIの構造的な問題で、RAG（検索拡張生成）を使っても完全にはゼロにならないことが分かっています。HITLは、AIの出力を人間が読んで事実と照合するプロセスを業務に組み込むので、AI単独では検知できない誤りを継続的にキャッチできます。医療・法律など致命的な用途では、人間ファクトチェックのHITLは必須です。全件レビューが難しい場合は「LLM as a Judge」でAI同士のクロスチェックを1次フィルタにする方法もあります。

Q5. うちで最初にHITLを入れるべき業務はどれですか？

調査業務が向いています。リスクが中程度で可逆性が高く、頻度も中程度で反復サイクルが回しやすく、結果が組織の知的資産になる、という3つの条件が揃っているからです。具体的には、競合調査、市場動向レポート、業界ニュース確認、稟議準備の材料集めなどが候補になります。この領域でHITLの反復ループを1〜2週間回してみて、感覚を掴んでから、稟議ドラフトや発注業務など他の業務に拡張していく順序が現実的です。

Q6. HITLとRPAの違いは何ですか？

RPA（Robotic Process Automation）は、決まった手順を機械が繰り返すだけの自動化で、判断が伴う業務には向きません。HITLは、判断が必要な業務にAIを組み込みつつ、判断そのものは人間が最終確認する設計です。RPAは「ルールベースの単純作業」を巻き取る道具、HITLは「判断を伴う業務」でAIと人間が協働する枠組み、と役割が違います。両者を組み合わせて、単純作業はRPA、判断業務はHITLで設計する、というのが実務的な使い分けです。

Q7. HITLはAIエージェント時代でも必要ですか？

必要です。むしろAIエージェントが自律的にツールを叩いて業務を回す時代になるほど、「どこで人間が止めるか」の設計が重要になります。日本のAI事業者ガイドライン v1.2は、AIエージェントの外部アクションに対して5委任原則（Observe/Judge/Propose/Execute/Revoke）を明示していて、契約や公開投稿のような対外的な行動は必ず人間の承認を通す（Propose）ように求めています。LangGraphのような技術フレームワークも、エージェントが実行途中で一時停止して人間承認を待つパターンを標準サポートするようになっています。

Q8. 小さく始めるにはどう進めればいいですか？

3ステップで始められます。ステップ1は、AI化候補の業務を10個リストアップし、リスク・可逆性・頻度の3軸で採点する。ステップ2は、採点結果を4象限マップに落として、どのループ（HITL事前承認・HITL＋閾値・HOTL事後監査・サンプリング監査）を選ぶかを決める。ステップ3は、その中で最もリスクが低くて反復サイクルが回しやすい業務（多くの場合は調査業務）を選び、SnorbeのようなツールでHITL反復ループを1テーマだけ回してみる。この体験を通じてHITLの本質を掴んでから、他業務に横展開する順序が失敗しにくい進め方です。