Difyのアプリ種類を選ぶ：Workflow・Chatflow・Agent

まず「会話の続き」と「AIに任せる判断」を分ける

Difyのアプリを選ぶときは、最初に「前のやり取りを踏まえて会話を続けるか」を考えます。

一度の入力やイベントから処理を進めるならWorkflow、複数ターンの会話を設計するならChatflowが第一候補です。

そのうえで、使うツールや次の行動をAIに選ばせる必要がある工程にAgentを検討します。

Workflow、Chatflow、Agentを、機能が少ない順に並ぶ三段階と考える必要はありません。

この記事は、Difyを使い始める前にアプリの種類を決めたい人向けの比較・参照ガイドです。

読後には、作りたい仕事を一つ選び、候補、選んだ理由、実装前に確認する条件を選択シートに残せます。

ここで完成させるのは設計上の判断です。

アカウント作成、モデル接続、アプリの実行は次の工程として扱います。

2026年10月27日に公式資料を確認しました。

読者のCloudプラン、自己運用のバージョン、権限、モデル、プラグインは未指定です。

以下の業務例は架空の「みなと学習室」を使う紙上演習で、Difyを操作して得た実行結果や測定値ではありません。

新Agentは公式資料でベータ版として案内されており、提供環境を確認してから候補にします。

まず、言葉の単位をそろえましょう。

「アプリ」は利用者が使う処理や会話のまとまり、「ノード」はフローに置く一つの工程です。

Agentという名前にはアプリとノードの両方があるため、単に「Agentを選ぶ」と書くだけでは構成が決まりません。

公式の主要概念は、WorkflowとChatflowを主要なフロー型アプリとして説明し、Chatbot、Agent、Text Generatorという基本アプリも挙げています。

この記事の三つの名前が、画面に存在するすべての選択肢という意味ではありません。

単純な会話や文章生成なら、ChatbotやText Generatorも比較対象になります。

Workflowは「一回の処理」を組み立てる

Workflowは、一度の開始から必要な工程をつないで処理する構成の第一候補です。

たとえば、授業メモを受け取り、要点を整理し、所定の形式の報告書を返す仕事が当てはまります。

どの工程を通るかを、ノード、分岐、反復などで設計します。

「一回の処理」は「LLMを一回だけ呼ぶ」という意味ではありません。

LLMは文章を理解・生成する言語モデルのことです。

一つのWorkflowに複数のLLMノードを置いたり、対象ごとの繰り返しを設けたりできます。

また、人の入力を待って一時停止する構成もあります。

モデルの出力が毎回同じになることや、開始後に中断せず終了することを保証する呼び方でもありません。

基本はWorkflowとChatflowの説明で確認できます。

開始方法は、手動・APIとイベントを分ける

利用者がフォームに入力する、または外部プログラムが必要なときに呼ぶ構成ではUser Inputを使います。

定期実行、Webhook、対応する外部サービスのイベントを起点にする構成ではTriggerを検討します。

Webhookは、外部サービスから届くHTTP通知を処理開始のきっかけにする仕組みです。

現行の開始ノードの説明では、User InputとTriggerは同じキャンバス上で併用しません。

「毎朝動かし、同じアプリを手入力のWeb画面としても使う」という要件なら、入口を分ける設計を先に検討してください。

Webアプリ、バックエンドのService API、MCP公開、Workflowをツールとして呼ぶ経路は、User Inputで始まるWorkflowを前提に確認します。

Triggerで始めたWorkflowにも同じ公開方法をそのまま当てはめないことが大切です。

Triggerの公式資料には、Schedule、Webhook、プラグインが提供するイベントが説明されています。

外部サービスの名前を書くだけで連携が完成するわけではなく、対応する連携、認証、公開時の有効化、利用プランのイベント枠などが条件になります。

呼び出し元へ値を返すならOutputを設計する

現在のOutputノードは、以前のEndノードに当たります。

Output自体は必須ではありませんが、呼び出し元が結果の値を必要とするなら、何を返すかを明示的に設計します。

Outputがない経路では、処理を行っても呼び出し元へデータを返しません。

また、Outputは「他のすべての工程を直ちに止めるスイッチ」ではありません。

並列の経路が動いている場合も考慮します。

