DifyのDSL（YAML）とは？ファイルの作り方・使い方を完全解説

室谷

今回はDifyのDSL、つまりYAMLファイルの話をしましょう。.AI（ドットエーアイ）のコミュニティでも「DSLって何ですか？」という質問がかなり多いんですよね。

テキトー教師

講座でもよく出てきます。「GUIでワークフローを作ったあとに.ymlというファイルが出てきたんですが、これって何ですか？」という質問パターンですね。

室谷

まさにそれです。Difyで作ったアプリをエクスポートすると.ymlファイルが出てくるんですが、これがいわゆるDSLファイルです。

DSLというのはDomain Specific Language（ドメイン固有言語）の略で、Difyのワークフローやアプリの構造を定義するための言語です。

テキトー教師

簡単に言うと、GUIで作ったワークフローの「設計図をテキストで書いたもの」ですね。ノードの種類、接続関係、プロンプトの内容、変数の定義——これらが全てYAML形式でファイルに書かれています。

室谷

Difyって基本的にはGUIで直感的にワークフローを作れるんですが、その裏側ではずっとこのYAMLが動いているんですよね。GUIで操作すると自動的にYAMLが更新される、というイメージです。

テキトー教師

なので「dify dslとは」と調べる人の多くは、エクスポートしたファイルを見て「これは何だろう？」と思って調べているパターンが多い印象です。YAMLを理解できると、Difyの活用が一段階上がりますよね。

室谷

そうなんですよ。DSLを理解することで、GUIだけでは難しかった「バージョン管理」「チームでの共有」「テンプレート化」といったことが一気にできるようになります。

MYUUUでも社内のDifyワークフローはGitHubで管理していて・・・

テキトー教師

Gitで管理！それはかなり実践的ですね。コミュニティのメンバーさんもワークフローが増えてくると「どこに保存すればいいか」という問題に直面するんですよ。

DSLファイルとして管理すれば、変更履歴もとれるし、元に戻すこともできる。

室谷

まずこの記事を読んでいただければ、DSLの基本から実践的な活用法まで一通り理解できると思います。前回のDifyワークフローの作り方に続いて、今回はDSL/YAMLという「Difyの中枢」を深掘りしていきます。

Dify DSL（YAML）とは？GUIの裏側にある「設計図」

DifyのDSLファイルインポートメニュー（公式UIより）

室谷

まず基本から整理しましょう。Dify DSLはYAML形式で書かれているんですが、YAMLとはそもそも何かというと「Human-readable data serialization language」、人間が読み書きしやすいようにデザインされたデータ記述言語です。

テキトー教師

JSONみたいなものですが、もっとシンプルで見やすいですよね。インデント（字下げ）でデータの階層構造を表現するのが特徴で、コメントも書けるので「この設定の意味」をメモとして残しやすい。

室谷

DifyのDSLファイルを開いてみると、最初の方にこんな内容が書いてあります。app というキーがあって、その下に description、icon、mode、name といった基本情報がある。

これがアプリの名前や種類（ワークフロー/チャットボット）を定義している部分ですね。

テキトー教師

mode のところを見ると、ワークフローなら workflow、チャットフローなら chat、チャットボットなら chatbot と書かれています。ここを変えるだけでアプリの種類が変わる——というのが理解できると、DSLがどういうものか見えてきます。

室谷

実際にDifyのDSLファイルの中身はこんな構造になっています。

app:
  description: ''
  icon: "\U0001F916"
  icon_background: '#FFEAD5'
  mode: workflow
  name: サンプルワークフロー
  use_icon_as_answer_icon: false

テキトー教師

icon のところがユニコードエスケープ（\U0001F916）になっているのがわかりますよね。これはロボットの絵文字のコードで、このファイルをそのままDifyにインポートすればその絵文字がアイコンに使われます。

室谷

このようにDSLファイルはアプリの見た目から動作まで全部定義しているわけで、これをテキストで持っておけば「同じアプリを別の環境で作る」ことが一瞬でできる。これがdify dsl fileの価値なんですよね。

テキトー教師

ワークフロー全体の構造を整理すると、こういう構成になっています。

セクション	内容
`app`	アプリ名、説明、アイコン、モード（workflow/chat等）
`workflow`	ワークフロー本体。`graph`と`variables`を含む
`workflow.graph.nodes`	各ノードの設定（開始・LLM・回答等）
`workflow.graph.edges`	ノード間の接続関係
`workflow.variables`	ユーザーからの入力変数

室谷

