Make.comのオペレーション消費はここで決まる　節約の実際 2026

Make.comの請求は、シナリオの数では決まりません。

ここを誤解したまま使い始めると、「シナリオ2本しか動かしてないのに、無料枠が月半ばで消えた」という事態が起きます。私も実際、このブログの記事生成をMakeで回していた時期に無料枠を使い切って、シナリオを止めたことがあります。原因はシナリオの本数ではなく、中身の組み方でした。

この記事では、Makeの消費の仕組みと、どこを直せば減るのかを整理します。

先に結論:消費は「モジュール数 × 実行回数」で決まる

誤解を恐れずに言えば、Makeのオペレーション管理はこの掛け算を見るだけです。

• モジュール数:シナリオの中に並んでいる処理の数
• 実行回数:そのシナリオが月に何回走るか

10モジュールのシナリオが毎日1回走れば、月300。15分おきに走れば、月28,800。同じシナリオでも、走らせ方だけで100倍近く変わるわけです。節約の話は、ほぼすべてこの掛け算のどちらかを小さくする話に帰着します。

そもそも「オペレーション」とは(今は「クレジット」)

まず用語の整理から。Makeの課金単位は長らく「オペレーション」と呼ばれてきましたが、2025年8月27日から「クレジット」に名称が変わりました。検索ではまだ「オペレーション」の情報が多く残っているので、この記事では両方の呼び名を使います。

基本のルールはシンプルで、シナリオ内のモジュールが1回動くごとに1クレジット。Google Sheetsに1行追加したら1、Gmailからデータを取得したら1。トリガーの確認も、フィルターやルーターの通過も、原則カウントされます。

クレジットは電気メーターのようなもの、と考えるとつかみやすいです。家電(モジュール)を回すたびにメーターが回る。大きい家電を長時間回せば電気代が跳ねるのと同じで、モジュールの多いシナリオを高頻度で走らせれば、クレジットが飛びます。

名称変更で何が変わったか

ふつうの自動化については、実質何も変わっていません。1モジュール=1クレジットの計算は同じ。変わったのは、MakeのAI機能(AIエージェントなど)を使ったときに、処理内容によって1回で複数クレジットを消費することがある点です。AI機能を使わなければ、従来のオペレーションと同じ感覚で大丈夫です。

カウントされない例外

地味に重要なのが、エラーハンドラー系のモジュール(Rollback、Break、Resume、Commit、Ignore)はクレジットを消費しないこと。エラー処理を入れるとコストが増える、ということはないので、遠慮なく入れてください。むしろ後述のとおり、エラー処理を省くほうが高くつきます。

プランごとのクレジット量(2026年時点)

注目してほしいのは、CoreもProもTeamsも基本のクレジット数は同じ10,000という点。上位プランの差は優先実行やチーム機能であって、クレジット量ではありません(量は各プラン内で追加購入・増量できます)。つまり「クレジットが足りないからProに上げる」は間違いで、足りないならCoreのままクレジットを増やすか、消費を減らすのが正解です。

ちなみに追加パックは、プランに含まれる分より25%ほど割高になります。毎月あふれるなら、増量プランへの変更か、シナリオの見直しを。料金は変動するので、契約前に公式の料金ページで最新を確認してください。

消費が跳ねる3大原因

原因1:ポーリング(定期チェック)

最大の犯人はこれです。「15分おきに新着メールを確認する」タイプのトリガーは、新着がなくても確認のたびに1クレジット消費します。15分おき=月2,880回。何も起きていない月でも、監視だけで無料枠の3倍が消えます。

対策はWebhookに替えること。Webhookは「向こうから知らせが来たときだけ動く」方式なので、待機中の消費がゼロ。ポーリングからWebhookへの変更だけで、消費が10分の1以下になるケースはざらにあります。対応していないアプリの場合は、チェック間隔を15分から1時間、6時間に伸ばすだけでも効果は大きいです。

原因2:フィルターの位置が遅い

100件のデータを取得して、10モジュール処理した最後に「対象は3件だけ」とフィルターで絞る——この組み方だと、捨てる97件ぶんの処理にもクレジットを払っています。

フィルターはできるだけシナリオの先頭近くに置く。取得の段階で検索条件を絞れるモジュールなら、そもそも100件取らずに3件だけ取る。処理する前に減らすのが鉄則です。

原因3:エラーの放置

見落としがちですが、エラーで途中まで走った処理も、走ったぶんはクレジット消費になります。バグったシナリオが夜中にリトライを繰り返して、朝起きたら枠が溶けていた——という事故は実際に起きます。エラーハンドラー(消費ゼロ)を入れて、失敗時は静かに止まる設計にしておくのが安全です。

節約の実際:私がやっていた運用

このブログをMakeで回していたときの構成で言うと、記事生成のシナリオは10モジュール前後。これを毎日1回、スケジュール実行にしていました。月の消費はおよそ300クレジット。無料枠1,000の中に収まる計算です。

それでも一度枠を使い切ったのは、作り込みの時期にテスト実行を繰り返したから。シナリオを組んでいる間の「試しに1回走らせる」も、本番と同じだけ消費します。テスト時は処理件数を1件に絞る、AIモジュールを一時的にダミーに差し替える、といった工夫をしておけばよかった、というのが反省点です。

まとめると、節約の打ち手は優先順にこの5つ。

1. ポーリングをWebhookに替える(効果最大)
2. チェック間隔を伸ばす(Webhook不可のアプリ向け)
3. フィルターと絞り込みを先頭に寄せる
4. エラーハンドラーを入れて暴走を止める
5. テスト実行の件数を絞る

使用量の確認方法

今どれだけ使っているかは、Makeの画面左下の組織(Organization)メニューからダッシュボードを開くと確認できます。シナリオごとの消費も見られるので、月に1回、どのシナリオが食っているかを見る習慣をつけると、異常に早く気づけます。75%と90%に達した時点で通知も来ますが、通知が来てからでは打ち手が限られるので、先に見るほうが安全です。

よくある質問

1クレジットも消費せずに待機させることはできますか?

Webhookトリガーなら可能です。データが来ない限り消費ゼロで待ち続けます。ポーリング型のトリガーでは、チェックのたびに消費が発生します。

ルーターで分岐した場合、通らなかった側も消費しますか?

しません。実際に実行されたモジュールだけがカウントされます。分岐を作ること自体はコスト増になりません。

無料枠の1,000クレジットで、実際どれくらい動かせますか?

10モジュールのシナリオを毎日1回なら月300で余裕です。一方、15分おきのポーリングを1本入れた瞬間に月2,880で即オーバー。本数ではなく組み方次第、としか言えないのが正直なところです。

月の途中でクレジットが尽きたらどうなりますか?

シナリオが止まります。追加購入するか翌月を待つかの二択。ただしWebhookで届いたデータはキュー(待ち行列)に保存され、再開後に処理されるので、データそのものは失われません。

まとめ:見るべきは請求額ではなく「1回あたりの消費」

クレジットの管理で毎月の合計だけを見ていると、対策が後手に回ります。見るべきはシナリオ1回あたりの消費 × 月の実行回数。この掛け算を紙に書き出せば、どこを削れるかは一目で分かります。たいていの場合、犯人はポーリングです。

私がブログの記事生成を回していたときも、この掛け算を意識してからは無料枠で安定しました。仕組みさえ分かれば、Makeはかなり安く使える部類のツールです。まず自分のシナリオの掛け算を計算してみてください。答えはダッシュボードではなく、その計算式の中にあります。

※本リンクはアフィリエイトリンクです。 Make.com(※アフィリエイトリンクです)