AIに任せた方が速いのは分かるんですが、最後に誰が責任を持つのかが曖昧なんです
これは、製造業の業務企画部で生成AIの活用ルールを整えていた佐伯さん（仮名）の言葉です。現場では、問い合わせ回答案や稟議書の下書きにAIを使い始めていました。しかし半年前までは、「AIに丸投げするか、これまで通り人がすべて確認するか」の二択になり、品質と効率の両立が難しい状態でした。営業は対応スピードを求め、法務は説明責任を重視し、現場責任者は承認フローが増えて作業が重くなることを懸念していました。
現在は、業務ごとに「AIが作成する部分」「人間が確認・判断する部分」「承認が必要な品質ゲート」を分けて設計し始めています。たとえば、AIチャットやプロンプトライブラリを備えた業務向けAIツールを使い、回答案の作成と確認観点の標準化を分ける方法があります。弊社が提供するKanataも、その選択肢の一つとして、AIチャット、要約、学習データ管理を組み合わせた運用に向いています。
ただし、Human in the Loopは万能ではありません。人を関与させる場所を増やすだけでは、かえって業務は遅くなります。この記事では、AI運用設計におけるHITLの考え方と、人間とAIの役割分担、責任分界、品質ゲートをどのように設計すればよいのかを整理します。AIに任せ過ぎる不安と、人が抱え込み過ぎる非効率の間で迷っている方は、自社の業務フローに重ねながら読み進めてください。
Human in the Loopとは何か
Human in the Loopとは、AIやシステムが処理を行う業務プロセスの中に、人間の確認・判断・承認・修正を組み込む考え方です。略してHITLと呼ばれることもあります。
重要なのは、単に「AIの出力を人が見る」という意味ではないことです。Human in the Loopは、人間がどの工程で介在し、何を判断し、どこからAIに任せるのかを設計するための考え方です。
たとえば、問い合わせ対応であれば、AIが回答案を作成し、人間が内容を確認して送信する形が考えられます。稟議書作成であれば、AIが下書きや論点整理を行い、最終的な判断や承認は責任者が担います。契約書レビューであれば、AIがリスク箇所の候補を抽出し、法務担当者が確認します。
AIの利用における人間の監督は、国際的なAIガバナンスの文脈でも重要な論点です。たとえばEUのAI規則では、高リスクAIシステムについて、自然人による効果的な監督が可能になるよう設計・開発されるべきだとされています。EU AI Act（Regulation (EU) 2024/1689）
つまりHuman in the Loopは、AIを止める仕組みではありません。AIを安全に、継続的に、業務の中で使うための運用設計です。
なぜAI運用には人間の関与が必要なのか
生成AIは、文章作成、要約、分類、検索、アイデア出し、問い合わせ回答案の作成など、多くの業務で利用できます。一方で、AIの出力には不確実性があります。
それらしい文章であっても、事実が誤っている場合があります。社内ルールや契約条件を読み違えることもあります。顧客対応では、言い回し一つで信頼を損なうこともあります。
NISTの生成AI向けリスク管理プロファイルも、生成AIには利用目的や文脈に応じたリスク管理が必要であることを示しています。日本でも、総務省・経済産業省の「AI事業者ガイドライン（1.2版）」が、AIガバナンスを継続的に改善する考え方に触れています。
AIに丸投げすると起きやすい問題
AIに任せる範囲を決めないまま運用を始めると、まず品質がばらつきます。AIの回答は、入力内容やプロンプトによって変わります。同じ業務でも、担当者ごとに指示の出し方が違えば、出力品質も変わります。
次に、責任分界が曖昧になります。AIが作った内容を誰が確認し、誰が承認し、誰が社外に出す責任を持つのかが決まっていないと、問題が起きたときに対応が遅れます。
さらに、説明責任が不足しやすくなります。顧客対応、契約、採用、評価、財務、法務などの領域では、「なぜその判断をしたのか」を説明できる必要があります。「AIがそう出したから」という説明だけでは、社内外の関係者に納得してもらえない場合があります。
人が関与し過ぎると起きやすい問題
一方で、人間がすべてを確認し過ぎると、AI導入の効果は出にくくなります。
AIが作った下書きを、担当者、上長、部門責任者、法務、経営層が毎回確認するような運用にしてしまうと、従来よりも承認フローが重くなることがあります。結果として、現場からは「AIを使う方が面倒です」という声が出ます。
Human in the Loopで大切なのは、人間を多く入れることではありません。人間が入るべき箇所を絞ることです。すべての業務に同じ確認フローを置くのではなく、業務リスクに応じて関与の深さを変える必要があります。
人間とAIの役割分担をどう考えるか
AI運用設計では、まず「AIが得意なこと」と「人間が担うべきこと」を分けて考える必要があります。
AIは、大量の情報をもとに下書きを作ること、文章を整えること、分類すること、要点を抽出すること、候補を複数出すことに向いています。
一方で、人間は、判断すること、責任を持つこと、相手との関係性を踏まえて対応すること、例外に対応すること、組織としての方針を決めることを担うべきです。
AIに任せやすい業務
AIに任せやすいのは、正解が一つに決まっておらず、下書きや候補を作ることで価値が出る業務です。
- 会議メモから議事録の下書きを作る
- 問い合わせ内容を分類する
- 社内文書を要約する
- メール文面の案を複数出す
- 提案書の構成案を作る
- FAQの回答候補を作る
- 稟議書の論点を整理する
- ナレッジ検索の候補を提示する
これらの業務では、AIが最初のたたき台を作ることで、人間はゼロから書く負担を減らせます。
人間が担うべき業務
人間が担うべきなのは、最終判断や説明責任が発生する業務です。
- 顧客に送る回答を最終確認する
- 契約上のリスクを判断する
- 採用候補者への評価を決める
- 社内ルールの例外対応を判断する
- 経営判断に関わる情報を採用する
- クレーム対応の方針を決める
- 金額、日付、固有名詞、法的表現を確認する
AIは判断の材料を整理できます。しかし、最終的に「この内容で進める」と決めるのは人間です。
実務上は、「作成・整理・要約・分類・候補提示はAI」「確認・判断・承認・説明・例外対応は人間」と分けると整理しやすくなります。
Human in the Loopを業務プロセスに組み込む手順
Human in the Loopは、考え方だけでは機能しません。業務プロセスの中に具体的に組み込む必要があります。
ここでは、AI運用設計の基本手順を5つに分けて整理します。
業務フローを分解する
最初に行うべきことは、対象業務を細かい工程に分けることです。
たとえば、問い合わせ対応であれば、次のように分解できます。
- 問い合わせを受け取る
- 内容を分類する
- 過去のFAQやマニュアルを確認する
- 回答案を作る
- 担当者が確認する
- 必要に応じて上長や専門部門に確認する
- 顧客に返信する
- 対応履歴を残す
このように分解すると、AIに任せられる工程と、人が確認すべき工程が見えやすくなります。
AIが処理する工程を決める
次に、AIに任せる工程を決めます。
問い合わせ対応であれば、内容の分類、関連FAQの候補提示、回答案の作成はAIに任せやすい領域です。一方で、クレーム対応や契約条件に関わる回答は、人間の確認が必要です。
ここで大切なのは、「AIに任せる業務」を広げ過ぎないことです。まずはリスクが低く、効果が見えやすい業務から始める方が現実的です。
たとえば、いきなり顧客への自動返信まで進めるのではなく、最初は「回答案の作成」までをAIに任せ、人間が確認して送信する形から始めると、運用品質を観察しやすくなります。
人間が確認する品質ゲートを決める
品質ゲートとは、AIの出力をそのまま次の工程に進めるのではなく、人間が確認するチェックポイントのことです。
品質ゲートでは、次のような観点を確認します。
- 事実に誤りがないか
- 社内ルールに反していないか
- 顧客に出してよい表現か
- 数字や日付に誤りがないか
- 契約や法務上のリスクがないか
- 会社として説明できる内容か
すべての業務に重い品質ゲートを置く必要はありません。リスクの大きさに応じて、確認の厚みを変えることが重要です。
承認フローと責任分界を決める
次に、誰が何を承認するのかを決めます。
通常の問い合わせ回答であれば、担当者の確認で十分な場合があります。一方で、返金、契約変更、法的リスク、顧客クレームに関わる内容は、上長や専門部門の承認が必要です。
このとき、「誰が責任者なのか」を明確にしておくことが大切です。
AIが作った回答であっても、社外に送る時点では送信者や承認者が責任を持ちます。Human in the Loopでは、AIの利用有無にかかわらず、最終的な責任を人間側に置く設計が必要です。
フィードバックループを作る
Human in the Loopは、一度設計して終わりではありません。AIの出力を人間が確認した結果を、次の改善につなげる必要があります。
たとえば、問い合わせ回答案に毎回同じ修正が入る場合は、プロンプトやFAQを見直すべきです。AIが特定の質問に答えられない場合は、学習データやナレッジの不足が原因かもしれません。
AIの出力、人間の修正、業務上の結果を定期的に見直すことで、AI運用は少しずつ安定していきます。ここでいうフィードバックループとは、「AIの出力を人が確認し、その修正結果をプロンプト、マニュアル、学習データ、承認ルールに反映する改善サイクル」のことです。
業務別に見るHuman in the Loopの設計例
Human in the Loopは、業務の種類によって設計が変わります。ここでは、代表的な業務を例に考えてみます。
問い合わせ対応
問い合わせ対応では、AIが回答案を作成し、人間が確認して送信する形が基本です。
AIは、過去のFAQやマニュアルをもとに、回答のたたき台を作れます。担当者は、内容が正しいか、顧客の状況に合っているか、表現が適切かを確認します。
リスクが低い一般的な質問であれば、担当者確認で十分な場合があります。一方で、契約、返金、障害、クレームに関わる問い合わせは、上長や専門部門にエスカレーションするルールを設けるべきです。
稟議・申請業務
稟議書や申請書では、AIが下書きや論点整理を行い、人間が内容を確認して承認します。
AIは、目的、背景、期待効果、リスク、代替案などを整理するのに向いています。担当者は、実際の金額、契約条件、関係者、スケジュールを確認します。
承認者は、AIが作った文章の上手さではなく、意思決定に必要な情報が揃っているかを確認する必要があります。
契約・法務確認
契約や法務に関わる業務では、AIの役割はあくまで補助です。
AIは、契約書の中からリスクがありそうな条項を抽出したり、確認すべき論点を整理したりできます。しかし、契約上の判断は法務担当者や専門家が行うべきです。
この領域では、Human in the Loopの品質ゲートを厚くする必要があります。AIの出力をそのまま判断に使うのではなく、専門部門が確認する前提で設計します。
社内ナレッジ検索
社内規程、業務マニュアル、FAQ、過去の議事録などをAIに参照させる場合、AIは検索や要約の入口として役立ちます。
ただし、社内ナレッジには古い情報や部署ごとの例外運用が含まれていることがあります。そのため、AIが提示した回答に対して、出典や更新日を確認する運用が必要です。
「AIがこう答えた」ではなく、「どの資料を根拠に答えたのか」を確認できる状態にすることが重要です。
AIガバナンスとしてのHuman in the Loop
Human in the Loopは、単なる業務効率化の手法ではありません。AIガバナンスの一部としても重要です。
AIガバナンスとは、AIを組織として安全かつ適切に利用するためのルール、体制、監督、改善の仕組みです。Human in the Loopは、その中で「人間がどこで関与し、何に責任を持つのか」を明確にする役割を持ちます。
説明責任を果たすための記録を残す
AIを業務で使う場合、あとから説明できる状態を作ることが大切です。
特に、顧客対応、採用、評価、契約、法務、財務などの領域では、次のような記録が必要になります。
- AIをどの業務で使ったのか
- どの情報を参照したのか
- 誰が確認したのか
- 誰が承認したのか
- どのような修正を加えたのか
- 最終的にどの内容を採用したのか
これらの記録が残っていれば、問題が起きたときにも原因を追いやすくなります。反対に、記録が残っていない場合、AIの出力そのものよりも「確認したのか、誰が承認したのか」が問題になりやすくなります。
リスクに応じて人間の関与を変える
すべてのAI出力を同じレベルで確認する必要はありません。大切なのは、リスクに応じて人間の関与を変えることです。
たとえば、社内メモの要約であれば、担当者本人が確認すれば十分な場合があります。一方で、社外向けの提案書、契約書、採用評価、顧客への正式回答では、より厳格な確認が必要です。
| リスク区分 | 業務例 | 人間の関与 |
|---|---|---|
| 低リスク | 社内メモの要約、個人用の下書き | 本人確認 |
| 中リスク | 部門内共有資料、社内FAQ回答案 | 担当者または上長確認 |
| 高リスク | 顧客回答、契約、採用、評価、財務関連 | 責任者または専門部門の承認 |
| 利用禁止または慎重対応 | 機微情報、未公開財務情報、法的判断の自動化 | AI利用を避ける、または専門部門判断 |
この分類を作ることで、現場は迷わずAIを使いやすくなります。
Kanataで進めるHITL型のAI運用設計
Human in the Loopを実務に落とし込む際には、AIツールだけでなく、プロンプト、学習データ、承認ルール、チーム運用を組み合わせる必要があります。
多くの業務向けAIツールには、チャット、要約、ナレッジ参照、テンプレート管理などの機能があります。Kanataもその一つであり、AIチャット、AI要約、プロンプトライブラリ、学習データライブラリを組み合わせて、業務ごとのAI運用を設計できます。
ここでは、特定ツールの導入を前提にし過ぎず、HITL型のAI運用を考える際の機能面の見方として整理します。
AIチャットで下書きと論点整理を行う
AIチャットは、業務の初稿作成や論点整理に向いています。
たとえば、問い合わせ回答案、議事録、提案書構成、稟議書の下書き、社内通知文などを作成できます。人間は、AIが作った案をもとに、事実確認や判断に集中できます。
ここで重要なのは、AIチャットを「最終回答を出す場所」ではなく、「人間が判断するためのたたき台を作る場所」として位置づけることです。
プロンプトライブラリで確認観点を標準化する
Human in the Loopでは、人間の確認品質もばらつきます。そのため、確認観点をプロンプトとして標準化しておくことが有効です。
問い合わせ回答であれば、次のような確認観点をプロンプトに含めます。
- 回答は社内ルールに沿っているか
- 不確かな内容を断定していないか
- 顧客に誤解を与える表現がないか
- 必要に応じて担当部門への確認を促しているか
- 文章が丁寧で分かりやすいか
このようなプロンプトをライブラリ化しておけば、担当者ごとに確認基準が変わりにくくなります。Kanataのようにプロンプトをチームで再利用できる環境がある場合は、確認観点の標準化にも使えます。
学習データライブラリで参照情報を統一する
AIの出力品質は、参照する情報によって大きく変わります。
社内規程、業務マニュアル、FAQ、製品資料、過去の議事録などを学習データとして整理しておくことで、AIは業務文脈に沿った回答を出しやすくなります。
ただし、学習データは入れればよいわけではありません。古い資料、重複資料、未承認の資料が混ざると、AIの回答も不安定になります。Human in the Loopでは、学習データを誰が管理し、いつ更新し、どの業務で使うのかを決めることも重要です。
チームごとの運用ルールを作る
AI運用は、個人の工夫だけでは安定しません。チームとして、次のようなルールを決める必要があります。
- どの業務でAIを使ってよいか
- どの情報をAIに入力してよいか
- どの出力は人間の確認が必要か
- どのケースは上長や専門部門にエスカレーションするか
- AIの出力をどこに記録するか
- プロンプトや学習データを誰が更新するか
このルールがあることで、現場は安心してAIを使いやすくなります。
Human in the Loop導入時の注意点
Human in the Loopは有効な考え方ですが、設計を誤ると逆効果になることがあります。
人を入れれば安全になるわけではない
もっとも多い誤解は、「人間が確認すれば安全になる」というものです。
実際には、確認者が何を見るべきか分かっていなければ、AIの誤りは見逃されます。確認者に専門知識がなければ、契約や法務のリスクを判断できません。忙しい承認者に大量のAI出力が流れ込めば、確認は形骸化します。
Human in the Loopでは、人間を入れることよりも、人間が何を確認するのかを明確にすることが重要です。
承認者に負荷が集中しない設計が必要
AI活用が広がると、確認や承認の負荷が一部の人に集中することがあります。
たとえば、すべてのAI出力を部門長が確認する運用にすると、部門長がボトルネックになります。結果として、現場はAIを使わなくなるか、承認を飛ばすようになります。
そのため、リスクに応じて確認レベルを分ける必要があります。低リスク業務は担当者確認、中リスク業務は上長確認、高リスク業務は専門部門確認というように、現実的な負荷で回る設計にすることが大切です。
例外対応ルールを先に決める
AI運用で問題になりやすいのは、通常パターンではなく例外パターンです。
問い合わせ対応であれば、クレーム、返金、契約変更、障害、個人情報、法的な主張などが例外にあたります。稟議であれば、高額案件、通常外の契約条件、複数部門にまたがる判断などが例外です。
例外対応をその場の判断に任せると、担当者によって対応がばらつきます。あらかじめ、どのケースはAIで処理せず人間に回すのか、どのケースは専門部門に相談するのかを決めておく必要があります。
定期的に品質ゲートを見直す
Human in the Loopの設計は、固定されたものではありません。
AIの性能、業務内容、社内ルール、顧客対応方針は変わります。最初は人間の確認を厚くしていた業務でも、運用が安定すれば確認を軽くできる場合があります。逆に、トラブルが起きた業務では、品質ゲートを強化する必要があります。
月次や四半期ごとに、AI出力の修正内容、承認フローの滞留、現場の負担、トラブルの有無を確認し、運用を見直すことが重要です。
Human in the Loopを設計するためのチェックリスト
最後に、Human in the Loopを業務に組み込む際のチェックリストを整理します。
業務選定のチェック
- その業務はAIに任せることで効果が出るか
- 誤った出力が出た場合の影響はどの程度か
- 社外に出る情報を扱うか
- 個人情報や機密情報を含むか
- 法務、契約、財務、人事評価などの高リスク領域か
- まず小さく試せる業務か
役割分担のチェック
- AIが担当する工程は明確か
- 人間が確認する工程は明確か
- 最終判断者は決まっているか
- 承認者は決まっているか
- 例外対応の担当者は決まっているか
- 責任分界が文書化されているか
品質ゲートのチェック
- 何を確認するかが明確か
- 事実確認の方法は決まっているか
- 数字や日付の確認方法は決まっているか
- 表現やトーンの確認基準はあるか
- 高リスク案件のエスカレーション条件はあるか
- 確認履歴を残す方法はあるか
改善運用のチェック
- AI出力への修正内容を振り返っているか
- よくある修正をプロンプトに反映しているか
- 学習データを定期的に更新しているか
- 古い情報を削除または整理しているか
- 現場からのフィードバックを集めているか
- 承認フローが重くなり過ぎていないか
まとめ：HITLはAIを止める仕組みではなく、安心して使うための設計である
Human in the Loopは、AIを制限するための考え方ではありません。AIを業務の中で安心して使うために、人間がどこで関与し、何に責任を持つのかを明確にする設計です。
AIは、下書き、要約、分類、候補提示、論点整理に強みがあります。一方で、判断、承認、説明責任、例外対応は人間が担うべき領域です。
AIに任せ過ぎると、品質や責任が曖昧になります。人が関与し過ぎると、効率が失われます。だからこそ、Human in the Loopでは、AIと人間の役割分担、品質ゲート、承認フロー、責任分界、フィードバックループをセットで設計する必要があります。
まずは、リスクが低く、効果が見えやすい業務から始めるのが現実的です。問い合わせ回答案、議事録、社内文書の要約、稟議書の下書きなど、小さな業務でHITLの型を作ることで、組織全体のAI運用設計に広げやすくなります。
Human in the Loopは、AIに人間を従わせる仕組みではありません。人間が責任を持ちながら、AIの力を業務に組み込むための設計思想です。
Q&A：Human in the Loopを理解するための5つの問い
Human in the Loopとは、AIの出力を人が毎回確認することですか？
必ずしもそうではありません。Human in the Loopは、人間がどの工程で確認・判断・承認するかを設計する考え方です。低リスク業務では本人確認だけでよい場合もあれば、高リスク業務では専門部門の承認が必要な場合もあります。
AIに任せてよい業務と、人が担うべき業務はどう分ければよいですか？
目安として、下書き、要約、分類、候補提示、論点整理はAIに任せやすい領域です。一方で、最終判断、承認、説明責任、例外対応、社外に出す内容の確認は人間が担うべき領域です。
品質ゲートとは何ですか？
品質ゲートとは、AIの出力を次の工程に進める前に、人間が確認するチェックポイントです。事実誤認、社内ルール違反、顧客に出す表現、法務・契約上のリスク、数字や日付の誤りなどを確認します。
Human in the Loopを入れると、業務が遅くなりませんか？
設計を誤ると遅くなります。すべてのAI出力を同じように承認するのではなく、リスクに応じて確認の厚みを変えることが重要です。低リスク業務は軽い確認、高リスク業務は専門部門の承認というように分けると、品質と効率を両立しやすくなります。
HITL型のAI運用を始めるなら、最初に何をすべきですか？
まずは一つの業務を選び、業務フローを分解します。そのうえで、AIが担当する工程、人間が確認する工程、承認が必要な工程、例外対応の条件を決めます。最初から全社展開するのではなく、問い合わせ回答案や議事録作成など、リスクが比較的低く効果を見やすい業務から始めるのが現実的です。
