Dify・n8n・Makeを徹底比較——用途別の最適解と、「n8nが比較から抜け落ちがち」な理由

先に要点

• 立ち位置の違い：Difyは生成AIアプリ／エージェント開発に特化したAIプラットフォーム（LLMOps）。n8nとMakeは**汎用ワークフロー自動化（iPaaS/IPA）**で、AIは“使える機能の一つ”。
• 価格の目安：Difyはクラウドの有料プラン（例：Professionalの月額）に加えOSS/セルフホストが選べます。n8nはクラウドの段階課金（Starter/Pro等）とセルフホスト、Makeはクレジット制の月額課金（運用回数＝クレジット）です。
• 強み：DifyはRAG/エージェント/観測/モデル切替などAI運用の土台が充実。n8nはセルフホスト＋柔軟な分岐・条件に強く、ライセンスは“サステナブル・ユース・ライセンス”。Makeはノーコードの視覚的シナリオと大量の連携、およびクレジット制のコスト管理がとっつきやすい。
• 「n8nが抜けている」理由の多くは：①比較テーマが“AI特化”だった（AIネイティブのDifyとSaaS特化のMakeを優先）、②選定基準が“純SaaSのみ”でセルフホスト前提のn8nが外れた、③ライセンス（Sustainable Use License）やセルフホスト課金の解釈を避けて説明コストを低くした、④日本チームの運用体制でMakeのトレーニング資産が先行——といった実務上の設計判断が背景にあることが多いです。

誰に役立つ記事か（具体像）

• 事業会社のDX/自動化担当：Salesforce/Google Workspace/Slackなど既存SaaS連携の運用コストとAI機能をバランス良く選びたい方。
• AIプロダクト開発チーム：RAG/エージェントをGUI＋APIで組み、監査・モデル差し替え・観測まで見据えたLLMOps基盤を検討している方。
• 情報システム部門：データ越境（レジデンシー）やオンプレ/セルフホストの要件があり、統制×自動化の落とし所を探している方。
• 中小企業の現場リーダー：少額から始めて標準化→定着させたい。UIの学習負荷やチームの教育コストを最小化したい方。

本稿は一次情報（公式サイト・ドキュメント）に基づき、不確実な情報は除外しています。価格・仕様は2025年10月時点の確認情報に準じ、リンク先の更新で変わる可能性があります（適宜ご確認ください）。

1. 3製品の“思想”と基本機能（まずは構図をそろえる）

Dify（LangGenius）

• 思想：生成AIアプリの本番運用に必要なエージェント型ワークフロー/RAG/モデル管理/観測を一体化したAIプラットフォーム。OSSとクラウド両対応で、モデルプロバイダを横断できます。
• 代表機能：エージェント・ワークフロー・RAG・評価/観測・モデル切替・マーケットプレイス。最新リリースではビジュアル・ナレッジ・パイプラインなど企業データのLLM準備が強化。
• 向く業務：FAQ/社内検索ボット、AI要約/分類、AIを内蔵した業務アプリの迅速立ち上げ。

n8n

• 思想：セルフホスト可能なワークフロー自動化。分岐・条件・ループを柔軟に構築し、各種SaaS/APIを低コードで連結。AI系ノードも増えています。ライセンスは“サステナブル・ユース・ライセンス”。
• 代表機能：ノードベースのビジュアルフロー、セルフホスト、Webhook/トリガ、分岐/フィルタ/エラー処理、AI連携ノード。
• 向く業務：社内のSaaS連携（CRM↔表計算↔メール等）、システム間の定期同期、オンプレ×クラウドの橋渡し。

Make（旧Integromat）

• 思想：ノーコードで“シナリオ”を組むSaaS自動化。膨大なコネクタと視覚的デバッグ、クレジット（オペレーション）制の課金がわかりやすい。AI接続もGUI中心で導入容易。
• 代表機能：ドラッグ&ドロップのシナリオ、豊富な分岐/フィルタ/イテレーション、詳細ログ、AI・Webhook・HTTP。
• 向く業務：SaaS中心の業務自動化、現場主導の小規模PoC→本番、教育コスト低減を優先する導入。

