2026.11.06 自動化

n8n Dify 違い：業務連携のn8nとLLMアプリのDifyの選び分けとAPI併用の構成

n8nとDifyの違いは、何を起点に組み立てるかにあります。n8nはSaaSや社内システムをつなぐ業務の流れが起点で、AIはその途中の1工程です。DifyはチャットやRAGなどLLMアプリが起点で、外部連携はアプリを構成する部品という位置づけです。この記事では、両者を設計・ライセンス・料金の軸で比べたうえで、どちらに任せるかの判断基準を示します。後半では、n8nからDifyのワークフローAPIを呼ぶ構成と、DifyからWebhookでn8nを起動する構成を、curlの例つきで解説します。版番号と料金は2026年11月6日時点の公式情報です。

まとめ：n8nとDifyの違いは起点の差で、迷う業務は役割を分けて併用する

受注データの転記や通知、承認後のシステム登録のように、複数のシステムを決まった順に動かす処理はn8nに任せます。社内向けの問い合わせチャットやナレッジ検索のように、利用者がAIと対話する画面が要る処理はDifyに任せます。

両方の性格を持つ業務では、片方に寄せず役割で分けます。AIの判断部分はDifyのワークフローとして作り、n8nのHTTP RequestノードからAPIで呼ぶ形が組みやすい構成です。逆に、Difyのチャットから業務システムへ書き込むときは、DifyのHTTPリクエストノードでn8nのWebhookを呼びます。どちらの向きでも、認証トークンと応答の待ち方を最初に決めておくと、本番で詰まりません。

n8nとDifyの違いを設計の起点・実行単位・ライセンス・料金の軸で比べる

n8n単体の機能と導入方法はn8nとは？読み方・料金・商用利用の範囲と3.0で変わる始め方で解説しています。ここでは比較に必要な差分だけを扱います。

業務の流れを起点に組むn8nとLLMアプリを起点に組むDifyの設計の差

n8nのワークフローは、トリガーで始まり、ノードを順につないで外部サービスを操作します。AI Agentノードも数あるノードの1つです。処理の主役はデータの受け渡しで、AIは分類や要約などの1工程を担います。

Difyは、チャットボット・ワークフロー・エージェントといったアプリの種別を選ぶところから始まります。モデルの切り替え、プロンプト、ナレッジ（RAG）の管理画面を最初から持ち、作ったアプリはWeb画面・API・MCPサーバーとして公開できます。外部連携はHTTPリクエストノードやツールで補う位置づけです。

つまり、n8nは「業務の手順書を自動化する道具」、Difyは「AIアプリを作って配る道具」と捉えると、選び分けの判断がぶれません。

n8n 2.46系とDify 1.19系で比べる機能・ライセンス・料金の対応表

2026年11月6日時点で、GitHubのn8nのリリース一覧では[email protected]が最新の安定版（11月4日公開）です。Difyのリリース一覧ではv1.19.0が最新（11月4日公開）です。

比較項目	n8n	Dify
設計の起点	業務の流れ（トリガーとノード）	LLMアプリ（会話・ワークフロー・エージェント）
外部からの起動	Webhookノード・スケジュールなど	API・Webhook起動（ワークフロー限定）
利用者向けの画面	Chat Triggerなど限定的	Web公開画面とナレッジ管理を標準で持つ
ライセンス	Sustainable Use License	Apache 2.0の改変版
クラウド版の課金単位	ワークフローの実行回数	メッセージクレジットとワークスペース
安定版（11月6日時点）	2.46.6	1.19.0

実務で差が出るのは、課金単位と利用者向け画面の2行です。n8nはプランごとの月間実行数で上限が決まるため、ノードの数よりも起動の回数で見積もります。Difyは、利用者がAIとやり取りする回数に比例して費用が増える前提で見積もります。

n8nとDifyの商用利用で比べるライセンスの制約と受託開発の注意点

n8nのLICENSE.md（Sustainable Use License 1.0）は、利用と改変を「自社の内部業務目的」か非商用・個人利用に限っています。配布や第三者への提供も、無償かつ非商用の場合に限るという条件です。社内業務の自動化に使う分には問題になりにくい一方、n8nを組み込んだ機能を顧客に有償で提供する場合は別契約の検討が要ります。

DifyのLICENSEはApache 2.0を改変したもので、他のアプリケーションのバックエンドとしての商用利用を明記して認めています。追加の制約は2点です。書面の許可なくマルチテナント環境を運用できないこと（1テナントは1ワークスペースと定義）、コンソールやアプリのロゴと著作権表示を削除・変更できないことです。ロゴの制約は、Difyのフロントエンドを使わない利用には適用されません。

