コラム /
Zapier / Make / n8n の現実的な選び方 ─ コスト・複雑さ・運用負荷で判断する
📖 約5分 / 公開日: 2026/05/24
Zapier を使っている会社が n8n に切り替えて月5万円のコスト削減に成功した、という話は2023年頃から業務改善界隈でよく出回るようになった。一方で「n8n に移ったら運用担当が疲弊してZapierに戻した」という話も同じくらいある。どちらも嘘ではなく、ツールの選択が組織のリソース構成にどれだけ依存しているかを示している。
3つのツールを整理する。Zapier は2011年創業、現在もノーコード自動化の最大手。Make（旧Integromat）は2016年にチェコ発、2022年にリブランド。n8n は2019年にドイツで誕生したオープンソースで、セルフホストが可能なのが最大の特徴だ。この3つが「ローコード自動化」の文脈で並べられることが多いが、想定ユーザーとアーキテクチャ思想はかなり異なる。
## 価格の現実
Zapier のFreeプランは月100タスクまで。スタートアッププランが月19.99ドル（年払い）で750タスク。実務で使い始めると、Slackへの通知・CRMへの書き込み・スプレッドシートへのログ追記で1フローだけで1日20タスクを消費することがある。月500タスクは意外と早い。チームで複数のZapが走り始めると Professional の月49ドルでは足りなくなり、Teamプラン 69ドル/月 に手が伸びる。年払いでも年間8万円超という数字は、小規模なチームには重い。
Make は月1,000オペレーション無料、Coreが月9ドルから。オペレーションの概念がZapierのタスクと若干違い、1フロー内のモジュール実行数単位で消費する。分岐やループを多用するシナリオではオペレーション消費が想定の2〜3倍になることがあるため、試算時には注意が要る。それでも同じ処理量なら Zapier の1/3〜1/4 の費用で収まるケースが多く、コストパフォーマンスは明らかに高い。
n8n はセルフホストなら基本無料。AWS の t3.small で月15ドル前後、Hetzner の CX21 ならさらに安く月7〜8ユーロで動く。クラウド版（n8n.cloud）は月20ドルから。ただしセルフホストは「無料」ではなく「サーバー管理コストとエンジニア工数がかかる」と捉えた方が正確だ。月7ユーロのサーバー費用の裏側に、ミドルウェアのアップデート・バックアップ設計・SSL証明書の管理・障害時の対応工数が乗ってくる。
## 何が向いていて何が向いていないか
Zapier が強いのは、非エンジニアが一人でフローを組んで回す場面だ。HubSpot → Slack → Google Sheets の連携を、コーディング知識ゼロの担当者がドキュメントだけで構築できる。コネクタの数は2024年時点で7,000超。ニッチなSaaSでもたいてい対応している。エラーメッセージも分かりやすく、トリガーのテストも直感的。問題は価格のスケーラビリティだ。自動化が増えれば増えるほど費用が跳ね上がる構造で、組織全体のフローを一元管理しようとすると月額費用が膨らみやすい。
Make は複雑なデータ変換と条件分岐に強い。HTTPリクエスト、JSONのパースと整形、配列の展開と再構築が視覚的に組める。Zapierでは「これを実現するためのZapを5本作らないといけない」という処理が、Makeなら1シナリオで完結することが多い。APIが整備されていないレガシーなシステムとつなぐ場合でも、カスタムHTTPモジュールで対応しやすい。欠点は学習コストとUIの複雑さで、初見で迷子になるユーザーは少なくない。Zapierと比べて「ぱっと見て何をしているかわかる」という感覚には欠ける。
n8n は「コードも書けるエンジニアが業務フローを自動化する」用途に最もマッチする。Function ノードで JavaScript が書けるので、Zapier や Make では不可能な柔軟な変換処理が組める。Webhookの受け取りと複数エンドポイントへの並列送信、条件分岐の深いネスト、スクレイピングの組み込みも現実的にできる。オープンソースなので社内ネットワーク内で完結させたい金融・医療・官公庁系の案件にも使える。これは Zapier / Make には原則できない点だ。
## 失敗パターンと教訓
「エンジニアがいないからZapierで自動化した」という構成でよくある失敗は、フロー設計者の退職後に誰も触れなくなるという問題だ。設計者以外には中身が見えないし、仕様書もない。外部APIの仕様が変わってフローが止まっても原因の特定に丸1日かかる。Zapierは便利だが、組織の自動化資産としての管理体制がないと技術負債になりやすい。
Makeに移行してオペレーション数の管理を怠った結果、月の途中でシナリオが止まるという事故も定番だ。特に月次バッチで大量のデータを処理するフローは、1回の実行でオペレーションを使い切ることがある。Makeはオペレーション枯渇時にフローを中断するのではなく「スキップ」する実装になっているため、気づかないまま何日もデータが欠落していたケースがある。アラート設定は必須だ。
n8n のセルフホストで見る失敗の筆頭は、バージョンアップの放置だ。n8n はメジャーバージョンアップ時に破壊的変更が入ることがあり、6ヶ月アップデートをサボっていたら v0.x から v1.x へのマイグレーションで設定が全滅、という話を複数のチームから聞いている。セルフホストは「初期構築して終わり」ではなく、継続的なメンテナンスを想定した運用設計が必要だ。もう一つ盲点なのが、n8n のワークフロー定義の管理だ。GUIで作ったフローをgitで管理しているチームは少なく、「誰かがうっかり消した」「本番を直接編集して動かなくなった」という事故が起きやすい。
## 選定の基準
費用対効果だけで考えると、月タスクが5,000を超えるあたりからZapierは割高になる。その規模になったらMakeへの移行を検討する価値がある。さらにカスタムロジックが必要で、かつエンジニアリソースがあるなら n8n のセルフホストは選択肢に入る。
「安いから」だけで n8n に移るのは推奨しない。ツールの移行コストは見えにくい。フローの棚卸し、動作確認、ドキュメント整備、担当者へのレクチャー、これだけで小規模な会社でも数日を要する。既存の Zapier フローが10本以下で安定動作しているなら、現状維持の方が総コストは低いことも多い。
組織に自動化専任担当がいて複雑なフローを継続的に構築・改善していくなら Make の習熟投資は回収できる。エンジニアが関与できてセキュリティ要件が厳しいなら n8n。「とにかく今週中に動かしたい」「非エンジニアが担当する」ならZapier。この3軸で判断すれば、ツール選定でそこまで悩まなくて済む。
付け加えると、3つを「使い分ける」という構成も現実的だ。外部向けのシンプルな通知フローはZapierで一元管理し、社内の複雑なデータ変換はMakeで構築する。この組み合わせで運用している会社は実際に増えている。ツールを1つに統一しなければならないという制約はない。自動化ツールの多様化は「管理が煩雑になる」という懸念より、「適材適所で運用コストを下げる」という実利の方が大きいことが多い。
3つのツールを整理する。Zapier は2011年創業、現在もノーコード自動化の最大手。Make（旧Integromat）は2016年にチェコ発、2022年にリブランド。n8n は2019年にドイツで誕生したオープンソースで、セルフホストが可能なのが最大の特徴だ。この3つが「ローコード自動化」の文脈で並べられることが多いが、想定ユーザーとアーキテクチャ思想はかなり異なる。
## 価格の現実
Zapier のFreeプランは月100タスクまで。スタートアッププランが月19.99ドル（年払い）で750タスク。実務で使い始めると、Slackへの通知・CRMへの書き込み・スプレッドシートへのログ追記で1フローだけで1日20タスクを消費することがある。月500タスクは意外と早い。チームで複数のZapが走り始めると Professional の月49ドルでは足りなくなり、Teamプラン 69ドル/月 に手が伸びる。年払いでも年間8万円超という数字は、小規模なチームには重い。
Make は月1,000オペレーション無料、Coreが月9ドルから。オペレーションの概念がZapierのタスクと若干違い、1フロー内のモジュール実行数単位で消費する。分岐やループを多用するシナリオではオペレーション消費が想定の2〜3倍になることがあるため、試算時には注意が要る。それでも同じ処理量なら Zapier の1/3〜1/4 の費用で収まるケースが多く、コストパフォーマンスは明らかに高い。
n8n はセルフホストなら基本無料。AWS の t3.small で月15ドル前後、Hetzner の CX21 ならさらに安く月7〜8ユーロで動く。クラウド版（n8n.cloud）は月20ドルから。ただしセルフホストは「無料」ではなく「サーバー管理コストとエンジニア工数がかかる」と捉えた方が正確だ。月7ユーロのサーバー費用の裏側に、ミドルウェアのアップデート・バックアップ設計・SSL証明書の管理・障害時の対応工数が乗ってくる。
## 何が向いていて何が向いていないか
Zapier が強いのは、非エンジニアが一人でフローを組んで回す場面だ。HubSpot → Slack → Google Sheets の連携を、コーディング知識ゼロの担当者がドキュメントだけで構築できる。コネクタの数は2024年時点で7,000超。ニッチなSaaSでもたいてい対応している。エラーメッセージも分かりやすく、トリガーのテストも直感的。問題は価格のスケーラビリティだ。自動化が増えれば増えるほど費用が跳ね上がる構造で、組織全体のフローを一元管理しようとすると月額費用が膨らみやすい。
Make は複雑なデータ変換と条件分岐に強い。HTTPリクエスト、JSONのパースと整形、配列の展開と再構築が視覚的に組める。Zapierでは「これを実現するためのZapを5本作らないといけない」という処理が、Makeなら1シナリオで完結することが多い。APIが整備されていないレガシーなシステムとつなぐ場合でも、カスタムHTTPモジュールで対応しやすい。欠点は学習コストとUIの複雑さで、初見で迷子になるユーザーは少なくない。Zapierと比べて「ぱっと見て何をしているかわかる」という感覚には欠ける。
n8n は「コードも書けるエンジニアが業務フローを自動化する」用途に最もマッチする。Function ノードで JavaScript が書けるので、Zapier や Make では不可能な柔軟な変換処理が組める。Webhookの受け取りと複数エンドポイントへの並列送信、条件分岐の深いネスト、スクレイピングの組み込みも現実的にできる。オープンソースなので社内ネットワーク内で完結させたい金融・医療・官公庁系の案件にも使える。これは Zapier / Make には原則できない点だ。
## 失敗パターンと教訓
「エンジニアがいないからZapierで自動化した」という構成でよくある失敗は、フロー設計者の退職後に誰も触れなくなるという問題だ。設計者以外には中身が見えないし、仕様書もない。外部APIの仕様が変わってフローが止まっても原因の特定に丸1日かかる。Zapierは便利だが、組織の自動化資産としての管理体制がないと技術負債になりやすい。
Makeに移行してオペレーション数の管理を怠った結果、月の途中でシナリオが止まるという事故も定番だ。特に月次バッチで大量のデータを処理するフローは、1回の実行でオペレーションを使い切ることがある。Makeはオペレーション枯渇時にフローを中断するのではなく「スキップ」する実装になっているため、気づかないまま何日もデータが欠落していたケースがある。アラート設定は必須だ。
n8n のセルフホストで見る失敗の筆頭は、バージョンアップの放置だ。n8n はメジャーバージョンアップ時に破壊的変更が入ることがあり、6ヶ月アップデートをサボっていたら v0.x から v1.x へのマイグレーションで設定が全滅、という話を複数のチームから聞いている。セルフホストは「初期構築して終わり」ではなく、継続的なメンテナンスを想定した運用設計が必要だ。もう一つ盲点なのが、n8n のワークフロー定義の管理だ。GUIで作ったフローをgitで管理しているチームは少なく、「誰かがうっかり消した」「本番を直接編集して動かなくなった」という事故が起きやすい。
## 選定の基準
費用対効果だけで考えると、月タスクが5,000を超えるあたりからZapierは割高になる。その規模になったらMakeへの移行を検討する価値がある。さらにカスタムロジックが必要で、かつエンジニアリソースがあるなら n8n のセルフホストは選択肢に入る。
「安いから」だけで n8n に移るのは推奨しない。ツールの移行コストは見えにくい。フローの棚卸し、動作確認、ドキュメント整備、担当者へのレクチャー、これだけで小規模な会社でも数日を要する。既存の Zapier フローが10本以下で安定動作しているなら、現状維持の方が総コストは低いことも多い。
組織に自動化専任担当がいて複雑なフローを継続的に構築・改善していくなら Make の習熟投資は回収できる。エンジニアが関与できてセキュリティ要件が厳しいなら n8n。「とにかく今週中に動かしたい」「非エンジニアが担当する」ならZapier。この3軸で判断すれば、ツール選定でそこまで悩まなくて済む。
付け加えると、3つを「使い分ける」という構成も現実的だ。外部向けのシンプルな通知フローはZapierで一元管理し、社内の複雑なデータ変換はMakeで構築する。この組み合わせで運用している会社は実際に増えている。ツールを1つに統一しなければならないという制約はない。自動化ツールの多様化は「管理が煩雑になる」という懸念より、「適材適所で運用コストを下げる」という実利の方が大きいことが多い。