条件をそろえて比較
Make vs n8n
月額だけでなくCreditsとworkflow executionsの違い、Self-host、コード利用、運用負担から選び分けます。
同じ仕事を任せたときの課金単位、例外処理、運用責任で比べます。機能数の勝敗ではなく、条件に合わない候補を落とすための比較です。
まず条件で候補を絞る
Visual workflowとSaaS横断を主軸に比較しやすい。
Self-hostedとJS/Pythonを選択肢に持つ。
同じ仕事で違いを比べる
| 比較項目 | Make | n8n |
|---|---|---|
| 無料版 / Trial | あり | Trial / Community* |
| 主な課金単位 | Credits | Workflow executions |
| Cloud | ○ | ○ |
| Self-host | — | ○（license条件あり） |
| Visual builder | ○ | ○ |
| コード利用 | JavaScript / Python（Plan条件あり） | JS / Python |
| API / Webhook | ○ | ○ |
| 連携 | 3,000+ apps | Cloud各Planでintegrations利用 |
| AI | AI apps / AI機能 | AI workflow機能 |
| Enterprise | Enterpriseあり | Business / Enterprise |
| 主な想定ユーザー | ノーコード〜業務改善 | Builder〜Developer |
月額より、何に対して課金されるか
最大の違いは機能数ではなく、どこまで自分で持つか
Makeはvisual-firstのクラウドAutomationとして、SaaS横断のScenarioを組む用途が中心です。n8nはCloudに加えてSelf-hosted Community Editionを選べ、JavaScript/PythonやAPIをWorkflow内へ組み込みやすい設計です。
両方ともWorkflowを作れます。差が出るのは、インフラを持つか、Codeを使うか、運用担当を置くかです。n8n Self-hostではSustainable Use License上の利用目的も確認が必要です。
「非エンジニアならMake、エンジニアならn8n」だけで切ると雑です。Developerがいても保守対象を増やしたくないならMakeやn8n Cloudが合理的ですし、非エンジニア中心でも明確なSelf-host要件があれば組織としてn8nを選ぶ余地があります。
- Make：クラウド運用を前提にvisualに組みたい
- n8n Cloud：Code/APIの自由度は欲しいがインフラ管理は避けたい
- n8n Self-host：deployment controlを自社で持つ明確な理由がある
- Self-hostのsoftware費が無料でもserver/backup/update/securityは別コスト
CreditsとExecutionsを同じ「回数」として比べない
Makeでは多くの非AI module actionがcreditを消費します。n8n CloudはWorkflowが開始から終了まで走る1回をexecutionとして課金します。
たとえば1イベントで5 step動くWorkflowを月1,000回実行する場合、Makeではmodule実行数、n8n CloudではWorkflow run数が主な見積軸になります。数字の単位が違うので、価格表だけ横並びにしても公平な比較にはなりません。
n8n Self-hostではCloud subscriptionだけでなく、infra、monitoring、backup、update、security、担当者工数を足します。Automation SaaSの比較なのに人件費まで出てくる。Self-hostとはそういう比較です。
- Makeを見積る：月間イベント数 × 1イベントあたりmodule実行数
- n8n Cloudを見積る：月間Workflow実行回数
- n8n Self-hostを見積る：infra＋運用工数＋必要edition＋license条件
- AI API費はAutomation SaaS側の料金と分けて計算
機能表ではなく、同じWorkflowを1本ずつ組む
両方が候補に残るなら、比較用Workflowを1本だけ決めます。おすすめは「Webhook受信→データ整形→条件分岐→SaaS書き込み→通知」のように、普段の業務を小さく代表するものです。
見るのは完成するかどうかだけではありません。誰が読めるか、エラーを追えるか、Credentialをどう管理するか、月間消費量を説明できるかまで確認します。
- 構築時間を競わない
- 同じ入力・同じ出力で比べる
- エラー時にどこを見ればよいか確認
- 料金単位へ換算
- 半年後に別担当が読めるか確認
自由度は、使う予定がなければただの選択肢
n8nのSelf-hostやCodeは明確な強みです。ただし「いつか使うかもしれない」だけなら、その自由度のために運用を複雑にする必要はありません。
Makeのvisual-first設計も、画面がきれいだから価値があるわけではありません。複雑な分岐をチームで読みやすくするために使うなら意味があります。
迷ったら運用責任の置き場所で決める
最終的には、誰が更新・監視・障害対応するかを決め、必要な自由度だけを選びます。
- Make寄り：運用をSaaS側へ寄せる、visual中心
- n8n Cloud寄り：Code/APIの自由度＋managed hosting
- n8n Self-host寄り：deployment controlが要件で、運用とlicense条件を管理できる
- どちらでもよい：同じ1〜2 Workflowを料金単位へ換算して比較
比較後に残る疑問
Makeとn8nではどちらが安いですか？
Workflow構成と月間実行回数で変わります。Makeはcredits、n8n Cloudはexecutions、n8n Self-hostはinfraと運用工数も含め、同じ業務量へ換算して比べます。
n8n Self-hostなら無料なのでMakeより得ですか？
Community Editionには無料で使える範囲がありますが、server、update、backup、security、monitoring、担当者工数が残り、Sustainable Use Licenseの用途条件もあります。
n8nはopen sourceですか？
n8n自身はOSIのopen-sourceではなく、Sustainable Use Licenseのfair-codeと説明しています。Self-hostできることと、用途制限のないopen-source licenseであることは別です。
非エンジニアならMake一択ですか？
一択ではありません。n8nにもvisual editorがあります。Self-hostやCodeを使わないならMakeとn8n Cloudを、実際のWorkflowと運用体制で比較すると判断しやすいです。
AI Automationではどちらが向いていますか？
AI Providerの接続方法、Automation側の課金、Code/APIの自由度、Self-host要件が主な比較点です。モデル性能そのものは同じWorkflowで別に評価します。
残った候補の公式条件を確認する
Make vs n8nは、月額ではなく「どこまで自分で持つか」で差が出ます。visualなSaaS運用へ寄せるならMake、Code/APIやdeployment controlを使う理由があるならn8n。理由が曖昧なら、まずCloud同士で比べるのが無難です。
一部の外部リンクは広告リンクになる場合があります。