GitHub Actions の cron を日本時間で動かすにはどう書きますか？

GitHub Actions の schedule は UTC で読まれるので、日本時間の時刻から 9 時間引いて書きます。日本時間の毎日 9:00 なら「0 0 * * *」、平日 9:00 なら「0 0 * * 1-5」です。日本時間の 0〜8 時は UTC では前の日になるため、平日 8:30 なら曜日も1つ前にずらして「30 23 * * 0-4」（日〜木の 23:30 UTC）にします。このツールの「日本時間と UTC の変換」に日本時間の式を入れると、ずらした式と次の実行日時を出します。

cron で日と曜日を両方指定するとどうなりますか？

crontab（Linux の cron）・GitHub Actions・Kubernetes では、日と曜日の両方を * 以外にすると「どちらかに当てはまる日」に動きます。たとえば「0 0 13 * 5」は 13 日の金曜日だけではなく、毎月 13 日と毎週金曜日の両方で動きます。「第1月曜日」のように両方を満たす日にしたいときは、日を 1-7 にしてコマンドの先頭で曜日を確かめるか、EventBridge・Spring の「MON#1」のような書き方を使います。

「* 9 * * *」と「0 9 * * *」は何が違いますか？

「* 9 * * *」は分が * なので、9:00 から 9:59 まで 1 分ごとに 60 回動きます。毎日 9:00 に1回だけ動かしたいなら、分を 0 にした「0 9 * * *」が正解です。cron 式の書き間違いで一番多いもので、このツールでは注意として表示します。

毎月の末日に cron を動かすにはどうすればいいですか？

crontab と GitHub Actions には末日の書き方がないため、日を 28-31 にして、コマンドの先頭で「明日が1日か」を確かめます（例: 0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && コマンド）。crontab ではコマンドの中の % を \% と書く点に注意してください。AWS EventBridge なら cron(0 23 L * ? *)、Spring なら 0 0 23 L * * のように L で書けます。

「*/7」は 7 分おきになりますか？

なりません。「*/7」は毎時 0・7・14・21・28・35・42・49・56 分に動き、56 分の次は次の時の 0 分なので、そこだけ間隔が 4 分になります。60 を割り切れる数（1・2・3・4・5・6・10・12・15・20・30）なら間隔はそろいます。このツールの「実行の間隔」で、最短と最長の間隔を確かめられます。

AWS EventBridge の cron で「?」は何の意味ですか？

「?」は「指定しない」という意味で、EventBridge では日（3 つ目）か曜日（5 つ目）のどちらかを必ず ? にします。毎日なら cron(0 9 * * ? *)、平日なら cron(0 9 ? * MON-FRI *) です。両方に値を書くとエラーになります。また EventBridge の曜日の数字は 1 が日曜なので、MON-FRI のように英語で書くと間違えにくくなります。

crontab のコマンドに date +%Y%m%d を書くと動かないのはなぜですか？

crontab では、コマンドの中の % が改行として扱われ、% から後ろは標準入力に回されます。そのため date +%Y%m%d のような書き方は途中で切れてしまいます。crontab の中では date +\%Y\%m\%d のように % の前に \ を付けるか、日付を作る処理をシェルスクリプトにまとめて、そのスクリプトを crontab から呼び出します。

cron 式チェッカー｜日本語訳・次の実行日時・日本時間・UTC 変換（GitHub Actions・EventBridge 対応）

cron 式チェッカーは、crontab・GitHub Actions・Kubernetes CronJob・AWS EventBridge・Spring の @Scheduled の cron 式を貼りつけるだけで、意味を日本語に訳し、次に動く日時を日本時間と UTC で一覧にする無料ツールです。GitHub Actions の schedule は UTC で読まれるため、日本時間の「平日 9:00」は「0 0 * * 1-5」になります。0〜8 時（日本時間）が前の日・前の曜日になる計算や、1行で書けないときの2行への分け方も自動で行い、変換前と変換後の実行時刻が一致するかまで確かめます。日と曜日を両方書くと「どちらか」になる、分を * にすると 1 時間に 60 回動く、*/7 が 7 分おきにならない、31 日指定で動かない月がある、EventBridge の ? の付け忘れや曜日の数字のずれ、crontab のコマンドの % のエスケープ忘れなどの落とし穴も知らせます。選ぶだけで cron 式を作るビルダーと、よく使う書き方の早見表つき。

