n8n、Zapier、Makeの選び方：価格、自由度、保守コストで試算する

三択の話は、10人に聞けば9人が「要件次第」と答える。それでは答えになっていない。この記事では回りくどいことはしない。同じことを3社でコストを全部並べて計算し、それに費やす時間も加味した上で、最後に私ならどう選ぶかを述べる。

結論を先に置く。1日に十数回、ステップが5つ以内、社内ネットワークに触れないなら、Zapier や Make のほうが楽で、サーバーにすら触れる必要がない。1日に数百回、社内データベースを読む必要があり、フロー内でコードを書くなら、n8n のセルフホストで桁一つ分のコストを節約できる——代償はそのマシンの管理が自分に帰属し、深夜に落ちても誰も代わりに引き受けてくれないことだ。

この結論は粗すぎてそのままでは使えない。なぜなら数字が一つ欠けているからだ：あなたは1ヶ月にいったい何回実行するのか。この数字を算出しない限り、すべての比較は他人のシナリオに過ぎない。

誰に向いているか

3社の中から一つを選ぼうとしている人、あるいはすでに Zapier の無料版で壁にぶつかり、どこが高いのか知りたい人。手元に遊休 VPS があり、ログインしてコマンドを叩くのも厭わないなら、第4節の計算はより胸に刺さるだろう。自動化に触れたことがない人は、まず「n8n とは何か」を読んでから戻ってきてほしい。この記事は「ワークフロー」と「ノード」の意味を知っている前提で書いている。

• 3社は同じ課金単位にない
• 同じフローを、3社それぞれでいくらかかるか
• コスト以外に、自由度の差はどこにあるか
• セルフホストの請求書には、金銭ではない部分がある
• ライセンスの这条線は、納品する人が最初に見なければならない
• 私が n8n を選ばないことを勧める4つのケース
• ツールを乗り換えるコスト
• 1週間の試験運用で、どうなれば成功とするか
• ハマりやすいポイント
• セルフホストで増える3つのセキュリティ事項

3社は同じ課金単位ではない

ここは全文の土台であり、最も見誤りやすいところだ。3社の公式サイトで見る「使用量」はまったく同じものではない。

Zapierはtaskで計算する。正常に完了したアクション1回につき1 task、一部のアプリやアクションは2と記録される。トリガーは含まれない。イベントが入ってきても課金されず、アクションが成功して初めて課金される。新データの有無をポーリングしても含まれず、空振りで戻ってきても含まれない。標準搭載のFilter、Formatter、Path、Delay、Looping、Sub-Zap、さらにTablesとFormsはtaskを消費しない。

Makeはcreditで計算する。課金単位はoperationsからcreditsに変更済みで、告知では8月27日が発効日とされている。ほとんどのモジュールは1回実行で1 credit、AI Provider経由はそれ以上になる場合がある。ここでの違いは、トリガーモジュールも記録される点だ。あるアプリからレコードを1件読み取ると、そのステップで1 credit消費する。Routerとエラーハンドリングモジュール（Rollback、Break、Resume、Commit、Ignore）は記録されない。

n8nはexecutionで計算する。1つのフローを最初から最後まで実行して1回、途中に3ノードでも30ノードでも同じく1回。データ件数も増幅しない。1回の実行で5件処理しても200件処理しても、やはり1回。しかも本番実行だけが枠に計上される。エディタで「実行」ボタンを押してテストしても、100回走らせてもカウントされない。

	Zapier	Make	n8n
単位	task	credit	execution
1つのフローを1回実行するといくつ記録されるか	アクション数で数える場合、6ステップで5個（トリガーは含まない）	モジュール数で数える場合、6モジュールで6個	1個
データが1件から200件に増える	それに応じて増える、20倍なら20倍	それに応じて増える	増えない
手動でテストをクリック	Zapを有効にして実行すればカウントされる	scenarioを実行すればカウントされる	カウントされない

最後の行が私が最も重視する違いであり、これがこの仕組みを拡張できるかどうかを決める。仮定を置く：1つのフローで200件の注文を処理し、途中に5つのアクションがある。Zapierでは1回の実行で1,000 taskが記録され、1日1回実行すれば30,000になる；n8nでは1回の実行は依然として1 executionであり、1日30回となる。差は1,000倍であり、パーセント上の差ではない。

