Difyの使い方｜ワークフローの作り方とノード一覧

Dify は、LLM を使うアプリを画面上で「ノード（処理の箱）」をつないで作るツールです。 1回の入力を処理して結果を返すなら「ワークフロー」、会話を続けるなら「チャットフロー」を選び、開始ノードから順に LLM・知識検索・条件分岐などをつなぎます。作ったアプリは、DSL（YAML ファイル）で書き出せ、API から呼べます。

確認環境：Dify 1.17.1（2026年9月10日のリリース。GitHub のリリース一覧で「Latest」の版）のソースを git clone して確かめました。ノードの種類はソースの定義（Dify が使うワークフロー実行ライブラリ graphon 0.7.0 の BuiltinNodeTypes と、Dify 側のトリガー・知識検索の定義）で、DSL の版と読み込みの判定は api/services/app_dsl_service.py・api/services/dsl_version.py で、作例の DSL は graphon 0.7.0 のノードの定義クラス（Pydantic）と DSL 読み込み関数で検証しました。API のリクエストの項目と SSE のイベントの種類は api/controllers/service_api・api/core/app/entities/task_entities.py で、送るコードは Dify の応答の形を返す擬似サーバー（手元の小さな HTTP サーバー）に向けて Python 3.11.15・requests 2.34.2 で確かめました。Docker Compose の構成と既定値は docker/ のファイルで、必要なスペックと手順は docs.dify.ai で確かめました。Dify を起動してモデルを動かすことはしていません（確認日 2026年10月13日）。

Dify のワークフローとは

ワークフローは「入力 → いくつかの処理 → 出力」を図で組む機能です。 プロンプト1つでは足りない処理（分類してから別々に答える、資料を検索してから答える、外部 API を呼ぶ）を、ノードの組み合わせで作れます。

関連記事「AIエージェントとは｜仕組みとワークフローとの違い・作り方入門」で、決まった手順の「ワークフロー」と、手順をモデルが決める「エージェント」の違いを扱っています。

ワークフローの作り方（手順）