1. cron 式を貼りつける

crontab の1行、GitHub Actions の YAML の行（- cron: '…'）、cron(…)、@Scheduled(cron = "…") をそのまま貼っても読めます。

どこで使う式？

cron 式（分時日月曜日）

例:

この式を読むタイムゾーン

2. 意味（日本語訳）

平日（月〜金）の 9:00（日本時間）

欄	書いた値	意味
分	0	0分
時	9	9時
日	*	すべての日
月	*	すべての月
曜日	1-5	平日（月〜金）

3. 次の実行日時

この式を日本時間で読んだときに動く日時を、日本時間と UTC で並べています。

次の実行日時を計算しています…

4. ほかの書き方に変換

同じ時刻に動くように、ほかのサービスの書き方に直しました。UTC で読まれる GitHub Actions と EventBridge のルールは、時差の分だけ時刻（と日付・曜日）をずらしています。

crontab（Linux）

CRON_TZ=Asia/Tokyo
0 9 * * 1-5 /path/to/command

crontab -e で開いて1行で書きます。CRON_TZ= は cronie（RHEL・Amazon Linux など）の書き方で、Ubuntu・Debian の cron では使えないため、サーバーのタイムゾーン（timedatectl で確認）を日本時間にしておくか、時刻をサーバーの時刻に直して書きます。

GitHub Actions（UTC に直した式）

on:
  schedule:
    - cron: '0 0 * * 1-5'
  workflow_dispatch:

GitHub Actions の cron は UTC で読まれるので、日本時間から 9 時間ずらしています。workflow_dispatch を足すと、Actions の画面から手動でも動かせます。

Kubernetes CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-job
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "Asia/Tokyo"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: job
              image: busybox
              command: ["sh", "-c", "echo hello"]

timeZone は Kubernetes 1.27 以降で使えます。書かないと kube-controller-manager のタイムゾーン（多くは UTC）で読まれます。

AWS EventBridge

# EventBridge Scheduler（タイムゾーンを指定できる）
aws scheduler create-schedule --name my-schedule \
  --schedule-expression "cron(0 9 ? * MON-FRI *)" \
  --schedule-expression-timezone "Asia/Tokyo" \
  --flexible-time-window Mode=OFF \
  --target '{"Arn":"arn:aws:lambda:ap-northeast-1:123456789012:function:my-func","RoleArn":"arn:aws:iam::123456789012:role/my-role"}'

# EventBridge のルール（UTC で読まれる）
ScheduleExpression: "cron(0 0 ? * MON-FRI *)"

EventBridge は「分時日月曜日年」の6つで、日か曜日のどちらかを ? にします。曜日の数字は 1 が日曜なので、MON-FRI のように英語で書いています。

Spring @Scheduled

@Scheduled(cron = "0 0 9 * * MON-FRI", zone = "Asia/Tokyo")
public void run() {
    // ...
}

Spring は先頭に「秒」があり、6つで書きます。zone を書かないとサーバー（JVM）のタイムゾーンで読まれます。

systemd timer（OnCalendar）

[Timer]
OnCalendar=Mon..Fri *-*-* 09:00:00 Asia/Tokyo
Persistent=true

# 書き方の確認: systemd-analyze calendar "Mon..Fri *-*-* 09:00:00 Asia/Tokyo"

Persistent=true にすると、電源が切れていて動かなかった分を起動したときに1回動かします（cron にはない機能）。

入力した cron 式とコマンドはこのブラウザに保存されるだけで、サーバーには送りません。次の実行日時はこの端末の時計をもとに計算しています。

ABOUT

cron 式チェッカー｜日本語訳・次の実行日時・日本時間・UTC 変換（GitHub Actions・EventBridge 対応）について

