DevOps 以外のためのクロン式パーサー説明

小さな機能を出荷し、平日午前 9 時に実行する必要があり、cron に手を伸ばします。3 回の失敗した試みと 1 つの本番インシデント（ジョブが週末全体毎分実行）の後、今月 4 回目の cron 式構文リファレンスを参照しています。Wikipedia テーブルは密集し、StackOverflow の回答は互いに矛盾し、AI アシスタントが与えた答えはスケジューラーが実際に受け入れたものと完全には一致しません。

このガイドは、毎日それらを書かない人々——プロダクトマネージャー、創業者、デザイナー、アナリスト、年に数回 cron を使用し、難解さを暗記せずに正しく取得したいバックエンド開発者——のために、第一原則から cron 式を説明します。任意の式を平易な英語で視覚化するための Ai2Done Cron Parser に加えて、経験豊富なエンジニアでさえ噛む落とし穴をカバーします。

TL;DR

• cron 式は 5 フィールド：分 時 月日 月 曜日 —— スペースで区切られる。
• 最もトリッキーな落とし穴：月日と曜日の両方が指定されているとき、古典的 Unix cron は OR として扱う（どちらかが一致すれば実行）、それは滅多にあなたが望むものではありません。
• 任意の式を平易な英語に翻訳し、デプロイ前に次の 5〜10 実行時間を見るために Ai2Done Cron Parser を使用。
• タイムゾーンが重要：ほとんどの cron スケジューラーは UTC で実行；呼び出しシステム（Kubernetes CronJob、AWS EventBridge など）でタイムゾーンを明示的に指定。
• 特殊文字 * / , - L W ? # は古典 cron 対 Quartz cron で異なる意味 —— スケジューラーに正しいダイアレクトを選んでください。

なぜ見た目より難しいのか

1975 年の元の Unix cron は 5 フィールドを使用しました。モダンスケジューラー（Quartz、Kubernetes CronJobs、AWS EventBridge、GitLab スケジュール、GitHub Actions）は構文を非互換な方法で拡張または変更します。少なくとも 4 つの広く使用されているダイアレクトがあります：

1. 古典 Unix cron（5 フィールド、Linux/macOS の crontab で使用）
2. Vixie cron（事実上の Linux 実装、いくつかの拡張）
3. Quartz cron（秒と年を含む 7 フィールド、Java スケジューラーと AWS EventBridge で使用）
4. Kubernetes CronJob（5 フィールド、ただし ? なしとわずかに異なる DST 処理）

1 つのシステムで完璧に機能する cron 式は、別のシステムで検証に失敗、予期しない時間に実行、または静かに発火しない可能性があります。「この式は有効か？」質問は本当にダイアレクト依存です。

混乱の 2 番目のソース：「5 フィールド」フレーミングは順序を覚えていると仮定。プレッシャー下のほとんどのエンジニアは「分と時があり... 日と月どっちが先？」を覚えています。正しい順序は分、時、月日、月、曜日です。

3 番目のソース：特殊文字は非明白な方法で相互作用。0 0 1,15 * 1-5 は毎月 1 日と 15 日に実行、または月曜から金曜まで（古典 cron が月日と曜日を OR するため）。「1 日と 15 日だが、平日のときのみ」を得るには、Quartz cron の ? プレースホルダーが必要です。

良い cron パーサーは、本番にデプロイする前に式が実際に何をするかを健全性チェックできるよう、タイムゾーンで次の 5〜10 実際の実行時間を表示します。

5 フィールドを説明

*   *   *   *   *
│   │   │   │   │
│   │   │   │   └── 曜日（0-6 または SUN-SAT；一部のダイアレクトは 1-7 を使用）
│   │   │   └────── 月（1-12 または JAN-DEC）
│   │   └────────── 月日（1-31）
│   └────────────── 時（0-23）
└────────────────── 分（0-59）

各フィールドは以下になれます：

• 特定の数値：5（「この正確な値」を意味）
• リスト：1,15,30（「これらの値のいずれか」を意味）
• 範囲：1-5（「これからその通り」を意味）
• ステップ：*/15（「0 から始まる N 番目ごと」を意味）—— だから分フィールドの */15 は「0、15、30、45」
• ワイルドカード：*（「すべての値」を意味）

構文を知ってからの一般的なパターン：

