ZapierのAI課金が膨らんだ担当者、Makeへの切り替えが割に合う条件を3軸
ホーム Askiveデイリー

Askiveデイリー #178 ・ 2026-08-17

ZapierのAI課金が膨らんだ担当者、Makeへの切り替えが割に合う条件を3軸

AI自動化ツールを業務で使用している担当者から寄せられる相談として、よくあるパターンがある。月40ドル台で推移していたZapierの請求が、気づいたら倍以上に膨らんでいたというケースだ。以下はそうした複数の相談内容をもとに再構成した典型例であり、特定個人・企業の事例ではない。原因を調べると、AIステップ(要約や分類をAIに任せる処理ブロック)を1つ挟んだフローが、動くたびにコストを積み上げていたというパターンが多い。

この記事では、そうした状況を受けて浮上しやすい「Makeに乗り換えれば安くなるのか」という問いに、3つの比較軸で答える。比較軸は順に、課金単位の違い(タスクかオペレーションか)、移行工数を含めたトータルコスト、日本の中小企業での運用継続性の3点だ。

結論の判定軸を先に示す。乗り換えが割に合いやすいのは「月間の実行回数が多く、かつ既存フローが10本以下で作り直しの負担が小さい会社」だ。逆にフローが数十本に育っていて実行回数が少ない会社は、移行コストのほうが高くつく可能性がある。フロー数の目安を10本とするのは、後述するように1本あたりの移行工数を2〜3時間と筆者が推計すると、10本で20〜30時間、すなわち中堅社員の3〜4営業日分が損益分岐の実感値として浮かびやすいためだ。この推計の算出根拠は「比較軸2」で詳しく説明する。また、月間実行回数が何回以下ならZapierを据え置くほうが有利になるかの具体的な試算についても、同節で数値化している。判定の詳細は以下で順を追って説明する。

記事末尾には、読後に担当者がすぐ着手できる「今週やること3ステップ」のチェックリストも用意している。

ZapierのAI課金で請求が増える仕組み

従来の課金モデルとAIステップ追加後の変化

ZapierとMakeはどちらも、プログラミング不要でアプリ同士をつなぐ業務自動化ツールだ。自然言語や画面操作でフロー(自動化の処理経路)を組める点は共通しており、直接競合する関係にある。

課金の変化について整理する。Zapierは従来、フローが1回動くと「タスク」を消費するモデルを採用していた。ここにAIステップが加わり、AI処理を含むステップの課金が別枠で重くなっている。Zapier公式ヘルプセンター(2025年6月時点)によると、AIステップは通常のタスクとは別にAIクレジットを消費する仕組みとなっており、プランごとに付与されるクレジット上限を超えると追加費用が発生する。同ヘルプセンターおよびZapier公式料金ページ(pricing、2025年6月時点)には、プランごとのクレジット上限と超過時の単価が掲載されている。正確な数値は各プランで異なるため、自社の契約プランに対応する最新の料金表を公式ページで直接確認することを勧める。

なお、Zapierの料金体系の変更履歴はZapier公式changelog(更新履歴ページ、2025年6月時点)にも掲載されており、AIクレジット制度がいつから適用されたかの確認に使える。

ここで押さえるべきは、「AIを使ったから請求が増えた」のではなく、「動くたびに課金される場所にAIを置いたから積み上がった」という構造だ。この構造を理解しないままMakeに乗り換えても、同じ設計を踏襲すれば同じ結果になる。

AIクレジット消費量をZapier管理画面で確認する方法

請求の内訳を把握するには、Zapier管理画面の「Usage」セクションを開き、AIステップ(AI by Zapierブロックを含むZap)の実行履歴を確認する。各Zapの詳細画面では、タスク消費数とAIクレジット消費数が分けて表示される(Zapier公式ヘルプセンター、2025年6月時点)。請求が急増している場合は、まずAIクレジットの消費が多い上位3〜5本のフローを特定することが出発点になる。

比較軸1:課金の数え方が「タスク」か「オペレーション」か

基本単位の違いが実務にどう効くか

最初の分かれ目は料金の基本単位だ。

Zapierは「タスク」で数える。フローの中でデータが1件処理されるごとに1タスクを消費するのが基本の考え方だ。一方Makeは「オペレーション」で数える。フロー内の各モジュール(処理ブロック)が1回動くごとに1オペレーションを消費する。Make公式ヘルプセンター(2025年6月時点)にもこの定義が明記されている。

