Zapier 料金とMakeを比較：分岐・復旧・チーム運用で選ぶ

「Zapier 料金」を調べるときも、先に決めたいのは運用の担当者です。分岐の多いワークフローを、設計・構築に詳しい担当者が管理するならMake。アプリ間のシンプルな連携を、同僚が引き継いで保守するならZapierが向いています。MakeとZapierの比較では、使用量より先に運用責任を考えましょう。後続のアクションが2つあるワークフローは説明こそ簡単ですが、片方だけ成功したときには、誰かが復旧させる必要があります。

MakeとZapier、どちらを選ぶべきですか？

営業、マーケティング、業務運営などの担当者が、通常のアプリ連携を管理するならZapierです。 新しい問い合わせを受けたら顧客レコードを作成し、担当者に通知する。この流れは説明しやすく、引き継ぐ人も大きな業務フロー図を読み解かずに内容を確認できるはずです。

処理が日常的に分岐し、そのロジックに責任を持つ担当者がいるならMakeです。 地域、顧客の状態、情報の不足によって、問い合わせへの対応が変わる場合です。各ルートをまとめて見渡せると、構築担当者は処理の関係を把握しやすくなります。

保守を引き継ぐ相手が変われば、選択も変わります。 高度なシナリオでも、作成者しか理解できなければチームの資産としては不十分です。一方、使い慣れたステップ型エディターでも、変更のたびに関連する複数の分岐をたどる必要があるなら、利点は薄れます。

料金と機能は、2026年11月12日に両社の公開ページで確認しました。本比較は公開ドキュメントと前提を明示した処理量の計算に基づいており、ログインしての実機検証は行っていません。判断軸は、対応アプリ、分岐の見通し、障害からの復旧、そして次の保守担当者に必要な管理機能です。

対応アプリ数と開始価格は、後述の料金セクションで参照している各社の料金ページに基づきます。アプリ数は検討の入口にすぎません。カタログの総数より、必要なアクションが使えるかどうかが重要です。

構築画面の違い：連携をつなぐZapier、分岐を見渡すMake

Zapierなら日常業務の流れを説明しやすくなります

Zapierは、Zapsと呼ばれるワークフローでトリガーと後続のアクションをつなぐ自動化プラットフォームです。定型的なアプリ連携で強みを発揮します。 特に、業務の責任者が保守も担当する場合に向いています。

フォームから問い合わせが届く場面を考えてみてください。レコードを作成し、担当者に通知して終了します。ステップを順に並べる表現は、業務担当者が仕事を説明する順序に合っています。条件が加わっただけでMakeが必要になるわけではありません。ZapierもFiltersとPathsによる条件付きの処理に対応しています。

Zapierの構築画面は単純な一本道しか扱えない、という前提で購入を決めないでください。同社は固定型、AI支援型、エージェント型のワークフローも打ち出しています。ワークフローの製品ページでは、従来のZapsと併せてNext Gen Zapsを紹介していますが、後者には早期アクセスと明記されています。宣伝されている機能がすべて一般提供済みだと考えず、自分のアカウントで使えるエディターと機能を基準に判断しましょう。

Zapierで難しくなる場面： 関連する例外が増えると、わかりやすかったはずの流れが複雑になります。引き継ぎやすいステップ構成でも、業務ルールが複数の分岐や別々のZapsに散らばると、全体を点検しにくくなります。これは実際の業務に照らして運用体制を評価すべき問題であり、Zapierは分岐できないという意味ではありません。

Makeなら分岐そのものを可視化できます

Makeは、シナリオと呼ばれるワークフローをビジュアルに構築する自動化ツールです。分岐自体が業務の中心となる場合に強みがあります。 モジュールはデータを読み取り、変換し、書き込む処理の部品です。マッピングでは、次のモジュールに渡す入力値を指定します。