cron 式チェッカーは、crontab・GitHub Actions・Kubernetes CronJob・AWS EventBridge・Spring の @Scheduled で使う cron 式を貼りつけるだけで、「平日（月〜金）の 9:00」のように日本語に訳し、次に動く日時を日本時間と UTC で 10 件並べるツールです。GitHub Actions の schedule や EventBridge のルールは UTC で読まれるため、日本時間の時刻から 9 時間引き、0〜8 時（日本時間）は前の日・前の曜日にずらした式を自動で作ります。1行で書けないときは2行に分け、変換前と変換後の実行時刻が次の 40 回で一致するかまで確かめます。日と曜日を両方書くと「どちらか」の日に動く、分を * にすると 1 時間に 60 回動く、*/7 が 7 分おきにならない、31 日だけの指定で動かない月がある、EventBridge の ? の付け忘れ、crontab のコマンドの % のエスケープ忘れなど、よくある書き間違いも知らせます。選ぶだけで式を作るビルダー、systemd timer（OnCalendar）への書き換え、よく使う書き方の早見表つきです。

cron 式チェッカー｜日本語訳・次の実行日時・日本時間・UTC 変換（GitHub Actions・EventBridge 対応）の使い方

1「どこで使う式？」で crontab・GitHub Actions・Kubernetes・EventBridge・Spring のどれかを選ぶ
2cron 式を貼りつける（crontab の1行、YAML の - cron: '…' の行、cron(…) のままでもよい）
3「意味（日本語訳）」と欄ごとの説明、注意の一覧を確かめる
4「次の実行日時」で、日本時間と UTC の実行時刻・30 日の実行回数・間隔がそろっているかを見る
5「ほかの書き方に変換」から、GitHub Actions（UTC に直した式）や EventBridge・Kubernetes・Spring・systemd の書き方をコピーする
6式をゼロから作るときは「cron 式を作る」で、○分ごと・曜日・毎月○日・末日・第n○曜日を選ぶ

使いやすい場面

GitHub Actions の schedule を日本時間の朝 9 時に動かしたいが、UTC で何と書けばよいかわからない
既存のワークフローに書かれた UTC の cron が、日本時間で何時に動くのか知りたい
サーバーの crontab に書いたバッチが、次にいつ動くのかを確かめてから本番に入れたい
「0 0 13 * 5」のような日と曜日の両方を書いた式が、いつ動くのか確かめたい
AWS EventBridge の cron(…) で ? の付け方や曜日の数字（1 が日曜）がわからない
毎月の末日や第2火曜日に動かす書き方を、crontab と EventBridge・Spring で比べたい
Kubernetes の CronJob や Spring の @Scheduled、systemd timer に同じスケジュールを書き写したい

利用時のポイント

GitHub Actions の schedule は、どのリポジトリでも UTC で読まれます。日本時間（JST）は UTC より 9 時間進んでいるので、日本時間の 9:00 は UTC の 0:00、日本時間の月曜 8:00 は UTC の日曜 23:00 です。
GitHub Actions の schedule は最短 5 分ごとで、混んでいる時間（とくに毎時 0 分）は数分〜数十分遅れたり、まれに実行されなかったりします。公開リポジトリでは 60 日間リポジトリに動きがないと、スケジュールのワークフローが自動で止まります。
crontab で日と曜日の両方を * 以外にすると、「どちらか」に当てはまる日に動きます（man 5 crontab の仕様）。ただし片方が * で始まる（*/2 など）と「両方」の扱いになります。Spring の @Scheduled は「両方」、EventBridge は片方を必ず ? にします。
AWS EventBridge の cron は「分時日月曜日年」の 6 つで、曜日の数字は 1 が日曜・7 が土曜です（crontab は 0 か 7 が日曜）。L（末日）・W（近い平日）・#（第n○曜日）が使えます。ルールは UTC で、EventBridge Scheduler はタイムゾーンを指定できます。
次の実行日時は、選んだタイムゾーンでこの端末の時計から計算しています。夏時間のある地域（米国・英国）では、切り替えの日に存在しない時刻は飛ばして表示します。
入力した cron 式とコマンドは、このブラウザ（localStorage）に保存するだけで、サーバーには送りません。

