Make(旧Integromat)でシナリオを組んで運用していると、こんな経験はないでしょうか。

シナリオは数本しか動かしていないのに、月の途中でオペレーション数が上限に達してしまう
実行履歴を見ると、データを1件も処理していない「空振り」の実行がずらっと並んでいる
どのシナリオが消費の主犯なのか分からず、とりあえず全部OFFにしてしのいでいる

筆者もまさにこれでした。月初には余裕があったはずのオペレーション数が想定よりずっと早く枯渇し、原因を調べたところ、**犯人は「15分間隔のポーリングトリガー」**でした。本処理ではなく、新着チェックの空振りが静かにクォータを食い潰していたのです。

この記事で分かること

ポーリング型トリガーが「新着ゼロでも」オペレーションを消費する仕組み
間隔と稼働時間の見直しだけで、消費が単純計算で1/4〜1/8になること（計算表つき）
根本対策としてのWebhook（instantトリガー）化と、対応可否の確認方法
シナリオ棚卸しのときに「どこを真実源にするか」という運用の教訓

なお、Makeの仕様やプラン体系に関する記述は執筆時点のものです。プランごとのオペレーション上限や課金ルールの細部は変わる可能性があるため、最新情報は必ず公式ドキュメント・料金ページで確認してください。

なぜ「何もしていないのに」枯渇するのか

Makeのトリガーは、大きく2種類に分かれます。

種類	起動方式	新着ゼロのときの消費
ポーリング型（スケジュール起動）	スケジュールのたびにMake側からデータを見に行く	消費する
instant型（Webhook）	データ発生側からMakeへ通知が飛んできて起動する	消費しない（イベントが無ければそもそも実行されない）

見落としやすいのが太字の部分です。ポーリング型トリガーは、スケジュールが来るたびに「新着データはあるか？」を確認しに行きます。そして新着がゼロでも、この確認のための実行がスケジュールのたびに発生し、オペレーションを消費します。

つまり「シナリオが本処理を1件もしていない＝消費ゼロ」ではありません。デフォルト感覚で短い間隔を設定したまま放置すると、誰も見ていない深夜も休日も、Makeは律儀に空振りし続けます。「何もしていないのに枯渇した」の正体は、たいていこの空振りです。筆者の環境で枯渇の主犯だったのも、まさにこの分でした。

算数してみる: 15分ポーリングは月2,880回の「固定費」

ここからは単純な掛け算だけで話をします。15分間隔なら、1時間に4回、1日で 4 × 24 = 96回。30日なら 96 × 30 = 2,880回です。新着がゼロの月でも、この回数分のチェック実行が積み上がります。

ポーリング間隔	稼働時間	回/日	月間（30日）	15分・終日を1とした比
15分	終日	96回	2,880回	1（基準）
30分	終日	48回	1,440回	1/2
1時間	終日	24回	720回	1/4（75%減）
1時間	日中のみ（8〜20時）	12回	360回	1/8

この表の数字はすべて算術的な事実です。15分→1時間にするだけで75%減、さらに稼働を日中（例: 8時〜20時）に限定すれば、単純計算で消費は1/8になります。

読み方の注意を2つ。

これはシナリオ1本あたりの数字です。同じ設定のポーリングシナリオが3本あれば3倍になります。
表の回数は「スケジュール実行の回数」です。1回の実行で消費されるオペレーション数はシナリオの構成（モジュール数や新着があったときの処理分）によって上乗せされるため、正確なカウント方法は公式ドキュメントを参照してください。ただ「空振りでもスケジュールのたびに消費が発生する」構造自体は変わりません。

まずやる設定見直し: 間隔を伸ばす + 稼働時間を絞る

シナリオのスケジュール設定を触るだけで、上の表の削減がそのまま手に入ります。

1. 間隔を「業務要件」から逆算する

15分間隔は、なんとなく選びがちな設定です。しかし一度立ち止まって「このデータ、本当に15分以内に処理しないと困るのか？」と問うてみてください。通知・集計・同期系の多くは、1時間遅れても実害がないはずです。1時間で困らないなら、それだけで75%減です。

2. 稼働時間帯を絞る

Makeのスケジュール設定では、実行する時間帯や曜日を指定できます（執筆時点）。人間が日中にしか見ない通知やレポートのために、深夜3時にポーリングする必要はありません。「1時間間隔 + 8〜20時のみ」にすれば、表のとおり1日12回まで下がります。

