Difyとn8nを連携させると、Difyが得意な「AIの思考」とn8nが得意な「業務の受け渡し」を分担でき、問い合わせ対応やレポート作成をまるごと自動化できます。ただし実際に組むと、APIキーの認証エラーやWebhook URLの取り違えでつまずく人が多いのも事実です。この記事では2026年7月時点の仕様にもとづき、2つの連携方向それぞれの設定手順と、実際に詰まりやすいポイント、料金の実費試算までを整理します。
Difyとn8nを連携すると何ができるのか
両者は競合ツールのように語られがちですが、役割が違うため組み合わせると強くなります。まずは分担のイメージを掴んでおきましょう。
Difyは「AIの頭脳」、n8nは「業務の手足」
Difyは、LLMを使ったチャットボットやワークフローをノーコードで組み立て、それをAPIとして公開するのが得意です。一方n8nは、SlackやGmail、スプレッドシート、データベースなど数百のサービスをつなぎ、「いつ・何をトリガーに・どこへ流すか」を制御するのが得意です。
つまり「考える部分をDify、運ぶ部分をn8n」に寄せるのが基本設計です。Difyの中でSlack連携まで作り込もうとすると無理が出ますし、逆にn8nの中でプロンプト管理まで抱えると保守が苦しくなります。
連携の方向は2つある
どちらから呼ぶかで設定がまったく変わります。先に方向を決めてください。
- 方向1：n8n → Dify（n8nがトリガーを受け、Difyに考えさせる）。実務ではこちらが9割です。
- 方向2：Dify → n8n（Difyの処理途中で、n8n経由で外部サービスを操作する）。
どちらを選ぶかの判断基準
「きっかけが外部にあるか」で決めるとぶれません。メール受信・フォーム送信・定時実行など起点が業務側にあるなら方向1。Difyのチャット画面がユーザーの入り口で、その会話の途中で外部操作をしたいなら方向2です。迷ったら方向1で組むほうが、デバッグが圧倒的に楽になります。
【方向1】n8nからDifyのワークフローを呼び出す手順
最も使う構成です。n8nのHTTP RequestノードからDifyのAPIを叩きます。
ステップ1：DifyでAPIキーを発行する
Difyで対象アプリを開き、左メニューの「APIアクセス」（API Access）へ進みます。右上の「APIキー」からキーを新規作成し、値をコピーします。このとき、画面に表示されるAPIベースURL（クラウド版なら https://api.dify.ai/v1）も控えておきます。セルフホスト版では自分のドメインになるため、ここを取り違えると後で必ず接続に失敗します。
ステップ2：n8nのHTTP Requestノードを設定する
n8n側で「HTTP Request」ノードを追加し、次のように設定します。チャット型アプリの場合の例です。
| 項目 | 設定値 |
|---|---|
| Method | POST |
| URL | https://api.dify.ai/v1/chat-messages |
| Authentication | Generic Credential Type → Header Auth |
| Header 名 / 値 | Authorization / Bearer <APIキー> |
| Body Content Type | JSON |
送信するJSONの最小構成は次のとおりです。query に前のノードの値を差し込みます。
inputs：Dify側で定義した変数（無ければ空オブジェクト）query：AIに渡す本文response_mode：blocking（n8nで扱うならこちら）user：ユーザー識別子（任意の文字列で可。必須項目）
APIキーはノードに直接書かず、n8nのCredentials機能に保存してください。ワークフローを書き出したときにキーが混入する事故を防げます。
ステップ3：レスポンスを受け取って次へ渡す
Difyの応答本文は answer フィールドに入ります。n8nの後続ノードでは {{ $json.answer }} で参照でき、そのままSlack投稿やスプレッドシート追記へ渡せます。ワークフロー型アプリを呼ぶ場合はエンドポイントが /v1/workflows/run になり、出力は data.outputs の下に入る点が違います。
【方向2】Difyからn8nのWebhookへ送る手順
Difyのチャットを起点にしつつ、外部サービスの操作だけn8nに任せる構成です。
ステップ1：n8nでWebhook URLを取得する
n8nで「Webhook」ノードを先頭に置くと、URLが自動発行されます。ここでTest URLとProduction URLの2種類が出る点が最重要です。Test URLは画面で「Execute workflow」を押している間しか反応しません。
ステップ2：DifyのHTTPリクエストノードから送信する
Difyのワークフロー編集画面で「HTTPリクエスト」ノードを追加し、メソッドをPOST、URLに先ほどのWebhook URLを貼り付けます。Body（JSON）にDify側の変数を埋め込めば、n8nがそれを受け取って処理を続けます。Difyのワークフローノードの基本操作はDifyワークフローの使い方（LLMを組み合わせてAIアプリを作る手順）で詳しく解説しています。
連携でつまずく5つのポイントと対処法
ここが本記事の核心です。実際に手が止まりやすい箇所を、症状ベースで整理しました。
認証まわりの失敗（401が返る）
- Bearerの付け忘れ：値はキー単体ではなく
Bearer+ 半角スペース + キーです。最頻出の原因です。 - キーの種類違い：Difyには「アプリのAPIキー」と「ナレッジ用のAPIキー」があり、用途が別です。取り違えると認証は通っても対象が見つかりません。
Webhookが反応しない
ほぼTest URLをProduction用に使っているケースです。n8n側でワークフローを「Active」にしたうえで、Production URLに差し替えてください。テスト時は動いたのに本番で沈黙する、という典型パターンがこれです。
タイムアウトと会話の途切れ
response_modeの選択ミス：streamingのままだとn8nはSSE形式を受け取り、パースに失敗します。blockingにしてください。- 長文生成でのタイムアウト：n8nのHTTP Requestノードは既定のタイムアウトが短めです。生成が長い場合はOptionsからTimeoutを60秒以上に延ばします。
- 会話が毎回リセットされる：Difyのレスポンスに含まれる
conversation_idを保存して次回リクエストに渡さないと、文脈は引き継がれません。1問1答の用途なら空のままで問題ありません。
料金の実費試算と「連携しない」という選択肢
連携は無料枠のままでも試せますが、常用すると費用構造が見えてきます。
両ツールの料金（2026年7月時点）
Difyのクラウド版はSandboxが無料で、メッセージクレジット200・APIコール5,000回/月の制限つきです。Professionalは年額590ドル（月額換算約49ドル）でクレジット5,000/月、DifyのAPIレート制限が撤廃されます（出典: Dify公式料金ページ）。n8nはクラウドのStarterが月額20ユーロ（年払い）で2,500実行まで。セルフホストのCommunity Editionはソフト自体が無料で、サーバー代のみで運用できます（出典: n8n公式料金ページ）。なお2026年時点のn8nは、実行回数のみが課金対象でワークフロー数やユーザー数は無制限です。
月300件処理する場合のざっくり試算
問い合わせ自動応答を月300件さばく前提で、編集部で構成別に費用を比べました。ポイントは、n8nの課金単位が「ステップ数」ではなく「ワークフロー実行回数」だという点です。1実行の中でノードを10個並べても、消費は1実行のままです。
| 構成 | 月額のめやす | 向いている人 |
|---|---|---|
| Dify Sandbox + n8n Community（セルフホスト） | サーバー代のみ（約5ドル前後） | 検証・個人利用。ただしDifyのクレジット200は試用向けで、常用には足りない |
| Dify Professional + n8n Community | 約49ドル + サーバー代 | 実務で常用する個人・小規模。最もコスパが良い構成 |
| Dify Professional + n8n Starter | 約49ドル + 約20ユーロ | サーバー管理をしたくないチーム |
300件はn8n Starterの2,500実行に対して十分余裕があります。したがって実務で最初に効いてくるのはn8nの実行回数ではなく、Difyのメッセージクレジットです。増やすべきはDify側、と覚えておくと選択を誤りません。
逆説的アドバイス：連携しないほうが早い場合
正直なところ、次に当てはまるなら2ツールを繋ぐ必要はありません。構成が増えるほど、障害時の切り分けは確実に重くなります。
- やりたいことが「単発のテキスト生成」だけ：n8nには各LLMを直接呼ぶノードがあります。Difyを挟まずn8n単体で完結させたほうが速いです。
- 社内資料へのQ&Aだけが目的：Difyのナレッジ機能だけで足ります。まずはDifyの使い方入門（ノーコードでAIアプリを作る方法）から始めるほうが、遠回りに見えて確実です。
- チームに管理者が1人もいない：セルフホストのn8nはアップデートと監視が発生します。運用の担い手が決まっていないなら、クラウド版から入るほうが結果的に安く済みます。
逆に、「プロンプトを頻繁に直したい」かつ「連携先が3つ以上ある」なら連携する価値は高いです。プロンプトをDifyに隔離できるので、n8nのワークフローを壊さずにAIの挙動だけ改善できます。n8n単体の基本操作はn8nの使い方入門（AI業務自動化ワークフローの作り方）を参照してください。
まとめ：方向を決めてから、小さく繋ぐ
Difyとn8nの連携は、「考えるのはDify、運ぶのはn8n」という分担さえ押さえれば構成はシンプルです。実務の入口はほぼ方向1（n8n → Dify）で、https://api.dify.ai/v1/chat-messages にHTTP Requestノードから Bearer 付きで投げるだけで動きます。つまずいたときは、401ならBearerとキーの種類、無反応ならTest／Production URLの取り違え、途中で切れるなら response_mode とタイムアウトを順に確認してください。
費用面では、n8nの実行回数より先にDifyのクレジットが上限に当たります。まずはDify Sandboxとローカルのn8nで1本だけ動かし、業務で使えると確信してからDify Professionalに上げる。この順番が、無駄な課金を避けつつ確実に進める方法です。
