Prompt 設計規範 – System Prompt の構造化・ロール設定・出力制約・Few-shot・変数注入
Dify で高品質なアプリケーションを構築するうえで、Prompt 設計はアプリの振る舞いを決定づける最も重要な工程です。本記事では、企業向け AI アプリケーションにおける Prompt 設計の標準的な手法を、Dify の機能と紐づけて実践的に解説します。
1. Prompt 設計の基本原則
1.1 「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ
現代の LLM アプリケーション開発では、単一の Prompt 文字列を工夫するだけでは不十分です。Dify における Prompt 設計は以下の要素を統合的に設計するコンテキストエンジニアリングとして捉える必要があります。
| 要素 | Dify での対応機能 | 役割 |
|---|---|---|
| System Prompt | アプリの「指示」欄 | AIの振る舞い・制約の定義 |
| User Input | ユーザー入力変数 | 動的な入力の受け取り |
| Context | Knowledge Base 連携 | 外部知識の注入 |
| Conversation History | 会話メモリ設定 | 過去のやり取りの維持 |
| Variables | 会話変数・環境変数 | 動的パラメータの管理 |
1.2 企業向け Prompt の3大要件
- 再現性: 同じ入力に対して安定した出力が得られること
- 保守性: チームメンバーが読んで理解・修正できること
- 拡張性: 要件変更時に部分的に修正できる構造であること
2. System Prompt の構造テンプレート
2.1 推奨構造
System Prompt は以下の6つのセクションで構造化することを推奨します。
# ロール定義
あなたは{{role_name}}です。{{role_description}}
# タスク定義
以下のタスクを実行してください:
- {{task_1}}
- {{task_2}}
# 入力仕様
ユーザーから以下の情報が提供されます:
- {{input_description}}
# 出力仕様
以下のフォーマットで回答してください:
{{output_format}}
# 制約条件
- {{constraint_1}}
- {{constraint_2}}
- 情報が不足している場合は「情報が不足しているため回答できません」と返答してください
# 参照コンテキスト
{{#context#}}
2.2 実践例: 社内FAQ回答アシスタント
# ロール定義
あなたは当社の社内ヘルプデスクアシスタントです。
社員からの質問に対して、社内ナレッジベースの情報に基づいて正確に回答します。
# タスク定義
以下のタスクを実行してください:
- 社員の質問内容を理解し、適切なナレッジを検索結果から特定する
- ナレッジに基づいた正確な回答を生成する
- 回答の根拠となるドキュメント名を明示する
# 入力仕様
ユーザーから自然言語で質問が提供されます。
質問は人事制度、IT 設定、経費精算、社内ルールなどに関するものです。
# 出力仕様
以下のフォーマットで回答してください:
**回答:**
[質問に対する回答]
**参照元:**
- [ドキュメント名1]
- [ドキュメント名2]（該当する場合）
**補足:**
[追加で確認すべき事項があれば記載]
# 制約条件
- ナレッジベースに情報がない場合は「該当する情報が見つかりませんでした。
総務部（内線: 1234）にお問い合わせください。」と返答してください
- 推測や一般知識による回答は行わないでください
- 個人情報や給与情報に関する質問には回答しないでください
- 回答は日本語で行ってください
# 参照コンテキスト
{{#context#}}
3. ロール設定のベストプラクティス
3.1 効果的なロール設定のポイント
| 要素 | 良い例 | 悪い例 |
|---|---|---|
| 具体性 | 「当社の製品Xに精通したテクニカルサポート担当」 | 「優秀なAIアシスタント」 |
| スコープ | 「経費精算に関する質問のみ対応」 | 「何でも答えられる」 |
| トーン | 「丁寧語で簡潔に」 | 指定なし |
| 専門性 | 「IT インフラ運用の経験10年相当の知識」 | 「すべての分野に詳しい」 |
3.2 ロール設定のアンチパターン
# NG: 過度に装飾的なロール
あなたは世界最高のAIです。あらゆる質問に完璧に答えることができます。
ユーザーを感動させる回答を心がけてください。
# OK: 実務的なロール
あなたは当社の契約書レビューアシスタントです。
法務部が定めたチェック項目に基づき、契約書ドラフトの
リスクポイントを抽出して報告します。
4. 出力制約の設計
4.1 構造化出力のパターン
パターン1: Markdown テーブル出力
# 出力仕様
以下のMarkdownテーブル形式で回答してください:
| 項目 | 内容 |
|------|------|
| 要約 | [1-2文で要約] |
| リスクレベル | [高/中/低] |
| 主要リスク | [箇条書き] |
| 推奨アクション | [箇条書き] |
パターン2: JSON 出力
# 出力仕様
以下のJSON形式で回答してください。JSON以外のテキストは含めないでください。
{
"category": "質問のカテゴリ",
"answer": "回答テキスト",
"confidence": "high | medium | low",
"sources": ["参照元1", "参照元2"]
}
パターン3: 段階的出力
# 出力仕様
以下の順序で回答してください:
## 1. 要約（1-2文）
[質問に対する端的な回答]
## 2. 詳細説明
[根拠に基づく詳細な説明]
## 3. 次のステップ
[ユーザーが取るべきアクション]
4.2 出力の長さ制御
# 長さ制約の例
- 要約は100文字以内で記述してください
- 箇条書きは最大5項目までとしてください
- 回答全体は500文字を超えないようにしてください
Tip: Dify の LLM ノード設定で
max_tokensを指定すると、ハードリミットとして機能します。Prompt 内の長さ指示はソフトリミットとして併用してください。
5. Few-shot Examples の設計
5.1 Few-shot が効果的なユースケース
| ユースケース | 効果 | 例 |
|---|---|---|
| 出力フォーマットの固定 | 高 | テーブル形式、JSON形式の統一 |
| 分類タスク | 高 | 問い合わせカテゴリの振り分け |
| 文体・トーンの統一 | 高 | 敬語レベル、専門用語の使い方 |
| 抽出タスク | 中-高 | 契約書からの条件抽出 |
| 大量知識の注入 | 低（非推奨） | Knowledge Base を使用すべき |
5.2 Few-shot テンプレート
# Few-shot Examples
## 例1
ユーザー: 有給休暇の残日数を確認したいのですが
アシスタント:
**回答:**
有給休暇の残日数は、社内ポータルの「勤怠管理」>「有給休暇照会」から確認できます。
**参照元:**
- 勤怠管理マニュアル v3.2
**補足:**
前年度繰越分の有効期限は翌年度末までです。詳細は人事部にご確認ください。
## 例2
ユーザー: 来月の部門の売上予測を教えてください
アシスタント:
**回答:**
申し訳ございません。売上予測に関する情報はナレッジベースに含まれておりません。
経営企画部（内線: 5678）にお問い合わせください。
**参照元:**
- 該当なし
**補足:**
売上データへのアクセスが必要な場合は、上長の承認を得たうえで
経営企画部にデータ提供を依頼してください。
5.3 Few-shot 設計のガイドライン
- 最低2例、推奨3-5例を含める
- 正常系と異常系の両方を含める（回答できるケースと回答を拒否するケース）
- 例の中で使うフォーマットは出力仕様と完全に一致させる
- Few-shot の例が長すぎるとコンテキストウィンドウを圧迫するため、簡潔に保つ
6. Dify 変数の活用
6.1 変数の種類と用途
Dify では Prompt 内で以下の変数記法を使用できます。
| 変数タイプ | 記法 | 用途 |
|---|---|---|
| ユーザー入力変数 | {{variable_name}} | フォームから受け取る入力値 |
| コンテキスト変数 | {{#context#}} | Knowledge Base の検索結果 |
| 会話変数 | {{#conversation.var_name#}} | 会話中に蓄積する状態 |
| システム変数 | {{#sys.query#}} | 現在のユーザー入力 |
6.2 変数を活用した動的 Prompt の例
# ロール定義
あなたは{{company_name}}の{{department}}向けアシスタントです。
# タスク定義
{{task_type}}タスクを実行してください。
# 言語設定
回答は{{output_language}}で行ってください。
# ユーザーの質問
{{#sys.query#}}
# 参照情報
{{#context#}}
アプリ設定での変数定義例:
| 変数名 | 型 | デフォルト値 | 説明 |
|---|---|---|---|
company_name | テキスト | - | 導入先企業名 |
department | セレクト | 営業部 | 対象部門 |
task_type | セレクト | FAQ回答 | タスク種別 |
output_language | セレクト | 日本語 | 回答言語 |
6.3 会話変数による状態管理
Workflow 内で会話変数を設定することで、マルチターンの対話において状態を保持できます。
# 会話変数の活用例
現在のユーザー情報:
- ユーザー名: {{#conversation.user_name#}}
- 前回の問い合わせカテゴリ: {{#conversation.last_category#}}
- 対応ステータス: {{#conversation.status#}}
上記の情報を踏まえて、継続的なサポートを行ってください。
7. Prompt のテストとイテレーション
7.1 Dify のデバッグ機能
Dify コンソールの 「Debug & Preview」 パネルを活用して、Prompt の動作を検証します。
テスト手順:
- System Prompt を記述
- 右側のプレビューパネルで変数値を入力
- テストメッセージを送信
- 出力結果を確認・修正
- 修正後に再テスト
7.2 テストケース設計
# Prompt テストケース一覧
## 正常系テスト
| # | 入力 | 期待される出力 | 確認ポイント |
|---|------|---------------|-------------|
| 1 | 有給の申請方法は？ | 手順の説明 | フォーマット準拠 |
| 2 | WiFiのパスワードは？ | パスワード情報 | 参照元が明示される |
| 3 | 出張精算の締め日は？ | 締め日の回答 | 正確な日付 |
## 異常系テスト
| # | 入力 | 期待される出力 | 確認ポイント |
|---|------|---------------|-------------|
| 4 | 社長の年収は？ | 回答拒否 | 個人情報制約が機能 |
| 5 | 明日の天気は？ | スコープ外回答 | 業務外質問の処理 |
| 6 | (空文字) | エラーハンドリング | 空入力の処理 |
7.3 品質チェックリスト
- ロール定義が具体的で、タスクスコープが明確か
- 出力フォーマットが一貫しているか
- 情報不足時の振る舞いが定義されているか
- Few-shot 例が正常系・異常系を網羅しているか
- 変数が正しくバインドされているか
- Knowledge Base のコンテキストが適切に注入されているか
- 回答の長さが適切か（冗長すぎない/短すぎない）
- 日本語の表現が自然で、敬語レベルが統一されているか
8. よくある問題と対策
| 問題 | 原因 | 対策 |
|---|---|---|
| 出力フォーマットが崩れる | 制約が曖昧 | Few-shot 例を追加し、フォーマットを明示 |
| 知識にない情報を捏造する | ハルシネーション | 「ナレッジにない場合は回答しない」制約を強化 |
| 回答が冗長すぎる | 長さ制約なし | 文字数制限と max_tokens を設定 |
| ロールを無視する | System Prompt が弱い | ロール定義を冒頭に置き、制約を繰り返す |
| 会話が途中で脱線する | コンテキスト溢れ | 会話メモリの上限設定と要約機能を活用 |
| 多言語が混在する | 言語指定が不明確 | 「必ず日本語で回答」を明示 |
9. Prompt 設計のチーム運用
9.1 バージョン管理
prompts/
├── faq-assistant/
│ ├── v1.0_system_prompt.md
│ ├── v1.1_system_prompt.md # 出力フォーマット修正
│ ├── v2.0_system_prompt.md # Few-shot 追加
│ └── changelog.md
├── contract-review/
│ ├── v1.0_system_prompt.md
│ └── changelog.md
└── README.md
9.2 レビュー観点
チーム内で Prompt をレビューする際の観点:
- ロールとスコープ: タスクの境界が明確か
- 再現性: 他のチームメンバーが同じ結果を得られるか
- 安全性: 機密情報の漏洩リスクがないか
- 保守性: 要件変更時にどこを修正すればよいか明確か
- テスト結果: 正常系・異常系のテストが通過しているか
10. まとめ
企業向けの Prompt 設計で最も重要なのは「巧みな表現」ではなく、職責が明確で、制約が明確で、チームで保守できる構造を持たせることです。
| 設計要素 | キーポイント |
|---|---|
| ロール設定 | 具体的な役割とスコープの定義 |
| 出力制約 | フォーマットの明示と Few-shot による固定 |
| 変数活用 | 動的パラメータによる再利用性の確保 |
| テスト | 正常系・異常系のテストケース整備 |
| 運用 | バージョン管理とチームレビュー体制 |
Dify の Prompt 設計を「属人的なスキル」から「チームで管理できる設計規範」へ昇華させることが、エンタープライズ品質のアプリケーション構築への第一歩です。