cron式は短いのに難解です。「毎週月曜の9時って 0 9 * * 1？それとも 9 0 * * 1？」のように毎回迷う人は多いはず。本記事では、cron式の構造を覚えやすい形で整理し、実務でよく使うパターン20選とデバッグの定石をまとめます。
cron式の基本構造（5フィールド）
┌──── 分（0-59）
│ ┌── 時（0-23）
│ │ ┌── 日（1-31）
│ │ │ ┌── 月（1-12）
│ │ │ │ ┌── 曜日（0-7、0と7=日曜）
│ │ │ │ │
* * * * * 実行コマンド
覚え方：「分→時→日→月→曜日」の順。日本語の自然な順序「年月日時分」とは逆です。これが慣れるまでの最大のハードルです。
| フィールド | 範囲 | 例 |
|---|---|---|
| 分 | 0-59 | */15 = 15分ごと |
| 時 | 0-23 | 9-17 = 9時から17時 |
| 日（月内） | 1-31 | 1 = 月初 |
| 月 | 1-12 | 1,7 = 1月と7月 |
| 曜日 | 0-7 | 0 または 7 = 日曜 |
特殊文字の意味
| 記号 | 意味 | 例 |
|---|---|---|
* |
すべての値 | * * * * * = 毎分 |
, |
列挙 | 0,15,30,45 = 0,15,30,45分 |
- |
範囲 | 9-17 = 9〜17時 |
/ |
間隔 | */5 = 5刻み |
? |
指定なし（一部実装のみ） | 日と曜日の競合回避 |
実務でよく使う20パターン
毎分・毎時・毎日
* * * * * 毎分実行
0 * * * * 毎時0分（毎時実行）
*/5 * * * * 5分ごと
*/15 * * * * 15分ごと
0 */2 * * * 2時間ごと（0,2,4...22時）
0 0 * * * 毎日0時（深夜）
0 9 * * * 毎日9時
30 9 * * * 毎日9:30
業務時間系
0 9-17 * * 1-5 平日9〜17時の毎時0分
*/30 9-17 * * 1-5 平日9〜17時の30分ごと
0 9 * * 1-5 平日9時のみ
0 18 * * 5 毎週金曜18時
週次・月次・年次
0 9 * * 1 毎週月曜9時
0 9 * * 1,4 毎週月・木の9時
0 0 1 * * 毎月1日0時
0 0 1 1 * 毎年1月1日0時
0 0 L * * 毎月最終日0時（一部実装のみ）
0 9 1-5 * * 毎月1〜5日の9時
0 0 1 */3 * 3ヶ月ごとの月初
高頻度系
0,30 * * * * 毎時0分と30分（30分ごとと同等）
*/10 * * * * 10分ごと
0 0 * * 6,0 毎週土日0時
注意したい3つの罠
罠1：日と曜日のORの不思議
「日」と「曜日」を両方指定したら、両方を満たす日に実行される——と思いきや、OR条件で実行される実装が多いです。
0 9 1 * 1
これは「毎月1日の9時」と「毎週月曜の9時」のどちらにも実行されます。両方を満たしたいなら、片方を * にして他方で絞ります。
罠2：曜日の「0」は日曜？月曜？
cronの仕様では 0=日曜、1=月曜、…、7=日曜 です。Linuxのcron・GNU mcron・systemd timer もすべて同じ。しかし、稀に「月曜=1」を起点にしている実装もあるため、ドキュメントを必ず確認しましょう。
罠3：タイムゾーン
サーバーのタイムゾーンに依存します。
0 9 * * * # サーバーがUTCなら、日本時間18時に実行される
意図せずズレることが多いトラブルです。crontabの先頭で TZ=Asia/Tokyo を指定すると安全。
拡張記法（特殊文字列）
cron実装によっては、人間が読みやすい記法も使えます。
| 記法 | 同等の式 |
|---|---|
@yearly / @annually |
0 0 1 1 * |
@monthly |
0 0 1 * * |
@weekly |
0 0 * * 0 |
@daily / @midnight |
0 0 * * * |
@hourly |
0 * * * * |
@reboot |
システム起動時 |
可読性が上がるので、対応している環境では積極的に使いましょう。
crontab の管理方法
編集
crontab -e # 自分のcrontabを編集
crontab -l # 一覧
crontab -r # 全削除（注意）
環境変数の指定
crontabの先頭で次のように環境変数を指定できます。
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
TZ=Asia/Tokyo
MAILTO=admin@example.com
0 9 * * * /path/to/script.sh
ログ出力
cronの出力はデフォルトでメール通知されます。ログをファイルに残すなら標準出力・エラー出力をリダイレクトしましょう。
0 9 * * * /path/to/script.sh >> /var/log/myjob.log 2>&1
デバッグの定石
1. 5分後に実行する式で動作確認
長い間隔の式を本番投入する前に、まず短い間隔でテストします。
*/5 * * * * /path/to/script.sh
2. ログを必ず取る
エラー時に何が起きたかを残す。set -e でエラー時に即終了するシェルスクリプト設定も併用すると安全です。
3. 環境変数の不一致に注意
ターミナルで動くスクリプトが cron では動かないのは、PATHや環境変数が違うことが原因の大半です。スクリプト内で必要なPATHを明示するか、絶対パスでコマンドを書きましょう。
4. cron式は必ず生成ツールで確認
可読性の悪い式は、意図と一致しているかを必ず別の手段で検証するのが鉄則です。cron式生成ツールを使えば、選択した条件から正しい式を作成し、次の実行時刻のプレビューも確認できます。
クラウド・コンテナ環境でのcron
| 環境 | 推奨方法 |
|---|---|
| AWS | EventBridge Scheduler（cron式対応） |
| GCP | Cloud Scheduler |
| Azure | Logic Apps / Function App Timer Trigger |
| Kubernetes | CronJob リソース |
| Docker | コンテナ起動時に cron デーモン起動 |
| GitHub Actions | schedule: でcron式 |
注意：クラウドのcronはUTC基準が多い。日本時間9時=
0 0 * * *(UTC) です。
まとめ - 「式」と「実行環境」を両方意識する
- 5フィールドは「分→時→日→月→曜日」の順
*/Nで間隔指定、,で列挙、-で範囲- 日と曜日の同時指定はOR条件になる実装が多い
- TZと環境変数のズレが本番トラブルの定番
- 必ず短い間隔で動作確認してから本番投入
迷ったらcron式生成ツールで式を組み立て、Unixタイムスタンプ変換ツールで実行時刻を可読化、複雑なログ整形は正規表現テスターで確認、という流れがオススメです。