このインスタンス上で8ノードのフローを実行したことがあり、中間のコードノードが1つのitemを5件に分割し、分岐を通ってから再びマージされます。各ノードの下に表示される「几个项目」はその回に流れたデータ量です：

実行記録はこのようになっており、1行が1回の完全な実行で、右側の「运行时间」はフロー全体の合計所要時間です：

クリックすると今回の実行の明細が表示されます：

同じフローで、3社それぞれいくらかかるか

実在する3つの形状のシナリオで計算します。数字はすべて公式サイトの公開プランから取得し、価格は2026年10月26日に確認したものです。閲覧時には変更されている可能性があります。

シナリオ1：1時間ごとに実行、6ステップ

あるAPIを監視し、1日24回、1か月720回。こういう作業が最も一般的です。

	使用量	どのプランに該当するか
Zapier	5 × 720 = 3,600 tasks	無料版は100個で、36倍の差があり、有料が必須
Make	6 × 720 = 4,320 credits	10,000 credits プランの Core、年払い換算で $9/月
n8n クラウド	720 回実行	Starter €20/月、枠 2,500
n8n セルフホスト	720 回実行	0、サーバー代のみ

この行の結果は少し直感に反する：クラウド版 n8n は Make より二倍以上高い。Starter 年払い €20、Make の Core 年払い換算 $9。多くの人は「オープンソースなら間違いなく一番安い」と默认しているが、オープンソースが節約するのはライセンス費であり、クラウドホスティングは依然として従量課金であることを忘れている。

Zapier の欄は正確な金額を出せない。Professional はタスク枠を調整できるため、$19.99 は最低枠の開始価格であり、3,600 task なら上に調整する必要がある。確実なのは三社の中で最も高いということ——アクション単位の課金で高く、フローが長いほど不利になる。

シナリオ2：5 分ごとに 1 回実行、6 ステップ

月 8,640 回。この頻度になると、差が開き始める。

	使用量	どのプランに該当するか
Zapier	43,200 tasks	すでにかなり上位にある
Make	51,840 credits	すでに 10,000 のプランを超えているので、スライダーを上に動かして価格を確認する必要がある
n8n クラウド	8,640 回実行	Pro €50/月、枠 10,000
n8n セルフホスト	8,640 回実行	0

ここで n8n クラウド版が逆転し始める。セルフホストとの差はなおさら計算するまでもなく、月に八千回以上実行しても、電気代のほうがサブスクより安い。

シナリオ3：毎日 10 回、3 ステップ

月300回、合計2つのアクション。

Zapierは600 taskを記録し、無料ラインの6倍を超える。Makeは900 creditを記録し、無料プランは1,000なので、ちょうどギリギリ——余裕がまったくなく、あと3日多く動かせば課金が必要になる。これがMake無料プランの境界であり、「十分」ではなく「ちょうど使い切る」だ。

私自身の判断：1日十数回この規模なら、Make無料プランで3〜5か月は問題ないが、重要な作業には使わないほうがいい。超えた瞬間にシナリオが直接停止し、更新を待ってくれないからだ。

お金以外に、自由度はどこが違うか

	Zapier	Make	n8n
接続できるアプリ	9,000+	3,500+	公式ノード＋コミュニティノード、セルフホストなら自分で書くことも可能
コードを書く	コードステップがあり、task単位で課金され、実行時間が長いほど多く消費する	Toolsモジュールがある	Codeノード、JSまたはPython、追加課金なし
内網システムに接続	不可	不可	可能、自分のネットワーク内で動く
データの保存先	相手のサーバー	相手のサーバー	自分のデータベース
バージョン管理	有料プランには Zap のバージョン管理がある	—	Business プランから Git 連携可能；コミュニティ版は自分で JSON をエクスポートして保存

最初の2行があなたの天井を決め、後の2行がコンプライアンスコストを決める。社内ネットワークの ERP や古いデータベースを読む必要があるなら、最初の2社は即除外——難しいのではなく、物理的につながらない、彼らは他人のデータセンターで動いている。これは方案討論の途中で初めて発覚しやすく、それまで描いた図が全部無駄になる。

