ZapierからMakeやn8nへ乗り換えるか:移行前に洗い出すこと

不満の原因を3つに分ける

「Zapierが高い」「Zapierでは足りない」と感じたとき、次の3つのどれに近いかを先に決めます。

• 料金、典型的な声：請求額が増えた、タスク数が読めない、乗り換えで解決するか：課金単位が変われば解決することがある。試算が必要
• 機能、典型的な声：複雑な分岐やデータ加工がやりにくい、使いたいアプリがない、乗り換えで解決するか：移行先に代替があれば解決する。連携先の有無は個別確認
• 運用、典型的な声：誰が作ったか分からない、止まっても気づかない、乗り換えで解決するか：ほぼ解決しない。移行前に整理が必要

複数に当てはまる場合は、いちばん困っているものを一つ選んでください。移行の成否をその一点で測れます。

課金単位の違いを押さえる

料金が原因なら、3社で「何を1回と数えるか」が違う点が出発点です。以下は、各社の公式ページを確認できた範囲の内容です。

• Zapier:成功したアクションステップがタスクになります。トリガー、フィルター、パスは数えられず、失敗したアクションも数えられません。Formatter、Delay、Looping などの一部機能も対象外と書かれています(Zapierヘルプ:タスクの数え方)。
• Make:シナリオが実行する各アクションがクレジットを消費し、ほとんどは1アクション1クレジットです。AI機能はそれ以上を使うことがあります(Make料金ページ)。トリガーはデータが見つからない確認も1回1クレジットです。ルーター、フィルター、エラーハンドラーのモジュールは消費しません(Makeヘルプ:機能ごとのクレジット消費)。
• n8n:Cloudでは、ワークフロー全体の1回の実行を1 executionと数え、ステップ数やデータ量は問われないと説明されています。セルフホスト向けの Community Edition は無料で提供されています(n8n料金ページ、n8nドキュメント:エディションの比較)。利用には Sustainable Use License の条件があり、社内業務での利用などは認められていますが、顧客にワークフローを作成・編集させるサービス提供などは対象外です(n8nドキュメント:ライセンスFAQ)。サーバー代や保守の費用は別途見積もります。

プランの価格や上限は変わるため、ここでは金額を載せません。試算の前に各社の最新ページで確認してください。

説明用の試算例

説明用の例です。「フォーム受信→条件で絞る→表計算に追記→チャット通知」の4ステップのフローが、月1,000回動くとします。1回につき1件を処理し、全件が条件を通って成功し、追加の定期確認や再試行はないものとします。

• Zapier、数え方の考え方：トリガーとフィルターは数えず、2アクションが対象、月の消費の目安：約2,000タスク
• Make、数え方の考え方：トリガー1回と追記・通知各1回が対象。フィルターは消費しない、月の消費の目安：約3,000クレジット
• n8n Cloud、数え方の考え方：1回の実行を1と数える、月の消費の目安：1,000 executions

この例では、ステップ数が多いフローほどn8nの数え方が有利に働く可能性があります。一方、ステップ数が少なく実行回数が多いフローでは差が小さいか、逆転することもあります。自分のフローで必ず計算し直してください。

既存フローの棚卸し表

移行の判断は、フロー1本ずつの情報がないと始まりません。Zapierのダッシュボードを見ながら、次の列を埋めます。

• フロー名、書く内容：Zapの名前
• 目的、書く内容：何を自動化しているか(一文)
• トリガー、書く内容：アプリとイベント
• ステップ数、書く内容：実行されるアクションの数
• 月間実行回数、書く内容：直近の履歴から概算
• 連携アプリ、書く内容：使っているアプリ名
• 特殊な機能、書く内容：分岐、ループ、コード、AIステップ、遅延など
• 失敗時の影響、書く内容：止まると誰が困るか(高/中/低)
• 担当者、書く内容：直せる人の名前
• 最終確認日、書く内容：最後に動作を確認した日
• 移行判断、書く内容：移行/留まる/廃止

説明用の記入例です。

