Difyワークフローの作り方と使い方｜ノード選定・ループ・トリガーを実装手順で解説【2026年版】

Difyのワークフローは、LLMの呼び出しと条件分岐・外部API連携をキャンバス上でつないで、業務処理を1本の実行フローにまとめる機能です。日本語の解説記事の多くは「開始ノードを置いてLLMをつなぐ」までで止まっていますが、2025年11月公開のv1.10.0でトリガーが加わり、ワークフローは「人が押して動かすもの」から「イベントで勝手に動き続けるもの」へ変わりました。この記事では作成手順の6ステップに加えて、ノードの選定基準、イテレーションとループの使い分け、トリガーによる常時稼働、承認を挟むHuman Inputまでを、公式ドキュメントとv1.16.1のソースで確認できた実値で整理します。

まとめ

Difyワークフローを実務で動かすうえで押さえるべき要点は、次の5点に集約されます。

• アプリタイプの選択が最初の分岐点：1回の入力で結果を返すならワークフロー、会話を続けるならチャットフロー。トリガーによる自動実行はワークフローだけの機能です。
• 作成は6ステップ：アプリ作成 → 開始ノードの入力定義 → ノード追加と接続 → 変数の受け渡し設定 → テスト実行とデバッグ → 公開。ユーザー入力起点であれば、公開後はWebアプリ・API・埋め込み・MCPサーバーの4形態で同時に使えます。
• 反復処理は2種類を使い分ける：要素が互いに独立するならイテレーション（並列は最大10）、前回の出力を次の入力に渡して精度を上げるならループ（既定の最大回数は10）。
• トリガーはv1.10.0以降の機能：スケジュール・Webhook・インテグレーションの3種。スケジュールトリガーは1ワークフローに1つだけで、cronは分・時・日・月・曜日の5フィールドです。
• 上限値を設計前に確認する：1実行あたり500ステップ・1,200秒、1つの実行経路に置けるノードは50、ループの最大回数は100までです。

以下、それぞれをノードの設定画面レベルまで落として説明します。

ワークフローとチャットフローの使い分け基準

Difyでキャンバスを使うアプリタイプは2つあります。公式ドキュメントはワークフローを「入力を受け取り、フローで処理し、結果を返す」一度きりの実行、チャットフローを「ユーザーがチャット画面で対話し、メッセージのたびに設計したフローが走ってから応答が生成される」ものと定義しています。判断に迷ったら、出力が1回で完結するかどうかで決めてください。

両者はノードの種類がほぼ共通で、違いは起点と終端、そして会話履歴の有無です。社内向けの質問応答ボットならチャットフロー側が適しており、構築手順は最近話題の「Dify」で社内チャットボットを作成しよう！概要と魅力で扱っています。逆に「毎朝9時に前日の売上を集計してSlackへ流す」処理はチャットフローでは組めません。トリガーがワークフロー専用だからです。

ワークフロー作成の6ステップ

ここからは実際の作成手順です。Difyクラウド版でもセルフホスト版でも画面構成は同じです。

アプリ作成と開始ノードの入力フィールド定義

スタジオ画面で「最初から作成」を選び、アプリタイプで「ワークフロー」を指定します。作成直後のキャンバスには開始ノードだけが置かれた状態になります。まずこの開始ノードに、実行時に受け取る入力フィールドを定義してください。短文・段落・選択・数値・ファイルといった型から選び、変数名を決めます。ここで定義した変数名が、以降のすべてのノードから参照される識別子になります。

変数名を後から変えると、参照している下流ノードの設定が外れます。input_text のような汎用名ではなく、customer_inquiry のように内容が分かる名前を最初に決め切るほうが、あとの手戻りが減るはずです。

ノードの追加と変数の受け渡し

キャンバス上のノード右端にあるハンドルをドラッグすると、次に置けるノードの一覧が表示されます。ノードを置いたら、上流ノードの出力を下流ノードの入力に紐づけます。LLMノードのプロンプト欄などでは、変数を次の記法で参照します。

