ZapierとMakeの比較、料金表を見比べても決まらないのは普通です

ZapierとMakeの料金ページを、別タブで並べて開いている。数え方の単位、月額、無料枠の上限。

数字は全部読める。どっちが自分に合うかだけが、どこにも書いていない。

ZapierとMakeは課金の数え方が違う。Zapierは成功したアクションだけを1タスクと数え、Makeは実行されたモジュールを1オペレーションと数える。料金表を並べる前に、自分のフローが何単位を消費するかを数えるのが正しい順序になる。

• Zapierはトリガー・フィルタ・分岐を数えない。失敗したアクションすら数えない。課金されるのは成功したアクションだけ。
• Makeはトリガーが0件でも1オペレーションを消費する。さらに前段のバンドル数が、後続のモジュール全体に乗算で効く。
• 無料枠の「100 tasks」と「1,000 operations」は単位が違うため、数値のまま比べても意味がない。

ZapierとMakeは、同じ数え方をしていない

「ZapierとMake、どっちが安いか」で検索すると、無料枠が100と1,000だから10倍お得だ、という比較が並ぶ。だがこの2つの数字は、そもそも同じものを数えていない。単位の定義が違うものを割り算しても、出てくるのは意味のない比率だけである。

Zapierの料金ページにある定義は「a task is counted whenever Zapier successfully completes a unit of work」だ。成功した1単位の処理ごとに1タスク。ここで重要なのは successfully の一語で、これが後述する非対称の起点になる。

一方Makeの定義は「Each module action in your scenario, like adding a Google Sheet row or fetching Gmail account data, counts as one credit」。シナリオの中でモジュールが1アクション動けば1オペレーションである。read / search / create / update / delete / transform / aggregate / iterate がそれぞれ該当する。シナリオ（ワークフロー全体）とオペレーション（その中の1動作）は別物で、ここを混同すると見積もりが一桁ずれる。

両者の公式ヘルプを突き合わせると、EC実務に直接効いてくる非対称が3つ出てくる。

1つ目はトリガーである。Zapierの公式ヘルプは「All trigger steps」を使用量に数えないと明記している。数分おきに楽天RMSの新規注文をポーリングしても、注文が1件も無ければタスクは減らない。対してMakeは、トリガーモジュールについて「only run once to check for or retrieve data, regardless of the number of bundles returned」と書いている。返ってきたバンドルの数に関係なく1回動く、つまり取得件数が0でも1オペレーションを消費する。空振りが前提の監視——受注が来ていないか、在庫が閾値を割っていないか、低評価レビューが付いていないか——を高頻度で回すほど、Makeは何も起きていない時間にも目減りしていく。

2つ目は分岐とフィルタである。Zapierは「Any Filter or Paths step」を消費しないと明記している。決済確認済みの注文だけを通すフィルタも、問い合わせを3方向に振り分けるPathsも、ステップとしては0タスクだ。Formatter・Delay・Loopingも同じく消費しない側に列挙されている。Makeについては、モジュール間に置くフィルタやルーターそれ自体が消費されるかどうか、公式ヘルプに明記が見当たらなかった。消費するとも、しないとも書かない。ここは断定できる材料が無い領域である。

3つ目は失敗の扱いである。Zapierは「All action steps that error or halt」を使用量に数えないと書いている。楽天RMS WEB APIの認証が切れていて連携が全部こけていた月でも、こけた分で請求が膨らむことはない。Makeの公式ヘルプには、エラーになったモジュールを課金対象から外すという記述を確認できなかった。

そしてMake側には、Zapierに対応物のない構造がひとつある。公式ヘルプの「bundles in earlier modules have a multiplying effect on the operations in the rest of the scenario」という一文だ。前段のモジュールが出したバンドル数が、シナリオの残り全体に乗算で効く。公式の例では、トリガーが10バンドルを返すと後続の各モジュールがそれぞれ10オペレーションを消費する。EC実務で言えば、1日分の出荷確定CSVをイテレータで注文ごとに割ったあと、その先に「RMSの受注管理へ送り状番号を登録する」「顧客へ出荷通知メールを送る」と2つ並べれば、後続は件数分だけ動く。積み上げではなく掛け算だという点が、月末の請求で効いてくる。

