Difyで実現する「ハルシネーション抑制」のアーキテクチャ設計（プロンプト分割×自己採点）

はじめに

プロダクトマネージャーとしてAI導入プロジェクトに関わる中で、**「プロンプトエンジニアリングの限界」**を感じることはないでしょうか。

「あなたは優秀なコンサルタントです」と役割を与えたり、Few-Shotで例示を与えたりしても、業務レベルの複雑なタスクではどうしてもハルシネーション（もっともらしい嘘）や出力の揺らぎが発生します。

本記事では、ノーコードツール**「Dify」を活用し、「プロンプト分割（Chain of Thought）」と「自己採点（Self-Correction）」**を組み合わせることで、ハルシネーションを一桁％台まで抑制した実装事例を紹介します。

課題：シングルプロンプトの限界

LLM（大規模言語モデル）に「抽出・分析・生成」といった複数の認知タスクを一度に要求すると、処理精度が著しく低下します。

• 認知負荷の増大: 指示が長くなるほど、後半の指示が無視されやすくなる。
• コンテキストの汚染: 不要な情報まで参照してしまい、回答がブレる。

これらはプロンプトの書き方ではなく、「アーキテクチャ（構造）」の問題です。

解決策：Difyによる構造化設計

解決策として、Difyのワークフロー機能を用い、処理を以下の3つのフェーズに分割・構造化しました。

1. プロンプト分割（Decomposition）

1つの巨大なプロンプトではなく、タスク単位でLLMノードを分割し、リレー形式で処理させます。

• Step 1: Fact Extraction（事実抽出）
  • 入力データから、数値・固有名詞などの「事実」のみを抽出させ、JSON形式で出力する。推論は禁止。
• Step 2: Logic Construction（論点整理）
  • 抽出された事実（JSON）のみを入力とし、比較・分析を行う。
• Step 3: Drafting（ドラフト生成）
  • 分析結果を元に、最終的な回答文章を生成する。

2. 検査工程（Verification Workflow）

生成された回答をそのままユーザーに返すのではなく、**「検査用LLM」**を通します。
ここでは、「禁止ワードが含まれていないか」「推測で断定していないか」などをチェックさせ、NGの場合は修正ループを回します。

3. 自己採点（Self-Correction）

出力の品質を安定させるため、LLM自身にスコアリングを行わせます。

# スコアリングプロンプト例
以下の観点で出力内容を0〜5点で採点せよ。
- 論理性：事実に基づいているか
- 一貫性：矛盾がないか
- 安全性：推測を含んでいないか

合計スコアが15点未満の場合は、改善点を挙げて再生成せよ。

/////////////////////////////////////////////////////

このループをワークフローに組み込むことで、人間がレビューするコストを大幅に削減できました。

実装結果
このアーキテクチャを導入した結果、以下の改善が見られました。

ハルシネーション率: 導入前 約40% → 導入後 5%未満

回答の安定性: 出力フォーマットの崩れがほぼ消滅

メンテナンス性: プロンプトが機能ごとに分割されているため、修正の影響範囲が限定的

まとめ
AI導入においては、「魔法のようなプロンプト」を探すよりも、**「堅実なワークフロー設計」**を行う方が、結果として近道になります。 Difyのようなツールを活用し、LLMを「チャット相手」ではなく「処理モジュール」として扱う設計思想が重要です。

▼ 実装テンプレート（プロンプトセット）の配布
本記事で解説した「分割プロンプトの構成案」や「自己採点ロジック」「禁止事項チェックリスト」など、実務で即利用できる設計図（プロンプトセット）をnoteで公開しています。

自力での検証時間をショートカットしたい方は、以下を参照してください。

https://note.com/quick_fox2970/n/n86ba577c0868