【Dify×n8n連携】AIワークフローを24時間完全自動化する構築手順！API呼び出しから外部通知まで徹底解説

AIワークフローを直感的に構築できる「Dify」は非常に強力なツールですが、実際に運用してみると「毎回ブラウザを開いて手動で実行するのが手間」「外部サービスのイベント（Webhook）や柔軟なスケジュールをトリガーにして、裏側で24時間自動稼働させたい」という壁にぶつかることが少なくありません。

その課題を根本から解決するのが、オープンソースのワークフロー自動化ツール「n8n」とのAPI連携です。Difyを「AIの頭脳（思考・文章生成エンジン）」とし、n8nを「手足（トリガー検知・データ取得・外部ツールへの入稿や通知）」として組み合わせることで、人間の手を介さない完全自動のAIパイプラインを構築できます。

本記事では、n8nの「HTTP Request」ノードからDifyのAPIを呼び出す具体的な設定手順から、コピペで使えるJSONリクエスト例、連携時につまずきやすいエラーの解決策までを順を追って解説します。

なぜ「Dify × n8n」が個人開発・メディア自動化の最適解なのか？

AIを活用した自動化基盤を作る際、Dify単体で完結させようとすると「外部との入出力」で限界が生じやすく、逆にn8n単体で複雑なプロンプトチェーンやRAG（ナレッジ検索）を組もうとすると管理が煩雑になりがちです。この2つを役割分担させることで、それぞれの強みを最大化できます。

Dify単体（チャット・手動実行）の限界とn8nが補う「トリガー・外部連携力」

Difyは、LLM（大規模言語モデル）の切り替えやプロンプトの変数管理、ナレッジベース（RAG）の構築、条件分岐を含むAIワークフローの設計において非常に優れたUIを持っています。しかし、Dify標準の機能だけでは以下のような運用が困難です。

多様なトリガーによる自動起動：「毎朝7時に自動実行する」「Googleフォームや外部Webhookを受信した瞬間に起動する」「RSSフィードの更新を検知して動かす」といった柔軟なトリガー管理。
数百種類の外部SaaSとの標準連携：生成したテキストをそのままmicroCMSやWordPressへ自動入稿したり、Slack・Discord・Gmail・Googleスプレッドシートへ複雑な加工を加えて振り分けたりする処理。
エラー時のリトライや待機制御：APIのレート制限（429エラー）を考慮したウェイト処理や、大量データのループ処理（バッチ実行）。

ここで「n8n」を前後に配置すると、n8nが数多くの外部サービスからデータを集めてDifyのAPIへ投げ、Difyが生成した高精度な出力結果を再びn8nが受け取って各ツールへ自動反映する、という一気通貫の自動化が実現します。

「GAS × Dify」と「n8n × Dify」の使い分け基準

DifyのAPIを外部から叩く方法としては、Google Apps Script（GAS）を使うアプローチもあります。当メディアでも、スプレッドシート上のデータを処理する手軽な方法としてDifyのAPIをGASから叩いてスプレッドシート上でAI自動化する手順を解説しました。

しかし、処理の規模や用途によって「GAS × Dify」と「n8n × Dify」には明確な向き・不向きがあります。以下の比較表を参考に、目的に合った構成を選択してください。

比較項目	GAS × Dify連携	n8n × Dify連携（本記事の構成）
向いている用途	スプレッドシート完結の少量データ処理・手動ボタン実行	複数ツールの横断連携・24時間無人稼働・大量ループ処理
実行時間の制限	1回の実行あたり最大6分で強制終了	制限なし（セルフホスト環境の場合、長時間の生成も待機可能）
フローの視認性・保守	JavaScriptコードで記述・管理	ノーコード/ローコードのGUIノードで直感的に接続・デバッグ可能
Webhook受信・分岐	`doPost()` の実装とデプロイ更新が必要でやや煩雑	Webhookノードを置くだけで即座にテスト・本番URLを発行可能

特に、推論モデル（思考時間の長いLLM）や複数ステップのワークフローをDify側で動かす場合、1件あたりの応答に30秒〜1分以上かかることがあります。GASでは数件ループさせただけで「6分制限エラー」に抵触しやすいため、本格的なバックグラウンド自動化には実行時間制限のないn8nとの連携が適しています（※GASの6分制限問題そのものの仕組みと対策については、GASの「実行時間エラー」をVPS×Python等へ逃がす解決策もあわせて参照してください）。

