57分間、死んだジョブを誰も見ていなかった ― 見張りを機械に渡す実装

長時間かかるジョブをAIエージェントに走らせた際、見張りの監視を途中で止めたところ、その34分後にジョブが落ちた。誰も気づかず、次に気づいたのは57分後だった。原因は単純で、監視を止めた人が「見る責任」を誰にも渡していなかったことだ。この記事は、その空白を埋めるために、見張りを機械に持たせる実装を、動くコードごと示している。

AIの鬼の視点で面白いのは、「動いているか」ではなく「動くべきなのに動いていないか」を判定しなければ、落ちたことに気づけないという指摘だ。プロセスの生死だけを見る監視は、固まったジョブを見逃し、死んだロックを残したまま後続を永久に待たせる。ここで効いたのは、状態に SHOULD_BE_RUNNING を足したことだ。人間の見張りは「止めました」とログを一行残して静かに消える。機械の見張りは、消えたこと自体を異常として数える。もう一つ引っかかるのは、「早く再開する」と「正しく再開する」は別物だという点だ。自動再開で得られるのは数十分の短縮だが、誤れば復旧できないデータの欠測になる。だから、原因が特定され手順が確定し、再開回数に上限があるときだけ機械に再開を許す。「繰り返し落ちる」は再開ボタンを押す合図ではなく、原因を見る合図だという割り切りが、この実装の本音だと感じる。

中小企業の実務に落とすなら、夜間バッチやデータ連携を走らせている会社は多いが、その「見る人」を決めていないことがほとんどだ。明日からできるのは、長時間の処理ごとに「どこを見れば進んでいると分かるか」「止まったら誰が判断するか」を一行ずつ書き出すことである。書けない処理は監視に載せない。Windowsでプロセスの生存を確認するなら、確認のために終了させてしまう関数を使わないこと。判定できなかった状態を「死んだ」と丸めないこと。この二点は、社内スクリプトの見直しで今日から効く。