ヒューマン・イン・ザ・ループとは？AIに任せる仕事と人が判断する仕事

1. HITLとは？まずはメール返信で考える

AIに文章を作ってもらうと便利。でも、そのままお客様に送ってよいのかは迷う。そんな場面で役立つのが、ヒューマン・イン・ザ・ループ（Human-in-the-loop、略してHITL）です。

日本語では「人間を処理の流れに組み込む」という意味です。ここでは、業務で動くAIに対して、人が途中で情報を補い、内容を修正し、実行してよいか判断する仕組みを指します。

例えば、お客様から商品の納期について問い合わせが届いたとします。AIが質問の要点を整理し、社内資料を参照して返信案を作ります。担当者は、最新の在庫や出荷予定と照らし合わせ、宛先・本文・添付ファイルを確認してから送信を承認します。

AIが文章を整えるのは得意でも、参照した資料が古かったり、担当者だけが知っている約束があったりする可能性があります。だからこそ、文章として自然かどうかと、業務として正しいかどうかを分けて確認する必要があります。

重要な処理の前で停止し、人が承認・拒否・修正する実装の考え方：参考資料［1］。

2. 見積書・議事録・コラムでの具体例

人が関わる場所は、業務によって変わります。次の表と例は、役割分担を考えるための架空の業務例です。

見積書：計算が正しくても、内容が正しいとは限らない

例えば、AIが単価と数量を正しく掛け算していても、現地への搬入費が抜けていれば、見積もり全体は不十分です。人は合計金額だけでなく、「必要な作業が全部入っているか」「例外的な条件がないか」を確認します。

議事録：「検討しましょう」が「決定しました」になっていないか

会議では、提案・保留・決定が入り交じります。AIの要約に「来月から導入」と書かれていても、実際の発言は「来月から導入できるか検討」だったかもしれません。担当者が録音や発言記録を確認し、確定事項と未決事項を分けて共有します。

コラム：読みやすさと、情報の確かさを別々に見る

流暢な文章にも、誤った数字や存在しない事例が混ざることがあります。公開前には、根拠となる資料までたどり、確認できた事実と自社の意見を区別します。実際には経験していない取り組みを、自社の実績として書かないことも大切です。

3. 開発元が公開する実装と調査

投稿案を、人間が修正・承認できる公開実装

LangChainは「Social Media Agent」というプログラムを公開しています。URLをもとにX・LinkedIn向けの投稿案を作り、人間が修正・承認・拒否できる構成です。文章を生成するだけでなく、人が内容を調整する流れまで含めた実装例として参考になります。［2］

ただし、コードが公開されていることは、すべての企業で同じ成果が出る証明ではありません。自社で使う際には、投稿ルール、確認担当者、認証情報の管理などを別途設計する必要があります。

毎回承認する以外にも、人が関わる形がある

Anthropicは2026年2月18日に、Claude Codeと公開APIにおける人とAIのやり取りの分析を公表しました。経験を積んだ利用者ほど自動承認を使う一方で、必要な場面で途中介入する傾向を報告しています。AI自身が不明点を質問して停止することも、監督の一つの形として扱っています。［4］

この結果は特定の製品や利用状況を対象とした観測です。すべての業務に自動承認を勧める根拠にはなりません。自社では、処理の影響や、間違った場合に元へ戻せるかを踏まえて、確認する場面を決めることが必要です。

4. 確認が形だけにならないために

人が承認する仕組みを入れても、確認が機能するとは限りません。何度も同じ確認を求められると、よく読まずにボタンを押してしまうことがあります。

Anthropicも2026年5月25日の技術記事で、確認の回数が増えるほど注意が薄れる「承認疲れ」を課題として報告しています。人の確認に加え、AIが操作できる範囲を技術的に制限する方法も説明しています。［3］

「承認」の前に、この3点

1. 何をする？宛先・金額・変更する内容
2. 根拠はある？最新の資料・合意した条件
3. 迷ったら止められる？修正・差し戻し・相談先

これらを踏まえ、MiToAでは、役割分担を考える際の確認項目として次の三つを提案します。

• 判断に必要な情報をそろえる：メールなら宛先と添付、見積書なら計算根拠と例外条件、データ更新なら変更前後の差分を示します。
• 修正・差し戻し・停止を選べるようにする：「承認」以外の選択肢と、迷ったときの相談先を用意します。承認後に内容が変わった場合は、変更部分を再確認します。
• AIが実行できる範囲を決める：例えば、情報を読む権限と、外部へ送信・更新・削除する権限を分けます。確認待ちのまま期限を迎えても、勝手に実行しない流れにします。

5. 自社で始める5つのステップ

最初から業務全体を自動化する必要はありません。まずは成果物を確かめやすい一つの仕事を選び、次の順番で試してみてください。以下は、参考資料を踏まえたMiToAの導入上の提案です。

1. 対象を一つに絞る

   例えば「問い合わせメールの返信案作成」。受信から送信までのどこを対象にするか、入力と成果物を決めます。

2. 間違えたときの影響を考える

   社内の草案と、お客様への送信では影響が異なります。外部への連絡、金額や条件の提示、データの削除など、確認が必要な操作を洗い出します。

3. 担当者と確認基準を決める

   「担当者が確認する」だけでなく、「納期は最新の出荷予定と照合する」など、何を見るかを具体化します。不在時の担当者も決めます。

4. 下書きまでの運用で試す

   まずは送信や更新を自動実行せず、人が成果物を確認します。通常のケースに加え、資料不足・例外条件・誤った宛先なども想定し、止まれるか確かめます。

5. 確認の負担を含めて見直す

   作成時間だけでなく、確認時間、修正箇所、差し戻しの理由、誤送信などの問題を記録します。導入前後を同じ条件で比較し、任せる範囲や資料を調整します。

目指すのは、AIの作業量と人の確認能力が釣り合う運用です。下準備を任せることで生まれた時間を、お客様の事情を理解することや、例外への対応に使えるかも確かめていきましょう。

6. よくある疑問

7. 参考資料と編集方針

本文の技術的な説明と調査の紹介は、開発元が公開した以下の一次資料を参照しています。すべて2026年10月26日に内容を確認しました。

1. LangChain：Making it easier to build human-in-the-loop agents with interrupt公開：2024年12月14日。参照日：2026年10月26日。
2. LangChain：Social Media Agent（公開ソースコード）公開：継続更新。参照日：2026年10月26日。
3. Anthropic：How we contain Claude across products公開：2026年5月25日。参照日：2026年10月26日。
4. Anthropic：Measuring AI agent autonomy in practice公開：2026年2月18日。参照日：2026年10月26日。