2. 料金とプランの考え方（“はじめての一歩”が切り出しやすいのは？）

• Dify：クラウドの有料プラン（例：Professional/月額）に加え、OSS/セルフホストも選択可能。AIアプリ側の実行（推論費用）は各モデル課金が別に発生する前提で、プラットフォーム利用料＋モデル費の二層で考えると把握しやすいです。
• n8n：クラウドは実行回数ベースの段階課金（Starter/Pro など）で、セルフホストも選べます。プランごとの同時実行や履歴など運用機能が段階的に増えます。
• Make：クレジット制（＝モジュール実行回数）。無料～有料で幅が広く、11月の更新でクレジット条件が一部改定される告知があります。**“使った分だけ”**の直感が明快で、PoC〜運用へ移行しやすいのが利点。

価格は為替・キャンペーン・改定で動きやすい領域です。最新の料金ページでの再確認を前提に、概算見積→1か月の実走で“伸び”を見てから本契約が安全です。

3. できること／向いていることを“実務視点”で棚卸し

3-1. Difyが得意なこと（AIアプリの“土台化”）

• RAGの構築・運用、エージェント、モデル切替（OpenAI/Anthropic/Vertex等）、観測・評価といったAIアプリの運用まわりがGUIで完結。本番に乗せやすい。
• セルフホスト/OSSでデータ保持要件に合わせられるのも企業導入の追い風。
• サンプル：社内規程Q&A、ナレッジ検索、要約・分類、エージェントを挟んだ自動処理のハブ。

3-2. n8nが得意なこと（柔らかな“つなぎ込み”）

• セルフホストを軸にオンプレ資産とクラウドをつなげる、“SaaS間の糊（グルー）”。分岐/フィルタ/再試行などフロー制御の自由度が高い。
• ライセンスはSustainable Use Licenseでフェアコードの立場。商用再販などの条項を読み解きつつ社内規程に落とし込めば、コントロール可能な自動化基盤になります。
• サンプル：基幹DB↔SaaSの定期同期、Webhook起点のリアルタイム連携、監査ログを伴う自動処理。

3-3. Makeが得意なこと（誰でも運用できる“見える化”）

• ノーコードの視覚的シナリオで現場導入が容易。ログの粒度・分岐/イテレーションもGUIで触れ、教育時間が短い。大規模なアプリ連携とクレジット制でコスト見通しを立てやすい。
• サンプル：Slack通知・表計算集計・CRMのレコード更新など、“管理部門主導の自動化”。

4. セキュリティ／データレジデンシー／ガバナンスの比較

• Dify：セルフホスト可。モデル側のログ保護やRAGのデータ取り扱いは自社インフラの統制でカバー可能。クラウド版はDPA（Data Protection Agreement）等の文書整備が進んでいます。
• n8n：セルフホストでネットワーク域内に閉じる設計が作りやすい。個社要件の厳しい部門でも運用しやすいのが持ち味。ライセンスの条項理解とセルフホスト時の運用費は事前に整理。
• Make：SaaS前提のため、レジデンシーや接続先の権限管理はアカウント設計と最小権限で運用。クレジット制は過負荷や暴走のブレーキとしても機能します。

5. 具体的ユースケースの比較（小粒から本番まで）

1. 社内のFAQボット＋社内文書検索

• Dify：RAGテンプレ→モデル設定→評価/観測までGUI完結。本番化が速い。
• n8n/Make：FAQ応答は外部LLM/APIに委託し、入力前後の整形やSaaS更新をフロー化。

2. ECの受注通知→在庫引当→会計登録

• Make：SaaS連携の厚さとGUIログが便利。現場運用が回しやすい。
• n8n：セルフホストで社内DB/基幹との双方向を安全に。分岐の自由度が活きる。
• Dify：エージェントを噛ませ、例外時に人へエスカレーションなど“半自律フロー”が設計しやすい。