こんなときに使えます

cron 式チェッカー｜日本語訳・次の実行日時・日本時間・UTC 変換（GitHub Actions・EventBridge 対応）は、次のような場面の答えになります。

GitHub Actions の cron を日本時間の朝 9 時に動かす書き方
cron 式を日本語に訳して、次にいつ動くか確かめたい
UTC で書かれた cron が日本時間で何時に動くか知りたい
cron で日と曜日を両方書いたらどうなるか
毎月末日や第2月曜日に cron を動かす書き方
AWS EventBridge の cron 式の書き方と ? の意味
crontab の 5 分おき・平日だけ・毎月1日の書き方
Kubernetes CronJob や Spring の @Scheduled を日本時間で動かしたい

よくある質問

GitHub Actions の cron を日本時間で動かすにはどう書きますか？: GitHub Actions の schedule は UTC で読まれるので、日本時間の時刻から 9 時間引いて書きます。日本時間の毎日 9:00 なら「0 0 * * *」、平日 9:00 なら「0 0 * * 1-5」です。日本時間の 0〜8 時は UTC では前の日になるため、平日 8:30 なら曜日も1つ前にずらして「30 23 * * 0-4」（日〜木の 23:30 UTC）にします。このツールの「日本時間と UTC の変換」に日本時間の式を入れると、ずらした式と次の実行日時を出します。
cron で日と曜日を両方指定するとどうなりますか？: crontab（Linux の cron）・GitHub Actions・Kubernetes では、日と曜日の両方を * 以外にすると「どちらかに当てはまる日」に動きます。たとえば「0 0 13 * 5」は 13 日の金曜日だけではなく、毎月 13 日と毎週金曜日の両方で動きます。「第1月曜日」のように両方を満たす日にしたいときは、日を 1-7 にしてコマンドの先頭で曜日を確かめるか、EventBridge・Spring の「MON#1」のような書き方を使います。
「* 9 * * *」と「0 9 * * *」は何が違いますか？: 「* 9 * * *」は分が * なので、9:00 から 9:59 まで 1 分ごとに 60 回動きます。毎日 9:00 に1回だけ動かしたいなら、分を 0 にした「0 9 * * *」が正解です。cron 式の書き間違いで一番多いもので、このツールでは注意として表示します。
毎月の末日に cron を動かすにはどうすればいいですか？: crontab と GitHub Actions には末日の書き方がないため、日を 28-31 にして、コマンドの先頭で「明日が1日か」を確かめます（例: 0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && コマンド）。crontab ではコマンドの中の % を \% と書く点に注意してください。AWS EventBridge なら cron(0 23 L * ? *)、Spring なら 0 0 23 L * * のように L で書けます。
「*/7」は 7 分おきになりますか？: なりません。「*/7」は毎時 0・7・14・21・28・35・42・49・56 分に動き、56 分の次は次の時の 0 分なので、そこだけ間隔が 4 分になります。60 を割り切れる数（1・2・3・4・5・6・10・12・15・20・30）なら間隔はそろいます。このツールの「実行の間隔」で、最短と最長の間隔を確かめられます。
AWS EventBridge の cron で「?」は何の意味ですか？: 「?」は「指定しない」という意味で、EventBridge では日（3 つ目）か曜日（5 つ目）のどちらかを必ず ? にします。毎日なら cron(0 9 * * ? *)、平日なら cron(0 9 ? * MON-FRI *) です。両方に値を書くとエラーになります。また EventBridge の曜日の数字は 1 が日曜なので、MON-FRI のように英語で書くと間違えにくくなります。
crontab のコマンドに date +%Y%m%d を書くと動かないのはなぜですか？: crontab では、コマンドの中の % が改行として扱われ、% から後ろは標準入力に回されます。そのため date +%Y%m%d のような書き方は途中で切れてしまいます。crontab の中では date +\%Y\%m\%d のように % の前に \ を付けるか、日付を作る処理をシェルスクリプトにまとめて、そのスクリプトを crontab から呼び出します。

