n8nとDifyの違いと使い分け｜料金・無料の範囲と、2つを連携して業務に組み込む手順

n8nとDifyの違いを一言でいうと、n8nはシステム同士をつなぎ、決まった手順を自動で流すワークフロー自動化ツール、DifyはLLM（大規模言語モデル）を使ったチャットボットやAIアプリを作る基盤です。役割が違うため、どちらか一方を選ぶ場面よりも、n8nが業務の流れを組み、その途中でDifyのAIを呼ぶ形で組み合わせる場面が多くあります。

どちらも無料で始められます。Difyはクラウドの無料プランとセルフホストの無料版があり、n8nもセルフホストの無料版とクラウド版の無料トライアルがあります。有償のプランでは、DifyはAIへの問い合わせの回数、n8nはワークフローを動かした回数で料金が決まります。

関連記事：n8nとは？できること・料金・使い方と、業務自動化を本番で回す前に決めること

この記事の料金と利用条件は2026年9月時点の情報です。変わりやすいため、契約の前にはDifyの料金ページとn8nの料金ページで最新の内容をご確認ください。

n8nとDifyの違いを一言で

n8nが受け持つのは「いつ動かし、どのシステムからデータを取り、どこへ渡すか」です。毎朝の定時の起動、フォームの受信、別のシステムからの呼び出しをきっかけに、ノードと呼ぶ部品を順につないで処理を進めます。つなぐ先は、表計算シート、チャット、顧客管理や会計のシステムなどです。

Difyが受け持つのは「AIに何を読ませ、何を聞き、どう答えさせるか」です。社内文書を登録するナレッジベース、プロンプトの編集、答えを返すチャット画面を1つの画面で作れます。社内文書を検索して、その内容をもとにAIに答えさせる仕組みをRAG（検索拡張生成）と呼び、Difyはこれを画面の操作で組めるのが強みです。

n8nは業務の流れを組む道具、DifyはAIとのやり取りを作り込む道具と考えると、どちらを当てるかを決めやすくなります。

比較表：目的・機能・連携・RAG・デプロイ・料金

n8nとDifyを6つの観点で並べると、次のようになります。

違いが大きいのは、連携とRAGの2行です。n8nはつなぐ先の広さで勝り、DifyはAIに社内文書を読ませて答えさせる部分の作り込みで勝ります。

料金の数え方の違いも、見積もりに効きます。n8nは途中のノードの数やAIを呼ぶ回数では料金が増えませんが、Difyは問い合わせの回数がそのまま費用になります。1件の処理でAIを何回呼ぶかを先に数えておくと、どちらのプランが足りるかを見誤りにくくなります。

料金と無料で使える範囲

n8nとDifyは、どちらも無料で使い始められます。ただし、無料で使える範囲の考え方が違います。

Difyの料金プラン

Difyのプランは、次のとおりです。

表の上の3行はクラウド版、Community Editionはセルフホストで使う版です。値はDifyの料金ページで確かめたものです。

無料プランのSandboxは、メッセージクレジットが200で、アプリも5個までです。試作や操作の確認には足りますが、社内で毎日使うチャットボットを動かし続けるには足りません。業務で使い続けるなら、有償のプランか、セルフホストのCommunity Editionのどちらかを選ぶことになります。

n8nの料金プラン

n8nのプランは、次のとおりです。料金は年払い時の月額で、値はn8nの料金ページで確かめたものです。

クラウド版には無料トライアルがあり、クレジットカードを登録せずに試せます。トライアル中は実行が1,000回までに制限されています。n8nの実行回数は途中でDifyを何回呼んでも1回と数えるため、組み合わせる場合は、Difyのメッセージクレジットがどれだけ減るかを先に見積もります。

商用で使うときのライセンスの違い

セルフホストの無料版は、どちらもソースコードが公開されていますが、一般的なオープンソースとは条件が違います。社内の業務に使う範囲なら、どちらも制約に当たることはまれです。気をつけるのは、顧客向けのサービスに組み込むときです。

DifyのGitHubに置かれたライセンスは、Apache License 2.0に追加の条件を付けたものです。追加の条件は次の2つです。

1. Difyの書面の許可なく、複数の顧客に1つの環境を貸す形のサービス（マルチテナント環境）を運用できない
2. Difyのフロントエンド（画面）を使う場合、画面のロゴと著作権の表示を消したり変えたりできない