比較表にあまり書かれないもう一つ：単回実行時間。n8n クラウド版 Starter は1回最大5分、Pro でようやく40分。大きなファイルを処理する、遅い API を待つ、5分はすぐにぶつかる。セルフホストにはこの制限はないが、マシンは自分のもの、メモリを使い切れば同じように落ちる。

セルフホストの請求書には、お金ではない部分がある

これがこの記事で最も言いたい部分、なぜなら「n8n 無料」の比較記事はすべてこれを漏らしているからだ。

セルフホストが省くのはサブスクリプション料、引き換えに得るのはこれらのことで、すべて誰かがやらなければならない：

• 1台のマシンと1つのドメイン、それに証明書。Let's Encrypt は自動更新されるが、更新失敗はサイレントで、気づいたときには証明書が3日過ぎている。
• アップグレード。2.x 以降バージョンの反復が速く、私の这台は現在 2.43.7。アップグレードのたびにデータベースと暗号化キーをバックアップし、完了後にワークフローを1つ抜き打ちで実行確認する。1回およそ20分程度。
• バックアップ。3つ：データベース、暗号化キー、ワークフローのエクスポート。暗号化キーが欠けると、復元したインスタンス内のすべての資格情報が復号できず、1つずつ再入力することになる。データベースだけをバックアップしキーを持たないのが、最もよくある失敗パターン。
• 失敗アラート。n8n は自分で設定しない限り通知しない。定期タスクが2週間サイレント失敗しても、誰かが「今月の表にデータがないのはなぜ」と聞くまで気づかない。
• 障害時の調査。コンテナが起動しない、ポートが占有されている、メモリが爆発した、これらにサポート窓口はない。

時間の勘定は大体こう：初回インストール＋HTTPS設定で1時間；その後毎月これに費やす時間は1〜2時間；実際に1回障害が起きたら1〜3時間。

だからコストを計算するとき、分母に自分の時給を入れる必要がある。週に30分も捻出できないなら、セルフホストは選ばないほうがいい——これは金を節約できるかどうかの話ではなく、この作業には人が必要だ。金を払って Zapier を買うのは、本質的に「問題が起きたら受け止めてくれる人がいる」ことを買うということ。

私の这台の使用量ページはこんな感じで、一見の価値がある：

ページ2行目の小さな文字に「複数のトリガーを持つワークフローは複数回カウントされる」とある。つまり1つのワークフローにトリガーを2つ付けると、2つとして数えられる。セルフホスト版ではここが「無限」と表示されるので私には影響ないが、クラウド版ライセンスを買ったなら、この条項は噛みついてくる。

ライセンスのこの線、納品する人はまず見なければならない

n8n はオープンソースライセンスではなく、自社で書いた Sustainable Use License で、fair-code という名目の下に置かれている。条項が許す範囲は想像より広い：内部業務での利用、コードの改変、派生版の作成、顧客向けのフロー構築、n8n 関連のコンサルティングや運用保守、いずれも可能。できないのは二点だけ：n8n を別ブランドにして製品として顧客に売ること；自前で構築して他人からアクセス料を取ること。この二点は別途商業契約を結ぶ必要がある。

代理運営をする人が最も曖昧にしやすいところだ。前版のライセンス（Apache 2.0 に Commons Clause を加えたもの）と比べ、今回の変更の重点は「コンサルティング費を取ってはならない」という条項を撤廃したことにある——今は顧客のワークフロー構築を手伝い、コンサルティングや運用保守の費用を取るのに、追加の契約は一切不要。売るのが自分の腕であって、n8n の殻でなければ問題ない。

中間的な形態は自分で見極める必要がある：顧客のデータがあなたのデプロイした n8n 上で動き、あなたが月額でサービス費を取る。これは「コンサルティング」というより「ホスティング」に近い。本当にビジネスにするなら、license@n8n.io にメールで問い合わせる方が、事後対応よりはるかに安く済む。

比較してみよう：Zapier と Make は純粋な SaaS で、お金を払ってサービスを買うのでこの層の懸念はないが、ものを移すこともできない。

n8n を選ばないことを勧める四つの状況

チームにコマンドラインを触る人がいない。学べないのではなく、トラブルが起きた夜にログインしてログを見る人が誰もいないのだ。こういうチームは Zapier を買った方が、お金を無駄にしない。

ベンダーの SLA と電話サポートが必要。セルフホストにはない。コミュニティフォーラムは優れているが、2時間での応答を約束するものではない。

