Dify でAPIフローを設計する：外部サービスと繋いだAIワークフローの作り方

を使ってWorkflowで外部APIとの連携を試した。

チャットボットを作った後、「もう少し実用的なことをしたい」と思って手を出したのがWorkflowモードだ。外部のAPIからデータを取ってきて、それをLLMで処理して返すという流れを、ノーコードで組めるかどうかを確認したかった。

この記事では、DifyのWorkflowモードを使ってHTTPリクエストノードで外部APIを叩き、LLMで処理するフローの設計手順を書く。チャットボットは作れた、次は何ができるかを探している人に向けた内容だ。

dify workflow API integration — Photo by Bluestonex on Unsplash

この記事でわかること
DifyのWorkflowモードとは何か：チャットボットとどう違うか
1. Workflowが向いている用途と向いていない用途
Workflowで外部APIを叩くための基本構成
実際に動かしてみた：天気APIを取得してLLMで要約するフロー
フリーランスが使いそうな連携パターン3つ
やってみてわかったWorkflowの限界と注意点
まとめ：Workflowは「決まった処理」の自動化に使いやすい

この記事でわかること

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}}&current=temperature_2m

このように変数をURL内に埋め込める。Open-MeteoはAPIキー不要で使えるので、試し用として使いやすい。

dify workflow node setup — Photo by Growtika on Unsplash

実際に動かしてみた：天気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プラン以上が必要だ。