古い説明のEndという名前と、現在のOutputの動作を混ぜず、「開始できた」「処理が進んだ」「必要な値を返した」を別々に確かめると、原因を絞りやすくなります。

Chatflowは「同じ会話の続き」を設計する

Chatflowは、一つの会話の中で質問と応答を重ねる用途の第一候補です。

みなと学習室で「平日の夜に受けたい」「その中で初級向けはある？」という相談を受けるなら、二つ目の質問を前の条件に結び付けたいでしょう。

この会話の継続が必要かどうかが、単発の問い合わせ処理との違いになります。

ChatflowはUser Inputで始まり、利用者のメッセージごとに設計したフローが動きます。

応答を返すためのAnswerノードが必要で、回答を段階的に返す構成もできます。

Answerの資料にはWorkflow側の古いEndという呼称も残っているため、Workflowの出力仕様は前節のOutput資料を優先して読みます。

会話変数とLLMのMemoryは役割が違う

「前のことを覚えている」を、少なくとも二つに分けましょう。

会話変数は、希望の曜日やコースなど、設計した値を同じ会話の中で保持するために使います。

通常の実行中の変数と違い、次のターンでも値を参照でき、Variable Assignerで更新します。

別の利用者や別の会話へ自動で共有する仕組みではありません。

LLMノードのMemoryは、そのノードで有効にした会話履歴をモデルへの入力に含める設定です。

LLMノードの公式資料に沿って、どのノードで履歴を使うかを確認します。

Chatflowを選んだだけで、すべてのLLMが必要な過去情報を無制限に参照する、と考えないようにしてください。

たとえば希望の曜日を会話変数に保存しても、その値を回答生成へ渡さなければ、期待した絞り込みにはつながりません。

反対に、会話履歴だけに頼ると、設計上必ず持っておきたい値が明確にならないことがあります。

「保持する値」「更新する工程」「回答で参照する場所」を別々に書くと確認しやすくなります。

現在のUser Input資料では、Chatflowの最新メッセージを参照する変数としてuserinput.queryが説明されています。

これはAPIで送るフィールド名や、古い画面の変数名と同一視せず、実際の編集画面で選びます。

変数を手入力で推測するより、User Inputの資料と画面の変数選択を照合する方が確実です。

資料検索が必要でも、直ちにAgentにはならない

手元の資料を検索して回答の根拠に使う方法をRAGと呼びます。

たとえば、講座案内を検索して該当部分をLLMへ渡すだけなら、ChatflowやWorkflowにKnowledge Retrievalノードを組み込む構成を検討できます。

Knowledge Retrievalは両方のフローで利用する説明になっています。

必要なのが「決めた資料を検索し、見つかった内容から答える」ことなのか、「検索方法や使う道具も状況に応じてAIが選ぶ」ことなのかを分けましょう。

前者なら、検索、回答、根拠が見つからない場合の応答を明示した構成から始められます。

検索結果が適切かと、回答がその根拠に沿っているかは別の確認項目です。

Agentは「何を任せるか」と「どの種類か」を具体化する

Agentを検討する理由は、外部サービスを使うことだけではありません。

WorkflowやChatflowでも、ToolsやHTTP Requestを使って外部とやり取りできます。

行う呼び出しと順番があらかじめ決まっているなら、その工程を設計すればよい場合があります。

ToolsとHTTP Requestの資料は、その判断の手掛かりになります。

Agentが候補になるのは、与えた目的や途中の結果に応じて、どのツールを使うか、次に何をするかをモデルへ委ねたい場面です。

ただし、実際にできることはモデル、戦略、ツール、認証、権限に依存します。

反復が増えると時間や費用が増える可能性もあるため、Agentなら必ず速い、安い、正確、と順位を付けることはできません。

Legacy Agentの資料とAgentノードの資料は分けて確認します。

Classic Agent nodeは、選んだ戦略に沿ってモデルがツールを選びながら処理するノードです。

ある部分にAgent nodeを置いても、アプリ全体をWorkflowやChatflowとして設計することはできます。

新Agentの概要では、能力の設定と各実行のタスクを分け、単独で使う方法とフロー内で使う方法を説明しています。

サンドボックス内でコマンドを実行し、ファイルを扱う経路もあるため、行動範囲を「追加したDify Toolsだけ」と考えないようにします。