ARTICLES

cron 式チェッカー｜日本語訳・次の実行日時・日本時間・UTC 変換（GitHub Actions・EventBridge 対応）の使い方ガイド

使い方ガイドGitHub Actions の cron を日本時間で動かす｜UTC 変換の早見表と曜日ずれ・遅延の対策GitHub Actions の schedule に「0 9 * * 1-5」と書いたのに、ワークフローが動いたのは日本時間の夕方 6 時だった。これは書き間違いではなく、GitHub Actions の cron が必ず UTC（協定世界時）で読まれるためです。この記事では、日本時間（JST）の時刻を UTC の cron 式に直す計算と早見表、朝 0〜8 時を指定したときに起きる「曜日・日付が前の日にずれる」問題、1 行で書けないときの 2 行への分け方、そして schedule が遅れる・動かないときの原因と対策までをまとめます。使い方ガイドcrontab の書き方と早見表｜5 つの欄と記号の意味・よく使う例・登録のコマンド「毎日 3 時にバックアップ」「5 分ごとに監視スクリプト」のような定期実行は、Linux では crontab に 1 行書くだけで設定できます。ただ、「分時日月曜日」の 5 つの欄と、* , - / という記号の組み合わせは、慣れないうちは読み間違えやすく、1 時間に 60 回動いてしまったり、7 分おきのつもりが 4 分おきになったりといった事故も起きがちです。この記事では、crontab の書き方の基本と記号の意味、そのまま使える早見表、crontab -e・-l・-r の使い方、コマンド部分を書くときの注意点までを、例を中心に解説します。仕組み解説cron の日と曜日は OR になる｜第 2 月曜・月末・最終金曜・隔週の正しい書き方「毎月第 1 月曜の 9 時」のつもりで「0 9 1-7 * 1」と書いたら、毎週月曜に加えて毎月 1〜7 日の毎日にも動いてしまった。cron でとても多いこの失敗は、日と曜日の両方を指定すると「どちらか」に当てはまる日に動くという、cron 独特のルールが原因です。この記事では、日と曜日が OR になる仕組みと例外、crontab で第 n 曜日・月末・最終金曜・隔週を正しく動かす書き方、AWS EventBridge や Spring で使える L・#・W の書き方までを、実際の実行日付の例つきで解説します。使い方ガイドEventBridge の cron 式の書き方｜? の意味・曜日の数字・日本時間の指定と crontab からの書き換えAWS で Lambda や ECS のタスクを定期実行するときに使う EventBridge の cron 式は、Linux の crontab と似ているようで、欄の数・? の使い方・曜日の数字・タイムゾーンが少しずつ違います。crontab の感覚で「0 9 * * 1-5」と書くとエラーになり、曜日の数字をそのまま移すと 1 日ずれ、時刻は UTC で読まれて 9 時間ずれる、とつまずきどころが重なります。この記事では、EventBridge の cron 式の 6 つの欄と ? のルール、曜日の数字、L・W・# の使い方、rate 式との違い、ルールと Scheduler での日本時間の扱い、crontab・Kubernetes・Spring・systemd との書き換え表までをまとめます。使い方ガイドcron が動かない原因チェックリスト｜手動では動くのに失敗する理由とログの確認方法crontab に書いたはずのバッチが動いていない。ターミナルで手で実行すると成功するのに、cron からだと何も起きない。cron のトラブルは、エラーがどこにも表示されないまま静かに失敗することが多く、原因を探すのに時間がかかりがちです。この記事では、cron が動かないときに確かめる順番を「式」「cron 本体」「ログ」「実行環境」「ファイルと権限」「タイムゾーン」に分けて整理し、手動では動くのに cron だと失敗する典型的な理由と、その直し方をまとめます。

Special Thanks

SOLO GUILD | サービス作るAIエンジニア

一覧に戻る