自分のフローが何単位を消費するか、自分で数える手順

定義が違う以上、価格の比較より先にやることがある。自分のフローを開いて、単位を数えることだ。以下は電卓さえあればできる。

手順1: フローを1本、ステップに分解して書き出す。ツールの編集画面を開いたまま、スプレッドシートに1行1ステップで写すのが早い。起点（何をきっかけに動くか）と、そのあとに続く動作を並べる。「受注が入ったら」「決済確認済みだけ残して」「Google Sheetsに行を追加して」「在庫管理システムへ送る」といった粒度でいい。画面を見ながら写すと、後から足した通知ステップの数え漏れが減る。

手順2: トリガーと Filter・Paths・Formatter・Delay・Looping を除いた、「成功したアクションステップ」の数を数える。この数がZapierのタスク数になる。ここで「外部に書き込む動作」だけを数えてはいけない。公式の文言は “All successful action steps” であり、外部への書き込みだけでなく、検索・取得系のアクションも1つと数える。Google Sheetsの行を検索する、既存の顧客レコードを引く、といったステップがこれに当たる（検索ステップは「見つからなくても次に進む」設定のとき1タスクとして計上される）。仮にアクションステップが3つあるフローなら、1回動くごとに3タスクである。書き込む動作だけを数えると消費量を実際より少なく見積もることになり、小さい刻みのプランを選んで月の途中で上限に当たる。

手順3: Makeは、起点も含めて「動くモジュール」を全部数える。起点1つとアクション3つが動くなら、少なくとも4オペレーションになる。「少なくとも」と書いたのは、フィルタ・ルーター・イテレータそれ自体を数えるかどうかが公式ヘルプで確認できないからだ。制御系の要素を挟むフローでは、この4という数字は下限として扱う。実際の消費量は自分のシナリオを1回実行して、管理画面の消費量が実行前後でいくつ増えたかを見るのが確実である。

手順4: 「1回のイベントで何件処理するか」を掛ける。ここがMake固有の項目になる。1回のトリガーで1レコードしか扱わないなら1倍。CSVの行ごと、注文の明細行ごとにイテレータで割るなら、割った件数がそのまま後続に乗る。前述の乗算構造である。Zapier側でも、Loopingステップの制御部分は消費しないが、ループの中で実行されるアクションは実行された回数だけ課金される。「ループなら無料」ではない点は両者とも同じである。

手順5: 月間の発生回数を掛ける。ここは公開統計に頼らず、自分の実数を使う。受注件数はRMSの受注管理やセラーセントラルの注文レポートから、問い合わせ件数はメールボックスの月次件数から出せる。1日あたりの件数×稼働日数でいい。お買い物マラソンやスーパーSALEのある月が平常月の何倍になるかを、直近1年の受注実績から出しておくと、上限に張り付く月を先に見つけられる。

この手順で出るのは、Zapierなら「成功したアクションステップの数 × 月間発生回数」、Makeなら「動くモジュールの数 × 1回あたり処理件数 × 月間発生回数（＋制御系の分だけ上振れ）」という2つの数字だ。単位が違うので、この2つを直接比べてはいけない。それぞれの数字を、それぞれの料金ページの含有量と突き合わせる。比較すべきは数字同士ではなく、自分の消費量が各社のどのプランの含有量に収まるか、という各社内での位置である。

ひとつ注意がある。イベントの発生源が複数ある業務では、フローを1本だけ数えても足りない。楽天・Amazon・自社Shopifyの3チャネルで受注を拾っているなら、フローも3本走っていることが多い。数えるのはフロー単位ではなく、月に動く全部の合計になる。

無料プランで足りる業務、足りない業務

結論から言うと、無料プランで足りるかどうかは、消費量よりも先に機能のゲートで決まる。数が足りていても、必要な機能が無料プランで使えなければそこで止まる。

Zapier Freeは月100タスク。ただし制約はタスク数ではない。公式料金ページによれば、Freeではマルチステップの Zap・プレミアムアプリ・Paths / Filter・Webhook・チーム機能がいずれも使えない。つまりFreeで組めるのは「トリガー1つ＋アクション1つ」の1対1連携に限られる。「新しい問い合わせフォームの回答が来たらSlackに流す」「Shopify Adminに新規注文が入ったらGoogle Sheetsに1行足す」までなら成立する。だが「決済確認済みのものだけ通す」を足した瞬間にFilterが要り、有料の側に移る。