誰に利用を許すか、どのデータを渡すか、どの隔離が必要かも選択条件です。

新Agentの適用範囲は環境を区別する必要があります。

確認したCloudのAgentノード資料では、New Agent nodeはベータ版でWorkflow向けと説明されています。

一方、2026年10月26日更新の自己運用向けBuild資料は、Chatflow利用に追加設定が必要で、該当フラグは既定で無効としています。

そのため「新Agentノードはどの環境でもChatflowで使えない」「どの環境でも最初から使える」のどちらも一般化しません。

本稿の基本例はCloud資料に沿うWorkflow内の利用とし、自己運用では版と設定を別途確認します。フラグの変更手順はここでは扱いません。

用途別の選択フローを一枚にする

次の順番で、まず候補を一つ書きます。

これは編集上の判断手順であり、Dify公式の適性診断や実測順位ではありません。

後半で独立したAgentが適切だと分かったら、最初の候補を見直して構いません。

最後の照合を省くと、見た目は似ていても再利用の条件が合わないことがあります。

たとえば、別のAgentから呼ぶWorkflow toolにしたいなら、User Inputで始まるWorkflowが対象です。

ChatflowはそのままWorkflow toolにはできません。

会話型アプリの中で使う共通処理を、別のWorkflowとして分ける設計が必要になる場合があります。

また、Web画面とAPIの会話を同じ利用者IDで自動的に共有できる、と仮定しないでください。

公式資料は両者の会話履歴を区別しています。

どの入口で、どの会話の続きとして使うかまで書くと、Chatflowが必要な理由が具体的になります。

六つの業務例で候補と条件を比べる

すべて同じ架空の学習室を題材にし、機能の優劣ではなく要件の違いを比較します。

期待する選択は設計例であり、実行して確認した最適解ではありません。

SEL-01は、追加の質問が本当に不要かを確かめます。

入力不足なら必ず利用者へ聞き返す要件が加わると、Chatflowを候補に戻す理由になります。

一方、単にファイルや文章を入力できるというだけでは、Chatflowにする必然性はありません。

SEL-02では、二回目の「その中で初級向けは？」を解釈できることが設計上の期待です。

ただし、会話変数に保存した曜日を回答に使う工程と、別の会話へ持ち越さないことの確認が必要です。

資料から答えるだけなら、最初からAgentを加える理由にはしません。

SEL-03の下書き作成と、メールやチャットへの配信は別の要件です。

この演習は下書きまでとし、送信先も送信権限も設定しません。

将来配信を追加する場合は、そのツール、宛先、認証、失敗時の扱いを別途設計します。Triggerがあるだけで必要な外部サービスとの接続が完了するわけではありません。

SEL-04で任せるのは、許可した検索手段からの選択です。

まず参照だけで済む範囲を設計し、存在しないツールや未設定の認証で成功したことにはしません。

どのツールを選んだか、使えないときにどう返すか、反復の上限と終了条件は実装時の確認項目になります。

SEL-05は「ファイルを受け取るなら必ず新Agent」という意味ではありません。

毎回同じ表を同じ規則で集計するなど、手順が決まっているなら通常のWorkflowを再検討できます。

新Agentを候補にする理由は、必要な作業の選択を委ねたいことです。

ベータ提供、モデル、実行環境、権限を確認できるまでは採用決定にしません。

SEL-06では、Human Inputが処理を止め、人の入力を待って再開する仕組みであることを押さえます。

これは会話履歴を保持する機能とは別です。

公式APIガイドではWorkflowとChatflowの両方の一時停止と再開が説明されています。

人が関わるだけで、必ずChatflowに変える必要はありません。

ただし、Triggerで始まるWorkflowではHuman InputのWebアプリ配信は使えないため、配信経路を別途確認します。

承認フォームへ回答できることと、業務上の承認者本人と確認できることも分けます。

メールのリンクを知る人が回答できる方式なら、その配送だけで本人確認を満たすと考えないようにしてください。

また、確認した新Agentの自己運用向けBuild資料では、Human Inputを含むWorkflowをAgentのツールとして使えません。

SEL-06をAgentの道具へまとめればよいと決めず、人の確認をフロー側に置く構成を検討します。

紙上演習：要件から選択記録を作る