簡単な自動化が一、二個しかない。サーバーを一台立て、HTTPS を設定し、監視を設置する、それがフォームを表に同期するためだけなら、割に合わない。Make の無料プランなら、月900 credit で足りる。

ホワイトラベル製品として売りたい。ライセンスの節で述べた通り、まず契約を結ぶ必要がある。オープンソース版をそのまま売るのは契約違反であって、「グレーゾーン」ではない。

ツールを乗り換えるコスト

これら3つの間にワンクリック移行はない。Zapは「トリガー＋アクション」の線形構造、scenarioはモジュールとルーティングのキャンバス、n8nのworkflowは任意の有向グラフだ。データ構造が合わないので、エクスポートしたJSONは参考程度にしかならず、ロジックは組み直す必要がある。

私の経験値：十数ステップのフローを別ツールで組み直すには半日から1日かかる。デバッグと認証情報の再接続を含めて。すでに30〜40本溜まっているなら、1回の移行で2〜3週間だ。

だから選ぶときは今月の請求額だけを見ず、3年後にどのくらいの量になっているかを見ろ。低頻度で安定しているなら手間が少ないものを選べ。高頻度で増えていくなら、早めに自分で管理できるものに乗せろ。山ほど溜まってから移すな。

1週間の試運転、どうなったら「動いた」と見なすか

公式サイトの比較表で決めるな。実際の1件を選んで1週間動かせ。要件は1つだけ：そのフローが1回失敗しても致命的でないこと。入金系のフローで試すな。

1. そのフローが1日に何回動くか、途中に何ステップあるかを書き出せ。この2つの数がすべての入力で、以降の計算はすべてこれに依存する。
2. 1か月の総量を算出：回数 × ステップ。さらに平均1回あたりの処理データ件数を掛ける。ステップ課金の2社はこの数を使う。
3. この数を持って3社の公式サイトの料金ページで档位を照合しろ。「プラン名」ではなく枠と照合しろ。
4. 7日間走らせて、2つ記録しろ：何回失敗したか、直すのにどれだけかかったか。

走り終えたらこの3つの数を並べるだけで、選択はほぼ自然に見えてくる：使用量が金を決め、失敗率が安定性を決め、修理時間が耐えられるかどうかを決める。3つ目が最も見落とされやすく、最も挫折を招きやすい——Zapierからセルフホストに移った人が挙げる理由は金ではなく、「エラー時に何も見えない」ことが多い。

試すのがn8nなら、動作確認はこの4つの現象で見る：キャンバス上の各ノードの下に緑のチェックと「N 个项目」が出る；実行リストに「成功」の行が1つ増える；クリックすると各ノードの入出力が見える；「概述」ページの本番実行回数はまだ0（手動実行は本番実行に数えないため）。最後の項目は成功していないと誤解しやすいが、正常だ。

踏みがちな罠

1. サブスク価格をそのまま比較し、課金単位を見ない。同じ6ステップのフローで、Zapierは5 task、Makeは6 credit、n8nは1実行と記録する。どれも1桁に見えるが、意味は一段違う：前2つはステップ数を掛け、後1つは実行回数を掛ける。

2. Makeがまだoperationsで計算すると思っている。その課金単位はすでに credit になっており、公式 FAQ の「As of August 27, credits are the billing unit in Make」という一文が今回の変更を指している。古いチュートリアルの operations の数字が新しい請求と合わない原因はここにある。

3. n8n が無料ならコストゼロだと思い込む。ソフトウェアは無料でも、マシンには金がかかり、あなたの時間にはもっと金がかかる。月2時間のメンテナンスを時給で換算すると、Make の $9 よりはるかに高くつくかもしれない。

4. 空リクエストはカウントされないと思い込む。n8n のドキュメントには明確に書かれている：Webhook トリガーは受信したリクエストごとに1回の実行としてカウントされ、body が空の場合も含まれる {}。webhook をヘルスチェックのプローブとして使い、10秒ごとに叩くと、月に26万件の実行記録がすべて課金対象になる。プロセス起動前に失敗する無効リクエストはカウントされない。

