Cron式パーサー
Cron 式を平易な言葉で解析・説明。次回の実行時刻を表示。プリセット例も収録。無料のオンライン cron ツール。
主な機能
- 人間が読める cron の説明
- 次回5回分の実行時刻プレビュー
- 一般的なプリセット式
- フィールドのビジュアルな内訳
Guide
Cron は Unix 系オペレーティングシステムで、特定の間隔でコマンドやスクリプトを実行するために使われる時間ベースのジョブスケジューリングシステムです。Cron 式は、分、時、日、月、曜日の5つのフィールドを使ってスケジュールを定義するコンパクトな文字列です。計算機で最も広く使われるスケジューリング形式のひとつであるにもかかわらず、Cron 式は一目で読むのが難しいことで有名です。本ガイドでは、構文の詳細、式の読み書き、一般的なパターン、実用的なユースケースを取り上げます。 標準 Cron 式の5つのフィールドは左から右へ：分（0〜59）、時（0〜23）、日（1〜31）、月（1〜12）、曜日（0〜7、0 と7はともに日曜日）。各フィールドは特定の値、範囲、リスト、特殊文字を受け付けます。30 14 * * 1-5 のような完全な式は、月曜から金曜の毎日14:30（午後2:30）を意味します。WebRecast の cron パーサーはこれらの式を平易な言葉に翻訳し、次回の実行時刻を示します。 アスタリスク（*）はすべての可能な値を意味するワイルドカードです。分フィールドの * は毎分を意味します。月フィールドの * は毎月を意味します。5つのフィールドすべてがアスタリスク（* * * * *）のとき、ジョブは毎日毎時毎分実行されます。これは最も単純な Cron 式であり、同時に本番環境でその頻度で実行するつもりがない場合は最も危険なもののひとつでもあります。 スラッシュ（/）はステップ値を指定します。分フィールドの */5 は5分ごと（0、5、10、15、20、25、30、35、40、45、50、55）を意味します。時フィールドの */2 は2時間ごと（0、2、4、6、8、10、12、14、16、18、20、22）を意味します。ステップは範囲と組み合わせられます：分フィールドの 1-30/5 は前半の30分間で5分ごと（1、6、11、16、21、26）を意味します。ステップによりすべての値を列挙せずに規則的な間隔を簡単に作れます。 カンマ（,）は特定の値のリストを作ります。日フィールドの 1,15 は毎月1日と15日を意味します。分フィールドの 0,30 は毎正時と30分過ぎを意味します。曜日フィールドの MON,WED,FRI（Cron 実装が名前をサポートする場合）は月曜、水曜、金曜を意味します。スケジュールが規則的な間隔に従わない場合にリストは有用です。 ハイフン（-）は範囲を定義します。時フィールドの 9-17 は午前9時から午後5時までの毎時を意味します。曜日フィールドの 1-5 は月曜から金曜を意味します。範囲は両端を含みます。範囲はステップと組み合わせられます：0-23/2 は1日を通して1時間おき、曜日フィールドの 1-5 に分フィールドの */10 を組み合わせれば平日は10分ごとを意味します。 一部の Cron 実装は追加の文字をサポートします。疑問符（?）は一部のシステム（Quartz スケジューラなど）で、日または曜日のいずれかを指定して他方を指定しない場合に、具体的な値がないことを示すために使われます。L 文字は最後を意味し、日フィールドの L は月の最終日を意味します。W 文字は最も近い平日を意味し、15W は15日に最も近い平日を意味します。ハッシュ（#）は曜日の n 番目の出現を指定し、2#3 は月の第3火曜を意味します。標準 Unix cron はこれらをサポートしませんが、Java ベースのスケジューラやクラウドプラットフォームの Cron サービスに現れます。 一般的な Cron パターンがほとんどのスケジューリングニーズをカバーします。毎分実行：* * * * *。5分ごと：*/5 * * * *。毎正時：0 * * * *。毎日深夜：0 0 * * *。毎日午前3:30：30 3 * * *。毎週日曜深夜：0 0 * * 0。毎月1日深夜：0 0 1 * *。平日午前9時：0 9 * * 1-5。平日の営業時間中に15分ごと：*/15 9-17 * * 1-5。cron パーサーツールはこれらの一般的なプリセットをクイックリファレンスとして収録しています。 タイムゾーンの扱いは、Cron 式自体が扱わない重要な考慮事項です。Cron 式は時刻を指定しますが、どのタイムゾーンでしょうか。ローカルサーバーでは、cron は通常サーバーのシステムタイムゾーンで実行されます。クラウドプラットフォーム（AWS CloudWatch、Google Cloud Scheduler、Azure Logic Apps）はタイムゾーンを明示的に指定できます。グローバルな利用者にサービスを提供するジョブやクラウドインフラで動かすジョブをスケジュールする場合、常に Cron 式が参照するタイムゾーンを確認し文書化しましょう。0 9 * * * のジョブはサーバーのタイムゾーンで9時を意味し、それは UTC、ローカル時刻、あるいはまったく別のものかもしれません。 夏時間は Cron スケジュールにエッジケースを作ります。時計が進むとき、午前2:00から3:00の時間は存在しません。春の移行時の午前2:30にスケジュールされたジョブは、Cron 実装によりスキップされるか午前3:00に実行される可能性があります。時計が戻るとき、午前1:00から2:00の時間は2回起こります。この期間にスケジュールされたジョブは実装により2回または1回実行されるかもしれません。UTC を使えば DST の問題を完全に回避できるため、多くの本番システムが UTC を標準としています。 重複実行は、ジョブの完了にスケジュール間隔より長くかかる場合に起こります。ジョブが5分ごとにスケジュールされているが時に8分かかる場合、次の実行は前の実行が終わる前に始まります。これはリソース競合、データ破損、重複処理を引き起こす可能性があります。Cron システム自体は重複実行を防ぎません。解決策にはロックファイル（ジョブ開始時にロックファイルを探し、存在すれば終了する）、flock（ファイルロックユーティリティ）の使用、組み込みの同時実行制御を持つジョブスケジューラの使用があります。 Cron ジョブのロギングと監視は本番の信頼性に不可欠です。暗黙に失敗する Cron ジョブは、一度も実行されなかったジョブより悪いです。cron コマンドに >> /var/log/myjob.log 2>&1 を追加して、ジョブ出力をログファイルに向けましょう。これで標準出力とエラーの両方を捕捉します。ジョブが失敗したり予定通りに実行されなかったりしたときに警告する監視を設定しましょう。Healthchecks.io や Cronitor のようなサービスはデッドマンスイッチ監視を提供し、Cron ジョブが完了時に URL に ping を送り、ping が時間内に届かなければ警告します。 対話型シェルと cron 環境の違いが多くの Cron ジョブ失敗を引き起こします。cron がジョブを実行するとき、対話型セッションが持つ PATH エントリ、環境変数、シェル設定を欠く最小の環境を使います。手動で実行すると動くのに cron では失敗する場合、原因は環境変数の欠落か、cron の PATH にない実行ファイルである可能性が高いです。解決策には、すべての実行ファイルに絶対パスを使う（python3 ではなく /usr/bin/python3）、crontab の先頭で環境変数を明示的に設定する、ジョブスクリプトの先頭でシェルプロファイルを source する、などがあります。 crontab コマンドが cron スケジュールを管理します。crontab -e は crontab ファイルをエディタで開きます。crontab -l は現在の crontab エントリを一覧表示します。crontab -r は crontab 全体を削除します（注意して使用）。crontab ファイルの各行は、コメント（# で始まる）、環境変数の代入（MAILTO=admin@example.com）、またはスケジュールエントリ（5つの時間フィールドの後に実行コマンド）のいずれかです。MAILTO 変数はジョブ出力をメールアドレスに送り、小規模環境では有用な監視機構になります。 システム全体の cron は /etc/cron.d/、/etc/cron.daily/、/etc/cron.hourly/、/etc/cron.weekly/、/etc/cron.monthly/ 内のファイルで管理されます。これらのディレクトリはやや異なる形式を使い、スケジュールとコマンドの間にユーザー名フィールドを含み、どのユーザーアカウントがジョブを実行するかを指定します。システムパッケージやサーバー管理スクリプトは通常、個別のユーザー crontab ではなくこれらの場所を使います。 cron の現代的な代替には Linux システムの systemd タイマーがあり、ランダム遅延、依存関係管理、より良いログ統合といった機能を提供します。クラウドプラットフォームは独自のスケジューリングサービスを提供します：AWS EventBridge（旧 CloudWatch Events）、Google Cloud Scheduler、Azure Logic Apps、Kubernetes CronJobs。これらのサービスは Cron 式の構文を使いますが、再試行ポリシー、デッドレター キュー、監視ダッシュボードなどの機能を追加します。これら現代的なツールはすべて同じ5フィールド形式を使うため、Cron 式の構文を理解することは依然不可欠です。 Kubernetes CronJobs は Cron スケジューリングとコンテナオーケストレーションを組み合わせるため特筆に値します。Kubernetes CronJob はスケジュールに従って新しい Pod を作成し、コンテナ内でジョブを実行し、完了時にクリーンアップします。schedule フィールドは標準の Cron 構文を使います。追加の設定が同時実行ポリシー（Allow、Forbid、Replace）、成功・失敗したジョブ履歴の限度、開始デッドライン秒数、suspend 機能を制御します。Kubernetes でワークロードを動かす場合、定期タスクのスケジュールには CronJobs が標準的な方法です。 WebRecast の cron パーサーは入力された式に対して3つのものを出力します：スケジュールの人間が読める説明（平日は15分ごと、のような平易な言葉）、各フィールドがどの値に一致するかを示す内訳、現在の日時に基づく次回5回分の実行時刻。これにより本番環境にデプロイする前に式が意図通り動くかを簡単に確認できます。式を入力し、説明を読み、次回の実行時刻を確認し、スケジュールが要件に合うか確かめましょう。 デプロイ前に Cron 式をテストすれば、現実的な帰結をもたらしうるスケジューリングの誤りを防げます。毎日実行すべきバックアップジョブが毎時実行されればディスク容量を無駄にします。毎月実行すべき請求ジョブが毎日実行されれば顧客に超過請求します。毎時実行すべきクリーンアップジョブが毎分実行されれば不要なサーバー負荷を生みます。crontab やクラウドスケジューラの設定に追加する前に、必ずこのようなツールで Cron 式を解析・検証しましょう。数秒の検証が、何時間ものデバッグやそれ以上の事態を防ぎます。
よくある質問
Cron 式とは何ですか？
分・時・日・月・曜日の5フィールドからなり、定期タスクのスケジュールを定義する文字列です。
Cron で */5 は何を意味しますか？
*/5 は「5間隔ごと」を意味します。例えば分フィールドの */5 は5分ごとを表します。