問い合わせを扱う代理店なら、営業に通知するルート、既存顧客をサポートへ案内するルート、情報の足りない送信内容を確認用に集めるフォールバックなどが考えられます。キャンバス上では、構築担当者がこれらの関係をまとめて確認できます。

Makeのルーターのドキュメントでは、フィルター付きの分岐、ルートの実行順序、通常のどのルートにも該当しないデータを受け止めるフォールバックが確認できます。見落としやすい制約もあります。ルーターの各ルートは並列ではなく、順番に実行されます。 図で枝分かれしていても、すべての分岐が同時に開始するわけではありません。

Makeで難しくなる場面： キャンバスが見やすくても、データを理解する人は必要です。フィールドが欠けている場合、リストに複数のレコードがある場合、複数の条件に一致する場合に、次の処理を決めるのは構築担当者です。稼働後にそうした判断を引き受ける時間のある人がいないなら、Makeは見送りましょう。

対応アプリ数はZapierが優勢。ただし決め手は必要なアクションです

カタログの規模ではZapierが上回ります。 公表値はZapierが9,000以上、Makeが3,500以上です。ニッチなソフトウェアに依存する業務ではZapierが有利ですが、どの連携でも必要なアクションが使えると保証する数字ではありません。

営業への引き継ぎなら、「自社の顧客関係管理（CRM）システムに対応している」だけでは曖昧です。既存の連絡先を検索できるか、必要なフィールドを更新できるか、正しい取引先にレコードを関連付けられるかを確認する必要があります。アクションが足りないだけで、簡単なはずの処理に独自の連携開発が必要になることもあります。

選定前に、対応が最も難しそうなアプリのトリガーとアクションの一覧を確認しましょう。必須フィールドと、ワークフローが重複を検出する方法を書き出します。見慣れたアプリのロゴだけでは、購入を決める根拠になりません。

両方で必要なアクションを使えるなら、構築画面と保守担当者に立ち返ってください。使わないアプリの多さにお金を払う必要はありません。どちらでもうまく実現できないなら、次はZapierの代替ツール比較で選択肢を広げましょう。

Zapier 料金とMakeの料金は、処理内容と課金ルールで比較します

有料プランの導入費用はMakeのほうが低いものの、共同管理や復旧に必要な機能によって選ぶプランは変わります。 以下は今回確認した表示価格です。Zapierは年払いと明記しています。Makeは月額を表示していますが、取得したページからは選択中の請求期間を確実に判別できませんでした。そのため、Makeの数字は表示額であり、確認済みの年払い価格ではありません。

出典：Makeの料金ページ、Zapierの料金ページ。Makeの有料プランの表示は月10,000クレジットでした。購入前に請求期間の選択状態と支払総額を確認してください。Zapierの有料プランは開始価格です。プラン体系を詳しく確認するには、Makeの料金ガイドとZapierの料金ガイドを参照してください。

Makeの課金単位はクレジットです。クレジットのドキュメントでは、クレジットとオペレーションを区別しています。通常の非AIオペレーションは各1クレジットですが、一部のAI機能は使用量が変動します。特にAIモジュールについて、どのモジュールも一律1クレジットだと考えないでください。

Zapierの課金単位はタスクです。使用料金のページでは、通常のステップ、AI、プログラムからの呼び出しに異なる料金を示しています。Formatter、Filters、Pathsなどの組み込みツールはタスクを消費しません。画面上のボックスをすべて1タスクと数えるのは誤りです。

前提を明示して、同じワークフローの使用量を計算します

月100件の問い合わせを受けると仮定します。各問い合わせは、自動化処理へイベントを直接送るwebhookで届き、顧客レコードを作成して通知を送ります。受信ごとに1レコードを扱い、通常の非AIモジュールを使用し、アクションは成功するものとします。検索、再試行、追加のポーリング、分岐は含めません。これは計画用の例であり、実測結果ではありません。