受託開発の観点では、顧客ごとにワークスペースを分けて1つのDifyで複数顧客を収容する構成が、マルチテナントの制約に触れやすい箇所です。

クラウド版の料金をn8nの実行数とDifyのメッセージクレジットで比べる

n8nの料金ページでは、年払いの月額がStarter 20ユーロ（月2,500実行）、Pro 50ユーロ（月1万実行）です。Business（月額667ユーロ・月4万実行）はセルフホスト専用と記載されています。

Difyの料金ページでは、Professionalが1ワークスペースあたり年590ドルで、月5,000メッセージクレジット・メンバー3人・アプリ50個です。Teamは年1,590ドルで、月1万クレジット・メンバー50人・アプリ200個まで広がります。無料のSandboxは200クレジット・アプリ5個で、検証用と割り切る規模です。

両方をクラウドで契約すると、固定費は二重にかかります。併用するなら、片方をセルフホストにするか、Dify側をAPI呼び出し専用にしてメンバー数を抑えるのが現実的です。

n8nに任せる業務とDifyに任せる業務を入口と出口の形で見分ける基準

判断は「処理が何で始まり、結果をどこへ返すか」で行います。入口と出口が業務システムならn8n、入口か出口に人とAIの対話があるならDifyです。

SaaSや社内システムを決まった順に動かす処理をn8nに任せる条件

次のいずれかに当てはまる処理は、n8nを主にします。

kintoneやSalesforceの更新をきっかけに、会計や在庫のシステムへ転記する
夜間に複数のAPIからデータを集め、整形してスプレッドシートやDBへ書き込む
承認の結果に応じて、メール送信・チャット通知・チケット起票を分岐させる
1回の実行で数十件のレコードを順に処理し、失敗した件だけ再実行したい

このような処理では、AIは問い合わせの分類や文面の下書きなど一部にとどまります。n8nのAI Agentノードで足りる範囲なら、Difyを足す必要はありません。AI Agentノードの組み方はn8n AIエージェント：AI Agentノードのツール接続と人の承認を挟む作り方で扱っています。

チャット画面やナレッジ検索を利用者に渡す処理をDifyに任せる条件

社員や顧客がブラウザでAIに質問し、社内文書を根拠に答えさせる用途はDifyが向きます。ナレッジの登録、チャンクの設定、回答の評価までをDifyの管理画面で完結できるためです。種別の選び方とナレッジの設定はDifyでチャットボットを作る手順にまとめています。

プロンプトやモデルを業務担当者が自分で直したい場合も、Difyを選びます。n8nで同じことをすると、ワークフローの編集権限を業務担当者に渡すことになり、他のノードまで触れる状態になります。

n8nとDifyのどちらか一方で済ませて失敗しやすい2つの構成パターン

1つ目は、Difyのワークフローに業務システムへの書き込みを何段も並べる構成です。HTTPリクエストノードで書き込みはできますが、10件のシステム連携を並べると、認証情報の管理とエラー時の再実行が煩雑になります。書き込みが3段を超えたら、n8nへ切り出す目安にします。

2つ目は、n8nのChat Triggerで社内向けのナレッジチャットを作り込む構成です。会話履歴やナレッジ更新の画面を自前で用意することになり、Difyなら標準で付いてくる機能を作り直す結果になります。

n8nからDifyのワークフローAPIを呼び出す実装手順と応答待ちの注意点

AIの判断部分をDifyで作り、n8nの業務フローから呼ぶ構成です。Difyのワークフローの作り方自体はDifyワークフローの作り方と使い方を参照してください。

DifyでAPIキーを発行しcurlでワークフロー実行APIの応答を確かめる手順

DifyのAPI入門ガイドによると、APIキーはアプリの中で作成し、そのアプリだけに有効です。キーはバックエンドからのみ使い、フロントエンドのコードに埋め込まないよう警告されています。Run WorkflowのAPI仕様では、エンドポイントはPOST /workflows/run、Dify Cloudのベースはapi.dify.ai/v1です。n8nに組み込む前に、curlで応答を確かめます。

curl -X POST 'https://api.dify.ai/v1/workflows/run' \
  -H "Authorization: Bearer $DIFY_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {"inquiry": "請求書を再発行してほしい"},
    "response_mode": "blocking",
    "user": "n8n-inquiry-flow"
  }'

