Makeのクレジットが急に減るときの調べ方｜頻度・bundle・AI利用・追加購入

請求期間と増加した時刻をそろえる

OrgのダッシュボードとSubscriptionで、対象組織、残量、利用期間、リセット日を確認します。複数組織の数字や違う期間を比べないようにします。まず日別の増加箇所を見つけ、直前に頻度、検索条件、対象データ、AI設定を変えたかを確認してください。請求額とクレジット数は同じ尺度ではありません。

Credit usageから多く使った実行へ進む

OrgのMy PlanにあるCredit usageでは、シナリオやAIエージェントごとの実行単位の利用を確認できます。大きく消費したシナリオの実行へ進み、履歴でモジュールごとの出力と処理を見ます。調査メモには日時、実行ID、入力件数、消費、直前の変更を並べ、印象だけで原因を決めないようにします。

データがない定期確認を見落とさない

履歴でcheck runが非表示になっていると、新着ゼロの確認に気付きにくくなります。表示設定を見直し、必要以上に短い実行間隔になっていないかを確認します。頻度を変える際は、通知が遅れる許容時間と元データの取得条件も確認してください。単に間隔を延ばすだけで欠落が起きないとは限りません。

入力1件から増えたbundleを追う

検索が広がった、Iteratorで商品ごとの処理が増えた、複数のRouter経路に一致したなどの変化を調べます。例として、1注文に20商品があれば、商品ごとの保存や通知は注文1件と同じ回数にはなりません。フィルターを置く位置と、まとめ通知で済むかを見直し、必要な効果を残して処理を減らします。

再実行・ループ・AIの入力増加を調べる

手動の再実行や復旧が増えた場合、同じIDの処理が繰り返されていないかを追います。書き込んだ更新を同じフローが再び拾う構成も点検します。AIでは長い入力や出力、接続方式によって消費が変わるため、選んだ機能の現行ルールと実行結果を確認します。自前のAI接続では、Makeとは別の事業者請求も見てください。

追加購入は原因対策と予算判断を分ける

Extra creditsやauto-purchasingの設定、購入履歴を確認します。追加分は通常枠と価格・有効期限が同じとは限らず、現行の確認画面で見積もります。自動購入は支出を伴う設定です。原因が残ったまま有効にせず、業務を継続する必要と予算を担当者が判断し、誰が設定を変更できるかを明確にします。

枯渇したら保存元と未処理を確認して再開する

残量不足の際は、重要な受付の代替手順、送信元の記録、キューや未処理の状態を確認します。復旧後に過去分を再取得できるかはトリガーや送信元の条件にもよります。残量を戻しただけで全件が完了したとはせず、受付IDと保存・通知の状態を照合します。再開で大量に処理される場合の外部API制限も点検してください。

変更後は同じ条件で比較する

練習入力の件数、対象期間、AIの入力長、通知先を記録し、一度に一つの設定を変えて比較します。「1入力あたり」と「1日合計」の両方を見ると、効率化と件数増加を分けられます。この記事の例は調査手順であり、節約額を測定した結果ではありません。

• 事前に利用量を見積もる
• 配列から増える処理を理解する
• 取得頻度とWebhookを比較する
• 再開前に完了済みの効果を照合する
• 更新が自分自身を再起動するループを防ぐ
• 外部API制限とバックログを設計する