Make： webhookの受信と通常のアクション2つで、100 × 3 = 300クレジットです。Freeの利用枠内なので、有効なシナリオ数などの制限がアカウントの要件に合えば、自動化サービスの利用料は**$0**にできます。追加機能を目的にCoreを選ぶ場合は、表の価格が適用されます。300クレジット分が別途上乗せされるわけではありません。

Zapier： 料金FAQはトリガーを除外し、成功した通常のアクションを数えるため、100 × 2 = 200タスクになります。一方、リンク先の使用料金ページには標準のトリガーとアクションが各1タスクと記載されており、同じ構成でも300タスクになります。どちらもFreeの枠を超え、複数ステップへの対応も必要なため、表示されている年払い価格のProfessionalが検討の出発点です。

ここから導ける結論は、「常にどちらかが安い」というものではありません。この小規模なワークフローならMake Freeに収まる一方、Zapierでは有料プランが必要です。同僚との共同管理やSSOが必要なら、処理量が上限に近づく前に、共同作業用プランの要件で料金が決まることもあります。

デバッグと復旧：障害ごとに対応を変えるならMakeです

障害の種類に応じて対応を変えるなら、Makeが適しています。 エラーハンドラーのリファレンスでは、不完全な実行を保存して再試行するRetry、代替値を渡すResume、後続のバンドルの処理を続けるSkipを区別しています。バンドルとは、処理対象のデータのまとまりです。

顧客情報の受け付けでは、任意の補足情報の取得に失敗したなら代替値を使えます。一方、顧客レコードの書き込みに失敗したなら、復旧できるように保持すべきです。両方を単に「エラーを無視する」で済ませると、ダッシュボードは静かになっても、業務処理の不整合は残ります。

特定の問い合わせの失敗を探す必要があるときは、未使用のクレジットより、Make Proの実行ログ全文検索のほうが重要になることがあります。障害を調査する人が該当の実行を見つけられることは、アップグレードの実務的な理由になります。

Zapierにも有用な復旧機能があります。再実行のドキュメントでは、失敗したステップの再試行と、ワークフロー全体の再実行を区別しています。前者では、それ以前に成功したアクションをスキップします。後者では、成功済みのアクションも再び実行します。有料プランではAutoreplayを利用できます。

重要な注意点は、Zapierのカスタムエラー処理のドキュメントにあります。カスタムエラーハンドラーを公開すると、そのZapのAutoreplayは無効になります。該当する実行では、手動で一部だけを再実行することもできませんが、全体の再実行は可能です。また、ハンドラーが動作した場合、エラー通知メールも送信されません。

この仕様は復旧設計に影響します。レコード作成が成功し、通知だけが失敗した場合、すべてを再実行すると、重複防止を組み込んでいなければ別のレコードが作られる可能性があります。独自の障害処理ルートには、通知と復旧の計画も必要です。

通常のアプリ連携で復旧設定を簡単にしたいならZapier、例外への対応を細かく設計したいならMakeが有利です。 どちらを選んでも、障害を監視する担当者は決めなければなりません。

AIステップ、エージェント、MCP：保守できる範囲を選びます

既存の業務連携にAIを追加するならZapier、構築担当者がエージェントの処理を組み立てるならMakeが基本の選択です。 AIステップは、カテゴリの抽出など、決められた仕事を実行します。エージェントはツールを選び、次の行動を判断できます。両者では、保守で引き受ける責任が異なります。

問い合わせの振り分けなら、まずAIで希望するサービスを抽出し、構造化されたフィールドに格納するところから始めましょう。担当者を割り当てるルールは明示したままにします。次のアクションをエージェントに選ばせるのは、業務上その柔軟性が必要な場合に限ります。

Zapierはワークフローの中にエージェントを組み込みます

ZapierのAgents移行ガイドでは、独立していたAgentsをAI by Zapierへ移す方法を説明しています。構造化出力、ツールごとの承認、Zap履歴での実行詳細の確認に対応しています。

