定期実行の基本
Codexの定期実行（スケジュール化）は、「取得する」「作る」「確認する」「公開する」という一連の作業を、人が毎回指示しなくても決まったタイミングで走らせる仕組みです。cronやタスクスケジューラなど、実行のきっかけを作る部分と、Codexが実際に作業する部分は別のレイヤーだと考えると整理しやすくなります。
無人実行ならではのリスク
- 人が見ていない間に、誤った内容がそのまま公開される可能性がある
- 検証（verify）を挟まないと、壊れた状態のまま繰り返し実行され続けることがある
- 同じ対象に対して複数回実行されると、重複・競合した変更が生まれることがある
- 失敗時に気づく手段（ログ、通知）がないと、止まっていることにも気づけない
特に本番環境へ自動で反映する構成にする場合は、実行のたびに検証ステップを必ず挟み、検証が失敗したらその回は何もしない設計にすることが重要です。
組む前のチェックリスト
- 失敗時に自動で止まる条件を決めたか
- 実行対象の範囲（触ってよい範囲）を限定したか
- 実行前・実行後にログが残る仕組みがあるか
- APIキーやパスワードなどの秘密情報を安全に扱えているか
- 想定外の重複実行が起きない間隔になっているか
実行間隔と重複実行の設計
定期実行でつまずきやすいのは、実行そのものより「間隔」と「重複」の設計です。よくある失敗と対策を整理します。
| 設計項目 | よくある失敗 | 対策の考え方 |
|---|---|---|
| 実行間隔 | 「多いほど新鮮」と考えて短くしすぎ、前回の実行が終わる前に次が始まる | 1回の処理にかかる最大時間を測ってから、その2〜3倍以上の間隔にする |
| 重複実行の防止 | 2つの実行が同じファイルを同時に書き換えて内容が壊れる | flockなどのロック機構で「前の実行が生きていたら今回は何もせず終了」にする |
| 実行時刻 | サーバーのタイムゾーン設定を確認せず、意図と違う時刻に動く | cron登録前にサーバーの現在時刻とタイムゾーンを必ず確認する |
| 失敗の通知 | ログは残るが誰も見ておらず、数週間止まっていたことに後から気づく | 「成功したら日付を記録し、記録が古いままなら異常」という形の逆転の検知にする |
特に最後の「止まっていることに気づけない」問題は、自動化の一番の落とし穴です。失敗した時に通知を送る作りは、通知処理自体が失敗すると意味がなくなります。逆に「成功のたびに更新される記録」を人間が時々見る形にすると、どんな失敗の仕方でも記録の古さとして現れるため、検知漏れが起きにくくなります。
実際に組むときの3つの部品
定期実行は「時刻を決めて呼ぶ」だけでは足りません。無人で動く以上、二重に走らない仕掛けと、自分で止まる条件を必ず一緒に作ります。この3つが揃って初めて、放っておける形になります。
| 部品 | 役割 | 無いとどうなるか |
|---|---|---|
| 呼び出し | 決まった時刻に起動する | — |
| 重複よけ | 前回がまだ動いていたら起動しない | 処理が重なり、同じ更新を二重に書く |
| 停止条件 | 連続で失敗したら自分から止まる | 失敗したまま延々と走り続ける |
重複よけは、開始時に印を置き、終了時に消すだけで足ります。印が残っていたらその回は何もしません。ただし異常終了すると印が残ったままになるので、置いた時刻も一緒に記録し、古すぎる印は無視する作りにしておきます。これが無いと、一度落ちただけで以後ずっと起動しなくなります。
止め方でつまずくところ
組むより、止めるほうが間違えやすいところです。実際に踏んだものを挙げます。
- 親を止めても子が残る。呼び出し元を終了させただけでは、そこから起動された処理が生き残ることがあります。止めた後に、動いている処理が本当に消えたかを確認してください
- 登録した処理の中身を直接実行しても、何も起きないことがある。定期実行の枠組みが渡す条件が揃っていないためで、動かないからといって壊れているとは限りません。試すときは枠組みごと動かします
- 止めた記憶と実際がずれる。複数の作業を並行していると、どれを止めたかが分からなくなります。登録した一覧をいつでも出せるようにしておきます
そして本番へ反映する処理は、定期実行に入れる前に必ず手動で通してください。無人実行は、うまくいっている時は静かですが、間違った変更も同じだけ静かに積み上がります。
よくある質問
codex cronとcodex scheduleは同じ意味ですか？
検索の言い回しの違いで、どちらもCodexを決まったタイミングで自動実行したいという同じ意図で使われることが多いです。
本番への反映まで自動化しても大丈夫ですか？
技術的には可能ですが、人の確認を挟まない分、検証ステップと失敗時に止める仕組みが特に重要になります。範囲を絞って始めるのが安全です。
失敗した時はどう気づけばいいですか？
実行ログを残す、検証失敗時に分かる形で記録するなど、後から気づける仕組みを先に用意しておくと安心です。