ピークの高さだけでは、異常とは言えない
商品説明の要約や記事分類を夜間にまとめて行うサイトでは、日中よりAI利用が大きくなるのが正常です。異常を見つけるには、費用の高さではなく、投入件数に対して完了件数が増えているかを見る必要があります。10倍のデータを処理して費用が10倍なら、設計どおりの可能性があります。
例として通常1,000件を2時間、40ドルで処理するバッチが、ある夜は2,500件を5時間、100ドルで処理したなら単位原価と速度は正常です。一方、1,000件のまま5時間、100ドルなら異常です。総額ではなく、投入100件あたりの費用と完了速度へ換算します。
正常値は、1件あたりと進捗速度で作る
過去7〜14回のバッチから、対象件数、成功件数、失敗件数、1件あたり入力・出力トークン、1時間あたり完了件数、総所要時間を出します。曜日や仕入れ日で件数が違うなら、絶対額ではなく1件あたりの値を中心に比較します。
基準値は平均だけにせず、正常だった回の範囲を持ちます。1件0.035〜0.045ドル、1時間450〜550件という幅を置けば、0.05ドルや300件／時への変化を検知できます。データ量の多い夜を異常扱いせず、同じ仕事に必要な資源が変わったときだけ調査できます。
- 投入100件あたりのAI呼び出し回数
- 1時間あたりの完了件数と残件数
- 同一レコードの再処理率
- 失敗理由別の再試行回数
- 成功1件あたりの推定費用
『動いている』のに止めるべきサイン
完了件数が増えないまま呼び出しだけ増える、同じIDが何度も処理される、失敗率が上昇し再試行が主な仕事になっているなら、バッチは壊れています。逆に、残件数が一定の速度で減り、1件あたり費用が基準内なら、予定より長くても処理量増加が理由かもしれません。
進捗が止まっているかは、完了件数だけでなく残件の変化で判断します。入力が同時に追加される処理では、完了が増えても残件が減らないことがあります。その場合、到着件数と処理件数を分け、処理能力不足なのか同一レコードの再投入なのかを特定します。
中断しても再開できる単位にする
一晩分を一つの巨大ジョブにせず、処理済みカーソルやレコード単位の状態を持たせます。上限や障害で止まっても、最初から再実行せず未処理分から再開できます。停止判断は「費用○ドル」だけでなく、「30分間完了件数が0」「同一IDの再試行が3回」のように進捗条件と組み合わせます。
バッチを中断する境界は、『30分間の新規完了0件』『同一IDの試行3回』『1件あたり費用が基準上限の1.5倍』など、観測可能な条件にします。単に『費用が高いとき』では当番者ごとに判断が変わります。停止時刻と最後に正常完了したIDも残します。
本番1回分の基準を作ってから安全網を置く
次の夜間処理では、投入件数、成功件数、推定費用、所要時間を一枚に残してください。標準のAI Clientを経由する処理なら、AI Cost Guardrails-CNXTの無料版を使って基本のハードストップ保護の候補値を検証できます。上限は正常な最大バッチを完走できる余裕と、壊れた処理の損失限度の間に置きます。
夜間バッチ正常性判定表は、翌朝の障害報告だけでなく容量計画に使えます。正常だが毎週終了時刻が遅くなるなら、異常ではなく処理能力の不足です。投入量、完了速度、単位原価の3か月推移から、分割実行、モデル変更、実行時間帯の見直しを判断します。クライアント報告では総額だけでなく、投入件数、正常完了率、1件あたり推定費用を添えます。費用増が仕事量によるものか、重複・失敗によるものかを分ければ、不要な不安を生まず改善提案へつなげられます。
「夜間AIバッチの『正常な急増』と『障害』を見分ける」で整理した判断を「夜間バッチ正常性判定表」だけで終わらせないでください。AI Cost Guardrails-CNXTを無料でダウンロードし、次の費用急増に備えてBasic hard-stop protectionを設定しましょう。