3. レポート自動作成（要約・可視化）

• Dify：要約・説明文生成をアプリ化。モデル差し替えでコスト/精度の最適化が容易。
• Make/n8n：データ収集・整形を得意にし、最後にLLMで要約→Slack/メール配信。

6. 長所・短所を“ひと目”で（要点まとめ）

Dify

• 長所：AIネイティブ（RAG/エージェント/観測/モデル管理）。OSS/セルフホストでデータ統制がしやすい。
• 短所：純SaaS自動化のコネクタ厚みはiPaaS勢に劣る場合あり。LLM費用の最適化や評価運用の設計が鍵。

n8n

• 長所：セルフホスト×高いフロー自由度。開発者フレンドリーでオンプレ連携が強い。
• 短所：**ライセンスの理解（Sustainable Use License）**が必要。クラウドの課金・同時実行制限など運用面の設計が要る。

Make

• 長所：クレジット制で分かりやすく、GUIログが丁寧。大量のSaaS連携で“まず動く”までが速い。
• 短所：セルフホスト不可。高度なガバナンス要件やオンプレ直結は設計工夫が必要。

7. 「n8nが比較から抜けている理由」は何か（よくある背景と正しい捉え方）

1. 比較テーマが“AIプラットフォーム”寄りだった
   　DifyはAIアプリ運用の土台（LLMOps）、MakeはSaaSオートメーションを“ノーコードで大衆化”という分かりやすい軸があります。一方でn8nは“汎用フロー＋セルフホスト”という技術色の強い立ち位置ゆえ、「AI特化比較」や「純SaaS比較」では外されることが起きやすい。

2. “純SaaSのみ”を選定条件にした
   　セキュリティレビュー・導入速度を最優先にSaaS限定で比較すると、セルフホスト本命のn8nは除外されがち。n8n Cloudもありますが、**社内ルールで“セルフホスト＝追加審査”**となる現場が多く、説明コストを避けた結果の省略も実務では起こりえます。

3. ライセンス説明を避けたい（Sustainable Use License）
   　フェアコード系ライセンスは**「完全OSS」との違いを社内説明する手間が増えがち。短時間での比較表では注意事項が多い製品を外す意思決定が起きやすい。これはn8n固有の欠点**ではなく、社内説明の効率化という現場事情です。

4. プライシングや実行上限の“運用設計”が必要
   　実行回数・同時実行・履歴といった運用パラメータを誰が管理するかを先に決める必要があります。記者・編集側の“簡潔な紙面”では、Makeのクレジット制やDifyの“AIアプリ志向”の方が説明しやすいのです。

まとめると、n8nが劣っているから省かれるのではなく、比較軸や紙面制約、社内説明コストの都合で**“抜ける”ことがある**、が実情に近いです。

8. 迷ったときの“選び方の芯”——シナリオ別レコメンド

• AIアプリを“本番”に乗せたい（評価・観測・RAG調整も込み）
  　→ Dify。モデル横断・観測・RAGがプラットフォーム化されており、将来のモデル更改にも強い。

• 社内のSaaSをコード最小でつなげたい／オンプレも絡む
  　→ n8n。セルフホストで境界内運用が作りやすく、分岐/条件の柔軟さが効く。ライセンス条項の理解は初期に済ませる。

• 現場主導で“まず回るフロー”を数日で量産したい
  　→ Make。ノーコードGUIと詳細ログ、クレジット制で教育・見積が容易。

9. 将来動向（2026年に向けた読み）

• Dify：エージェント/ワークフローの高度化とナレッジ前処理（Visual Knowledge Pipeline等）の実務寄り拡張が続き、“AIアプリのOS”としての色合いが濃くなるはず。マルチモデル運用と観測は引き続き伸び筋。
• n8n：AIノードの充実とクラウド運用の改善、エンタープライズ機能の拡張が進む見込み。資金調達と成長も報じられており、製品進化のスピードは期待できます。
• Make：AI接続（プロバイダ設定の柔軟化）やクレジット制の最適化の告知が続いており、大衆化された業務自動化の王道を磨く方向。UI/ログの改善と教育資産の拡充がカギ。