連携の全体像と事前準備（セルフホスト環境・APIキーの発行）

実際にn8nからDifyを呼び出す設定に入る前に、今回の連携フローの全体像と、Dify側で準備しておくべき2つの項目（入力変数の確認とAPIキーの発行）を整理します。

Dify側でアプリを作成し「APIアクセス」からシークレットキーを発行する

n8nからDifyのアプリ（チャットボット、テキスト生成、またはワークフロー）を動かすには、Dify側でAPIシークレットキーを発行する必要があります。以下の手順で準備してください。

Difyの管理画面を開き、n8nから呼び出したい対象のアプリ（例：「ブログ構成案生成ワークフロー」など）を選択します。
スタジオ画面の「開始（Start）」ブロックを開き、設定されている入力フィールドの変数名（例：keyword や query など）をメモしておきます。n8nからデータを渡す際、この変数名と1文字でもズレるとエラーになります。
画面右上の「公開する（Publish）」ボタンをクリックし、最新の変更を必ず公開状態にします（※公開していない下書き変更はAPI実行時に反映されません）。
左側のサイドメニューにある「APIアクセス（API Access）」を開きます。
画面右上の「APIキー」ボタンをクリックし、「新しいシークレットキーを作成する」からキー（app-xxxxxxxxxxxx という形式の文字列）を発行して安全な場所にコピーします。
同じ「APIアクセス」画面の上部に表示されている「APIサーバー（ベースURL）」（クラウド版なら https://api.dify.ai/v1、独自ドメインのセルフホスト版なら https://あなたのドメイン/v1 など）もあわせて控えておきます。

n8nとDifyを動かすインフラ環境（VPSセルフホストの優位性）

Difyとn8nはそれぞれクラウド版（SaaS版）も提供されていますが、クラウド版の無料プランや下位プランでは「ワークフローの実行回数制限」や「同時実行数の制限」が厳しく、24時間の自動処理や定期バッチを回すとすぐに上限へ達してしまいます。

そこで個人開発やメディア運営で圧倒的にコストパフォーマンスが高いのが、月額1,000円〜2,000円前後のVPS（仮想専用サーバー）を1台借りて、Docker上でDifyとn8nの両方をセルフホスト（自前構築）する構成です。

💡 まだDify・n8nのセルフホスト環境を構築していない方へ
Dockerを使ったそれぞれの具体的な立ち上げ手順は、以下の記事でコマンド付きで詳しく解説しています。
・【脱・無料枠制限】Difyを格安VPSにセルフホスト構築する完全手順！
・【脱Zapier】n8nを格安VPSにDocker構築する完全手順！
また、Difyとn8nを同時に快適かつ安定して稼働させるには、メモリ4GB以上（推奨8GB）のVPS選びが重要です。各社のスペックと月額コストの比較は「開発・自動化におすすめのVPS 3選を徹底比較！」をご確認ください。

準備が整ったら、いよいよn8nのキャンバスを開き、DifyのAPIを叩くワークフローを組み立てていきましょう。

【実践】n8nの「HTTP Request」ノードからDify APIを叩く完全手順

ここからは、実際にn8nのワークフロー画面を開き、DifyのAPIを呼び出して結果を受け取るまでの手順を4つのステップで構築します。

STEP 1：トリガーノード（Schedule / Webhook）の配置

まずはn8nのキャンバス上で、ワークフローを起動する「きっかけ（トリガー）」となるノードを配置します。自動化の目的に合わせて、主に以下の2つから選択します。

Schedule Trigger（定期実行）：「毎日朝8時」「6時間ごと」など、決まった間隔で自動実行したい場合に使用します。GoogleスプレッドシートやRSSフィードから未処理のネタを定期的に取得してDifyへ投げる運用に適しています。
Webhook（外部イベント起動）：n8n側で専用の受信URLを発行し、外部のフォーム送信やチャットツール、別システムからのPOSTリクエストを受け取った瞬間にリアルタイムでDifyを起動したい場合に使用します。

最初は動作確認をスムーズに行うため、標準の「Manual Trigger（Test workflowをクリックしたときに実行）」または「Schedule Trigger」を置いて進めるのがおすすめです。

STEP 2：HTTP Requestノードの認証（Header Auth）とエンドポイント設定

次に、トリガーの後ろに「＋」ボタンから「HTTP Request」ノードを追加します。n8nにはコミュニティ製のDifyノードも存在しますが、標準の「HTTP Request」ノードを使う方がDify側の最新API仕様に確実に対応でき、細かなタイムアウト設定も柔軟に行えます。