graph の中に nodes（ノードの設定）と edges（ノード間の接続）が入っています。GUIで「ノードを繋ぐ線を引いた」という操作が、ファイル内では edges セクションに書かれているわけです。

テキトー教師

これがわかると「GUIで操作していることとDSLファイルの内容が対応している」というのが見えてきて、ファイルを直接編集する気力が出てくるんですよ（笑）。最初はとっつきにくいですが、構造を理解したら意外とシンプルです。

なぜGUIだけでは限界があるのか——DSLを使う3つの理由

室谷

DSLを使う理由を話しましょう。「GUIで作れるんだからDSLは不要じゃない？」という声も.AIコミュニティで出るんですよね。

でも本当に面白いのはそこじゃないんですよ・・・

テキトー教師

私も最初はそう思っていた受講生さんが多いんですが、実際に実務でDifyを使い始めると「あ、GUIだけじゃ辛い」という場面に必ず当たりますよ。

室谷

大きく分けて3つの理由があると思っています。まとめるとこうなります。

課題	GUIのみ	DSL活用
同じワークフローを複製したい	一から作り直し	コピペ一発
チームで開発・共有したい	スクリーンショット共有	ファイル共有
変更履歴を追跡したい	不可能	Git管理で追跡可能
本番/開発環境で使い分けたい	困難	環境別にファイルを管理

テキトー教師

「同じワークフローを複製したい」はかなりよくある悩みですね。例えばクライアントA向けに作ったRAGワークフローを、クライアントB向けにも使いたい——でもちょっと変えたい、というケース。

DSLがあればコピーして変数名だけ変えればOKです。

室谷

MYUUUでのケースだと、dify yaml githubで管理して、新しいプロジェクトが始まると「このリポジトリのworkflow-v2.ymlをベースにして」という会話が普通に出てきます。これはDSLなしには成立しない働き方ですね。

テキトー教師

あと見落とされがちな理由が「DSLファイルの仕様共有」です。「このDifyアプリってどういう動きをするの？」という質問に対して、DSLファイルを渡せば「全部ここに書いてあります」で済む。

dify dsl documentとして機能するわけです。

室谷

プロンプトの内容も全部ここに入ってるので、「どんなプロンプトを使っているか」を可視化したいときにも使えますし。プロンプトエンジニアリングの観点からもDSLを読めると強い・・・

テキトー教師

最近はAIエージェントがDSLファイルを直接生成してくれるケースも出てきましたよね。LLMにDSLを書いてもらうという使い方も現実的になっています。

室谷

まさに。Claude CodeにDSLを書かせてDifyにインポートする、という開発フローも実際にやっています。

LLMの精度が上がっているので、ちゃんとしたdify dsl syntaxに従ったコードを出力してくれる。

DSLファイルのエクスポートとインポート手順

DifyのDSLエクスポートボタン（公式UIより）

室谷

では実際の操作の話をしましょう。dify dsl exportとdify dsl importの手順です。

これ、意外と「どこにあるの？」という人が多くて・・・

テキトー教師

確かに最初は迷いますね。エクスポートはアプリの管理画面に入って「DSLをエクスポート」というボタンを押すだけです。

DSLファイルのエクスポート

室谷

エクスポートの手順を整理すると、こういう流れです。

Difyのダッシュボードから対象のアプリを開く
上部メニューから「DSLをエクスポート」ボタンをクリック
.ymlファイルがダウンロードされる

テキトー教師

シンプルですね。ダウンロードされたファイルをVSCodeなどのテキストエディタで開けば、YAML形式でワークフローの全内容が見られます。

dify dsl file downloadと調べている人はこの手順ですね。

室谷

ダウンロードしたdify yaml ファイルはそのまま保存しておくのがおすすめです。このファイルがあれば、何かあったときにいつでもワークフローを復元できます。

MYUUUでは大きな変更をする前にエクスポートしてGitにコミットするのが習慣になってます。

DSLファイルのインポート

DifyのDSLインポートダイアログ（公式UIより）

テキトー教師

インポートはDifyの新規アプリ作成画面から行います。「最初から作成」「テンプレートから作成」と並んで「DSLファイルをインポート」という選択肢が表示されます。

室谷

dify dsl importの手順はこうなります。

Difyダッシュボードの右上「アプリを作成する」をクリック
「DSLファイルをインポート」を選択
.ymlファイルをドラッグ＆ドロップ、または「参照」でファイルを選択
「作成する」をクリック

テキトー教師

