この記事の内容（9項目）

Makeで匿名Webhookを試した後、実行履歴を見ると「2 operations」と「2 credits」が並んでいました。同じ数字なので、最初は呼び方が変わっただけにも見えます。

ただ、公式ヘルプを確認すると、この二つは役割が違います。operationsはシナリオの中で行われた処理回数、creditsはその処理に対して消費する単位です。

今回は、実際に動かした匿名データ1件の履歴を起点に、無料枠を見積もるときにどちらを見ればよいか確認しました。

先に結論

  • operations: モジュールがデータを処理、または新しいデータを確認した回数
  • credits: Makeの機能を使うときに消費する単位
  • 一般的な非AIモジュール: 基本は1 operationで1 credit
  • AIや一部の高度な機能: token数などにより1 operationとcreditが同じにならない場合がある

今回の手動実行では2 operations、2 creditsでした。ただし、この結果からFreeの月1,000 creditsを「同じシナリオが必ず500回動く」と決めることはできません。入力件数と通るモジュールが変われば、1回の実行で使う数も変わります。

実際に2 operations、2 creditsだった構成

2026年9月24日、Make Freeで次の小さなシナリオを手動実行しました。

匿名JSON → Custom webhook → Router → 組み込みTools

入力は1件だけです。category=invoiceのときだけ請求書経路を通し、もう一方はFallbackにしました。外部アプリは接続せず、氏名、メールアドレス、請求金額も使っていません。

実行履歴はSuccess、1秒未満、2 operations、2 credits、129.0 Bでした。

Routerを含めると画面上の部品は三つ以上に見えますが、Makeの料金ページではRouterはcreditを数えない例外として案内されています。見た目のモジュール数だけを数えるのではなく、実行後の履歴を確認した方が確実でした。

Webhookの作成から分岐までの操作は、Makeで匿名Webhookを試した手順に分けて記録しています。

operationsは処理されたbundle数で増える

Make公式では、operationを「モジュールがデータを処理、または確認する1回の実行」と説明しています。

ここで気をつけたいのがbundleです。bundleはメール1件、連絡先1件、ファイル1件のようなデータのまとまりです。同じモジュールでも、1件を処理したときと10件を処理したときではoperationsが変わります。

例えば、1回の起動で複数の問い合わせを後段へ流す構成なら、「シナリオを1回動かしたから1 operation」ではありません。通ったモジュールと処理したbundleの数を見ます。

そのため、月の実行回数だけで無料枠を見積もるとずれます。最低でも次の三つを分けます。

  1. 何件のデータを受け取るか
  2. 1件がいくつのモジュールを通るか
  3. 分岐後にどの経路を通るか

creditsは請求と利用枠を見るための数字

Makeでは2025年8月から、請求の単位としてcreditsが使われています。Freeは期限なしで、月1,000 creditsです。

一般的な非AIアプリでは、1 operationが1 creditです。今回も2対2でした。一方、MakeのAI機能や一部の高度な機能は、operationsだけでなくtoken数、ファイルサイズ、ページ数などでcreditが変わる場合があります。

つまり、operationsは「何が何回動いたか」を調べる数字、creditsは「利用枠をどれだけ使ったか」を見る数字、と分けると理解しやすくなります。

外部のAIサービスを接続する場合は、Make側のcreditsに加えて、AI提供元のtoken料金が別にかかる構成もあります。無料枠を調べるときは、Makeの画面だけで費用全体を判断しない方が安全です。

月1,000 creditsで足りるかを試す手順

本番の件数をいきなり掛け算する前に、匿名データを1件だけ流します。

  1. 本番と同じモジュール構成を、外部送信なしで作る
  2. 代表的な入力を匿名化して1件だけ手動実行する
  3. 履歴でSuccess、operations、creditsを確認する
  4. 通常経路と例外経路を分けて記録する
  5. 1日または1か月の想定件数を掛ける

仮に通常経路が2 creditsでも、エラー時の再実行、検索結果が複数件返る処理、複数bundleの反復まで同じとは限りません。最小実行の数字は、上限の見積りではなく、計算を始めるための基準として使います。