5. ポーリングの計算方向を間違える。ポーリングトリガーは新しいデータが見つかったときだけ1回としてカウントされ、空振りはカウントされない——これは有利だ。しかし逆に、サンドボックスで見える回数が請求より少ないことも意味するので、テスト環境の数字で本番の請求を推測してはいけない。スケジュールトリガーは逆で、成功・失敗にかかわらず毎回カウントされる。

6. トライアル期間が終わることを忘れる。Zapier の新規登録アカウントは自動的に14日間の Professional トライアルに入る。トライアル期間中に組んだマルチステップ Zap は、期限切れで無料版に戻ると停止する——無料版はのみサポート。これを「Zapier が突然壊れた」と勘違いする人もいる。

7. 暗号化キーを紛失する。n8n のクレデンシャルは1つのキーで暗号化され、データベースには暗号文が保存される。マシンの変更、再インストール、移行の際にキーを持っていかないと、クレデンシャルが一切復号できず、ノードが次々とクレデンシャル無効を報告する。しかも入力したパスワードは明らかに正しい。このキーはデータディレクトリにあり、バックアップ時に漏らしてはいけない。

8. 長時間タスクが実行時間の上限にぶつかる。n8n クラウド版 Starter は1回最大5分。数百メガの表を処理したり、遅い API を待ったりすると、簡単に超過し、超過すると実行失敗になる。キューで再試行されるわけではない。

セルフホストで増える3つのセキュリティ事項

SaaSを選ぶなら、セキュリティ境界は相手側のもの；セルフホストを選ぶなら、境界は自分のもの。具体的には三つ：

露出面。n8n はデフォルトでアカウントとパスワードを備えているが、それを公網ドメイン上に置くのは、この扉を壁の外側に掛けるようなもの。少なくとも三つやる：HTTPS を導入する、弱いパスワードを変更する、セルフ登録を無効にする。スキャナが n8n のログインページを探すための辞書は既成のものだ、これは脅しではない。

鍵とバックアップは一箇所に置かない。暗号化鍵の漏洩は全認証情報の漏洩に等しい——中にはメールパスワード、データベースのパスワード、決済インターフェースの key があるかもしれない。バックアップファイルには暗号化後の認証情報が入っている、鍵ファイルは別に置き、バックアップと同じネットディスクディレクトリに詰め込まない。

データの帰属はよく考える必要がある。セルフホストの利点はデータが自分の庫から出ないこと、代償はバックアップ、削除、保持がすべて自分の管理下になること。Zapier や Make を使う場合、データはそれらのサーバーを経由する、顧客の携帯番号や身分証などのフィールドが関わるなら、まずその会社の DPA とデータ保持条項を見てから決める。この項目は価格とは無関係だが、三択の中で最も妥協できない項目だ。

まとめ

三社の違いは「誰が機能が多いか」ではなく、何を単位に課金するかにある。アクション単位で計算するものは、フローが長いほど高くつく；実行単位で計算するものは、ノードも件数も増幅しない。

低頻度、少量、内網に触れないなら、Zapier や Make の無料枠で十分、「オープンソース」のためにサーバーを一台養う必要はない。数百回に達し、バッチデータを処理し、内網を読む必要があるなら、n8n セルフホストの採算がようやく合う——前提として、毎月一、二時間をそれに費やす意志があること。

クラウド版 n8n はセルフホストの代替ではない。Make より高く、セルフホストより手間が省け、位置は中間で、「n8n のモデルが欲しいがマシンを管理したくない」人に適している。

続きは

ツールを選んだら、次の本当の問題は最初のフローをどう組むかだ。三つのノードを空白のキャンバスから結果が出るまで走らせる方法は、『最初のワークフロー』に書いてある。インターフェースにまだ慣れていない人は、まずそちらを。『n8n インターフェースガイド』。順番に読む場合は、コース総目次から入り、各記事は単独でも読めます。

参考資料

• n8n Pricing：各プランの実行枠、同時実行数、1回あたりの実行時間上限
• Understand executions：何が1回の実行と見なされるか、どのトリガー方式が枠に算入されるか
• Community license：Sustainable Use License が許可・禁止する用法、コンサルティングサービスの定義を含む
• Zapier Pricing：task 課金ルール、無料版の2ステップ制限、トライアルの説明
• Make Pricing：credit 課金ルール、各プランの価格と無料プランの枠

最終更新：2026年10月26日、n8n 2.43.7を使用。