• 問い合わせ通知、目的：フォーム内容をチャットへ通知、ステップ数：3、月間回数：400、特殊な機能：なし、失敗時の影響：中、担当：佐藤、判断：試験移行の候補
• 請求書の整理、目的：受信メールの添付を保存、ステップ数：6、月間回数：80、特殊な機能：分岐、遅延、失敗時の影響：高、担当：不明、判断：先に担当者を決める
• 旧キャンペーン用、目的：旧フォームの集計、ステップ数：4、月間回数：0、特殊な機能：なし、失敗時の影響：低、担当：不明、判断：廃止

担当者が「不明」のフローは、乗り換え以前の問題です。 そのまま移すと、不明なまま新環境に持ち越します。廃止できるものは移行前に止めると、移行量も課金も減ります。

移行する・しないの判断項目リスト

棚卸しが終わったら、次の項目に「はい/いいえ」で答えます。

• 不満の中心は料金か。試算で下がる見込みがあるか、「はい」なら：移行寄り、「いいえ」なら：留まる寄り
• 必要なアプリの連携が移行先に存在するか、「はい」なら：移行可能、「いいえ」なら：HTTPリクエスト等で代替できるか確認。難しければ留まる
• 分岐・ループ・データ加工で今の構成に無理が出ているか、「はい」なら：移行寄り、「いいえ」なら：留まる寄り
• 担当者と手順が明確なフローが大半か、「はい」なら：移行可能、「いいえ」なら：先に整理
• 移行後の運用を担える人がいるか(特にセルフホスト)、「はい」なら：移行可能、「いいえ」なら：留まる、またはクラウド版を検討
• 失敗時の影響が「高」のフローを並行稼働で試せるか、「はい」なら：移行可能、「いいえ」なら：高影響のフローは最後にする
• チームでの共有やバージョン管理が必要か、「はい」なら：下の注意を確認、「いいえ」なら：影響なし

n8nのCommunity Editionには、ワークフローと認証情報の共有、Gitによるバージョン管理、プロジェクト管理などが含まれず、セルフホストでは有料のBusiness・Enterpriseプランの機能として案内されています(n8nドキュメント:エディションの比較)。複数人で運用する場合は、無料のセルフホストで足りるかを先に確認してください。

「はい」が料金の項目だけなら、移行しなくても、フローの統合や無駄なステップの削除で請求を減らせる場合があります。逆に、機能の項目に「はい」が複数あるなら、移行の価値は高いと言えます。

試験移行の進め方とAIの使いどころ

全面移行はせず、失敗時の影響が低く、ステップが少ないフローを1〜3本選んで試します。この記事で確認した資料には、Zapを自動変換してくれる仕組みの記述は見当たりませんでした。再構築が前提と考えて見積もってください。

AIには、棚卸し表の下書きと判断の整理を任せられます。渡す情報は、フロー名、ステップの種類、月間回数までにします。メールアドレス、顧客名、APIキー、Webhook URLは渡さず、「顧客A」「アプリX」のような仮の名前に置き換えます。n8nのワークフローをJSONで書き出す場合、認証情報の名前とIDが含まれます。ID自体は機密ではありませんが、名前には機密情報が含まれる場合があります。cURLから取り込んだHTTP Requestノードには認証ヘッダーが残る場合もあるため、共有前に確認し、機密情報を削除・匿名化してください(n8nドキュメント:エクスポート/インポート)。

依頼文の例です。

以下は業務自動化フローの棚卸し表(固有名詞は仮名に置換済み)です。
Zapierから、Make または n8n へ移行すべきか判断したいです。

【不満の中心】料金 / 機能 / 運用(いずれかを選択)
【表】
(ここに表を貼る)

お願い:
1. 各フローを「試験移行の候補」「先に整理が必要」「廃止候補」に分類し、理由を一文で添えてください。
2. 分類の根拠が表の情報だけでは足りない場合は、推測せず「要確認」と書き、確認すべき点を挙げてください。
3. 移行先のアプリ対応や料金は断定せず、公式ページで確認すべき項目として列挙してください。

AIの分類は下書きです。人が確認するのは次の3点です。

1. 各社の最新の料金ページで、課金単位と上限を確認する。
2. 必要なアプリの連携が移行先にあるかを、公式の一覧で確認する。
3. 試験移行したフローで、Makeのクレジット消費やn8nの実行数を実際に見て、試算と照らす。

試験の間は旧Zapも止めずに並行稼働させ、結果が一致するかを数日分比べてから切り替えます。一致を確認できなければ、そのフローは「留まる」にして構いません。