ワークフロー自動化ツールを導入しようとすると、必ず「n8nとMake（旧Integromat）、どっちがいいのか」という問題に行き当たる。筆者はクライアントのワークフロー構築で両方を年間50件以上使ってきたが、結論から言えば「用途による」——しかし、その判断軸は明確にある。
この記事では、2026年3月時点の最新情報をもとに、料金・機能・日本語対応・セルフホスト・AI連携の5軸で比較する。
比較の前提条件
公平な比較のために、前提を明確にしておく。
- n8n: セルフホスト版（無料）とn8n Cloud版（有料）の両方を考慮
- Make: クラウドSaaS版のみ（セルフホスト不可）
- 料金: 2026年3月時点の公式サイト掲載価格。為替レートは1ドル=150円で計算
- 検証環境: 月間ワークフロー実行回数1,000〜10,000回の中小企業ユースケースを想定
比較1: 料金——月間実行数でコストが逆転する
| 項目 | n8n（セルフホスト） | n8n Cloud | Make |
|---|---|---|---|
| 初期費用 | 0円 | 0円 | 0円 |
| 月額（最小プラン） | 0円（OSS） | 約3,000円（Starter） | 約1,400円（Core） |
| 月間実行回数上限 | 無制限 | 2,500回 | 10,000回（Ops） |
| 追加実行の費用 | なし | 上位プランへ移行 | 追加Ops購入 |
| サーバー費用 | 月1,000〜3,000円（VPS） | 込み | 込み |
コスト分岐点
月間実行回数が5,000回以下ならMakeが安い。月額1,400円で10,000 Opsまでカバーでき、サーバー管理も不要だ。
月間実行回数が10,000回を超えるとn8nセルフホストが圧倒的に安い。VPSの月額1,000〜3,000円だけで、実行回数に上限がない。年間で計算すると、Makeの上位プランとの差額は10万円以上になるケースもある。
比較2: 機能——カスタマイズ性と手軽さのトレードオフ
| 機能 | n8n | Make |
|---|---|---|
| 連携サービス数 | 400+（公式）+ 500+（コミュニティ） | 1,800+ |
| コード実行 | JavaScript / Python | JavaScript（限定的） |
| バージョン管理 | Git連携対応 | シナリオ履歴のみ |
| エラーハンドリング | Error Trigger + 詳細ログ | Error Handler（視覚的） |
| サブワークフロー | 対応 | 対応（Module） |
| Webhook | 無制限 | プランにより制限 |
n8nが強い領域
コードによる拡張性では、n8nが圧倒する。JavaScriptノードでほぼ何でもできるうえ、Pythonの実行にも対応している。APIのレスポンスを独自ロジックで加工したり、外部ライブラリを呼び出したりする必要がある場合はn8n一択だ。
Git連携も大きなアドバンテージだ。ワークフローをJSONファイルとしてGitHubで管理でき、チーム開発でのレビュー・ロールバックが容易になる。
Makeが強い領域
連携サービスの数ではMakeが大差で勝つ。1,800以上のコネクタが公式に提供されており、SaaSとの接続がノーコードで完結するケースが多い。n8nでは手動でHTTP Requestノードを設定する必要があるサービスでも、Makeなら専用モジュールが用意されていたりする。
UIの分かりやすさもMakeに軍配が上がる。フローの視覚的な見やすさは、非エンジニアのチームメンバーと画面を共有する場面で効く。
比較3: 日本語対応——どちらも道半ば
正直なところ、日本語対応はどちらも完璧ではない。
- n8n: UIは英語のみ。ドキュメントも英語。ただし日本語のコミュニティ記事やQiita投稿が増えてきており、「n8n 使い方」で検索すれば日本語の情報はそれなりに見つかる
- Make: UIは日本語化済み。公式ヘルプの一部も日本語訳がある。非エンジニアが触る場合は、この差が結構効く
結論として、日本語UIが必須な場合はMake。英語UIに抵抗がなければn8nで問題ない。
比較4: セルフホスト——n8nの独壇場
Makeはクラウドサービスのみで、セルフホストに対応していない。データは必ずMakeのサーバーを経由する。
n8nはDockerで自社サーバーやVPSにインストールでき、データを外部に出さない運用が可能だ。これは以下の場面で決定的な差になる。
- 個人情報を扱う業務: 顧客データ、従業員データなどのPII（個人識別情報）を処理する場合
- 規制産業: 金融、医療、法律関連で、データの外部送信に制約がある場合
- 社内ポリシー: 情報セキュリティポリシーで外部SaaSの利用に承認が必要な場合
セルフホスト要件がある時点で、選択肢はn8n（またはApache Airflowなどのエンジニア向けツール）に絞られる。
比較5: AI連携——2026年の差別化ポイント
2026年現在、ワークフロー自動化ツールにとってAI連携は必須機能になりつつある。両ツールの対応状況を見てみよう。
n8nのAI連携
- Claude API、OpenAI APIをHTTP Requestノードで直接呼び出し可能
- LangChainノードが公式に統合され、RAG（Retrieval Augmented Generation）パイプラインをGUI上で構築できる
- AI Agentノードでツール呼び出し型のエージェント構築に対応
- コードノードで独自のプロンプトエンジニアリングを実装可能
MakeのAI連携
- OpenAI、Claude、Geminiなどの公式モジュールが用意されている
- ノーコードでプロンプトを設定し、レスポンスを後続モジュールに渡せる
- AI連携の設定がシンプルで、非エンジニアでも扱いやすい
AIを「シンプルに使う」ならMake、「高度にカスタマイズする」ならn8n。RAGやエージェント構築まで踏み込むならn8nが現時点では唯一の選択肢だ。n8nとClaude APIの連携については、別記事で詳しく解説している。
用途別おすすめ——結局どちらを選ぶべきか
n8nを選ぶべきケース
- 月間実行回数が10,000回を超える見込みがある
- セルフホストが必須（データを外部に出せない）
- JavaScriptやPythonでカスタムロジックを書きたい
- AI連携で高度な処理（RAG、エージェント）を組みたい
- ワークフローをGitで管理したい
- エンジニアがチームにいる（またはエンジニア本人が使う）
Makeを選ぶべきケース
- 月間実行回数が5,000回以下で、コストを抑えたい
- 日本語UIが必要（非エンジニアのチームメンバーが操作する）
- サーバー管理をしたくない
- 連携先のSaaSが多く、公式コネクタの充実度を重視する
- AI連携はシンプルな用途（テキスト生成・要約）に限定される
両方使うという選択肢
実は「両方使い分ける」という運用も現実的だ。筆者のクライアントでは、社内向けのデータ処理ワークフローをn8n（セルフホスト）で、クライアント納品用のシンプルなワークフローをMakeで構築している例がある。ツールに固執するより、用途に合わせて使い分ける柔軟さが実務では効く。
n8nの導入を検討しているなら、まずはn8n使い方入門で手元のPCに環境を作ってみるのが最も確実だ。30分あれば最初のワークフローが動く。