cron式の書き方と、定期実行で失敗しないためのポイント

バッチ処理やバックアップ、レポート送信など、決まった時刻にプログラムを自動実行する仕組みとして、cron（クーロン）は長く使われてきました。
Linuxのcrontabだけでなく、クラウドのスケジューラーやCIサービスでも、同じ「cron式」で実行時刻を指定できます。
この記事では、cron式の書き方と、運用で失敗しやすいポイントを解説します。

cron式の基本：5つのフィールド

標準的なcron式は、空白で区切られた5つのフィールドで構成されます。

分　時　日　月　曜日

使える記号

• *：すべての値（毎分、毎時など）
• ,：複数の値を列挙（例：0,30 は0分と30分）
• -：範囲（例：1-5 は1〜5）
• /：間隔（例：*/15 は15ごと）

よく使う記述例

運用で失敗しやすいポイント

1. タイムゾーン

cronはサーバーやサービスに設定されたタイムゾーンで動きます。
クラウドのスケジューラーやコンテナでは、既定がUTCになっていることが多く、日本時間（JST、UTC+9）の感覚で設定すると9時間ずれます。
「毎朝9時（JST）」にしたいなら、UTCでは0時です。
タイムゾーンを指定できるサービスでは、明示的に Asia/Tokyo を設定すると安全です。

2. 「日」と「曜日」の両方を指定したときの挙動

伝統的なcronでは、日と曜日の両方に * 以外を指定すると、「どちらかに一致すれば実行」（OR条件）になります。
たとえば 0 9 13 * 5 は「13日」または「金曜日」に実行され、「13日の金曜日」だけではありません。
実装によって挙動が違う場合があるため、使用するサービスの仕様を確認してください。

3. 実行時間が間隔より長くなる

5分ごとの処理に10分かかると、前の処理が終わる前に次が始まり、重複実行になります。
データの二重更新やリソース枯渇の原因になるため、ロックの取得や、実行中は起動しない制御を入れておきましょう。

4. 時刻が集中する

多くの人が「毎時0分」「毎日0時」に設定するため、外部APIやサーバーの負荷が集中しがちです。
処理に厳密な時刻の指定が不要なら、7 * * * * のように少しずらすと、負荷分散になります。

5. 失敗に気付けない

cronは、実行が失敗しても通知してくれません。
ログの保存先を決める、失敗時に通知する、監視サービスで「実行されたこと」を確認する、といった仕組みを用意しておくことが大切です。

6. 環境変数とパス

cronから実行されるシェルは、ログイン時の環境変数を引き継ぎません。
コマンドは絶対パスで書く、必要な環境変数はcrontabや実行スクリプトの中で設定する、といった対応が必要です。

書いたcron式を確認する

cron式は一見して分かりにくく、書き間違いに気づきにくいものです。
設定する前に、「次回の実行時刻」を一覧で確認できるツールを使えば、意図どおりに動くかを事前に検証できます。

まとめ

cron式自体は5つのフィールドと数個の記号だけの単純な書式ですが、運用ではタイムゾーン、重複実行、失敗の検知といった点が問題になります。
式を書いたら次回実行時刻を確認し、ログと通知を整えておくことを習慣にしましょう。