Cron表現実際の例を交えた実用的な参考書

掲載日 2026年4月22日

Cron表現は、Unixスケジューラがコマンドを実行するタイミングを示す5つのスペースで区切られたフィールドです。5つのフィールド、いくつかの特別な記号、そしていくつかの一般的なパターン——これがすべてのメンタルモデルです。この参考書は、文法、人々が誤解しやすい記号、および開発者が実際に使うスケジュールをカバーしています。

5つのフィールド

標準のCronは、次の5つの位置フィールドを使用します：

* * * * *
│ │ │ │ └─ Day of week   (0–7, Sunday = 0 or 7)
│ │ │ └─── Month         (1–12)
│ │ └───── Day of month  (1–31)
│ └─────── Hour          (0–23)
└───────── Minute        (0–59)

AWS EventBridgeおよびJavaのQuartzスケジューラは、先頭にフィールドを追加し、合計6フィールドになります。すべての他のフィールドが右にシフトします。これは、環境間で移動する開発者を混乱させます——Quartz表現を標準のcrontabに貼り付けると、警告なしに誤ったスケジュールで実行されます。秒 POSIXの5フィールドCronに従ってください。プラットフォームが明確に6フィールドを必要とする場合を除きます。

特別な記号

任意の値——すべての単位に一致

文字	意味	例
`*`	— 1分ごと	`* * * * *` — 9時と17時
`,`	値のリスト	`0 9,17 * * *` — 9時から17時の間の毎時間
`-`	範囲	`0 9-17 * * *` ステップ間隔
`/`	— 15分ごと	`/15 * * *` 特定の値なし（Quartz/AWSのみ）
`?`	— 月の15日、どの曜日でも	`0 0 15 * ?` 最終日（Quartz/AWSのみ）
`L`	— 月の最終日	`0 0 L * ?` 最も近い曜日（Quartz/AWSのみ）
`W`	— 15日から最も近い曜日	`0 0 15W * ?` 標準

のみ認識 crontab . 表現に見つかる場合は、QuartzまたはAWS EventBridge用に書かれたものであるため、Linuxのcrontabにそのまま貼り付けるべきではありません。 *, ,, -と、 /参考表：開発者が実際に使うスケジュール ?, L、または W これはブックマークに残す価値のある部分です。以下の表現を構築および検証できます。

IO Tools Cron表現生成器

生産環境ではほとんど適切ではありませんヘルスチェック、短いポーリングサイクル.

説明	Cron式	注記
毎分	`* * * * *`	キャッシュのウォームアップ、フィード同期
5分ごと	`/5 * * *`	30分ごと
15分ごと	`/15 * * *`	等価に
毎時間（時刻の0分）	`/30 * * *`	6時間ごと `0,30 * * * *`
データ同期、インクリメンタルエクスポート	`0 * * * *`	UTCの午前0時
標準的な毎日バッチトリガー	`0 /6 * *`	UTCの午前9時
朝のレポート生成	`0 0 * * *`	平日午前9時
ビジネス時間のみのジョブ（月～金）	`0 9 * * *`	午前8時30分の平日
スタンドアップ前のレポート配信	`0 9 * * 1-5`	毎週月曜日の午前2時
週間メンテナンス、オフピークバックアップ	`30 8 * * 1-5`	月の初日
月次請求処理、繰り返しレポート	`0 2 * * 0`	1月1日午前0時
年間リセット、年始ジョブ	`0 0 1 * *`	タイムゾーンの問題
Cronはタイムゾーン意識を持ちません。サーバーが設定されているタイムゾーンで実行されます——ほとんどのLinuxシステムではUTCです。これは通常問題ありませんが、ビジネス時間に関連するジョブや、複数地域にいるユーザーが「9時レポート」が2時まで到着する理由を理解できない場合があります。	`0 0 1 1 *`	最も安全なデフォルト設定：

サーバーをUTCに設定し、Cronスケジュールではなくアプリケーションロジックでローカルタイムに変換します。

すべてのCronジョブに実行されるローカルタイムをコメントを付けてください。次にそのcrontabを読む人があらゆる推測をしなくてもよいようにします。

