ZapierとMakeの違い｜課金単位と対応アプリ数で決める選び分けの基準

ZapierとMakeはどちらもSaaS同士をつなぐiPaaSですが、料金の数え方が根本から違います。Zapierは成功したアクション1件を1タスクと数え、Makeはモジュールの実行1回を1オペレーションと数える。この差は月末の請求額で数十倍に開きます。この記事では、2026年8月時点の公式料金と公式ヘルプの記述をもとに、両者が「数えないもの」の違い、月1,000件のフローを両方で組んだときの消費量の内訳、対応アプリ数9,955件と3,000件が実務のどこで効くか、そしてどちらも見送って受託開発へ切り替えるべき条件までを整理します。

まとめ：ZapierとMakeの違いは課金単位とアプリ対応数の2点に収束

結論から言えば、実行量が月3,000件を超えるフローではMakeが総額で有利です。Makeの Core は月9ドルで10,000クレジットを含み、Zapierの Professional は年払いでも月19.99ドルで750タスク。1件あたりの単価に直すと、およそ30倍の開きがあります。分岐や繰り返しを含む込み入ったフローほど、この差は広がります。

それでもZapierを選ぶ理由は、価格ではなく接続先です。Zapierは公式ページで9,955以上のアプリと表記し、Makeは3,000以上。候補のSaaSがZapierにしか載っていなければ、単価の差は検討の対象になりません。もうひとつは作る人で、画面の指示に沿って進めるZapierに対し、Makeはフロー図を自分で組み立てます。現場の担当者が自分で作って自分で直す運用なら、学習コストの低いZapierが現実的です。

判断の順番は、接続先の確認、作る人の確認、実行量の試算の3つ。この順で潰していくと候補は自然に1つに絞れます。逆に、データの整合性を業務側で担保しなければならない処理や、月数十万件の一括転送は、どちらのiPaaSでも扱いきれません。その場合は受託開発へ切り替える判断が必要になります。

ZapierとMakeの構造の違い｜直列のZapと分岐を描くシナリオ

料金の話に入る前に、2つのツールが自動化をどう表現するかを押さえておくと、後の消費量の計算が読みやすくなります。

Zapのトリガー1つとアクション直列で完結する単純な実行モデル

Zapierの自動化はZapと呼ばれ、トリガー1つとそれに続くアクションの直列で構成されます。フォームに回答が入ったら、CRMにレコードを作り、Slackに通知する。上から下へ順に流れるだけの構造です。

この単純さが、そのまま画面の分かりやすさになっています。次に何をするかを選ぶと、その下に枠が増えていく。フロー図を読む訓練が要りません。条件分岐はPathsという機能で表現しますが、これも「この条件ならこちらの列」という並列のレーンとして描かれ、線を引く操作は出てきません。

Makeのシナリオでルーターとイテレーターを標準で描ける表現力

Makeの自動化はシナリオと呼ばれ、円形のモジュールを線でつないだ図として組み立てます。分岐はルーター、繰り返しはイテレーターというモジュールを置いて表現し、途中で配列を展開したり、複数の経路の結果を再び1本に集約したりできます。

できることの幅は広い。ただし、線をどこにつなぐか、どのモジュールがどの形のデータを返すかを理解していないと組めません。Makeの公式ヘルプは、モジュールが返すデータのまとまりをバンドルという単位で説明しており、この概念を掴むまでが最初の壁になります。

フローを作る人が非エンジニアかどうかで分かれる学習コストの境界

両者の構造の差は、そのまま誰が作れるかの差になります。営業事務や人事の担当者が空き時間に組むならZapier、情報システム部門やエンジニアが組むならMake、という切り分けが実務では機能します。

境界の見極め方は単純です。作る予定の人がExcelのVLOOKUPやIF関数を自分で書けるかどうか。書けるならMakeのモジュール接続も習得できる範囲です。書けない場合、Makeで組んだフローは作った人以外に引き継げなくなり、後述の運用負担に跳ね返ります。Zapier単体の機能や料金の詳細は、Zapierの読み方とタスク課金の仕組みを整理した解説にまとめています。

課金単位の違い｜Zapierが数えないステップとMakeのモジュール課金

ここが両者を分ける最大の論点です。どちらも「実行するほど課金される」点は同じですが、何を数えないかが製品ごとに違います。

Zapierがタスクに数えないトリガーとFilterとFormatter

Zapierの公式Pricingは、タスクを「Zapierがあなたのために作業の単位を正常に完了したときに1件計上される」ものと定義しています。失敗したアクションは計上されません。

