Cron Jst Intro
・対象: 初心者,中級者
title: CronとJSTの落とし穴入門 date: 2025-09-01 author: site-admin published: false robots: 'noindex,follow' tags:
- internal
- archived description: JSTとUTCのズレ、夏時間非対応、曜日と日付条件の優先関係など、cron運用で詰まりやすい要点を最速で把握するための入門ガイド。設計と検証のコツも簡潔に整理します。
対象読者: cron を JST 前提で運用する SRE/開発者。
この記事で得られること: JST/UTC のズレや DOM×DOW の仕様差異を短時間で把握し、安全に設計・検証する手順が分かります。
なぜ JST で cron を検証する必要があるのか
多くの SaaS や CI/CD サービスは内部的に UTC で動いていますが、ビジネス要件は JST（日本時間）で定義されることが多く、「毎月 1 日 0:00 JST」 のような表現がそのまま 0 0 1 * * として投入されます。このとき、夏時間 (DST) が無いという前提に安心しすぎて以下のような見落としが生まれます。
- 実際にはサーバは UTC → フロント表示だけ JST 換算
- ローカル検証時に
cronライブラリがデフォルトタイムゾーンを使用 - CI 上のスケジュールは UTC 計算で 9 時間ズレ
DOM と DOW の同時指定
cron 実装はベンダ差異が発生しやすい領域です。とくに「日 (DOM)」と「曜日 (DOW)」を同時指定した場合に、OR なのか AND なのかは仕様依存です。本サイトのツールではモード切替 (OR / AND) を明示化し、混乱を減らします。
| 例 | OR モード動作 | AND モード動作 |
|---|---|---|
0 9 1 * 1 | 1 日 または 月曜の 09:00 | 1 日 かつ 月曜の 09:00 |
推奨ワークフロー
- まずビジネス要件を自然言語で箇条書きにする
- JST 基準で期待する次回実行日時を 3〜5 ケース書き出す
- ツールに cron 式を入れて結果が一致するか確認
- CI/クラウド側に設定する際は UTC 換算差異をコメント化
まとめ
- JST 要件でも内部は UTC のことが多い
- DOM/DOW 同時指定は仕様差異を確認
- ツールで目視検証を自動化しヒューマンエラーを減らす
# 最小例（JSTで毎月1日9:00想定）
0 9 1 * 1