はじめに
プロダクトマネージャーとして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