見落とされやすいのは、除外される側です。トリガーとポーリング、そしてFormatter・Paths・Filter・Delayといった組み込みのデータツールは、タスクとして数えられません。つまり日付の書式変換や条件による打ち切りを何段挟んでも、請求上はゼロです。5ステップのZapのうち3つがFilterとFormatterなら、1回の実行で消費するのは2タスクということになります。ただしZapier MCP経由のツール呼び出しは課金対象で、この点はZapier MCPのタスク消費と権限設計の解説で扱っています。

Makeがモジュール実行1回を1オペレーションと数える計算式

Makeの公式ヘルプは、オペレーションを「データを処理するか新しいデータを確認するためのモジュールの1回の実行」と定義しています。Gmailの送信モジュールがメールを5通送れば5オペレーション、Google Driveのアップロードモジュールが3ファイルを上げれば3オペレーションです。

例外はトリガーモジュールで、取得したバンドルの数に関わらず1回のみ計上されます。またルーターとエラーハンドラはクレジットを消費しません。データの整形を専用モジュールで行う場合はそれも1オペレーションになるため、Zapierと違って「整形は無料」という前提は置けません。

無料枠は100タスクと1,000クレジットで10倍開く月間上限

無料で試せる範囲にも差があります。Zapierの Free は月100タスク。Makeの Free は月1,000クレジットで、最小実行間隔15分、アクティブなシナリオは2本までという制約が付きます。

数字の上では10倍ですが、Zapierは整形と分岐を数えないので、同じフローでの実効差は10倍より縮みます。それでも月100タスクは、1日3件の処理で使い切る水準。試験導入で実データを流すなら、Makeの無料枠のほうが検証には向きます。

月1,000件の連携で試算するZapierとMakeの月額差と逆転条件

用語の定義だけでは判断できないので、同じフローを両方で組んだ場合の消費量を数えます。

フォーム受付をCRMとSlackへ流す月1,000件の消費量の内訳

想定するのは、問い合わせフォームの回答を受けて、日付とフリガナを整形し、対象の部署だけを絞り込み、CRMにレコードを作成してSlackへ通知するフローです。月間の受付は1,000件とします。

Zapierでの内訳は、トリガーが0、Formatterによる整形が0、Filterによる絞り込みが0、CRMのレコード作成が1、Slack通知が1。1件あたり2タスクで、月2,000タスクになります。Makeでの内訳は、トリガーが1、整形モジュールが1、ルーターが0、CRM作成が1、Slack送信が1。1件あたり4オペレーションで、月4,000クレジットです。消費する数そのものはMakeが2倍になります。

単価にして約30倍の開きが出るプラン別の月額と含み枠の比較表

ところが月額に直すと結果は逆転します。月2,000タスクのZapierは Professional の年払いで月49ドル、月払いなら73.50ドル。月4,000クレジットのMakeは Core の10,000クレジット枠に収まるため月9ドルです。消費量が2倍でも、支払いは5分の1以下になります。

単価は約30倍。この差はフローを工夫して埋められる幅ではありません。実行量が月に数千件を超えた時点で、総額の議論はMake優位で決着します。

Zapierのほうが安く収まる少量多品種という例外的な2つの条件

逆転が起きる条件は2つに限られます。1つは、フロー1本あたりの実行が月数十件で、そのかわり整形や分岐のステップが極端に多い場合。Zapierは組み込みツールを数えないため、10ステップのZapでも実質2〜3タスクに収まることがあります。

もう1つは、そもそもMakeに接続先が無く、HTTPモジュールで自作する工数が発生する場合です。この工数を人件費に換算すると、月40ドルの差は数か月で消えます。逆に言えば、この2条件のどちらにも当てはまらないなら、価格を理由にZapierを選ぶ根拠はありません。多製品を横並びで見たい場合は、iPaaS9製品の料金と課金単位を比較した記事で候補群ごと確認できます。

対応アプリ数9,955件と3,000件の差が効く場面と効かない場面

アプリ数は数字の大きさより、自分が使うSaaSが入っているかどうかで意味が決まります。

kintoneのように両方に載っていても対応版が違う場合の確認手順

国内SaaSの代表格であるkintoneは、両方に用意されています。Zapierは New Record トリガーと Create Record・Update Record by Record ID・Add Comment などのアクションを提供。Makeは Kintone (Legacy) として12モジュール、内訳はトリガー1・アクション9・検索2で、kintone社が提供元となる Verified 表示が付いています。

