Dify 1.x でワークフローのバージョン管理が実用的になった

Dify の 1.x 系のアップデートで、ワークフローに「版」を残せるようになりました。公開した時点の状態が履歴として保存され、名前やメモを付けて、あとから一覧で見比べたり、選んだ版に戻したりできます。地味な機能に見えますが、私たちが Dify で業務エージェントを作ってきた中で、いちばん困っていたところに手が入った印象です。この記事では、何が変わったのか、どんな場面で効くのか、PoC の段階でどう運用に組み込むと有効かを整理します。

これまで何に困っていたか

Dify のワークフローは、ノードを繋いで画面上で組み立てるので、変更のハードルがとても低いです。プロンプトの一文を直す、分岐の条件を少し変える、ナレッジ検索の件数を増やす。どれも数分でできます。ところが、この手軽さが PoC の後半になると逆に効いてきます。

よくあるのが、「先週のほうが回答が良かった気がするけれど、何を変えたか思い出せない」という状態です。プロンプトを何度も直しているうちに、どの変更で精度が上がり、どの変更で崩れたのかが追えなくなります。もう一つは、動いているものを壊す怖さです。現場で使い始めたエージェントに手を入れるとき、これまでは DSL をエクスポートして手元に控えを取る、あるいはアプリごと複製してから触る、といった運用でしのいでいました。控えを取り忘れた変更が一つでもあると、戻る場所がなくなります。

複数人で触る場合はさらに難しくなりました。担当者 A が直したプロンプトを、担当者 B が知らずに上書きする。その結果、誰の変更が今の挙動を作っているのか、誰も説明できない。PoC を「試行錯誤の記録」として残したいのに、記録が残らない構造になっていました。

何が変わったのか

1.x 系では、ワークフローを公開するたびに、その時点の状態が一つの版として履歴に残ります。版には名前と説明を付けられるので、「回答形式を箇条書きに変更」「検索件数を 3 から 5 に」といったメモを添えておけます。履歴はエディタから一覧で確認でき、過去の版を選んで復元すれば、その内容が編集中のドラフトに戻ってきます。

ポイントは、編集中のドラフトと公開済みの版が切り離されている点です。ドラフトでいくら試しても、公開しない限り現場で動いているものは変わりません。試して、良ければ公開して版を残す。悪ければドラフトを捨てるか、前の版を復元する。この流れが標準の操作として用意されました。

具体的にどんなときに便利か

まず、精度チューニングの比較です。同じ質問セットを版 A と版 B に投げて結果を並べる、という作業が現実的になりました。以前は「直す前の状態」を再現すること自体に手間がかかっていましたが、今は版を復元すればすぐに同じ条件を作れます。

次に、本番で動いているエージェントの改修です。運用中のワークフローに手を入れるとき、直前の版がそのまま残っているので、問題が出たらその版に戻すだけで済みます。改修のたびにアプリを複製して切り替える運用が不要になり、URL や API の接続先も変わりません。

三つ目は、複数人での編集です。誰がいつ何を変えたかが版の履歴に残るので、挙動が変わったときに「どの版から変わったか」を特定できます。意図せず上書きしてしまった場合も、上書き前の版に戻せます。

最後に、クライアントへの説明です。PoC の報告で「この 2 週間でこう変えて、こう良くなりました」と話すとき、版の履歴がそのまま変更の記録になります。メモを丁寧に付けておけば、報告資料の下書きに近いものが自然に溜まっていきます。

PoC でどう運用に組み込むか

機能があるだけでは、使い方がばらつきます。私たちが PoC で回してみて、これなら続けられると感じた運用を書いておきます。

一つ目は、版の名前の付け方を最初に決めることです。おすすめは「日付＋変更内容の一言」です。「0922 回答形式を箇条書きに」のような形で、誰が見ても何をしたか分かるようにします。説明欄には、変更の理由と、期待した効果を一行で残します。あとから比較するときに、この一行があるかないかで作業時間が大きく変わります。

二つ目は、変更の単位を小さくすることです。プロンプトの修正と検索条件の変更を同時に入れると、良くなっても悪くなっても原因が分かりません。一つの版には一つの変更、を原則にします。手数は増えますが、PoC の目的は「何が効くかを知ること」なので、ここは崩さないほうがいいです。

三つ目は、評価用の質問セットを固定することです。現場から集めた 20〜30 問程度を用意し、版を公開するたびに同じセットを流して結果を記録します。記録先はスプレッドシートで十分です。版の名前と、各質問の結果の良し悪しを並べておくと、どの版が現時点のベストかが一目で分かります。

四つ目は、「現場に見せる版」と「試している版」を意識して分けることです。現場のメンバーが触るのは公開済みの版だけ、というルールにしておけば、ドラフトで大胆に試しても影響が出ません。週に一回など、公開のタイミングを決めておくと、現場側も「今週は何が変わったか」を把握しやすくなります。

五つ目は、戻す手順を先に決めておくことです。問題が起きたときに誰が判断して、どの版に戻すのか。復元は数クリックですが、判断の担当が決まっていないと結局戻せません。PoC の初期に一度、わざと前の版に戻す練習をしておくと、本番に入ってからも慌てずに済みます。

気を付けたい点

版として残るのはワークフローの構成です。ナレッジベースの中身や、モデルの API 設定など、ワークフローの外にあるものは対象になりません。ナレッジに文書を追加したり差し替えたりした場合、その変更は版を戻しても元には戻らないので、ナレッジ側の変更履歴は別に記録しておく必要があります。

また、版を復元すると、その内容がドラフトに反映されます。復元しただけでは公開されないので、現場に戻したい場合は復元した版をあらためて公開する、という一手間が要ります。ここを忘れると「戻したつもりなのに変わっていない」ということが起きます。

まとめ

Dify は「作るのが早い」ことが強みでしたが、作ったあとの「育てる」段階では、記録が残らないことが弱点でした。バージョン管理が入ったことで、試行錯誤を記録として残しながら進められるようになり、PoC から運用へ移すときの不安も小さくなります。

新しく PoC を始めるなら、最初の週に版の名前のルールと評価セットだけ決めておいてください。それだけで、2 か月後に「何が効いたか」を説明できる状態が手に入ります。

出典: Dify 公式