DifyでAIアプリケーションを開発する際、プロジェクトの進行に伴う要件変更や、プロトタイピングから本番実装への移行段階で、アプリケーションのモード（チャットフローなのか、ワークフローなのか）を変更したいというニーズが発生することがあります。例えば、「当初はデータ処理を目的としたワークフローとして構築したが、ユーザーとの対話機能が必要になったためチャットフローに移行したい」といったケースです。
このようなモード変更において、アプリケーションを一から再構築するのは、大幅な出戻りとなり開発工数を圧迫します。今回はDSLファイルを編集することで、チャットフローとワークフローを簡単に変換する方法を紹介します。
1. はじめに
Difyのチャットフローとワークフローについて
Difyは、直感的なインターフェースで高度なAIアプリケーションを構築できるプラットフォームです。その中でも「チャットフロー」と「ワークフロー」は、開発の核となる2つのモードです。
- チャットフロー: ユーザーとの対話を通じてタスクを遂行するアプリケーションです。チャットボットや対話型AIエージェントなどが該当します。
- ワークフロー: 一連のデータ処理を実行し、結果を出力するアプリケーションです。データ整形、外部API連携、定型業務の自動化などに利用されます。
両者はユースケースが明確に異なるため、開発フェーズの進行に応じてモード変更の必要性が生じることは少なくありません。
2. 実際の変換手順
では、DSLファイルを使った変換の具体的な手順を見ていきましょう。
ステップ1：アプリケーションのDSLファイルをエクスポートする
まず、変換したいDifyアプリケーションのDSLファイルを以下の方法でエクスポートします。
- Difyの「Studio」ページに移動します。
- アプリケーションのオーケストレーション（編集）ページに入り、画面左上にある「DSLをエクスポート」をクリックします。
エクスポートされるDSLファイルはYAML形式で、アプリケーションの基本設定、モデルのパラメータ、ノードの構成情報などが含まれています。
⚠️ エクスポート時の注意点:
- 認証情報は含まれない: DSLファイルには、ツールノード（例: Google Searchツールやfirecrawlなど）に設定したAPIキーなどの認証情報は含まれません。インポート後に再設定が必要です。
- 機密性の高い環境変数: 環境変数にSecretタイプの変数が含まれている場合、エクスポート時にこれらの機密情報をエクスポートに含めるか尋ねるプロンプトが表示されることがあります。
ステップ2：DSLファイルを編集する
エクスポートしたYAML形式のDSLファイルを、任意のテキストエディタで開きます。
2-1: ワークフロー → チャットフローへの変換
【修正箇所】
appセクションのmode: workflowとなっている箇所をmode: advanced-chatに書き換えます。
2-2: チャットフロー → ワークフローへの変換
【修正箇所】
appセクションのmode: advanced-chatとなっている箇所をmode: workflowに書き換えます。
2-2-1: LLMでメモリ機能を使用している場合
ワークフローに変換すると、LLMのメモリ機能が使用できなくなります。そのため、DSLファイル内のメモリ機能自体を削除するために以下の作業をする必要があります。
workflow > graph > nodes 配下にある各ノード定義の中から、type: llm となっているLLMノードを特定します。当該ノードの data セクション内に memory キーが存在する場合、そのキーごとセクション全体を削除します。
【修正例】
例えば、以下のBeforeの画像の、121行目に、type: llmという記述があり、llmノードについてのセクションであるとわかります。そして、101行目から108行目のmemoryセクションをすべて削除しましょう。Afterの画像のようになれば完了です。
Before
After
【理由】
ワークフローモードは会話履歴を保持する memory 機能をサポートしていません。この定義が残存していると、インポート時にDifyがモードと定義の不整合を検知し、エラーが発生します。そのため、この削除処理は必須です。
2-2-2: 会話変数を使用している場合
ワークフローに変換すると、LLMの会話変数が使用できなくなります。そのため、DSLファイル内の会話変数自体を削除するために以下の作業をする必要があります。
workflow配下でconversation_variablesセクションを見つけます。そのセクションを丸々 conversation_variables: []に変更してください。
【修正例】
例えば、以下のBeforeの画像の、11行目から19行目をすべて削除し、Afterの画像のようにそのセクションがあった場所（11行目）にconversation_variables: []を入れることで、Afterの画像のようになれば完了です。
Before
After
2-3: 上記の2-1,2-2の編集を自動的に行うDifyアプリを作成することもできます
実は、以下の画像のように、今まで紹介した2-1~2-2-2の編集を自動的に実行してくれるDifyアプリを作成することもできます。処理していることは上記2-1~2-2-2と同様です。なお、difyのテキスト抽出はYML形式のファイルに対応していません。そのため、最初に手動でMARKDOWN形式にファイルタイプを変換してからファイルを入力しています。
入力画面
Difyのオーケストレート画面
出力画面には以下の画像のようにMARKDOWN形式で出力されます。これをコピーしてテキストエディタの新規ファイルに貼り付け、yml形式にファイルタイプを戻せば、次の「ステップ3：編集したDSLファイルをインポートする」と同様の手順でインポートできます。
ステップ3：編集したDSLファイルをインポートする
編集したDSLファイルをDifyにインポートします。
- Difyの「Studio」ページに戻ります。
- 「アプリを作成する」の項目の「DSLファイルをインポート」を選択し、編集したYAMLファイルをアップロードします。
⚠️ インポート時の注意点:
- バージョンチェック: インポート時にDSLファイルのバージョンチェックが行われ、Dify本体のバージョンとDSLファイルのバージョンに差異がある場合、警告が表示されることがあります。
- SaaS版Difyユーザーの場合、エクスポートされるDSLファイルは常に最新バージョンです。
- セルフホスト版（Community Edition）ユーザーの場合、互換性の問題を避けるため、Difyを最新版にアップグレードしてからDSLをエクスポート・インポートすることが推奨されます。
警告が出た場合は、無理にインポートを進めず、可能であればエクスポート元のDify環境を更新して再エクスポートすることを検討してください。
3. 変換後の変数の調整が必要
app.modeを変更したDSLファイルをインポートしただけでは、アプリケーションは正常に動作しません。モードの特性に合わせて、ノードや変数を手動で調整する必要があります。
app.mode変更だけでは終わらない理由
app.modeの値は、Difyに対してアプリケーションの動作モード（チャットフロー or ワークフロー）を宣言するものです。しかし、ファイル内に旧モードでしか利用できないノード定義や変数参照が残っている場合、それらが実行時エラーの原因となります。
そのため、モード変更後は、各モードの仕様に準拠するよう、以下のようなアプリケーションのオーケストレートで変数やノードの変更が不可欠です。
3-1: ワークフローからチャットフローへの移行の場合
終了ノードから回答ノードへの変更
ワークフローの「終了ノード」は、チャットフローではそのままでは機能しません。チャットフローの「回答ノード」に置き換える必要があります。出力に使う変数を忘れないようメモなどした上で、「終了ノード」を削除し、「回答ノード」を追加し、設定し直しましょう。
3-2: チャットフローからワークフローへの移行の場合
回答ノードから終了ノードへの変更
チャットフローの「回答ノード」は、ワークフローではそのままでは機能しません。ワークフローの「終了ノード」に置き換える必要があります。出力に使う変数を忘れないようメモなどした上で、「回答ノード」を削除し、「終了ノード」を追加し、設定し直しましょう。
3-2-1: LLMのメモリ機能を使用していた場合
ワークフローには会話履歴を記憶するメモリ機能がありません。そのため、メモリ情報に依存するロジックはすべて動作しなくなります。必要な情報は、実行時に利用者に入力してもらうようにしたり、ノードに直接変数として引き渡すようにするなどして、メモリ機能を使用しないように再設計が必要です。
3-2-2: 会話変数を使用していた場合
ワークフローでは会話変数の機能がありません。ノード内で会話変数を使用していた場合は、会話変数を削除した上で、会話変数を使用しないように再設計が必要です。
3-2-3: 開始ノードの一部の変数（sys.queryとsystem.dialogue_countとsys.conversation_id）を他のノード内で入力変数として使用していた場合
ワークフローの開始ノードでは、チャットフロー特有の sys.queryなどの変数は利用できません。これらの変数を使用していた場合は、ノード内のこれらの変数を削除した上で、別の入力方法（例：開始ノードでカスタム変数やファイル入力を新たに定義する）に置き換える必要があります。
4. まとめ
DSLファイルの編集を使った変換は、Dify開発における生産性を大幅に向上させる強力な手法です。
本手法のメリット:
- 開発資産の再利用: 既存のロジックやノード構成を流用でき、無駄な再開発コストを削減します。
- 仕様変更への俊敏性: プロジェクト要件の変更に迅速かつ柔軟に対応可能です。
- 工数削減とリードタイム短縮: 再構築に伴う手間を大幅に削減し、開発サイクルを高速化します。
主な注意点:
- モード変更は第一歩: app.modeの書き換えだけでは不十分であり、後続の手動調整が必須です。
- 手動での再構成: 両モード間の仕様差（ノード、変数等）を理解し、手動で調整する必要があります。
アプリケーションを変換する際は、作業前に必ずDSLファイルをバックアップとして保存することを強く推奨します。この手法を習得することで、より高度で柔軟なAIアプリケーション開発が可能になります。
参考文献
Discussion