ここで見るべきは名前の有無ではなく、名称に付く但し書きと、必要な操作が揃っているかどうかです。Makeの表記が Legacy であることは、新しいAPIへの追随が別扱いになっている可能性を示します。候補のSaaSごとに公式のアプリ一覧を開き、使いたい操作がトリガー側とアクション側の双方に存在するかを、契約前に一覧で確かめてください。

一覧に無いときのWebhookとHTTPリクエストで自作する現実解

目的のSaaSが載っていなくても、対象がREST APIを公開していれば接続はできます。両者ともHTTPリクエストのモジュールとWebhookの受け口を備えており、認証情報を自分で設定して叩く形になります。

この自作を選ぶかどうかの分かれ目は、APIの認証方式です。APIキーをヘッダに載せるだけなら現場でも組めますが、OAuth 2.0のトークン更新を自前で回す構成になると、更新の失敗時にフローが黙って止まります。認証の更新まで面倒を見る必要が出た時点で、これは自動化ツールの設定作業ではなく開発案件だと切り替えたほうが安く済みます。

AIから自動化を叩くZapier MCPという接続経路の有無の差

2026年時点で両者の差が出ている領域が、生成AIからの呼び出しです。ZapierはMCPサーバーを提供し、対応するAIクライアントから自社のZapを操作できます。9,955以上というアプリ数がそのままAI側から触れる操作の幅になるため、この経路を前提にするならZapierが選択肢として残ります。

ただしMCP経由のツール呼び出しはタスクとして課金される点に注意が必要です。AIが試行錯誤して同じ操作を繰り返すと、想定より早く枠を消費します。呼び出せる操作の範囲を絞る権限設計を先に決めてから通してください。

ZapierとMakeの選び分け条件｜どちらも見送るべき業務の境界

ここまでの材料を、実際に発注や契約を決める形の条件に落とします。玉虫色の結論にはしません。

Makeを選ぶ条件は月3,000件超と分岐を含むフローの2つ

次の2つのどちらかに当てはまるならMakeを選んでください。月間の実行が3,000件を超える見込みがあること。もしくは、条件によって処理を分け、配列を1件ずつ回す構造が必要なこと。前者は単価差、後者はルーターとイテレーターの表現力が理由です。

あわせて、直す担当者が決まっていることが前提になります。この条件を満たせないままMakeを選ぶと、安く作ったフローが半年後に誰も触れない状態で残ります。

Zapierを選ぶ条件は接続先の有無と作る人が現場担当である場合

Makeのアプリ一覧に必要なSaaSが無い場合、価格差は検討から外してZapierにしてください。加えて、フローを作るのが情報システム部門ではなく現場の担当者で、月間の実行が数百件に収まるなら、Zapierの Professional 年払い19.99ドルで足ります。

この2つに当てはまらないのにZapierを選ぶと、実行量が伸びた時点でプランの階段を駆け上がることになります。月2,000タスクで年払い49ドル、Teamなら69ドル。想定より1桁多く流れたときの請求を、契約前に一度計算しておいてください。

両方とも見送って受託開発へ切り替えるべき3条件と失敗の典型例

次の3条件のいずれかに当てはまるなら、iPaaSは使わないほうが安全です。1つ目は、連携の途中でデータの整合性を保証する必要がある場合。在庫の引き当てや売上の計上のように、片方だけ書き込まれた状態が許されない処理は、iPaaSの逐次実行では守れません。2つ目は、業務ロジックが条件表で10行を超える場合。ルーターで表現すると図が読めなくなり、改修のたびに事故が起きます。3つ目は、月数十万件規模の一括転送で、これは連携基盤ではなくデータ処理の設計問題です。

典型的な失敗は、最初は3本だったフローが2年で40本に増え、誰がどれを作ったか分からなくなる形で起きます。増えた時点で作り直すのではなく、10本を超えた段階で棚卸しの担当を決めるのが実務的です。どこまでiPaaSで組み、どこから開発に回すかの線引きは、iPaaS導入支援（Zapier／Make／Workato／Yoom）で製品選定と実装の両面から相談できます。大量データの移送との切り分けはiPaaSとETLの違いを判定する記事が判断材料になります。

導入後に差が出る運用の負担｜エラー処理と実行間隔と担当者の交代

契約前には見えにくく、運用に入ってから効いてくる差が3つあります。

エラー時に止まるZapと途中から再開できるMakeの復旧の差

連携先のAPIが一時的に落ちたときの挙動が違います。ZapierはAutoreplayという再実行の仕組みを Professional・Team・Enterprise で提供しており、Free では使えません。実行全体を再生した場合、すでに成功していたステップも再びタスクとして計上されます。