• * * * * * —— 毎分（午前 3 時に起こす有名な「スケジュール指定し忘れた」式）
• */5 * * * * —— 5 分ごと
• 0 * * * * —— 毎時、時刻
• 0 9 * * * —— 毎日午前 9:00
• 0 9 * * 1-5 —— 平日午前 9:00（教科書的「営業時間」ジョブ）
• 0 0 1 * * —— 毎月 1 日午前 0 時
• 0 0 * * 0 —— 日曜午前 0 時（週境界）
• 15 14 1 * * —— 毎月 1 日午後 2:15
• 0 */6 * * * —— 6 時間ごと（0、6、12、18）

方法 1：Ai2Done Cron Parser（デプロイ前の視覚的検証）

Ai2Done Cron Parser は任意の式を平易な英語に翻訳し、次の 10 実際の発火時間を表示します。フロー：

1. 任意のブラウザで /tools/cron_parser を開く。
2. 式を貼り付け —— 例：0 9 * * 1-5。
3. 瞬時に見る：
   • 平易な英語：「午前 09:00、月曜から金曜まで」
   • ローカルタイムゾーンの次の 10 発火時間
   • 各部分が何にマッチするかを示すフィールドごとの内訳
   • 不可能な式の検証エラー（例：0 9 32 * * —— 月の 32 日はない）
4. スケジューラーが非標準バリアントを使用する場合は、古典 cron、Quartz、AWS EventBridge、Kubernetes 間でダイアレクトを切り替え。

ツールは人間読みやすい翻訳のために cronstrue ライブラリと次発火計算のために cron-parser を使って完全にクライアントサイドで実行されます。式はサーバーに触れません。

プロのヒント：任意の cron 駆動ジョブを本番にデプロイする前に、式をパーサーに貼り付け、少なくとも次の 3 発火時間が意図と一致することを確認してください。これは古典的な「6 時間ごとを意味したが、午前 6 時に 1 日 1 回を意味する 0 6 * * * をタイプした」エラーを 5 秒でキャッチします。

方法 2：crontab.guru ウェブサイト

すでにブラウザにいるなら、crontab.guru は cron 説明の非公式標準です。同じコア機能を持つ単一ページの Web ツール —— 式を貼り付け、英語を見る。Ai2Done パーサーとの違い：

• サーバーサイドで実行（式が彼らのアクセスログにログされる）
• フィールドごとの内訳を表示しない
• 古典 cron のみをサポート（Quartz なし、AWS EventBridge ダイアレクトなし）
• 〜10 年間無料で優秀

非機微な式には、結構な選択です。情報をリークする可能性のある式（例：一部の Quartz ダイアレクトでカスタムフィールド名を含む式）には、ローカルパーサーが安全です。

方法 3：ドライランスケジューラーでテスト

高リスク cron ジョブ（データパイプライン、課金実行、顧客向けスケジュールアクション）には、最高信頼度のアプローチは最初にドライラン環境にデプロイすることです：

• Kubernetes：suspend: true で CronJob をデプロイし、kubectl describe 経由で計算された次の実行を検査。
• AWS EventBridge：ターゲットなしでルールを作成し、計算された NextInvocations を見る。
• Airflow / Dagster：常に任意の DAG スケジュールの次の 5〜20 発火時間を表示するスケジューラーの UI を使用。

これはパーサーがしないエッジケースをキャッチします（クラスターの UTC オフセット、サマータイム遷移、? を持つ 6 フィールドを必要とする AWS EventBridge の cron(0 9 ? * MON-FRI *) 構文のようなスケジューラー固有の癖）。

古典的な落とし穴

月日と曜日は AND ではなく OR。 0 0 1 * 1 は毎月 1 日午前 0 時に実行、そして毎月曜日。「月曜のときのみ 1 日」ではありません。AND を得るには、「特定の値なし」を示すために Quartz cron の ? を使用 —— 0 0 1 * ? は曜日に関係なく 1 日のみ実行。

*/N は「N 単位ごと」ではない。 「0 から始まる N 単位ごと」です。だから */30 * * * * は毎時 :00 と :30 に実行、「最後の実行から 30 分後」ではない。実際の固定間隔スケジューリングには、ジョブキュー（Celery、BullMQ、Sidekiq）を使用 —— cron は根本的にカレンダーベースで、間隔ベースではない。

タイムゾーンデフォルトは信頼できない。 Linux cron はシステムタイムゾーンで実行。Docker コンテナは通常 UTC をデフォルト。AWS EventBridge は UTC をデフォルト。Kubernetes CronJobs は API サーバーのタイムゾーン（しばしば UTC）をデフォルト。ジョブが「ローカル時間午前 9 時」に実行する必要があるなら、タイムゾーンを明示的に設定 —— デフォルトを信頼しないでください。