新着が少なくても、定期確認の回数は別に数える

月に届く問い合わせが少なくても、「新着があるか」を繰り返し調べる構成は確認分も見積りの対象です。一定間隔で接続先を調べる方式を、ポーリングと呼びます。

Make公式のoperationsの説明では、データの処理だけでなく、新しいデータの確認もoperationに含まれます。ただし、すべての確認が同じcreditsを使うわけではありません。使うモジュールの仕様と、実行履歴を照らし合わせてください。

★例えば、15分ごとに24時間、30日間、新着を確認する予定なら、確認回数の計算は次のとおりです。

60 ÷ 15 × 24 × 30 = 2,880回

★さらに「確認1回で1 credit使う」と仮定すると、確認だけで2,880 creditsです。Freeの月1,000 creditsを超える試算ですが、Makeで月間稼働を試した結果ではありません。全モジュールに1 creditを当てはめる計算でもありません。

自分の予定を書き込むメモ

定期確認型の処理なら、次を埋めると確認分と後段処理を分けられます。

使う確認モジュール：＿＿＿＿
確認間隔：＿＿分／1日の稼働時間：＿＿時間／月の稼働日：＿＿日
予定する確認回数：60 ÷ 間隔 × 稼働時間 × 稼働日 = ＿＿回
確認部分の消費：＿＿credits／回（モジュールの仕様・履歴で確認）
★確認分の試算：予定する確認回数 × 確認部分の消費 = ＿＿credits

月に後段へ渡す予定件数：＿＿件
通常経路で1件を処理する消費：＿＿credits（確認部分を除いた実測値）
★後段分の試算：予定件数 × 1件の処理消費 = ＿＿credits
★ここまでの小計：確認分 + 後段分 = ＿＿credits

小計に含めていない処理・例外：＿＿＿＿

このサイトで9月24日に確認した2 creditsは、匿名Webhookから組み込みToolsまでを手動で1回動かした合計です。確認だけの消費でも、上のメモの「確認部分を除いた実測値」でもありません。そのままどちらかの欄へ入れず、自分の構成で分けて測ります。

分岐や複数件のデータで経路が変わるなら、経路ごとに後段分を計算してください。AI処理、再実行、例外経路は、測っていなければこの小計には含めません。未計上があるうちは、月1,000 credits以内に収まるという判断は保留です。

データ到着で起動するWebhookなどには、上の定期確認回数の式をそのまま使いません。Webhookなら安くなると決めず、実際に動く処理と消費を見る必要があります。

小計の大半が定期確認なら、最初に見直すのは有料プランではなく、必要な確認間隔と稼働時間です。夜間も確認が必要かを決めてから、匿名データで履歴を確かめてください。

Freeで試しやすい構成、先に有料枠を確認したい構成

月1,000 creditsの範囲を確認しやすいのは、入力件数が少なく、通る経路が短く、AIや大量ファイルを使わない構成です。

一方、次のような処理は、無料枠だけを前提にしない方がよいと思います。

  • 1回の起動で多くのデータを反復処理する
  • 複数の外部アプリへ書き込む
  • AIモジュールで長い文章やファイルを扱う
  • 失敗時に自動再実行する
  • 停止すると業務が滞る処理を常時動かす

GASとMakeのどちらへ置くか迷う場合は、GASとMakeを分けた5つの判断軸も合わせて確認できます。

Makeを無料で試す

この記事のリンクはMake公式アフィリエイトです。料金とFreeの最新条件は登録画面で確認してください。

登録後は外部アプリをつなぐ前に、匿名データ1件だけを手動実行し、履歴のoperationsとcreditsを並べて見てください。同じ数字なら、どのモジュールがその2件を使ったかまで説明できる状態にすると、月の利用量を見積もりやすくなります。

出典・関連資料

この記事の確認情報

最終確認日：2026年9月28日

確認に使ったもの

  • Make Freeで匿名WebhookをRouterへ通した手動実行
  • Success、1秒未満、2 operations、2 credits、129.0 Bの実行履歴

参照した公式情報

リンクは新しいタブで開きます。