移行後も、従来のエージェントのプロンプト、ツール、推論は1つのAIステップ内に保持されます。各ツール呼び出しが自動的に独立したネイティブアクションへ変換されるわけではありません。また、既存のAgentsで使えるナレッジソースのうち、AI by Zapierではまだ対応していないものもガイドに記載されています。通常のアプリ連携とは別に、ナレッジソースの対応状況を確認してください。

この構成は、AIと通常のアクションを同じワークフローで扱いたい業務担当者にとって魅力です。一方、既存エージェントの依存関係を確認せず、そのまま置き換えられると考えてはいけません。

前述の使用料金では、AIの課金はモデルの区分とツール呼び出しに応じて決まります。上位モデルを使うエージェントが複数回呼び出しを行う場合、エディター上では1つのボックスでも、通常のアクション1回と同じにはなりません。

Makeではエージェントの前後の処理も組み立てられます

MakeのAI Agentの紹介では、製品をオープンベータとしています。MakeのAI Providerを使う場合は全プランで利用でき、独自のプロバイダーへの接続には有料プランが必要です。ツールにはモジュール、シナリオ、MCPサーバーのツール、ほかのエージェントを含められます。

エージェントの周囲に再利用可能な業務プロセスを組み立てたい構築担当者がいるなら、この方式が合います。課題は運用責任です。ツールの説明、想定する入力、失敗時の動作を、誰かが保守する必要があります。

Makeのエージェントのクレジット規則では、同社のプロバイダーを使う場合、オペレーションとトークンの使用量が含まれます。独自のプロバイダーを使う場合、トークンは別途課金されます。自分でプロバイダーを用意しても、周辺の自動化処理が無料になるわけではありません。

MCPはAIアシスタントを外部のアクションにつなぎます

Model Context Protocol（MCP）は、AIクライアントが外部ツールを使うための標準です。幅広いアプリのアクションを公開したいならZapier、既存シナリオをツールとして公開したいならMakeが有利です。

Zapier MCPはタスクの利用枠を消費し、ドキュメント上のレートはツール呼び出し1回につき2タスクです。この独立したインターフェースについては、Zapier MCPガイドで詳しく解説しています。

Make MCPサーバーのドキュメントによると、有効化されたオンデマンド実行のシナリオを動かせます。シナリオ実行ツールは全プランで利用でき、管理ツールには有料プランが必要です。公開範囲はスコープで決まります。入力と出力を定義し、アシスタントが手順をその場で考えるのではなく、範囲の定まった業務プロセスを呼び出せるようにしましょう。

どちらでも、公開するアクションは必要最小限にします。「問い合わせレコードの下書きを作る」という操作なら、営業プロセス全体を変更できる広い権限よりも、確認や復旧が容易です。

チーム管理：SAML SSOを導入しやすいのはZapierです

企業向けの個別見積もりを取らずに、会社のログイン基盤であるSAML SSOを導入したいチームには、Zapierのほうが選びやすいプランがあります。 Teamプランには、Zaps、フォルダー、アプリ接続の共有に加え、SAML SSOが含まれます。Professionalは単独ユーザー向けです。

Make Teamsでは、チームロールと共有シナリオテンプレートが追加されます。料金表では、会社のSSO、監査ログ、カスタムロールはEnterpriseに含まれています。構築担当者が主導するチームならMake Teamsが合う場合もありますが、会社管理のログインが必須なら、選ぶプランが変わります。

Zapier Enterpriseでは、高度な権限設定、アプリの管理、可観測性の機能が追加されます。各部門が自分たちで自動化を構築し、中央の管理者が接続先を把握・制限する必要がある場合に、こうした機能が重要になります。

プランは、運用責任について簡潔な方針を決めてから選びましょう。誰が編集できるのか、誰の認証情報を使うのか、誰がアプリを再接続できるのか、誰が障害通知を受けるのかを定めます。ログインの共有は、その方針の代わりにはなりません。

ZapierからMakeへ、またはMakeからZapierへ移行するには

