Difyでアプリを作っていると、毎回少し悩むのが「システムプロンプトをどう設計するか」という部分です。
ざっくりしたアイデアはあっても、それを実際に使える形のプロンプトに落とし込むには意外と時間がかかります。
そこで今回は、アプリ概要をもとに新しいプロンプトを生成したり、すでにあるプロンプトを改善したりできる「プロンプト生成/改善アプリ」をDifyで作ってみました。
単に文章を出力するだけではなく、対話しながら段階的にブラッシュアップできるようにしたのがポイントです。
この記事では、Difyでこのアプリを作った背景や、どんな課題を解決したかったのか、そして実際にどのような構成で組んだのかを順番に紹介していきます。
これからDifyで業務用アプリや支援ツールを作りたい方や、プロンプト設計をもう少し効率化したい方の参考になればうれしいです。
なお、私はDifyを体系的に学習できるDify学習館というサイトを運営しており、このアプリもそこで無料でダウンロードできます。
よければご利用ください^^
配布記事：https://programming-mondai.com/top/dify/t3-1/
解決したかった課題
今回このアプリを作ろうと思った理由は、Dify向けのプロンプト作成をもっと楽に、そして実用的にしたかったからです。
実際に触っていると、プロンプトは思った以上に試行錯誤が必要で、「一度作れば完成」というよりは、使いながら調整していくものだと感じました。
まず課題だったのは、アプリの目的や利用シーンは頭の中にあるのに、それをそのまま高品質なシステムプロンプトへ変換するのが難しいことです。
アプリ概要を文章で説明することはできても、そこから役割や制約、出力形式まで整理されたプロンプトを書くには、それなりに慣れが必要です。
特にDifyでそのまま使える形にしようとすると、曖昧な表現を減らしたり、出力のブレを抑えたりする工夫が欠かせません。
もうひとつの課題は、すでにあるプロンプトを改善したい場面です。
既存のプロンプトにはそれなりに意図があるので、全部作り直すより、良い部分を残しながら改善したいことがよくあります。
ただ、実際には「どこを直せばよいのか」が見えにくく、少し修正したつもりが逆に使いづらくなることもあります。
目的は維持したまま、曖昧さや抜け漏れを減らし、再現性のある形へ整える仕組みが必要でした。
さらに、プロンプト改善は一回で終わらないことも多いです。
最初の出力を見てから「もう少し初心者向けにしたい」「表現をやわらかくしたい」「制約をもっと明確にしたい」といった追加の修正をしたくなります。
そのたびに最初から入力し直すのは手間なので、会話しながら何度か改善できる流れにしたいと考えました。
このように考えると、必要だったのは単なる「プロンプト生成ツール」ではありませんでした。
アプリ概要から新規に作る機能と、既存プロンプトを改善する機能の両方を持ち、さらに対話を通じて継続的に磨けるアプリがほしかった、というのが今回の出発点です。
作ったアプリの概要と入出力例
今回作ったのは、Dify上で使うシステムプロンプトを、できるだけ少ない手間で作成・改善できるアプリです。
アプリ名は「プロンプト生成/改善アプリ」で、その名前の通り、新しくプロンプトを作る用途と、すでにあるプロンプトを改善する用途の両方に対応させました。
このアプリの使い方はとてもシンプルです。入力欄として用意したのは「アプリ概要」と「現状のプロンプト」の2つで、どちらを入れるかによって処理の流れが変わります。
たとえば、まだプロンプトが何もない段階であれば、アプリ概要だけを入力すれば新規のプロンプトを生成できます。
一方で、すでにたたき台になるプロンプトがある場合は、それを入力することで改善モードとして使えるようにしました。
入力例と出力例
例えば、アプリ概要として単純に「個人経営の旅館の問い合わせ対応チャットボット」とだけ入力して実行してみたところ、以下のように出力されました。
# 役割
- あなたは、個人経営の旅館の問い合わせ対応を行うチャットボットです。
- 旅館を検討中または利用予定のユーザーに対して、わかりやすく丁寧に案内します。
- 旅館の公式案内担当としてふるまいますが、実在しない情報を作らず、不明点は確認を促します。
# 命令
- ユーザーからの問い合わせ内容を正確に読み取り、旅館利用に関する案内を行ってください。
- 予約、宿泊、チェックイン・チェックアウト、食事、客室、設備、アクセス、駐車場、周辺案内、キャンセル、忘れ物など、旅館によくある問い合わせに対応してください。
- まずユーザーの質問に直接答え、必要があれば追加確認事項を簡潔に尋ねてください。
- 情報が不足している場合は、断定せずに「確認が必要です」「詳細をお知らせください」と案内してください。
- 料金、空室、送迎、特別対応、最新の営業状況など、変動する可能性がある内容は確定表現を避けて案内してください。
- 問い合わせ内容が複数ある場合は、項目ごとに整理して回答してください。
- 高齢者や旅行に不慣れなユーザーにも伝わるよう、やさしく簡潔な日本語で回答してください。
- ユーザーが不安や不満を示している場合は、先に気持ちに配慮した一言を添えてから案内してください。
# 文脈
- このチャットボットは、個人経営の旅館に寄せられる一般的な問い合わせへの一次対応に利用されます。
- ユーザーは宿泊を検討している人、予約済みの人、宿泊後に連絡したい人を含みます。
- 旅館ごとの詳細情報が会話内で提示されていない場合は、一般的で安全な案内にとどめてください。
- 旅館の印象を左右するため、親しみやすさと礼儀正しさを両立してください。
# 制約事項
- 入力されていない旅館名、住所、電話番号、料金、設備、サービス内容、規約などの固有情報を勝手に作らないでください。
- 空室状況、予約確定、料金確定、送迎可否、アレルギー対応可否、ペット同伴可否などを、根拠なく断定しないでください。
- 医療、法律、事故対応、災害対応などの専門判断が必要な内容は、一般的な案内にとどめ、必要に応じて旅館または関係機関への確認を促してください。
- クレーム対応では、対立的な表現や責任の断定を避け、事実確認を促してください。
- ユーザーの個人情報を必要以上に求めないでください。
- 回答は簡潔にし、長すぎる説明や不要な前置きはしないでください。
- わからないことは、推測で埋めずに不明と伝えてください。
- 危険、違法、有害な依頼には協力しないでください。
# 出力形式
- 回答は自然で丁寧な日本語で出力してください。
- 1回の回答で伝える内容は、要点がすぐわかる構成にしてください。
- 必要に応じて以下の順で構成してください。
- 結論
- 補足案内
- 確認したい事項
- 箇条書きが適切な場合は `-` を用いて整理してください。
- 予約や料金など確定が必要な話題では、最後に「詳細は旅館へご確認ください」または同等の確認案内を添えてください。
この出力を見て、おかしい部分や追加したい内容があればチャット欄に記入して再実行すると、さらに改善されたプロンプトが出力されます。
記入する内容が詳しいほどに、当然プロンプトの精度も高くなります。
ワークフロー全体
このアプリのワークフローは、できるだけシンプルに見えつつも、実際の使い勝手を意識した流れになるように組みました。
やっていること自体は「入力を受け取る」「条件に応じて処理を分ける」「最後に仕上げる」という構成ですが、この流れを明確にしておくことで、新規生成と改善のどちらにも無理なく対応できるようになります。
最初の入口になるのは、ユーザーが「アプリ概要」と「現状のプロンプト」を入力するスタートノードです。
ここで受け取った内容をもとに、次のIF/ELSEノードでどのルートに進むかを判断します。
両方とも空のまま初回実行された場合は、そのまま処理を進めるのではなく、入力を促すメッセージを返すようにしています。
これによって、意味のない実行を減らし、利用者にとっても分かりやすい挙動になります。
分岐のあとには、新規生成用と改善用の2つのLLMノードを用意しました。
アプリ概要だけが入っている場合は新規生成のノードへ進み、既存プロンプトがある場合や会話の流れの中で再調整したい場合は改善ノードへ進みます。
このように役割ごとにノードを分けたことで、それぞれに合った指示を与えやすくなり、1つのノードで全部を処理するよりも挙動を安定させやすくなりました。
さらに、このアプリでは生成または改善した結果を、そのまま返して終わりにはしていません。
どちらのルートを通った場合でも、一度変数集約ノードを経由させてから、最後にもうひとつLLMノードへ渡しています。
この後段のノードは、いわば最終チェックの役割です。
新規生成ルートでも改善ルートでも、出力には多少の表現ゆれや構成のばらつきが出ることがあるため、最後に共通の観点で整えるようにしました。
この構成にしてよかったと感じているのは、ワークフローの責務が分かりやすくなったことです。
最初の分岐までは「何をしたいかを判定する」役割、その次のLLMノードは「内容を生成または改善する」役割、そして最後のノードは「完成版として整える」役割を持っています。
1つのノードにすべてを任せると、指示が増えるほど意図がぶれやすくなりますが、工程ごとに役割を切り分けることで調整しやすくなりました。
今回のアプリは単なる生成ツールではなく、実運用で使いやすい支援ツールにしたかったので、このワークフロー構成はかなり重要なポイントでした。
入力と分岐の考え方
このアプリで意識したのは、ユーザーが迷わず使えることです。
入力項目は「アプリ概要」と「現状のプロンプト」の2つだけですが、シンプルな入力画面ほど、裏側の分岐設計が大事になります。
見た目は簡単でも、入力内容に応じて自然に振る舞ってくれないと、使い勝手は一気に下がってしまいます。
そこで今回のワークフローでは、最初にIF/ELSEノードを置いて、入力状況と会話回数をもとに処理を切り替えるようにしました。
ポイントは、単に「入力があるかどうか」だけを見るのではなく、「初回の実行なのかどうか」も含めて判断していることです。
これによって、最初の利用時と、2周目以降の改善時で挙動を変えられるようになっています。
分岐のロジック自体はそれほど複雑ではありませんが、アプリの体験には大きく影響します。
新規生成と改善をきちんと分けつつ、会話の継続も壊さないようにしておくことで、単発のツールではなく、実際に使い続けられるアプリに近づけることができます。
個人的にも、この分岐を入れたことで、アプリの使い勝手がかなりはっきりしたと感じました。
プロンプト新規生成LLMノードでやっていること
新規生成ルートの役割は、まだ何もない状態から、実際に使えるシステムプロンプトのたたき台を作ることです。
ただ単にそれらしい文章を出すのではなく、Difyでそのまま使いやすい形まで整ったプロンプトを返すようにしたかったので、このノードにはかなり明確な指示を与えています。
入力として渡しているのは、主に「アプリ概要」と、ユーザーがチャットで追加した要望です。
ここで大事にしたのは、アプリ概要から目的や対象ユーザー、利用シーン、回答方針を読み取らせることでした。
つまり、ユーザーが細かく仕様を書き切っていなくても、概要から必要な要素をくみ取り、実運用で使える形に落とし込むことを狙っています。
とはいえ、情報が足りない部分を勝手に作り込みすぎると危険なので、不足している箇所は汎用的で安全な表現にとどめるようにしています。
また、このノードでは、出力するプロンプトの構成も固定しています。
具体的には、「役割」「命令」「文脈」「制約事項」「出力形式」という見出しを必ずこの順で含めるようにしました。
これによって、出力の読みやすさが上がるだけでなく、あとから人が見直すときにも意図を追いやすくなります。
プロンプトは中身だけでなく、どの観点がどう整理されているかも大事なので、最初から構造を決めておくのはかなり効果的でした。
実際にこのLLMに記入したシステムプロンプトは以下の通りです。
あなたは、Difyアプリ用の高品質なシステムプロンプトを設計するプロンプトエンジニアです。
以下の情報をもとに、Difyへそのまま貼り付けて使える完成版プロンプトを1つ作成してください。
# 入力情報
- アプリ概要
{{#1774577891439.app#}}
- ユーザーからの追加指示
{{#sys.query#}}
# 役割
- あなたの役割は、アプリ概要から目的・対象ユーザー・利用場面・回答方針を読み取り、実運用しやすいシステムプロンプトを設計することです。
# 命令
- 入力情報をもとに、完成版プロンプトを1つだけ作成してください。
- 出力するプロンプト本文には、必ず次の5つの見出しをこの順で含めてください。
- # 役割
- # 命令
- # 文脈
- # 制約事項
- # 出力形式
- 必要に応じて、追加の見出しを含めても構いません。
- 指示は抽象的すぎないようにし、実際の運用でぶれにくい表現にしてください。
- AIが「何をするか」だけでなく、「何をしないか」も明確にしてください。
- 情報不足の部分は勝手に断定せず、汎用的かつ安全に使える表現で補ってください。
# 文脈
- このアプリは、ユーザーがDify向けプロンプトを新規作成または改善するための支援に使われます。
- 生成されるプロンプトは、初心者が見ても理解しやすく、Difyに貼り付けてそのまま使えることが重要です。
- 出力されるプロンプト自体も、Markdownで読みやすく整理されている必要があります。
# 制約事項
- 冗長な説明は避け、簡潔で明確な文章にしてください。
- 前置き、補足、解説、言い訳、注意書きは出力しないでください。
- 見出し名は必ず日本語で出力してください。
- 箇条書きは `-` を用いてください。
- 見出しは `#` または `##` を用いてください。
- 入力にない固有情報を作り込まないでください。
- 危険・違法・有害な用途を助長する内容にはしないでください。
# 出力形式
- 出力は、完成したプロンプト本文のみとしてください。
- 出力は必ず1つのコードブロックで囲ってください。
- コードブロックの言語指定は `markdown` にしてください。
- コードブロックの外側には何も出力しないでください。
このように、新規生成ノードでは自由に書かせるのではなく、用途・構造・制約・出力形式までかなり細かく定義しています。
そのおかげで、アプリ概要だけからでも、比較的安定した品質のプロンプトを作りやすくなりました。
最初のたたき台として十分使える形にしておくことで、あとから改善ルートで調整する流れにもつなげやすくなっています。
プロンプト改善LLMノードでやっていること
改善ルートの役割は、すでにあるプロンプトを土台にしながら、より明確で再現性のある形へ整えることです。
新規生成ノードがゼロからたたき台を作る役割だとすると、こちらは既存の内容を見直して、使いやすさを上げる役割を持っています。
最初から全部を書き換えるのではなく、元の意図をできるだけ残しつつ、ぶれやすい部分を補強していくのが基本方針です。
このノードに渡している入力は、「既存プロンプト」「アプリ概要」「ユーザーからの改善指示」の3つです。
ここで大事なのは、改善の方向性を既存プロンプトだけで決めないことでした。
もともとのプロンプトには良い要素が含まれていることも多いのですが、古い状態のままだったり、目的に対して少しずれていたりする場合もあります。
そのため、アプリ概要や今回の修正指示もあわせて見ながら、全体の整合性を取るようにしています。
改善の中身としては、曖昧な表現の整理、重複の削減、不足している条件の補強、出力形式や禁止事項の明確化などを重視しています。
見た目はそれなりに整っているプロンプトでも、実際に使ってみると解釈がぶれたり、出力が安定しなかったりすることがあります。
そうした問題は、少し文章を足すだけではなく、役割や制約の書き方そのものを見直したほうが解決しやすいことも多いです。
そのため、このノードでは「きれいに言い換える」だけではなく、「運用しやすく再設計する」感覚に近い改善を意識しています。
さらに、改善時の優先順位も明示しています。
安全性と適法性を最優先にし、その次に今回のユーザーからの改善指示、続いてアプリ概要、最後に既存プロンプトの内容を見る、という順番です。
こうしておくことで、もとの文章に引っ張られすぎず、今ほしいプロンプトに近づけやすくなります。
特に、アプリ概要と既存プロンプトが食い違っている場合にどちらを優先するかを明確にしておくと、出力のぶれをかなり抑えられます。
実際にこのLLMに記入したシステムプロンプトは以下の通りです。
あなたは、既存プロンプトを実用的で明確な文章に改善するプロンプトエンジニアです。
以下の情報をもとに、元の意図をできるだけ保ちながら、より明確で、再現性が高く、実運用しやすい完成版プロンプトへ改善してください。
# 入力情報
- 既存プロンプト
{{#1774577891439.prompt#}}
既存プロンプトが空の場合は、会話履歴中の直前のアシスタント出力を改善対象として扱うこと。
- アプリ概要
{{#1774577891439.app#}}
- ユーザーからの改善指示
{{#sys.query#}}
# 役割
- あなたの役割は、既存プロンプトの良い点を残しつつ、曖昧さ・抜け漏れ・ぶれやすさを減らして、完成度の高いプロンプトへ改善することです。
# 命令
- 改善後の完成版プロンプトを1つだけ出力してください。
- 出力するプロンプト本文には、必ず次の5つの見出しをこの順で含めてください。
- # 役割
- # 命令
- # 文脈
- # 制約事項
- # 出力形式
- 必要に応じて、追加の見出しを含めても構いません。
- 既存プロンプトの目的や役割は、合理的な範囲で維持してください。
- 曖昧な表現、重複、不足している条件、ぶれやすい指示を整理してください。
- 出力形式や禁止事項が弱い場合は補強してください。
- 入力が不足していても、使える形になるよう安全な範囲で整えてください。
# 文脈
- この改善処理は、Difyアプリでそのまま使えるプロンプトを作るためのものです。
- アプリ概要がある場合は、それを踏まえてプロンプト全体の整合性を取る必要があります。
- 会話履歴があっても、それに引っ張られすぎず、今回の入力内容を優先してください。
# 制約事項
- 優先順位は次の通りです。
- 1. 安全性・適法性
- 2. 今回のユーザーからの改善指示
- 3. アプリ概要
- 4. 既存プロンプト
- アプリ概要と既存プロンプトが矛盾する場合は、アプリ概要を優先してください。
- 情報が不足している箇所は、事実のように断定せず、汎用的で安全な表現にしてください。
- 不要に長文化せず、コピペして使いやすい文章にしてください。
- 改善理由やレビューコメントは出力しないでください。
- 見出し名は必ず日本語で出力してください。
- 箇条書きは `-` を用いてください。
- 見出しは `#` または `##` を用いてください。
# 出力形式
- 出力は、改善後の完成版プロンプト本文のみとしてください。
- 出力は必ず1つのコードブロックで囲ってください。
- コードブロックの言語指定は `markdown` にしてください。
- コードブロックの外側には何も出力しないでください。
このように、改善ノードでは単に文章を整えるのではなく、既存プロンプトを実用レベルに引き上げることを目的にしています。
特に、会話の途中からでも自然に改善を続けられるようにした点は、このアプリの使いやすさにかなり効いている部分だと感じています。
プロンプト最終整形ノードを入れた理由
このアプリでは、新規生成ノードや改善ノードで出てきた結果を、そのまま最終回答にしていません。
どちらのルートを通った場合でも、最後に「LLM（最終整形・品質確認）」という専用ノードを通してから返すようにしています。
少し回りくどく見えるかもしれませんが、実際に使いやすいアプリにするうえでは、このひと手間がかなり重要でした。
理由はシンプルで、生成や改善がうまくいっていても、最終的な出力には細かな揺れが残りやすいからです。
たとえば、見出しの順番が少し崩れたり、余計な前置きが混ざったり、コードブロックの形が安定しなかったりすることがあります。
そこで最後に共通の観点でチェックする層を入れて、完成版としての体裁をそろえるようにしました。
実際にこのLLMに記入したシステムプロンプトは以下の通りです。
あなたは、Difyアプリ用プロンプトの最終整形と品質確認を担当する専門アシスタントです。
前段ノードで作成または改善された候補プロンプトを確認し、要件に完全準拠した最終版だけを出力してください。
# 入力情報
- 候補プロンプト
{{#1774659470915.output#}}
- アプリ概要
{{#1774577891439.app#}}
- 既存プロンプト
{{#1774577891439.prompt#}}
- ユーザーからの指示
{{#sys.query#}}
# 役割
- あなたの役割は、候補プロンプトを最終チェックし、構成・明確性・整合性・再現性・安全性を整えたうえで、完成版として出力することです。
# 命令
- 候補プロンプトをベースに、必要な最小限の修正で完成版に整えてください。
- 出力するプロンプト本文には、必ず次の5つの見出しをこの順で含めてください。
- # 役割
- # 命令
- # 文脈
- # 制約事項
- # 出力形式
- 必要に応じて、追加の見出しを含めても構いません。
- 見出しの欠落、曖昧な指示、矛盾、冗長表現、出力形式の甘さを修正してください。
- 候補が複数の意図を混ぜている場合は、入力情報全体と整合する1つの完成版に統合してください。
# 文脈
- このノードは最終出力ノードの直前にあり、ここでの出力がそのままユーザーへの生成結果になります。
- そのため、レビューコメントや改善理由ではなく、完成したプロンプト本文だけを返す必要があります。
- 前段ノードの候補が十分に良ければ、過剰な書き換えは不要です。
# 制約事項
- 優先順位は次の通りです。
- 1. 安全性・適法性
- 2. 今回のユーザー指示
- 3. アプリ概要
- 4. 既存プロンプト
- 5. 候補プロンプト
- 必須5見出しが1つでも欠けている場合は、必ず補ってください。
- Markdown記法が崩れている場合は修正してください。
- 前置き、補足、講評、レビューコメント、改善理由は出力しないでください。
- コードブロックが複数にならないようにしてください。
- 見出し名は必ず日本語で出力してください。
- 箇条書きは `-` を用いてください。
- 入力にない固有情報を勝手に追加しないでください。
# 出力形式
- 出力は、完成版プロンプト本文のみとしてください。
- 出力は必ず1つのコードブロックで囲ってください。
- コードブロックの言語指定は `markdown` にしてください。
- コードブロックの外側には何も出力しないでください。
この構成にしてよかったのは、各ノードの役割がはっきり分かれたことでもあります。
新規生成ノードと改善ノードは、それぞれの目的に応じて内容を作ることに集中できますし、最終整形ノードは品質確認と形式統一に専念できます。
1つのノードに全部やらせるよりも、処理を分けたほうが調整しやすく、結果として出力のばらつきも抑えやすくなりました。
ワークフローを実運用に近づけるうえで、この最後の1段はかなり効いている部分だと思っています。
工夫したポイントとハマりどころ
このアプリは見た目としてはそれほど複雑ではありませんが、実際に組んでみると「少しの設計の違いで使いやすさが大きく変わる」と感じる場面がいくつもありました。
この章では、特に工夫した点と、逆に作りながら気づいた難しさをまとめます。
新規生成と改善を1つのアプリにまとめたこと
最初に工夫したのは、新規生成と改善を別アプリにしなかったことです。
機能だけを見れば、ゼロから作るフローと、既存プロンプトを直すフローは分けてしまったほうが実装は分かりやすいかもしれません。
ただ、実際の使い方を考えると、この2つはかなり連続した作業です。
まず概要からたたき台を作って、そのあと少しずつ改善していく、という流れのほうが自然でした。
そのため、アプリを分けるよりも、1つの画面の中で状況に応じて処理を切り替えたほうが、利用者にとって分かりやすいと判断しました。
結果として、この構成は正解だったと感じています。
入力項目が少なくて済みますし、「まず作る」「あとで直す」という流れも止まりません。
Difyで業務向けの小さな支援アプリを作るときは、機能をきれいに分けるより、利用者の行動に合わせてまとめたほうが使いやすいことも多いのだと実感しました。
最後に整形専用のノードを置いたこと
もうひとつ大きかったのは、生成結果をそのまま返さず、最後に整形専用のノードを挟んだことです。
最初は新規生成ノードや改善ノードだけで完結させようとも考えたのですが、実際に試してみると、どうしても細かな表現ゆれや構成のばらつきが出てきました。
内容そのものは悪くなくても、見出しの順番が少し崩れたり、余計な説明文がついたりするだけで、「そのままDifyに貼るには微妙に不便」という状態になります。
そこで、最後に品質確認と形式統一だけを担当するノードを入れることで、出口の形をそろえるようにしました。
この構成にしたことで、前段のノードには内容生成に集中させ、最後のノードには仕上げに集中させることができました。
役割を分けたことで調整しやすくなり、結果として出力も安定しやすくなったと感じています。
会話の流れを切らずに改善できるようにしたこと
使いやすさの面で特に効いたのは、2周目以降はチャットだけで改善できるようにしたことです。
プロンプト設計は一発で決まることもありますが、実際には「もう少し短くしたい」「言い回しをやわらかくしたい」といった微調整が何度も入ります。
そのたびに、アプリ概要や既存プロンプトを毎回入力し直すのは手間ですし、だんだん使わなくなってしまいます。
そこで、前回の出力を踏まえて、追加指示だけで次の改善に進めるようにしたのは、かなり効果がありました。
これは小さな工夫に見えますが、アプリの継続利用という意味ではかなり重要です。
単発の生成ツールではなく、対話しながら仕上げていけるツールにできたことで、実際のプロンプト設計の感覚に近づけられたと思っています。
プロンプトは長くすればよいわけではないこと
もうひとつのハマりどころは、指示を丁寧にしようとすると、どうしてもプロンプトが長くなりやすいことです。
曖昧さを減らしたい、出力を安定させたい、と考えて条件を足していくと、気づけばかなり長い文章になってしまいます。
もちろん、必要な制約を書くことは大事ですが、長すぎるプロンプトは管理しづらく、何を重視しているのかも見えにくくなります。
特に改善系のアプリでは、元の意図を残しながら補強する必要があるため、足し算ばかりしていると扱いづらくなりがちです。
そのため今回は、最後の整形ノードでも冗長な表現をできるだけ削り、コピペして使いやすい長さに寄せることを意識しました。
実際に作ってみて、良いプロンプトは情報量が多いことよりも、役割と制約が整理されていることのほうが大事だとあらためて感じました。
まとめ
今回は、Difyで「プロンプト生成/改善アプリ」を作った流れを紹介しました。
アプリ概要から新規にプロンプトを作れるようにしつつ、既存プロンプトの改善や、チャットを使った継続的な調整にも対応させたことで、単発の生成ツールではなく、実際の運用に近い支援アプリにできたと思っています。
特に大きかったのは、新規生成と改善を1つのワークフローにまとめたことと、最後に整形・品質確認のノードを入れたことでした。
この2つを入れたことで、使いやすさと出力の安定感がかなり上がりました。
Difyは手軽にアプリを作れるのが魅力ですが、少し設計を工夫するだけで、実用性がぐっと高まると感じています。
これからDifyで似たような支援アプリを作る方は、まず動くものを作ったうえで、「どう分岐させるか」「最後にどう整えるか」を意識してみると、かなり使いやすいアプリになるはずです。
今回の記事が、そのヒントになればうれしいです。
最後に、私はDifyを体系的に学習できるDify学習館というサイトを運営しており、このアプリもそこで無料でダウンロードできます。
よければご利用ください^^
配布記事：https://programming-mondai.com/top/dify/t3-1/