Makeは未完了実行として保存され、あとから続きを流せる仕組みです。保存できる量は10,000クレジットあたり10MBという枠で決まります。復旧のたびに費用が積み増される構造ではないぶん、障害の多い連携先を抱える場合はMakeのほうが読みやすくなります。

最小実行間隔が15分と1分で分かれる無料枠と有料枠の実務の差

定期実行の粒度も異なる仕様です。Makeは Free が15分間隔、Core 以上で1分間隔まで縮められます。受注データを基幹に流すような処理では、15分の遅延が現場の待ち時間として跳ね返ります。

Webhookで即時に受ける構成にすれば間隔の制約は回避できますが、連携元がWebhookを提供していなければポーリングに頼るしかありません。連携元がWebhookを出すかどうかを、間隔の要件と一緒に確認しておくと後戻りが減ります。

作った担当者の異動後に残るフローを誰が直すのかという運用設計

2年目以降に効いてくるのがこれです。Zapierは画面が上から下へ流れるため、作った人が抜けても他の担当者が読めます。Makeは図の読み方を知らない人には手が出せません。

対策は製品の選択ではなく体制側にあります。フローごとに管理者を1名割り当て、命名規則を決め、変更履歴を業務側の台帳に残す。この3つを導入時に決めておけば、どちらの製品でも引き継げます。決めないまま増やすと、製品を問わず同じ場所で詰まります。

よくある質問

ZapierとMakeの比較でよく聞かれる論点を、判断に直結する順にまとめました。

ZapierとMakeは併用できますか？

技術的には併用できますが、勧めません。フローが2つの製品に散ると、障害の切り分けと費用の把握が両方で二重になり、棚卸しの手間が増えます。併用が正当化されるのは、片方にしか接続先が無いSaaSがあり、そのフローが他と独立している場合だけです。その場合も、どちらを主に置くかを決め、新規のフローは主の側に寄せてください。

Makeの無料プランだけで業務を回せますか？

試験導入なら回せますが、本番運用には向きません。Free は月1,000クレジット、最小実行間隔15分、アクティブなシナリオ2本までという制約があります。1件で4オペレーションを消費するフローなら、月250件で上限に達します。加えて実行間隔15分の遅延を業務が許容できるかを確かめてください。本番へ移すなら月9ドルの Core が現実的な出発点です。

ZapierからMakeへの移行にどれくらいかかりますか？

所要時間を左右するのは、フローの本数と分岐の数です。移行ツールは無く、シナリオを1本ずつ組み直す作業になります。分岐の無い3ステップのZapなら1本あたり数十分ですが、Pathsで3経路に分かれているZapはルーターとフィルタの再設計が要るため数時間かかります。移行の判断は費用差だけでなく、この組み直しの工数を含めて計算してください。10本を超えるなら段階移行を勧めます。

日本語のサポートはどちらが手厚いですか？

どちらも一次サポートは英語が基本で、日本語の窓口は用意されていません。管理画面とヘルプの日本語化の度合いにも差があり、込み入った障害の問い合わせでは英語でのやり取りが前提になります。社内に英語で切り分けを進められる担当がいない場合は、国内の導入支援事業者を挟むか、国産iPaaSを候補に入れる判断になります。

n8nやPower Automateと比べるとどう位置づけられますか？

n8nは自社サーバーに置ける点が特徴で、データを外部に出せない要件があるときの候補です。Power AutomateはMicrosoft 365の契約に含まれる範囲があるため、社内がTeamsとSharePoint中心ならライセンス上の優位が出ます。ZapierとMakeは外部SaaS同士をつなぐ用途で強く、この3系統は接続したい相手がどこにあるかで住み分けが決まります。

関連記事

• iPaaSとは？仕組み・RPAとの違い・主要ツールと導入判断をわかりやすく解説：ZapierとMakeが属するiPaaSという枠組みそのものの定義と、RPAとの役割分担を先に押さえたい場合に。
• iPaaSの比較9製品｜料金と課金単位・接続数で選ぶ判断軸と規模別の結論：2製品に絞る前に、国産iPaaSや企業統合型まで含めた候補群を横並びで見るための記事です。
• Workatoとは？レシピとタスク課金・環境分離を実装視点で解説：本記事の2製品では届かない全社連携や環境分離が要件に入る場合の上位候補として。
• embedded iPaaSとは？自社SaaSへの連携機能の組み込みと内製・調達の判断：自社が提供するSaaS側に連携機能を持たせたい場合は、この記事の論点が近くなります。
• Power Automateとは？基本・できること・料金・導入判断まで解説：Microsoft 365を軸に社内業務を自動化する選択肢との比較に。