n8nとMakeを比較｜自由度と運用負荷の違い

n8nとMakeは、どちらも複数serviceをvisual workflowでつなげるautomation platformです。

大きな違いは、n8nがSelf-hostedとcode / custom nodeまで含む自由度を持ち、Makeがmanaged cloud上のvisual scenario builderを中心にしている点です。

n8nはSelf-hostedできる

n8nはCloudに加えてSelf-hostedを選べます。

自社server、VPC、private network、on-premなどへ配置しやすく、databaseやruntimeもcontrolできます。

その代わり、security、backup、update、monitoringを自分で持つ必要があります。

Makeはmanaged cloudが基本

Makeはmanaged platformです。

Scenario Builder上でmoduleをつなぎ、Router、Filter、mappingを使ってdata flowを作ります。

platform自体を自社serverへ置くn8nのようなCommunity self-host modelではありません。

visual workflow

Makeはcanvas上でmodule、router、branchを視覚的に組み立てる体験が強いです。

n8nもnode-based canvasですが、code、HTTP、AI node、custom nodeなどdeveloper寄りのcontrolまで広がっています。

AI Agent

n8nはAI Agent、model、memory、vector store、retriever、MCPをnode単位で組み合わせられます。

MakeもAI Agent、AI Toolkit、MCPなどを提供し、通常scenarioとAIを組み合わせられます。

両方ともagentic workflowを作れますが、構成方法とplatform controlが異なります。

課金単位

n8n Cloudはworkflow executions。

Makeはcreditsです。

Makeでは通常moduleのoperationがcreditを消費し、AIなど一部featureではdynamic creditになる場合があります。

n8nではstep数そのものではなくworkflow runがexecutionとしてcountされます。

複雑なscenarioほどcost modelの差が出やすくなります。

custom integration

n8nはcustom nodeを開発できます。

MakeもHTTP moduleやAPIを使えますが、platform extensionの考え方はn8nと同一ではありません。

internal systemへ深く寄せたい場合は比較ポイントです。

on-prem接続

Make EnterpriseはOn-prem agentを使い、local networkのserviceへ接続する構成があります。

ただしMake本体をself-hostするわけではありません。

n8nはworkflow runtime自体を自社environmentへ置けます。

自由度を「設定できる数」ではなく責任範囲で比べる

「自由度が高い」は、そのまま導入しやすいという意味ではありません。n8nをSelf-hostedにするか、Makeをmanaged環境で使うかは、どこまで社内で運用を引き受けられるかで変わります。たとえば、顧客の申込を受けて社内DBへ登録し、担当者へ通知するworkflowを考えます。

表は横にスクロールできます

確認点	n8n Self-hosted	Make managed
実行環境	自社が選んだserverやcloud	Make側のmanaged platform
ネットワーク	private networkや社内serviceへ直接置ける構成を検討	Enterprise On-prem agent等でlocal network accessを構成する場合がある
更新・監視	自社でversion、backup、monitoring、復旧を担う	providerの運用範囲と契約条件を確認し、自社はscenarioと接続権限を管理
Workflow変更	node、code、HTTP、custom node等を組み合わせる	visual scenario、module、router、filterで処理を組む
費用を見る単位	Cloud利用ならexecution。Self-hostedはinfra・保守工数も含める	credits。通常のmodule actionは原則operation単位、AI機能は消費が変動する場合がある

MakeのOn-prem agentは、Make本体を自社へインストールすることと同じではありません。local networkのserviceへ接続するための手段として案内されているため、「社内ネットワークに届く」と「実行基盤を自社で管理する」を分けてください。

申込から登録までの失敗経路を先に書く

正常な1件だけで試すと、運用負荷は見えません。次のような入力を使って、両方で同じ受入条件を確かめます。

1. 必須項目が欠けた申込

2. 同じ受付IDが二度届く

3. 登録先APIが一時的に応答しない

4. AI分類が曖昧な文章を返す

5. 通知先のcredentialが期限切れ

6. 再試行した際に重複登録が起きる

各ケースで「止まる」「再試行する」「担当者へ知らせる」のどれが起きたか記録します。業務データをそのまま使う前に、匿名化したテストデータで検証してください。成功件数だけでなく、失敗を見つける方法と復旧手順を比べると、編集画面の好みだけでは分からない違いが出ます。

