Difyワークフローの使い方｜LLMを組み合わせてAIアプリを作る手順

Difyの基本を触ったあと、多くの人が最初につまずくのが「チャットボットは作れたけれど、複数の処理を順番に動かすワークフローの組み方がわからない」という壁です。本記事では、DifyのワークフローでLLMノードや知識ベースノードを組み合わせ、実用的なAIアプリを作るまでの手順を、初心者がつまずきやすいポイントとあわせて解説します。ノーコードの基本操作は押さえた前提で、一歩進んだ「処理の設計」に踏み込みます。

Difyのワークフローとは｜チャットフローとの違いを先に押さえる

Difyには大きく分けて「チャットボット」「エージェント」「ワークフロー」「チャットフロー」という作成タイプがあります。このうちワークフローは、入力から出力までの処理を複数のノードでつなぎ、一連の自動処理として実行する仕組みです。1回のリクエストで「文章を要約し、その結果を翻訳し、指定フォーマットで出力する」といった多段処理を、コードを書かずに組めるのが特徴です。

ワークフローとチャットフローはどう違うのか

混同しやすいのが「ワークフロー」と「チャットフロー」です。ワークフローは1回の入力に対して処理を流して終わるバッチ型で、文章生成・データ変換・分類などの単発タスクに向きます。一方チャットフローは会話の文脈を保持し続ける対話型で、問い合わせ対応のように複数ターンのやり取りが必要な用途に向きます。「会話の往復が要るか」を基準に選ぶと迷いません。

ワークフローで何ができるか

典型的な用途は、議事録の要約と整形、長文の多言語翻訳、問い合わせ内容の自動分類と振り分け、社内ドキュメントを参照した回答生成（RAG）などです。いずれも「複数のステップを決まった順序で実行したい」場面で力を発揮します。

ワークフローの基本ノードと役割｜まず覚える5種類

Difyのワークフローは、用途別のノードをドラッグ＆ドロップで配置し、各ノードの出力端子を次のノードの入力端子へ線でつないで構築します。代表的なノードは10種類以上ありますが、まず覚えるべきは次の5つです。

開始ノード・終了ノード

すべてのワークフローは開始ノードから始まり終了ノードで結果を返します。開始ノードでは、ユーザーから受け取る入力変数（テキスト、ファイル、選択肢など）を定義します。ここで定義した変数が、後続のノードで参照する「材料」になります。

LLMノード

ワークフローの中核がLLMノードです。GPTやClaude、Geminiなどのモデルを呼び出し、プロンプトに沿って文章生成・要約・分類などを実行します。プロンプト内では {{変数名}} の形で前のノードの出力を埋め込めるため、入力をそのままモデルに渡せます。複数のLLMノードを並べれば「要約→翻訳」のような多段処理も可能です。

知識取得（知識ベース）ノード

RAGを実現するのが知識取得ノードです。事前にアップロードしたドキュメントから、入力に関連する箇所を検索してLLMノードへ渡します。社内マニュアルや製品仕様を参照した回答を作りたいときに使います。

条件分岐（IF/ELSE）ノード

入力内容によって処理を分けたいときは条件分岐ノードを使います。たとえば「問い合わせが技術系か営業系か」を判定し、それぞれ別のLLMノードへ流す、といった振り分けができます。

Difyワークフローの作り方｜LLMを組み合わせる実践手順

ここでは「入力した日本語テキストを要約し、その結果を英語に翻訳して返す」という2段のLLM処理を例に、手順を追います。

手順1：ワークフローアプリを新規作成する

Difyのトップで「最初から作成」を選び、アプリタイプでワークフローを選択します。名前を付けて作成すると、開始ノードと終了ノードだけが置かれた編集画面（キャンバス）が開きます。

手順2：開始ノードに入力変数を定義する

開始ノードを選び、テキスト型の入力変数（例：source_text）を追加します。これがユーザーから受け取る原文になります。変数名は後で参照するため、わかりやすい英数字にしておくのがコツです。

手順3：1つ目のLLMノードで要約する

開始ノードの後ろにLLMノードを追加し、使用モデルを選びます。プロンプト欄に「次の文章を3行で要約してください：{{source_text}}」のように書き、開始ノードの変数を埋め込みます。これで原文が要約されます。

手順4：2つ目のLLMノードで翻訳する

さらにLLMノードを追加し、前のノードの出力（要約結果）を {{要約ノードの出力変数}} で受け取って「次の日本語を自然な英語に翻訳してください」と指示します。前のノードの出力を次の入力に渡すのがワークフロー構築の肝です。