n8nは「Sustainable Use License」という独自の条件で、自社の業務のために使う範囲で無料です。n8nの利用条件のページでは、n8nを基盤にして顧客にワークフローを作らせるサービスや、n8nの表示を外して自社製品として提供する使い方を認めていません。顧客向けの製品にどちらかを組み込む計画があるなら、設計の前にそれぞれの利用条件を確かめ、判断がつかなければ開発元に問い合わせます。

どちらを選ぶか：業務別の使い分け（具体例3件）

使い分けの目安は、無人で動く裏側の処理ならn8n、社員や顧客が話しかけるAIアシスタントならDifyです。どちらか1つで済む業務もあれば、両方を組み合わせる業務もあります。

社員が話しかける仕組みはDifyから作る

社内規程の質問に答えるチャットボットでは、答えの質を決めるのは、どの文書をナレッジベースに入れ、どう分けて登録するかです。ここを画面で調整しながら作れるのがDifyの利点で、n8nで同じものを組むと、検索の仕組みまで自分で作ることになります。

n8nを足すのは、チャットの外で何かを動かしたいときです。たとえば、ナレッジで答えられなかった質問を表に記録する、担当部署へ知らせて回答を依頼する、といった処理です。

関連記事：社内RAGの回答精度が上がらないときに見る順番｜検索の当て外れと、元の文書側の直し方

決まった流れの途中でAIを使うならn8nから作る

問い合わせの振り分けや議事録の要約の共有のように、きっかけと行き先が決まっている業務は、n8nを起点にします。AIが受け持つのは流れの途中の「読んで分類する」「要約する」の1工程だけです。

この場合、AIの部分をDifyに置くか、n8nのAIのノードで済ませるかを選べます。プロンプトを業務の担当者が自分で直したい、社内文書を検索させたい、という事情があればDifyに置くと、n8nのワークフローに触れずにAIの答え方だけを直せます。

AIが要らない業務にDifyを入れない

複数のシステムの間で顧客情報や受注のデータをそろえる業務は、決まった手順で済むことがほとんどです。ここにAIを入れると、毎回同じ結果にならない部分が増え、原因探しが難しくなります。AIを使うのは、人が読んで判断していた箇所だけに絞ります。

関連記事：AIエージェントにどこまで任せるか｜工程を通常のプログラム・AI・人の承認に仕分ける基準

n8nとDifyを連携する手順

n8nとDifyは、互いのAPIとWebhookを使ってつなげます。つなぎ方は2方向あります。

• n8nのHTTP RequestノードでDifyのAPIを呼ぶ（n8nが起点）
• DifyのワークフローからWebhookでn8nを動かす（Difyが起点）

Difyのワークフローをn8nから呼ぶ

n8nを起点にする場合は、DifyのアプリをAPIとして公開し、n8nのHTTP Requestノードから呼び出します。手順は次のとおりです。

1. Difyで要約や分類をするアプリを作り、アプリの「API Access」の画面でAPIキーを発行する。キーはアプリごとに発行される
2. n8nにトリガーを置く。問い合わせフォームの受信や、Schedule Triggerでの定時の起動がこれに当たる
3. HTTP Requestノードを置き、メソッドをPOST、URLをDifyのAPIの宛先にする。Difyのワークフローのアプリなら /v1/workflows/run、チャットのアプリなら /v1/chat-messages を呼ぶ
4. ヘッダーに Authorization: Bearer <APIキー> を入れる。キーは本文に直接書かず、n8nの認証情報（Credential）に登録して使う
5. ボディはJSONで送る。ワークフローのアプリなら inputs にDifyの入力欄の名前と値を入れ、response_mode と、呼び出し元を区別する user を付ける
6. 返ってきた結果をIFノードやSwitchノードで見て、分類ごとに処理を分ける。Difyが返したJSONの中から、使う項目を取り出して次のノードへ渡す
7. 表への記録やチャットへの通知をつなぐ。失敗したときはHTTP Requestノードの再試行の設定でやり直し、それでも失敗したら担当者へ知らせる

Difyのアプリの「API Access」の画面に、そのアプリで呼ぶ宛先と送るJSONの例が出るため、それを見ながらn8n側の設定を書くと、項目名の書き間違いを減らせます。

DifyからWebhookでn8nを動かす

