自動復旧を仕込んでも、土台ごと消えたら意味がない

「自動で延命する仕組みを入れたから、もう止まらない」——そう思っていたら、5日間まるごと止まっていました。

私たちは AI エージェント（Claude Code）に定期タスクを持たせて、リサーチや記事の下書きを日に何度か回しています。この定期タスクはセッションの中にしか存在せず、登録から7日で自動失効する仕様です。放っておけば必ず止まるので、1日2回すべてのジョブを登録し直す「再武装ジョブ」を1つ作りました。これで解決したはずでした。

⏳延命できるのは「時間切れ」だけだった

定期タスクが止まる理由は2種類あり、監視役が延命できたのは片方だけでした。「登録の期限切れ」は登録し直せば防げますが、「実行環境そのものの終了」は防げません。監視役自身がその実行環境の中で動いている以上、環境が終われば道連れで消えるからです。

ツールの仕様を読み直して、はっきりしました。定期タスクはセッション内のみ（in-memory）で保持され、永続化のオプションは用意されていても実際には効かないと明記されています。つまり再武装ジョブが延ばせるのは「7日の失効時計」だけで、セッションが閉じる方には手が届かない。延命の仕組みが、延命できない前提の上に立っていたわけです。

📉気づいたきっかけは、記録に残していた5日間の空白

再武装のたびに時刻を1行ずつ書き残す運用にしていたおかげで、止まっていること自体に気づけました。記録の最後の行から5日ぶんの間が空いており、その間は誰ひとり再登録していませんでした。観測の記録が無ければ、止まっているという事実にすらたどり着けなかったはずです。

空白は 2026年7月27日から31日まで。31日にジョブ一覧を確認したところ、登録されているジョブは0本でした。リサーチのレポートも記事の下書きも、最終出力が揃って7月26日で止まっていたので、原因の切り分けは早かったです。実はその前にも6日間止めており、そのときは記録が無かったので、あとから気づくまで誰も検知できませんでした。

🧭まとめ: 延命の仕組み自体が、延命の対象外になっていないか

自動化の仕組みを作るとき、「何を延命できて、何を延命できないか」を分けて考える必要がありました。監視役を作ったことで安心してしまい、その監視役自身が同じ制約の中で動いていることを見落としていたのです。

私たちが出した結論は「恒久的に動き続けてほしい処理は、そもそも別の土台に置く」でした。OS 側の常駐サービス（launchd / systemd タイマー）や CI のスケジューラのように、セッションとは無関係に生き続ける場所へ移す。自動復旧を仕込んだこと自体は正しい判断でしたが、「復旧できる範囲」を過信しないことが、その次に必要な一手でした。

📚参考

同じ課題に既存の設計思想がどう答えているかを見ると、私たちの見落としの形がはっきりします。「プロセスはいつ終了してもよい前提で設計する」という考え方は、以前から言語化されていました。

12-Factor Appsの「Disposability（廃棄容易性）」という原則や、OS標準の定期実行の仕組みが「実行環境が起きていなかった間の分をあとから捕捉する」設定を用意しているsystemdタイマーのPersistent設定を見て、同じ課題に対する解き方の違いを学びました。私たちの監視役は「終了しない前提」で作ってしまっていたことになります。