補足トレンド：「RAGだけでなくエージェント志向へ」という潮流（賛否）は、AIアプリ側の設計指針に影響し続けます。Difyのようなエージェント/ワークフロー志向の基盤は、この流れと相性が良い領域です。

10. 導入ロードマップ（90日テンプレ）

• Day 1–14：要件定義

  • データ所在（社内/外）、越境要件、監査レベル、AI利用の目的（要約/分類/RAG/エージェント）。
  • SaaS限定かセルフホスト併用かを先に決める（ここでn8nの出番が決まる）。

• Day 15–30：PoC

  • DifyでFAQ/RAGのたたき台。Makeで2〜3本の“現場フロー”。n8nでオンプレ↔SaaS橋渡しの1本。
  • 成果を**コスト（モデル費＋プラットフォーム費）とMTTR（障害復旧時間）**で簡易評価。

• Day 31–60：標準化

  • 役割分担（AIアプリ＝Dify／SaaS自動化＝Make／境界橋渡し＝n8n）の運用ルールを成文化。
  • ログ保存・権限・監査、失敗時の再実行戦略、バージョン管理。

• Day 61–90：本番移行

  • SLAと運用費の再見積、監査証跡の確認、教育セッション（Makeで現場、n8nで情シス、DifyでAIプロダクト）。

11. よくある質問（FAQ）

Q. 一つに絞るべき？
A. 絞らなくてOKです。役割分担で考えましょう——AIアプリ＝Dify、現場GUI自動化＝Make、オンプレ↔クラウド橋渡し＝n8n。重なる部分はありますが、得意分野は明確です。

Q. n8nのライセンスが心配です
A. Sustainable Use Licenseはフェアコードの位置づけ。商用用途や再販に関わる条項の社内レビューをおすすめします。セルフホストの統制が必要なら依然として有力です。

Q. まず小さく始めたい
A. Makeの無料〜低額プランで見える化→Difyの無料/OSSでAIアプリ原型→n8nで境界要件の検証という3点攻めが実践的。

12. まとめ——“比較から漏れた理由”を正しく扱い、最適な三位一体へ

• DifyはAIアプリ運用の土台。RAG/エージェント/観測まで含めた本番設計に強い。
• n8nはセルフホスト×柔軟制御の橋渡し役。AIも使えるが本質は汎用自動化。比較から抜けやすいのはテーマ設定（AI特化/SaaS限定）や紙面制約が原因のことが多い。
• Makeはノーコードで“まず動く”。UI/ログ/クレジット制で現場導入が早い。

結論：三者を競わせるより、役割を分けて同居させるのが実務最適です。AIアプリ＝Dify、現場のスピード＝Make、境界・自社統制＝n8n。そして、**“n8nが比較にいない”**という状況に出会ったら、比較表の前提（AI特化か、SaaS限定か）を必ず確認しましょう。前提が変われば、答えは変わります。私は、小さく試す→役割を定義→標準化の順で、ムダなく心地よい自動化が育つと信じています。

参考資料（確認日：2025-10-29）

• Dify

  • 公式サイト（機能・最新リリース）：「Agentic Workflow／RAG／モデル管理／観測」等の記載。
  • 価格ページ（クラウドの有料プラン記載）。
  • GitHub（OSS・セルフホストの位置づけ）。
  • 公式ブログ（2025夏のハイライト：ナレッジパイプライン等）。

• n8n

  • 価格ページ（クラウドのプラン・実行回数・同時実行等）。
  • ライセンス（Sustainable Use Licenseの公式ドキュメント／告知）。
  • 資金調達の報道（成長トレンド）。

• Make

  • 価格ページ（クレジット制／改定告知）。
  • レビュー系の概説（価格帯・入門向け解説）。
  • 長所（分岐・ログ・コスト効率・連携の広さ）を整理した最新レビュー。

• 補助トピック

  • エージェント志向への移行（RAGをめぐる議論）。