DifyのDSLとは｜アプリをYAMLで書き出して納品・移行する方法

Dify DSL を使うと、作ったアプリを相手のワークスペースに渡したり、別の環境へ移したりできます。納品や移行の前に、何がファイルに入り、何が入らないかを知っておくと、受け取った側の設定の手間を減らせます。

この記事の内容は、2026年10月2日に Dify の公式ドキュメントと GitHub のソースコードで確かめたものです。画面の表示や仕様は変わることがあります。使う前に、末尾の出典から最新の内容を確かめてください。

DifyのDSLとは

DSL は Domain Specific Language の略です。Dify の公式ドキュメントは、すべての Dify アプリを、Dify 独自のDSLでYAMLファイルに書き出せると説明しています。そのDSLファイルから、直接アプリを作ることもできます。ほかの Dify へ移したり、ほかの人と共有したりしやすくするための仕組みです。

ファイルの形式はYAMLです。n8n のワークフローのようなJSONではありません。Dify にJSONファイルをインポートしたい場合は、まず元のファイルが Dify から書き出したDSLかどうかを確かめます。公式ドキュメントは、DSLを、アプリの設定をまとめてYAML形式で残すための標準と位置づけています。

DSLには、アプリの設定とメタデータ、ワークフローとノードの設定、モデルのパラメータとプロンプトが入ります。中身はテキストなので、エディタで開いて読むこともできます。渡す前に開いて、APIキーや社内の情報が残っていないかを目で確かめておくと安心です。

DSLを使う場面

• 納品：作ったアプリを、相手のワークスペースに渡す
• 移行：試験用の環境で作ったアプリを、本番の環境へ移す
• 控え：アプリを大きく変える前や消す前に、設定を残しておく

同じワークスペースの中でアプリを複製したいだけなら、DSLは要りません。公式ドキュメントによると、複製すると設定、プロンプト、ワークフローがすべてコピーされ、元のアプリはそのまま残ります。DSLが役に立つのは、ワークスペースや Dify の環境をまたぐときです。アプリを消すと設定やログは元に戻せないため、公式ドキュメントは、消す前にDSLで控えを作ることを勧めています。

DSLを書き出す手順

公式ドキュメントは、書き出しの方法を2つ挙げています。

1. スタジオのページで、アプリのメニューから「DSL エクスポート」を選ぶ
2. アプリの編集画面で、左上の「DSL エクスポート」を選ぶ

アプリで Secret 型の環境変数を使っている場合は、書き出しに含めるかどうかを聞かれます。納品や共有のために書き出すときは、含めない側を選びます。含めると、APIキーなどの値がYAMLファイルに入るためです。

書き出したファイルは、名前にアプリ名と書き出した日を入れて保存しておきます。納品の後に直した版を渡すとき、どのファイルが最新かを相手と確かめやすくなります。

Dify の環境変数は、APIキーなどの秘密情報をアプリの外に置き、DSLを共有しても見えないようにするための仕組みです。プロンプトやノードの設定にAPIキーを直接書かず、環境変数に入れておくと、書き出したファイルを安心して渡せます。

DSLを読み込む手順

公式ドキュメントは、読み込みの流れを次のように説明しています。

1. DSLファイル（YAML形式）をアップロードする
2. Dify がバージョンの互換性を確かめる
3. DSLのバージョンが今の Dify より古い場合は、警告が表示される
4. ファイルの設定で、アプリが作られる

読み込んだ後は、モデルの提供元とツールの認証情報を設定し直します。ナレッジを使うアプリなら、ナレッジを作ってアプリにつなぎ直します。最後に、テスト用の入力で動きを確かめてから公開します。

読み込んだ側の作業は、渡す側が説明書をどこまで書いたかで変わります。設定の順番を説明書の手順と同じにしておくと、相手は上から順に進めるだけで済みます。分からない点が出たときに、どの手順で止まったかも伝えやすくなります。

書き出しに含まれないもの：APIキーとナレッジ

公式ドキュメントは、書き出されないものとして、サードパーティのツールのAPIキー、ナレッジの実際の中身、利用ログと分析データを挙げています。ナレッジは、つながりの設定だけが書き出され、文書のデータは入りません。

Dify のソースコード（GitHub の main ブランチ、2026年10月確認）では、書き出し時に次の処理も行われています。

• アプリが使うプラグインを、dependencies として一覧にする
• ナレッジ検索のノードにあるナレッジのIDを、ワークスペースごとに暗号化した形で書き出す
• Secret を含めない場合、ツールのノードから認証情報のIDを外す
• Webhook トリガーのURLを空にする
• スケジュールのトリガーの設定を既定の値に戻す

そのため、読み込んだ側では、プラグインの導入、認証情報の設定、Webhook のURLの確認、スケジュールの設定し直しが必要になることがあります。説明書にこれらを書いておきます。

バージョンが違う環境に移すときの注意

Dify のクラウド版について、公式ドキュメントは、常に最新のDSLのバージョンで動くため、読み込んだファイルは互換性があると説明しています。自分のサーバーで動かす版の説明では、新しい Dify で作ったDSLを読み込むには、先に Dify を新しくする必要がある場合があると書かれています。

ソースコードでは、DSLに書かれたバージョンと、読み込む側のバージョンを比べて、扱いを分けています。

相手が自分のサーバーで Dify を動かしている場合は、納品の前に相手の Dify のバージョンを聞いておきます。自分の環境のほうが新しい場合は、相手と同じバージョンの環境で作り直すか、相手に Dify を新しくしてもらうかを決めます。クラウド版で作ったアプリを、相手の自分のサーバーへ移す場合も同じです。警告付きで取り込まれた場合は、ノードの設定が意図どおりかを1つずつ開いて確かめます。

Chatflow と Workflow のアプリには、バージョン管理の機能もあります。公開した版が記録され、以前の版を下書きに読み込み直せます。納品した版には名前を付けておくと、後で直すときに区別できます。2つの形式の違いはDifyのChatflowとWorkflowの違いで説明しています。

納品物に添える説明書

DSLファイルだけでは、受け取った側が動かせないことがあります。次の内容を説明書に書きます。

• アプリの目的と、入力から出力までの流れ
• 作った環境（クラウドか自分のサーバーか）と Dify のバージョン
• 使うモデルの提供元と、APIキーを発行する手順
• 必要なプラグインと、入れ方
• 環境変数の名前と、入れる値の説明（値そのものは書かない）
• ナレッジに入れる文書と、作り方の手順
• Webhook やスケジュールの設定し直し方
• 動作確認に使う入力の例と、期待する結果

Dify を自分のサーバーで動かして商用で使う場合は、ライセンスの条件も確かめます。条件はDifyの商用利用で説明しています。

Employee Store では、DSLファイルと説明書を、取引ごとの納品ボックスで渡します。納品は原則3営業日以内で、過ぎた場合は返金になります。購入者は取引ルームで納品物を確かめ、受領を確認します。出品ページに書く内容はAIエージェントの説明の書き方、取引の流れはEmployee Store の使い方をご覧ください。