Cron式パーサー・構文検証

Cron式パーサー・構文検証

Cron式を直感的な実行スケジュールに高精度変換。タイムゾーン別の次回実行予定日時の算出、crontab構文の妥当性検証、将来のトリガー予測を完全ローカルで実行します。

標準プリセット一覧
解析トークン数5/5
MIN
*/5
HOUR
*
DOM
*
MON
*
DOW
*
スケジュール実行周期Every 5 minutes past every hour.
高次スケジュール変数オーバーラン安全
推定実行時間（ランタイム）1 分
SVG実行パイプラインインメモリ処理
LEX5 トークンASTフィールドビットマスクPOSIXCleanRUNSafeSLOT10 件
構文正常（有効）
5 フィールド構成•POSIX 1分最小粒度
次回以降の実行予定タイムライン(10 occurrences)
No.予定時刻（現地時間）曜日カウントダウンジッタースロット（分散枠）UTCタイムスタンプ (ISO 8601)
1Nov 03, 2026, 03:20Tuein 3m 16sexact2026-11-03T03:20:00.029Z
2Nov 03, 2026, 03:25Tuein 8m 16sexact2026-11-03T03:25:00.029Z
3Nov 03, 2026, 03:30Tuein 13m 16sexact2026-11-03T03:30:00.029Z
4Nov 03, 2026, 03:35Tuein 18m 16sexact2026-11-03T03:35:00.029Z
5Nov 03, 2026, 03:40Tuein 23m 16sexact2026-11-03T03:40:00.029Z
6Nov 03, 2026, 03:45Tuein 28m 16sexact2026-11-03T03:45:00.029Z
7Nov 03, 2026, 03:50Tuein 33m 16sexact2026-11-03T03:50:00.029Z
8Nov 03, 2026, 03:55Tuein 38m 16sexact2026-11-03T03:55:00.029Z
9Nov 03, 2026, 04:00Tuein 43m 16sexact2026-11-03T04:00:00.029Z
10Nov 03, 2026, 04:05Tuein 48m 16sexact2026-11-03T04:05:00.029Z
次回実行予定 in 3m 16sタイムゾーン UTC
主要メトリクスAST構文木検証合格
稼働効率 / 処理キャパシティ5フィールド（標準POSIX）
実効出力数10 SLOTS
年間総トリガー数in 3m 16s
次回実行までの時間24 / 24 HRS
構文健全性スコア100% ローカル実行

完全クライアント側処理

ブラウザのメモリ内でのみ高速計算を実行。外部へのデータ送信は一切発生しません。

サーバー送信ゼロのプライバシー

入力されたスケジュール設定やペイロードはローカルに留まり、外部サーバーとの通信は皆無です。

本番環境対応エクスポート

Linux crontab、Kubernetes、CI/CDパイプラインへ即時投入可能な最適化済みフォーマットを出力。

ToolsAA•100% クライアント実行・完全プライベートWeb開発ツール
技術リファレンス・アーキテクチャガイド

Cron Expression Parser & Crontab Tester ガイド — 技術リファレンス

Cron式（クーロン式）を人間が理解しやすい実行スケジュールに解析・変換。各タイムゾーンにおける次回実行日時のシミュレーション、crontab構文のバリデーション、将来の実行予定タイムスタンプの予測を高精度に行います。

Cron Expression Parser & Crontab Tester ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図
Cron Expression Parser & Crontab Tester ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図

主要パラメータと設定項目

分フィールド（POSIX 第1フィールド / Quartz 第2フィールド）整数集合 [0-59]、アスタリスク (*)、ステップ (/n)、範囲 (a-b)、リスト (,)

ジョブを実行する毎時の指定「分」（0〜59）を定義します。60ビットの整数ビットマスクを用いたO(1)の包含判定で評価され、ステップ構文「*/15」を指定した場合は毎時0分、15分、30分、45分にトリガーされます。

初期値: 0（毎時0分）
時フィールド（POSIX 第2フィールド / Quartz 第3フィールド）整数集合 [0-23] 24時間制

24時間表記（0〜23）で1日の実行「時」を指定します。0は深夜00:00、23は午後11:00を表します。「9-17」の範囲指定により、各IANAタイムゾーンにおける標準的な営業時間（9:00〜17:00）の実行スケジュールを設定できます。

初期値: *（毎時）
日フィールド（POSIX 第3フィールド / Quartz 第4フィールド）整数集合 [1-31]、クエスチョンマーク (?)、末日 (L)、最近接平日 (W)

