Cron式ジェネレーター＆翻訳ツール — Cronスケジュールの作成と解読

cron式とは、Unix cron、crontab、CI/CDパイプラインなどのスケジューラーに対して、ジョブをいつ実行するかを正確に伝える5フィールドの文字列（分、時、日、月、曜日）です。例えば `*/15 9-17 * * MON-FRI` は「月曜から金曜、午前9時から午後5時の間、15分ごと」を意味します。このツールは双方向に使えます。シンプルなドロップダウンでスケジュールを作成してcron文字列を取得することも、既存のcron式を貼り付けて平易な言葉での説明と実際の次の5回の実行時刻を即座に確認することもできます。Unix、Linuxのcrontab、そしてほとんどのジョブスケジューラーで使われる標準的な5フィールドのPOSIX/Vixie cron構文に準拠しています。正式な仕様についてはcrontab(5)のmanページをご覧ください。すべての処理はブラウザ内でローカルに完結し、入力した内容がどこかにアップロードされることはありません。

このツールとは？

cron式とは、`分時日月曜日` という5フィールドからなるコンパクトなスケジュール文字列で、Unixの`cron`デーモンと、それをモデルにしたほぼすべてのジョブスケジューラー（crontab、Kubernetes CronJob、GitHub Actionsの`schedule:`、Airflow、Jenkinsなど）で使われています。各フィールドには、アスタリスク（`*`、「任意の値」を意味する）、特定の数値、カンマ区切りのリスト（`1,15,30`）、範囲（`9-17`）、ステップ（`*/15`、「15単位ごと」を意味する）、または月と曜日については数値の代わりに3文字の名前（`JAN`、`MON`）を指定できます。

この構文の正式な定義はLinuxのcrontab(5) manページにあり、まったく同じ5つのフィールド、特殊文字（`* , - /`）、そしてVixie cron（ほとんどのLinuxディストリビューションに標準搭載されているバージョン）を含む多くのcron実装がよく使われるスケジュールのエイリアスとしてサポートする8つの`@`省略記法（`@reboot`、`@yearly`/`@annually`、`@monthly`、`@weekly`、`@daily`/`@midnight`、`@hourly`）が文書化されています。

このツールはまさにその標準的な5フィールド形式を実装しています。これはLinuxやmacOSサーバーで`crontab -e`に直接入力する形式、あるいはKubernetes CronJobの`schedule:`フィールドに入力する形式です。JavaのQuartz Schedulerや一部のベンダーツールで使われる、異なる6〜7フィールド形式であるQuartz cron構文には対応していません（どちらが必要かについては下の比較セクションを参照してください）。

なぜこれを使うのか？

退職したメンバーが残したcrontabの設定ファイルを引き継いで、`0 3 1,15 * *`のような式が実際いつ動くのか本番環境をいじる前に確認したいとき。
GitHub ActionsのワークフローYAMLに`schedule:`を追加する際、フィールドの順番を間違えて意図しない時間にジョブが走ってしまうミスを事前に防ぎたいとき。
Kubernetes CronJobのマニフェストを書いていて、深夜バッチが日本時間で本当に想定通りの時刻に実行されるか、次の実行時刻のプレビューで確認してからデプロイしたいとき。
「毎月8日と毎週月曜の両方で動いてしまう」というcron特有のOR挙動にハマった経験があり、日と曜日を両方指定する式を作る前に必ず次回実行時刻で検証する習慣をつけたいとき。
「平日の9時から17時まで15分おき」というシンプルな要件を、フィールドのカンマやスラッシュを打ち間違えることなく、ドロップダウン操作だけで正確な式に変換したいとき。
社内システムのバッチスケジュール設定は機密性が高いため、外部サーバーに送信せずブラウザ内だけで完結するツールを使いたいとき。

使い方

