Zapier・Make・n8nの料金比較。ワークフロー自動化基盤の選び方

社内システムの連携やアラート通知、日次バッチのようなワークフロー自動化基盤を、Zapier・Make・n8nのどれで構築するか迷っている運用担当者向けの内容です。SaaS間の連携ツールをオンプレのcron処理やスクリプトから移行する際、料金モデルの違いが後から運用コストを大きく左右します。導入前に整理しておきたい判断軸をまとめました。

この3つは「iPaaS（Integration Platform as a Service、複数のSaaSやシステムをつなぐクラウド型連携基盤）」と呼ばれる領域のツールです。オンプレで運用していたバッチスクリプトやcronジョブを、こうしたノーコード連携基盤に移す動きが増えています。ただし移行後に請求額が想定を超えるケースは、機能不足ではなく課金単位のミスマッチが原因になりがちです。

どんな場面で判断が必要になるか

典型的なきっかけは、既存ワークフローにステップを1つ追加した翌月、請求額が跳ね上がるという体験です。

たとえば「フォーム入力を受けてSlack通知するだけ」の単純な連携が、「入力を受けて顧客情報を検索し、値を整形し、CRMとスプレッドシートの両方に書き込む」構成に育つのはよくある話です。

機能要件が変わらなくても、内部のステップ数が増えるだけで課金が変わるツールがあります。この構造を理解していないと、移行判断を「機能比較」だけで済ませてしまい、後から運用コストで痛い目を見ます。

判断軸1: 課金単位（メータリング方式）

3つのツールは、使用量を数える「メーター」がそれぞれ違います。

Zapierは「タスク」単位で課金します。タスクとはワークフロー内の1つのアクションステップが実行されるごとに1カウントされる単位です。トリガー（起動条件）自体はカウントされず、その後のアクションだけが数えられます。5ステップのワークフローを1回動かすと5タスク消費、というシンプルな仕組みです。

Makeは「オペレーション」単位で課金します。1モジュール（処理ブロック）が1回動くごとに1オペレーションです。Zapierのタスクと似た概念ですが粒度がより細かく、同グレードのプランでの許容量は大きめに設定されている傾向があります。注意点は、配列やリストをループ処理するイテレーター（繰り返し処理モジュール）を使うと、1回の実行で50件処理すれば50オペレーション以上を一気に消費する点です。

n8nは「エグゼキューション（実行）」単位で課金します。ワークフローが3ノードでも30ノードでも、1回動けば1エグゼキューションとしてカウントされる点が構造的に異なります。さらにn8nはフェアコード（Sustainable Use Licenseという、OSI承認のオープンソースではないが公開されたソースコードを条件付きで使えるライセンス形態）のセルフホスト版を提供しており、これを使うと実行回数の課金メーター自体が存在せず、サーバー費用だけで運用できます。

つまりZapierとMakeは「1回の実行の中でどれだけ作業が発生したか」で課金され、n8nは「何回実行されたか」だけで課金される、という構造の違いがあります。

判断軸2: ワークフローの複雑さと拡張余地

新規リード2,000件を処理する、5ステップのワークフローを例に比較してみます。

この表から分かるのは、タスク課金・オペレーション課金では「ステップ数×実行回数」がコストになる点です。n8nの実行課金では「実行回数」だけがコストになります。

運用中のワークフローは、要件追加によってステップ数が増えていくのが自然な成長パターンです。ステップ課金のツールでは、機能追加のたびに静かに月額コストが上がっていく構造になっている点を理解しておく必要があります。

判断軸3: 運用体制とインフラ管理の負荷

セルフホストできるn8nは、サーバー費用だけで実行課金を回避できますが、その代わりにサーバーの保守・アップデート・監視を自分たちで抱えることになります。

オンプレ運用の経験があるSRE・インフラ担当者にとっては、コンテナで動かして監視基盤に組み込む作業自体は馴染みがあるはずです。DockerイメージやKubernetes向けのHelmチャートも公開されており、既存の監視スタック（PrometheusやGrafanaなど）に組み込むことも可能です。

一方でZapierやMakeはフルマネージドなので、サーバーのパッチ適用やダウンタイム対応から解放されます。運用担当者を増やさずに自動化基盤を広げたいなら、この「管理不要」という点自体が価値になります。

判断軸4: 障害耐性と外部API依存の吸収度

Zapierの強みは連携先アプリの数と、外部APIの不安定さを吸収する仕組みの成熟度にあります。サードパーティAPIが一時的にレスポンスを崩しても、Zapier側でリトライやエラーハンドリングをある程度吸収してくれる傾向があります。

これは障害対応の観点で見落とされがちなポイントです。自前でエラーハンドリングを書く必要がある分、n8nのセルフホスト版は障害発生時の一次対応も自分たちの責任範囲になります。

監視設計の観点では、n8nは実行ログをOpenTelemetry対応の外部ログ基盤に転送する構成が組みやすく、既存のオブザーバビリティ（システムの内部状態を外部から把握できる仕組み）基盤に統合しやすい利点があります。SaaS版のZapier・Makeは基本的に管理画面上のログに閉じるため、既存の監視基盤との統合は限定的です。

ケース別の推奨

以下の条件に当てはまるかで、選ぶべきツールが変わってきます。

• 月間の実行ボリュームが小さく安定している、社内に運用担当を置きたくないならZapierを選ぶ
• ワークフローがステップ数の多い複雑な構成で、実行回数も月数千件規模に育っているならn8nのセルフホスト版を検討する
• 粒度の細かい課金で許容量の大きいプランを使いたく、かつマネージド運用を維持したいならMakeを選ぶ
• 既存の監視基盤（Prometheus/Grafanaなど）に自動化ログを統合したいならn8nが相性が良い

あえて見送るべき条件

n8nのセルフホスト移行は、どのチームにも正解とは限りません。

インフラ運用の人員が確保できず、サーバーのパッチ適用やバックアップ運用に手が回らないなら、実行課金の安さよりも運用負荷の増加が先に問題になります。

また、月間の実行回数がそもそも数百件程度で、料金プランの上限に余裕があるなら、課金モデルの違いを気にする段階ではありません。既存ツールを使い続けるほうが合理的です。

連携先が非常にニッチなSaaSで、ZapierやMakeにしか公式コネクタが存在しない場合も、移行より現状維持を優先すべき条件です。

まとめ

Zapier・Make・n8nの違いは機能の優劣ではなく、課金単位（タスク・オペレーション・実行）の違いに帰着します。

判断の起点は「現在のワークフローが何ステップで、月に何回実行されているか」を実際に集計することです。管理画面の使用量レポートから、直近のタスク数やオペレーション数を確認してみてください。

ステップ数が増える見込みがあり実行回数も伸びているなら、n8nのセルフホスト版で運用コストを実行回数だけに固定する選択肢を検討する価値があります。逆に運用体制が薄いチームは、コストよりも管理不要という価値を優先して現状のツールを使い続けるのが妥当な判断です。