Human-in-the-Loopの概念をDifyに落とし込み、AIの暴走を防ぐ安全設計を構築する

目次

はじめに

LLMの自動化を進める中で、「AIが勝手に間違った顧客対応をしたらどうしよう…」「重要な決裁をAI任せにするのは怖い」と不安に感じたことはありませんか?
本記事を読めば、その不安を解消し、Difyで安全にAIを運用するための「Human-in-the-Loop(HITL)」の具体的な実装手順・アプローチが分かります。

顧客サポートやデータ入力など、AIによる業務の「完全自動化」は理想的ですが、LLM特有のハルシネーション(もっともらしい嘘)や、想定外のエラーのリスクが常につきまといます。

この課題を解決するのが、Human-in-the-Loop(HITL)という設計モデルです。人間がAIのプロセスの「輪(Loop)」の中に入り、最終的な判断や修正を行うことで、重大なエラーを劇的に削減できます。本記事では、HITLの基本概念から、Difyを使った具体的な実装アプローチ、そして完全自動化との使い分けの基準を解説します。

🎉 朗報:Difyクラウド版でも待望の利用開始!
これまで「人間の入力」ノードを利用したHITL構築は、セルフホスト(オンプレミス)版などの一部環境に限られていました。しかし、最近のアップデートによりDifyクラウド版(SaaS版)でも標準機能として利用可能になりました。これにより、サーバー構築なしで誰でも簡単に、高度で安全な承認プロセスを実装できるようになっています。



1. 完全自動化AIの課題:思わぬミスや暴走のリスク

1.1 なぜ「完全自動化」は危険なのか

AIエージェントやLLMを用いたシステムでは、ユーザーの入力を受け取り、AIが考えて、そのままシステムやユーザーへ出力(実行)する「完全自動化」がよく用いられます。

しかし、このプロセスには大きなリスクが潜んでいます。

ハルシネーションと文脈の誤認
LLMは確率に基づいてテキストを生成するため、事実とは異なる情報(ハルシネーション)を出力したり、ユーザーの複雑な意図を誤解して不適切な対応(例:返金対象外の顧客に返金処理をしてしまう等)を実行してしまうことがあります。

結果として、「完全自動化」が危険なのは、AIが「常識や文脈を無視したミス」や「もっともらしい嘘(ハルシネーション)」をつく可能性があり、その結果生じる全責任を最終的に負うのはAIではなく利用者本人だからです。

1.2 具体例: oversight(監視)がないとどうなるか

以下のカスタマーサポートの例を考えてみましょう。

ユーザーの問い合わせ:

「製品Aを購入したのですが、思っていたものと違いました。返金条件の『未開封』ではないですが、特別に返金してくれませんか?」

完全自動化AIの対応:

「申し訳ございません。お客様のご不満をお詫びし、特別に返金処理を実行いたしました。」(※勝手に決済システムを操作)

AIが「顧客に寄り添う」ことを優先しすぎた結果、企業のルールを破ってシステム上で重大なアクションを実行してしまう恐れがあります。


2. Human-in-the-Loop(HITL)とは?

ずばり、Human-in-the-Loop(HITL)とは、AIシステムの処理プロセスの一部に「人間(Human)」の判断・介入を組み込む(in the Loop)設計手法のことです。

AIにすべてを丸投げせず、重要な局面で人間がチェックや判断を行う「共同作業のスタイル」のことを言います。

2.1 人間とAIの協働アプローチ

完全にAIに任せるのではなく、「AIが提案・下書きを行い、人間が確認・承認した上で実行する」というプロセスを作ります。OpenAIやAnthropicなどの主要なAI企業も、リスクの高いタスクにおいてはこのHITLのアプローチを強く推奨しています。

完全自動化: ユーザー入力 → AIが処理・決定 → 即時実行(API操作など)
HITL:      ユーザー入力 → AIが下書き・提案 →【人間が確認・修正・承認】→ 実行

2.2 HITLの強み

  • 安全性の担保: 誤った出力や危険な操作を、システムに反映される前に未然にブロックできる
  • 品質の向上: AIの出力ベースに人間が少し手直しを加えるだけで、ゼロから作業するより圧倒的に早く高品質な成果物が出せる
  • 責任の所在が明確: 最終的な「実行ボタン」を押すのは人間であるため、業務上の責任とガバナンスを保てる

