無料AIツール集

Cron 式解析

Cron式が、いつ動く設定かを日本語で読み解きます。

無料・登録不要

実行タイミング
0 分 / 9 時 / 曜日: 1 から 5
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)
Cron 式の使い所
  • 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 * * *
  • 関連: タイムゾーン変換 / 正規表現テスター

使い方

  1. 1「Cron 式(5 フィールド: 分 時 日 月 曜日)」に式を入れます。「よく使うプリセット」からも選べます
  2. 2「実行タイミング」を読みます
  3. 3「構文エラー」が出たら式を直します

あわせて使えるツール

使い方と例文

Cron 式解析の使い方

  1. 1テキストを入力またはペーストします
  2. 2「変換する」ボタンをクリックします
  3. 3結果を確認してコピーします

よくある質問

Cron 式解析は無料ですか?
はい、完全無料でご利用いただけます。会員登録も不要です。
スマートフォンでも使えますか?
はい、スマートフォン・タブレット・PCなど、ブラウザがあればどのデバイスでもご利用いただけます。
入力したコードやデータは安全ですか?
はい、入力データはブラウザ上で処理され、サーバーに送信されません。
判断基準と失敗例

良い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 式(5 フィールド)を視覚的に解釈 + 12 プリセット + フィールド数のチェック。GitHub Actions / Linux crontab / Vercel Cron / Kubernetes CronJob に対応。

Cron 式を日本語の実行タイミングに読み替える画面

GitHub Actions / Vercel Cron / Linux crontab で定期実行を設定する時、「平日 9:00 は何?」「30 分ごとは?」と毎回ググるのは時間の無駄。本ツールは Cron 式を入れると日本語で実行タイミングを解釈 + 12 プリセットからコピペで使用 + 構文エラーを即検出します。

【画面の作り】入力欄は1つだけです。式を打つと、その下の枠に日本語の解釈がその場で出ます。生成するボタンを押す操作はありません。式のフィールド数が5でないときだけ、枠が赤くなって構文エラーが出ます。次にどの日時で動くかを計算する機能は付いていないため、実行タイミングの読み替えと構文の確認までがこの画面の役割です。

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 に実行

0 9 * * 1-5 と */15 * * * * を解析した実処理結果

編集部で4つの式を実際に入力し、画面に出た解釈をそのまま記録しました。処理はブラウザの中で完結し、検証中にサイトの AI 処理窓口へ送られた通信は1件もありませんでした。

【入力】0 9 * * 1-5(画面を開いた直後に入っている式) 【出た解釈】0 分 / 9 時 / 曜日: 1 から 5

【入力】*/15 * * * * 【出た解釈】15 分ごと / 毎時

解釈はスラッシュ区切りの短い文で出ます。「平日9時」「15分おき」のような日常語ではなく、フィールドの値を1つずつ日本語に置き換えた形です。アスタリスクが入っているフィールドは文から省かれます。*/15 の例で「毎時」だけが残っているのは、時のフィールドがアスタリスクだからです。省かれた項目は「毎回」の意味なので、出ていないものを読み落とさないでください。

2月31日(0 0 31 2 *)と6フィールドを入れたときの実処理結果

弱点が出るはずの2つも試しました。

【入力】0 0 31 2 *(2月31日という、暦に無い日付) 【出た解釈】0 分 / 0 時 / 31 日 / 2 月

エラーになりません。赤い枠も出ず、そのまま説明文が組み立てられました。文法としては正しいが永久に来ない日付が、正しい式に見えてしまいます。

【入力】*/5 * * * * *(秒を足した6フィールド) 【出た結果】Cron 式は 5 フィールド(分 時 日 月 曜日)必要。現在 6 フィールド

こちらは構文エラーとして止まりました。フィールドの数え違いは検出できる一方、中身の値が暦として成り立つかは見ていない、という線引きが実測ではっきりしました。この線引きさえ分かっていれば、日付を指定する式のときだけ自分の目で確かめる、という使い方に切り替えられます。

曜日の範囲が「1 から 5」のまま出る、この解析器のクセ

【クセ1】曜日の範囲指定は数字のまま出ます。0 9 * * 1-5 の解釈は「曜日: 1 から 5」で、「月曜から金曜」には書き換わりません。曜日を1つだけ指定したときは曜日名が添えられる作りですが、範囲にはその処理が及びません。0が日曜、1が月曜という対応は自分で当てはめてください。

【クセ2】アスタリスクのフィールドは解釈文から消えます。短く読みやすい代わりに、指定していない項目が画面から見えなくなります。

【クセ3】解釈は入力のたびに書き換わります。式を1文字直すたびに下の枠が更新されるので、思いついた式を続けて試すのに向いています。

弱点は、暦として成立するかを検査しないことです。今回試した4つのうち、5フィールドで書かれた式はすべて説明文が出ました。フィールドの数だけを見る仕組みで、値が現実に存在する日付かどうかは見ていません。これは4パターンで見えた範囲であり、どんな式でも同じ挙動になる保証ではありません(分や時に大きすぎる数字を入れた場合は今回試していません)。もう1つの構造上の限界として、次回の実行日時を計算する機能そのものが無いため、本当に次はいつ動くのかはこの画面では確認できません。

UTC と JST のずれなど、実行環境に貼る前の5つの注意

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 分以上推奨)。リソース消費注意。

向かない用途は、拡張記法が使えるかどうかの判定です。この画面が検査しているのはフィールドの数だけなので、L や W のような環境固有の書き方に対応しているかは判断できません。設定先のドキュメントで確認してください。次回の実行日時を知りたい場合も、この画面の役割の外にあります。

GitHub Actions・crontab・Vercel Cron で式を貼る場面

【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 式を選択可)。

この6つは、貼り付け先ごとに書式もタイムゾーンも変わります。本ツールで確かめられるのは「その式が5フィールドとして何を意味するか」までです。同じ式が貼り付け先でも同じ意味になるかは、それぞれのドキュメントと突き合わせてください。

12 プリセットの中身と、コピー前に読み合わせる2点

画面下部のプリセットは12個で、押すと入力欄の式が置き換わります。実物は次のとおりです。

毎分 = * * * * * 5 分ごと = */5 * * * * 15 分ごと = */15 * * * * 毎時 0 分 = 0 * * * * 毎日 0:00 = 0 0 * * * 毎日 9:00 = 0 9 * * * 平日 9:00 = 0 9 * * 1-5 毎週月曜 9:00 = 0 9 * * 1 毎月 1 日 0:00 = 0 0 1 * * 毎月28〜31日(月末の近く)= 0 0 28-31 * * 四半期初日 = 0 0 1 1,4,7,10 * 毎年 1/1 = 0 0 1 1 *

プリセットの「毎月28〜31日(月末の近く)」のとおり、0 0 28-31 * * は28日から31日まで毎日動く式です。月末の1回だけ動く式ではありません。プリセットも万能ではない、という前提で使ってください。

コピーする前に人が読み合わせるのは2点です。1つ目は、日本語の解釈文と自分の意図が一致しているか。特に曜日は数字のまま出るので、1が月曜であることを確かめます。2つ目は、その時刻が貼り付け先のタイムゾーンで正しいか。この2点は解釈文とドキュメントを並べれば数十秒で終わります。

最終更新 ・ 所要時間 約1分 ・ 編集: 無料AIツール集 編集部

シェア