Difyワークフローの実例5選｜非エンジニアが実際に作って動いた構成を公開【再現可】
「Difyワークフローの例を見たい」という方向けに、私が実際に作って動いた5つのワークフローを公開します。
「作り方は分かった。でも何を作ればいいか分からない」という状態を、この記事で抜け出してもらうことが目的です。
各例は「目的・ノード構成・フロー・詰まった点・改善点」の統一フォーマットで解説します。コードは不要です。すべてDifyの画面上で再現できる構成です。
Difyワークフローで「何が作れるか」を先に整理する
いきなり例を見ても「自分には無理そう」と感じませんか？まず作れるものの種類を整理しておくと、各例が格段に再現しやすくなります。
非エンジニアが最初に作るべき3種類
Difyのワークフローは、大きく3種類に分類できます。
単純型（入力→処理→出力）は、Start・LLM・Endの3ノードだけで動きます。最初はこれだけで十分です。複雑に見えるワークフローも、分解すると単純型の組み合わせになっていることがほとんどです。
条件分岐型は、入力の内容によって処理の流れを変えます。単純型が安定して動いてから追加します。
外部連携型は、HTTPノードを使ってGASやスプレッドシートなど外部サービスと繋ぎます。3種類の中で最も詰まりやすいため、最後に挑戦することをおすすめします。
この記事の5例の位置づけ
例1・2が単純型、例3が分岐型、例4・5が外部連携型です。この順番で読むとステップアップできる構成になっています。
ノードの種類や接続の基本操作は[Difyワークフローの作り方](https://bizinets.life/dify-workflow-build-guide)で解説しています。画面操作を確認してから各例を試すとより再現しやすいと思います。
例1：SEO記事の構成案を自動生成するワークフロー
最初に作るなら、この例が一番再現しやすいと思います。3ノードで完結し、プロンプトだけ書けば動きます。
目的
キーワードを入力すると、H2見出し5個とそれぞれの要旨が出力されます。毎回ゼロから考えていた構成案作業を自動化するために作りました。実際に使い始めてから、構成案作成にかかる時間が約70%短縮されました。
ノード構成
Start（keyword: テキスト型）→ LLM → End の3ノード構成です。
フロー
Startノードにkeyword変数を1つ定義します。LLMノードのシステムプロンプトには役割と出力フォーマットを明記し、ユーザープロンプトでStartノードの変数を参照します。
【システムプロンプト】
あなたはSEO記事の構成案を作るアシスタントです。
与えられたキーワードに対して、H2見出しを5個と各見出しの要旨を1文ずつ提案してください。
出力は以下の形式で返してください。
## 見出し1
要旨：〇〇
## 見出し2
要旨：〇〇
【ユーザープロンプト】
キーワード：{{#start.keyword#}}EndノードはLLMの出力変数textをそのまま参照します。
詰まった点
出力フォーマットを指定しないと、毎回バラバラな形で返ってきました。あるときは番号付きリスト、あるときは箇条書き、あるときは段落テキストという状態で、後工程で使いにくかったです。
解決策はプロンプトにMarkdown形式のサンプルを1つ添えることでした。「このような形式で出力してください」と例を見せるだけで、出力が安定しました。
改善点
現在は見出しと要旨のみ出力しています。次のステップとして、各H2の「想定字数」と「含めるべきキーワード」も合わせて出力させる予定です。
例2：入力文章を要約して箇条書きにするワークフロー
例1と骨格は同じです。プロンプトを差し替えるだけで別の用途になることを体感できる例です。
目的
長い文章（議事録・メール・記事）を貼り付けると「3行要約＋箇条書き5点」で出力されます。会議後の議事録整理に毎週使っています。
ノード構成
Start（text: テキスト型）→ LLM → End の3ノード構成です。例1と同じ骨格で、プロンプトだけ差し替えています。
フロー
Startノードのtext変数は「複数行テキスト型」に設定します。これにより長文の貼り付けに対応できます。
【システムプロンプト】
あなたは文章の要約アシスタントです。
与えられた文章を以下の形式で出力してください。
【3行要約】
1行目：〇〇
2行目：〇〇
3行目：〇〇
【重要ポイント5点】
・〇〇
・〇〇
・〇〇
・〇〇
・〇〇
【ユーザープロンプト】
{{#start.text#}}詰まった点
長文を貼り付けるとトークン上限に近づき、出力が途中で切れることがありました。5000字を超える議事録を貼ったとき、重要ポイントが3点で終わってしまった経験があります。
解決策は2つです。LLMノードの最大トークン数を調整したことと、Startノードの変数説明に「3000字以内を推奨」と注記を追加したことです。
改善点
現在は文章を手動で貼り付けています。将来的にはHTTPノードでURLを渡してスクレイピング連携させることを検討中です。
例3：入力内容によって処理を分岐するワークフロー
分岐が入ると一気に「本格的なワークフロー」に見えますが、構造自体はシンプルです。単純型が動いてから挑戦してみてください。
目的
「質問」と「依頼」の2種類が混在する入力を、内容によって異なるプロンプトで処理します。1つのワークフローで複数の用途に対応させるための設計です。
ノード構成
Start（input: テキスト型）→ LLM①（分類）→ 条件分岐 → LLM②（質問処理）/ LLM③（依頼処理）→ End の5ノード構成です。分岐構成の最小形です。
フロー
LLM①は分類専用です。入力が「質問」か「依頼」かを判定して、"question" か "request" の1単語だけ返すよう指示します。
【LLM①システムプロンプト】
以下の入力テキストを分類してください。
「質問」であれば "question" のみ返してください。
「依頼」であれば "request" のみ返してください。
他の文字は一切出力しないでください。条件分岐ノードでは「LLM①の出力が'question'を含む」かどうかで分岐します。LLM②とLLM③はそれぞれ異なるシステムプロンプトで処理し、Endノードを2系統に接続します。
詰まった点
LLM①が "question" ではなく「これは質問です」などと余分な文章を返してきて、分岐条件に一致しませんでした。条件分岐が常に片方のルートしか通らない状態が続きました。
解決策は2つです。「必ず1単語のみ返してください」とプロンプトに明記したことと、LLM①のtemperatureを0に設定したことです。temperatureを0にすると出力がほぼ固定され、余分な表現が出なくなりました。
改善点
現在は「質問」と「依頼」の2分岐のみです。「情報収集」「フィードバック依頼」などを追加して3〜4分岐に拡張する予定です。
例4：フォーム入力をGoogleスプレッドシートに記録するワークフロー
外部連携が入ると詰まりやすくなります。でも仕組みを理解すれば応用範囲が一気に広がります。
目的
Difyのフォーム画面に記入した内容を、GASを経由してGoogleスプレッドシートに自動保存します。問い合わせ内容や日次ログの記録に使っています。
ノード構成
Start（name / email / message: テキスト型）→ LLM（整形）→ HTTPノード（GASにPOST）→ End の4ノード構成です。外部連携の最小形です。
フロー
Startノードにname・email・messageの3変数を定義します。LLMノードで入力内容を「日付・名前・メール・内容」のフォーマットに整形します。HTTPノードでGASのエンドポイントURLにPOSTリクエストを送信し、GAS側でスプレッドシートに追記処理を行います。
GAS連携の詳細（エンドポイント設定・認証・エラー処理）は[DifyとWordPressを自動連携した実装ログ](https://bizinets.life/dify-wordpress-gas-403-log)で解説しています。
詰まった点
HTTPノードのJSONボディ内でDifyの変数が展開されず、"{{#start.message#}}" がそのまま文字列として送られました。スプレッドシートを確認したらプレースホルダーがそのまま書き込まれていました。
解決策はLLMノードで整形した出力テキストを、Codeノードでエスケープ処理してからHTTPノードに渡すことです。この変数展開の問題の詳細は[Difyのイテレーションで変数が文字列になる問題](https://bizinets.life/dify-iteration-variable-string-bug)で実体験から解説しています。
改善点
現在はLLMノードで整形しています。Codeノードで直接整形すればLLMノードが不要になり、3ノード構成に削減できます。LLMを使わないぶん処理速度も上がるため、次のバージョンで変更予定です。
例5：キーワードリストからSNS投稿文を一括生成するワークフロー
イテレーション（繰り返し処理）を使った例です。リスト処理ができるようになると自動化の幅が一気に広がります。
目的
改行区切りのキーワードリストを受け取り、各キーワードに対してX（旧Twitter）用の投稿文を生成します。週1回のX投稿ストックを自動生成するために使っています。5キーワードを入力すると約90秒で5本の投稿文が出力されます。
ノード構成
Start（keywords: テキスト型）→ LLM①（配列変換）→ イテレーション → LLM②（投稿文生成）→ End のイテレーション構成です。
フロー
Startノードは改行区切りのキーワードリストを1つのテキストとして受け取ります。
LLM①でリストをJSON配列に変換します。
【LLM①システムプロンプト】
入力されたキーワードリストを、以下のJSON配列形式のみで返してください。
他の文字は一切出力しないでください。
例：["キーワード1","キーワード2","キーワード3"]イテレーションノードで配列の各要素を1つずつLLM②に渡し、140字以内のX投稿文を生成します。Endノードで全結果を結合して出力します。
詰まった点
イテレーション内のLLMノードにitem変数を渡すときに展開されないケースがありました。LLM②に渡されるはずのキーワードが "{{item.keyword}}" という文字列のままになっていました。
解決策はイテレーション先頭にCodeノードを追加してitem変数を展開してから後続ノードに渡すことです。同じ問題の詳細な原因と対処は[Difyのイテレーションで変数が文字列になる問題](https://bizinets.life/dify-iteration-variable-string-bug)に記載しています。
改善点
現在はEndで全結果を結合して出力しています。HTTPノードを追加してGoogleスプレッドシートに1行ずつ書き込む構成に改善予定です。
5つの例から見えてきた共通パターン
5例を作ってみて、共通する傾向が3つ見えてきました。これを知っておくと次に作るときに詰まりにくくなります。
単純型（例1・2）から始めるべき理由
3ノードで動くワークフローは、問題が起きたときの切り分けが簡単です。「Startに問題があるか」「LLMのプロンプトに問題があるか」「Endの出力設定に問題があるか」の3箇所しか疑う場所がありません。改善サイクルが速く回るため、最初の1本は必ず単純型で作ることをおすすめします。
分岐・連携は「動いてから追加する」
例3・4・5で詰まったのは、すべて「複雑にしたあと」でした。単純型が動いている状態から1ノードずつ追加して、都度動作確認するのが最短ルートです。いきなり5ノードを並べてから「どこがおかしいか」を探すのは、経験上とても時間がかかります。
「詰まった点」の9割はプロンプトか変数展開
5例すべての詰まりを振り返ると、原因はほぼ2パターンに集約されます。プロンプトの曖昧さか、変数展開の仕様理解不足かです。実行ログを開いて1ノードずつ「入力と出力が期待通りか」を確認する習慣をつけると、原因の特定が格段に速くなります。
まとめ
5例すべてがDifyの画面上だけで再現できる構成です。今日できる一歩としては、例1のプロンプトをそのままコピーして、自分のキーワードで動かしてみることをおすすめします。
まずは例1か例2（3ノード）から始め、動いてから例3・4・5の要素を少しずつ追加していく順番が、一番詰まらずに進める方法です。
5つの例を通じて共通しているのは、ツールを動かすことと、何を自動化するかを設計することは別の問いだということです。Difyで仕組みを動かせるようになった次のステップとして、設計の考え方を体系的に整理したい方は、bizinets.biz の[サイト設計思想](https://bizinets.biz/site-design-philosophy/)が参考になると思います。
bizinets.biz
記事を読んで「もっと知りたい」と思ったあなたへ
bizinets.biz では、ビジネスの仕組みづくりを体系的に学べるコンテンツを用意しています。まずは一度、覗いてみてください。
bizinets.biz へ行く →