Makeは無料プランで月1,000オペレーション。こちらの制約はシナリオの最小実行間隔で、Freeは15分間隔が下限となる。カスタム変数と全文ログ検索、チーム機能も無い。15分間隔という制約は、業務によって重みがまるで違う。日次の売上集計や、翌営業日出荷が前提の受注取り込みなら15分の遅れは実害にならない。一方、在庫の即時同期は話が別だ。複数モールに同一SKUを載せていて、片方で売れた分の在庫引当をもう片方へ反映するまでに最大15分空くなら、その15分は売り越しのリスク時間そのものになる。売れ筋の在庫が1桁のときに効いてくる。

ここで冒頭の話に戻る。100 tasks と 1,000 operations を並べて「Makeは10倍」と読むのは誤りだ。1タスクと1オペレーションは同じ仕事量ではない。Zapierの100タスクは「成功したアクション100回分」で、その手前のトリガーもフィルタも含んでいない。Makeの1,000オペレーションは「動いたモジュール1,000回分」で、空振りしたトリガーの回数もそこに含まれる。15分間隔で1つのシナリオを24時間動かし続けると、トリガーだけで1日96回、30日で2,880回になる計算だ。何も取得できなくても回るのだから、無料枠の1,000は監視型のシナリオを常時回すには足りない。Makeの無料枠は、常時監視ではなく「1日数回のスケジュール実行」の形に寄せると持ちやすい。

まとめると、無料プランを検討する順序はこうなる。まず自分のフローに Filter や分岐が要るかを見る。要るならZapierのFreeは選択肢から外れる。次に、遅延の許容時間を見る。15分の遅れが業務上許されないならMakeのFreeは外れる。この2つを通過してはじめて、消費量の話になる。

有料プランの価格は、タスク数・オペレーション数とセットで読む

比較記事でよく見かける「Zapierは月$19.99から」という書き方は、正確ではない。Zapier Professionalは含まれるタスク数の刻みごとに価格が変わる段階制だからだ。公式料金ページの表示では、750タスクの刻みで年払い$19.99/月、2,000タスクの刻みでは年払い$49.00/月になる。月払いを選ぶと750タスクで$29.99/月、2,000タスクで$73.50/月だ（いずれも2026年8月時点の公式料金ページ表示）。含有量の刻みは750から2,000,000まで用意されている。つまり$19.99は最小の刻みの値段であって、Professionalという名前の定額ではない。

ここで手順5の数字が効いてくる。月間タスク数の見積もりが無いまま料金表を眺めても、自分がどの刻みにいるのか分からない。逆に「月に何タスク」が出ていれば、その刻みの価格を1点だけ見ればいい。料金表は上から順に読むものではなく、自分の消費量で1行を引き当てるものである。

Zapierの上位にあるTeamは、2,000タスク時に年払い$69.00/月（月払い$103.50/月）と表示されていた（2026年8月時点の公式料金ページ表示）。Teamの含有量は2,000タスクからで、750タスクから選べるProfessionalとは最小の刻みが違う。同じ2,000タスクで比べたときの差は、チーム共同編集と25ユーザーの枠にある。Enterpriseは個別見積で、公開価格は無い。

Makeの料金ページは、2026年8月時点の掲載内容で月払い表示が前面に出ている。Coreが月$9、Proが月$16、Teamsが月$29で、いずれも10,000オペレーションが付く表示になっていた。年払いについては「15%以上お得になる」旨の表記が確認できた一方、取得した時点のページ表示からは、プランごとの年払い実額を読み取れなかった。したがってこの記事ではMakeの年払い額を書かない。料金ページの支払いサイクルを Annually 側に切り替えると実額が表示される場合があるので、総額を先に確定させたいなら、自分で切り替えて確認するのが確実である。Zapier側は年払いの月額換算がそのまま表示されているので、稟議に載せる数字を作りやすい。

