Difyプロンプトエンジニアリング実践ガイド

プロンプトの品質がすべてを決める

Dify のワークフローがうまく動かないとき、原因の大半はプロンプトにある。
モデルを変えても・ノードを増やしても、プロンプトが曖昧なら精度は上がらない。

プロンプトの基本構造（RCIE フレームワーク）

効果的なシステムプロンプトの4要素:

R — Role（役割）
  「あなたは〇〇の専門家です」
  モデルの振る舞いの基準点を決める

C — Context（文脈・制約）
  「このツールは〇〇向けに作られており、〇〇の目的で使います」
  「〇〇については答えないでください」

I — Instructions（具体的な指示）
  「ユーザーの質問に対して以下の手順で回答してください:
   1. まず質問を1文で言い換える
   2. 根拠を2〜3点挙げる
   3. 結論を1文でまとめる」

E — Examples（例示）
  Few-shot: 良い回答の具体例を1〜3件示す
  Out-of-scope: 答えてはいけないケースの例も示す

実装例（社内 FAQ ボット）

System Prompt:

あなたは株式会社〇〇の社内 FAQ ボットです。
社員からの規程・手続きに関する質問に答えます。

【役割と制約】
- 社内規程・マニュアルに記載されている情報のみ回答してください
- 給与・評価に関する個別の判断はしないでください
- 回答には必ず根拠となる規程名と条番号を引用してください
- 「〜と思います」等の主観的表現は使わないでください

【回答フォーマット】
1. 回答（1〜3文）
2. 根拠（規程名・条番号）
3. 不明点がある場合は担当部署への問い合わせ先を案内する

【回答できない場合】
「該当する規程が見つかりません。人事部（内線XXXX）にお問い合わせください。」
と回答してください。

Chain of Thought（CoT）: 推論させる

CoT が有効なタスク:
  - 複数ステップの判断が必要な問題
  - 計算・比較・条件分岐を含む処理
  - 複雑な文書の解析・要約

❌ CoT なし（精度が低くなりやすい）:
  「この申請内容を承認すべきか判断してください」
  → LLM が結論だけを返し、根拠が曖昧になる

✅ CoT あり:
  「この申請内容を以下のステップで分析してください:
  Step 1: 申請者の条件（年収・勤続年数）を確認する
  Step 2: 社内規定の条件と照合する
  Step 3: 照合結果から承認可否の理由を3点挙げる
  Step 4: 最終的な推奨判断（承認/要確認/否認）を述べる」

ゼロショット CoT

シンプルな CoT 誘導フレーズ:
  「ステップ・バイ・ステップで考えてください」
  「結論を出す前に、考慮すべき要素を列挙してください」
  「判断の根拠を3点挙げてから、結論を述べてください」

Dify での実装:
  LLM ノードのプロンプト末尾に追加するだけでOK
  難しい推論タスクには効果が大きい

Few-shot: 例示で精度を安定させる

Few-shot が特に有効なケース:
  - 出力フォーマットを固定したい
  - 特定のトーン・文体を維持したい
  - ドメイン固有の表現（専門用語・社内用語）を使わせたい

Few-shot の書き方:
  【例1】
  入力: 「有給休暇を来週3日間取りたい」
  出力:
    申請内容: 有給休暇 3日間
    申請期間: 来週（具体的な日付を確認してください）
    必要書類: 休暇申請フォーム（人事システムから申請）
    申請期限: 取得希望日の3営業日前まで

  【例2】
  入力: 「育児休業を取得したい」
  出力:
    申請内容: 育児休業（育休）
    申請期間: 出産予定日から最長2年
    必要書類: 育児休業申出書（人事部から取得）
    申請期限: 休業開始の1ヶ月前まで

Few-shot の注意点:
  - 例は2〜5件が最適（多すぎると逆効果）
  - 良い例と悪い例の両方を示すと効果的
  - 例はシステムプロンプト内に埋め込む（変数化も可能）

出力フォーマットの固定化

JSON 出力の安定化

❌ 不安定な指示:
  「JSONで出力してください」

