このチェックリストで確認すること
cronは登録して終わりではありません。手動実行、ログ、重複防止、翌日確認までセットで見ます。
使うタイミング
ニュース取得や定期更新など、自動実行処理を登録する前後に使います。
チェック項目
| 項目 | なぜ必要か | 確認のやり方 |
|---|---|---|
| 手動実行が成功している | 手動で動かないものは自動でも動かない。cron登録は「動くことが確認済みの処理」を予約する行為 | 同じコマンドをシェルから直接実行し、正常終了と出力を確認 |
| ログが残る | ログなしのcronは、失敗しても気づけず「動いていたつもり」が続く | 出力をログファイルへリダイレクトし、実行後にログの中身を見る |
| flockなどで重複起動を避けている | 処理が長引いた時に次の実行が重なると、データ破損や二重投稿の原因になる | flock経由の起動にするか、処理内でロックファイルを確認 |
| 実行時刻が適切 | 深夜のバックアップと重ねるとサーバー負荷が集中する。取得系は相手サイトへの配慮も必要 | 既存cronの時刻一覧と突き合わせて間隔を空ける |
| 同じcronが重複していない | 過去の登録が残ったまま追加すると、同じ処理が2回走る | crontab -l で全登録を見て、同一コマンドがないか確認 |
| 出力ファイルが壊れていない | JSONの書きかけ保存などで壊れると、それを読む後続処理も連鎖して失敗する | 実行後に出力ファイルを開き、形式が正しいか確認 |
| 既存データが消えていない | 追記のつもりが上書きになっている事故は珍しくない | 実行前後でファイルサイズ・件数を比較 |
| 翌日に実行記録を確認する | 登録直後の1回と、無人での定時実行は条件が違う（環境変数・パスなど） | 翌日にログの実行時刻と結果を確認して初めて完了 |
ポイントは「登録した瞬間」ではなく「翌日の無人実行が成功した瞬間」を完了と見なすことです。cronの事故は登録時ではなく、数日後に静かに起きていることが多いためです。
よくあるミス
- 手動実行前にcron登録する
- ログなしで登録する
- 同じ処理を重複登録する
- 翌日確認を忘れる
「手動では動くのにcronでは動かない」の正体
cronの質問で最も多いのがこのパターンです。手動実行とcron実行では、実は環境が違います。原因はほぼ次の3つに集約されます。
| 原因 | 何が起きるか | 対策 |
|---|---|---|
| PATHが違う | 手動シェルでは通っているコマンド（node、phpなど）が、cronの最小限の環境では見つからない | cronに書くコマンドは/usr/bin/phpのようにフルパスで書く |
| 作業ディレクトリが違う | スクリプト内の相対パス（./data/file.jsonなど）が、意図と違う場所を指す | スクリプト冒頭でcdするか、パスをすべて絶対パスにする |
| 環境変数が無い | 手動シェルの設定ファイルで読み込まれる変数が、cronでは読み込まれない | 必要な変数はcron行かスクリプト内で明示的に設定する |
切り分けのコツは、エラーメッセージを憶測せずログに実際のエラーを吐かせることです。ログさえあれば「command not found（=PATH）」「No such file（=パス）」のように、上の3つのどれかが一目で分かります。ログなしで登録してしまった場合は、原因調査の前にまずログ出力を足すのが結局いちばん速い手順です。
Codexへ確認を頼む時の指示文
cron設定チェックをしてください。手動実行、ログ、flock、実行時刻、重複cron、出力ファイル、翌日確認項目を確認し、登録してよい条件を満たすか報告してください。停止条件
以下が出た場合は、作業を続けずに報告します。
- 手動実行でエラー
- ログが出ない
- 出力ファイルが壊れる
- 既存cronを上書きしそう