そしてMakeのCoreとProの差は、含まれるオペレーション数ではなく機能側にあると読むのが妥当だ。取得時点の表示では両方10,000に見えたが、そこから読み取れる差は、カスタム変数と全文ログ検索の有無だった。全文ログ検索は、EC実務では地味に効く。「先週の火曜に出荷通知が飛ばなかった注文番号」を探すとき、実行ログを1件ずつ開いて回るのと、注文番号で串刺しに検索できるのとでは、原因特定にかかる時間が変わる。

比較にあたっての注意を2つ。第一に、支払い条件を揃えずに価格を並べない。Zapierの$19.99は年払いの月額換算、Makeの$9は月払いの表示であり、この2つを並べた表はそもそも成立しない。第二に、いずれもUSD建てで、為替と税は考慮していない。円で予算を取るなら、社内のレートを別途当てる必要がある。

比較表 — EC実務の作業量で見るZapierとMake

ここまでの内容を1枚にまとめる。断っておくと、この表に価格は載せていない。Zapierは段階制、Makeは年払い実額が読み取れず、しかも表示の支払い条件が違う。条件の揃わない数字を1つの表に並べると、比較しているつもりで誤読を作ることになる。載せたのは、価格より先に効いてくる「数え方」の側だけである。単位が違って数値のまま比べられない項目は、比べずにそのまま並べてある。

比較軸	Zapier	Make	EC実務者との相性
課金の数え方	成功したアクションだけ1タスク	実行したモジュールごとに1オペレーション	工程の数え方そのものが違う
トリガー	消費しない	0件でも1オペレーション消費	空振りの多い監視ほどMakeは目減りする
失敗した処理	課金されない	公式ヘルプに明記なし	エラーが続く時期はZapierの方が読める
分岐・フィルタ	消費しない	公式ヘルプに明記なし	仕分けの多い業務はZapierが数えやすい
無料枠	100 tasks/月	1,000 operations/月	単位が違うので数値のまま比べられない

「公式ヘルプに明記なし」という欄をそのまま残したのは、埋められなかったからではない。見積もりが立たない箇所を、立つように見せかけないためである。この記事の根拠は、両社の公式料金ページと公式ヘルプを直接読んだ内容であって、有料プランでの実測ではない。他社の比較記事にはMakeのフィルタやルーターの消費有無を断定しているものもあるが、公式ヘルプにその記述を確認できなかった以上、ここでは書かない。この点が自分の業務にとって決定的なら、無料プランでシナリオを1本組み、フィルタありとなしで実行して消費量の差を見る。数分で済むうえ、他人の記事より自分のアカウントの実測のほうが確実である。

EC実務でよくある自動化を、数え方に当てはめる

抽象的なままだと使えないので、手順1〜5をよくある3つのフローに当ててみる。以下は構造の分解であって、消費量の実測値ではない。読者が自分のフローに置き換えて数えるための型として読んでほしい。

受注データの複数モール集約。楽天RMSに新規注文が入る、決済確認済みだけを残す、Google Sheetsに1行追加する、在庫管理システムへHTTPで送る——という並びになる。Zapierが数えるのは、フィルタを通過したあとに動くアクションステップ、つまり「Sheetsへの行追加」と「HTTP送信」である。トリガーもフィルタも0だ。ここに、モール別商品番号と自社の商品管理番号を突き合わせる検索ステップを足すなら、書き込まないステップであってもアクションステップとして1つ数に入る。書き込むかどうかではなく、アクションステップが動いたかどうかで数える。Makeは起点のモジュールも数に入るため、フィルタを別にしても動くモジュールはZapierより1つ多い。チャネルが3つあればフローも3本になり、その全部で起点分が積まれることは覚えておきたい。

在庫数の複数モール同期。Shopify Adminで在庫が動く、閾値を割ったものだけ残す、楽天RMS WEB APIへ反映、Amazon SP-APIへ反映。1回のイベントで1SKUを処理する構造なので、乗算は効かない。この形は両者の差が最も出にくい。差が出るのは前節で触れた実行間隔のほうである。

