crontabの設定で「* * * * *」という5つの星（アスタリスク）は何を意味していますか？

左から順に「分、時、日、月、曜日」を指定しており、すべて「*」にすると毎分実行されます。例えば、毎日深夜3時に実行したい場合は「0 3 * * *」のように記述します。

cronに設定したコマンドがうまく実行されない（動かない）場合、何を確認すればよいですか？

コマンドや実行ファイルのパスを「/usr/bin/python3」のような「絶対パス」で記述しているか確認してください。cronは実行時の環境変数が通常のターミナルと異なるため、相対パスでは正しく動作しないことが多々あります。

設定したcronのスケジュールを変更したり、定期実行を一時的に停止したりするにはどうすればいいですか？

ターミナルで「crontab -e」を実行して設定ファイルを開き、該当する行を編集または行頭に「#」を付けてコメントアウトして保存してください。すべての設定を削除したい場合は「crontab -r」を使用しますが、一括で消去されるため注意が必要です。

cron で定期実行｜基礎を学ぶ

cron で定期実行とは

cronを設定し、コマンドを定期的に実行する方法をターミナルで体験します。本レッスンでは、cron で定期実行の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

なぜ重要か

「毎晩 3 時にバックアップを取りたい」「5 分おきにヘルスチェックを叩きたい」といった定期処理を Linux で行う定番が cron です。Web アプリのバッチ処理、ログローテーション、SSL 証明書の自動更新 (certbot)、データベースの定期メンテナンス、メトリクス収集など、運用の裏側はほとんど cron か、それを継承した systemd timer / Kubernetes CronJob で動いています。

cron 単体は古い仕組みですが、書式とトラブルパターンは現代の cron 系スケジューラ (GitHub Actions の schedule、Vercel Cron、Cloudflare Cron Triggers) でもそのまま流用されます。本レッスンでは crontab の書式、典型レシピ、デバッグの勘所、そして現代的な代替 (systemd timer / CronJob) との位置付けまで押さえます。

cron を一言でいうと「決めた時刻に決めたコマンドを自動で叩いてくれる目覚まし時計」です。書式は今どきのスケジューラにもそのまま通じます。

crontab の基本書式

ターミナル

# 分 時 日 月 曜 コマンド
*/5 *   *   *   *  /usr/local/bin/health-check.sh
0   3   *   *   *  /usr/local/bin/backup.sh
0   0   1   *   *  /usr/local/bin/monthly-report.sh

5 つのフィールドを左から「分・時・日・月・曜日」と読みます。* は任意、*/5 は 5 分おき、0,30 はカンマで複数指定、1-5 はハイフンで範囲、MON-FRI の英字略称も使えます。

フィールド	範囲	例
分	0-59	`*/5` で 5 分おき
時	0-23	`0,12` で 0 時と 12 時
日	1-31	`1` で毎月 1 日
月	1-12 または JAN-DEC	`*` で毎月
曜日	0-7 (0 と 7 が日曜) または SUN-SAT	`MON-FRI`

図解 cron の処理フロー

diagram (will load when visible)

crond は常駐デーモンで、毎分 crontab を読み、時刻が一致したエントリを子プロセスとして起動します。コマンドの標準出力と標準エラーは、デフォルトではローカルメールに送られ、配送設定がないと闇に消えるため、後述のリダイレクト指定が必要になります。

crontab の編集と確認

ターミナル

# 自分のユーザーの crontab を編集
crontab -e

# 一覧表示
crontab -l

# 全削除
crontab -r

システム全体の cron は /etc/crontab および /etc/cron.d/ 配下に置きます。こちらは 6 つ目のフィールドに実行ユーザー名が入る点だけ異なります。

代表例 1 5 分おきにヘルスチェック

ターミナル

*/5 * * * * curl -sf https://example.com/healthz > /dev/null || echo "down at $(date)" >> /var/log/health.log

-sf で 200 以外なら curl が非ゼロ終了し、|| の後の echo が走って失敗のみログに残ります。

代表例 2 毎日 3 時にバックアップ

ターミナル

0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

>> log 2>&1 はバッチでほぼ必須のイディオムで、標準出力と標準エラーを同じログにまとめます。これがないと出力先がメールになり、原因究明が困難になります。

代表例 3 月初に集計

ターミナル

0 0 1 * * /usr/local/bin/monthly-report.sh >> /var/log/report.log 2>&1

日=1 を指定すると月初 1 日のみに発火します。「毎月最終日」は cron 単体では表現しにくく、スクリプト側で日付チェックする方が確実です。

環境変数とパスの罠

cron の中では、ログインシェルで読まれる .bashrc や .profile が読まれません。PATH は最小限の /usr/bin:/bin 程度しか通っておらず、/usr/local/bin のコマンドが見つからない事故が頻発します。

対策の通例は次の通りです。

ターミナル

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOME=/root

0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

crontab の上部に環境変数を明示すると、各エントリで使えます。それでも不安なら、cron からは「シェルスクリプトを 1 本呼ぶだけ」にして、スクリプト側で source ~/.bashrc するのが安全です。

デバッグの定石

まずシェルで手動実行してから cron に乗せる
標準出力 / エラーを必ずファイルにリダイレクト
時刻のずれは TZ 環境変数で明示 (例: TZ=Asia/Tokyo)
grep CRON /var/log/syslog で cron の起動ログを確認 (Debian 系)
5 分おきのジョブで動作確認するには */1 (毎分) で短時間試す

systemd timer という現代的代替

ターミナル

# /etc/systemd/system/backup.timer
[Unit]
Description=Daily backup

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

対応する backup.service を別ファイルで定義し、systemctl enable --now backup.timer で有効化します。journald にログが集約され、Persistent=true で「停止中にスキップされたジョブを起動後に追いかける」挙動が選べる等、cron より強力です。

本番サーバー単体で動かす定期処理は systemd timer、コンテナや Kubernetes で動かすなら CronJob、サーバーレスなら GitHub Actions schedule や Cloud Scheduler、というふうに環境ごとの定番を選び分けるのが現代的です。crontab の知識はその基礎になります。

Kubernetes CronJob との対応

YAML

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup
              image: backup:latest
          restartPolicy: OnFailure

schedule フィールドは crontab とまったく同じ書式です。これが分かると Kubernetes へ移植する際の学習コストがほぼゼロになります。

よくある間違い

PATH の通っていないコマンドを直に書いて動かない
標準出力をリダイレクトせず、結果が闇に消える
曜日と日の両方を指定して、意図せず OR で発火する
TZ 未設定で UTC のまま動く (本番では Asia/Tokyo を明示)
crontab -e でファイル末尾に改行がなく、最後の行が無視される

やってみよう

このレッスンは executor 上では実走できないため、手元の Linux / Mac で次を試すのがおすすめです。

crontab -e で */1 * * * * date >> /tmp/cron.log を入れて 2-3 分待つ
cat /tmp/cron.log で記録を確認
終わったら crontab -r または該当行を削除

まとめ

crontab は 5 フィールドで「分時日月曜」を表す書式
cron は最小 PATH で動くため、PATH / SHELL / TZ を明示するのが安全
出力は >> log 2>&1 でファイルに集約する
現代的には systemd timer や Kubernetes CronJob を使うことが多いが、書式は crontab 互換
動作確認は毎分実行で短く回し、安定したら本来の間隔に戻す

次のレッスン

次は 開発環境での Linux 活用例 で、cronを設定し、コマンドを定期的に実行する方法をターミナルで体験しますを学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

cron の要点を自分の言葉で説明できる
このレッスンの最小コード (または操作手順) を見ずに書ける
練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. cron とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン