Cron式パーサー・Crontabビルダー
Cron式の解説とcrontab式の作成
Cron式の解説とcrontab式の作成
説明
上にCron式を入力すると、説明と次回の実行時刻がここに表示されます。
フィールド内訳
読み込み中…
処理中…
0.0
停止していません。計算が終わると結果が表示されます。
Cron式パーサー・Crontabビルダーについて
このツールは標準の5フィールドUnix cron(分 時 日 月 曜日)を読み取って文章で説明し、次回の実行時刻を1分ずつ実際に進めながら探して表示します。「ビルダー」タブでは逆に、頻度・時刻・曜日を選んで式を組み立て、同じルールで検算します。
cronの1行は短いものの、間違いの多くは文法ではなく解釈にあります。日と曜日を両方書くとANDではなくORになり、同じ式でもサーバーのタイムゾーン次第で9時間ずれ、QuartzやSpringの式はフィールドが1つ多い。以下では、こうした落とし穴を具体的なスケジュールで確認します。
日と曜日を両方指定するとORになる
0 9 1 * 1は「毎月1日が月曜なら9時」と読みたくなりますが、POSIXのcrontab仕様は逆です。日フィールドと曜日フィールドがどちらも*でなければ、どちらか一方に一致した日に実行されます。つまりこの行は「毎月1日の9時」と「毎週月曜の9時」の両方です。片方が*なら条件から外れるので、直感どおりに動きます。
このツールの次回実行の計算も同じ規則です。元の式がちょうど*だったかを覚えておき、両方が制限されているときだけORで判定します。「毎月第1月曜」のような積集合が必要なら標準cronでは書けないので、0 9 1-7 * *で起動してスクリプト内で曜日を確認するのが定番です(1〜7日には月曜がちょうど1回あります)。
タイムゾーン:同じ行が別の時刻に動く
cron式にはタイムゾーンの情報がありません。Linuxのcronはそのマシンのローカル時刻で解釈し、このツールはブラウザのローカル時刻で次回実行を表示します。クラウドのサーバーはUTCが既定のことが多く、日本で「0 9 * * *」と書いて朝9時のつもりが、実際には日本時間18時に動くという事故が起きます。
GitHub Actionsのscheduleイベントも既定はUTCです。日本時間の朝9時に動かすなら0 0 * * *と書きます(UTC+9)。最新のドキュメントにはIANAタイムゾーン名を指定するtimezoneキーが載っていますが、既存のワークフローの多くはUTC前提なので、キーがなければUTCとして読みます。同じページには、最短間隔は5分であること、毎時0分のような混雑時には遅延し、負荷が高いとキューから落ちることもあること、公開リポジトリでは60日間アクティビティがないと予約実行が自動で無効になることも書かれています。7 * * * *のように分をずらすと混雑を避けやすくなります。
夏時間がある地域での注意
日本には夏時間がありませんが、米国や欧州のサーバーでは年2回問題になります。春に2時から3時へ飛ぶ日は2時30分が存在せず、秋に1時台が繰り返される日は同じ時刻が2回来ます。飛ばされた時刻のジョブを直後に1回実行するcronもあれば、単に飛ばすスケジューラーもあります。GitHub Actionsはtimezoneを指定した場合、飛ばされた時刻のジョブを次の有効な時刻(例:2:30→3:00)に移すと説明しています。
確実なのは、深夜1〜3時台を避けるか、サーバーをUTCにしてUTCで式を書くことです。
5フィールドと6・7フィールド:Quartz・Spring
Unix cronは分から始まる5フィールドです。Quartz(とそれに倣うSpringの@Scheduled)は先頭に秒が付く6フィールドで、末尾に年を任意で付けられるため最大7フィールドです。Quartzの「0 0 9 * * ?」はUnixの「0 9 * * *」と同じ意味になります。
Quartzでは日と曜日の両方に値を入れることはできず、どちらかに?を入れます。また曜日の数字は1=日曜〜7=土曜で、Unixの0=日曜とずれています。このツールが解釈するのは5フィールドだけですが、6・7フィールドを入れるとQuartz・Spring形式だと知らせ、意味がそのまま移せる場合は5フィールドに変換するボタンを表示します。秒が0でない、特定の年がある、L・W・#のようなQuartz独自の書き方がある場合は5フィールドで表せないので変換しません。6フィールドで曜日が数字の場合も、Quartz(1=日曜)かSpring(0=日曜、Unixと同じ)か判別できないため変換しません。MON-FRIのように名前で書くか、自分で先頭の秒を削り?を*にしてください。Quartzなら数字の曜日を1ずつ減らします。
ビルダーで式を作るとき
ビルダーは選んだ頻度に必要なフィールドだけを埋め、残りは*にします。間隔は*/Nで表されますが、これは「保存した時点からN分ごと」ではなく、フィールドの先頭(分なら0)からNおきの値の一覧です。*/7は0, 7, …, 56分に動き、次の時の0分との間は4分になります。60の約数(5, 10, 15, 20, 30)を使うと予想どおりに動きます。
既存のcrontabの行を式の欄に貼り付けると、ビルダーの状態に逆変換されるので、他人が書いた行の修正にも使えます。
例
日・曜日のOR規則
- 入力
0 9 1 * 1(基準:2026-09-22 火曜)- 結果
9/28(月)09:00、10/1(木)09:00、10/5(月)09:00、10/12(月)09:00、10/19(月)09:00
10月1日は木曜ですが実行されます。1日または月曜なら動くOR規則のためです。
GitHub Actionsで日本時間の朝9時
- 入力
cron: '0 0 * * 1-5'(timezone指定なし)- 結果
UTC 月〜金 00:00 = 日本時間 月〜金 09:00
UTCで書く必要があります。0 9 * * 1-5と書くと日本時間18時に動きます。
永遠に来ない日付
- 入力
0 0 30 2 *- 結果
次回実行なし
2月30日は存在しません。ツールは最大4年分を1分単位で探し、見つからなければ空の一覧を表示します。
Quartzの式を移す
- 入力
Quartz: 0 30 8 ? * MON-FRI- 結果
Unix: 30 8 * * 1-5
先頭の秒を削り、?を*に置き換えます。曜日を数字で書いている場合は1ずつ減らします。
使い方
- パーサータブにcron式を貼り付けるか、@dailyなどのマクロを入力します。
- 説明文と次回実行時刻(ブラウザのローカル時刻)を確認します。
- 新しく作るときはビルダータブで頻度と時刻を選び、生成された行をコピーします。
よくある質問
0 9 1 * 1が毎週月曜にも動くのはなぜ?
日と曜日を両方指定すると、POSIXの規則でどちらか一方に一致すれば実行されるOR条件になるためです。
GitHub Actionsの予約が9時間遅れて動きます。
scheduleのcronは既定でUTCです。日本時間から9時間引いて書くか、対応していればtimezone: "Asia/Tokyo"を指定します。
秒単位で実行できますか?
標準cronの最小単位は1分です。秒フィールドはQuartzやSpringの6フィールド形式にしかありません。
曜日に7を使えますか?
多くのUnix cronとこのツールは7を日曜として扱いますが、POSIXの範囲は0〜6なので移植性を考えるなら0が安全です。
出典
- POSIX crontab (The Open Group Base Specifications Issue 8)
- GitHub Docs – Events that trigger workflows: schedule
- Quartz Scheduler – CronTrigger Tutorial
基準日: