Difyでプロンプトやノードを触っていると、「本番を壊さずに試したい」「うまくいった版に戻したい」という場面がすぐ来る。
公式ドキュメントでは、Chatflow / Workflow 向けのバージョン管理、アプリの複製、DSL（YAML）のエクスポート／インポートが用意されている。
この記事では、公開情報をもとに、初心者が安全に実験するための使い分けを整理する。
結論：まずこの3層で覚える
| やりたいこと | 使う機能 | 要点 |
|---|---|---|
| ライブを変えずにプロンプトを試す | Current Draft（下書き） | 下書きはユーザーに見えない。公開するまで本番は据え置き |
| 良い版を本番にする／戻す | Publish Update / Restore | 公開で Latest になる。復元は下書きをその版で置き換える |
| 別条件で並行実験する | Duplicate（複製） | 設定・プロンプトが丸ごとコピーされ、元アプリと独立 |
| バックアップ／持ち運び | Export DSL / Import DSL | モデル設定・プロンプト・ワークフロー構成を YAML で持ち出せる |
迷ったら「まず下書きで試す → 問題なければ Publish」。いきなり本番アプリを直接いじる必要はない。
なぜ「そのまま編集して公開」が危ないか
プロンプトは一度変えると、回答のトーン・根拠の有無・ツール呼び出しの癖まで変わる。
Dify公式の公開説明でも、Publish を実行すると、既に稼働中のライブアプリ設定が現在の設定に置き換わるとされている（Webアプリ・API・埋め込みなど、公開経路は設定を共有する）。
つまり「ちょっと文言をいじっただけ」でも、公開操作をした瞬間から利用者に届く。
安全な実験とは、ライブに届く更新と、手元の試行錯誤を分けることに尽きる。
Chatflow / Workflow のバージョン管理
公式の Version Control ドキュメントでは、対象は いまのところ Chatflow と Workflow アプリのみと明記されている。
3つの状態
| 状態 | 意味 |
|---|---|
| Current Draft | いま編集している作業版。ユーザーにはライブでない |
| Latest Version | ユーザーが見ている現行の公開版 |
| Previous Versions | 過去に公開した版 |
操作の基本は次のとおり。
- 下書きでプロンプトやノードを変更する
- デバッグ／プレビューで確認する
- Publish → Publish Update で下書きを最新公開版にする
- 公開後、また新しい下書きが作業用に用意される
履歴アイコンから版一覧を見られる。名前付けやリリースノート編集、不要な古い版の削除もできる（Current Draft と Latest Version は削除不可）。
Restore（復元）の注意点
古い版を Restore すると、その内容が現在の下書きを完全に置き換える。未保存の試行がある状態で復元すると消える。
公式 Tips も「公開前に必ず下書きでテストする」「重要なリリースには分かりやすい版名を付ける」「ロールバックが必要なら Restore」と書いている。
また英語版ドキュメントには、版の復元・特定版の DSL エクスポート・Service API で特定公開版を実行する機能は有料プラン向けであり、Sandbox プランではアプリは常に最新公開版を実行する、との注記がある。利用中のプランでどこまで使えるかを先に確認すると安全だ。
下書きで試すときの実務ルール
| ルール | 理由 |
|---|---|
| 変更は1テーマずつ | 「プロンプト文言」と「モデル温度」を同時に変えると、効いた要因が分からない |
| 固定の評価セットで比較する | 毎回ちがう雑談入力だと、良し悪しが気分依存になる |
| 公開前に必ずプレビューする | Publish はライブ設定の置き換えだから |
| うまくいった版には名前を付ける | 履歴が autogenerated 名だらけだと後から探せない |
評価セットは大げさなものでなくてよい。たとえば次の5件をメモしておくだけで実験が安定する。
1. 正常系の代表質問（答えが一意に決まるもの）
2. 知識外／断定できない質問（断る・根拠を求める挙動）
3. 曖昧な質問（聞き返しが必要か）
4. 長文入力（要約や truncation の挙動）
5. 危険／ポリシー違反っぽい入力（拒否できるか）
同じ5件を、変更前の Latest と変更後の Draft で並べて見る。感覚比較をやめるだけで、プロンプト実験の再現性が上がる。
並行実験したいときは Duplicate
公式のアプリ管理ドキュメントでは、複製（Duplicate）の用途として次が挙げられている。
- 異なるプロンプトやモデルでの A/B テスト用バージョン
- 別オーディエンス向けの適応版
- 成功パターンを出発点にした新規プロジェクト
- 大きな変更前のバックアップ
複製では設定・プロンプト・ワークフローがコピーされ、元アプリは変わらない。複製後のアプリは独立して動く。
命名は公式推奨どおり Draft- / Test- / Prod- などの接頭辞が分かりやすい。
Prod-support-bot ← ライブ想定（触る前に複製）
Test-support-bot-promptA ← プロンプト案A
Test-support-bot-promptB ← プロンプト案B
「同一アプリの下書き履歴」で足りる変更と、「別アプリとして並べて比較したい変更」を切り分けると迷いにくい。
| 状況 | おすすめ |
|---|---|
| 文言の微調整・ノード1個の修正 | 同じアプリの Draft → Publish |
| モデルやプロンプト方針を大きく分岐させたい | Duplicate して並行比較 |
| ロールバック前提の大きな改修 | まず Duplicate か DSL バックアップ |
DSL エクスポート／インポートで版を残す
Dify DSL は YAML 形式のアプリ定義（公式では v0.6 以降の標準として説明）。ワークスペース間の共有やバックアップに使う。
含まれるもの／含まれないもの
| 含まれる | 含まれない |
|---|---|
| アプリ設定・メタデータ | サードパーティAPIキー |
| ワークフロー／ノード設定 | ナレッジベースの本文データそのもの |
| モデルパラメータ・プロンプトテンプレート | 利用ログ・分析データ |
| ナレッジへの接続情報（参照） | （上記以外の実行時データ） |
安全な持ち出しの注意
- Secret 型の環境変数を含むアプリをエクスポートすると、含めるか確認される。秘密情報は安易にファイルへ出さない
- 公式のキーコンセプトでも、環境変数で API キーなどをアプリ本体から分離し、DSL 共有時にパスワードやキーを晒さない設計が推奨されている
- CLI（
difyctl export studio-app）では、Workflow / Chatflow は既定で現在の下書きをエクスポートする。公開版を出したい場合は--workflow-id指定が可能（CLI ドキュメント）
Git で管理するなら「人が読める差分」より リリース前スナップショットとして使うのが現実的だ。プロンプト文字列の1行差分を追う用途ではなく、「この日の動いていた設定一式」を残す用途向きである。
安全な実験の最小フロー
初心者向けの最短手順は次のとおり。
1. いまの Prod 相当アプリを開く
2. 必要なら Duplicate して Test- を作る（または Prod の Draft だけで進む）
3. Draft でプロンプトを1点だけ変える
4. 固定の評価セット（5問程度）でプレビュー
5. 問題なければ Publish Update
6. 重要リリースには版名と一言メモを付ける
7. 定期的に DSL をエクスポートしてバックアップ（Secret は含めない）
大きな変更の前だけでも、手順 2 と 7 を入れると「戻せない編集」が減る。
実装チェックリスト
- 対象アプリが Chatflow / Workflow なら、履歴から Current Draft / Latest / Previous を確認した
- プロンプト変更は Draft で行い、公開前にプレビューした
- 評価用の固定質問セット（少なくとも正常系＋失敗系）を用意した
- 一度に変える変数を1つに絞った（文言 or 温度 or ノード構成）
- 重要な公開版にわかりやすい名前を付けた
- 大きな方針分岐は Duplicate で Test- アプリを分けた
- DSL バックアップを取り、Secret を含めていない
- Publish がライブ全公開経路に効くことを理解したうえで更新した
- 利用プランで Restore / 特定版 API 実行が使えるかを確認した
失敗パターン
パターン1：下書き確認なしで Publish してしまう
→ 対策：Publish 前に固定質問セットでプレビュー。公開は「確認済み」のときだけ。
パターン2：プロンプト・モデル・ノードを同時に変えて比較不能になる
→ 対策：1変更＝1実験。効いた要因をメモに残す。
パターン3：Restore で作業中の下書きを消す
→ 対策：復元前に DSL エクスポートか Duplicate。未保存の試行がない状態で Restore する。
パターン4：本番アプリで直接 A/B し、利用者に未検証応答が届く
→ 対策：A/B は Duplicate した Test アプリで行う。勝った案だけ Prod に反映する。
パターン5：DSL に Secret を含めて共有する
→ 対策：エクスポート確認で Secret を含めない。キーは環境変数側で管理する。
パターン6：Sandbox なのに「特定の古い公開版を API で動かしている」と思い込む
→ 対策：公式注記どおりプラン差を確認する。使えないなら Latest 前提で運用設計する。
まとめ
- Difyの安全なプロンプト実験の中心は Draft と Latest の分離（Chatflow / Workflow）。
- 公開（Publish Update）はライブ設定の置き換えなので、試行は下書きか Test 複製で行う。
- 並行比較とバックアップには Duplicate と DSL が向く。Secret は持ち出さない。
- 評価セットを固定し、変更は1点ずつにすると「何が効いたか」が分かる。
次の一歩としては、いま使っている Chatflow / Workflow で履歴パネルを開き、Latest と Draft の違いを確認したうえで、プロンプトを1行だけ変えてプレビュー比較すると理解が定着する。
参考リンク
- Version Control（Dify Docs）
- Manage Apps（Dify Docs）
- Key Concepts（Dify Docs）
- difyctl apps（Export studio-app）
- Lesson 10: Publish and Monitor Your AI App
- Dify公式ドキュメント
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。