Cron式は、1970年代からUnix系システムで使われている、タスクの繰り返しスケジュールを表現するコンパクトな方法です。スペースで区切られた5つのフィールドで、ほぼあらゆる規則的なスケジュールを表現できます。
式の5つのフィールド
標準的なcron式は分 時 日 月 曜日の形式です。例えば、30 14 * * 1は「毎週月曜日の14時30分」を意味します——アスタリスクは日と月に対して「任意の値」を意味します。
スラッシュとカンマの意味
*/15 * * * *のようにアスタリスクの後のスラッシュは「15単位ごと」を意味します——この場合は15分ごとです。カンマを使うと複数の特定の値を列挙できます。例えば、0 9,18 * * *は9時と18時の1日2回タスクを実行します。
「曜日」フィールドが最も混乱を招く理由
標準的なcronでは、「日」フィールドと「曜日」フィールドの両方を同時にアスタリスク以外に設定できます——その場合、タスクは2つの条件のうち少なくとも一方が一致すれば実行されます（論理ANDではなくOR）。これはほとんどの人の直感的な期待に反します。
今も現役の crontab -e という運用文化
日本の運用現場では、Kubernetesのような新しい基盤が広がった今でも、枯れた技術として信頼性が重視されるバッチ処理やレガシーシステムの定期実行に、サーバー上で直接crontab -eを編集する運用が根強く残っている。長年変わらないこの構文の安定性こそが、cronが半世紀近く現場で使われ続けている理由のひとつだ。
なぜこれが必要か
- サーバー設定やCI/CDパイプラインで他人が書いたcron式を読み解く。
- 本番環境にデプロイする前に、書いたスケジュールが正しいか確認する。
- タスクの次の数回の実行の正確な時刻を計画する。
夏時間/冬時間の切り替えとcron
スケジューラーが夏時間の切り替えがあるタイムゾーンで動作している場合、存在しない時刻(例えば時計を進める夜の2時30分)に設定されたタスクはその日実行されないことがあり、時計を戻す際に繰り返される時刻に設定されたタスクは2回実行されることがあります。日本自体は現在サマータイムを採用していないためこの問題とは無縁だが、海外サーバーと連携するシステムを組む際には注意が必要で、重要なタスクには明示的にUTCタイムゾーンを指定することが多い。