バッチ処理・定期レポート送信・キャッシュクリア・バックアップなど、定期実行タスクの設定にはcron式を使います。「毎日午前2時に実行したい」という要件をcron式に変換する際、フィールドの順序や特殊文字の意味を誤解してしまうことはよくあります。この記事では、cron式の基本構文から実務でよく使うパターン、ハマりやすい落とし穴まで体系的に解説します。
cron式の5つのフィールド
cron式は左から「分（0-59）・時（0-23）・日（1-31）・月（1-12）・曜日（0-7、0と7が日曜日）」の5フィールドで構成されます。例えば `30 2 * * *` は「毎日2時30分」、`0 9 * * 1` は「毎週月曜日9時0分」を意味します。各フィールドに `*` を使うと「すべての値」を意味します。フィールドの数はシステムによって違うので、書く前に必ず確かめます。GitHub Actions の schedule は Linux の crontab と同じ5フィールドです。AWS EventBridge のルールの cron は、末尾に「年」が付いた6フィールドで、日と曜日のどちらか一方を `?` にする決まりがあります。Java の Quartz や Spring のスケジューラは、先頭に「秒」が付きます。同じ `0 9 * * 1` でも、どのシステムに書くかで意味が変わったりエラーになったりします。
この手順で使うツール
CRON 式ビルダー
cron 式をビジュアルで組み立て・日本語で解説
特殊文字：*/,-の使い方
`*`（アスタリスク）はすべての値を意味します。`*/n` はn間隔（`*/15` なら15分ごと）、`,`（カンマ）は複数値の列挙（`1,15` なら1日と15日）、`-`（ハイフン）は範囲指定（`1-5` は月〜金）に使います。例えば `0 */6 * * *` は6時間ごと（0・6・12・18時）、`0 9 * * 1-5` は平日（月〜金）の9時0分、`0 0 1,15 * *` は毎月1日と15日の0時0分を意味します。`L`（Last）や `W`（Weekday）などの特殊文字はQuartzスケジューラやAWS固有の拡張で、標準cronでは使えないため注意が必要です。ここで落とし穴が2つあります。1つ目は、日と曜日を両方指定したときの意味です。`0 0 13 * 5` は「13日の金曜日」ではなく、「毎月13日」と「毎週金曜日」のどちらかに当てはまる日に実行されます。日と曜日の両方が `*` 以外だと、標準の cron は「または」として扱うためです。2つ目は `*/n` の数え方で、範囲の最初の値から n おきに数えます。日の `*/2` は1・3・5…31日で、31日の翌日の1日にも実行されるので、月をまたぐと2日連続になります。分の `*/7` も 0・7…56分の次は次の時の0分で、間が4分しか空きません。Cron Builder に式を入れると、次の5回の実行日時と日本語の説明が出るので、こうした「思っていたのと違う日」にその場で気づけます。
この手順で使うツール
CRON 式ビルダー
cron 式をビジュアルで組み立て・日本語で解説
定番パターン集
`0 0 * * *`（毎日0時）はバックアップ・日次レポートの定番設定です。`0 */1 * * *`（毎時0分）はAPIのキャッシュクリアや定期同期に使われます。`0 9 * * 1`（毎週月曜9時）は週次レポートメール送信の典型パターンで、ビジネス向けシステムでよく使われます。`0 0 1 * *`（毎月1日0時）は月次集計バッチ。`*/5 * * * *`（5分ごと）は健全性チェック（ヘルスチェック）やポーリング処理に使います。`0 2 * * 0`（毎週日曜2時）は週次のデータ整備やフルバックアップに向いています。トラフィックが少ない深夜〜早朝の時間帯に重い処理を設定することで、本番環境への影響を最小化できます。
この手順で使うツール
CRON 式ビルダー
cron 式をビジュアルで組み立て・日本語で解説
タイムゾーンとcronの落とし穴
cronのデフォルトのタイムゾーンはサーバーのシステムタイムゾーンです。UTCで動いているサーバーに「毎朝9時（JST）」の処理を設定したい場合は `0 0 * * *`（UTC 0:00 = JST 9:00）と書く必要があります。GitHub Actions の schedule は常に UTC です。Linux の crontab では、cronie など一部の実装が `CRON_TZ=Asia/Tokyo` でタイムゾーンを指定できますが、使えない実装もあるので、サーバーの cron が対応しているかを確かめてから使います。AWS では、EventBridge Scheduler ならスケジュールごとにタイムゾーンを選べます（EventBridge のルールの cron は UTC です）。夏時間（サマータイム）がある地域では、切り替わる日に `2:30` のような時刻が存在しなかったり2回来たりして、ジョブが飛んだり2回動いたりします。日本は夏時間が無いので JST のままでも問題は起きませんが、海外のサーバーや利用者が関わる場合は注意が必要です。UTCでの時刻とJSTでの時刻の対応は、Timezone Converter で確かめられます。なお Cron Builder の「次回実行時刻」は、ブラウザの時刻帯で計算しています。
この手順で使うツール
Time Zone Converter
最大5都市のタイムゾーンを同時変換・ビジネスアワー重複をビジュアル表示
まとめ
cron式は一見暗号のように見えますが、「分・時・日・月・曜日」の順と `*` `/` `,` `-` の意味を押さえれば大半のパターンを書けます。そのうえで「書くシステムのフィールド数」「日と曜日を両方指定すると“または”になる」「*/n は範囲の最初から数え、月や時をまたぐと間隔が崩れる」「どのタイムゾーンで動くか」の4点を確かめてください。設定後は必ず次の実行日時を確認するのが確実で、Cron Builder のプレビューを使えば意図どおりの設定かをその場で確かめられます。