cron 式とは何ですか？
cron 式は、ジョブスケジューラーにタスクをいつ実行するかを正確に伝えるコンパクトなスケジューリング文字列です。このフォーマットは 1975 年の Unix V7 cron デーモンで生まれ、以来ほとんど変わっていません — 同じ 5 フィールドの文法が今日の Kubernetes CronJob、AWS EventBridge、GitHub Actions ワークフロー、Google Cloud Scheduler、GitLab CI、Jenkins パイプライン、そしてすべての Linux ディストリビューションに同梱されている crontab バイナリに使われています。この文法は 13 文字程度の中に多くの意味を詰め込んでいます。だからこそ、それを平易な日本語に変換するパーサーが、自信を持ったデプロイと深夜 3 時のロールバックの分かれ目になります。
cron 式はどのように機能しますか？
標準的な cron 式は、繰り返しスケジュールを定義する 5 つのスペース区切りフィールドで構成されています。エンジンは毎分現在時刻と式を照合し、5 つのフィールドがすべて一致したときにジョブを実行します。フィールドは左から順に：
- 分（0–59）。ジョブが実行される時間内の分。
0は毎時 0 分、30は 30 分、*/5は 5 分ごと（00, 05, 10, ...）、15,45は 15 分と 45 分に実行します。 - 時（0–23）。24 時間制での時刻。
0は深夜 0 時、9は午前 9 時、17は午後 5 時です。範囲（9-17は業務時間）やステップ値（*/2は 2 時間ごと）も分と同様に機能します。 - 日（1–31）。実行するカレンダーの日付。
1は月の 1 日、*は毎日、1,15は 1 日と 15 日です。31は 31 日が存在しない月では暗黙的にスキップされる点に注意してください。 - 月（1–12 または JAN–DEC）。実行する月。
*は毎月、1,7は 1 月と 7 月、1-3は第 1 四半期のみです。3 文字の月名はほとんどの実装で大文字小文字を区別しません。 - 曜日（0–7、0 と 7 はどちらも日曜日）。特定の曜日への実行を制限します。
1-5は月曜から金曜、0,6は週末、MON-FRIはほとんどのパーサーで機能します。日（月内）と曜日の両方が特定の値に設定されている場合、従来の cron はいずれかが一致したときに実行します（論理 OR）。これは毎回人を驚かせます。
cron 式パーサーを使う理由は何ですか？
- デプロイ前にサイレントな読み間違いを検出できます。`0 2 */3 * *` という式は 3 分ごとではなく、3 日ごとの午前 2 時に実行されます — ここに貼り付ければ本番に投入する前に平易な日本語で確認できます。
- ほとんどのクラウドスケジューラーはデフォルトで UTC で動作します。ローカルタイムゾーンで次の 10 回の実行時刻をプレビューすることで、深夜 3 時に誰かを呼び出す前に夏時間の 1 時間ずれを発見できます。
- `@daily`、`@weekly`、`@monthly` などのショートカットは便利ですが曖昧です。パーサーは基礎となる 5 フィールド形式を表示するので、何がスケジュールされているかを正確に把握できます。
- フィールドごとのビルダーを使えば、スケジュールを 1 列ずつ組み立てながら人間が読める説明がリアルタイムで更新されます。cron の man ページを 10 回読み直すよりずっと速く確認できます。
cron 式はどこで使われますか？
cron 構文はジョブが定期的に繰り返す必要があるあらゆる場所に登場します。最も一般的な 3 つのユースケースと、それぞれ有名な落とし穴：
- バックアップスケジュール。古典的な `crontab -e` エントリで毎晩午前 2 時にデータベースを S3 にダンプしたり、毎月 1 日に `pg_dump` アーカイブをローテーションします。`0 2 * * * /usr/local/bin/backup.sh` という行は、史上最も多くの Linux サーバーに記述された cron の 1 行です。分と時を正しく設定し、stderr をどこかに記録すれば、手動チェックリストを自動スクリプトに置き換えられます。
- GitHub Actions の `schedule` トリガー。`.github/workflows/*.yml` の `on.schedule.cron` キーは標準の 5 フィールド cron を受け付けますが、ジョブは常に UTC で実行され、ランナーキューが混雑している場合は GitHub が実行をサイレントにスキップすることがあります。一般的なパターン：`cron: '0 9 * * 1-5'` で月曜から金曜の午前 9 時 UTC にダイジェストを送信。ここでローカルタイムゾーンでプレビューして、BST（夏時間）に実際には午前 10 時に届く London 向け「午前 9 時」ダイジェストを約束しないようにしましょう。
- AWS EventBridge Scheduler。EventBridge cron 式は 6 番目のフィールドとして年を追加し、日付フィールドまたは曜日フィールドのいずれかに `*` の代わりに `?` が必要です — `cron(0 9 ? * MON-FRI *)` が平日午前 9 時の標準 cron の EventBridge 版です。Lambda 呼び出しや ECS タスク実行、Step Functions ステートマシン起動に使われます。標準 cron 構文との不一致は、CloudFormation デプロイで `ValidationException` エラーが最も頻繁に発生する原因です。
実際の cron 式はどのように見えますか？
0 9 * * 1-5 を例にとると — 毎平日午前 9 時 0 分に実行されます。フィールドを左から読むと：0 は時間内の 0 分、9 は 24 時間制の午前 9 時、日（月内）の * は毎日、月の * は毎月、曜日の 1-5 は月曜から金曜（標準 cron 番号体系で 1 = 月曜）に限定します。これを上の入力に貼り付けると、パーサーは選択した IANA タイムゾーンで次の 10 回の日付とともに 月曜から金曜の午前 9 時 0 分 と確認します。AWS EventBridge 構文での同じ意図は cron(0 9 ? * MON-FRI *) — 末尾の年フィールドと、標準 cron が `*` を使う箇所の `?` に注意してください。Quartz 式（先頭に秒を追加した 6 フィールド）では 0 0 9 ? * MON-FRI になります。3 つの異なるプラットフォーム、3 つの異なる表記形式、1 つの同じスケジュールです。
cron 式には 1 つだけ厳しい点があります：タイポが構文的には有効だが間違った時刻に実行されるスケジュールを生み出し、コードレビューで検出できるエラーが何も出ません。`0 0 1 * *` を読んで 1 月 1 日ではなく毎月 1 日の深夜 0 時に実行されることを知るには練習が必要です。上のパーサーはその練習を 10 秒のサニティーチェックに変えてくれます — 式を貼り付け、日本語で読み、ローカルタイムゾーンで次の 10 回の実行時刻を確認し、cron の行が commit メッセージの通りに動くことを確かめて YAML を投入しましょう。
5 フィールドと 6 フィールドの cron の違いは何ですか？
5 フィールド cron は 1 分解像度の古典的な Unix 文法です。6 フィールド cron は先頭に秒列を追加してサブ分スケジューリングを可能にします — Quartz と Spring の @Scheduled で使用されます。AWS EventBridge も 6 フィールドを使いますが、追加列は秒ではなく末尾の年です。
@hourly、@daily、@weekly は何を意味しますか？
1987 年に Vixie-cron で導入されたニックネームです。@hourly = 0 * * * *、@daily = 0 0 * * *、@weekly = 0 0 * * 0、@monthly = 0 0 1 * *、@yearly = 0 0 1 1 *。@reboot はブート時に一度実行されます。GitHub Actions と EventBridge はこれらのエイリアスを拒否します。
cron では日曜日は 0 ですか、それとも 7 ですか？
古典的な Vixie cron では両方です — 0 と 7 の両方が受け入れられるため、5-7 のような範囲が金曜から日曜として自然に読めます。月曜は常に 1、土曜は常に 6 です。Quartz と AWS EventBridge は異なる規約を使います：1-7 で日曜が 1。プラットフォームのドキュメントを確認してから前提を立ててください。
cron は夏時間をどのように処理しますか？
エンジンのタイムゾーンによります。UTC（EventBridge、Kubernetes、GitHub Actions のデフォルト）では夏時間は存在しません。ローカルの夏時間ゾーンでは、古典的な Vixie cron は春の時計を進める間隔中のジョブをスキップし、秋の時計を戻す間隔中は 2 回実行します。一方 systemd タイマーは正確に 1 回実行されます。