筆者の環境では、15分間隔・終日で回していたポーリングを「1時間間隔 + 日中のみ」へ変更したことで、オペレーション数の枯渇が解消しました。削減率は上の表のとおりの単純計算（1/8）で、特別なテクニックは何も使っていません。

根本対策: Webhook（instantトリガー）に置き換える

設定見直しよりさらに効くのが、ポーリングをやめてWebhookで受けることです。

instantトリガーはイベント駆動です。データが発生した側（送信元のサービス）がMakeに通知を送ってきたときだけシナリオが動くため、空振りによる消費がゼロになります。新着が1日に数件しかないのに96回見に行く、という無駄が構造ごと消えます。副次効果として、ポーリング間隔ぶんの遅延もなくなり、処理の即時性も上がります。

対応しているかの確認方法

Makeのモジュール選択画面で、そのアプリのトリガーに 「INSTANT」のラベルが付いているかを確認します（執筆時点のUI表記）。付いていればイベント駆動で使えます。
アプリ専用のinstantトリガーが無くても、送信元サービス側にWebhook送信機能があれば、Makeの汎用「Webhooks」モジュール（Custom webhook）で受けられます。送信元の管理画面やAPIドキュメントで「Webhook」の項目を探してみてください。

注意点

Webhook化しても、イベントが来てシナリオが実行されれば当然オペレーションは消費します。ゼロになるのはあくまで「空振り」の分です。イベントが大量に飛んでくるサービスでは、instant化によって逆に実行回数が読みにくくなることもあるため、イベント量を把握したうえで切り替えるのが安全です。

棚卸しの罠: ローカルに保存したblueprintを信じない

消費を見直すには、まず全シナリオの現状を棚卸しする必要があります。ここで筆者がハマった教訓を1つ。

Makeのシナリオはblueprint（エクスポートJSON）としてローカルに保存できますが、このファイルは当てになりません。エクスポート後にMake上でシナリオを編集すれば、手元のJSONはその瞬間から古くなります。筆者もローカルのblueprintを見て「間隔は問題ない」と思い込んでいたところ、ライブ環境では別の設定で動いていた、という経験をしました。

**真実源はMakeのライブ環境です。**棚卸しは必ず、

Makeのシナリオ一覧・各シナリオのスケジュール設定画面を直接見る
もしくはMake APIでシナリオ一覧とスケジュール設定を取得する（執筆時点でシナリオ情報を取得するAPIが提供されています。詳細は公式のAPIドキュメントを参照）

のどちらかで、今動いている設定を確認してください。ローカルのJSONは「過去のある時点のスナップショット」として扱うのが正解です。

見直しチェックリスト

最後に、実際に手を動かす順番をチェックリストにまとめます。

ライブ環境で全シナリオを一覧化する
シナリオ名／トリガー種別（polling or instant）／ポーリング間隔／稼働時間帯を表にする。情報源はMakeの画面かAPI。ローカルのblueprintは使わない。
シナリオごとの月間空振り回数を計算する
上の消費計算表に当てはめるだけです（15分・終日なら月2,880回）。
空振り消費の多い順に対処する
優先順位は「instant化できるか → できなければ間隔を伸ばす → さらに稼働時間帯を絞る」の順。
変更後、実行履歴で効果を確認する
空振り実行の件数が実際に減っているか、ライブ環境の履歴で確かめて完了です。

まとめ

Makeのポーリング型トリガーは、新着データがゼロでもスケジュールのたびにオペレーションを消費する。「何もしていないのに枯渇」の正体はこれ。
15分間隔・終日は、シナリオ1本あたり月2,880回の固定費。1時間間隔にするだけで1/4（75%減）、日中限定を併用すれば1/8（いずれも単純計算）。
根本対策はWebhook（instantトリガー）への置き換え。イベント駆動なら空振り消費はゼロになる。対応可否はモジュール選択画面の「INSTANT」ラベルと、送信元サービスのWebhook対応で確認する。
棚卸しの真実源はMakeのライブ環境。ローカルに保存したblueprintは編集で古くなるため信用しない。
プランごとのオペレーション上限や課金ルールの細部は執筆時点から変わる可能性があるため、公式ドキュメントで最新を確認する。

クォータの枯渇は「使いすぎ」ではなく「設定の初期値のまま空振りさせ続けたこと」が原因であるケースが少なくありません。まずはライブ環境の棚卸しから始めてみてください。