出荷確定CSVの一括処理。ここが最も差の開く形になる。WMSや配送業者の送り状発行システムから1日分の出荷確定CSVを受け取り、注文ごとに分割し、それぞれについてRMSの受注管理へ伝票番号を登録し、顧客へ出荷通知メールを送る。Makeではイテレータが1つのバンドルを注文件数分に割るため、後続の各モジュールが件数分だけ動く。公式の言う乗算構造がそのまま当たる場面だ。Zapierも、ループの中のアクションは実行回数分課金されるので、件数に比例して増えること自体は変わらない。違うのは、Makeでは起点と制御系がその上に乗る一方、Zapierは制御部分が0のままである点だ。1日20件と1日200件では月末の絵が変わるので、繁忙期の件数で見積もる。

数え方を持っておくと、副次的な効用もある。消費量が急に減った月は、節約できたのではなく壊れている可能性がある。楽天RMS WEB APIやAmazon SP-APIの認証・トークンには有効期限があり、切れたあともフロー自体は動き続ける。Zapierは失敗したアクションを課金しないので、この状態では請求だけがおとなしくなる。管理画面のエラー通知を見ていなければ、「今月は安く済んだ」と読み違えることになる。同種の落とし穴として、Shift-JISで出力されるモール系CSVを前提の違うツールで読んで文字化けする、再実行時に処理済みフラグを条件に入れておらず同じ注文へ出荷通知が二重に飛ぶ、といった構造的なリスクもある。いずれも件数の見積もりとは別の話だが、フローを組む前に条件として洗い出しておく価値はある。

なお、この記事は料金と作業量の見積もり方に絞っている。UIの触りやすさや学習コスト、Shopify・BASE・STORES・freeeといった個別サービスとの連携可否、エラー通知や再実行まわりの信頼性は、いずれも選定で重要な観点だが、手元に実測の材料が無いため今回は扱っていない。連携可否については、各社のアプリ一覧で自分が使うサービス名を検索するのが早い。

ツールの選定は、それ自体が目的ではない。どちらを選んでも、フローを工程に分解し、どこがボトルネックかを見て、条件を決めるのは現場を知っている人間の仕事として残る。自動化ツールが代替するのは工程の実行であって、工程の設計ではない。その先、EC実務者がどこまでを自分の領域として持っておくべきかは、EC担当者がAI時代に学ぶべきスキルを、業務を3つに分けて整理した記事にまとめてある。

よくある質問

無料プランだけでどこまでできますか。

Zapier Freeは「トリガー1つ＋アクション1つ」の1対1連携までです。マルチステップ・Paths / Filter・Webhook・プレミアムアプリが使えないため、条件で仕分けをする時点で有料側に移ります。Make Freeは月1,000オペレーションで分岐は組めますが、シナリオの最小実行間隔が15分です。在庫の即時同期のように遅延が損失に直結する業務では、この15分が制約になります。

Zapierの2,000タスクは、月にどれくらいの作業量ですか。

フローの形によって変わるので、一律の換算はできません。数えるのは、トリガーとフィルタ・分岐を除いた「成功したアクションステップ」の数です。外部への書き込みだけでなく、検索・取得系のアクションも1つと数えます。アクションステップが2つのフローなら1回動くごとに2消費なので、2,000タスクはそのフローが月1,000回動く量にあたります。アクションステップが4つなら500回分です。本文の手順1〜5で、自分のフローの数字を先に出してください。

Makeの年払いはいくら安くなりますか。

公式料金ページには「15%以上お得になる」旨の表記がありましたが、取得時点のページ表示からプランごとの年払い実額を読み取れなかったため、この記事では実額を書いていません（2026年8月時点で確認）。支払いサイクルを Annually に切り替えると表示される場合があるので、契約前にご自身で確認してください。Zapierは年払いの月額換算が料金ページに表示されています。

Makeのフィルタやルーターはオペレーションを消費しますか。

公式ヘルプに明記を確認できませんでした。この記事で断定していないのはそのためです。確実なのは、無料プランでそのシナリオを1本組み、実行前後で消費量がいくつ増えたかを見ることです。フィルタや分岐を多用する予定なら、本契約の前にこの1回の実測をしておく価値があります。

結局どちらを選べばいいですか。

フローを数えた結果で決まります。仕分けや分岐が多く、失敗しやすい連携を抱えているならZapierのほうが消費量を読みやすい構造です。1回のイベントから複数件をまとめて処理する形が主なら、Makeの乗算構造を見積もりに織り込む必要があります。価格から入らず、数えてから料金表の1行を引き当ててください。