Difyを起点にする場合は、n8nのWebhookノードで受け口を作り、DifyのワークフローのHTTP Requestノードから呼びます。チャットボットで受けた依頼をもとに、社内のシステムへの登録や通知をn8nに任せたいときの形です。

1. n8nでWebhookノードを置き、メソッドをPOSTにする。Webhookノードには試しに動かすとき用のURL（Test URL）と本番用のURL（Production URL）がある
2. Webhookノードの後ろに、受け取ったデータで行う処理（表への記録、チャットへの通知など）をつなぐ
3. Difyに処理の結果を返すなら、Webhookノードの「Respond」の設定で「Using ‘Respond to Webhook’ Node」を選び、流れの最後にRespond to Webhookノードを置いて返す内容を組む。結果を返さないなら「Immediately」を選び、受け取った直後に応答させる
4. n8nのワークフローを「Publish」で公開する。公開するまで本番用のURLは動かない
5. DifyのワークフローにHTTP Requestノードを置き、本番用のURLへPOSTする。ボディには、前の工程で作った値をJSONで入れる
6. n8nの受け口が誰からでも呼べる状態にならないよう、Webhookノードで認証を設定し、Dify側のヘッダーにその値を入れる

つまずきやすい点

n8nとDifyをつなぐときにつまずきやすいのは、次の4つです。

応答の待ち方を先に決めておく

タイムアウトは、試作では起きず、長い文書を読ませる本番になって初めて起きることが多い問題です。Difyを呼ぶときは、答えが出るまで待つ方式（blocking）と、少しずつ受け取る方式（streaming）を選べます。n8nのHTTP Requestノードで扱いやすいのは待つ方式ですが、処理が長いと途中で切れることがあります。長い文書を扱う業務では、試作の段階から本番と同じ長さの文書で試しておきます。

空の入力でも動いてしまう点に気づく

Difyの入力欄を必須にしていないと、項目名が合わないまま送っても、Difyはエラーを返さずに空の入力で答えを作ります。n8n側では処理が成功したように見えるため、気づくのが遅れます。業務で必ず要る入力欄はDify側で必須にし、返った答えが決まった分類のどれかに当たっているかを、n8nのIFノードで確かめてから次へ進めます。

業務で組み合わせるときに決めること

n8nとDifyを業務で組み合わせるときは、作り始める前にAPIキーの管理、承認を人に残す箇所、監視の3つを決めておきます。どれも、動き始めてから決めようとすると、止まったときや担当者が替わったときに困る項目です。

APIキーは使い道ごとに分けて管理する

Difyのキーはアプリごとに発行され、n8nのWebhookの受け口にも認証の値を設定します。どちらも、どこに保管し、誰が見られるかを先に決めます。1つのキーを複数のワークフローで使い回すと、ある処理を止めるつもりでキーを無効にしたとき、同じキーを使う別の処理も止まります。キーごとに、どのワークフローが使っているかを一覧にしておくと、止めたい処理だけを止められます。担当者が異動したときにも、一覧があれば引き継ぎの漏れを防げます。

承認はn8n側でまとめて持つ

AIの答えをそのまま社外へ送ったり、会計や顧客管理のシステムへ書き込んだりはしません。影響の大きい処理の手前で、担当者がチャットのボタンなどで承認するまで、n8nのワークフローを先へ進めないようにします。

Difyとn8nの両方に承認の手順を散らすと、「どこで人が確認しているか」を後から説明できなくなります。AIの答えを作るのはDify、承認を待って先へ進めるかを決めるのはn8nと役割を分け、承認の手順はn8nのワークフローにまとめると、止め方も説明もしやすくなります。

関連記事：AIエージェントを基幹システム・SaaSにつなぐ｜連携方式の選び分けと、書き込みまで許す範囲の決め方

監視は、処理の成否と答えの中身の両方を見る

n8nの実行の記録で分かるのは、処理が最後まで動いたかどうかです。n8nが止まるとエラーの通知も一緒に止まるため、大事な処理がその日に動いたかどうかは、n8nの外の仕組みで確かめます。

一方で、Difyの答えが外れていても、処理そのものは成功として記録されます。最初の数週間は、Difyのログで質問と答えの組を担当者が読み、外れた答えの原因がプロンプトにあるのかナレッジにあるのかを確かめます。答えの外れが減ってきたら、読む件数を抜き取りに減らしていきます。

