BlueprintLab Guide

Cron式が環境によって違う理由――「式は合ってるのに動かない」を減らす見方

Cronは短く書けるぶん、環境差が見えにくい仕組みです。フィールド数、曜日、タイムゾーンを順番に見ると、かなり切り分けやすくなります。

Cron式をコピーして本番へ入れる前に、同じ実行環境のテストジョブで次回実行時刻を確認してください。特にUTC基準のサービスでは、式が正しくても期待時刻とずれることがあります。

同じCron式なのに、片方では動いて片方では動かない

`0 9 * * 1-5`。見慣れてくると「平日の9時ね」と読めます。ところが、これを別のサービスへ貼ったら動かない。あるいは、動いたけれど日本時間の18時だった。Cronでは、こういうことが普通に起こります。

式そのものが間違っているとは限らないんですよ。Cronにはいくつかの“方言”があって、Linuxのcrontab、Quartz系、CIサービスなどでルールが少しずつ違います。まずは式より先に「どのCronなのか」を確認すると話が早くなります。

一般的なcrontabは「分・時・日・月・曜日」の5フィールドです。一方で、秒を先頭に足す6フィールド、さらに年まで持つ7フィールドの実装もあります。

ここを見落とすと、数字は全部正しく見えるのに意味が一つずつ横へずれます。Cron式をネットからコピーしたときほど、最初にスペースで何個に分かれているか数えてみるといいんです。

日曜日を0とするのか7とするのか、両方使えるのか。`MON-FRI`のような名前を使えるのか。`?`、`L`、`#`のような拡張記号が使えるのか。ここも実装で変わります。

「毎月最終日」を`L`で書ける環境もありますが、一般的なcrontabではそのまま使えないことがあります。便利そうな記号を見つけたら、まず実行先のドキュメントで使えるかを見るのが安全です。

Cronで一番ありがちな“動いてるけど違う”は、タイムゾーンです。サービス側がUTCで動いていると、日本時間9時のつもりで書いた式が18時に見える、といったズレが出ます。

さらに夏時間のある地域では、存在しない時刻や1日に2回来る時刻もあります。毎日決まったローカル時刻に動かしたい処理は、Cron式だけでなく実行環境のタイムゾーン設定までセットで確認します。

Cronは「式を読める」より「次にいつ動くかを具体的な日時で見られる」方が確認しやすいです。BlueprintLabのCron式生成・解析では次回実行候補を出せるので、月末や曜日またぎの式ほどここを見ておくと安心です。

最後は、同じ実行環境で小さなテストジョブを1回動かします。Cronは短い式なので、目視だけで安心しやすいのがむしろ落とし穴なんですよ。

式を見て混乱したら、全部の記号を覚える必要はありません。まずフィールド数、実行環境のタイムゾーン、使っているCronの種類。この3つを確認します。

それでも合わなければ、次回実行時刻を具体的な日時で出してみます。「毎週月曜9時」という言葉より、`2026-09-14 09:00 JST`の方がずれに気付きやすいんです。