問題:
  モデルによって:
  - マークダウンコードブロックで囲む/囲まない
  - キー名が違う（"name" vs "fullName"）
  - null を "" や 0 で返す

✅ 安定する指示:
  「以下の JSON スキーマに従って出力してください。
  コードブロック・説明文は一切不要です。JSONのみ出力してください。

  {
    "category": "string（技術系 or ビジネス系 or その他）",
    "priority": "integer（1=高 2=中 3=低）",
    "summary": "string（50文字以内）",
    "tags": ["string", "string"]
  }」

Dify の実装ヒント:
  JSON スキーマ出力は「構造化出力（Structured Output）」機能を使うと
  さらに安定する（GPT-4o 系で利用可能）

マークダウン出力の制御

マークダウンを使いたい場合（Web 表示向け）:
  「回答は以下の形式で Markdown を使ってください:
  ## セクション名
  - 箇条書き（3点以内）
  **重要なキーワード**は太字にする」

マークダウンを使いたくない場合（プレーンテキスト向け）:
  「マークダウン記号（#・*・`等）は使わず、
  プレーンテキストで回答してください」

トークン効率を上げる指示の書き方

冗長なプロンプトの削減テクニック:

❌ 冗長:
  「ユーザーから質問を受け取ったとき、その質問を注意深く読み取り、
  内容を理解した上で、適切な回答を生成してください。
  回答は丁寧な敬語を使い、わかりやすい表現にしてください。
  また、不明な場合は正直に答えられないことを伝えてください。」

✅ 簡潔（同等の効果）:
  「敬語で簡潔に回答。不明な場合は「確認が必要です」と答える。」

削減のポイント:
  - LLM が「当然知っている」こと（「日本語で答えて」等）は書かない
  - 「注意深く」「丁寧に」等の形容詞は具体的な指示に置き換える
  - 同じ内容を繰り返さない

プロンプトの反復改善サイクル

1. 基準テストセットを作る
   - 代表的な質問20件（成功例・失敗例・エッジケースを含む）
   - 期待する回答を記録しておく

2. 現状のプロンプトで全テストを実行
   - Dify のバッチテスト機能を使う
   - 出力を期待回答と比較する

3. 失敗パターンを分類する
   A: フォーマットが違う → 出力形式の指示を強化
   B: 内容が足りない → Few-shot 例を追加
   C: 全然違うことを答える → ロール・制約の見直し
   D: 専門用語が違う → ドメイン固有の例を追加

4. 修正して再テスト
   - 1回に1箇所だけ変更する（変化を追跡するため）
   - スコアが上がれば確定、下がれば元に戻す

5. Dify のバージョン管理で変更を保存
   → DSL エクスポートで各バージョンをバックアップ

Dify 固有のプロンプトテクニック

会話変数の活用

Chatflow で会話の文脈を蓄積する:

例（転職相談ボット）:
  Turn 1: ユーザーが業界を言う → conversation.industry に保存
  Turn 2: ユーザーが経験年数を言う → conversation.years に保存
  Turn N: すべての変数をまとめてプロンプトに挿入

LLM ノードのプロンプト:
  「ユーザー情報:
   業界: {{conversation.industry}}
   経験年数: {{conversation.years}}
   上記を踏まえて転職アドバイスをしてください。」

メリット: 毎ターン同じ情報を再入力させなくて済む

テンプレートノードとの組み合わせ

複数変数を組み合わせてプロンプトを動的生成:

Template ノードで:
  「{{product_name}}（{{category}}）の説明文を生成してください。
   ターゲット: {{target_audience}}
   字数: {{word_count}}文字以内
   トーン: {{tone}}」

→ 変数を変えるだけで異なる商品・ターゲット・トーンに対応
→ LLM ノードには整形済みプロンプトが渡される

参考：関連ドキュメント

RAG精度チューニングガイド — ナレッジ検索精度の改善
ハルシネーション対策ガイド — 事実誤認・引用ミスへの対処
Difyアンチパターン集 — プロンプト設計の失敗例
ノード一覧と制御フロー — Template・Variable Assigner ノードの詳細