実務への影響を具体例で見る。「受注メールを受け取り、内容を分類し、担当者に振り分け、記録する」という4工程のフローを考える。Makeではこの4工程それぞれが1回動いた時点で4オペレーションを消費する計算になる。工程が多く複雑なフローほど、Makeのオペレーション消費は積み上がりやすい。逆に工程は少ないが同じフローを大量の件数こなす用途であれば、Makeのほうが費用を抑えやすい場面もある。

AI処理の従量コストは別立てで計算する

注意が必要なのは、要約や分類に外部AIモデルを使う場合のコストだ。どのモデルを選ぶかで費用は変わり、ツールの月額課金とは独立して従量課金が発生しうる。「ツールの月額」と「AI処理の従量コスト」は分けて計算するのが原則だ。ここを一緒くたにすると、乗り換え後に「思ったより下がらなかった」という結果になる。

比較軸2:フローの移行工数を人件費で換算する

作り直しは自動化されない

2つ目の比較軸は移行そのものにかかる人件費だ。ZapierのフローをMakeが自動変換する機能は、2025年6月時点の各公式情報では確認できない。1本ずつ、トリガーとステップを目視で確認しながら組み直す作業が必要になる。

フロー数と移行工数の試算

ここで示す工数は筆者の推計値であり、公式が定めた数字ではない。算出の根拠は次のとおりだ。単純なトリガー+2〜3ステップのフローであれば設計・実装に30〜60分、テスト送信と動作確認に30〜60分、本番への切り替えと旧フロー停止の確認に30分程度と分解できる。これを積み上げると1本あたり1.5〜2.5時間が下限であり、条件分岐や複数アプリ連携を含む中程度の複雑さのフローでは2〜3時間が実務的な目安になると考えられる。

この前提に立つと、フロー10本で20〜30時間、フロー30本では60〜90時間の作業量になる。時給換算の基準は会社次第だが、概ね「中堅社員の3〜4営業日分」がフロー10本あたりの参照値として使いやすい。

月額の節減効果との比較で言えば、例として月額差額が30ドル(約4,500円、1ドル=150円換算)の場合、フロー10本・工数25時間・時給2,500円と仮置きすると移行コストは約62,500円となり、回収に14か月以上かかる計算になる。月額差額が50ドル(約7,500円)でも約8か月かかる。この試算はあくまで仮定値であり、自社の実際の時給・工数・月額差額を代入して確認することを勧める。

なお、月間実行回数が少ない場合のZapier据え置き判断についても触れる。Makeのオペレーション単価(Make公式料金ページ、2025年6月時点に掲載の各プラン)と自社の月間実行回数・平均ステップ数を掛け合わせた試算額が、現在のZapier請求額を下回らない場合は乗り換えによるコスト削減効果がないと考えられる。目安として、フロー1本あたりの平均ステップ数が5工程以上あり、かつ月間総実行回数が500回以下の構成では、MakeのオペレーションコストがZapierのタスクコストを上回るケースが生じやすいと推計される(自社環境での実測を推奨)。

移行コストの全体像を判断するには、少なくとも次の3項目を足し算する必要がある。月額の差額(ツール費用の節減分)、移行作業の人件費(工数×時給)、並走期間中の二重課金(両ツールを同時利用する月数分)。これらを合計したうえで、何か月で元が取れるかを計算してから判断するのが実務的な手順だ。

フローの複雑さによる設計思想の違い

Zapierはトリガーの後にステップを一直線に並べる設計が基本で、直観的に組みやすい。Makeは処理を線でつなぐ図として組むため、分岐や複数ルートの合流を視覚的に扱いやすい。複雑な条件分岐が多いフローを今後も増やす見込みがある会社ほど、Makeの設計思想は中長期で効いてくる可能性が高い。ただしこれは移行が完了した後の話であり、移行期間中の負荷は別に計上する必要がある。

比較軸3:日本の中小企業で運用が継続できるか

確認しておくべき4つの運用軸

3つ目の比較軸は、海外発サービスを国内の中小企業が使い続けられるかという点だ。ZapierもMakeも本社は海外にある。導入前に次の4点を確認軸として持っておきたい。

  • 日本語での管理画面と設定のしやすさ:担当者が変わっても引き継げる設計になっているか
  • 国内で使う会計ソフト・チャットツールとの連携:コネクタ(接続先の処理部品)として用意されているか
  • 円建てかドル建てか:ドル建て課金の場合、円安局面では月額の実質負担が上がる
  • サポートの言語と反応速度:フローが停止したとき、日本語で問い合わせて業務再開までに許容できる時間か