式を翻訳するには、入力フィールドに5フィールドのcron文字列（または`@daily`のような@省略記法）を入力または貼り付けます。
その下に表示される平易な言葉での説明と、計算された次の5回の実行時刻を確認してください。どちらも入力に合わせてリアルタイムで更新されます。
スケジュールを作成するには、代わりにビルダーセクションを開き、5つの各フィールドについてモード（every / every N / 特定の値）を選択し、「式を生成」をクリックします。
生成された式は上部の入力フィールドに反映され、すぐに説明パネルと次の実行時刻パネルに反映されます。
ページ下部の構文一覧を`*`、`,`、`-`、`/`のクイックリファレンスとして活用してください。
コピーボタンで最終的な式をコピーし、crontabやCI設定、スケジューラーに貼り付けてください。

例

入力

*/15 9-17 * * MON-FRI

出力

09:00、09:15、09:30、09:45、10:00 ... 17:45に、月曜日、火曜日、水曜日、木曜日、金曜日

この式は15分ごとに実行されますが、09:00〜17:59の時間帯のみ、かつ平日のみに限定されます。典型的な「業務時間内」のポーリングスケジュールです。

標準cron vs Quartz cron

「cron構文」は単一の普遍的な標準ではありません。よく遭遇する2つの形式は、フィールド数といくつかの特殊文字の意味が異なります。この表を使って、対象のスケジューラーに正しい形式を使用しているか確認してください。

項目	標準cron（このツール）	Quartz cron
フィールド数	5（分時日月曜日）	6または7（秒、および任意の年が追加）
使用箇所	Linux/macOSのcrontab、Kubernetes CronJob、GitHub Actions	Javaの Quartz Scheduler、一部のエンタープライズスケジューラー
日と曜日の両方を設定した場合	どちらか一方に一致（和集合/OR）	2つのフィールドのどちらかに`?`が必須 — 両方に同時に値を設定できない
追加の特殊文字	`* , - /`以外なし	`?`、`L`（最終日）、`W`（直近の平日）、`#`（その月のn番目の曜日）を追加
秒単位のスケジューリング	非対応	対応（先頭フィールド）

本番環境でよくあるcronのハマりどころ

cron式そのものは正しくても、実際に本番で動かすと想定と違うタイミングで実行されるトラブルは珍しくありません。特に日本のチームが海外のクラウド基盤やDockerコンテナを使う場合、サーバーのタイムゾーンがUTCのままになっていることに気づかず、深夜バッチのつもりが日中に実行されてしまう、という事故がよく起こります。式を生成・検証する段階で「次の実行時刻」を必ず確認し、想定した日本時間と一致しているかをチェックする習慣が重要です。

サーバーやDockerコンテナのタイムゾーンがUTCになっていないか、デプロイ前に`date`コマンドなどで確認する。
GitHub ActionsやGitLab CIのスケジュール機能は基本的にUTC評価なので、日本時間からの変換を必ず行う。
日フィールドと曜日フィールドを両方指定すると『OR』評価になる仕様を忘れずに、意図せず余分な日に実行されていないか次回実行時刻で確認する。
夏時間を採用する地域のサーバーを使う場合、年2回スケジュールがずれる可能性があるため、UTC基準で設計しアプリ側で変換するのが安全。

よくある質問

cron式とは何ですか？

cron式とは、Unixの`cron`デーモンや互換スケジューラー向けに繰り返しスケジュールを指定する5フィールドのテキスト文字列（`分時日月曜日`）です。各フィールドには`*`（任意の値）、数値、カンマ区切りのリスト、範囲（`a-b`）、ステップ（`*/n`）を指定でき、月と曜日のフィールドには`JAN`や`MON`のような3文字の名前も使えます。完全な仕様はcrontab(5) manページに記載されています。

日と曜日の両方が制限されている場合はどうなりますか？

これはcronのよく知られた落とし穴です。POSIX cronの仕様では、日フィールドと曜日フィールドの両方が制限されている（`*`でない）場合、どちらか一方の条件を満たせばジョブが実行されます。つまりAND（積）ではなくOR（和）です。例えば`0 4 8 * MON`は、毎月8日の午前4時と、毎週月曜日の午前4時の両方で実行されます。8日がたまたま月曜日である場合だけ実行されるわけではありません。このツールは次の実行時刻を計算する際、まさにこのOR（和集合）の動作を実装しています。

標準cronとQuartz cron — どちらが必要ですか？