3. DifyでHITLを実装する3つのアプローチ

DifyでHITLの仕組みを実現するには、大きく分けて以下の3つのアプローチがあります。

アプローチ1:従来手法(外部ツール連携)

Difyのワークフローを使って「AIが下書きを作成して保存する」ところまでを自動化し、SlackやMake等の外部システムへWebHookを飛ばして人間が確認・承認した後に、本番へ反映させる手法です。

  • 特徴: 既存の社内チャットツール等で完結できる反面、外部ツール連携の手間と複雑な設定が必要です。

アプローチ2:従来手法(プロンプトでの疑似確認)

Difyのチャットフローやエージェントツールにおいて、重要なアクション(メール送信やAPI呼び出し)を実行する前に、明示的にユーザーに「確認」を求めるようプロンプトを設計する手法です。

  • 特徴: 「〇〇を実行してもよろしいですか?」とユーザーに確認を取り、YESの場合のみ実行してください と指示する手軽な方法ですが、プロンプト指示ベースのためAIが指示を無視して勝手に実行してしまうリスクをゼロにはできません。

アプローチ3:最新の最適解(Dify標準「人間の入力」ノード)

Difyのワークフロー/チャットフロー上に組み込まれた、一時停止と承認を強制する専用ノードです。

  • 特徴: 外部システム不要でDify単体で完結し、AIのプロンプト解釈に依存せず「人間がボタンを押すまでシステム的に絶対に先へ進まない」という強固な安全性を保証します。

👉 次章(第4章)では、この最新の最適解である「人間の入力ノード」を使ったチャットフローの具体的な実装手順を解説します。


4. 実践:Dify標準機能の「人間の入力」ノードを使った承認チャットフロー

Difyでは先日、公式コミュニティでも大々的に発表されたv1.13.0の大型アップデート(リリースノート)において、待望の「人間の入力(Human Input)」ノードが搭載されました。

これにより、これまでのように外部ツール(SlackやMake)をわざわざ経由・連携させずとも、Difyのチャットフロー内に直接、安全で強固な承認プロセス(HITL)を組み込むことができるようになっています。

人間の入力ノードとは?
AIの自動処理の途中で「一時停止(待機)」させ、人間が画面上で内容を確認・修正・承認して初めて次の処理に進む、という機能を持ったノードです。これ1つでDify内に承認チャットフロー(Human-in-the-Loop)を直接組み込むことができます。

ここでは、ビジネスメール作成を例に、「AIが下書きを作成し、人間が承認・修正してから送信する」という最も本質的なHITLの構築手順を解説します。

チャットフロー全体像

[開始:ユーザー入力(送信先、目的、ポイント)]
    ↓
[LLM(下書きの自動作成):条件に従い、ビジネスメールの下書きを生成]
    ↓
==== ここが Human-in-the-Loop ====
[人間の入力:人間が下書きを確認・修正・承認する]
   ┣━ (APPROVE) ━ [HTTPリクエスト:メール送信API等へ連携]
   ┣━ (REJECT) ━ [出力:実行をキャンセル・記録]
   ┗━ (TIMEOUT) ━ [今回は未接続]

4.1 Step 1:開始ノードの設定(ユーザー入力)

Difyで「チャットフロー」タイプのアプリを作成し(例:「メール承認フロー」)、開始ノードに以下の入力フィールドを設定します。

  • recipient(短文):送信先のメールアドレス等
  • purpose(短文):メールの目的
  • key_points(長文):メールに含めたいポイント

4.2 Step 2:「下書きの自動作成」ノードの設定(LLM)

開始ノードの次に「LLM」ノード(ノード名:下書きの自動作成)を追加し、メールの下書きをAIに作成させます。

実装フロー(LLMノード)

システムプロンプト(SYSTEM):

あなたはビジネスメール作成の専門家です。

##ルール

  1. 丁寧かつ簡潔なビジネスメールを作成してください
  2. 件名と本文を分けて出力してください
  3. 敬語を正しく使用してください
  4. 相手に求めるアクションを明確にしてください
  5. 差出人名:田中太郎
    会社名:ノーコード商事
    連絡先:tarou123456@gmail.com