手順5：終了ノードで出力を設定し、テスト実行する

終了ノードで、最終的に返したい変数（翻訳ノードの出力）を指定します。右上の「実行」から原文を入力してテストし、要約→翻訳が意図どおり流れるか確認します。問題なければ「公開」でAPIやWebアプリとして利用できます。

つまずきやすいポイントと対処法｜実際にハマった失敗例

ワークフロー構築で初心者が必ずと言っていいほど引っかかる箇所を、失敗例とあわせてまとめます。

失敗例1：変数の参照先を間違えて空の出力になる

最も多いのが変数の取り違えです。2つ目のLLMノードで、開始ノードの原文（source_text）を参照してしまい、要約結果を翻訳できていないケース。実行結果が「原文の英訳」になっていたら、参照先が1つ前のノードの出力になっているかを必ず確認します。各ノードの実行ログで中間出力を見られるので、どこで途切れたかを追うのが近道です。

失敗例2：プロンプトで出力形式を指定せず後段が崩れる

前段のLLMが余計な前置き（「以下が要約です：」など）を付けると、後段がそれごと処理して精度が落ちます。前段のプロンプトで「要約本文のみを出力。前置き不要」と明示すると、後段に渡るデータがきれいになります。多段ワークフローでは「各ノードの出力をどの形で次に渡すか」を設計する意識が重要です。

失敗例3：知識ベースが効かない

RAGを組んだのに参照が効かない場合、ドキュメントのインデックス作成が終わっていない、または知識取得ノードの出力をLLMノードのプロンプトに埋め込み忘れている、のどちらかが大半です。知識取得ノードの結果変数を、LLMノードのプロンプト内で明示的に参照しているか確認します。

失敗例4：実行は成功するのに料金だけかさむ

多段のLLMノードを欲張って積みすぎると、1リクエストごとに複数回モデルを呼び出すため、処理は動いてもモデルのAPI利用料が想定以上に膨らむことがあります。要約と整形のように分けたほうが精度が上がる工程は分割し、単純な変換は1ノードにまとめるなど、「ノード数＝コスト」を意識した設計にすると無駄が減ります。テスト段階で1回あたりのトークン消費を確認しておくと、本番のコスト予測が立てやすくなります。

ワークフロー設計の型｜目的別のおすすめノード構成

毎回ゼロから考えると手が止まります。よくある目的に対する「ノード構成の型」を持っておくと設計が速くなります。編集部で実際に組んで使いやすかった構成を整理しました。

まずはこの型をそのまま組んでみて、動いたら自分の用途に合わせてノードを足していくのが、挫折しない進め方です。

Difyワークフローの料金｜プラン費用とLLM従量課金は別建て

ワークフローを本格運用する前に、費用の構造を理解しておきましょう。Difyクラウドの料金はプラン利用料とLLM API（モデル）の利用料が別建てになる点に注意が必要です。

ワークフローはノードを増やすほどリッチになりますが、その分メッセージクレジットとモデル利用料を消費します。費用は「どれだけ呼ぶか」で決まるため、設計段階からコスト意識を持っておくと運用が安定します。

クラウド版の主なプランは次のとおりです（Dify公式の料金ページに基づく、2026年6月時点）。

まずは無料のSandboxでワークフローを試作し、運用に乗せる段階でProfessional以上を検討するのが現実的です。なお、LLMノードで呼び出すモデル（OpenAIやAnthropicなど）のAPI利用料は、各モデル提供元の従量課金として別途かかる場合があるため、処理量が多いワークフローではモデル側のコストも見積もっておくと安心です。

まとめ：ワークフローは「型」と「変数の受け渡し」を押さえれば作れる

Difyのワークフローは、LLMノードを軸に開始・終了・知識取得・条件分岐を組み合わせることで、コードなしで実用的なAIアプリを構築できます。つまずきの大半は変数の参照先と前段の出力形式に集約されるので、各ノードの実行ログで中間出力を確認しながら組むのが上達の近道です。まずは本記事の「型」をそのまま再現し、動く成功体験を作ることから始めてみてください。

Difyの基本操作やアプリ作成の全体像から確認したい方はDifyの使い方入門｜ノーコードでAIアプリを作る方法を、より高度な自動化を比べたい方はn8nの使い方入門｜AI業務自動化ワークフローの作り方もあわせてご覧ください。