止まったメディア更新を、見張り役が自動で叩き起こしていた話 ― 導入初日に3本を復活させた記録

この記事は、前の記録の続きです

前の記録（毎朝動いているはずのAI自動化41本を5.3日ぶん数えたら、最大91%が発火すらしていなかった）で、当社の自社メディア更新が最大91%抜けていた、という都合の悪い数字を出しました。

穴が空いているとわかったら、塞ぐしかありません。塞ぎ方は2つあります。原因を突き止めて直すか、止まったら自動で叩き起こすか。原因（1回の処理が数十分と長いこと）の機序はまだ追い切れていないので、先に後者を入れました。「見張り役（watchdog）」です。

結論から言うと、この見張り役は導入初日から仕事をしました。止まっていた3本を自動で叩き起こし、59時間止まっていた記事生成を51分かけて復活させました。 ただし、見張り役自身にも正直な弱点があります。それも含めて載せます。

見張り役（watchdog） … 他のジョブがちゃんと動いているかを定期的に見回り、止まっていたら再始動させる番人のプログラムです。今回は1時間ごとに動かしています。
「止まっている」の判定 … 2通りで判断します。①起動した記録（run_start）だけ残って、終了の記録（run_end）が一定時間経っても来ない。②最後に成功してから、そのジョブの予定間隔＋余裕を過ぎても新しい成功がない。このどちらかなら「止まった」とみなします。
クールダウン … 同じジョブを短時間に何度も蹴らないための待ち時間です。一度再始動したら、次に蹴るまで一定時間あけます。暴走を防ぐ仕組みです。

自動で再始動する仕組みは、作り方を間違えるとそれ自体が暴走します。全ジョブを一斉に何度も蹴り続けて、Macを過負荷で落とすからです。そうならないよう、3つの箍（たが）をはめました。

2026年7月23日 19:00、見張り役の初回の見回り。

見回った結果、7本が止まっていると判定されました。 そのうち上限の3本を再始動し、残る4本は「今回の上限に達したので次回に回す」と記録されました。

そして、再始動した3本がどうなったか。

最後の1本が、地味にいちばん価値がありました。見張り役が叩き起こしたジョブが、さらに別の止まっているジョブを見つけてきたからです。穴の底に、もう一つ穴があったわけです。

この仕組みは初日から役に立ちました。が、万能ではありません。都合の悪いところも書きます。

見張り役自身も、cronで動く1本のジョブです。 つまり、前の記事で書いた「cronが抜ける」問題は、この見張り役にも起こりえます。番人が寝ていたら、誰も番をしていません。 番人を見張る仕組みは、まだありません。
一度に3本しか戻せません。 初日は7本止まっていて、4本は次の時間に持ち越されました。同時多発で止まると、全部が戻るまで数時間かかります。
これは対症療法です。 なぜメディア更新が数十分もかかり、抜けるのか——その根本原因は、まだ突き止められていません。叩き起こしているだけで、倒れる理由は直っていない。
導入したてで、実績はまだ初日の3本だけです。「うまくいっている」と言い切るには早い。数週間まわして、再始動の回数と成功率がどう出るかを、また数えて報告します。

それでも、この一手には意味があります。前の記事の問題は「止まっても誰も気づかない」ことでした。見張り役は、少なくとも気づいて、動く。気づかないまま何日も止まっているより、はるかにましです。