Cron 式生成・解析無料・登録不要
Cron 式（5 フィールド）を視覚的に解釈 + 12 プリセット + 構文エラー検出。GitHub Actions / Linux crontab / Vercel Cron / Kubernetes CronJob に対応。
0 9 * * 1-5よく使うプリセット
フィールド構文一覧
| 分 (0-59) |
| 時 (0-23) |
| 日 (1-31) |
| 月 (1-12) |
| 曜日 (0-6 / 0=日) |
- *: 任意（全範囲）
- 5: 単一値
- 1,3,5: 複数値（カンマ区切り）
- 1-5: 範囲（1 から 5 まで）
- */15: 15 間隔（0, 15, 30, 45）
- 1-5/2: 範囲 + 間隔（1, 3, 5）
- GitHub Actions:
on.schedule.cronで定期 workflow（UTC 基準・JST -9h 注意） - Linux crontab:
crontab -eで編集（システム / ユーザ別 cron） - Jenkins: ジョブの Build Triggers - Build periodically
- Vercel Cron:
vercel.jsonのcrons配列 - Kubernetes CronJob:
spec.scheduleフィールド - 注意: GitHub Actions / AWS は UTC 基準。日本時間 9:00 = UTC 0:00 =
0 0 * * * - 関連: タイムゾーン変換 / 正規表現テスター
良いCron 式生成・解析の判断基準
定期実行のスケジュールを設定する時は、本ツールで Cron 式の解釈とエラーの有無を確認したうえで、下の判断基準を満たしてから実行環境に設定してください。式の文法が正しくても、タイムゾーンや環境ごとの書式差で意図と違う時刻に動くことがあります。
5 つのフィールドの順番を確認したか
標準的な Cron 式は左から「分・時・日・月・曜日」の順です。分と時を逆に書くミスが多いため、ツールの日本語解釈が自分の意図と一致しているかを必ず読み合わせます。
実行環境のタイムゾーンを確認したか
クラウドの実行環境には UTC 基準のものが多く、その場合「日本時間の朝 9 時」は 9 時間ずらした式で書く必要があります。設定先のドキュメントでどのタイムゾーン基準かを確認してから時刻を決めます。
実行頻度は意図通りか
「*/15」のような間隔指定や「1-5」のような範囲指定は、思い込みと実際の解釈がずれやすい書き方です。ツールの解釈文で「何分ごと・どの曜日に動くか」を日本語で確認します。
日と曜日を同時に指定していないか
日フィールドと曜日フィールドの両方を指定した場合の解釈（両方満たす時か、どちらかを満たす時か）は実行環境によって異なります。同時指定が必要な時は、設定先のドキュメントで挙動を確認します。
実行環境の書式差を確認したか
フィールド数（5 つか 6 つか）や使える拡張記法は環境ごとに違います。別の環境で使っていた式を流用する時ほど、設定先のドキュメントで書式を確認してから貼り付けます。
本番投入前にテスト実行したか
式の解釈が正しくても、実行される処理自体が失敗することはあります。まず数分後に動く式で 1 回テストし、ログで実行時刻と結果を確認してから本来のスケジュールに切り替えると安全です。
ありがちな失敗例（NG → 改善）
NG「0 9 * * *」を日本時間の朝 9 時のつもりで、UTC 基準の実行環境に設定する。
改善実行環境が UTC 基準なら「0 0 * * *」（UTC 0 時 = 日本時間 9 時）のように 9 時間ずらして書く。
→ タイムゾーンのずれは式の文法エラーにならないため、ツールでも実行環境でも警告が出ません。気づくのは「想定と違う時刻に動いた後」になりがちです。
NG「* * * * *」（毎分実行）を深く考えずに設定する。
改善本当に必要な最小限の頻度にし、実行環境に最短間隔の制限がないかドキュメントで確認する。
→ 毎分実行はリソース消費や実行回数の上限に直結します。環境によっては短すぎる間隔が制限・間引きの対象になります。
NG別のシステムで使っていた 6 フィールドの式を、5 フィールドの環境にそのまま貼り付ける。
改善設定先のフィールド数を先に確認し、秒フィールドの有無に合わせて式を書き直す。
→ フィールド数が違うと全フィールドの意味が 1 つずつずれて解釈され、まったく別のスケジュールで動いてしまいます。
Cron 式生成・解析の使い方
- 1テキストを入力またはペーストします
- 2「変換する」ボタンをクリックします
- 3結果を確認してコピーします
よくある質問
Cron 式生成・解析は無料ですか？
はい、完全無料でご利用いただけます。会員登録も不要です。
スマートフォンでも使えますか？
はい、スマートフォン・タブレット・PCなど、ブラウザがあればどのデバイスでもご利用いただけます。
入力したコードやデータは安全ですか？
はい、入力データはブラウザ上で処理され、サーバーに送信されません。安心してご利用ください。
関連ツール
Cron 式生成・解析について
Cron 式生成・解析が解決する課題
GitHub Actions / Vercel Cron / Linux crontab で定期実行を設定する時、「平日 9:00 は何？」「30 分ごとは？」と毎回ググるのは時間の無駄。本ツールは Cron 式を入れると日本語で実行タイミングを解釈 + 12 プリセットからコピペで使用 + 構文エラーを即検出します。
5 フィールドの意味
【1. 分 (0-59)】0 から 59 の数字 【2. 時 (0-23)】0 から 23 の数字（24 時間制） 【3. 日 (1-31)】1 から 31 の数字 【4. 月 (1-12)】1 から 12 の数字 【5. 曜日 (0-6)】0=日, 1=月, 2=火, 3=水, 4=木, 5=金, 6=土（一部 7=日 のシステムも）
例: - `0 9 * * 1-5` = 平日（月-金）9:00 に実行 - `*/15 * * * *` = 15 分ごとに実行 - `0 0 1 * *` = 毎月 1 日 0:00 に実行 - `0 0 1 1 *` = 毎年 1/1 0:00 に実行
こんなシーンで使えます
【1. GitHub Actions 定期実行】`on.schedule.cron` で毎日のスケジュールビルド・スクレイピング。
【2. Vercel Cron】vercel.json の crons 配列で Next.js API Route の定期実行。
【3. Linux crontab】サーバの定期バックアップ・ログローテート・スクリプト実行。
【4. Jenkins / GitLab CI】定期ビルド・定期テスト・週次レポート生成。
【5. Kubernetes CronJob】コンテナワークロードの定期実行。
【6. AWS EventBridge】Lambda / ECS タスクの定期実行（rate 式と cron 式を選択可）。
よくある失敗と注意点
1つ目: UTC vs JST 混同 → GitHub Actions / AWS / Vercel は UTC 基準。「日本時間 9:00」は `0 0 * * *`（UTC 0:00 = JST 9:00）。
2つ目: 5 フィールド vs 6 フィールド → 標準 Cron は 5 フィールド（分 時 日 月 曜日）。Java Quartz は 6 フィールド（秒 + 5）。
3つ目: 毎月末日 → 月によって 28/29/30/31 と異なる。`0 0 28-31 * *` の簡易表記 or Linux 系では `0 0 L * *` の L 拡張。
4つ目: 日と曜日の同時指定 → `0 0 15 * 1` は「15 日 OR 月曜日」(OR) または「15 日 AND 月曜」(AND) でシステム別解釈異なる。注意。
5つ目: 短すぎる間隔 → `* * * * *` （毎分）は GitHub Actions では制限あり（5 分以上推奨）。リソース消費注意。