安定しているワークフローを、相手の開始価格が安く見えるという理由だけで移行しないでください。 移行の作業は、マッピング、分岐条件、認証情報、重複防止、復旧といった動作を再構築することです。

拡大する業務プロセスを点検しやすくできるなら、Zapierの代替としてMakeを選ぶ価値があります。反対に、連携をシンプルにすることで、元の構築担当者に頼らず同僚が保守できるなら、Zapierへの移行に意味があります。

1. 1

   確認できる処理結果を書き出します

   作成・変更するレコード、送信するメッセージ、確認のために処理を止めるべきケースを列挙します。顧客データを露出させずに、入力サンプルを保存してください。

2. 2

   最も難しいケースから再構築します

   フィールドが欠ける分岐や、後続のアクションが失敗する分岐を選びます。新しいツールでかえって理解しにくくなるなら、移行にかかるコストに見合っていません。

3. 3

   書き込み先を切り替える前に結果を比べます

   同じ入力に対し、対象のレコードとメッセージを確認します。同じイベントについて、両方のワークフローが本番の書き込みを行う状態は避けてください。

4. 4

   次の担当者に復旧を引き継ぎます

   部分的な成功の見分け方、安全な再試行の方法、有効期限の切れたアカウントの再接続方法を、今後の保守担当者に説明してもらいます。引き継ぎが機能するまでは、元に戻す計画を維持してください。

ワークフローが安定し、保守担当者も使い慣れていて、見込める節約額が再構築に見合わないなら、現状を維持しましょう。必要なアクションの欠如、分岐の扱いにくさ、運用責任の要件など、具体的な理由があるときに変更します。

n8nも候補に入っている場合は、3製品の比較とn8nとMakeの比較を参考にしてください。

導入前によくある質問

MakeとZapierはどちらがおすすめですか？

専門の構築担当者ではない人がシンプルなアプリ連携を保守するなら、Zapierが基本の選択です。マッピングや復旧を扱える人が分岐の多い処理を保守するなら、Makeが適しています。決め手は、次の担当者がワークフローを理解し、修復できるかどうかです。

MakeとZapierはどちらが安いですか？

表示されている有料プランの開始価格はMakeのほうが低く、無料枠も数字の上では大きいものの、クレジットとタスクは異なる単位です。前提を限定した上の問い合わせ例では、MakeはFreeに収まり、ZapierはProfessionalが必要です。AI、共同管理、復旧の要件によって、選ぶプランは変わります。

Zapierより適した代替ツールはありますか？

視覚的な分岐と、業務に合わせた例外処理が決め手なら、Makeのほうが適しています。ただし、特定の連携アクションや、同僚がシンプルな処理を保守できることを優先する場合まで、Makeが有利とは限りません。

自動化に使うAIツールはどちらがよいですか？

この両製品では、業務担当者が管理する連携にAIを追加するならZapier、構築担当者がシナリオやエージェント用ツールを組み合わせて処理を作るならMakeを選びます。固定ルールで表現できる仕事に、どちらもエージェントは必要ありません。

Zapierを選ぶ条件、Makeを選ぶ条件

Zapierを選ぶのは、 業務の中心がアプリ間の連携で、同僚が運用を担い、必要なアクションがそろっている場合です。幅広い対応アプリと、導入しやすい共同管理機能が、料金を払う主な理由になります。

Makeを選ぶのは、 業務ロジックの分岐を可視化する必要があり、明確な構築責任者がいて、障害ごとに異なる対応を設計したい場合です。その担当者が復旧まで引き継げるとき、キャンバスの価値が生きます。

週明けには、最も簡単なデモではなく、最も壊れそうなワークフローを取り上げてください。今後の保守担当者に、分岐と、一部の処理だけ成功した場合の復旧方法を説明してもらいます。その説明が明確になるツールを選びましょう。

プラットフォームを選ぶ前にワークフローと責任者を整理するため、ニュースレターでAI業務ワークフロー監査チェックリストを受け取ってください。