Cronの重複実行を『Bot攻撃』と誤説明しないための財務向け1ページ

重複処理を外部Botと決めつけない

在庫同期が11分かかるのに実行ロックが5分で切れると、6分目に次の処理が開始できてしまいます。ログには似たAI要求が連続して現れますが、発生源がWordPressのバックグラウンド処理なら、訪問者をHuman、Bot、Unknownへ分類する問題ではありません。

財務説明で『Botにやられた』と短絡すると、誤った通信遮断へ予算が使われ、内部不具合が残ります。発生源、実行コンテキスト、開始時刻、ロック所有者、重複範囲を示し、悪意の有無ではなく制御点を明確にします。

11分の実行と5分のロックを並べる

対象ジョブの実行時間を最低30回分取り、中央値だけでなく95パーセンタイルを出します。それが11分なら、5分の固定ロックは例外的な遅延ではなく通常範囲内で失効し、重複を許す設計です。

三つの重複開始について、最初のジョブが完了する前に次のロックを誰が取得したかを記録します。source=inventory-sync、context=background、同一の処理対象、外部アクセス記録なしがそろえば、外部自動化より内部並行実行を優先して説明できます。

財務が必要とする結論だけを一枚に置く

財務が必要なのは実装の全ログではなく、なぜ費用が重複し、どの修正で再発確率を下げ、費用上限をどう守るかです。原因を『ロックが処理完了前に失効』、影響を『同一対象へ外部要求が3回』、修正を『更新可能なロックと単一所有者』と一文ずつ書きます。

重複費用を実額と最大額に分ける

金額は実際の重複要求数×各要求の請求額で出し、最大想定も別記します。AI Cost Circuit Breakerの推定値は状況把握に使えますが、正式な損失額はプロバイダー請求書で確定し、直接呼び出しなど対象外経路がないかも添えます。

ロック延長ではなく所有権を直す

ロックを20分へ延ばすだけでは、処理が停止した際に20分間復旧できず、将来25分かかれば再発します。実行中に所有者が有効期間を更新し、異常終了時だけ期限切れで引き継げる仕組みと、同じ業務キーを二者が処理しない確認が必要です。

暫定措置として実行コンテキスト別の上限や同一要求の反復制御を使う場合も、それを恒久修正と呼びません。内部ジョブが一度だけ所有される設計へ直し、保護機能は万一の増幅を止める二段目に置きます。

重複ゼロと異常終了からの復旧を試す

修正後に正常、遅延、途中停止を含む30回の試験を行い、同じ業務キーの並行所有が0件であることを確認します。同時に実行者を強制終了し、ロックが安全に解放または引き継がれて処理が永久停止しないことも試します。

1ページ説明書の結論は『Botではなかった』だけでは不十分です。内部原因を証明し、重複費用の最大値を限定し、復旧試験まで通したことを示せば、財務は通信遮断ではなく正しい実装修正へ承認を出せます。

「Cronの重複実行を『Bot攻撃』と誤説明しないための財務向け1ページ」の「原因・制御の1ページ説明書」を、最初の実環境導入に使ってください。AI Cost Circuit Breakerを無料でダウンロードし、Monitoringから始め、期待するシグナルと戻し方を確認してから制御を有効にしましょう。