ユーザープロンプト(USER)の工夫:
開始ノードで受け取った変数を埋め込みます。

以下の条件でビジネスメールを作成してください。

送信先: {{ recipient }}
目的: {{ purpose }}
ポイント: {{ key_points }}

4.3 Step 3:「人間の入力」ノードの追加と設定(Loop部分)

LLMが生成した文章をそのまま送信するのではなく、ここで直接人間に確認を求めます。LLMノードの次に「人間の入力」ノードを追加します。このノードこそが、チャットフローを一時停止させ、人間の判断を介入させるHITLの要となります。

実装フロー(人間の入力ノード)

【具体的な設定手順と例】

  1. 配信方法(通知の手段)
    • 設定例: 担当者のメールアドレスを指定、またはUI上の待機通知を利用します。
      ※現在Difyでは実行画面上の通知が基本ですが、将来的には外部連携での通知トリガーとなる予定です。
  2. フォームコンテンツ(プレビュー画面の構築)
    • 人間が「何を見て判断するか」を設定します。入力フィールドに、前のステップで生成された変数や入力内容をテキストとして埋め込みます。
    • 設定例:
      以下の内容でメールを送信してよろしいですか?

      【宛先】 {{ recipient }}
      【目的】 {{ purpose }}
      【AIが作成したメール文面】 {{ 下書きの自動作成の出力テキスト (text 変数など) }}

      このように設定することで、担当者はAIの生成結果とその背景(宛先や目的)をワンストップで確認・修正できます。
  3. ユーザーアクション(判断ボタンの設定)
    • 担当者がクリックする「ボタン」と、分岐ルートを定義します。
    • 設定例:
      • アクション1:Approve(表示名:承認して送信)
      • アクション2:Reject(表示名:否認)
    • Difyの「人間の入力」ノードには、このユーザーアクションに応じた「分岐(ブランチ)」機能がノード自体に備わっています。 わざわざ別の条件分岐ノードを追加しなくても、ボタン結果ごとに線を分けることができます。
  4. タイムアウト(時間切れ時の処理)
    • 人間が一定期間対応しなかった場合の安全装置です。画像では「3日間」でタイムアウトするように設定されています。
    • 設定例: 3日 に設定。
    • タイムアウト後のルート(TIMEOUTの青い端子)を、「管理者にアラートメールを飛ばす」ノードや、「処理を安全に破棄する」ノードに繋いでおくことで、未承認のまま放置されるリスクを防ぎます。

4.4 Step 4:判断後の後続処理(直接ルーティング)

「人間の入力」ノードで担当者が下した判断(ボタンのクリック)に応じて、直接それぞれのノードへと線を繋ぎます(個別のIF/ELSEノードの配置は不要です)。

1. 「APPROVE」ルートの設定(承認時)
このルートの先には、「HTTPリクエスト」ノードや各種連携ツールノードを繋ぎ、実際にメールを送信する処理を配置します。