URLからのインポートもできます。dify dsl urlとして、GitHubのRawファイルURLや、誰かがホスティングしているDSLファイルのURLを入力すれば、ダウンロードせずにそのままインポートできます。

室谷

これが結構便利で、「dify dsl share」という使い方につながるんですよ。GitHubでDSLファイルをパブリックに公開して、「このURLをインポートしてください」という形での配布ができる。

実際に僕もDSLを配布したことがありますが・・・

テキトー教師

コミュニティのメンバーさんにもDSLファイルを共有しながら「このワークフローを自分の環境にインポートして試してみてください」という形で教えると理解が早いんですよ。完成品を見た方が仕組みがわかりやすい。

室谷

まさにそうですね。中国語圏のDifyコミュニティも活発で、GitHubでdify github dslとして多数のDSLファイルが公開されています。

dify dsl 市場という観点でも、これは重要なエコシステムになっています。

DSLのワークフローノード記述方法——YAML基本構文をマスターしよう

Difyのワークフローノード構成（開始→知識検索→LLM→回答）

室谷

少し深掘りして、Dify YAML（DSL）の基本構文の話をしましょう。完全に理解しなくてもいいですが、最低限のdify yaml 基本構文を知っておくと、エラーが出たときに原因がわかるようになります。

テキトー教師

そうですね。プログラミング未経験の人でも、「このブロックがあのノードに対応してるんだな」くらいは読めるようになります。

大事なのは全部書けるようになることじゃなくて、読めるようになることですから。

ノード（nodes）の記述方法

室谷

DifyのワークフローYAMLで一番重要なのが nodes の記述です。各ノードはリスト形式で書かれていて、それぞれに id、type、data という基本プロパティがあります。

nodes:
  - id: "start"
    type: "start"
    data:
      title: "開始"
      variables:
        - label: "入力テキスト"
          max_length: 48
          options: []
          required: true
          type: "paragraph"
          variable: "query"
  - id: "llm-1"
    type: "llm"
    data:
      title: "LLM"
      model:
        name: "gpt-4o-mini"
        provider: "openai"
        mode: "chat"
      prompt_template:
        - role: "system"
          text: "あなたは優秀なアシスタントです。"
        - role: "user"
          text: "{{#start.query#}}"

テキトー教師