inputsのキーは、Difyのワークフローで開始ノードに定義した変数名と合わせます。userはアプリ内で利用者を区別する識別子で、n8nから呼ぶ場合はワークフロー名などの固定値で構いません。応答にはworkflow_run_idと、data.outputsに終了ノードの出力が入ります。セルフホストの場合は、ベースURLを自社のDifyのAPIのURLに置き換えてください。

n8nのHTTP RequestノードにBearer認証とinputsを渡す設定の手順

curlで通った内容を、n8nのHTTP Requestノードに移します。

MethodをPOST、URLにDifyの/workflows/runのURLを入れる
AuthenticationでGeneric Credential Typeを選び、Header authの資格情報を作る（NameはAuthorization、ValueはBearerとAPIキー）
Send Bodyをオンにし、Body Content TypeをJSON、指定方法をUsing JSONにする
本文にinputs・response_mode・userを書き、前段の値は式で埋める
OptionsのTimeoutをミリ秒で指定し、Difyの処理時間より長くとる

APIキーを本文やURLに直書きせず資格情報に入れておくと、キーを再発行したときに資格情報の1か所を直すだけで済みます。後続のノードではdata.outputsの中身を参照して分岐させます。

Dify Cloudのエッジプロキシで切れる長時間実行をstreamingで避ける設計

Run Workflowの仕様には、Dify Cloudでは応答がエッジプロキシのタイムアウト内に返らないと接続が切られうる、という注意があります。response_modeを省略するとblockingになるため、ナレッジ検索や複数回のLLM呼び出しを含む重いワークフローでは、この切断に当たります。

対策は2つあります。処理が短いうちはblockingのまま使い、長くなったらstreamingに切り替えて、ノードの実行ごとに届くイベントの最後で結果を受け取る方法です。もう1つは、Dify側の最後にHTTPリクエストノードを置き、結果をn8nのWebhookへ送り返す非同期の形です。n8n側は「依頼を投げるワークフロー」と「結果を受けるワークフロー」に分かれますが、待ち時間の制約から外れます。実行の途中経過はworkflow_run_idで後から引けるので、ログに残しておくと障害時の追跡に使えます。

DifyからWebhookでn8nのワークフローを起動し業務システムへ書き込む構成

チャットで受けた依頼を、n8n経由で業務システムに登録する向きの構成です。Difyは会話と判断、n8nは書き込みと通知を受け持ちます。

n8nのWebhookノードでHeader authと応答を返す時点を決める設定

n8nのWebhookノードは、テスト用URLと本番用URLを別々に発行し、本番用はワークフローを公開した時点で登録されます。認証はBasic auth・Header auth・JWT auth・Noneなどから選べます。Difyから呼ぶなら、共有の秘密値をヘッダーで照合するHeader authが設定しやすい方式です。Pathは既定でランダムな文字列が入ります。

応答の返し方（Respond）は、DifyのチャットでAIが結果を伝える必要があるかで選びます。登録の完了を待たずに受付だけ返すならImmediately、登録した伝票番号をDifyに返したいならWhen Last Node FinishesかRespond to Webhookノードです。最大ペイロードは既定で16MBで、セルフホストではN8N_PAYLOAD_SIZE_MAXで変更できます。公開前に、curlで本番用URLへの受信を確かめます。

curl -X POST '<WebhookノードのProduction URL>' \
  -H 'X-Webhook-Token: <Header authに設定した値>' \
  -H 'Content-Type: application/json' \
  -d '{"customer_id": "C-1024", "request": "請求書再発行", "source": "dify"}'

ヘッダー名と値は、n8nのHeader authの資格情報に登録したものと一致させます。わざと誤った値で送り、拒否されることまで確かめてからDify側の設定に進みます。

DifyのHTTPリクエストノードでn8nを呼ぶ認証とリトライ回数の設定

DifyのHTTPリクエストノードの認証は、No AuthとAPI Key（Basic・Bearer・Custom）です。n8nのHeader authに合わせるなら、API KeyのCustomでヘッダー名にX-Webhook-Tokenを指定します。ボディはJSONを選び、会話から抽出した変数を埋め込みます。

失敗時のリトライは最大10回、間隔は最大5,000ミリ秒まで設定できます。業務システムへの登録は重複すると困るため、リトライを有効にするならn8n側でcustomer_idと依頼内容による重複チェックを入れてください。リトライを使わず、失敗時の別経路で「登録できなかった」とチャットに返す設計のほうが安全な場面も多くあります。