課金見積もりは小さなシナリオから

n8n Cloudはworkflow全体のexecution数が中心です。Makeはcreditsを使い、通常moduleではoperationが課金単位の基本になります。一方、MakeのAI Providerを使うAgentやAI機能は、操作回数だけでなくtoken等に基づいてcreditが変わることがあります。planにより単価や上限も異なるので、ここでは固定価格を並べず、数え方を分けます。

仮に月500件の申込を処理し、1件につき「受信→重複確認→登録→通知」の4 moduleが動く場合、Makeでは通常処理が何回実行されるか、Router等の例外、AI stepの使用有無を分けて試算します。n8n Cloudでは起動workflowの数をまず数え、失敗再試行やsub-workflowの実行が別executionになる条件を契約上の定義で確認します。Self-hostedの場合は、server費だけでなく更新・バックアップ・監視の担当時間も費用に含めます。

1回の実行を手でテストし、scenario/workflow履歴から実際のcreditまたはexecutionを記録した後、月間件数を掛けます。データ量やAI利用が増える業務は、少数テストをそのまま単純比例させず、ピーク時や追加呼び出しも別に確認してください。

選定前の分岐

• n8nを先に試す：実行環境、network、code、custom nodeを自社側で調整したく、保守担当がいる。

• Makeを先に試す：serverを管理せず、視覚的なscenarioと多数の接続を使って業務担当者が組み立てたい。

• MakeのOn-prem agentを調べる：社内ネットワークのserviceへ接続したいが、Make本体をself-hostするのが目的ではない。

• どちらも保留：Databaseの書き込み権限、個人情報の保存場所、障害連絡先、復旧責任者が決まっていない。

この分岐は製品の優劣ではなく、業務を止めずに維持する担当者がいるかを確かめるものです。運用担当がいないなら、最初は書き込みを下書きへ止め、担当者が確認したあとに本登録する形で小さく試す方が安全です。

Self-hostedを選ぶ前の運用確認

自社環境へ置く必要があるなら、n8nのSelf-hostedは有力な比較対象です。ただし、次の担当が空欄なら、自由度を得る代わりに業務が止まる恐れがあります。

表は横にスクロールできます

運用項目	決めること	未決定のまま公開したときの困りごと
更新	誰がversionとsecurity updateを確認するか	既知の脆弱性や互換性問題が残る
backup	workflow、credential、databaseをどう復元するか	server障害で復旧できない
monitoring	実行停止やqueue滞留を誰が見るか	不達に気づかず業務が遅れる
network	外部接続先と社内接続先をどう分けるか	過剰な権限や到達範囲が残る
変更管理	誰が本番workflowを承認するか	テスト中の変更が本番へ入る

n8nのCloudとSelf-hostedでは提供条件や機能が同じとは限りません。契約ページでSelf-hostedのみのplan、実行上限、機能差を確認し、オープンソース版の存在を有償プラン機能と混同しないようにします。Make側も、planにより権限、ログ、連携方法が異なります。最新の条件は契約前に公式料金・helpを確認してください。

検証の結果、private networkへの接続は必要だがserver運用者がいない場合は、MakeのOn-prem agentが要件を満たすか候補にできます。ただし通信方式、対応plan、社内security審査を確認し、「本体のself-host」とは別の構成として設計します。接続先の承認が得られない場合、データを外へ出さずに済むと推測してはいけません。

最後に、1件の正常処理だけではなく、API応答がないケース、認証期限切れ、同じ入力の再送も試します。n8nではexecution historyから、Makeではscenario historyから失敗node/moduleを特定し、復旧後に二重登録がないか確認します。運用者が履歴を見つけられない、再実行を安全に行えないなら、機能の多さより管理しやすさを優先して選び直します。

AIものさしの判断

n8nはruntimeやnetworkまで自分でcontrolしたい場合に向く構成です。

Makeはmanaged環境でvisual scenarioを細かく組み立てたい場合に分かりやすい構成です。

自由度が高いほど運用責任も増えるため、「できること」だけでなく誰がinfraを持つかで選ぶことが重要です。

同一workflowのHands-on比較をしていないため、速度・成功率・実コストの優劣は断定しません。