1. アプリを作る：スタジオで「最初から作成」を選び、種類（ワークフロー／チャットフロー）を選ぶ
2. モデルを使えるようにする：設定の「モデルプロバイダー」で、OpenAI などのプラグインを入れ、API キーを登録する
3. 開始ノードに入力を決める：ワークフローなら text などの変数を足す。チャットフローは sys.query（ユーザーの発言）が最初からある
4. ノードを足してつなぐ：ノードの右の「＋」から次のノードを選ぶ。前のノードの出力は {{#ノードID.変数名#}} で参照する
5. 出口を置く：ワークフローは出力ノード、チャットフローは回答ノード
6. 試す：右上の「実行」（チャットフローは「プレビュー」）で動かし、各ノードの入力・出力・かかった時間を確かめる
7. 公開する：「公開する」を押すと、Web アプリと API から使える。API キーは「API アクセス」で作る

変数の参照のしかた

ノード設定の入力欄では、/ を打つと変数を選べます。ソースの定義では、sys・env・conversation は決まった名前空間です（ドキュメントの画面の説明では、ユーザーの発言が userinput.query と表示される箇所があります）。

ノード一覧と使いどころ

Dify 1.17.1 のソースで決まっているノードの種類は、次のとおりです。 「DSL の type」は YAML の data.type に書く値です。

入口と出口

ドキュメントによると、出力ノードは以前「End」という名前で、今は必須ではありません。複数置くと、実行された全部の出力ノードの変数が1つにまとめられ、名前が重なると後から来た値で上書きされます。

LLM と知識

分岐とくり返し

データの加工と外部連携

ソースには、このほか RAG パイプライン用の datasource・knowledge-index と、以前の DSL を読むための variable-assigner（変数集約の以前の type）があります。

ノードの選び方の目安

作例：問い合わせの一次対応（チャットフロー）

問い合わせを3つに分け、使い方の質問はナレッジを根拠に答え、不具合は状況を聞き取り、その他は窓口を案内する bot です。

開始 ─→ 質問分類器 ─┬─ ① 使い方の質問 ─→ 知識検索 ─→ LLM（回答） ─→ 回答
                    ├─ ② 不具合の報告 ─→ LLM（聞き取り） ─→ 回答
                    └─ ③ その他       ─→ 回答（窓口の案内文）

各ノードの設定

ドキュメントでは、質問分類器のクラスの説明文は LLM が分岐を選ぶときに読む部分で、重なりそうなクラスには「〜を除く」のような境目を書くと分けやすくなる、とあります。迷う入力の扱いは「指示」欄に書きます。

LLM（回答）のシステムプロンプト

あなたは製品サポートの担当です。次の資料だけを根拠に、手順を番号付きで答えます。
資料に無いことは「担当者から折り返します」と答えます。

<資料>
{{#context#}}
</資料>

{{#context#}} は、コンテキストに知識検索の result を入れたときだけ中身が入ります。 コンテキストを設定し忘れると、資料の無いプロンプトになります。資料に無いことを答えさせない書き方は、関連記事「ハルシネーション対策のプロンプト集｜根拠と出典を求める書き方」で扱っています。

LLM（聞き取り）のシステムプロンプト

あなたは不具合受付の担当です。原因は推測で断定しません。
発生日時・操作の手順・エラーの文・使っている環境のうち、まだ聞いていないものを最大3つ質問します。

聞き取った内容を記録したいときは、変数代入ノードで会話変数に書き込むか、HTTP リクエストノードでチケットの API に送ります。

DSL（YAML）の書き方

DSL は、Dify のアプリを YAML で表したファイルです。 スタジオの「DSL をエクスポート」で書き出し、「DSL ファイルをインポート」で読み込めます。Git で管理する、別の環境へ移す、レビューする、といった用途に使えます。

上の作例の DSL

app:
  description: 問い合わせを分類し、使い方はナレッジで回答、不具合は聞き取り、その他は窓口を案内する
  icon: 🤖
  icon_background: '#FFEAD5'
  mode: advanced-chat
  name: 問い合わせ一次対応
  use_icon_as_answer_icon: false
dependencies: []
kind: app
version: 0.7.0
workflow:
  conversation_variables: []
  environment_variables: []
  features: {}
  graph:
    edges:
    - {id: start-classifier, source: start, sourceHandle: source, target: classifier, targetHandle: target}
    - {id: classifier-1-retrieval, source: classifier, sourceHandle: '1', target: retrieval, targetHandle: target}
    - {id: classifier-2-llm_bug, source: classifier, sourceHandle: '2', target: llm_bug, targetHandle: target}
    - {id: classifier-3-answer_other, source: classifier, sourceHandle: '3', target: answer_other, targetHandle: target}
    - {id: retrieval-llm_howto, source: retrieval, sourceHandle: source, target: llm_howto, targetHandle: target}
    - {id: llm_howto-answer_howto, source: llm_howto, sourceHandle: source, target: answer_howto, targetHandle: target}
    - {id: llm_bug-answer_bug, source: llm_bug, sourceHandle: source, target: answer_bug, targetHandle: target}
    nodes:
    - id: start
      type: custom
      position: {x: 80, y: 280}
      data:
        type: start
        title: 開始
        desc: ''
        variables: []
    - id: classifier
      type: custom
      position: {x: 380, y: 280}
      data:
        type: question-classifier
        title: 質問分類器
        desc: ''
        query_variable_selector: [sys, query]
        model:
          provider: langgenius/openai/openai
          name: gpt-6-luna
          mode: chat
          completion_params:
            temperature: 0
        classes:
        - id: '1'
          name: 製品の使い方・設定方法の質問
        - id: '2'
          name: 不具合・エラーの報告
        - id: '3'
          name: 料金・契約・その他
        instruction: 迷ったら「料金・契約・その他」に分類する
    - id: retrieval
      type: custom
      position: {x: 680, y: 120}
      data:
        type: knowledge-retrieval
        title: 知識検索
        desc: ''
        query_variable_selector: [sys, query]
        dataset_ids: [ここにナレッジのID]
        retrieval_mode: multiple
        multiple_retrieval_config:
          top_k: 4
          score_threshold: null
          reranking_enable: false
    - id: llm_howto
      type: custom
      position: {x: 980, y: 120}
      data:
        type: llm
        title: 回答を作る
        desc: ''
        model:
          provider: langgenius/openai/openai
          name: gpt-6-luna
          mode: chat
          completion_params:
            temperature: 0.2
        context:
          enabled: true
          variable_selector: [retrieval, result]
        prompt_template:
        - role: system
          text: |-
            あなたは製品サポートの担当です。次の資料だけを根拠に、手順を番号付きで答えます。
            資料に無いことは「担当者から折り返します」と答えます。

            <資料>
            {{#context#}}
            </資料>
        - role: user
          text: '{{#sys.query#}}'
        vision:
          enabled: false
    - id: answer_howto
      type: custom
      position: {x: 1280, y: 120}
      data:
        type: answer
        title: 回答（使い方）
        desc: ''
        answer: '{{#llm_howto.text#}}'
        variables: []
    - id: llm_bug
      type: custom
      position: {x: 680, y: 300}
      data:
        type: llm
        title: 聞き取り
        desc: ''
        model:
          provider: langgenius/openai/openai
          name: gpt-6-luna
          mode: chat
          completion_params:
            temperature: 0.2
        context:
          enabled: false
          variable_selector: []
        memory:
          window:
            enabled: true
            size: 10
          query_prompt_template: '{{#sys.query#}}'
        prompt_template:
        - role: system
          text: |-
            あなたは不具合受付の担当です。原因は推測で断定しません。
            発生日時・操作の手順・エラーの文・使っている環境のうち、まだ聞いていないものを最大3つ質問します。
        vision:
          enabled: false
    - id: answer_bug
      type: custom
      position: {x: 980, y: 300}
      data:
        type: answer
        title: 回答（不具合）
        desc: ''
        answer: '{{#llm_bug.text#}}'
        variables: []
    - id: answer_other
      type: custom
      position: {x: 680, y: 480}
      data:
        type: answer
        title: 回答（その他）
        desc: ''
        answer: 料金・契約のお問い合わせは、営業窓口（平日10時〜17時）で承ります。
        variables: []

dataset_ids は、自分の環境のナレッジの ID に置き換えます（エクスポートした DSL では、ナレッジの ID は暗号化された値で書き出されます）。モデルの provider は、モデルプロバイダーのプラグインの名前（例：langgenius/openai/openai）です。インポート先に同じプラグインが入っていないと、そのモデルは使えません。

この DSL を検証した結果

DSL の書き方の要点

質問分類器の枝は、sourceHandle にクラスの id を書きます。 ソースでも、分類の結果のクラスの id を、次に進むエッジの sourceHandle として使っていました。

版が違う DSL を読み込んだときの扱い

インポート時の判定は check_version_compatibility() で次のとおりでした（今の版は 0.7.0）。

Dify のテストに入っている DSL の見本は version: 0.3.1 のものが20件ありました。以前の版で書き出した DSL も、警告つきで読み込まれる扱いです。YAML の書き方そのものは、関連記事「Python設定ファイルの読み込み｜ini・TOML・YAML・JSON比較」でも扱っています。

API から呼ぶ

公開したアプリは、アプリごとの API キー（app- で始まる）で呼びます。 キーはアプリの「API アクセス」で作り、Authorization: Bearer app-... ヘッダで送ります。セルフホストでは、nginx が /v1 を API のコンテナ（api:5001）へ渡す設定でした。

Python のコード（requests）

import json, os
import requests

BASE_URL = os.environ.get("DIFY_BASE_URL", "http://localhost/v1")   # API アクセス画面の URL
API_KEY = os.environ["DIFY_API_KEY"]                               # app-...
HEADERS = {"Authorization": f"Bearer {API_KEY}"}


def chat(query: str, user: str, conversation_id: str = "", inputs: dict | None = None) -> dict:
    """チャットフローに1回聞く（blocking）"""
    r = requests.post(
        f"{BASE_URL}/chat-messages",
        headers=HEADERS,
        json={
            "inputs": inputs or {},
            "query": query,
            "response_mode": "blocking",
            "conversation_id": conversation_id,   # 空なら新しい会話
            "user": user,                         # 必須。利用者を区別する文字列
        },
        timeout=120,
    )
    r.raise_for_status()
    return r.json()


def chat_stream(query: str, user: str, conversation_id: str = ""):
    """チャットフローに聞き、SSE を1イベントずつ返す（streaming）"""
    with requests.post(
        f"{BASE_URL}/chat-messages",
        headers=HEADERS,
        json={"inputs": {}, "query": query, "response_mode": "streaming",
              "conversation_id": conversation_id, "user": user},
        stream=True,
        timeout=(10, 300),
    ) as r:
        r.raise_for_status()
        for raw in r.iter_lines():                 # bytes で受ける
            line = raw.decode("utf-8")             # charset が無くても UTF-8 で読む
            if line.startswith("data: "):
                yield json.loads(line[len("data: "):])


def run_workflow(inputs: dict, user: str) -> dict:
    """ワークフローを実行する（blocking）"""
    r = requests.post(
        f"{BASE_URL}/workflows/run",
        headers=HEADERS,
        json={"inputs": inputs, "response_mode": "blocking", "user": user},
        timeout=120,
    )
    r.raise_for_status()
    return r.json()


if __name__ == "__main__":
    res = chat("パスワードの変え方は？", user="user-001")
    print(res["answer"], res["conversation_id"])

    answer = ""
    for ev in chat_stream("パスワードの変え方は？", user="user-001",
                          conversation_id=res["conversation_id"]):
        if ev["event"] == "message":
            answer += ev["answer"]
        elif ev["event"] == "message_end":
            print("usage:", ev["metadata"].get("usage"))
        elif ev["event"] == "error":
            raise RuntimeError(ev.get("message"))
    print(answer)

    wf = run_workflow({"text": "VPNにつながりません"}, user="user-001")
    print(wf["data"]["status"], wf["data"]["outputs"])

擬似サーバーで受けた、送られた中身です。

POST /v1/chat-messages
Authorization: Bearer app-test123
Content-Type: application/json
{"inputs": {}, "query": "パスワードの変え方は？", "response_mode": "blocking", "conversation_id": "", "user": "user-001"}

POST /v1/chat-messages
{"inputs": {}, "query": "パスワードの変え方は？", "response_mode": "streaming", "conversation_id": "8f0c6d2e-1b7a-4c1e-9a55-3f2b1d0e4c11", "user": "user-001"}

POST /v1/workflows/run
{"inputs": {"text": "VPNにつながりません"}, "response_mode": "blocking", "user": "user-001"}

SSE を iter_lines(decode_unicode=True) で読むと、文字化けすることがあります。 擬似サーバーが Content-Type: text/event-stream だけを返したとき（charset なし）、requests は ISO-8859-1 として読み、日本語が 1. 設å®... のように化けました。上のコードのように bytes で受けて decode("utf-8") すると、正しく読めました。

リクエストの項目（ソースの定義）

blocking の応答（チャットフロー）は、event・task_id・id・message_id・conversation_id・mode・answer・metadata・created_at を持つ JSON です。ワークフローの blocking の応答は、task_id・workflow_run_id と、data（status・outputs・error・elapsed_time・total_tokens・total_steps など）です。OpenAPI の定義には「Dify Cloud ではタイムアウトまでに返らないと接続が切れることがある」との注意があり、streaming が推奨とされています。

SSE のイベントの種類（ソースの StreamEvent）

SSE は data: {JSON} の行と空行のくり返しで、接続を保つための event: ping も届きます（ソースの convert_to_event_stream）。

チャットフローの回答は message、ワークフローの出力は text_chunk で届きます。 ワークフローの最終結果は workflow_finished の data.outputs で受け取ります。ストリームの読み方は、関連記事「Pythonのrequestsの使い方｜タイムアウト・エラー処理・再試行まで」でも扱っています。

エラーの応答（chat-messages のドキュメント文字列）

認証のヘッダが Bearer で始まらないと、Authorization header must be provided and start with 'Bearer' になります（ソースの wraps.py）。429 への備えは、関連記事「LLM APIの429・529エラー対処｜リトライ実装とエラー一覧」で扱っています。キーの置き場所は、関連記事「.envの使い方と注意点｜APIキーを安全に管理する方法」で扱っています。

Docker Compose で自分のサーバーに立てる

セルフホスト版は、リポジトリの docker/ にある docker-compose.yaml で起動します。

必要なスペック（ドキュメント）

起動の手順

git clone --branch 1.17.1 https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
docker compose ps        # init_permissions が Exited なのは正常

ブラウザで http://サーバーのIP/install を開き、管理者のアカウントを作ります。2回目からは / でログインします。.env.example では SECRET_KEY が空で、コメントに「空なら、ストレージのディレクトリに永続のキーを自動で作る」とありました。

起動するコンテナ（1.17.1 の docker-compose.yaml）

.env.example の COMPOSE_PROFILES は ${VECTOR_STORE:-weaviate},${DB_TYPE:-postgresql},collaboration で、ベクトル DB と DB の種類に合わせて起動するコンテナが変わります。Compose の基本は、関連記事「Docker Composeの使い方｜compose.yamlの書き方と開発環境の作り方」で扱っています。ベクトル DB を PostgreSQL にまとめたいときは、関連記事「pgvectorの使い方｜PostgreSQLでベクトル検索をコピペで構築」も参考になります。

1.17.1 で変わった点（リリースノート）

• 同梱の Weaviate を使うセルフホストでは、1.17.1 を起動する前に Weaviate を 1.27.0 から 1.39.2 へ段階的に上げる手順が必要
• 1.17.0 で、タイムアウトの既定が 1200 秒から 3600 秒に延びた
• 1.17.0 で、環境変数 EDITION が DEPLOYMENT_EDITION に変わり、ENTERPRISE_ENABLED は無くなった

アップグレードの前に、新しい .env.example と自分の .env を比べます（ドキュメントの案内）。

設計の前に知っておく上限値（1.17.1 の既定値）

値は docker/envs/core-services/ の *.env.example にあります。コードノードで31件以上の文字列の配列を返すと上限に当たります。 件数の多いデータは、JSON の文字列にして返すか、上限を上げます。ドキュメントでは、コードノードのサンドボックスはファイルやシステムコマンドを使えず、外への通信は SSRF プロキシ経由とされています。

よくある質問

Q. ワークフローとチャットフローは、あとで変えられますか。 A. DSL の mode が違い、置けるノード（出力と回答）も違います。作り直すつもりで選びます。会話の記憶が要るならチャットフローです。

Q. Dify Cloud とセルフホストの違いは？ A. Cloud はサーバーの用意が要らず、セルフホストは自社のネットワークにデータを置けます。セルフホストでは、上の上限値を .env で変えられます。

Q. ローカル LLM を使えますか。 A. モデルプロバイダーのプラグインに Ollama などがあります。Ollama 自体は関連記事「Ollamaの使い方｜ローカルLLMのコマンド一覧とAPIの呼び方」で扱っています。Docker の中の Dify から、ホストの Ollama へは localhost ではつながらない点に注意します。

Q. LangChain との使い分けは？ A. Dify は画面で組み、そのまま Web アプリと API になります。LangChain は Python のコードで組みます。画面で業務の人と一緒に直したいなら Dify、細かい制御やテストをコードで持ちたいなら LangChain、という分け方ができます。LangChain は関連記事「LangChain入門｜PythonでLLMアプリを作る基本とコピペ集」で扱っています。

Q. ナレッジの精度が上がりません。 A. 文書の分け方・Top K・スコアのしきい値・リランクで変わります。考え方は関連記事「RAGの精度改善の方法一覧｜原因の切り分けと評価指標の計算」で扱っています。

まとめ

• 1回で終わる処理は ワークフロー（workflow・出力ノード）、会話は チャットフロー（advanced-chat・回答ノード）
• 前のノードの値は {{#ノードID.変数名#}}、ユーザーの発言は {{#sys.query#}}
• 分類は 質問分類器（LLM）か 条件分岐（ルール）。分岐を戻すのは 変数集約
• DSL は version: 0.7.0（1.17.1）。質問分類器の枝は sourceHandle にクラスの id
• API は /v1/chat-messages（query・user 必須） と /v1/workflows/run。SSE は bytes で受けて UTF-8 で読む
• セルフホストは 2コア・4GiB 以上、cp .env.example .env → docker compose up -d → /install
• 上限（500 ステップ・コードの配列 30 件・コード 15 秒など）を設計の前に確かめる

参考・出典

確認日はいずれも 2026年10月13日です。

• GitHub「langgenius/dify」Releases：https://github.com/langgenius/dify/releases
• GitHub「langgenius/dify」1.17.1 のソース：https://github.com/langgenius/dify/tree/1.17.1
• Dify ドキュメント「Deploy with Docker Compose」：https://docs.dify.ai/en/self-host/quick-start/docker-compose
• Dify ドキュメント「Environment Variables」：https://docs.dify.ai/en/self-host/deploy/configuration/environments
• Dify ドキュメント「LLM」：https://docs.dify.ai/en/use-dify/nodes/llm
• Dify ドキュメント「Question Classifier」：https://docs.dify.ai/en/self-host/use-dify/nodes/question-classifier
• Dify ドキュメント「Knowledge Retrieval」：https://docs.dify.ai/en/self-host/use-dify/nodes/knowledge-retrieval
• Dify ドキュメント「Output」：https://docs.dify.ai/en/self-host/use-dify/nodes/output
• Dify ドキュメント「Code」：https://docs.dify.ai/en/self-host/use-dify/nodes/code
• Dify API リファレンス（OpenAPI）：https://docs.dify.ai/en/api-reference/openapi_service.json
• PyPI「graphon」：https://pypi.org/project/graphon/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。