{{#1711528915811.text#}}
{{#sys.timestamp#}}

波かっこ2つとシャープで囲む形式で、ドットの前がノードID、後ろが出力変数名です。ノードIDは作成時に自動採番される数値文字列のため、変数ピッカーから選んで挿入するのが確実です。なお同じ二重波かっこでも、テンプレートノードはJinja2形式の {{ variable_name }} でシャープを付けません。ノードにはリトライ設定もあり、HTTPリクエストノードでは既定で有効・最大3回・間隔100ミリ秒が入ります。外部APIの実レスポンス時間に合わせて調整してください。

テスト実行と変数インスペクトによるデバッグ

右上の「テスト実行」で、入力値を入れて1回流せます。失敗したノードは赤く表示され、実行ログから各ノードの入力・出力・所要時間を確認可能。期待した文字列が下流に渡っていないときは、変数インスペクト機能で実行中の変数の中身を直接のぞくのが早道です。

デバッグで最も多いのは型の不一致です。イテレーションノードやリスト操作ノードは配列を要求するため、文字列を返すLLMノードの出力をそのまま渡すとエラーになります。この場合はコードノードやパラメータ抽出ノードを挟んで、配列に変換してから渡してください。

公開と4つの提供形態

右上の「公開する」を押すと、その時点の構成がライブ版になります。公式ドキュメントは「公開すると現在の構成でライブアプリが置き換わり、ユーザーは次の操作から変更を目にする」と明記しており、反映は即時です。公開したワークフローは次の4形態で同時に利用できます。

ただし対象はユーザー入力を起点とするワークフローに限られます。公式ドキュメントは「Webアプリ、MCPサーバー、バックエンドAPI、あるいは他のDifyアプリのツールとして公開できるのはユーザー入力ワークフローだけ」と明記しており、後述するトリガー起点のワークフローはこの4形態の対象外です。トリガー起点のものは、公開後はイベントを待って自走します。

4形態は同じアプリ構成を共有するため、公開すれば全経路へ一斉に反映されます。本番稼働中のAPIがある状態で公開を押せば、検証中の構成がそのまま本番へ出るということ。編集中の確認はテスト実行にとどめ、公開は区切りのついた時点だけにしてください。MCPサーバーとして外部AIツールから呼ぶ構成は、Playwright MCPとは？設定・使い方からDify連携まで実務ガイド【2026年版】でMCP側の設定を扱っています。

主要ノードの役割と選定基準

v1.16系のノード解説ページは公式ドキュメントに23枚あり、うち回答ノードはチャットフロー専用です。すべてを覚える必要はなく、「何をしたいときにどれを選ぶか」の対応さえ押さえれば足ります。

分岐3ノードの選定基準（IF/ELSE・質問分類器・パラメータ抽出）

選定基準は明快です。条件がコードで書けるならIF/ELSE、書けないなら質問分類器を選びます。「返品という単語が含まれるか」ならIF/ELSEで足りますが、「返品したい意図か」の判定にはLLMが要ります。質問分類器はLLM呼び出しを1回消費するため、機械的に判定できる条件までLLMに投げると実行時間と課金が無駄に増えます。

データ整形ノードの使い分け（コード・テンプレート・変数集約）

LLMの前後でデータの形を整えるノード群です。コードノードはPythonまたはJavaScriptを直接書けるため、配列の整形やJSONの組み立てはここで処理します。テンプレートノードはJinja2形式で複数の変数を1つの文章にまとめる用途、変数集約ノードは分岐した複数ルートの出力を1変数に束ねる用途になります。リスト操作ノードは配列の絞り込みと並べ替え、ドキュメント抽出ノードはアップロードされたファイルのテキスト化を担当。なお変数代入ノードはチャットフローの会話変数を管理するためのノードで、会話履歴を持たないワークフローでは出番がありません。

迷いやすいのがコードノードとテンプレートノードの境目ですが、出力が文字列1本ならテンプレート、配列やオブジェクトを返すならコードと割り切ってください。テンプレートノードの出力は文字列固定です。

外部連携ノードの役割分担（HTTPリクエスト・ツール・知識取得）

HTTPリクエストノードは任意のREST APIを呼べる汎用口で、ヘッダー・ボディ・認証を自分で組み立てます。ツールノードはMarketplaceで配布されている既製の連携（検索、Slack投稿、画像生成など）を呼ぶもので、認証情報を入れるだけで使えます。知識取得ノードはDifyのナレッジベースを検索し、RAG構成の中核になります。エージェントノードは、ツールの選択と呼び出し順をLLM自身に任せたいときの選択肢です。

ツールノードで使うプラグインが入らない場合は、署名検証やパッケージ容量の制限に引っかかっていることが多く、Difyのプラグインがインストールできない原因と対処法【署名検証・容量・バージョン】に原因別の対処をまとめています。

イテレーションとループの使い分け

Difyには反復処理のノードが2つあり、名前が似ているため混同されがちです。判断基準は「前の回の結果を次の回で使うかどうか」の一点です。

イテレーション：独立した要素の一括処理

配列を受け取り、各要素に同じ処理を適用します。公式ドキュメントは入力について「パラメータ抽出、コードノード、知識取得、HTTPリクエストのレスポンスなど、上流ノードの配列変数を接続する」と説明しています。処理中は組み込み変数として items（現在の要素）と index（0から始まる番号）を参照できます。

既定は逐次処理で、並列処理は設定で有効化します。並列数は1から10までの範囲で指定でき、初期値は10です。順序が結果に影響しない処理なら並列化で実行時間が縮みますが、ストリーミング出力の扱いと実行順の予測可能性は逐次のほうが優れています。

エラー処理は3つのモードから選びます。既定は「終了」で、1件でも失敗するとその場で止まりエラーメッセージを返します。「エラーを無視して続行」は失敗した要素に null を入れて残りを処理し、「失敗した結果を削除」は成功分だけを返します。100件のうち数件の失敗を許容してよいバッチ処理では、既定のままだと全体が止まるので必ず変更してください。

ループ：前回の出力を引き継ぐ反復

ループノードは「各サイクルが前サイクルの結果の上に積み上がる反復処理を実行する」ノードです。ループ変数はサイクルをまたいで値を保持し、ループ終了後も参照できます。文章を採点しては書き直す、条件を満たすまで検索条件を変えて再試行する、といった段階的な改善に向きます。

終了の経路は3つあり、公式ドキュメントは「終了条件が満たされたとき、最大回数に達したとき、またはループ完了ノードが実行されたときにループは終了する」と説明しています。終了条件は quality_score > 0.9 のような式で書けます。最大回数の初期値は10です。

10件の記事をそれぞれ要約するならイテレーション、1本の文章を合格点になるまで推敲させるならループです。ここを取り違えると、イテレーションで無理に前回結果を参照しようとして変数が空になる、あるいはループで配列を処理しようとして1件しか処理されない、という形で詰まります。

トリガーによるワークフローの常時稼働

v1.10.0（2025年11月13日公開）で、開始ノードに「トリガー」モードが加わりました。それまでのDifyワークフローは、Webアプリで人が実行するかAPIで呼ばれるまで待つだけの受け身の存在でしたが、トリガーによって時刻やイベントで自走するようになりました。日本語で公開されている解説記事の大半はこれ以前に書かれており、この段落が抜けています。

スケジュールトリガー：時刻起動

指定した時刻や間隔でワークフローを実行します。設定は毎時・毎日・毎週・毎月を選ぶビジュアル指定と、cron式の直接入力の2通りです。cronは空白区切りの5フィールドで、分（0〜59）、時（0〜23）、日（1〜31）、月（1〜12）、曜日（0〜7）の順です。

0 9 * * 1-5      平日の毎朝9時
*/15 * * * *     15分ごと
0 0 L * *        毎月末日の0時
@daily           毎日0時（定義済みショートカット）

使える特殊文字は *（毎）、,（複数指定）、-（範囲）、/（間隔）、L（最終）、?（指定なし）です。@yearly @monthly @weekly @daily @hourly のショートカットも使えます。

1つ注意点があります。日と曜日の両方を指定した場合、公式ドキュメントは「トリガーはどちらかのフィールドに一致する日付で起動する」と説明しており、AND条件ではなくOR条件です。1 2 3 4 4 は4月3日と4月のすべての木曜日に実行されます。また、スケジュールトリガーは1つのワークフローに1つまでという制約があります。「平日朝と月末」の2系統を回したいなら、cron式でまとめるか、ワークフローを分けてください。

スケジュールトリガーは出力変数を持ちません。公式ドキュメントは「スケジュールトリガーは出力変数を生成しないが、ワークフローを起動するたびにシステム変数 sys.timestamp（各実行の開始時刻）を更新する」と説明しています。実行日時を処理に使いたい場合は、この sys.timestamp を参照します。

Webhookトリガーとインテグレーショントリガー：イベント起動

Webhookトリガーは、自社システムやIoT機器からのHTTPリクエストでワークフローを起動します。発行されたエンドポイントを呼び出し元に設定する作業が必要なぶん、送るペイロードを自由に設計できます。

インテグレーショントリガー（設定画面の項目名はプラグイン由来のため旧称で表示される場合があります）は、SlackやGitHub、Gmailなどのイベントを購読する方式です。購読の作り方は2通りで、自動設定は「購読するイベントを選ぶと、Difyが外部システム側にWebhookを作成する」もので事前のOAuthまたはAPIキー認可が要ります。手動設定は「Difyが提示するコールバックURLを使って自分でWebhookを作る」もので認可は不要です。1つのインテグレーションあたりの購読はワークスペースごとに10件までです。既製の連携があるサービスならインテグレーショントリガー、社内システムからならWebhookトリガー、という切り分けになります。

トリガー数とクォータの制約

1つのワークフローに複数のトリガーを並べて待機させられます。公式ドキュメントによれば、複数のトリガーがある場合は「最初に起動したトリガーがワークフローを開始し、他は無視される」動作です。テスト時は「テスト実行」から「すべてのトリガーを実行」を選ぶとまとめて確認できます。

制約は2種類あります。1つはトリガーの本数で、Sandboxアカウントは1ワークフローあたり最大2つ、ProfessionalとTeamプランではより多く設定できます。もう1つは実行回数で、トリガー起動によるワークフロー実行はプランごとの月次クォータの対象です。残量はワークスペースのオーナーと管理者が設定画面の請求セクションで確認できます。15分間隔のcronを組むと1日96回、月間で約2,900回を消費する計算になるため、間隔を詰める前にクォータを見てください。クォータの制約を受けたくない場合はセルフホストという選択肢もあり、構築手順はAWS EKSにDifyを導入するための事前準備と環境構築のポイントにまとめています。

Human Inputノードによる人的承認の組み込み

全自動化が最善とは限りません。外部への送信や金額の確定を含むフローでは、途中で人の確認を挟むほうが安全です。Human Inputノードは「重要な地点でワークフローを一時停止し、カスタマイズ可能な依頼フォームを配信する」ノードで、受け手は内容を確認し、入力や選択肢の指定でその後の分岐を決められます。

配信方法はWebアプリとメールの2つです。ここに実装上の落とし穴があります。公式ドキュメントは、Webアプリ配信について「トリガーで起動されたワークフローでは利用できない」と明記しています。トリガーで自動起動する処理に承認を挟むなら、配信はメール一択です。宛先はワークスペースメンバー、外部メールアドレス、ワークスペース全員から選べます。

タイムアウトの既定は3日です。期限内に回答がなければノードのタイムアウト分岐へ進みますが、この分岐に何も接続していないとワークフローはそこで終了します。承認待ちのまま消えるのを避けるには、タイムアウト分岐に通知ノードや再送のループを必ずつないでください。また、配信方法にかかわらず最初の回答を受け取った時点で受付は閉じます。複数人の合議を取る用途には向きません。

フォームの項目は3種類です。段落（文字数上限なし、変数で初期値を入れられる）、選択（一覧からの単一選択）、ファイルアップロード（単一または複数）で、任意入力にできるのは段落だけ。選択とファイルは必須項目になります。ファイルサイズの上限は画像10MB、ドキュメント15MB、音声50MB、動画100MBで、複数ファイルの項目は10件までです。

回答の内容は下流のノードから3つの変数で受け取れます。__action_id は押されたボタンの識別子、__action_value はそのボタンの表示名、__rendered_content は入力値が埋まった状態のフォーム全文です。承認と差し戻しの分岐は __action_id をIF/ELSEノードで判定して組みます。

業務ワークフローの実装例

ここまでのノードを組み合わせた構成例を3つ挙げます。

日次レポートの自動生成と配信

スケジュールトリガー（0 9 * * 1-5）で平日朝9時に起動し、HTTPリクエストノードで社内の集計APIから前日実績を取得、LLMノードで要約文を生成し、ツールノードでSlackへ投稿する4ノード構成です。集計APIが不安定ならリトライ回数を初期値の3から増やし、失敗時はIF/ELSEで「データ取得失敗」の定型文を流すルートを用意しておきます。

問い合わせの一次対応と承認

Webhookトリガーで問い合わせフォームからのPOSTを受け、質問分類器で「見積依頼」「不具合報告」「その他」に振り分けます。見積依頼のルートでは知識取得ノードで価格情報を引き、LLMノードで返信案を作成したうえで、Human Inputノードからメールで担当者へ承認を求める流れ。__action_id で承認と差し戻しを分岐し、タイムアウト分岐は3日後に営業リーダーへ再送する経路へつないでおきます。

大量ドキュメントの一括要約

ユーザー入力でファイルリストを受け取り、ドキュメント抽出ノードでテキスト化し、イテレーションノードで各ファイルをLLMに要約させます。並列数を10にして実行時間を圧縮し、エラー処理は「失敗した結果を削除」にして、読み取れないファイルがあっても全体が止まらないようにするのが要点。取り込み元をS3に置いている場合の設定はDifyのストレージをAmazon S3に切り替える設定手順と.envの優先順位が参考になります。

設計前に確認すべき上限値と避けるべき構成

Difyのワークフローには、キャンバス上では見えない上限値があります。セルフホスト版v1.16.1のソースで確認できる既定値は次のとおりで、いずれも環境変数で変更できます。

上2つはAPI側、下3つは画面側の設定値です。いずれもセルフホスト版で変更できる値であり、クラウド版の運営値とは別だと考えてください。

そのうえで、Difyのワークフローを採用すべきでない場面をはっきり書きます。まず、数千件規模のバッチ処理です。イテレーションの繰り返しは1実行あたり500ステップ・1,200秒という上限の中で消化されるため、1回の実行に全件を詰め込む構成はタイムアウトと再実行の難しさで破綻します。この規模はDify側でトリガーとAPI呼び出しだけを担い、実処理は自前のジョブ基盤に逃がすほうが確実です。

次に、ミリ秒単位の応答が求められる同期処理です。LLMノードを1つ挟むだけで秒単位の遅延が乗るため、ユーザー操作の直列上に置く設計は成立しません。

最後に、フローの巨大化です。1つの実行経路に置けるノードは50までですが、実務で40近くまで伸びたフローは変数の追跡もテストも現実的でなくなります。ノードが20を超えたら、ワークフローを分割してAPIやMCP経由で呼び合う構成へ切り替える判断を。分割の目安は「1つのワークフローが1つの業務単位を担う」ことです。

よくある質問

Difyのワークフローでは何ができますか？

LLMの呼び出し、ナレッジベースの検索、条件分岐、外部APIの実行、ファイルの読み取り、コードの実行を組み合わせて、1本の処理フローとして自動実行できます。v1.10.0以降はスケジュールやWebhookでの自動起動にも対応したため、定期レポート生成や問い合わせの一次対応のような、人が起動しない業務処理まで組めます。

ループが終わらないときはどこを見ればよいですか？

終了条件の式が一度も成立していない可能性が高いため、まず条件で参照している変数がループ内で更新されているかを変数インスペクトで確認してください。ループ変数は明示的に更新しないと初期値のままです。最大回数の初期値は10で、設定可能な上限は100。無限に回り続けることはありませんが、上限まで回ってから終わるとLLMの呼び出し回数だけが増えます。break相当の「ループ完了」ノード（英語UIではExit Loop）を分岐の先に置く方法も有効です。

トリガーは1つのワークフローにいくつ設定できますか？

Sandboxアカウントでは1ワークフローあたり最大2つ、ProfessionalとTeamプランではより多く設定できます。ただしスケジュールトリガーだけは、プランにかかわらず1ワークフローに1つまでです。複数のトリガーを置いた場合は、最初に起動したものがワークフローを開始し、残りは無視されます。

チャットフローでもトリガーは使えますか？

使えません。チャットフローの起点はユーザー入力に固定されており、トリガーを持てるのはワークフローだけです。会話型のアプリで定期処理を組みたい場合は、処理本体をワークフローとして作り、チャットフロー側からはAPIやツールとして呼び出す構成にしてください。

作成したワークフローを外部システムから呼び出せますか？

ユーザー入力を起点とするワークフローであれば、公開と同時にWebアプリ・API・サイト埋め込み・MCPサーバーの4形態が有効になります。自社プロダクトへ組み込むならAPI、Claude DesktopやCursorのようなAIツールから使わせるならMCPサーバーを選んでください。一方、トリガー起点のワークフローはこの4形態の対象外で、イベント発生時に自動で走る使い方に限られます。

関連記事

• 最近話題の「Dify」で社内チャットボットを作成しよう！概要と魅力
• Difyのプラグインがインストールできない原因と対処法【署名検証・容量・バージョン】
• Playwright MCPとは？設定・使い方からDify連携まで実務ガイド【2026年版】
• AWS EKSにDifyを導入するための事前準備と環境構築のポイント
• DifyのストレージをAmazon S3に切り替える設定手順と.envの優先順位