を使ってWorkflowで外部APIとの連携を試した。
チャットボットを作った後、「もう少し実用的なことをしたい」と思って手を出したのがWorkflowモードだ。外部のAPIからデータを取ってきて、それをLLMで処理して返すという流れを、ノーコードで組めるかどうかを確認したかった。
この記事では、DifyのWorkflowモードを使ってHTTPリクエストノードで外部APIを叩き、LLMで処理するフローの設計手順を書く。チャットボットは作れた、次は何ができるかを探している人に向けた内容だ。
この記事でわかること
- DifyのWorkflowモードとチャットボットモードの違い
- HTTPリクエストノードで外部APIを呼び出す手順
- 変数の定義と受け渡し方法
- 実際に動かしてみてわかった注意点
DifyのWorkflowモードとは何か：チャットボットとどう違うか
Difyには複数のアプリモードがある。チャットボット、テキストジェネレーター、エージェント、そしてWorkflowだ。
Workflowが他と違うのは、処理の手順が完全に固定されていること。入力→処理A→処理B→出力、という順番が決まっていて、LLMが途中で判断して経路を変えたりしない。
チャットボットはユーザーと対話を繰り返す。Workflowは1回の入力に対して処理を実行して結果を返す、非対話型の設計だ。
Workflowが向いている用途と向いていない用途
向いている用途：
– 毎回同じ手順で処理したい業務（データ取得→整形→LLM要約→返却）
– 外部APIのデータをLLMで加工して使う
– 定型的なレポート生成・テキスト処理
向いていない用途：
– ユーザーと複数ターンで会話しながら進める処理 → チャットボットを使う
– 状況に応じてLLMが判断して処理を変える → Agentモードを使う
– 複雑なトリガー駆動の自動化 → n8nやMakeの方が向いている
まあ、「決められた手順を確実にこなす」ときのツールだと思えばいい。
Workflowで外部APIを叩くための基本構成
Difyのダッシュボードで「アプリを作成」→「ワークフロー」を選んで新規作成する。ワークフローの詳細な仕様はDify公式日本語ドキュメントでも確認できる。
作成すると、START（開始）ノードとEND（終了）ノードだけがある画面が表示される。ここに必要なノードを追加していく。
外部APIを呼ぶ基本的な構成はこうなる：
START → HTTPリクエスト → LLM → END
シンプルに見えるが、各ノードの設定が少し手間だ。
HTTPリクエストノードの追加と設定
画面上の「+」ボタンからノードを追加できる。「HTTPリクエスト」を選ぶ。
追加したノードをクリックすると設定画面が開く。設定する項目：
- メソッド：GET / POST / PUT / DELETE から選ぶ
- URL：呼び出すAPIのエンドポイント
- ヘッダー：必要に応じてContent-Typeや認証トークンを設定
- ボディ：POSTの場合はリクエストボディをJSON形式で記述
ここでハマりやすいのが、Content-Typeを設定し忘れること。POSTリクエストでJSONを送る場合は Content-Type: application/json を明示しないと、サーバー側でリクエストを受け付けないことが多い。僕は30分これで消費した。
入力変数を定義する
STARTノードをクリックすると、入力変数を定義できる。
変数は {{変数名}} という形式で他のノードから参照できる。例えば {{location}} という変数を作れば、HTTPリクエストのURLやボディに {{location}} と書いて値を渡せる。
変数の型は「テキスト」「数値」「セレクト」などから選べる。入力フォームのUIも選択肢によって変わる。
リクエスト先のURLとヘッダーを設定する
HTTPリクエストノードのURL欄に変数を含めることもできる。
例えば、天気情報を取得するなら：
https://api.open-meteo.com/v1/forecast?latitude={{lat}}&longitude={{lon}}¤t=temperature_2m
このように変数をURL内に埋め込める。Open-MeteoはAPIキー不要で使えるので、試し用として使いやすい。
実際に動かしてみた：天気APIを取得してLLMで要約するフロー
実際に以下のフローを作った：Open-MeteoのAPIから東京の現在気温を取得して、LLMで「今日の服装アドバイス」を返すワークフロー。
設計〜テスト完了まで約2時間かかった。ノード設定のミスと変数の渡し方の理解不足で、5回ほどエラーを出した。
ノードの接続順序：START → HTTPリクエスト → LLM → END
各ノードを追加し、ドラッグで接続線を引く。接続は出力ポート（ノードの右端）から次のノードの入力ポート（左端）へ引く。
構成：
- START：入力変数
city_name（テキスト）を定義 - HTTPリクエスト：Open-MeteoのAPIを叩く（latitude/longitudeをハードコード）
- LLM：レスポンスから気温を取り出して服装アドバイスを生成
- END：LLMの出力を返す
変数の受け渡しとレスポンスのパース
HTTPリクエストノードの出力は {{HTTPリクエスト1.body}} という形で参照できる。ただし、JSONレスポンスの特定フィールドを取り出すには少し工夫が必要だ。
例えば {"current": {"temperature_2m": 22.5}} というレスポンスから気温だけ取り出したいとき、DifyのWorkflowではLLMノードのプロンプト内で「このJSONから current.temperature_2m の値を取り出して使え」と指示する方法が手軽だ。
ただ、より確実にやりたいなら「コード」ノードをHTTPリクエストとLLMの間に挟んで、Pythonで json.loads(body)['current']['temperature_2m'] を実行する方が安定する。
テストして確認する
各ノードの右上に「テスト」ボタンがある。ノード単体で入力を渡して出力を確認できる。フロー全体のテストは画面上部の「実行」から行う。
テスト実行時に表示されるパネルで、各ノードの入力・出力を確認できるのが便利だ。どのノードでエラーが出ているかがすぐわかる。
フリーランスが使いそうな連携パターン3つ
パターン1：Slack通知に使う
SlackのIncoming WebhookのURLにHTTPリクエストでPOSTすれば、DifyのWorkflowからSlackに通知を送れる。LLMで生成したテキストをそのまま投稿する、というフローが作りやすい。Incoming WebhookのURLはSlackのApp管理画面から取得できる。
パターン2：Notionにデータを書き込む
NotionのAPIを使えば、Workflowの処理結果をデータベースに書き込める。定期実行は別途スケジューラーが必要になるが、「処理→Notion書き込み」の部分だけDifyで作るのは悪くない。NotionのAPIドキュメント（日本語ページ）からAPIキーの発行手順を確認できる。
パターン3：外部データをLLMで要約してレポート化する
何らかのAPIからデータを取得して、LLMで整形して返すという形はWorkflowの得意な用途だ。毎回同じフォーマットで出力させたいなら、チャットボットよりWorkflowの方が安定する。
やってみてわかったWorkflowの限界と注意点
エラーメッセージが素っ気ない。
HTTPリクエストが失敗したとき、エラーの内容がわかりにくいことが多い。「ステータス400」だけ表示されて、何が原因かを特定するのに時間がかかった。デバッグには、まずAPIを単体でcurlで叩いてみて、正しく動くことを確認してからDifyに持ち込むのが結局早い。
複雑なJSONパースはコードノードを使わないと辛い。
UIだけでJSONの深い階層にアクセスしようとすると無理が出る。Pythonコードを少し書けるならコードノードを使う方が結局早い。「ノーコード」と言いつつ、実用的なフローを作るとコードが欲しくなる局面がある。
n8nと比べると。
率直に言うと、「外部APIとつないで何か処理をする」という用途だけなら、n8nの方が柔軟で細かい制御がしやすい。DifyのWorkflowの強みは、LLMノードとの統合が素直にできること。外部API連携が主で、LLMはあくまで補助という場合はn8nを選ぶ方が良さそうだ。
とはいえ、「LLMを中心に置いたフロー」にはDify Workflowが向いている。どちらを使うかは、処理の主役がLLMか外部APIかで決まる。
LLMのAPI費用について補足しておくと。
WorkflowでLLMノードを使う場合、当然LLMのAPIキーが必要で費用がかかる。Workflowを何百回も実行するような使い方をすると、LLM費用が想定外に膨らむことがある。1回の実行で使うトークン数をテスト段階で確認しておくことをすすめる。軽い処理ならGPT-4o-miniで抑えるのが無難だ。
また、Workflowは「1実行＝1メッセージクレジット消費」というカウントになる（プランの制限に関係する）。Sandboxプランの200クレジットはWorkflowのテストでもすぐ消えるので、本格的に使うならProfessionalプラン以上が必要だ。
まとめ：Workflowは「決まった処理」の自動化に使いやすい
DifyのWorkflowモードは、外部APIとLLMを組み合わせた定型処理を作るのに向いている。チャットボットの次のステップとして試す価値はある。
ただ、複雑な処理をしようとするとコードノードが必要になるし、n8nと比べると外部API連携の細かい制御に不満が出る場面もある。使い分けのイメージとしては、「LLM処理を中心に据えたシンプルなフロー」ならDify、「複数のサービスを複雑に繋ぐ自動化」ならn8nという感じだ。
次は、DifyのAgentモードを試してみるつもりだ。Workflowが「決まった処理」なのに対して、AgentはLLMが状況を判断してツールを使う「考えながら動く」設計になっている。
合わせて読みたい
– Difyの使い方入門
– n8n WebhookでAPIを受け取る方法
–
コメント