HTTP Requestノードを開いたら、まず通信方式とURL（エンドポイント）、認証情報を以下のように設定します。

Method：POST を選択します。
URL：Dify側で作成した「アプリのタイプ」に応じて、ベースURLの末尾に以下のパスを結合して入力します。

Difyのアプリ種別	指定するエンドポイントURL（例）
ワークフロー（Workflow）	`https://あなたのDifyドメイン/v1/workflows/run`
チャットボット / チャットフロー	`https://あなたのDifyドメイン/v1/chat-messages`
テキスト生成（Text Generator）	`https://あなたのDifyドメイン/v1/completion-messages`

※クラウド版のDifyを使用している場合は、https://api.dify.ai/v1/workflows/run のように指定します。

続いて、同じノード内でAPIキーの認証（Header Auth）を設定します。

Authentication：Generic Credential Type を選択します。
Generic Auth Type：Header Auth を選択します。
Credential for Header Auth：「Create New Credential」を開き、以下のように入力して保存します。
- Name：Authorization
- Value：Bearer app-xxxxxxxxxxxx（※Bearer の後ろに半角スペースを1つ空けて、事前準備で取得したDifyのAPIシークレットキーを貼り付けます）

このようにCredential（認証情報）として分離して保存しておくことで、ワークフロー内にAPIキーが平文で露出するのを防ぎ、複数のノードで安全に使い回すことができます。

STEP 3：リクエストボディ（JSON）の記述と response_mode: "blocking" の重要設定

認証の設定ができたら、Difyへ渡すデータ（リクエストボディ）を設定します。HTTP Requestノードの下部にある設定を以下のように切り替えてください。

Send Body：ON（有効）にする
Body Content Type：JSON を選択
Specify Body：Using JSON を選択

表示された「JSON」の入力欄（Expressionモードに切り替えると前段ノードの変数を埋め込めます）に、以下のJSONを記述します。

▼ パターンA：Difyの「ワークフロー（/v1/workflows/run）」を呼び出す場合

{
  "inputs": {
    "keyword": "{{ $json.keyword }}",
    "target_audience": "個人ブログ運営者"
  },
  "response_mode": "blocking",
  "user": "n8n-auto-runner"
}

▼ パターンB：Difyの「チャットボット / チャットフロー（/v1/chat-messages）」を呼び出す場合

{
  "inputs": {},
  "query": "{{ $json.question }}",
  "response_mode": "blocking",
  "user": "n8n-auto-runner"
}

ここで最も重要なポイントが、"response_mode": "blocking" の指定です。DifyのAPIには、文字を少しずつリアルタイムに返却する streaming モードと、すべての処理が完了してから1つのJSONとして結果を返却する blocking モードの2種類があります。

n8nの自動ワークフローで後続のノード（Slack通知やCMS入稿など）に生成結果を綺麗に渡すには、必ず blocking を指定して一括のJSONレスポンスを受け取るようにしてください。また、user には誰からのリクエストかを識別するための任意の文字列（固定の "n8n-auto-runner" などで問題ありません）を指定します。

STEP 4：出力されたJSONから生成テキスト（answer / outputs）を抽出してSlack・microCMS等へ渡す

設定が完了したら、HTTP Requestノードの「Test step」ボタンをクリックしてテスト実行してみます。成功すると、右側のOUTPUTパネルにDifyからのJSONレスポンスが表示されます。

後続のノード（例：Slackノード、Google Sheetsノード、またはmicroCMS入稿用のHTTP Requestノードなど）でDifyが生成したテキストを取り出す際は、アプリの種別によって参照するJSONパスが異なります。

ワークフロー（/v1/workflows/run）の出力参照パス：
{{ $json.data.outputs.出力変数名 }}
※たとえばDifyの「終了（End）」ブロックで出力変数名を result_text に設定している場合は、{{ $json.data.outputs.result_text }} でテキストを抽出できます。
チャットボット / テキスト生成の出力参照パス：
{{ $json.answer }}

n8nの画面では、右側のOUTPUTパネルに表示されている目的の項目を、次のノードの入力欄へドラッグ＆ドロップするだけで上記の式（Expression）が自動挿入されます。抽出したテキストをそのままSlackへ通知したり、microCMSのAPIを用いたメディア自動省力化の仕組みへ流し込んだりすることで、生成から入稿・通知までが完全に自動化されます。