実装フロー(httpリクエスト)
  • 【メール送信(HTTPリクエスト)の設定のポイント】
    ※本記事のメインテーマはHITL(承認プロセス)の構築であるため、外部API連携の詳細な設定手順は割愛します。
    • ポイント: HTTPのBody(JSON等)に組み込む「本文(text)」の変数には、画像のように前のステップ(LLMノード等)から出力された変数(例:下書きの自動作成の出力テキストなどを適切に指定して、送信データを構築してください。

2. 「REJECT」ルートの設定(否認時)
差し戻し(否認)と判断された場合は、メール送信等のアクションを起こさずにフローを終了させます。

  • 【「出力」ノードの設定例】
    • フローの最後に「出力」ノード(チャットフローの回答ノード等)を繋ぎます。
    • 単に終了させるだけでなく、「終了時の状態」を変数として出力・記録しておくのがおすすめです。
    • 値の設定: {{ 人間の入力ノードの __action_id }} を記録するように設定します(値は Reject となります)。
    • ※補足: 単に終了させるだけでなく、この「REJECT」ルートを最初の「LLM(下書きの自動作成)ノード」へ再び繋ぎ直し、人間がテキストで修正指示を入力してAIに文面を再作成(ループ)させるような高度な構成も可能です。
実装フロー(出力ノード)
実装フロー(出力ノード)

💡 このチャットフローのメリット

Dify単体で「AIの処理を一時停止(待機)し、人間の操作をトリガーにして再開する」という理想的なHITLが完成します。担当者はDifyのUIからフォームを確認し、テキストエリアでAIの回答を直接手直しした上で「承認」ボタン(ユーザーアクション)をクリックするだけで処理を進められるため、「AIの暴走を防ぐ確実な安全性」と「ゼロから作業するよりも圧倒的に早い効率化」を両立できます。


5. 完全自動化との比較:どちらを使うべきか

HITLと完全自動化には、それぞれメリットとデメリットがあります。業務の性質に合わせて使い分けることが重要です。

5.1 比較表

比較項目Human-in-the-Loop (HITL)完全自動化 (Fully Automated)
安全性・正確性非常に高い(人間が担保)AIの精度に依存(ハルシネリスクあり)
処理スピード遅い(人間の確認を待機するため)非常に早い(即時実行)
労働コスト削減70〜80%削減(確認作業は残る)100%削減(ほぼ放置可能)
適したタスク契約書の作成、顧客への返金処理、重要メールの送信社内FAQチャット、データ整理、アイデア出し

5.2 使い分けガイド

状況おすすめ
間違えた時のビジネスインパクトや損害が非常に大きいHITL(必ず承認プロセスを挟む)
ユーザーからのクレームや感情的な対応が含まれるHITL(人間の温かみやニュアンスの調整が必要)
社内向けの単純な質問応答(マニュアル検索など)完全自動化
数万件単位の大量のデータ処理や分類作業完全自動化

💬 実践Tips: はじめは必ず「HITL」からスタートしてください。「AIの精度が十分に高く、人間が修正する回数がほぼゼロになった」と実証データを取れてから、段階的に「完全自動化」へ移行するのが最も安全なAI導入のステップです。

5.3 HITLが効果を発揮するケース

具体的に、どのようにHITLが活用されるか例を見てみましょう。

  • 広報・マーケティング: AIが作成したSNS投稿文やプレスリリースを、人間が炎上リスクがないか最終確認して投稿。
  • 営業・経理: AIが読み取った請求書や見積もりの金額データ(OCR)を、人間が目視でダブルチェックしてからシステムに登録。
  • エンジニア: AIが生成したプログラムコードを、人間がレビュー・承認してからGitHub等へ反映。

6. まとめ

  • 課題: LLMの「完全自動化」は、ハルシネーションや不適切な判断により重大なインシデントを引き起こすリスクがある。
  • 解決策: Human-in-the-Loop(HITL)AIが下書きし、人間が確認・承認・修正する運用モデルを採用する。
  • Difyでの実装: 外部ワークフロー(Make/Slack)と連携した承認プロセスの構築や、チャットプロンプトでの対話的な確認を組み込む。
  • 使い分けの基準: リスクの高いタスクはHITL、リスクの低く大量処理が必要なタスクは完全自動化。まずはHITLから小さく始める。

AIは「人間の仕事を奪う魔法の杖」ではなく、「人間の生産性を極限まで高める強力なアシスタント」です。HITLの設計を取り入れることで、安全性を保ちながらAIの恩恵を最大限に引き出すことができます。ぜひ、Difyでのチャットフロー構築時に「人間が確認するステップ」を意識してみてください。


最後に

私たちは、単にシステムを組むだけの開発会社ではありません。低コストで高品質なAIツールの構築から、ROI(投資対効果)を最大化する導入ロードマップの策定、社内スタッフが自らAIを運用・改善できる体制の構築まで、AI導入の成功に必要なすべてを最初から最後まで丸ごと支援いたします。

実は、ご相談いただく方のほとんどが「何が分からないかも分からない」という状態からのスタートです。構想段階でも、ただのアイデアベースでも構いません。
まずは、あなたのお困りごとをそのまま聞かせていただけませんか?貴社のビジネスを加速させるパートナーとして伴走いたします。
👉 無料オンライン相談で、最適な導入プランを相談する

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次