ここではSEL-02を使います。

Difyへ投入するプロンプトや設定ファイルではなく、構成を考えるための要件メモです。

実在の顧客情報、APIキー、認証情報は不要です。

演習ID: LEARN-010
組織: みなと学習室（架空）
仕事: 希望曜日を聞き、講座案内から候補を示す
入力例1: 平日の夜に受けたい
入力例2: その中で初級向けはある？
期待する成果: 同じ会話の希望を踏まえ、資料に沿って候補を返す
今回は行わない処理: 申込確定、決済、メール送信

まず、会話の継続が必要かを判定します。

二つ目の入力は前の希望を参照するため、Chatflowを第一候補にします。

次に、情報を得る方法を考えます。

検索先が講座案内に決まっているなら、Knowledge Retrievalと回答生成を組む案から始められます。

ツールをモデルに選ばせる要件は、まだありません。

続いて、保持する値と回答に渡す情報を決めます。

希望曜日などは会話変数の候補、過去の発言は必要なLLMノードでMemoryを設定する候補です。

どちらも設定しただけで成功とせず、回答で使う場所まで設計します。

最後に、根拠が見つからない質問を用意し、案内できないことを伝える方針を残します。

選択記録: SEL-02
第一候補: Chatflow / User Input
理由: 同じ会話の前の希望を使って候補を絞りたい
Agentを追加する条件: 検索先や次の行動をAIへ選ばせる要件が加わる場合
保持する値の候補: 希望曜日、希望時間帯、習熟度
回答に使う情報: 今回の質問、必要な履歴・会話変数、検索した講座案内
出力の設計: Answerで候補と根拠を返す。根拠がなければ不足を伝える
実装前の確認: 提供機能、モデル、資料、変数更新、Memory、別会話との分離
状態: 紙上の設計案。アプリ実行は未実施

演習の完成条件は、選択名だけでなく理由と未確認事項が埋まることです。

例と違う候補になっても、入力条件や成功条件を変えた理由が説明できれば再検討できます。

選択シートには、実際の実行結果を書く欄を別に用意し、紙上の期待と混ぜずに残してください。

選び直しにつながる失敗と、実装前の確認

種類の選択が適切でも、ノード設定や権限が不足すれば期待どおりには動きません。

逆に、設定ミスをアプリ種類の問題だと決めつけると、作り直しても同じ箇所で止まります。

次の表を、切り分けの出発点として使えます。

実装に進むときは、通常入力、情報不足、根拠なし、外部ツールの失敗、必要な出力がない分岐など、候補に関係するケースを選んで確認します。

Chatflowなら同じ会話の続きと、新しい会話での状態を分けます。

Agentなら、許可したツールをどう選ぶかと、完了できない場合にどう終えるかを確認します。

人の確認を含むなら、承認、却下、期限切れも別々に扱います。

費用や所要時間の比較は、同じ入力、モデル、ツール条件をそろえてから行います。

この記事では実測していないため、方式ごとの価格や速度の順位は付けません。

公式料金ページで現在の利用枠を確認し、モデル提供元や外部サービスの条件も照合してください。

Cloudの資料確認日を、読者環境の実機検証日として記録しないことも大切です。

選択記録を持って、最小の構成へ進む

最初の候補がWorkflowなら、User Inputから必要な出力へ至る小さな処理を一つ作るのが次の学習です。

Chatflowなら、二回の入力で前の希望を使い、新しい会話では持ち越さないという確認対象を決めます。

Agentなら、委ねる判断と利用可能な道具を一つずつ具体化し、通常のフローで設計する部分との境界を先に書きます。

まだDifyの用途自体が曖昧なら、業務の入力と出力を整理する基礎へ戻りましょう。

作りたいものが決まったら、作業環境の準備、モデル接続、最小Workflow、Agentの使い分けの順に必要な項目を学べます。

新Agentの詳しい構築やSkillsは、ベータ提供と対象環境を確認したうえで別の実習として進めます。

今回の選択シートには、採用候補、選んだ理由、再検討する条件、公開前に確かめる項目を残してください。

公式資料や画面が更新された際は、名前だけ置き換えるのではなく、開始方法、出力、会話の状態、Agentの提供条件が変わっていないかを見直すと、判断を更新できます。