Cron式 計算ツール｜次回実行時刻と書式解説・AWS/GitHub Actions/K8s対応
Cron式から次回実行時刻と意味を即算出する無料電卓。「分 時 日 月 曜日」の5フィールド書式、AWS EventBridge/GitHub Actions/Kubernetes CronJob対応記法、UTC/JSTタイムゾーン運用、systemd timerとの使い分け、実務のハマりどころまで整理。POSIX crontab(5)・大手クラウドの公式ドキュメントに基づき、ジョブスケジューラ設計を支援します。
Cron式ツール
Cron式の5フィールド書式
基本書式
分 時 日 月 曜日 [コマンド]
CronはUnix系の定時実行スケジューラで、1975年のVersion 7 UNIX（AT&T Bell Labs）に起源を持ちます。5フィールドで実行タイミングを記述し、記法はPOSIX標準として広く受け入れられています。AWS Lambda（EventBridge Scheduler）、GitHub Actions、Kubernetes CronJob、GCP Cloud Scheduler、Azure Functionsなど、現代のクラウドスケジューラでも基本記法として採用されています。
各フィールドの範囲
| フィールド | 値の範囲 | 特殊記号 |
|---|---|---|
| 分（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 # |
秒フィールドの拡張
AWS EventBridge、Quartz Scheduler、Spring Framework等では先頭に「秒」フィールドを追加した6フィールド記法を採用しています。「秒 分 時 日 月 曜日」で1秒精度の実行が可能。GitHub ActionsやGCP Cloud Scheduler、Vixie 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分ごと）も可能。
? （クエスチョン）─ 未指定（Quartz系）
AWS EventBridge・Quartzで、日と曜日を両方指定しない場合に使う。「日と曜日は片方を?にする」のがEventBridge記法の必須ルール。0 12 * * ? * は「毎日12時に実行」（曜日は?で指定なし、末尾は年フィールド）。
L / W / # ─ 高度な指定（Quartz/EventBridge）
L=Last（月末・週末）：0 0 L * ?で月末実行。W=Weekday（最近の平日）：0 0 15W * ?で15日直近の平日。#=第n週：0 0 ? * MON#1で第1月曜日。伝統的なUnix cronでは使えないので注意。
プラットフォーム別書式差
Cron式は基本仕様が広く共通ですが、クラウドサービスや実装により細かな差異があります。ワークロード移植時は必ず対象プラットフォームの公式ドキュメントで確認してください。
| サービス | フィールド数 | タイムゾーン | 備考 |
|---|---|---|---|
| Unix cron (Vixie cron) | 5 | サーバTZ | 伝統的POSIX形式・オンプレLinux |
| systemd timer | 柔軟なOnCalendar記法 | 設定可能 | 秒精度・実行漏れ検知が可能 |
| Quartz Scheduler | 6-7 | 設定可能 | 秒・年フィールドあり・?/L/W/#対応 |
| AWS EventBridge Scheduler | 6（分・時・日・月・曜日・年） | 設定可能 | 日と曜日は片方?必須・rate式も選択可 |
| GitHub Actions | 5 | UTC固定 | on: schedule: - cron: 記法。TZ変更不可 |
| Kubernetes CronJob | 5 | spec.timeZone(1.27+) | ジョブテンプレート＋バックオフ制御 |
| GCP Cloud Scheduler | 5 | 設定可能 | App Engine cron.yaml形式も選択可 |
| Azure Functions timer trigger | 6 | WEBSITE_TIME_ZONE | NCronTab（Quartz派生）ベース |
| Spring @Scheduled | 6 | zone属性で指定 | 秒フィールドあり |
タイムゾーン運用（UTC vs JST）
ハマりどころNo.1: TZ設定
Cronジョブの「日本時間で動かない」問題の8割はタイムゾーン設定。オンプレLinuxのcrontabはサーバの/etc/localtimeに従うのに対し、クラウドはUTCデフォルトが多く、JSTの想定と9時間ずれます。例：0 9 * * *をUTC実行するとJST18時に発火します。
主要プラットフォームのTZデフォルト
- AWS EventBridge Scheduler：デフォルトUTC。
ScheduleExpressionTimezoneでAsia/Tokyoを明示指定可能 - GitHub Actions：UTC固定・変更不可（回避策：ジョブ内でTZ変換）
- Kubernetes CronJob：Kubernetes 1.27以降
spec.timeZone: "Asia/Tokyo"で明示指定可能。それ以前はNode(kubelet)のTZ - GCP Cloud Scheduler：
timeZoneフィールドで明示指定（デフォルトAmerica/Los_Angeles） - Azure Functions：環境変数
WEBSITE_TIME_ZONE=Tokyo Standard Timeで指定 - Cron on Docker/K8s：Dockerfileで
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チームの学習コストが低い。K8s CronJobやAWS EventBridgeもCron記法を採用しているのはこの互換性ゆえです。
使い分けの指針
単発の日次バッチ・簡単な定期タスクはCronで十分。複雑な依存関係、失敗リトライ、実行漏れ許容不可、監視必須ならsystemd timerかジョブオーケストレータ（Airflow・Digdag・Prefect・Dagster）を検討。分単位より短い間隔が必要な場合はCronは選ばず、systemd timer・Quartz・専用ジョブスケジューラを使います。
anacronの役割
Cronはサーバ停止中の実行をスキップしますが、anacronは次回起動時に「昨日の分」を実行する仕組み。ノートPCや常時稼働しないサーバでも日次バックアップが漏れない設計。RHEL/CentOS標準の/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 (Quartz) | 月末バッチ・請求処理 |
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は単発ジョブ・小規模運用には最適ですが、依存関係管理・失敗リトライ・実行漏れ検知が必要な用途では専用のジョブオーケストレータが有利です。
| ツール | 用途 | 特徴 |
|---|---|---|
| Cron (Vixie/paulcron) | 単発定時実行 | POSIX標準・軽量 |
| systemd timer | Linuxサーバ全般 | 秒精度・Persistent・journalctl統合 |
| Kubernetes CronJob | K8s上の定時ジョブ | concurrencyPolicy・backoffLimit |
| AWS EventBridge Scheduler | AWSリソース定期実行 | 1000万スケジュールまで対応 |
| Apache Airflow | 依存DAGパイプライン | Python DSL・Web UI・Backfill |
| Digdag | データパイプライン | YAMLで依存関係定義 |
| Prefect / Dagster | データパイプライン新世代 | Airflow代替・型安全 |
| Argo Workflows | K8sネイティブ | Container-native WF・CI/CDにも |
| Temporal / Cadence | ワークフロー基盤 | 長時間実行・状態管理 |
単純な定時実行はCron、複雑な依存管理はAirflow等、リアルタイム性は専用SaaSと使い分けるのが実務のベストプラクティスです。
よくある間違い・注意点
- タイムゾーン設定漏れ — クラウドサービスはUTCデフォルトが多く、日本時間で「9時に動かしたい」つもりが実際はJST18時に発火。
ScheduleExpressionTimezoneやspec.timeZoneで必ずTZを明示しましょう。 - 「日」と「曜日」の同時指定 — Vixie cronでは日と曜日を両方指定するとOR条件（どちらかが一致したら実行）になり、意図しない頻度で発火します。Quartz/EventBridgeでは片方を?にしないと構文エラーになります。
- 15分より短い間隔をCronで組む — Vixie cronの最小粒度は1分。GitHub Actionsは5分が最小推奨（それ以下はスキップ多発）。秒単位はQuartz/EventBridge/systemd timerを選ぶかloopスクリプトで対応します。
- 実行漏れの検知不備 — Cronは実行漏れを検知・通知しません。Dead man's switch（Healthchecks.io・Cronitor等）で「N分間ログが来ない=障害」検知が定石。GitHub Actionsは長期リポジトリ非活動で自動停止されるので、定期commitやDependabotで維持が必要です。
- 環境変数の未設定 — 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 ― Vixie cron/paulcron等のcrontabファイル書式の公式マニュアル。
- Quartz Cron Expression ― Java系スケジューラの拡張Cron記法。6-7フィールド・?/L/W/#対応。
参考文献・公式資料
Cron式・ジョブスケジューラ実装の詳細は、以下の公式ドキュメントを参照してください。
- crontab(5) - Linux manual page (man7.org) ― Vixie cron形式のcrontab書式の公式マニュアル。
- The Open Group Base Specifications - crontab ― POSIX crontab仕様（IEEE Std 1003.1）。
- AWS EventBridge Scheduler - Cron式リファレンス ― AWS独自拡張（6フィールド・?/L/W対応）の公式仕様。
- GitHub Actions - schedule イベント ― GitHub Actions cron記法の公式ドキュメント（UTC固定の説明含む）。
- Kubernetes Documentation - CronJob ― K8s CronJob APIとタイムゾーンサポート（v1.27+）の公式説明。
- Google Cloud Scheduler - Cron スケジュール ― GCP Cloud Schedulerの記法とTZ設定。
- Azure Functions - タイマー トリガー ― NCronTab記法とWEBSITE_TIME_ZONE設定。
- systemd.timer - freedesktop.org ― systemd timerのOnCalendar記法・Persistent動作の公式マニュアル。
- Quartz Scheduler - CronTrigger Tutorial ― Quartz独自の6-7フィールドCron記法チュートリアル。
- Crontab.guru ― Cron式を人間可読な文章に変換する定番Webツール（サードパーティ）。
よくある質問（FAQ）
日本時間で動く？
サーバのタイムゾーン設定次第です。多くのクラウドサービスはUTCがデフォルトで、JSTと9時間ずれます。AWS EventBridgeはScheduleExpressionTimezone、K8s CronJobはspec.timeZone、GCPはtimeZoneで明示指定を。GitHub ActionsはUTC固定・変更不可なので、時刻計算はUTC基準で組み立ててください。
15分より短い頻度で動かせる？
Vixie cronの最小粒度は1分で、それ以下はsystemd timer（秒指定可）、Quartz、AWS EventBridge（rate式：1 minute～）、専用ジョブスケジューラを使うか、1分毎cron内でループする実装で対応します。GitHub Actionsは5分間隔でも実行遅延・スキップが頻発するので用途を選びます。
GUI管理ツールは何がある？
crontab.guruがCron式の可読化・検証で最も普及。実行可視化はcron-view、WebhookモニタリングはHealthchecks.io・Cronitor・Better Uptimeが定番。ジョブ依存関係管理まで含めるとAirflow・Digdag・Prefect・Dagsterのジョブオーケストレータへの移行を検討します。
「日」と「曜日」を両方指定するとどうなる？
Vixie cronではOR条件（どちらか一致で実行）となり、意図しない発火頻度になります。例：0 0 15 * 5は「毎月15日 OR 毎週金曜」の0時。Quartz/AWS EventBridgeでは?を使って片方を無視する規約：0 0 15 * ?で「毎月15日のみ」を明示します。
実行漏れを検知する方法は？
Cronは実行漏れ通知機能を持ちません。Dead man's switch方式（Healthchecks.io・Cronitor.io・Sentry Crons）でジョブ末尾にpingを送り、「N分間pingが来ない=異常」と検知します。systemd timerならPersistent=trueで電源断による欠落を次回起動時に自動リカバリーできます。
Cronで環境変数が読めないのはなぜ？
Cronはログインシェルではないため、~/.bashrcや/etc/profileを読み込みません。PATH=・LANG=・TZ=等はcrontab先頭で明示するか、スクリプト内でsource ~/.bashrcを実行してください。「手動なら動く、cronだと動かない」の主因です。
CronのログはどこにEmit される？
デフォルトはローカルメール（/var/mail/{user}）にstdout/stderrが送られます。メールサーバ未設定の環境ではジョブ内で明示的にファイル出力（>> /var/log/xxx.log 2>&1）が必須。systemd timerならjournalctlに自動集約され、journalctl -u xxx.timerで参照可能です。
K8s CronJobで並列実行を防ぐには？
spec.concurrencyPolicy: Forbidで「前回のJobが実行中なら新規スキップ」に設定できます。Allow（デフォルト）・Replace（前回を止めて新規実行）と選べます。長時間ジョブではForbid必須、リアルタイム性優先ならReplaceを選択します。
DockerコンテナでCronを動かすのは？
可能ですがPID 1問題に注意。CronをPID 1で起動するとSIGTERMを受け取らずgraceful shutdown不可。対策はtini/dumb-initで親プロセス化するか、K8s CronJob等のオーケストレータに任せるのが定石。ENV TZ=Asia/Tokyoとtzdataパッケージのインストールも忘れずに。
@reboot や @yearly の予約語は？
Vixie cronの特殊予約語として @reboot（起動時1回）、@yearly（=0 0 1 1 *）、@monthly、@weekly、@daily、@hourly があり、可読性が高い書き方。ただしPOSIX非標準で、AWS EventBridge・GitHub Actionsなど非対応の実装もあります。
Cronでリトライを実装する方法は？
Cron自体はリトライ機能を持ちません。スクリプト内でwhile+sleepでリトライするか、K8s CronJobのbackoffLimit、AWS EventBridge SchedulerのRetryPolicyで対応します。恒久的な失敗を防ぐため、指数バックオフ＋Dead-letter queueの組合せが定石です。
2月29日や月末を安全に指定するには？
0 0 29 2 *は平年に発火しません。安全なのはQuartz/EventBridgeのL指定（0 0 L * ?で月末）。Vixie cronで月末を扱うには「毎日実行して、シェルスクリプト内で[ $(date +%d) = $(cal | tail -2 | head -1 | awk '{print $NF}') ]」等の条件分岐が必要です。
ケース別 Cron設計シナリオ
日次バックアップ（DB＋オブジェクトストレージ）
0 3 * * *で毎日3時に実行（ユーザーアクセスの少ない時間帯）。Dead man's switch連携でHealthchecks.ioに完了ping送信、24時間ping無しでアラート。バックアップ先はS3 Standard-IA → Glacier Deep Archiveへ90日でライフサイクル移行し月額$0.001/GB程度に圧縮。
週次レポート配信（Slack/メール）
0 9 * * 1で毎週月曜9時、営業日レポートをSlack Webhookへ投稿。祝日判定はスクリプト内で内閣府CSVを参照するか、Google Calendar APIで動的判定。月末最終営業日は0 17 25-31 * *+スクリプト内チェックで月末判定するのが定石。
SNS投稿予約（15分間隔ポーリング）
*/15 * * * *で15分ごとにDBの予約投稿をチェック→X/Bluesky APIへ投稿。処理時間短くAPI Rate Limit考慮でloopではなく都度cron方式。Race Condition対策で「processing」ステータス排他制御必須。冪等性を確保するとリトライ安全に。
ヘルスチェック（1分間隔ping）
* * * * *で毎分curlによる外形監視。3回連続失敗でPagerDuty通知。これがcron限界の粒度で、それより短い間隔はGrafana Cloud Synthetic Monitoring・Datadog Synthetics・UptimeRobot等の専用SaaSを利用します。1分間隔cron自体もタイムアウト60秒に注意。