まとめ：n8nは流れを組み、Difyは途中のAIを受け持つ

• n8nとDifyの違いは、n8nがシステムをつなぐワークフロー自動化ツール、DifyがLLMのチャットボットやAIアプリを作る基盤である点
• どちらも無料で始められる。有償のプランは、n8nがワークフローの実行回数、Difyが問い合わせの回数で料金が決まる
• 社内で使う範囲ならライセンスの制約に当たることはまれ。顧客向けのサービスに組み込むなら、Difyのマルチテナントとロゴ表示の条件、n8nの利用条件を先に確かめる
• 社員が話しかける仕組みはDifyを起点に、決まった流れの途中でAIを使う業務はn8nを起点にする。AIが要らない業務にはDifyを入れない
• 連携はn8nのHTTP RequestノードでDifyのAPIを呼ぶ形と、DifyからWebhookでn8nを動かす形の2方向がある
• 業務に組み込む前に、APIキーの管理、承認を人に残す箇所、監視の3つを決める

関連記事：n8nとは？できること・料金・使い方と、業務自動化を本番で回す前に決めること

Augueでは、n8nのような自動化ツールと生成AIを組み合わせ、どこをAIに任せてどこで人が承認するかの設計から、本番の運用に乗せるまでをご支援しています。ご興味がある方は是非ご相談ください。

よくある質問

n8nとDifyの両方を使うと、月の費用はどれくらいになりますか？

一律の金額は出せません。クラウド版なら、n8nは月に何回ワークフローを動かすか、Difyは月に何回AIへ問い合わせるかで必要なプランが決まり、そこにLLMの利用料が加わります。まず対象の業務で1日に何件処理するかを数え、1件あたりn8nの実行が何回、Difyへの問い合わせが何回起きるかを掛け合わせると、どのプランに収まるかを見積もれます。

Difyのメッセージクレジットは、自社で契約したLLMを使うときも減りますか？

クレジットは、Difyが用意したモデルを呼び出したときに使われるものです。自社で契約したLLMのAPIキーをDifyに登録して使う場合、モデルの利用料はそのLLMの提供元へ払う形になります。どのモデルの呼び出しがクレジットの対象になるかは変わることがあるため、契約前にDifyの料金ページで確かめてください。

n8nのAIエージェントのノードがあれば、Difyは要らないのではありませんか？

文章の要約や分類をワークフローの途中で1回呼ぶ程度なら、n8nのAIのノードだけで足ります。Difyを足す意味が出るのは、社内文書を登録して検索させる仕組みを作り込みたいとき、プロンプトを業務の担当者が画面で直したいとき、社員が話しかけるチャット画面が要るときです。この3つが無ければ、道具を1つに絞ったほうが保守の手間は減ります。

2つをつないだ仕組みが業務で使えるようになるまで、どれくらいかかりますか？

問い合わせの要約を担当者へ知らせる程度の構成なら、試作は数日で動きます。長くかかるのは、AIの答えが業務で使える水準かを実際のデータで確かめる期間で、数週間は結果を人が見て、プロンプトやナレッジを直すことになります。取引先へ送る、システムへ書き込むといった処理を含む場合は、承認の手順を決める時間も見込んでおきます。

関連する記事

n8nセルフホストの手順｜Docker・Docker Composeでの構築と本番運用で決めることn8nセルフホストは、DockerやDocker Composeを使えば自社のPCやVPSに無料で構築できます。クラウド版との費用の違い、起動の手順、SSLとリバースプロキシ、暗号化キーとバックアップの扱いを解説します。非エンジニアがAIエージェントを作る開発環境の選び方｜ノーコード・生成AI開発ツールの型の違いと、情シスが確認する条件非エンジニアがAIエージェントを作る開発環境を、画面で組む型と対話で作る型、コードを社内で持つ型の3つに整理し、作れる範囲や直せる人の違い、情シスが導入前に確認する条件を表でまとめました。ファインチューニングとは？意味とRAGとの違い・使い分け｜社内データはRAGから始めるファインチューニングとは、既存のAIモデルに追加学習させて重みを書き換え、答え方を特定の形へ寄せる手法です。RAGとの違いは知識の置き場所にあります。社内データでの使い分けと併用する順番まで整理しました。