ここで大事なのが {{#start.query#}} という記法ですね。これが「startノードのqueryという変数を参照する」という意味です。

前のノードのアウトプットを後ろのノードで使うときに、この記法を使います。

室谷

GUIで「変数を参照する」をクリックしてノードを選ぶ操作が、コードでは {{#ノードID.変数名#}} という形になっているわけです。これがわかると「あー、GUIで選んだのがコレに変換されるのか」というのが見えてきますよね。

エッジ（edges）の記述方法

テキトー教師

ノード間の接続を定義するのが edges です。どのノードからどのノードへ流れるかを書きます。

edges:
  - id: "edge-start-to-llm"
    source: "start"
    target: "llm-1"
  - id: "edge-llm-to-answer"
    source: "llm-1"
    target: "answer-1"

室谷

シンプルですね。source が出発点のノードID、target が宛先のノードIDです。

条件分岐がある場合は source_handle と target_handle で分岐条件を指定できます。

テキトー教師

条件分岐ノード（IFELSEノード）を使う場合はもう少し複雑になりますが、基本の直線的なワークフローなら source と target だけ書けばOKです。

dify dsl versionの確認

室谷

あとdify dsl versionの話もしておきましょう。DSLファイルの先頭には version というフィールドがあって、最新バージョンはDifyのリリースに合わせて更新されています。

version: 0.1.x  # 最新バージョンに合わせる
kind: app
app:
  name: サンプルアプリ
  ...

テキトー教師

このバージョン番号、重要なんですよね。古いバージョンのDSLファイルをインポートすると、機能が足りないとか互換性の問題が起きることがある。

dify dsl バージョンが合っているかは確認した方がいいです。

室谷

GitHubで公開されているDSLファイルを使う場合は特に注意ですね。2年前のDSLをそのままインポートしてもうまく動かないことがある。

その場合はDifyのドキュメントを見て構造を修正する必要があります。

ChatflowとWorkflowのDSLの違い

室谷

次にdify chatflow dslとdify workflow dslの違いについて話しましょう。Difyには「チャットフロー」と「ワークフロー」という2種類のモードがあって、それぞれDSLの構造が微妙に違います。

テキトー教師

受講生さんが「どっちを使えばいいですか？」と聞くことが多いんですが、DSLの観点から言うと app.mode フィールドが違う、ということですね。

種類	`app.mode` の値	特徴
チャットフロー	`chat`	ユーザーとの往来型会話。複数ターン対応
ワークフロー	`workflow`	1回のリクエストに1回の処理。バッチ処理向き
チャットボット	`chatbot`	シンプルなQ&A型。LLMのみ使用
エージェント	`agent-chat`	自律的にツールを選択・実行

室谷

チャットフローのDSLには conversation_variables（会話変数）というセクションが追加されます。複数ターンの会話を通じて保持したい情報——たとえばユーザー名や過去の回答——をここで定義します。

テキトー教師

ワークフローの場合は会話というより「入力→処理→出力」の一方向なので、このセクションはありません。どっちを使うかはユースケース次第で、チャット形式が必要なら chat、バッチ処理や単発の処理なら workflow を選ぶといいですね。

室谷

あと dify dsl workflow と dify workflow dsl で検索する人が多いんですが、これは同じことを言っています。「WorkflowモードのDSLファイル」を探しているということですね。

DSLジェネレーターとAI自動生成

室谷

次は最近話題の「dify dsl generator」について。DifyにはAIがDSLを自動生成してくれる機能があります。

「ワークフロージェネレーター」という機能で、自然言語でアプリの仕様を書くとDSLが生成されます。

テキトー教師

受講生さんに紹介すると反応がいいですね。「自然言語でアプリが作れる」って聞くと「それなら自分でも作れそう！」ってなる。

まずはこれで骨格を作って、細かい調整は手動でやるのが現実的です。

室谷

dify dsl generator skillというキーワードで調べる人もいますが、これはDifyのワークフロージェネレーター機能のことですね。プロンプトの書き方次第で出てくるDSLのクオリティが全然違います。

テキトー教師

コツを整理すると、こういう点を意識するといいですね。

「何を入力して、何を処理して、何を出力するか」を具体的に書く
入力のデータ型（テキスト/数値/ファイル等）を明示する
使いたいLLMや外部APIがあれば名前を書く
出力の形式（JSON形式で返す、等）を指定する

室谷

例えば「ユーザーのテキスト（paragraph型）を受け取って、Claude APIを使って要約し、JSON形式で要約文とキーワードを返すワークフロー」みたいに書くと、ちゃんとそれに対応したDSLが出てきます。

テキトー教師

自動生成だけじゃなく、既存のDSLファイルをLLMに渡して「このノードにエラーハンドリングを追加して」と頼む使い方もあります。dify dsl 自動生成というより「DSLの改良をAIに頼む」という形ですね。

室谷

MYUUUでは実際にそのフローを使っています。既存のワークフローをエクスポート→Claude CodeにDSLを渡して修正依頼→インポートして動作確認。

これで開発スピードが上がってます。

DSLのGitHub活用とバージョン管理

室谷

DSLのバージョン管理について深掘りしましょう。dify yaml githubで管理するのが実際一番使いやすいです。

テキトー教師

これはかなり実践的な話ですね。「Gitは難しそう」という受講生さんも多いんですが、実は必要な操作は最低限でいいんですよ。

室谷

基本的なフローはこうです。

GitHubにプライベートリポジトリを作る
Difyでワークフローを変更する前にDSLをエクスポート
エクスポートしたYAMLファイルをコミット
必要なら別ブランチで改良版を作る

テキトー教師

チームで開発している場合は、このリポジトリを共有するだけでメンバー全員が同じワークフローを使えます。「このURLからDSLをインポートして」というのが成立する。

室谷

dify for dsl githubとして検索している人の多くは、GitHubで公開されているDSLサンプルを探しているケースが多いですね。github.comでdify dsl githubと検索すると、色々なワークフローのDSLが公開されています。

テキトー教師

参考になるDSLがあれば、そのままインポートして自分の環境で動かしてみる——という学習方法もアリですよね。動いているものを見て逆算する方が、ドキュメントを読むより理解が早いことも多い。

室谷

ただし公開されているDSLファイルを使う場合、dify dsl versionの互換性と、使用しているLLMプロバイダーが自分の環境にあるかを確認する必要があります。OpenAIを使っているDSLをAnthropicしか設定していない環境でインポートしてもエラーになります・・・

DSLインポート失敗の原因と対処法

テキトー教師

次に「dify dsl インポート失敗」というキーワードで調べる人が多いですが、よくある失敗パターンと対処法を話しましょう。

室谷

これ、結構ハマる人多いんですよね。でもほとんどの場合、原因は決まっています。

まとめるとこうなります。

エラーの原因	症状	対処法
dify dsl バージョン不一致	「サポートされていないバージョン」エラー	ファイル内のversionを確認・修正
LLMプロバイダー未設定	インポート後にワークフローが動かない	使用しているプロバイダーのAPIキーを設定
YAMLの構文エラー	インポート時にエラー	インデントを確認。タブではなくスペース2つ
存在しないモデル名	ワークフロー実行時エラー	利用可能なモデル名に変更
ファイルエンコーディング	文字化け	UTF-8で保存されているか確認

テキトー教師

一番多いのはやっぱりYAMLの構文エラーですね。YAMLはインデントがずれると全部壊れます。

タブ文字を使ってはいけなくて、スペース2つでインデントするのがルールです。

室谷

VSCodeで編集するとインデントのズレを視覚的に確認しやすいです。あとdify dsl importの際にエラーメッセージをよく読むと、どこが問題かが書いてあることが多い。

「line XX: ...」という形でエラー箇所が指定されているので、そこを確認すると早い。

テキトー教師

「dify 导入dsl 失败（DSLのインポートに失敗した）」というキーワードは中国語圏での検索ですが、同じ問題に世界中のユーザーが悩んでいるんですよね（笑）。

室谷

GitHubのIssueや中国語フォーラムにも解決策が書かれていることが多いので、英語や中国語で検索するのもおすすめです。「dify dsl import error」で検索すると結構情報が出てきます。

テキトー教師

あと「dify dsl 配布」して受け取った側がインポートしようとして失敗するケースでは、受け取ったファイルが正しいかどうかの確認もポイントです。メールやSlackで送受信する際にファイルが破損することがあります。

室谷

ファイルのmd5ハッシュを確認するか、シンプルにURLからのインポートを使う方が安全です。URLからインポートすれば、ファイルの送受信による破損は起きないので。

Dify DSLマーケットプレイスとテンプレート活用

室谷

Difyには公式のマーケットプレイス（dify dsl market）があって、色々なアプリのテンプレートが公開されています。これを活用するとゼロから作る手間が省けます。

テキトー教師

最初から作るより、まず似た用途のテンプレートをインポートして改造する方がずっと早いですよ。dify dsl templateとして使えるものが揃っています。

室谷

Difyの公式テンプレートはのダッシュボード内「探索」セクションで確認できます。チャットボット、RAG、ワークフロー自動化など様々なカテゴリに分かれています。

テキトー教師

気に入ったテンプレートはそのままインポートできますし、DSLとしてエクスポートして中身を確認することもできます。「dify dsl example」として学習材料にするのもいいですね。

室谷

コミュニティ側でもDSLの共有が活発になっていて、GitHubの wwwzhouhui dify for dsl というリポジトリには多数の実用的なDSLサンプルが集まっています。dify apps dsl exporter というツールを使うと、自分が持っているアプリを一括でエクスポートできます。

テキトー教師

講座で受講生さんに「良いDSLサンプルはどこで探せますか？」と聞かれたら、こう答えています。公式テンプレートを見てから、GitHubで「dify dsl sample」と検索する。

この順番が一番効率的です。

MCPとDSL——Dify 2.0時代の新しい使い方

室谷

ここ最近（2026年）で一番大きいトピックが「dify mcp dsl」の話ですね。DifyのワークフローをMCPサーバーとして公開できるようになって、DSLの活用範囲が一気に広がりました。

テキトー教師

MCPについて補足すると、Model Context Protocolの略で、AIエージェントが外部のツールを呼び出すための標準的なプロトコルです。これをDifyと組み合わせることで、「Difyで作ったワークフローをClaudeやCursorから呼べる」ようになります。

室谷

これが本当に便利で・・・。MYUUUでも自社の業務データを参照するRAGワークフローをDifyで作って、MCPサーバーとして公開して、開発チームがClaude Codeから呼び出す、という使い方をしています。

テキトー教師

このツイートにあるように、「DifyのワークフローをMCP化してClaude経由で使う」という使い方が現実的になっています。DSLでワークフローを定義して→MCPで公開する、という流れが次のトレンドだと思います。

室谷

dify mcp dslというキーワードで調べる人が増えているのも、この流れを反映してますね。DSLを理解しておくと、このMCPとの連携も理解しやすくなります。

RAGワークフローのDSL実例

テキトー教師

実践的な話として、dify rag dslの例を見てみましょう。RAG（Retrieval Augmented Generation）はDifyの使い方の中で最も多いユースケースなので、そのDSLの構造を把握しておくと便利です。

室谷

RAGワークフローの基本構成はこうです。

開始ノード（ユーザーの質問を受け取る）
知識検索ノード（ナレッジベースから関連情報を取得）
LLMノード（取得した情報と質問を組み合わせて回答生成）
回答ノード（ユーザーに回答を返す）

テキトー教師

さっきの画像がまさにこれですね。開始→知識検索→LLM→回答という直線的な流れ。

これがdify dsl workflowの基本パターンです。

室谷

知識検索ノードのYAMLはこんな感じです。knowledge_id に事前に作ったナレッジベースのIDを設定します。

- id: "knowledge-1"
  type: "knowledge-retrieval"
  data:
    title: "知識検索"
    query_variable_selector:
      - "start"
      - "query"
    dataset_configs:
      datasets:
        - dataset:
            enabled: true
            id: "YOUR_KNOWLEDGE_BASE_ID"
    retrieval_model:
      reranking_enable: false
      top_k: 4
      score_threshold_enabled: false

テキトー教師

query_variable_selector のところが「startノードのquery変数を検索クエリとして使う」という設定です。GUIでやると自動で設定されますが、DSLを見ればこういう接続になっているとわかる。

室谷

top_k: 4 は「関連度の高い上位4件のチャンクを取得する」という設定です。RAGの精度に直接関わるパラメータなので、ユースケースに応じて調整してください。

よくある質問

テキトー教師

よく受講生さんから来る質問に答えていきましょう。

室谷

「プログラミングの知識がなくてもDSLは使えますか？」という質問が一番多いですよね。

テキトー教師

これについては「読むだけならほぼ不要」と答えています。基本構造を一度理解したら、ほとんどはGUIの操作をYAMLに置き換えているだけなので。

書き方がわからなくてもGUIで操作してからエクスポートすれば、そのDSLをベースに改造できます。

室谷

「DSLファイルを直接書くのと、GUIで作るのはどっちが早いですか？」という質問も多いですね。

テキトー教師

用途によります。シンプルなワークフローはGUIの方が圧倒的に早い。

複雑な繰り返し処理がある場合や、既存のDSLを少し変えたい場合は直接編集の方が早いです。ハイブリッドが正解ですね——GUIで骨格を作ってからDSLで細かい調整、という使い方です。

室谷

「dify dsl fileの保存場所はどこにすればいいですか？」という話も。

テキトー教師

GitHubのリポジトリが最善ですが、まずはローカルのフォルダに整理するだけでも十分です。dify-workflows/ というフォルダを作って、アプリ名でファイルを命名してください（例: customer-support-chatflow.yml）。

室谷

あとdify docker compose yamlとdify dsl yamlを混同して「docker-compose.ymlをインポートしようとしたけど失敗した」という人も・・・

テキトー教師

あーそれはよく聞きますね（笑）。docker-compose.ymlやdify docker yamlはDifyの環境構築に使うファイルで、アプリのDSLファイルとは全くの別物です。

セルフホスティングの設定ファイルと、アプリの設計図は別物、というのを整理しておきましょう。

室谷

dify docker compose middleware yaml、dify docker compose override yaml、dify sandbox conf config yaml といったキーワードで調べる人は、Difyのインフラ設定（セルフホスト）を探しているということです。DSLのアプリファイルとは別の話ですね。

まとめ

室谷

今回はDifyのDSL（YAML）について一通り解説しました。まとめると、DSLはGUIの裏側にあるアプリの「設計図」で、これを理解・活用することでDifyの可能性が大きく広がります。

テキトー教師

最初からDSLを書く必要はなくて、まずGUIで作ってエクスポートして、構造を見てみるところから始めてください。「あ、このノードがここに対応してるのか」という発見が積み重なると、だんだん読めるようになります。

室谷

DSLを活用することで実現できることをまとめると：

ワークフローのバックアップ・復元
チームでの共有・コラボレーション
GitHubでのバージョン管理
テンプレートとしての再利用
LLMによるDSL自動生成・改良
MCPサーバーとしての公開

テキトー教師

DifyはGUIだけでも十分強力ですが、DSLを使いこなせるとさらにプロフェッショナルな使い方ができます。ぜひこの記事を参考に、DSLファイルを一度エクスポートして中身を見てみてください。

室谷

質問があれば.AIコミュニティでどうぞ。Dify関連の話は毎週活発に議論されているので、きっと誰かが答えてくれます。

DifyのDSL（YAML）とは？ファイルの作り方・使い方を完全解説