🛡️
概念 #Dify #ハルシネーション #信頼性 #RAG #品質保証 #実践 📚 Dify実践ガイド

Difyハルシネーション対策ガイド

LLMが「もっともらしい嘘」をつくハルシネーション。Difyで使える引用強制・「わからない」設計・出力検証ノード・Human-in-the-loopによる防御設計を体系整理。

ハルシネーションとは何か

ハルシネーション（Hallucination）:
  LLM が事実と異なる情報を「もっともらしい文体」で出力する現象

種類:
  ① 事実誤認: 実在しない人物・法律・数値を生成する
    例: 「消費税は2026年から15%になりました」
  ② 引用ミス: 実在する文書の内容を誤って引用する
    例: 「就業規則第10条によると〜（実際は第15条の内容）」
  ③ 存在しない情報の作出: ナレッジにない情報を創作する
    例: 「当社のXXプランには〇〇特典があります」（実在しない）
  ④ 数値の誤算: 計算を LLM に任せたときの誤答
    例: 「割引後の価格は〇〇円です」（計算ミス）

特性:
  - 文体・形式は完全に正しいため、一見して嘘とわからない
  - モデルが「知らない」のではなく「知っているふり」をする
  - 高度なモデルでも発生する（完全に防ぐことはできない）
  → 「発生前提」で設計を組み立てる

対策1: 引用強制（RAG + 引用表示）

最も効果的なハルシネーション対策は
「ナレッジにある情報のみ回答させる」こと。

プロンプトでの引用強制:
  System Prompt に以下を追加する:

  「回答は提供されたコンテキスト情報のみに基づいて生成してください。
   コンテキストに記載のない情報は答えないでください。
   回答の最後に必ず（出典: [文書名] [条番号/ページ]）を記載してください。」

効果:
  - LLM が「コンテキスト外」から情報を作ることを抑制できる
  - 引用先が明記されることで、ユーザーが確認しやすくなる
  - 出典がない場合、ユーザーが気づくことができる

Dify での設定:
  Knowledge Retrieval ノードの
  「Citation and Attribution」を有効にする
  → 回答に自動で出典（ドキュメント名・チャンク）が表示される

対策2: 「わからない」と答えさせる設計

ナレッジに情報がない場合に「知ったかぶり」を防ぐ。

プロンプト:
  「提供されたコンテキストに質問の答えが含まれていない場合、
   『この質問については情報が見つかりませんでした。
   担当部署（TEL: XXXX）にお問い合わせください。』
   と回答してください。
   絶対に情報を推測・創作しないでください。」

よくある失敗:
  「不明な場合は一般的な情報で答えてください」と指示する
  → LLM が「一般的」な情報をハルシネーションで生成する

ワークフローでの実装:
  [Knowledge Retrieval]
    │ 取得チャンク数が 0 の場合
    ▼
  [Conditional Branch]
    ├── チャンク数 > 0: [LLM: 回答生成]
    └── チャンク数 = 0: [Template: 「情報が見つかりません」メッセージ]

→ LLM を使わずに固定文言を返すことでハルシネーションを完全排除

対策3: 出力検証ノード（Code + 再試行）

LLM の出力を次のノードで検証し、問題があれば再生成する。

パターン1: フォーマット検証
  [LLM: JSON 生成]
    ↓
  [Code: JSON パース検証]
    ├── パース成功: → 次の処理へ
    └── パース失敗: → [LLM: 再生成（エラー内容をフィードバック）]

Pythonコード例:
  ```python
  import json

  raw = variables.get("llm_output", "")
  
  # コードブロックを除去
  cleaned = raw.strip()
  if cleaned.startswith("```"):
      lines = cleaned.split("\n")
      cleaned = "\n".join(lines[1:-1])

  try:
      parsed = json.loads(cleaned)
      required_keys = ["category", "priority", "summary"]
      missing = [k for k in required_keys if k not in parsed]
      if missing:
          return {"valid": False, "error": f"Missing keys: {missing}"}
      return {"valid": True, "data": parsed}
  except json.JSONDecodeError as e:
      return {"valid": False, "error": str(e)}

パターン2: 数値範囲の検証 LLM が出力した数値が「ありえない値」でないかチェック

score = float(variables.get("sentiment_score", -1))
if not (0.0 <= score <= 1.0):
    return {"valid": False, "error": "Score out of range"}
return {"valid": True, "score": score}

---

## 対策4: LLM に計算させない

数値の計算を LLM に任せると誤答率が高い。

NG 例: 「月額10,000円 × 12ヶ月 + 消費税10% の合計を計算してください」 → LLM が電卓代わりに使われ、桁数が増えると誤答が増える

OK 設計: [LLM: 数値の抽出] ← テキストから数値を取り出すのは LLM が得意 │ “monthly_fee”: 10000, “months”: 12 ▼ [Code: Python で計算] ← 計算は必ず Code ノードで │ total = 10000 * 12 * 1.1 = 132000 ▼ [LLM: 結果の文章化] ← 数値を読みやすい文に整形するのは LLM が得意 │ 「合計金額は132,000円（税込）です」

鉄則: LLM に任せるのは「テキストの理解・生成・分類」 計算・ソート・データ操作は Code ノードで処理する


