15. cronジョブが実行されない場合の系統的トラブルシューティング手順

2026年4月10日 2026年4月27日 fdlc

cronの実行タイミングと実行環境の乖離

ローカルで手動実行できるスクリプトが、cron経由で実行されないという事象は、実行環境の差異が原因であることがほとんどです。cronは、ユーザーが意識するシェルセッションとは異なる、非常に限定的でクリーンな環境でプロセスを起動するため、パスや環境変数が期待通りでないことが最大の落とし穴となります。

cronは、指定されたコマンドを、指定されたユーザーの権限で、指定された環境変数セットを用いて実行します。この「最小限の環境」を理解し、それを再現することがデバッグの基本となります。

以下のフローで、原因を最も可能性の高いものから順に切り分けます。

ステップ	確認すべきレイヤー	具体的な確認コマンドとアクション
1. スケジューラ自体の確認	cronデーモンが稼働し、ジョブが登録されているか	crontab -lで記述内容を確認し、構文エラーがないか確認する。また、システムログ（/var/log/syslogなど）でcronデーモン自体のエラーログがないか確認する
2. 実行権限とユーザーの確認	ジョブを実行するユーザーに、必要なリソースへのアクセス権があるか	sudo -u <user> <command>のように、明示的にユーザーを指定して実行し、権限不足による失敗（Permission Denied）がないかを確認する
3. 環境変数の明示的な指定	スクリプトが依存する環境変数がcron実行時に渡されているか	PATHやAPIキーなどの環境変数は、export VAR=valueをジョブの先頭に記述するか、bash -c 'export VAR=value && your_script.sh'のように明示的に渡す必要がある
4. ログのキャプチャとリダイレクトの徹底	標準出力と標準エラー出力を必ずファイルに記録する	ジョブの最後に> /path/to/log.log 2>1を付与し、実行結果をファイルに強制的に書き出すことが、最も基本的な防御策である。

定期実行ジョブは、同じ処理を複数回実行する可能性があるため、処理の冪等性（Idempotency）を担保することが極めて重要です。処理の開始時に実行IDやタイムスタンプをチェックし、既に処理が完了している場合は即座に終了するロジックを組み込むべきです。

cronジョブのトラブルシューティングは、まず「ログをファイルに強制的に吐き出す」ことで、実行環境の差異による情報を失わないことが最優先事項です。その後、環境変数を明示的に指定し、最小限のテストで再現性を確認することが、成功への最短ルートとなります。