クラウドスケジューラ（AWS EventBridge、Google Cloud Scheduler）を使用する場合、タイムゾーンフィールドを確認してください——ほとんどのものはIANAタイムゾーン名を直接サポートしており、曖昧さを解消します。

テスト：デプロイ前に次の実行時刻を計算する
Cronジョブをデプロイして、それが1分ごとではなく1時間ごとであることに気づくことは、多くの開発者の経験です。これをスキップします。
IO Tools Cron次の実行時刻計算機

# Always comment with the effective local time
# Runs daily at midnight UTC (= 8pm EST / 5pm PST)
0 0 * * * /usr/bin/python3 /opt/scripts/daily_report.py

あなたの表現が次の実行時刻を正確に示します——表現を貼り付けて、次の10回の実行時刻をサーバーに触れる前に確認できます。

コマンドラインでの検証：

の LinuxでのCronジョブの追加バックアップラインの終わりに`at`を追加することで、stderrをstdoutにリダイレクトし、両方をログファイルに記録します。これがないと、Cronエラーはメールスプールに記録され、誰も確認しません。

GitHub Actionsのスケジュールされたワークフロー

# Install croniter (Python) for quick expression testing
pip install croniter

python3 -c "
from croniter import croniter
from datetime import datetime

cron = croniter('*/15 * * * *', datetime.utcnow())
for _ in range(5):
    print(cron.get_next(datetime))
"

GitHub Actionsは、常にUTCで5フィールドのCron文法を使用します。タイムゾーンオーバーライドはありません。

# Open the crontab editor for the current user
crontab -e

# Format: minute hour day month weekday command
# Run backup script daily at 2:30am UTC
30 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

# Run a Python script every 5 minutes
*/5 * * * * /usr/bin/python3 /home/user/scripts/sync.py

# View current crontab entries
crontab -l

# Edit another user's crontab (requires root)
crontab -u www-data -e

の 2>&1 ただし、GitHub Actionsのスケジュールされたワークフローは、高負荷期間中に最大15分遅延することがあります。正確なタイミングが必要な場合は、それらに頼らないでください。

標準Cronが十分ではない場合

標準Cronは、1サーバー上のほとんどのケースを処理できます。その制限がスケールアップ時に問題になります：

name: Nightly Data Export

on:
  schedule:
    # Runs at 1:00 AM UTC every weekday
    - cron: "0 1 * * 1-5"
  workflow_dispatch: # Allow manual trigger

jobs:
  export:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run export script
        run: python scripts/export.py

失敗時のリトライ機能がない。

ジョブがクラッシュした場合、次の実行は次のスケジュール時刻になります——自動リトライはありません。

分散ロック機能がない。

同じcrontabを実行する複数のサーバーが同時に同じジョブを実行します。 観察機能がない。
実行履歴、失敗アラート、実行時間のトラッキングに組み込まれたダッシュボードはありません。 問題
より良い代替案 リトライロジックとタスクキュー

Celery Beat（Python）、Sidekiq-Cron（Ruby）	クラウドネイティブスケジューリングとリトライ
AWS EventBridge + Lambda、Google Cloud Scheduler	CI/CDパイプライントリガー
GitHub Actionsのスケジュール	観察可能なジョブオーケストレーション
Airflow、Prefect、Temporal	1サーバー上のスクリプトには、Cronがまだ正しいツールです——シンプルで信頼性があり、依存関係はありません。リトライ保証、分散実行、または失敗の可視性が必要な場合は、専用のタスクキューはすぐにコストを回収します。
次のスケジュールを構築するためには、文法を暗記せずに	Cron次の実行時刻計算機

それが期待されるタイミングで実行されることを確認できるようにします。

を使用して、よく使用されるヘッダーをデフォルト値とともに挿入します。認証セクションで認証タイプと認証情報を設定し、カスタムヘッダーを手動で追加します。curl、Postman、またはコードで使用するための完全なヘッダーセットをコピーします。 Cron式ジェネレータ Cron表現：実用的な参考書と実際の例 2 Cron表現：実用的な参考書と実際の例 1 それが期待されるときに発火することを確認する。