Dify × n8n連携でよく起きるエラーと解決策（トラブルシューティング）

実際にn8nからDifyのAPIを叩いてみると、設定のわずかな食い違いやインフラ環境（Docker）の仕様によってエラーが発生することがあります。現場で頻出する2大トラブルと解決策をまとめました。

400 Bad Request / inputs is required が出る原因と対処法

HTTP Requestノードの実行時に 400 Bad Request（inputs is required や invalid_param など）が返ってくる場合、原因は主に以下の3つです。

Dify側の「開始」ブロックの変数名とJSONのキー名が一致していない：
Difyのワークフロー側で必須（Required）に設定している入力変数（例：topic）が、n8nから送る "inputs": { ... } の中に含まれていないか、スペルが異なっています。Difyのスタジオ画面で変数名を再確認してください。
Difyのワークフローを変更した後に「公開（Publish）」していない：
Difyの画面上で入力変数を追加・変更しても、右上の「公開する」ボタンを押さない限り、API側の仕様は古いままです。修正後は必ずPublishを実行してください。
前段ノードのテキストに「改行」や「ダブルクォーテーション」が含まれておりJSONが壊れている：
長文のテキストを "{{ $json.text }}" のように直接ダブルクォーテーションで囲んで埋め込むと、テキスト内の改行コードや引用符によってJSON構文エラーが発生します。長文を渡す場合は、波括弧の外側のクォーテーションを外し、{{ JSON.stringify($json.text) }} と記述することで安全にエスケープ処理されます。

同一VPS（Docker）内で localhost や外部URLが繋がらない・タイムアウトする場合の対策

1台のVPS上でDifyとn8nの両方をDockerコンテナとして動かしている場合、通信先URLの指定方法や待ち時間の設定でつまずくケースがあります。

localhost を指定して ECONNREFUSED になる場合：
n8nコンテナの中から http://localhost/v1/... を指定すると、Difyではなく「n8nコンテナ自身」を見に行ってしまうため接続が拒否されます。独自ドメイン（https://dify.example.com/v1/...）経由でアクセスするか、Dockerのホストゲートウェイ（http://host.docker.internal/v1/... 等）または共通Dockerネットワーク上のコンテナ名を指定してください。
Difyの生成中にn8n側やCloudflare側がタイムアウトする場合：
Dify側で複数のLLMノードやWeb検索を繋いだ重いワークフローを実行すると、応答完了までに1分〜数分かかることがあります。HTTP Requestノード下部の「Add Option」から「Timeout」を追加し、ミリ秒単位で長めの値（例：180000 ＝3分、300000 ＝5分）を設定しておくと、n8n側での途中切断を防げます（※ドメインにCloudflareのプロキシを通している場合は、Cloudflare側の100秒タイムアウト制限を避けるため、同一VPS内のローカルIPや内部ネットワーク経由でAPIを叩く構成も有効です）。

まとめ：Difyの「頭脳」とn8nの「手足」を繋いで24時間自動化を実現しよう

本記事では、AIアプリ開発基盤「Dify」とワークフロー自動化ツール「n8n」をAPI連携させ、24時間無人で稼働するAI自動化パイプラインを構築する手順を解説しました。

役割分担：プロンプト管理やRAG・AI思考フローは「Dify」に任せ、定期起動・Webhook受信・外部SaaSへの連携は「n8n」が担うことで、保守性の高い自動化基盤が作れる。
実装の核心：n8nの「HTTP Request」ノードで Header Auth（Bearer APIキー）を設定し、JSONボディに "response_mode": "blocking" を指定して一括レスポンスを受け取る。
長文・長時間対策：変数埋め込み時は JSON.stringify() で構文崩れを防ぎ、重いワークフローではHTTP Requestノードのタイムアウト値を延長しておく。

Difyとn8nを連携させた自動化基盤は、一度構築してしまえば、毎日の情報収集・記事ドラフト生成・SNS投稿案の作成・データ整形などをバックグラウンドで黙々と処理し続けてくれます。

なお、この「Dify × n8n」の2大ツールを実行回数無制限・維持費最小限でフル稼働させるには、メモリに余裕のあるVPS環境でのセルフホスト運用が欠かせません。「どのVPSを選べばDifyとn8nを同時にサクサク動かせるか知りたい」という方は、以下の徹底比較ガイドを参考に最適なサーバー環境を整えてみてください。