cronの基本｜定期実行の仕組みと設定方法を解説
cronを使うと、決まった時刻にコマンドやスクリプトを自動実行できます。毎朝のバックアップ、ログ削除、データ取得、定期通知のような処理を、人が毎回手で起動しなくて済むのが大きな利点です。
特にLinuxサーバーや開発環境では、まず覚えたい定期実行の基本です。この記事では、cronの仕組み、crontab の書き方、実務でそのまま流用しやすい最小例、つまずきやすい点まで順に整理します。
- cronは「定期実行する仕組み」、
crontabは「実行予定を書く設定ファイル」です - 基本書式は
分 時 日 月 曜日 コマンド - 個人の定期処理は
crontab -eで設定するのが基本です - 相対パス、PATH不足、出力未保存 は初心者が詰まりやすい代表例です
- systemd環境では、用途によっては
systemd timerの方が向く場合もあります
ここがポイント: cronは難しい仕組みではありません。まずは「1分ごとにログへ日時を書き出す」ような小さなジョブで動作確認すると、設定ミスを切り分けやすくなります。
cronとは何か
cronは、Unix系OSで長く使われてきた定期実行の仕組みです。cronデーモンが設定を見張り、条件に合う時刻になると指定したコマンドを実行します。crontab(5) でも、crontabは「この時刻にこのコマンドを実行する」という指示を書くファイルとして説明されています。
ここで区別したいのは次の2つです。
cron: 定期実行を担当する仕組みそのものcrontab: 実行スケジュールを書く設定
実務では、ユーザー単位の定期処理なら crontab -e で設定する場面が多く、システム全体のジョブでは /etc/crontab や /etc/cron.d/ を使うことがあります。後者はユーザー名欄が追加で必要になる点が違いです。
何ができるか、どんな場面で使うか
cronが向くのは、時刻や間隔が明確な繰り返し処理です。
- 毎日深夜にバックアップを取る
- 毎時ごとにAPIからデータを取得する
- 古いログや一時ファイルを削除する
- 定期レポートをCSVで出力する
- 監視用スクリプトを数分ごとに実行する
逆に、サーバーが止まっていた間の取りこぼしを後で確実に補完したい処理や、サービスとして細かく管理したい処理では、後述する systemd timer が向くことがあります。
前提環境と確認しておきたいこと
まずは対象環境を押さえます。この記事の説明は、LinuxやUnix系OSで一般的なVixie cron/Cronie系の書式を前提にしています。
確認ポイントは次の通りです。
- OS: Linux系サーバー、WSL、一部のUnix系環境
- 利用コマンド:
crontab -ecrontab -l - 書式: 5つの時刻フィールド + コマンド
- 実行タイミング: cronは通常、設定を毎分確認します
crontab(5) では、cronはエントリを毎分確認すると案内されています。また、crontab(1) では -e で編集、-l で一覧表示、-r で削除できると定義されています。
cronの基本書式
cronの基本形は次の1行です。
* * * * * command
左から順に意味はこうなります。
分 時 日 月 曜日 コマンド
代表的な範囲は以下です。
- 分:
0-59 - 時:
0-23 - 日:
1-31 - 月:
1-12 - 曜日:
0-7（0と7は日曜日）
よく使う記号
*: すべて,: 列挙-: 範囲/: 間隔
例をまとめるとこうなります。
0 9 * * *: 毎日9:00*/10 * * * *: 10分ごと0 1 * * 1-5: 平日1:0030 8 1 * *: 毎月1日8:30
day of month と day of week の注意
ここは見落としやすい点です。crontab(5) では、日と曜日の両方を制限した場合、どちらか一方が一致すれば実行される動作が説明されています。
たとえば次の設定です。
30 4 1,15 * 5 /path/to/script.sh
これは「毎月1日と15日」か「毎週金曜」のどちらかに当てはまれば実行されます。AND ではなく、実質的に OR と考える方が誤解が少ないです。
設定方法
まずは現在の設定確認から始めます。
crontab -l
新規作成または編集は次です。
crontab -e
保存して閉じると反映されます。crontab(1) でも、編集終了後に自動でインストールされると説明されています。
最初の動作確認に向いた例
まずは、毎分ログへ現在時刻を書き出すだけの簡単なジョブを入れるのが安全です。
* * * * * /bin/date >> /tmp/cron-test.log 2>&1
これなら確認が速く、標準出力と標準エラーを両方ログに残せます。
確認は次の流れです。
crontab -eで上の1行を保存する- 1〜2分待つ
/tmp/cron-test.logを開く
出力例は次のようになります。
Tue Apr 21 14:32:00 JST 2026
Tue Apr 21 14:33:00 JST 2026
この確認が通れば、cron自体は動いていると判断しやすくなります。
実務で使う基本例
ここからは、実際に使われやすい設定を短く見ていきます。
毎日深夜2時にバックアップ
0 2 * * * /home/app/bin/backup.sh >> /home/app/logs/backup.log 2>&1
向いている場面:
- DBダンプ
- ファイル退避
- 日次集計の出力
10分ごとにAPIデータを取得
*/10 * * * * /usr/bin/python3 /home/app/jobs/fetch_data.py >> /home/app/logs/fetch.log 2>&1
向いている場面:
- 社内ダッシュボード用の定期取得
- 売上や在庫の定期更新
- 外部サービスの状態確認
平日だけレポートを出力
0 8 * * 1-5 /home/app/bin/report.sh >> /home/app/logs/report.log 2>&1
向いている場面:
- 朝の定例レポート
- 営業日だけ必要なCSV生成
- Slackやメール通知の下準備
スクリプトと組み合わせる書き方
cronでは1行に長い処理を直接書くより、処理本体はスクリプトに分けて、cronからはそのスクリプトを呼ぶ方が保守しやすくなります。
たとえば backup.sh を用意します。
#!/bin/bash
set -eu
mkdir -p /home/app/backup
cp /home/app/data/orders.csv /home/app/backup/orders-$(date +\%F).csv
cron側は短くします。
0 2 * * * /home/app/bin/backup.sh >> /home/app/logs/backup.log 2>&1
この形にすると、次の利点があります。
- 処理内容の見通しがよい
- 手動実行でテストしやすい
- cron特有の書式ミスと、スクリプト自体のバグを切り分けやすい
よくある失敗と対処
cronが「動かない」と感じる原因は、書式そのものより実行環境の違いにあることが多いです。
相対パスを使っている
NG例:
0 2 * * * python3 jobs/fetch_data.py
改善例:
0 2 * * * /usr/bin/python3 /home/app/jobs/fetch_data.py
cronでは、普段のシェルと同じカレントディレクトリを期待しない方が安全です。コマンドもファイルも絶対パスで書くのが基本です。
PATHが足りずコマンドが見つからない
対話シェルでは通るのにcronでは失敗する典型例です。crontab(5) でも、cronは限定的な環境変数で動くことが説明されています。
対策:
/usr/bin/python3のようにフルパスを書く- 必要なら
PATH=をcrontabで明示する
例:
PATH=/usr/local/bin:/usr/bin:/bin
0 2 * * * /usr/bin/python3 /home/app/jobs/fetch_data.py
実行権限がない
シェルスクリプトを呼ぶなら、実行権限を忘れないようにします。
chmod +x /home/app/bin/backup.sh
また、cronはそのcrontabを持つユーザー権限で動くため、参照先ファイルや出力先ディレクトリの権限も確認が必要です。
ログを残していない
エラー時に手がかりが消えるので、最初は出力先を付けた方が安全です。
*/5 * * * * /home/app/bin/job.sh >> /home/app/logs/job.log 2>&1
最低限、次のどちらかは入れておくと切り分けが速くなります。
- 標準出力と標準エラーをログへ保存する
- スクリプト内で開始時刻や終了時刻を記録する
改行不足やコメント位置のミス
crontab(5) では、最後の行が改行で終わっていないと問題になる場合があると案内されています。また、行末コメントはコマンドの一部として扱われることがあるため、コメントは単独行に分ける方が安全です。
夏時間や時刻変更の影響
crontab(5) では、夏時間の切り替え時に存在しない時刻は実行されず、逆に同じ時刻が2回現れる場合はジョブも2回走る可能性があると説明されています。
毎日2:30実行のような設定は、環境によってはこの影響を受けます。重要な処理なら、タイムゾーンや実行時刻の設計も確認しておくべきです。
ニックネーム指定も使える
Cronie系では、5フィールドの代わりに短縮記法も使えます。
@reboot: 起動時に1回@yearly: 年1回@monthly: 月1回@weekly: 週1回@daily: 日1回@hourly: 1時間ごと
例:
@reboot /home/app/bin/startup-check.sh >> /home/app/logs/startup.log 2>&1
毎日0時のように時刻を細かく指定したいなら通常の5フィールドの方が分かりやすいですが、意味が明確な定期処理では短縮記法も便利です。
systemd timerとの違い
最近のLinuxでは、cronの代わりに systemd timer を使う選択肢もあります。freedesktop.org の systemd.timer マニュアルでは、タイマー設定で対応する .service を起動する仕組みが説明されています。
ざっくりした使い分けは次の通りです。
- cron: 手早く定期実行したい
- systemd timer: サービス管理と一体で扱いたい
- systemd timer: 停止中に逃した実行を
Persistent=で補完したい
特に、ノートPCや再起動があるサーバーで「止まっていた間に実行できなかった分も後で拾いたい」なら、cronより systemd timer の方が適することがあります。
まず覚えたい最小チェックリスト
設定前後で、ここだけ確認すると失敗を減らせます。
crontab -lで現在の設定を見るcrontab -eで追加する- 最初は
/bin/dateなどの小さなジョブで試す - コマンドとファイルは絶対パスで書く
- ログ出力を付ける
- 手動実行でも同じスクリプトが動くか確認する
まとめ
cronは、時刻ベースの自動化を最短で始めるための基本ツールです。書式自体は単純ですが、実際に差が出るのは「絶対パス」「ログ保存」「権限確認」を最初から入れるかどうかです。
毎日1回のバックアップや10分ごとのデータ取得のような定番処理なら、まずcronで十分です。一方で、取りこぼし補完やサービス管理まで含めて設計したいなら、次に systemd timer を比較すると判断しやすくなります。