長時間ジョブにチェックポイントを入れる
収録 2026-11-06
三時間のジョブが落ちたとき、最初からやり直すべきではない。
長時間のバッチ処理があります：[処理内容、規模、失敗の仕方]。チェックポイント再開を設計してください：1）粒度（バッチ単位、ファイル単位、時間単位）とコストの兼ね合い；2）状態の記録形式（完了、処理中、失敗項目、冪等キー）；3）クラッシュ後に「処理中」をどう判定し、やり直すか；4）並行処理や順序の乱れで二重処理を防ぐ方法；5）コード変更でチェックポイントが不整合になった場合（バージョン、無効化）；6）受け入れ方法：途中で落としても一度で完走した結果と一致すること。
当サイトオリジナル
中国語の原文
置き換えるプレースホルダー 1
括弧の中をご自身の情報に置き換えてから送ってください。
[処理内容、規模、失敗の仕方]
使い方
チェックポイントには冪等キーを。なければ再開は再処理になる。
こう変えてみる
- コードを書く前に要件と制約を復唱させる。
- 全体書き換えではなく、最小の変更とロールバック方法を出させる。
得られる成果物
- そのまま使える最小変更（コピー可能なコード）
- 影響範囲：変更ファイルと追従が必要な呼び出し元
よくある失敗
- 一度に十ファイル変更させ、何が原因か分からなくなる。
- エラーだけ貼ってコードとバージョンを省くと、使えない修正が返る。
出力のチェック
- 変更は動いて戻せて、無関係なコードに手を入れていない。
- 境界条件（空・巨大・同時実行）が説明かテストで押さえられている。
使いどころと注意
- 向いている用途：要件と制約を復唱させてから、最小限の動く変更を出させる。
- 注意：エラーにはバージョンと最小再現を添える。無いと一見もっともらしいが合わない修正が返る。