Difyで新規アプリを作るとき、公式が第一推奨としているのは Workflow と Chatflow の2つだ。
名前が似ているうえ、どちらもノードを並べて処理を組むため、「どっちを選べばよいか」で止まりやすい。
この記事では、公式ドキュメント（docs.dify.ai の Key Concepts）を根拠に、違いと使い分けを初心者向けに整理する。
結論：1問で決める
ユーザーと複数回やり取りするか？
| 質問への答え | 選ぶタイプ | イメージ |
|---|---|---|
| いいえ（入力→結果で終わり） | Workflow | レポート生成、分類、バッチ変換 |
| はい（聞き返し・確認・続きの質問がある） | Chatflow | ガイド付きFAQ、段階的ヒアリング |
| 観点 | Workflow | Chatflow |
|---|---|---|
| ターン | シングルターン（1回実行で完結） | マルチターン（会話の各発言でフローが起動） |
| 開始 | User Input または Trigger | 常に User Input |
| 終了のイメージ | Output で結果を返す | Answer などで会話に返答する |
| 会話の文脈 | 持たない（実行ごとに独立） |
sys.conversation_id などで同一会話を束ねる |
| 会話変数 | なし | あり（Variable Assigner で更新可） |
| LLMメモリ | 会話前提ではない | LLMノードで Memory を有効化できる |
| 向きやすい公開形態 | Web／APIでの単発・バッチ実行 | チャットUIでの対話 |
迷ったら「会話が続くなら Chatflow、続かないなら Workflow」でよい。
全体像：同じエンジン、違う起動の仕方
公式の Key Concepts では、次のように整理されている。
- Workflow … 単発タスク向け。Webアプリや API から、まとめて多数のタスクを実行しやすい。
- Chatflow … 会話のターンごとに起動される特別な Workflow。Workflow の機能に加え、会話固有の変数・LLMメモリ・途中でのストリーミング出力などが使える。
裏側は同じワークフローエンジンだ。違いは「1回きりの実行か」「会話レイヤー付きか」にある。
Workflow:
[入力 or Trigger] → ノード列 → [Output] ※ここで終了
Chatflow:
[User Input] → ノード列 → [Answer 等]
↑__________________________| ※次の発言でまた先頭から起動
（同一 conversation_id の会話が続く）
Workflow：決まった手順を1回で回す
Workflow は、入力を受けて一連のノードを実行し、結果を返すアプリだ。
会話の文脈を持ち越さない。毎回同じ手順・同じ検証を再現したいときに向く。
向く例:
- 文書の要約・分類・フォーマット変換
- 複数ステップのレポート生成
- API から「実行して結果だけ欲しい」処理
- スケジュールや外部イベントで自動起動したい処理（Trigger）
開始ノードは次のどちらか。
- User Input … ユーザーや API が都度起動する
- Trigger … スケジュールや外部イベントで自動起動する
「対話は不要で、パイプラインとして動かしたい」なら Workflow を選ぶ。
Chatflow：会話のたびに同じ設計図を回す
Chatflow は、チャットの各メッセージがフローを起動するアプリだ。
開始は常に User Input。ユーザーが聞き返すたびに、設計したノード列が再度走る。
Workflow に加えて、特に次が効く。
- 会話変数（Conversation Variable） … 複数ターンにまたがって値を保持・更新できる（Variable Assigner で更新）
- LLMノードの Memory … 直前までのやりとりを踏まえた応答に使える
- 途中出力のストリーミング … テキスト・画像・ファイルを実行の途中で返せる
-
システム変数 …
sys.conversation_id（同一会話の束ね）、sys.dialogue_count（何ターン目か）など
向く例:
- 社内FAQのように、足りない条件を聞き返してから案内する
- 申し込みや障害切り分けのように、段階的に情報を集める
- 「前の発言を覚えていてほしい」対話アシスト
「チャット画面で進めたいが、分岐や外部APIもノードで明示したい」なら Chatflow が適する。
変数の差：初心者がつまずきやすいポイント
どちらにも入力変数・ノード出力・環境変数がある。差が出るのは主に次だ。
| 変数 | Workflow | Chatflow |
|---|---|---|
| 入力変数（User Input） | あり（実行開始時に固定） | あり（各ターン開始時） |
| 環境変数 | あり（APIキー等。DSL共有時に秘密を分離） | あり |
sys.conversation_id / sys.dialogue_count
|
なし（会話前提ではない） | あり |
| 会話変数 | なし | あり（会話中に更新可能） |
ポイントは次の2つ。
- 入力変数は実行開始時に決まり、途中では更新できない（公式の説明どおり）。会話中に状態を変えたいなら Chatflow の会話変数を使う。
- 環境変数は秘密情報向け。DSL を共有するときにキーを本文に埋め込まないための仕組みだ。
使い分けフローチャート
Q1. ユーザーと複数回やり取りする？
Yes → Chatflow
No → Q2へ
Q2. 決まった手順・分岐・検証をノードで明示したい？
Yes → Workflow
No → そもそも簡易タイプ（Chatbot / Text Generator 等）も検討
Q3. スケジュールや外部イベントで自動起動したい？
Yes → Workflow（Trigger）
No → Q1の答えに従う
補足（公開情報ベースの実務メモ）:
- ツールとして他アプリから呼び出す Workflow-as-Tool は、公式上 Workflow アプリのみが対象（Chatflowは非対応）。「部品として再利用する処理」は Workflow 側に置くのが安全。
- Human Input（人が途中で入力して再開）は Chatflow / Workflow の両方で扱える系統がある。対話UIが主なら Chatflow、単発パイプライン内の承認待ちなら Workflow、と用途で分ける。
具体シナリオで選ぶ
| やりたいこと | 推奨 | 理由 |
|---|---|---|
| CSVを受け取り、要約レポートを返すAPI | Workflow | 単発・会話不要 |
| 毎朝の定時でニュース要約を生成 | Workflow + Trigger | 自動起動が自然 |
| 「商品AとBどっち？」と聞き返すFAQ | Chatflow | 複数ターンと会話変数が必要 |
| 障害切り分けで症状を順番に聞く | Chatflow |
dialogue_count や会話変数で段階管理しやすい |
| 1回のプロンプトでメール文面を生成 | Workflow（または Text Generator） | 対話レイヤーが過剰 |
実装チェックリスト
- 「会話が続くか／1回で終わるか」を1文で書いてからアプリタイプを選ぶ
- Workflow なら開始が User Input か Trigger かを決める
- Chatflow なら、ターンをまたぐ状態を会話変数にする項目を列挙する
- 秘密情報は環境変数に置き、DSLや画面キャプチャにキーを載せない
- 他フローから部品として呼びたい処理は Workflow 側に分離する（Workflow-as-Tool）
- プレビューで「2ターン目に前の回答を覚えているか／単発で再現するか」を確認する
失敗パターン
パターン1：とりあえず Chatflow にして、バッチ実行で苦しむ
→ 対策：APIや定時実行が主用途なら Workflow。会話UIが要らなければ Chatflow を選ばない。
パターン2：Workflow で「前の発言を覚えて」と期待する
→ 対策：会話文脈が必要なら Chatflow。単発なら、必要な情報を毎回入力変数で渡す設計にする。
パターン3：状態をプロンプトの長文に全部押し込む
→ 対策：Chatflow なら会話変数と sys.dialogue_count で段階管理する。プロンプト肥大は再現性とコストを悪化させる。
パターン4：Chatflow をツール化しようとして詰まる
→ 対策：再利用したい処理は Workflow として切り出し、Workflow-as-Tool で呼ぶ。
まとめ
- Dify の推奨2タイプは Workflow（単発） と Chatflow（会話の各ターンで起動する Workflow）。
- 選び方の軸は「ユーザーと複数回やり取りするか」が最短。
- Chatflow 固有の強みは会話変数・LLMメモリ・会話系システム変数。
- 自動起動や部品化（Workflow-as-Tool）は Workflow 側の話として切り分けると混乱が減る。
次の一歩としては、同じ題材（例: FAQの1問）を Workflow と Chatflow の両方で小さく作り、2ターン目の挙動差を体感すると理解が定着する。
参考リンク
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。