サマータイムはゴースト実行を作成。 午前 2 時に時計が春に前進すると、午前 2:30 にスケジュールされたジョブはその日実行しません。時計が後退するとき、2 回実行します。ほとんどのスケジューラーにはこれを処理するオプションがあります（Quartz のミスファイアポリシー、Kubernetes の concurrencyPolicy）；あなたのものについてドキュメントを読んでください。

0 0 31 2 * —— 2 月 31 日に実行、存在しません。ほとんどのスケジューラーは静かにそれをスキップします。デプロイ前にテストしてください。

パーサーをどう構築したか（技術的ディープダイブ）

Ai2Done Cron Parser は以下に構築されています：

• 英語翻訳のための cronstrue（クラス最高、すべての主要ダイアレクトをサポート、〜30 KB gzip 圧縮）
• 次の発火時間を計算するための cron-parser（DST、うるう日、範囲、ステップを正しく処理）
• AWS EventBridge 構文（cron(0 9 ? * MON-FRI *) —— 6 フィールド、年オプション）を基礎パーサーが期待するフォーマットに翻訳する小さなダイアレクトアダプター
• Web Crypto / SubtleCrypto は未使用 —— ここにはセキュリティ機微なコンテンツはない；パーサーは単に便利ツール

興味深いデザインの選択：「Google Calendar スタイルのピッカーから cron を構築」を意図的に提供しません。その種の UI は初心者には素晴らしいですが、基礎構文ではなくピッカーを人々に教える傾向があります。Cron は密集していますが 20 分で学べます；隠すのではなく読むのを助けます。

FAQ

Q: なぜ一部のスケジューラーには 5 フィールドで他には 6 または 7 ありますか？ A: 古典 Unix cron は 5 フィールド（分 時 日 月 曜日）。Quartz は 2 つ追加：前に秒、終わりに年（* * * * * * *）。AWS EventBridge は 6 フィールドを使用、月日 / 曜日の 1 つが ? である必要。スケジューラーに一致するダイアレクトを選んでください。

Q: cron 式で ? は何を意味しますか？ A: 「特定の値なし」を意味する Quartz / AWS EventBridge 拡張。1 つだけがマッチすべきとき曖昧さ解消のために月日と曜日で使用。古典 Unix cron ではサポートされない。

Q: cron 式で L は何を意味しますか？ A: 「最後」のための Quartz 拡張。月日の L は「月の最後の日」（28/29/30/31 による）を意味。曜日の 5L は「月の最後の金曜日」を意味。28/29/30/31 をハードコードせずに月末ジョブに便利。

Q: cron 式で W は何を意味しますか？ A: 「平日」のための Quartz 拡張。月日の 15W は「15 日に最も近い平日」を意味 —— 「月給だが週末には決して」に便利。

Q: 営業時間中のみ 5 分ごとにジョブを実行するには？ A: */5 9-17 * * 1-5 —— 5 分ごと、時間 9-17、平日。パーサーで検証；次の 10 発火時間が期待と一致するはず。

Q: サマータイム遷移中にジョブが 2 回実行されました。どう修正しますか？ A: これはスケジューラー固有です。Kubernetes CronJob の concurrencyPolicy: Forbid は重複する実行を防ぎます。Quartz にはミスファイアポリシーがあります。AWS EventBridge は常に UTC で実行することで DST を処理（だからサマータイムはアプリケーションの問題）。

Q: cron で「毎月最初の月曜日」を表現できますか？ A: 古典 Unix cron では、いいえ —— アプリケーションレベルロジックが必要です。Quartz cron では、はい：0 0 0 ? * MON#1（毎月の最初の月曜日午前 0 時に実行）。

今試す

本番で実行する前に任意の cron 式を検証：

Cron Parser を開く →

貼り付け、見る、デプロイ。アップロードなし、サインアップなし、式はブラウザに留まります。

関連読み物

• トークンを決して送信しないプライバシーセーフ JWT デバッガー —— 同じアーキテクチャ、JWT に適用
• JSON、YAML、XML、CSV —— 1 つのツールボックスでラウンドトリッピング —— cron ジョブがおそらく消費する設定ファイル用
• WASM サイド処理：なぜすべてをブラウザで実行するか
• すべての 開発者ツール を閲覧

最終更新 2026-06-14。Cron Parser はブラウザで 100% 動作 —— 式はデバイスを離れません。テストしたものについてサーバーログはありません。