Cron式 計算ツール｜次回実行時刻と5フィールド書式・プラットフォーム別の記法差
Cron式から次回実行時刻と意味を即算出する無料電卓。「分 時 日 月 曜日」の5フィールド書式、クラウドのイベントスケジューラ・CIサービス・コンテナ基盤で異なる記法、UTC/JSTタイムゾーン運用、systemd timerとの使い分け、実務のハマりどころまで整理。POSIX crontab(5)に基づき、ジョブスケジューラ設計を支援します。
Cron式 次回実行 計算機
Cron式の5フィールド書式
基本書式
分 時 日 月 曜日 [コマンド]
CronはUnix系の定時実行スケジューラで、1970年代のUNIXに起源を持ちます。5フィールドで実行タイミングを記述し、記法はPOSIX標準として広く受け入れられています。クラウドのイベントスケジューラ、CI/CDサービスの定期実行、コンテナ基盤のCronJob、サーバーレス関数のタイマートリガーなど、現代のクラウドスケジューラでも基本記法として採用されています。
各フィールドの範囲
| フィールド | 値の範囲 | 特殊記号 |
|---|---|---|
| 分（minute） | 0-59 | * / , - |
| 時（hour） | 0-23 | * / , - |
| 日（day of month） | 1-31 | * / , - ? L W |
| 月（month） | 1-12 または JAN-DEC | * / , - |
| 曜日（day of week） | 0-7 または SUN-SAT（0/7=日） | * / , - ? L # |
秒フィールドの拡張
クラウドのイベントスケジューラや、Java系フレームワークの拡張Cron記法では先頭に「秒」フィールドを追加した6フィールド記法を採用しています。「秒 分 時 日 月 曜日」で1秒精度の実行が可能。一方、CI/CDサービスのスケジュール実行やマネージドCronサービス、伝統的なUnix cronは5フィールドのみです。プラットフォーム間で移植する際は要注意です。
特殊記号（* / , - ? L W #）
* （アスタリスク）─ 任意の値
* * * * * は「毎分」（1分ごとに実行）。「* を1回でも書いたフィールド」は「そのフィールドは何でもOK」の意味。0 * * * * は「毎時0分に1回」（1時間ごと）。
/ （スラッシュ）─ 間隔指定
*/15 * * * * は「15分ごと」。「0分・15分・30分・45分」に実行。*/5 * * * * は5分ごと、0 */6 * * * は6時間ごと。開始値と間隔で表現でき、リアルタイム性の高い監視ジョブに便利。
, （カンマ）─ 複数指定
0 9,12,18 * * * は「毎日9時・12時・18時」の3回実行。営業時間内の複数タイミングで動かすジョブに使用。曜日フィールドでは 0 0 * * 1,3,5 で「月・水・金の0時」となる。
- （ハイフン）─ 範囲指定
0 9-17 * * 1-5 は「平日の9時〜17時の毎時0分」。営業時間中の定期処理・監視スクリプトの起動に頻用。範囲＋間隔の組合せ（0-30/5 * * * *で0-30分の5分ごと）も可能。
? （クエスチョン）─ 未指定（拡張記法）
拡張Cron記法を採用するクラウドのイベントスケジューラやJava系スケジューラで、日と曜日を両方指定しない場合に使います。「日と曜日は片方を?にする」のが拡張記法の必須ルール。0 12 * * ? * は「毎日12時に実行」（曜日は?で指定なし、末尾は年フィールド）。
L / W / # ─ 高度な指定（拡張記法）
L=Last（月末・週末）：0 0 L * ?で月末実行。W=Weekday（最近の平日）：0 0 15W * ?で15日直近の平日。#=第n週：0 0 ? * MON#1で第1月曜日。伝統的なUnix cronでは使えないので注意。
プラットフォーム別書式差
Cron式は基本仕様が広く共通ですが、クラウドサービスや実装により細かな差異があります。ワークロード移植時は必ず対象プラットフォームの公式ドキュメントで確認してください。
| 実装・サービスのタイプ | フィールド数 | タイムゾーン | 備考 |
|---|---|---|---|
| Unix cron（伝統的実装） | 5 | サーバTZ | POSIX形式・オンプレLinux |
| systemd timer | 柔軟なOnCalendar記法 | 設定可能 | 秒精度・実行漏れ検知が可能 |
| Java系スケジューラ（拡張記法） | 6-7 | 設定可能 | 秒・年フィールドあり・?/L/W/#対応 |
| クラウドのイベントスケジューラ | 6（分・時・日・月・曜日・年） | 設定可能 | 日と曜日は片方?必須・レート式も選択可 |
| CI/CDサービスのスケジュール実行 | 5 | UTC固定が多い | ワークフロー定義に記述。TZ変更不可が一般的 |
| コンテナ基盤のCronJob | 5 | タイムゾーン指定フィールド（新しめのバージョン） | ジョブテンプレート＋バックオフ制御 |
| クラウドのマネージドCronサービス | 5 | 設定可能 | YAML定義形式も選択可 |
| サーバーレス関数のタイマートリガー | 6 | 環境変数で指定 | 拡張記法ベース |
| アプリケーションフレームワークのスケジューラ | 6 | 属性で指定 | 秒フィールドあり |
タイムゾーン運用（UTC vs JST）
ハマりどころNo.1: TZ設定
Cronジョブの「日本時間で動かない」問題の8割はタイムゾーン設定。オンプレLinuxのcrontabはサーバの/etc/localtimeに従うのに対し、クラウドはUTCデフォルトが多く、JSTの想定と9時間ずれます。例：0 9 * * *をUTC実行するとJST18時に発火します。
プラットフォーム種別ごとのTZデフォルト
- クラウドのイベントスケジューラ：デフォルトUTC。タイムゾーン指定パラメータで
Asia/Tokyoを明示指定できます - CI/CDサービスのスケジュール実行：UTC固定・変更不可のものが多い（回避策：ジョブ内でTZ変換）
- コンテナ基盤のCronJob：新しめのバージョンでは
spec.timeZone: "Asia/Tokyo"で明示指定可能。それ以前はノード側のTZに従います - クラウドのマネージドCronサービス：
timeZoneフィールドで明示指定（デフォルトが米国時間の実装もあるので要確認） - サーバーレス関数のタイマートリガー：アプリ設定の環境変数でタイムゾーンを指定
- コンテナ内でcronを動かす場合：イメージのビルド時に
ENV TZ=Asia/Tokyoとtzdataのインストールが必須
サマータイム（DST）の落とし穴
UTCで運用すればDSTの影響を受けませんが、TZにAmerica/New_York等を指定すると、DST切替日（3月・11月）に実行がスキップされたり2回実行されたりすることがあります。日本国内はDST未採用のためAsia/Tokyo指定なら問題ありませんが、多国籍展開ではUTCベースで設計し、通知メッセージのみJST変換するのが定石です。
systemd timerとの比較
systemd timerの優位性
systemd timerはCronを置き換える現代的スケジューラ。OnCalendar記法（*-*-* 09:00:00で毎日9時）で秒精度指定可能。Persistent=trueで電源断時のスキップを次回起動時に自動リカバリー、OnBootSec/OnUnitActiveSecで「起動○分後」等の相対時刻指定も可能。ログはjournalctlに集約されトラブルシューティングが容易です。
Cronの優位性
Cronは設定ファイル1行で表現できる可搬性が最大の強み。POSIX標準として世界中のUnix系OSで通用します。既存のシェルスクリプト資産をそのまま活用でき、DevOpsチームの学習コストが低い。コンテナ基盤のCronJobやクラウドのイベントスケジューラもCron記法を採用しているのはこの互換性ゆえです。
使い分けの指針
単発の日次バッチ・簡単な定期タスクはCronで十分。複雑な依存関係、失敗リトライ、実行漏れ許容不可、監視必須ならsystemd timerかジョブオーケストレータを検討。分単位より短い間隔が必要な場合はCronは選ばず、systemd timerや拡張記法対応のスケジューラ、専用ジョブスケジューラを使います。
anacronの役割
Cronはサーバ停止中の実行をスキップしますが、anacronは次回起動時に「昨日の分」を実行する仕組み。ノートPCや常時稼働しないサーバでも日次バックアップが漏れない設計。多くのLinuxディストリビューションで/etc/anacrontabにより管理されます。systemdのPersistent機能と同等の思想です。
よく使うCron式パターン集
| Cron式 | 意味 | 用途例 |
|---|---|---|
0 0 * * * | 毎日 0:00 | 日次バックアップ |
0 3 * * * | 毎日 3:00 | ログローテート・DBメンテナンス |
0 9 * * 1-5 | 平日 9:00 | 営業日レポート送信 |
0 * * * * | 毎時 0分 | キャッシュクリア |
*/5 * * * * | 5分ごと | ヘルスチェック |
*/15 * * * * | 15分ごと | SNS投稿予約・監視ポーリング |
0 9,12,18 * * * | 毎日 9/12/18時 | 営業時間の定期通知 |
0 0 1 * * | 毎月1日 0:00 | 月次締め処理 |
0 0 * * 0 | 毎週日曜 0:00 | 週次サマリー生成 |
30 2 * * 6 | 毎週土曜 2:30 | フルバックアップ |
0 0 1 1 * | 毎年 1/1 0:00 | 年次リセット |
0 0 L * ? | 月末 0:00（拡張記法） | 月末バッチ・請求処理 |
Cronトラブルシュートと運用Tips
「手動なら動くのにcronで動かない」問題
最頻の原因は環境変数の欠落。cronはログインシェルではないためPATHやLANGが最小限。crontab -eの先頭でSHELL=/bin/bash、PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binを明示するか、スクリプト内でsource ~/.bashrcを実行してください。
ログ出力先の設定
* * * * * /path/to/script.sh >> /var/log/xxx.log 2>&1の形でstdout+stderrをファイルに追記。logrotate設定で日次ローテート＋圧縮＋古いログ削除を設定。systemd使用環境ならsystemd-cat経由でjournalへ送るのも良い選択。
実行状況の確認
grep CRON /var/log/syslog（Debian系）または journalctl -u cron.service --since=todayでcronデーモンの実行ログを確認。実行が記録されていない=cron書式エラー、実行はされたが失敗=スクリプト内エラー、と切り分けができます。
タイムアウト対策
長時間ジョブはtimeout 300 /path/to/script.shのようにtimeoutコマンドでハードリミットを設定。無限ループやハングによる次回実行との重複を防止。lock機構（flock）と組み合わせるとより堅牢になります：flock -n /tmp/xxx.lock -c "/path/to/script.sh"。
Cron代替スケジューラの選択肢
Cronは単発ジョブ・小規模運用には最適ですが、依存関係管理・失敗リトライ・実行漏れ検知が必要な用途では専用のジョブオーケストレータが有利です。
| ツールのタイプ | 用途 | 特徴 |
|---|---|---|
| Unix cron | 単発定時実行 | POSIX標準・軽量 |
| systemd timer | Linuxサーバ全般 | 秒精度・Persistent・journalctl統合 |
| コンテナ基盤のCronJob | コンテナ基盤上の定時ジョブ | 並行実行ポリシー・バックオフ制御 |
| クラウドのイベントスケジューラ | クラウドリソースの定期実行 | 数百万〜1000万スケジュール規模に対応 |
| DAG型ワークフローエンジン（OSS） | 依存関係のあるパイプライン | コードでDAG定義・Web UI・バックフィル |
| 宣言的データパイプラインツール | データパイプライン | YAMLで依存関係定義 |
| 新世代のデータオーケストレータ | データパイプライン | 型安全・アセット指向 |
| コンテナネイティブのワークフローエンジン | コンテナ基盤ネイティブ | コンテナ単位のワークフロー・CI/CDにも |
| 長時間ワークフロー基盤 | ワークフロー基盤 | 長時間実行・状態管理 |
単純な定時実行はCron、複雑な依存管理はDAG型ワークフローエンジン、リアルタイム性は専用SaaSと使い分けるのが実務のベストプラクティスです。
よくある間違い・注意点
- タイムゾーン設定漏れ — クラウドサービスはUTCデフォルトが多く、日本時間で「9時に動かしたい」つもりが実際はJST18時に発火。タイムゾーン指定パラメータや
spec.timeZoneで必ずTZを明示しましょう。 - 「日」と「曜日」の同時指定 — 伝統的なUnix cronでは日と曜日を両方指定するとOR条件（どちらかが一致したら実行）になり、意図しない頻度で発火します。拡張記法では片方を?にしないと構文エラーになります。
- 15分より短い間隔をCronで組む — Unix cronの最小粒度は1分。CI/CDサービスのスケジュール実行は5分が最小推奨（それ以下はスキップ多発）。秒単位は拡張記法対応のスケジューラやsystemd timerを選ぶかloopスクリプトで対応します。
- 実行漏れの検知不備 — Cronは実行漏れを検知・通知しません。Dead man's switch型の死活監視サービスで「N分間ログが来ない=障害」を検知するのが定石。CI/CDサービスのスケジュール実行はリポジトリが長期間非活動だと自動停止されることがあるので、定期的な更新で維持が必要です。
- 環境変数の未設定 — Cronはログインシェルではなく、ユーザーの
.bashrcやPATHを継承しません。スクリプト冒頭でフルパスやsource ~/.bashrcを明示しないと「手動なら動くのにcronだと動かない」トラブルの主因になります。 - ログを見捨てる — Cronの標準出力はデフォルトでメール送信されます（
MAILTO）。メールサーバ未設定の環境では出力が消えるため、>> /var/log/xxx.log 2>&1でファイル出力するか、systemd timerでjournalctl集約を推奨。
関連する規格・ドキュメント
- POSIX (IEEE Std 1003.1) crontab ― Unix系OSにおけるcrontabコマンドの標準仕様。分・時・日・月・曜日の5フィールドを規定。
- RFC 5545 iCalendar RRULE ― カレンダー系スケジューラのRRULE仕様。反復規則の代替表現として使用。
- ISO 8601 ― 日時表現の国際規格。Cron代替のsystemd timerではISO 8601風の記法を採用。
- tz database (IANA Time Zone Database) ―
Asia/Tokyo等のタイムゾーン識別子の管理団体。 - crontab(5) manual page ― crontabファイル書式の公式マニュアル。
- 拡張Cron記法（6-7フィールド） ― Java系スケジューラを起源とし、多くのクラウドサービスが採用する拡張記法。秒・年フィールドと ?/L/W/# に対応。
参考文献・公式資料
Cron式・ジョブスケジューラ実装の詳細は、以下の公式ドキュメントを参照してください。
- crontab(5) - Linux manual page ― crontab書式の公式マニュアル。
- The Open Group Base Specifications - crontab ― POSIX crontab仕様（IEEE Std 1003.1）。
- systemd.timer マニュアル ― systemd timerのOnCalendar記法・Persistent動作の公式マニュアル。
- IANA Time Zone Database ―
Asia/Tokyo等のタイムゾーン識別子とDST規則の一次情報。 - IETF RFC 5545 (iCalendar) ― 反復規則（RRULE）の標準仕様。
- 各クラウドのスケジューラ公式ドキュメント ― フィールド数、?の必須ルール、レート式の有無、タイムゾーン指定方法が書かれた一次情報。移植前に必ず確認します。
- CI/CDサービスのスケジュールイベント仕様 ― UTC固定かどうか、最小間隔、遅延・スキップの挙動が明記されています。
- コンテナ基盤のCronJob API仕様 ― タイムゾーン指定の対応バージョン、並行実行ポリシー、バックオフ回数の既定値。
よくある質問（FAQ）
日本時間で動く？
サーバのタイムゾーン設定次第です。多くのクラウドサービスはUTCがデフォルトで、JSTと9時間ずれます。クラウドのイベントスケジューラはタイムゾーン指定パラメータ、コンテナ基盤のCronJobはspec.timeZone、マネージドCronサービスはtimeZoneで明示指定を。CI/CDサービスのスケジュール実行はUTC固定・変更不可のものが多いので、時刻計算はUTC基準で組み立ててください。
15分より短い頻度で動かせる？
Unix cronの最小粒度は1分で、それ以下はsystemd timer（秒指定可）、拡張記法対応のスケジューラ、クラウドのレート式（1分〜）、専用ジョブスケジューラを使うか、1分毎cron内でループする実装で対応します。CI/CDサービスのスケジュール実行は5分間隔でも実行遅延・スキップが頻発するので用途を選びます。
GUI管理ツールは何がある？
Cron式を人間可読な文章に変換するWebツールが可読化・検証で普及しています。実行可視化はcron閲覧系のOSSツール、Webhookによる死活監視はDead man's switch型の監視SaaSが定番。ジョブ依存関係管理まで含めるとDAG型ワークフローエンジンやデータオーケストレータへの移行を検討します。
「日」と「曜日」を両方指定するとどうなる？
伝統的なUnix cronではOR条件（どちらか一致で実行）となり、意図しない発火頻度になります。例：0 0 15 * 5は「毎月15日 OR 毎週金曜」の0時。拡張記法では?を使って片方を無視する規約：0 0 15 * ?で「毎月15日のみ」を明示します。
実行漏れを検知する方法は？
Cronは実行漏れ通知機能を持ちません。Dead man's switch方式（死活監視SaaSやエラー監視サービスの定期実行監視機能）でジョブ末尾にpingを送り、「N分間pingが来ない=異常」と検知します。systemd timerならPersistent=trueで電源断による欠落を次回起動時に自動リカバリーできます。
Cronで環境変数が読めないのはなぜ？
Cronはログインシェルではないため、~/.bashrcや/etc/profileを読み込みません。PATH=・LANG=・TZ=等はcrontab先頭で明示するか、スクリプト内でsource ~/.bashrcを実行してください。「手動なら動く、cronだと動かない」の主因です。
Cronのログはどこに出力される？
デフォルトはローカルメール（/var/mail/{user}）にstdout/stderrが送られます。メールサーバ未設定の環境ではジョブ内で明示的にファイル出力（>> /var/log/xxx.log 2>&1）が必須。systemd timerならjournalctlに自動集約され、journalctl -u xxx.timerで参照可能です。
コンテナ基盤のCronJobで並列実行を防ぐには？
spec.concurrencyPolicy: Forbidで「前回のJobが実行中なら新規スキップ」に設定できます。Allow（デフォルト）・Replace（前回を止めて新規実行）と選べます。長時間ジョブではForbid必須、リアルタイム性優先ならReplaceを選択します。
コンテナ内でCronを動かすのは？
可能ですがPID 1問題に注意。CronをPID 1で起動するとSIGTERMを受け取らずgraceful shutdown不可。対策は軽量initプロセスで親プロセス化するか、コンテナ基盤のCronJob等のオーケストレータに任せるのが定石。ENV TZ=Asia/Tokyoとtzdataパッケージのインストールも忘れずに。
@reboot や @yearly の予約語は？
Unix cronの特殊予約語として @reboot（起動時1回）、@yearly（=0 0 1 1 *）、@monthly、@weekly、@daily、@hourly があり、可読性が高い書き方。ただしPOSIX非標準で、クラウドのイベントスケジューラやCI/CDサービスなど非対応の実装もあります。
Cronでリトライを実装する方法は？
Cron自体はリトライ機能を持ちません。スクリプト内でwhile+sleepでリトライするか、コンテナ基盤のCronJobのbackoffLimit、クラウドのイベントスケジューラのリトライポリシーで対応します。恒久的な失敗を防ぐため、指数バックオフ＋デッドレターキューの組合せが定石です。
2月29日や月末を安全に指定するには？
0 0 29 2 *は平年に発火しません。安全なのは拡張記法のL指定（0 0 L * ?で月末）。Unix cronで月末を扱うには「毎日実行して、シェルスクリプト内で翌日が1日かどうかを判定する」等の条件分岐が必要です。
ケース別 Cron設計シナリオ
日次バックアップ（DB＋オブジェクトストレージ）
0 3 * * *で毎日3時に実行（ユーザーアクセスの少ない時間帯）。Dead man's switch連携で死活監視サービスへ完了pingを送信し、24時間ping無しでアラート。バックアップ先は低頻度アクセス階層 → アーカイブ階層へ90日でライフサイクル移行し、月額$0.001/GB程度まで圧縮できます。
週次レポート配信（チャット/メール）
0 9 * * 1で毎週月曜9時、営業日レポートをチャットツールのWebhookへ投稿。祝日判定はスクリプト内で内閣府が公開する祝日CSVを参照するか、カレンダーAPIで動的判定。月末最終営業日は0 17 25-31 * *+スクリプト内チェックで月末判定するのが定石。
SNS投稿予約（15分間隔ポーリング）
*/15 * * * *で15分ごとにDBの予約投稿をチェックし、SNSのAPIへ投稿。処理時間が短くAPIのレート制限も考慮して、loopではなく都度cron方式。競合状態への対策で「processing」ステータスによる排他制御は必須。冪等性を確保するとリトライが安全になります。
ヘルスチェック（1分間隔ping）
* * * * *で毎分curlによる外形監視。3回連続失敗でインシデント管理ツールへ通知。これがcron限界の粒度で、それより短い間隔は外形監視の専用SaaSを利用します。1分間隔cron自体もタイムアウト60秒に注意。