---

## 対策5: 時事情報・最新情報を扱う場合

LLM の学習データには「知識カットオフ」がある。 2026年現在の事実を「学習していない可能性がある」モデルもある。

ハルシネーションが起きやすいケース:

  • 「最新の法改正」を質問する
  • 「現在の為替レート・株価」を質問する
  • 「最近発表された新製品」を質問する

対策:

  1. 最新情報が必要なケースは RAG（ナレッジベース）で補う → 社内の最新規程集・価格表をナレッジに登録して随時更新

  2. HTTP Request ノードで外部 API から最新データを取得する → 為替レートなら OpenExchangeRates API → 法令情報なら e-Gov 法令 API（日本）

  3. プロンプトで時制を明示する 「あなたの学習データは2025年8月以前です。 それ以降の情報は提供されたコンテキストのみを参照してください。」


---

## 対策6: Human-in-the-loop（最終防衛ライン）

自動化ができても、高リスクな出力は必ず人間が確認する。

リスクレベル別の Human 関与設計:

低リスク（SNS投稿の下書き・社内 FAQ の回答草案）: → 自動出力 + 「AI が生成しました。ご確認の上ご利用ください」の表示

中リスク（顧客への提案書・クレーム対応メール）: → 担当者が確認・編集してから送信 → Human Input ノードで承認ボタンを挟む

高リスク（契約書の法的条項・診断結果・財務データ）: → 専門家（弁護士・医師・会計士）がレビューして最終判断 → AI の出力には「参考情報」のラベルを必ず表示

Dify での Human Input ノード実装: [LLM: 契約書レビュー] ↓ [Human Input: 「この内容で送信してよいですか？」] ├── 承認: → [HTTP Request: 送信処理] └── 差し戻し: → [LLM: 修正指示に基づいて再生成]


---

## ハルシネーション対策チェックリスト

RAG を使う場合: □ Knowledge Retrieval の Citation を有効にした □ コンテキスト外の情報を答えないよう System Prompt に明記した □ チャンク数が0のときの「情報なし」応答を設計した □ 類似度閾値を適切に設定して無関係なチャンクを除外した

計算・数値処理: □ 数値計算は Code ノードで処理している □ LLM の出力数値を Code ノードで範囲チェックしている

時事情報・最新情報: □ 最新情報が必要な箇所はナレッジを定期更新している □ または HTTP Request ノードで外部 API から取得している

出力品質: □ 出力フォーマットの検証（JSON パース等）を実装した □ 検証失敗時の再生成フロー（またはエラーメッセージ）がある

Human-in-the-loop: □ リスクレベルに応じた人間の確認フローを設計した □ AI 生成物であることをユーザーに明示している


---

## ハルシネーションを「ゼロ」にすることはできない

重要な前提認識:

LLM の確率的な性質上、ハルシネーションを 完全にゼロにすることは現時点では不可能。

「ゼロにする」ではなく「リスクをコントロールする」設計が重要:

許容できるリスク（コスト < 便益）: SNS 下書き・アイデア出し・情報整理補助 → 多少の誤りはユーザーが確認できる

許容できないリスク（コスト > 便益）: 医療診断・法的判断・財務情報・個人への通知 → 人間の最終確認を必ず挟む

設計哲学: 「AI は素案を作り、人間が最終判断する」 この分業が、現時点での最善設計。


---

## 参考：関連ドキュメント

- [Difyプロンプトエンジニアリング実践ガイド](concepts_dify_prompt_engineering.md) — 引用強制・「わからない」設計のプロンプト
- [RAG精度チューニングガイド](concepts_dify_rag_tuning.md) — 検索精度を上げてハルシネーションを減らす
- [Difyアンチパターン集](concepts_dify_antipatterns.md) — AP-3（Human省略）・AP-7（LLMに計算させる）
- [Difyでできること・できないこと](concepts_dify_intro_limitations.md) — LLM の根本的な限界
📚 Dify実践ガイド 11件
  1. 1. ⚠️Difyアンチパターン集（設計・プロンプト・RAG・運用の落とし穴）
  2. 2. ✅Dify本番リリース前チェックリスト＆運用設計ガイド
  3. 3. ✍️Difyプロンプトエンジニアリング実践ガイド
  4. 4. 🔍DifyのRAG精度チューニングガイド
  5. 5. 🛡️Difyハルシネーション対策ガイド
  6. 6. 🔗Dify×n8n連携ガイド（AIと外部サービスをつなぐオーケストレーション）
  7. 7. 🖥️Difyセルフホスト本番構成ガイド（Docker・セキュリティ・スケーリング）
  8. 8. 🏢Dify Enterprise機能ガイド（SSO・RBAC・監査ログ・マルチワークスペース）
  9. 9. 👨‍💻エンジニア向けDifyガイド（API統合・CI/CD・テスト自動化）
  10. 10. 💼ビジネスパーソン向けDifyガイド（ノーコードで始めるAI活用）
  11. 11. 🚀スタートアップ向けDifyガイド（最小コストでAI機能を最速でリリース）

出典: Dify公式ドキュメント / LLMハルシネーション対策事例