月内のカレンダー日付（1〜31）を指定します。月の実際の日数を超える無効な日付（4月31日や2月30日など）は、カレンダー繰り越し検証時に安全にスキップされます。

初期値: *（毎日）
月フィールド（POSIX 第4フィールド / Quartz 第5フィールド）整数集合 [1-12] または英字3文字エイリアス [JAN-DEC]

カレンダー月を1（1月）〜12（12月）で指定します。POSIX準拠システムでは大文字・小文字を区別しない英字3文字（JAN〜DEC）表記に対応しており、内部的に12ビット整数ビットマスクにマッピングされます。

初期値: *（毎月）
曜日フィールド（POSIX 第5フィールド / Quartz 第6フィールド）整数集合 [0-7] または英字3文字エイリアス [SUN-SAT]、第N曜日 (#)、最終曜日 (L)

実行する曜日を指定します。POSIX IEEE 1003.1およびVixie cron仕様では、0と7の両方が日曜日を表します（1=月曜日、…、6=土曜日）。英字3文字の略称（SUN〜SAT）を使用することで、処理系の方言によるインデックスのズレ（オフバイワンエラー）を防止できます。

初期値: *（すべての曜日）
秒フィールド（Quartz / Spring 第1フィールド、POSIXでは省略）整数集合 [0-59] 高分解能秒

6フィールド構成のスケジューラ（Quartz、Spring Frameworkなど）で先頭に配置される高分解能な秒指定フィールド。標準的な5フィールドUNIX crontabでは秒単位の指定をサポートしておらず、先頭に余分なトークンが存在すると構文エラーとして扱われます。

初期値: 0（0秒）
年フィールド（Quartz オプション第7フィールド / AWS EventBridge 第6フィールド）整数集合 [1970-2099]、アスタリスク (*)、POSIXでは省略

エンタープライズスケジューラでサポートされる末尾の西暦年フィールド。定期実行ジョブを特定のエポック年に限定し、無期限の無限ループを防止するために使用されます。

初期値: *（無制限 / 毎年）

現場のベストプラクティス・実践Tips

POSIX仕様における「日」と「曜日」の同時指定はANDではなく論理ORとして評価される

標準的なVixie cronおよびPOSIX IEEE 1003.1仕様では、日（第3フィールド）と曜日（第5フィールド）の両方にワイルドカード（*）以外の値を指定した場合、スケジューラはこれらを論理OR条件として評価します。例えば「0 0 13 * 5」は「13日の金曜日」にのみ実行されるのではなく、「毎月13日」および「すべての金曜日」の両方で実行されます。厳密に13日の金曜日のみに限定したい場合は、曜日フィールドを「*」にした上で、コマンド側で曜日判定を実行します: 0 0 13 * * [ $(date +\%u) -eq 5 ] && /opt/backup.sh

ステップ値（*/N）はフィールド境界でリセットされ不均等な剰余ギャップを生む

開発者の間でよくある誤解として、「*/25 * * * *」が25分間隔で連続実行されるという思い込みがあります。実際には、cronのステップ式は各フィールドの境界（分なら0〜59）内で厳密に評価されます。59を25でステップ評価すると、実行されるのは0分、25分、50分のみです。時刻が次の時間（例: 01:50から02:00）に進むと、フィールドは再び0分にリセットされるため、25分周期ではなく10分の隙間が生じます。時間を跨いで厳密に一定の間隔で実行する必要がある場合は、Systemdモノトニックタイマー（OnUnitActiveSec=25m）やトークンバケット方式のタスクキューを使用してください。

夏時間（DST）の衝突を回避するためサーバーのcrontabは常にUTCへ統一する

夏時間（DST）が導入されているタイムゾーンでcrontabデーモンを稼働させると、深刻なスケジュール異常が発生します。春の進み時間（スプリングフォワード: +1時間）移行時には、02:00〜02:59の時刻が存在しないため、その間に設定されたジョブは完全にスキップされます。秋の戻り時間（フォールバック: -1時間）移行時には、該当時間のジョブが2回重複実行されます。二重実行やスキップを防ぐため、システムクロックとcrontab環境変数は常に「TZ=UTC」に固定し、業務時間オフセット（JST等）は静的に算出して管理することを推奨します。

Vixie Cronのコマンドフィールド内ではパーセント記号（%）をバックスラッシュでエスケープする

crontabファイル内において、エスケープされていないパーセント記号（%）は特別な構文上の意味を持ちます。cronデーモンによって改行文字へと置換され、以降のすべてのデータがコマンドの標準入力（stdin）へとパイプされます。「date +%Y-%m-%d」のようなインラインフォーマットコマンドをそのまま記述すると、スクリプトが途中で切断されるか難解な構文エラーを引き起こします。「date +\%Y-\%m-\%d」のようにすべての%記号をエスケープするか、呼び出し処理を外部の実行可能シェルスクリプトファイル内にカプセル化してください。

よくある落とし穴とトラブルシューティング

⚠️Crontabが構文エラーを出力する: Linuxの/etc/crontabに6フィールドまたは7フィールドの式を貼り付けた場合

標準的なUNIX/Linuxのcrontabは、半角スペースで区切られた厳密に5つのフィールドのみを要求します。Java Quartz、Spring Framework、AWS EventBridgeからコピーした式には、先頭の秒フィールド（例: 0 0 12 * * ?）や末尾の年フィールドが含まれています。これらを標準crontabに貼り付けると、6番目のトークンが実行ユーザー名またはコマンド名として誤認識され、構文エラーが発生します。先頭の秒トークンと末尾の年トークンを削除し、クエスチョンマーク（?）を標準のアスタリスク（*）に変換してください。

⚠️Cronジョブが意図しない時間や誤ったローカル時刻に実行される

crontabデーモンは、システムローカルのハードウェアおよびカーネルのタイムゾーン（/etc/timezoneまたは/etc/localtime）を基準にスケジュールを評価します。クラウド環境（AWS EC2、Dockerコンテナ、Kubernetesノード等）では、デフォルトのシステムクロックは通常UTCに設定されています。日本時間（JST）の午前9:00を意図して「0 9 * * 1-5」と記述すると、UTCの午前9:00（日本時間の18:00）に実行されてしまいます。crontabファイルの先頭に「CRON_TZ=Asia/Tokyo」を明示的に記述するか（Vixie cron 4.1以降）、UTC基準の時刻（例: JST 9時はUTC 0時なので「0 0 * * 1-5」）に換算して設定してください。

⚠️Cronジョブが実行されない、または環境変数（$PATH）が見つからない

cronはタスクを非対話型・非ログインのクリーンなシェル内で実行するため、最小限のデフォルトPATH（通常は /usr/bin:/bin のみ）しか読み込まれません。/usr/local/bin、~/.nvm、/opt/homebrew などにインストールされたコマンドは「command not found」エラーで失敗します。crontabの先頭行に「PATH=/usr/local/bin:/usr/bin:/bin」を明示的に定義するか、すべての実行ファイルやバイナリを絶対パス（例: /usr/bin/python3 /opt/app/job.py）で指定して呼び出してください。

⚠️日（DOM）と曜日（DOW）を組み合わせた際に想定外の2倍の頻度で実行される

POSIX標準規格 IEEE 1003.1 に規定されているとおり、日と曜日の両フィールドに「*」以外の値を指定した場合、それらはAND条件ではなくOR条件として評価されます。日付が一致した日、または指定の曜日に該当する日のいずれでもジョブが発火します。両方の条件を同時に満たす実行（例: 毎月第1月曜日）を強制するには、曜日フィールドを「*」に設定し、コマンド内にPOSIX dateコマンドによる判定を組み込んでください: 0 3 1-7 * * [ $(date +\%u) -eq 1 ] && /opt/first-monday.sh

よくある質問 (FAQ)

Cron式の正確な次回実行日時はどのように算出されますか？▼

次回実行日時は、基準となるISO 8601タイムスタンプを1分単位（6フィールドエンジンでは1秒単位）で進めながら、各候補値を事前にコンパイルされた64ビットのビットマスクとビット単位のAND演算で照合（O(n)のステップ計算量）することで算出されます。POSIX仕様の日/曜日ユニオンロジックに従い、すべてのフィールドが同時に一致した時点で、そのタイムスタンプが有効な実行日時として記録されます。ブラウザサンドボックス環境では、すべてのAST構文解析および予測計算が隔離されたJavaScriptメモリ内で完結し、サーバーとの通信は一切発生しません。

標準的なLinuxの5フィールドcronとQuartzの6フィールドcronの違いは何ですか？▼

標準のPOSIX/Linux cronは、半角スペース区切りの5つのフィールド（分、時、日、月、曜日）を用い、1分単位の精度で動作します。一方、Java QuartzやSpring Frameworkのスケジューラは、先頭に必須の「秒」フィールド（0〜59）を追加し、末尾に任意の「年」フィールド（1970〜2099）を付加した6〜7フィールド構成を採用しています。さらにQuartzでは「?」（制約なし）や「L」（月末または週末）などの特殊文字が使用可能ですが、これらを標準のUNIX crontabに入力すると致命的な構文エラーとなります。

Cron構文におけるアスタリスク（*）とスラッシュ（/ステップ）の違いは何ですか？▼

アスタリスク（*）はそのフィールドのすべての有効な整数値（例: 分フィールドなら0〜59）に合致する無制約のワイルドカードとして機能します。一方、スラッシュ（/ステップ）はフィールド境界内の基準値から離散的なステップ間隔で評価を行う剰余インターバルを定義します。例えば「*/15」は0分、15分、30分、45分にマッチしますが、「10-30/5」と指定した場合は限定された範囲内でのみステップが評価され、10分、15分、20分、25分、30分にマッチします。

「0 0 13 * 5」が「13日の金曜日」だけでなく「すべての金曜日」にも実行されるのはなぜですか？▼

POSIX規格 IEEE 1003.1 の仕様により、日（第3フィールド）と曜日（第5フィールド）の両方にワイルドカード以外の値が設定されている場合、スケジューラは論理AND結合ではなく論理OR結合（選言）として評価します。その結果、日付に関係なくすべての金曜日、および曜日に関係なく毎月13日の両方でジョブが実行されます。AND条件（13日かつ金曜日）を実現するには、曜日フィールドを「*」にしておき、実行スクリプト側で [ $(date +\%u) -eq 5 ] を用いて曜日を判定してください。

Cron式におけるクエスチョンマーク（?）や「L」記号にはどのような意味がありますか？▼

Quartz、Spring、AWS EventBridgeなどのcron方言において、クエスチョンマーク（?）は日フィールドと曜日フィールドの競合を回避するための「特定の値なし（指定なし）」を表します。また「L」記号は「Last（最終）」を意味し、月の最終日や「5L」（月の最終金曜日）などの指定に使用されます。なお、標準のPOSIX IEEE 1003.1 crontabでは「?」や「L」は認識されず、構文エラーとして拒否されます。

夏時間（DST）のスプリングフォワードとフォールバックはCronジョブにどのような影響を与えますか？▼

夏時間の1時間進む移行時（スプリングフォワード）には、スキップされる時計上の時間枠（通常は02:00:00〜02:59:59）にスケジュールされたジョブは、その時刻が存在しないため完全に実行されずにスキップされます。一方、秋の1時間戻る移行時（フォールバック）には、重複する時間枠にスケジュールされたジョブが2回トリガーされる危険があります。ジョブのスキップや意図しない多重実行を防ぐため、本番環境のサーバーではハードウェアクロックおよびcrontabデーモンを常にUTCで稼働させることが推奨されます。

関連開発者ツール

全ツール一覧 →
GraphQL TS型生成開発者ツール

GraphQL スキーマ（SDL）やクエリから TypeScript の型定義、インターフェース、Enum、リゾルバーを自動生成。設定不要・サーバー送信なしでブラウザ上で即座にコード生成できます。

ツールを開く→
HTML Markdown変換開発者ツール

HTMLやWebクリップをGitHub Flavored Markdown（GFM）に瞬時に変換。インラインスタイルを除去し、テーブルやコードブロックをクリーンなMDファイルとして出力します。

ツールを開く→
テキスト差分比較ツール開発者ツール

テキスト、コード、設定ファイルの差分を高速比較。左右分割やインラインでの文字単位の変更確認、空白の無視、Unified Diff（.patch）の出力に対応。

ツールを開く→
カノニカルタグ生成ツール開発者ツール

有効なrel=canonicalタグやHTTPレスポンスヘッダーを瞬時に作成。不要な追跡パラメータの削除、URL正規化、重複コンテンツによるSEO評価の分散を確実に防止します。

ツールを開く→
cURLをFetchに変換開発者ツール

cURLコマンドを一瞬でFetch APIコードに変換。HTTPヘッダー、認証トークン、Cookie、JSONペイロードを自動解析し、最新のasync/await対応JavaScriptコードを生成します。

ツールを開く→
XMLサイトマップ検証ツール開発者ツール

XMLサイトマップおよびインデックスファイルの構文を瞬時に検証。5万URL制限、50MB容量上限、W3C Datetime（ISO-8601）、hreflang相互リンク、画像拡張、Google Search Console登録エラーを完全チェックします。

ツールを開く→