Dify側から定期実行や外部イベントで処理を始めたい場合は、ワークフローアプリに限ってWebhookトリガーが使えます。受け付けるメソッドとContent-Typeが一致しないリクエストは拒否されるため、n8nから呼ぶ側の設定とそろえます。

MCPで相互につなぐ場合のDifyのMCPサーバー公開とn8nの受け口

APIとWebhookの代わりにMCPでつなぐ方法もあります。DifyはアプリをMCPサーバーとして公開でき、既定では無効です。発行されるURLに認証情報が含まれるため、APIキーと同じく扱い、漏えいが疑われたら再生成します。再生成すると旧URLは即座に無効になります。

n8n側にはMCP Server TriggerとMCP Client Toolがあり、設定と権限の分け方はn8n MCP：MCP Server TriggerとClient Toolの設定とAIに渡す権限の設計で解説しています。ただし、固定の業務処理を呼ぶだけならHTTPのほうが単純で、障害時の切り分けも容易です。MCPは、AIに呼ぶツールを選ばせたい場合に限って選びます。

受託開発でn8nとDifyの併用を採用する条件と片方に絞って見送る場面

併用は強力ですが、運用する仕組みが2つに増えます。採用するかは、運用コストを上回る分担の効果があるかで決めます。

AIの判断と業務システム連携の両方が3つ以上の工程を持つ業務の併用

併用を採用するのは、AI側も業務連携側も、それぞれ単独で3工程以上の処理を持つ場合です。例えば、問い合わせを分類しナレッジで回答案を作り担当者の確認を挟む部分（Dify）と、顧客台帳の照会・チケット起票・期限管理の通知を行う部分（n8n）が並ぶ業務を想定しています。プロンプトの改善は業務担当者がDifyで、システム連携の保守は開発者がn8nで、と担当を分けられることも利点です。

セルフホストでそろえる場合は、両方を同じネットワーク内に置き、Webhookを外部へ公開しない構成にできます。n8nの構成はn8n docker：Composeで建てる本番構成、Difyのサーバー構築はDifyをAWS EC2に構築しBedrockへIAMロール接続する手順が参考になります。

AIや連携の工程が少ない業務で併用を見送り片方に寄せる判断の基準

AIの工程が要約や分類の1回だけなら、n8nのAI Agentノードで完結させ、Difyは入れません。逆に、業務システムへの書き込みが1〜2件だけのチャットボットなら、DifyのHTTPリクエストノードで済ませます。どちらの場合も、仕組みを2つ持つ保守費と、クラウド版なら二重の固定費が効果を上回ります。

迷ったら、まず片方で作り、限界が見えた工程だけを切り出してください。社内の業務フローにAIエージェントを組み込む設計から相談したい場合は、RPA×AIエージェント連携（インテリジェントオートメーション）で、n8nとDifyの分担を含めた構成をご提案しています。

よくある質問：n8nとDifyの比較で多い無料利用・併用・移行の疑問

n8nとDifyの比較で検索されることの多い質問に答えます。

n8nとDifyはどちらも無料で使えますか？

どちらもセルフホストなら、ソフトウェア自体の利用料はかかりません。ただし、n8nは自社の内部業務目的か非商用の利用に限られ、Difyはマルチテナント運用とロゴの改変に制約があります。クラウド版では、Difyに無料のSandbox（200メッセージクレジット）があります。n8nのクラウド版は有料プランが中心で、年払いのStarterが月20ユーロです。サーバー代とLLMのAPI利用料は別にかかります。

n8nとDifyを併用するときはどちらから呼ぶのが基本ですか？

業務の起点がシステム側にあるならn8nからDifyを呼び、起点が利用者との会話にあるならDifyからn8nを呼びます。受注の登録をきっかけにAIで内容を確認するならn8n→Dify、チャットで受けた依頼を台帳に登録するならDify→n8nです。両方向を同じ業務で使う場合は、呼び出しが循環しないよう、どちらが処理の主導権を持つかを決めておきます。

DifyだけでもSaaSとの連携はできますか？

できます。HTTPリクエストノードで任意のAPIを呼べ、マーケットプレイスのツールやプラグインでも主要なSaaSとの接続も可能です。ただし、認証方式はNo AuthとAPI Key系に限られ、多数のシステムを順に更新する処理や、失敗した件だけ再実行する運用はn8nのほうが組みやすくなります。連携先が2〜3件までならDifyだけで進めて問題ありません。