「どちらが日本語サポートで優れるか」はプランや契約時期で条件が変わるため、現時点で一律に断定できる公開データは見当たらない。各公式のサポートページで最新条件を直接確認することを勧める。

金額・顧客情報を扱うフローの原則

請求や顧客情報を扱うフローでは特に慎重さが要る。受注データや金額を自動処理する場合、AIの要約や分類が誤る可能性をゼロにはできない。金額・契約条件・顧客情報が絡む処理は、原本と照合する仕組みを残し、最終確認は人が行う運用にしておく。どちらのツールに乗り換えても、この原則は変わらない。

ケース別の判断基準

フロー数と実行回数の組み合わせで判定する

ケースA:フロー5本以下、実行回数が多い会社 乗り換えの検討価値がある。作り直し工数が小さく、Makeのオペレーション課金が実行回数の多さと噛み合いやすい条件が整っている。まず月間の実行回数を実測したうえで試算する。

ケースB:フロー30本以上に育っている会社 安易な全面移行は推奨しにくい。移行工数が数週間分に膨らむ可能性がある。まずは「AIステップを含む請求が重い数本」だけを対象に、そこだけ組み直すか、AI処理の置き場所を見直すほうが現実的だ。

ケースC:条件分岐が多く、今後さらに複雑化する見込みの会社 中長期ではMakeの設計思想が向く可能性がある。ただし移行を一気に進めるよりも、新規フローからMakeで作り始め、既存フローはZapierに残す並走期間を置くと作業負荷を分散できる。

ケースD:担当者が兼任で、自動化に割ける時間が週数時間の会社 乗り換えより先に、現在の請求の内訳を分解することを勧める。実行回数が多い重いフロー1本を止めるか設計を変えるだけで、請求が落ち着く場合もある。

乗り換えを判断する3つの確認事項

判断前に自分の数字を揃える

乗り換えるべきかは、次の3問で切り分けられる。

  1. 今のZapierのフローは何本あるか。10本を超えるなら、移行工数を人件費で試算してから決める。
  2. 請求が重いフローの原因は、実行回数の多さか、工程の複雑さか。実行回数が原因ならMakeで下がる余地があるが、工程数が原因ならMakeで逆に増える場合がある。
  3. 移行に使える時間は、今後1か月で何時間確保できるか。20時間を下回るなら、全面移行ではなく重いフローの部分的な見直しから始める。

請求書の数字は目に入りやすいが、乗り換えで本当に問われるのは帳簿に載らない作業時間だ。月額が下がった事実は数字で見えるが、移行に費やした時間は誰の請求書にも現れない。「月額が下がった」と「トータルで得した」は別の問いだ。その差を試算してから、移行の判断を下すことを勧める。

今週やること3ステップ

読後に担当者がすぐ着手できる行動を3点に絞る。

ステップ1:Zapierの請求内訳でAIクレジット消費量を確認する Zapier管理画面の「Usage」セクションを開き、AIクレジットの消費が多い上位フローを特定する。フローの詳細画面ではタスク消費数とAIクレジット消費数が分かれて表示される(Zapier公式ヘルプセンター、2025年6月時点)。請求増の原因がAIステップにあるか、単純な実行回数増にあるかをここで切り分ける。

ステップ2:自社フローの本数と複雑さを棚卸しする 現在稼働中のフローを一覧化し、本数・平均ステップ数・月間実行回数を書き出す。この3つの数字があれば、本記事の「比較軸2」で示した試算式に代入して移行コストを概算できる。棚卸し自体は1〜2時間で完了できる作業だ。

ステップ3:Makeの無料トライアルで重いフロー1本だけを再現する Make公式サイト(2025年6月時点で無料トライアルを提供)で、現在最もAIクレジットを消費しているフロー1本を再現し、1週間分のオペレーション消費数を計測する。この1本での実測値をもとに、全フローを移行した場合のMake月額を推計すると、試算の精度が大きく上がる。

本記事はAI編集を経たのち、編集長が事実確認と品質チェックを実施しています。記事内の料金・仕様に関する記述はZapier公式ヘルプセンター、Zapier公式料金ページ(pricing)、Zapier公式changelog、およびMake公式ヘルプセンター・Make公式料金ページ(いずれも2025年6月時点)を参照しています。正確な単価・プラン条件は各公式の最新ページで確認してください。工数・コストに関する試算値は筆者推計であり、自社環境での実測値を優先してください。

本記事はAskiveのAIネイティブ編集部が執筆し、編集長 四月鶉(Yotsuki Uzra)が監修しています。内容は公開時点で確認できた情報に基づきます。