このツールはLinux/macOSの`crontab`、Kubernetes CronJob、GitHub Actionsの`schedule:`、そしてほとんどのUnix系ジョブランナーで使われる、標準的な5フィールドのPOSIX/Vixie cron構文を生成します。JavaのQuartz Schedulerやそれを基盤にしたツール（一部のエンタープライズスケジューラー、古いSpring Batchの設定）で使われるQuartz cronは、先頭に秒フィールドを追加し、一部の特殊文字の意味を変更した異なる6〜7フィールド形式です（日フィールドで「特定の値なし」を意味する`?`、「最終日」「直近の平日」「その月のn番目の曜日」を意味する`L`/`W`/`#`など）。使用するスケジューラーのフィールド数が6または7であったり、ドキュメントに`?`、`L`、`W`、`#`が記載されていたりする場合は、Quartz専用のツールが必要です。このジェネレーターで生成した式は正しく解釈されません。フィールド数がちょうど5つ（または`@daily`のような省略記法）であれば、このツールで問題ありません。

@yearly、@monthly、@weekly、@daily、@hourlyというショートカットは何を意味しますか？

これらは標準ではありませんが広くサポートされている省略記法で、一般的な5フィールド式に展開されます。`@yearly`/`@annually` = `0 0 1 1 *`（年に1回、1月1日の午前0時）、`@monthly` = `0 0 1 * *`（毎月1日の午前0時）、`@weekly` = `0 0 * * 0`（毎週日曜日の午前0時）、`@daily`/`@midnight` = `0 0 * * *`（毎日午前0時）、`@hourly` = `0 * * * *`（毎時0分）。このツールはこれらすべてを解析し、展開後の5フィールド式とまったく同じものとして扱います。

数値の代わりに日・月の名前を使えますか？

はい。月フィールドには`JAN`から`DEC`までの3文字の名前を使用でき、曜日フィールドには`SUN`から`SAT`（大文字小文字を区別しません）を数値の代わりに使用できます。曜日の数値は0〜6で、0が日曜日です。一部の実装では日曜日を表す7も使えますが、このツールでは0に正規化されます。範囲やリストも名前で使用可能です。例えば`MON-FRI`や`JAN,JUN,DEC`のように書けます。

入力したcron式はサーバーに送信されますか？

いいえ。解析、平易な言葉での説明、次の実行時刻の計算は、すべてブラウザ内のJavaScriptでローカルに処理されます。入力または生成した内容がデバイスの外に出ることは一切ありません。

次の実行時刻はどのタイムゾーンで計算されますか？

このツールはブラウザが認識しているローカルのタイムゾーン設定に基づいて次の実行時刻を計算します。実際のcronデーモンやCI/CDランナーがUTCなど別のタイムゾーンで動作している場合、表示される時刻と実際の実行時刻がずれることがあるため、本番のスケジューラーの設定タイムゾーンを別途確認してください。

GitHub ActionsのYAMLにそのまま貼り付けても大丈夫ですか？

生成される5フィールドの式自体はGitHub Actionsの`schedule:`が期待する構文と互換性があります。ただしGitHub Actionsのcronは常にUTCで評価される点に注意してください。日本時間で実行したい時刻がある場合は、UTCとの時差（+9時間）を差し引いた時刻を計算してから式を生成する必要があります。

「毎月最終日」のような指定はできますか？

いいえ。このツールが対応する標準の5フィールドcron構文には「最終日」を表す`L`のような特殊文字はありません（それはQuartz cronの機能です）。標準cronで月末を扱うには、`28-31`の範囲を指定した上でスクリプト側で当月の実際の最終日かどうかを判定するなど、別の工夫が必要です。

深夜バッチが想定より1時間ずれて実行されることがあるのはなぜですか？

サーバーやコンテナのタイムゾーン設定と、開発時に確認していたタイムゾーンが異なっている可能性があります。特に夏時間（サマータイム）を採用している地域のサーバーでは、年に2回スケジュールが1時間ずれることがあるため、UTC基準で式を組み、アプリ側で日本時間に変換する設計にしておくと事故を防ぎやすくなります。

Cron式ジェネレーター