Dify プロンプト設計チートシート:役割宣言・制約・出力フォーマットの定石

AI エージェントを開発する上で、プロンプト設計は成功の鍵を握る重要な要素です。Dify は強力な AI オーケストレーションプラットフォームですが、効果的なプロンプトを設計できなければ、その真価を発揮することはできません。本記事では、Dify でプロンプトを設計する際の「定石」となるテクニックを、早見表とともに徹底解説いたします。
Dify プロンプト設計早見表
プロンプト設計の全体像を一目で把握できる早見表です。実際の設計時には、この表を参考に構造化されたプロンプトを作成してください。
# | 設計要素 | 目的 | 主な記述パターン | 効果 |
---|---|---|---|---|
1 | 役割宣言 | AI の振る舞いを定義 | あなたは〜です 、You are a〜 | 応答の一貫性とトーン統一 |
2 | 制約 | 望ましくない動作の防止 | 〜しないでください 、Never〜 | 誤動作の防止、安全性向上 |
3 | 出力フォーマット | 構造化された応答を取得 | JSON スキーマ、テンプレート指定 | パース可能性、統一性 |
4 | コンテキスト | タスク背景の共有 | 状況説明、ユースケース記載 | 精度向上、適切な判断 |
5 | 例示(Few-shot) | 期待する出力の明示 | 入出力ペアの提示 | 精度向上、フォーマット統一 |
6 | ステップ指示 | 思考プロセスの誘導 | ステップ 1:〜 、First,〜 | 複雑なタスクの精度向上 |
この表は、プロンプト設計時のチェックリストとしても活用できます。次の章から、各要素を詳しく解説してまいります。
背景
AI を活用したアプリケーション開発において、プロンプトエンジニアリングは極めて重要なスキルとなっています。特に Dify のような AI オーケストレーションプラットフォームでは、複数の AI モデルやツールを組み合わせて複雑なワークフローを構築するため、適切なプロンプト設計が欠かせません。
Dify におけるプロンプトの役割
Dify では、プロンプトが以下の役割を担います。
- AI エージェントの「性格」や「専門性」の定義
- 入力データの処理方法の指示
- 出力形式の制御
- ワークフロー内での情報の受け渡し
これらの役割を適切に果たすためには、構造化されたプロンプト設計が必要です。しかし、多くの開発者が「どのようにプロンプトを構造化すれば良いのか」という点で悩んでいるのが現状でしょう。
プロンプト設計における課題
従来、プロンプトは自然言語で自由に記述できるため、以下のような課題が発生しがちです。
- 曖昧な指示により、期待しない出力が返される
- 出力形式が安定せず、後続処理でパースエラーが発生
- AI が不適切な推論や判断を行う
- プロンプトが肥大化し、メンテナンスが困難になる
Dify でプロンプト設計の「型」を理解し、定石を身につけることで、これらの課題を解決できます。以下の図は、プロンプト設計の全体構造を示したものです。
mermaidflowchart TB
input["ユーザー入力"] --> role["役割宣言"]
role --> context["コンテキスト"]
context --> constraint["制約"]
constraint --> instruction["指示・ステップ"]
instruction --> format["出力フォーマット"]
format --> output["AI 出力"]
style role fill:#e1f5ff
style constraint fill:#fff4e1
style format fill:#f0e1ff
style output fill:#e1ffe1
この図が示すように、プロンプトは複数の要素が階層的に組み合わさって構成されています。次の章では、これらの要素を定石として解説してまいります。
課題
Dify でプロンプトを設計する際、開発者が直面する主な課題は以下の 3 点に集約されます。
課題 1:役割が不明確で一貫性が欠ける
AI に役割を与えずにタスクだけを指示すると、応答のトーンや専門性がバラバラになります。例えば、カスタマーサポート用のチャットボットを作る場合、「丁寧に応答してください」だけでは不十分でしょう。
javascript// ❌ 曖昧な指示
const prompt = 'ユーザーの質問に答えてください。';
このような曖昧な指示では、AI が技術的すぎる回答をしたり、逆にカジュアルすぎる言葉遣いをしたりする可能性があります。
課題 2:制約が不足して危険な動作をする
制約を設けていないプロンプトは、AI が意図しない動作を行うリスクを含んでいます。例えば、社内ドキュメント検索システムで、機密情報を外部に送信しようとするなど、セキュリティ上の問題が発生する恐れがあるでしょう。
javascript// ❌ 制約がないプロンプト
const prompt =
'ドキュメントを検索して情報を提供してください。';
課題 3:出力フォーマットが不安定でパースできない
出力形式を明確に指定しないと、AI は自由な形式で応答を返します。これにより、後続の処理で JSON パースエラーが発生したり、データ抽出に失敗したりするケースが頻発するでしょう。
javascript// ❌ フォーマット指定がないプロンプト
const prompt = '商品の名前と価格を教えてください。';
// 期待する形式: { "name": "商品A", "price": 1000 }
// 実際の出力: "商品Aは1000円です。"
以下の図は、これら 3 つの課題がどのように関連し、問題を引き起こすかを示しています。
mermaidflowchart LR
unclear_role["役割が<br/>不明確"] --> inconsistent["応答の<br/>一貫性欠如"]
no_constraint["制約が<br/>不足"] --> unsafe["危険な<br/>動作"]
no_format["出力フォーマット<br/>未指定"] --> parse_error["パース<br/>エラー"]
inconsistent --> ux_poor["UX 低下"]
unsafe --> security_risk["セキュリティ<br/>リスク"]
parse_error --> workflow_break["ワークフロー<br/>断絶"]
ux_poor --> failure["システム<br/>失敗"]
security_risk --> failure
workflow_break --> failure
style unclear_role fill:#ffe1e1
style no_constraint fill:#ffe1e1
style no_format fill:#ffe1e1
style failure fill:#ff9999
これらの課題を解決するためには、体系的なプロンプト設計の定石が必要です。次の章では、具体的な解決策を示してまいります。
解決策
Dify でプロンプトを設計する際の 3 つの定石「役割宣言」「制約」「出力フォーマット」について、それぞれ詳しく解説いたします。
定石 1:役割宣言で AI の振る舞いを定義する
役割宣言は、プロンプトの冒頭に配置し、AI がどのような立場で応答すべきかを明確にします。これにより、応答の一貫性とトーンが統一されるのです。
役割宣言の基本パターン
markdownあなたは[専門性]を持つ[役割]です。
[追加の特徴や制約]
具体例:カスタマーサポートボット
javascriptconst roleDeclaration = `
あなたは、10年以上の経験を持つカスタマーサポート専門家です。
常に丁寧で親切な言葉遣いを心がけ、ユーザーの課題解決を最優先に考えます。
技術的な内容は、初心者にもわかるように噛み砕いて説明します。
`;
この役割宣言により、AI は一貫して「丁寧」「親切」「初心者向け」のトーンで応答するようになります。
具体例:技術ドキュメント生成エージェント
javascriptconst roleDeclaration = `
あなたは、TypeScript と React に精通したテクニカルライターです。
コードサンプルは必ず動作確認済みのものを提供し、
ベストプラクティスに則った実装例を示します。
`;
定石 2:制約で望ましくない動作を防止する
制約は、AI が「してはいけないこと」を明確に示すことで、安全性と信頼性を向上させます。Dify では、特にワークフロー内でツールを使用する場合、制約が重要な役割を果たすでしょう。
制約の基本パターン
markdown以下の行動は絶対に行わないでください:
- [禁止事項 1]
- [禁止事項 2]
- [禁止事項 3]
具体例:社内ドキュメント検索システム
javascriptconst constraints = `
以下の行動は絶対に行わないでください:
- 社外秘情報を外部に送信する
- ユーザー権限を超えたドキュメントにアクセスする
- 検索結果を改ざんまたは編集する
- 個人情報を含むデータをログに記録する
`;
具体例:コード生成エージェント
javascriptconst constraints = `
以下のコードは生成しないでください:
- セキュリティ脆弱性を含むコード(SQL インジェクション、XSS など)
- 非推奨または廃止予定の API を使用するコード
- エラーハンドリングが欠如したコード
- ハードコードされた機密情報(API キー、パスワードなど)を含むコード
`;
定石 3:出力フォーマットで構造化された応答を取得する
出力フォーマットの指定は、AI の応答を後続処理で確実にパースできるようにするために不可欠です。Dify では、JSON フォーマットの指定が最も一般的でしょう。
JSON スキーマによるフォーマット指定
javascriptconst outputFormat = `
以下の JSON スキーマに厳密に従って応答してください:
{
"name": "商品名(文字列)",
"price": "価格(数値)",
"category": "カテゴリ(文字列)",
"inStock": "在庫有無(真偽値)"
}
JSON 以外のテキストは一切含めないでください。
`;
Markdown テンプレートによるフォーマット指定
javascriptconst outputFormat = `
以下のテンプレートに従って応答してください:
# タイトル
[タイトルをここに記載]
# 概要
[3行以内で概要を記載]
# 詳細
[箇条書きで詳細を記載]
# 関連リンク
- [リンク1]
- [リンク2]
`;
以下の図は、これら 3 つの定石がどのように連携して、安定した AI エージェントを実現するかを示しています。
mermaidflowchart TB
start["プロンプト設計開始"] --> role_check{"役割宣言<br/>明確か?"}
role_check -->|No| add_role["役割を定義"]
role_check -->|Yes| constraint_check{"制約は<br/>十分か?"}
add_role --> constraint_check
constraint_check -->|No| add_constraint["制約を追加"]
constraint_check -->|Yes| format_check{"出力フォーマット<br/>指定済みか?"}
add_constraint --> format_check
format_check -->|No| add_format["フォーマット指定"]
format_check -->|Yes| test["テスト実行"]
add_format --> test
test --> evaluate{"期待通りの<br/>動作か?"}
evaluate -->|No| refine["プロンプト改善"]
evaluate -->|Yes| done["完成"]
refine --> role_check
style done fill:#e1ffe1
style add_role fill:#e1f5ff
style add_constraint fill:#fff4e1
style add_format fill:#f0e1ff
次の章では、これらの定石を組み合わせた具体例を示してまいります。
具体例
ここでは、Dify で実際に使用できる実践的なプロンプトテンプレートを、用途別に紹介いたします。
具体例 1:技術サポートチャットボット
技術サポート用のチャットボットを構築する際のプロンプト例です。役割宣言・制約・出力フォーマットの 3 要素を組み合わせています。
プロンプト全体構造
javascriptconst techSupportPrompt = `
# 役割宣言
あなたは、Web 開発に精通したテクニカルサポート担当者です。
ユーザーの技術的な問題を迅速かつ丁寧に解決することが使命です。
初心者から上級者まで、それぞれのレベルに合わせた説明を提供します。
# 制約
以下の行動は絶対に行わないでください:
- ユーザーのコードを削除または破壊的に変更する提案
- セキュリティリスクのある解決策を提示
- 確証のない推測に基づく回答
- 他の技術やツールを根拠なく批判
# 出力フォーマット
以下の JSON 形式で応答してください:
{
"diagnosis": "問題の診断結果",
"solution": "具体的な解決手順(配列形式)",
"codeExample": "コード例(該当する場合)",
"relatedLinks": "関連ドキュメントへのリンク(配列形式)",
"estimatedTime": "解決にかかる推定時間(分)"
}
`;
ユーザー入力の受け取り方
javascript// Dify のワークフロー内で変数を使用
const userInput = '{{user_question}}'; // ユーザーからの質問
const finalPrompt = `
${techSupportPrompt}
# ユーザーの質問
${userInput}
`;
期待される出力例
json{
"diagnosis": "npm install 時に peer dependency の警告が発生している状態です。依存関係の不整合が原因と考えられます。",
"solution": [
"package.json で React のバージョンを確認してください",
"npm install --legacy-peer-deps を試してください",
"それでも解決しない場合は、node_modules と package-lock.json を削除して再インストールしてください"
],
"codeExample": "npm install --legacy-peer-deps",
"relatedLinks": [
"https://docs.npmjs.com/cli/v8/commands/npm-install",
"https://docs.npmjs.com/cli/v8/using-npm/config#legacy-peer-deps"
],
"estimatedTime": 5
}
具体例 2:コードレビューエージェント
TypeScript コードをレビューするエージェントのプロンプト例です。詳細な評価基準と構造化された出力を実現します。
プロンプト全体構造
javascriptconst codeReviewPrompt = `
# 役割宣言
あなたは、10年以上の経験を持つシニア TypeScript エンジニアです。
コードの品質、保守性、パフォーマンス、セキュリティの観点から、
建設的で具体的なフィードバックを提供します。
# 評価基準
以下の観点でコードを評価してください:
1. 型安全性:型定義の適切性、any の使用有無
2. 可読性:命名規則、コメント、構造の明確さ
3. パフォーマンス:不要な再レンダリング、メモリリーク
4. セキュリティ:XSS、SQL インジェクションなどの脆弱性
5. ベストプラクティス:React/TypeScript の推奨パターンへの準拠
# 制約
以下のことは避けてください:
- 単に「良い」「悪い」といった曖昧な評価
- 個人の好みに基づく主観的な指摘
- 重箱の隅をつつくような些細な指摘のみ
# 出力フォーマット
{
"overallScore": "総合評価(0-100)",
"findings": [
{
"category": "評価カテゴリ",
"severity": "重要度(critical/high/medium/low)",
"issue": "問題点",
"suggestion": "改善提案",
"codeExample": "修正例"
}
],
"summary": "総評(3行以内)"
}
`;
コードの入力方法
javascriptconst codeToReview = `
{{code_snippet}} // Dify ワークフロー変数
`;
const finalPrompt = `
${codeReviewPrompt}
# レビュー対象コード
\`\`\`typescript
${codeToReview}
\`\`\`
`;
期待される出力例
json{
"overallScore": 75,
"findings": [
{
"category": "型安全性",
"severity": "high",
"issue": "関数の戻り値の型が明示されていません",
"suggestion": "明示的に戻り値の型を指定することで、意図しない型の返却を防ぎます",
"codeExample": "function fetchUser(id: string): Promise<User> { ... }"
},
{
"category": "パフォーマンス",
"severity": "medium",
"issue": "useEffect 内で毎回新しいオブジェクトを生成しています",
"suggestion": "useMemo を使用してオブジェクトをメモ化してください",
"codeExample": "const config = useMemo(() => ({ ... }), [deps]);"
}
],
"summary": "全体的に良好なコードですが、型安全性とパフォーマンスの面で改善の余地があります。特に戻り値の型を明示することで、より堅牢なコードになるでしょう。"
}
具体例 3:ドキュメント生成エージェント
API ドキュメントを自動生成するエージェントのプロンプト例です。統一されたフォーマットで、読みやすいドキュメントを生成します。
プロンプト全体構造
javascriptconst docGenerationPrompt = `
# 役割宣言
あなたは、開発者向けドキュメントの作成に特化したテクニカルライターです。
明確で簡潔、かつ実用的なドキュメントを作成することを心がけます。
# ドキュメント作成方針
- コード例は必ず含める
- エッジケースやエラーハンドリングについても言及
- 初心者でも理解できるよう、専門用語には補足説明を加える
# 制約
- コピペだけで動作するコード例を提供する
- 非推奨の機能や古い実装方法は紹介しない
- 実装詳細よりも使用方法を重視する
# 出力フォーマット
Markdown 形式で以下の構造に従ってください:
# [関数名またはAPI名]
## 概要
[1-2行で機能の概要]
## 構文
\`\`\`typescript
[関数シグネチャ]
\`\`\`
## パラメータ
| パラメータ名 | 型 | 必須 | 説明 |
|---|---|---|---|
## 戻り値
[戻り値の型と説明]
## 使用例
\`\`\`typescript
[実際に動作するコード例]
\`\`\`
## エラーハンドリング
[起こりうるエラーと対処方法]
## 関連項目
- [関連する関数やドキュメントへのリンク]
`;
関数情報の入力
javascriptconst functionInfo = {
name: '{{function_name}}',
signature: '{{function_signature}}',
description: '{{function_description}}',
};
const finalPrompt = `
${docGenerationPrompt}
# 対象関数情報
- 関数名: ${functionInfo.name}
- シグネチャ: ${functionInfo.signature}
- 説明: ${functionInfo.description}
`;
以下の図は、これら 3 つのユースケースにおける、プロンプト要素の使い分けを示しています。
mermaidflowchart LR
subgraph use_case1["技術サポート"]
role1["サポート担当者"] --> constraint1["安全な提案のみ"]
constraint1 --> format1["JSON 診断結果"]
end
subgraph use_case2["コードレビュー"]
role2["シニアエンジニア"] --> constraint2["建設的な指摘"]
constraint2 --> format2["評価スコア付き<br/>JSON"]
end
subgraph use_case3["ドキュメント生成"]
role3["テクニカル<br/>ライター"] --> constraint3["実用的な内容"]
constraint3 --> format3["Markdown<br/>構造"]
end
use_case1 --> output["安定した<br/>AI 出力"]
use_case2 --> output
use_case3 --> output
style output fill:#e1ffe1
これらの具体例を参考に、自身のユースケースに合わせたプロンプトを設計してみてください。
まとめ
Dify でのプロンプト設計において、「役割宣言」「制約」「出力フォーマット」の 3 つの定石を理解し、適切に組み合わせることで、安定性と信頼性の高い AI エージェントを構築できます。
プロンプト設計の 3 つの定石
本記事で解説した定石をまとめますと、以下のようになります。
定石 | 効果 | 重要ポイント |
---|---|---|
役割宣言 | 一貫性のある応答、トーンの統一 | プロンプトの冒頭に配置、具体的な専門性を明記 |
制約 | 危険な動作の防止、安全性向上 | 禁止事項を明確に列挙、セキュリティリスクに配慮 |
出力フォーマット | パース可能な構造化データ、後続処理の安定化 | JSON スキーマまたはテンプレートを明示 |
これらの定石は、単独で使用するのではなく、組み合わせることで真価を発揮します。役割宣言で AI の立場を定義し、制約で安全性を担保し、出力フォーマットで確実にデータを取り出す、という一連の流れを意識してください。
プロンプト設計のベストプラクティス
実践において、以下のポイントを意識するとより効果的でしょう。
- 段階的な改善:最初から完璧なプロンプトを目指さず、テストと改善を繰り返す
- 具体性の重視:曖昧な表現を避け、具体的な例や基準を示す
- メンテナンス性の確保:プロンプトをモジュール化し、再利用可能な構造にする
- バージョン管理:プロンプトの変更履歴を残し、パフォーマンスの変化を追跡する
Dify のワークフロー機能を活用すれば、これらのプロンプトを組み合わせて、より高度な AI アプリケーションを構築できます。本記事で紹介した定石を基盤として、独自のプロンプトライブラリを構築していってください。
プロンプトエンジニアリングは、試行錯誤の連続ですが、本記事の定石を活用することで、その道のりはずっと短くなるはずです。
関連リンク
- article
Dify プロンプト設計チートシート:役割宣言・制約・出力フォーマットの定石
- article
Dify を macOS でローカル検証:Docker Compose で最短起動する手順
- article
Dify と LangGraph/LangChain を比較:表現力・保守性・学習コストのリアル
- article
Dify でジョブが止まる/再実行される問題の原因切り分けガイド
- article
Dify の内部アーキテクチャ超図解:エージェント・ワークフロー・データストアの関係
- article
2025年 Dify コミュニティとエコシステムの最新動向
- article
Apollo キャッシュ操作チートシート:`cache.modify`/`writeQuery`/`readFragment` 早見表
- article
GitHub Actions 条件式チートシート:if/contains/startsWith/always/success/failure
- article
Zod で CSV/TSV インポートを安全に処理:パース → 検証 → 差分レポート
- article
Yarn のインストール完全ガイド:Corepack 有効化からバージョン固定まで
- article
Git を macOS に最適導入:Homebrew・初期設定テンプレ・credential 管理まで
- article
Web Components で作るモーダルダイアログ:フォーカス管理・閉じる動線まで実装
- blog
iPhone 17シリーズの発表!全モデルiPhone 16から進化したポイントを見やすく整理
- blog
Googleストアから訂正案内!Pixel 10ポイント有効期限「1年」表示は誤りだった
- blog
【2025年8月】Googleストア「ストアポイント」は1年表記はミス?2年ルールとの整合性を検証
- blog
Googleストアの注文キャンセルはなぜ起きる?Pixel 10購入前に知るべき注意点
- blog
Pixcel 10シリーズの発表!全モデル Pixcel 9 から進化したポイントを見やすく整理
- blog
フロントエンドエンジニアの成長戦略:コーチングで最速スキルアップする方法
- review
今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
- review
ついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
- review
愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
- review
週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
- review
新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
- review
科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来