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は編集で古くなるため信用しない。
- プランごとのオペレーション上限や課金ルールの細部は執筆時点から変わる可能性があるため、公式ドキュメントで最新を確認する。
クォータの枯渇は「使いすぎ」ではなく「設定の初期値のまま空振りさせ続けたこと」が原因であるケースが少なくありません。まずはライブ環境の棚卸しから始めてみてください。