Linuxサーバーの運用では、定期的なメンテナンス作業を自動化することが安定運用の基本です。
この記事では、Linuxのジョブスケジューリング（cronとatコマンド）を体系的に解説します。
crontabの5フィールドの書き方・システムcrontab・/etc/cron.d/・環境変数設定、
crontab -rの危険性とバックアップ手順、さらにcronの現代的な代替手段であるsystemd timerの使い方まで、実務で使えるノウハウを網羅しています。この記事のポイント
・cronは「分 時 日 月 曜日 コマンド」の5フィールドで定期実行を設定する
・crontab -rは全設定を削除する危険コマンド。必ずバックアップを取ること
・cronの環境変数はシェルと異なる。PATH/LANGは明示的に設定が必要
・1回限りはatコマンド。現代的代替としてsystemd timerも有効
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
cronとは？定期ジョブ自動化の仕組み
cronは、Linuxで定期的なジョブ実行を管理するシステムです。crond（cronデーモン）が1分ごとに起動し、crontabファイルを読み込んで実行すべきジョブがあれば実行します。バックアップ、ログのローテーション、ウイルススキャン、DBのクリーニングなど、
「定期的に動かしておきたい処理」はすべてcronで自動化できます。
ジョブスケジューリングの全体像は以下のとおりです。
| ツール | 用途 | 設定場所 |
|---|---|---|
| cron | 定期的（毎分・毎時・毎日等）に繰り返す処理 | crontabファイル |
| at | 指定した時刻に1回だけ実行する処理 | atコマンドで設定 |
| anacron | 電源OFFが多い環境でも確実に実行（日次・週次・月次） | /etc/anacrontab |
| systemd timer | cronの現代的代替。journalctlでログを一元管理できる | .timerユニットファイル |
crontabコマンドの使い方
ユーザーのcrontabファイルは/var/spool/cron/ディレクトリ配下に保存されます。例えばmiyazakiユーザーなら
/var/spool/cron/miyazakiというファイルになります。このファイルを編集するには、crontabコマンドを使います（直接viで編集しない）。
1. crontabコマンドの主要オプション
| オプション | 意味 | 注意 |
|---|---|---|
| crontab -e | エディタでcrontabを編集する | 保存時にsyntaxチェックが入る |
| crontab -l | 設定中のcronジョブを一覧表示 | 確認専用 |
| crontab -r | crontabファイルを丸ごと削除 | 【危険】確認なしで即削除 |
| crontab -u ユーザー名 | 指定ユーザーのcrontabを操作（root専用） | 一般ユーザーはエラー |
2. crontab -eで編集する（基本操作）
# crontabを編集（viエディタが開く） $ crontab -e # 現在の設定を確認 $ crontab -l 0 1 * * * /var/www/system/backup.sh 30 9 * * 1-5 /usr/local/bin/report.sh # rootとして別ユーザーのcrontabを確認 $ sudo crontab -u apache -l
3. crontab -rは絶対に間違えない【重要】
【重要】crontab -rは全cronジョブを確認なしで削除する危険なコマンドです。crontab -eと打ち間違えると、すべての設定が消えてしまいます。削除前のバックアップ手順を習慣にしてください。
# crontabのバックアップ（削除前に必ず実行） $ crontab -l > ~/crontab_backup_$(date +%Y%m%d).txt # バックアップを確認 $ cat ~/crontab_backup_20260407.txt 0 1 * * * /var/www/system/backup.sh # 誤ってcrontab -rで削除してしまった場合の復元 $ crontab ~/crontab_backup_20260407.txt $ crontab -l 0 1 * * * /var/www/system/backup.sh
EDITOR環境変数にviを設定していると、-eと-rをタイプミスするリスクがあります。重要なサーバーでは、crontabファイルをgitやNASでバージョン管理することを強くお勧めします。
crontabファイルの5フィールド詳解
crontabの書式は「分 時 日 月 曜日 コマンド」の6要素で構成されます。1. 各フィールドの値の範囲
| フィールド | 値の範囲 | 補足 |
|---|---|---|
| 分 | 0～59 | *で毎分 |
| 時 | 0～23 | *で毎時 |
| 日 | 1～31 | *で毎日 |
| 月 | 1～12（またはjan～dec） | *で毎月 |
| 曜日 | 0～7（0と7が日曜）またはsun～sat | *で毎日 |
| コマンド | 実行するコマンドまたはスクリプト | フルパスを推奨 |
2. crontab書式の実例集
# 毎日午前1時に実行 0 1 * * * /var/www/system/backup.sh # 毎時間の30分に実行（0:30, 1:30, 2:30...） 30 * * * * /usr/local/bin/healthcheck.sh # 月曜日から金曜日（平日）の9時に実行 0 9 * * 1-5 /usr/local/bin/weekday_report.sh # 月曜日の9時と12時に実行（カンマで複数指定） 0 9,12 * * 1 /usr/local/bin/report.sh # 2時間ごとに実行（*/2 = ステップ指定） 0 */2 * * * /usr/local/bin/monitor.sh # 毎月1日の深夜0時に実行 0 0 1 * * /usr/local/bin/monthly_cleanup.sh # 毎年1月1日0時に実行 0 0 1 1 * /usr/local/bin/yearly_report.sh # 10分ごとに実行 */10 * * * * /usr/local/bin/check.sh # 毎朝9時から17時の間、1時間ごとに実行 0 9-17 * * * /usr/local/bin/business_hours_check.sh
cronの環境変数設定（実務で必須の知識）
cronジョブはシェルのログイン環境を引き継ぎません。これが「手動実行は動くのに、cronだと動かない」という最もよくあるトラブルの原因です。
1. cronの環境変数を設定する
# crontab -e で開いたファイルの冒頭に環境変数を設定する SHELL=/bin/bash PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin LANG=ja_JP.UTF-8 MAILTO=root # 実行するジョブ 0 1 * * * /var/www/system/backup.sh >> /var/log/backup.log 2>&1
MAILTO=rootは、cronジョブが標準出力や標準エラー出力を生成した場合にrootにメール送信します。メールを送らない場合は
MAILTO=""にするか、ジョブの末尾に>> /dev/null 2>&1を追記してください。2. スクリプト内でPATHを明示する方法
#!/bin/bash # cronから実行されるスクリプトの冒頭 export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin export LANG=ja_JP.UTF-8 export HOME=/root # 以降の処理... echo "バックアップ開始: $(date)" rsync -av /data/ /backup/
システムcrontabと/etc/cron.d/
ユーザーのcrontabとは別に、システム全体のcrontabも存在します。1. /etc/crontabの構造
/etc/crontabはシステム管理者が使うcrontabファイルです。ユーザーのcrontabと異なり、「実行ユーザー」を指定するフィールドが追加されています。
# /etc/crontabの書式（ユーザー名フィールドが追加） # 分 時 日 月 曜日 ユーザー コマンド SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # 1時間ごとにcron.hourlyを実行 01 * * * * root run-parts /etc/cron.hourly # 毎日4:02にcron.dailyを実行 02 4 * * * root run-parts /etc/cron.daily # 毎週日曜4:22にcron.weeklyを実行 22 4 * * 0 root run-parts /etc/cron.weekly # 毎月1日4:42にcron.monthlyを実行 42 4 1 * * root run-parts /etc/cron.monthly
2. /etc/cron.d/ ディレクトリの活用
/etc/cron.d/はシステムサービスやパッケージが独自のcron設定を置くディレクトリです。/etc/crontabと同じ書式（ユーザー名フィールドあり）で書きます。# /etc/cron.d/ にファイルを作成する例 $ sudo vi /etc/cron.d/myapp_cleanup # ファイルの内容（/etc/crontabと同じ書式） SHELL=/bin/bash PATH=/usr/local/bin:/usr/bin:/bin 0 3 * * * webapp /opt/myapp/cleanup.sh >> /var/log/myapp_cleanup.log 2>&1 # 権限を644に設定（実行権限は不要） $ sudo chmod 644 /etc/cron.d/myapp_cleanup
/etc/cron.d/内のファイルは644の権限である必要があります。書き込み可能だとcrondがそのファイルを無視するので、作成後に必ずパーミッションを確認してください。
3. cron.daily / weekly / monthly の活用
/etc/cron.daily/にスクリプトを置くだけで、毎日自動実行されます。cronの書式を覚えなくても使える便利な方法です。
# cron.dailyにスクリプトを配置する例 $ sudo vi /etc/cron.daily/db_backup #!/bin/bash export PATH=/usr/bin:/bin mysqldump -u root mydb > /backup/mydb_$(date +%Y%m%d).sql # 実行権限を付与（必須） $ sudo chmod +x /etc/cron.daily/db_backup # 手動でcron.daily全体を実行してテストする $ sudo run-parts /etc/cron.daily
atコマンドで1回限りのジョブを実行する
atコマンドは、指定した時刻に1回だけジョブを実行するツールです。「このサーバーを深夜2時に再起動したい」「明日の朝9時にレポートを送りたい」という場合に使います。
1. atコマンドの基本的な使い方
# atコマンドをインストール（RHEL9/Rocky9の場合） $ sudo dnf install at -y $ sudo systemctl enable --now atd # 今夜22:00にスクリプトを実行する $ at 22:00 at> /opt/scripts/nightly_backup.sh at> （Ctrl+D で確定） job 1 at 2026-04-07 22:00 # 3時間後に実行する $ at now + 3 hours at> /opt/scripts/delayed_task.sh at> （Ctrl+D） # 明日の9:30に実行する $ at 9:30 tomorrow at> /opt/scripts/morning_report.sh at> （Ctrl+D） # スケジュール済みのジョブを確認 $ atq 1 2026-04-07 22:00 a miyazaki 2 2026-04-08 09:30 a miyazaki # ジョブをキャンセル（ジョブ番号を指定） $ atrm 1
systemd timerでcronを代替する
RHEL 9・Rocky Linux 9・Ubuntu 22.04以降の環境では、cronの代替としてsystemd timerを使う選択肢があります。cronと比べて、実行ログをjournalctlで一元管理できること、停止中にスキップしたジョブを起動後に自動補完する機能（
Persistent=true）が大きな強みです。1. cronとsystemd timerの比較
| 比較項目 | cron | systemd timer |
|---|---|---|
| 設定ファイル | crontabファイル（1ファイル） | .timer + .service（2ファイル） |
| ログ確認 | /var/log/cron をgrepして確認 | journalctl -u サービス名 で確認 |
| 停止中のジョブ | 停止期間中はスキップされる | Persistent=trueで起動後に補完実行 |
| 依存関係設定 | 設定できない | After=で依存サービスを指定可能 |
| 一覧確認 | crontab -l で確認 | systemctl list-timers --all で確認 |
2. .serviceファイルと.timerファイルを作成する
systemd timerは、実行するコマンドを定義した.serviceファイルと、実行タイミングを定義した.timerファイルをペアで作成します。# /etc/systemd/system/mybackup.service [Unit] Description=My Backup Job After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/mybackup.sh User=root StandardOutput=journal StandardError=journal
# /etc/systemd/system/mybackup.timer [Unit] Description=Run mybackup.service every day at 02:00 [Timer] OnCalendar=*-*-* 02:00:00 AccuracySec=1s Persistent=true [Install] WantedBy=timers.target
・OnCalendar=*-*-* 02:00:00：毎日02:00に実行（cronの
0 2 * * *と同等）・AccuracySec=1s：デフォルトは最大1分の誤差があるため、cronに近い精度が必要な場合は1sを指定する
・Persistent=true：タイマーが停止していた期間にスキップしたジョブを、次回起動時に実行する
3. タイマーを有効化・起動する
# systemdに新しいユニットファイルを読み込ませる $ sudo systemctl daemon-reload # タイマーを有効化（OS再起動後も自動で起動） $ sudo systemctl enable mybackup.timer # タイマーを今すぐ起動 $ sudo systemctl start mybackup.timer # タイマーの状態確認 $ sudo systemctl status mybackup.timer * mybackup.timer - Run mybackup.service every day at 02:00 Loaded: loaded (/etc/systemd/system/mybackup.timer; enabled) Active: active (waiting) since Wed 2026-05-15 10:30:22 JST; 5min ago Trigger: Thu 2026-05-16 02:00:00 JST; 15h left # 全タイマーの一覧表示（次回実行日時含む） $ systemctl list-timers --all
4. OnCalendarの時刻指定一覧（cron対応表）
| やりたいこと | OnCalendarの書き方 | cron相当 |
|---|---|---|
| 毎日02:00 | OnCalendar=*-*-* 02:00:00 |
0 2 * * * |
| 毎週月曜09:00 | OnCalendar=Mon *-*-* 09:00:00 |
0 9 * * 1 |
| 毎時10分 | OnCalendar=*-*-* *:10:00 |
10 * * * * |
| 毎月1日00:00 | OnCalendar=*-*-01 00:00:00 |
0 0 1 * * |
| 起動後5分経過時 | OnBootSec=5min |
（cronでは設定不可） |
5. 実行ログをjournalctlで確認する
# mybackup.serviceの実行ログを確認 $ sudo journalctl -u mybackup.service # 最新20行のみ表示 $ sudo journalctl -u mybackup.service -n 20 # リアルタイム監視 $ sudo journalctl -u mybackup.service -f
/var/log/cronをgrepして確認する必要がありましたが、systemd timerではjournalctlで統一的に確認できます。6. OnCalendarの書式を事前に検証する
# OnCalendarの書式を事前に検証する $ systemd-analyze calendar "*-*-* 02:00:00" # 出力例 # Original form: *-*-* 02:00:00 # Normalized form: *-*-* 02:00:00 # Next elapse: Thu 2026-05-16 02:00:00 JST
cronのトラブルシュート・よくあるエラー
1. 手動実行は動くがcronで動かない
最もよくあるトラブルです。主な原因と対処法は以下のとおりです。| 原因 | 確認方法 | 対処法 |
|---|---|---|
| PATHが違う | cron内でenv > /tmp/env.txtを実行してPATHを確認 | crontabまたはスクリプト内でexport PATH=...を明示 |
| LANGが違う（文字化け） | ジョブの出力ファイルを確認 | export LANG=ja_JP.UTF-8をスクリプト冒頭に追加 |
| スクリプトに実行権限がない | ls -l /path/to/script.sh | chmod +x /path/to/script.sh |
| 相対パスを使っている | スクリプト内のパスを確認 | 全てのパスをフルパスで記述 |
2. cronのログで原因を特定する
# RHEL9/Rocky9のcronログを確認 $ sudo tail -f /var/log/cron # systemdジャーナルからcronログを確認 $ sudo journalctl -u crond -f # 特定の日付のcronログを確認 $ sudo journalctl -u crond --since "2026-04-07" --until "2026-04-08" # cronジョブの出力をファイルにリダイレクト（デバッグ用） # crontabファイルの設定例 0 1 * * * /var/www/system/backup.sh >> /var/log/backup.log 2>&1
3. crondが起動しているか確認する
# RHEL9/Rocky9でcrondの状態を確認 $ sudo systemctl status crond * crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2026-04-07 09:00:00 JST; 7h ago # 停止していた場合は起動する $ sudo systemctl start crond $ sudo systemctl enable crond
本記事のまとめ
| コマンド・設定 | 用途 | 重要なポイント |
|---|---|---|
| crontab -e | cronジョブを編集 | 保存時にsyntaxチェックあり |
| crontab -l | 設定中のジョブを一覧表示 | 確認のみ（変更なし） |
| crontab -r | 全ジョブを削除【危険】 | 前に必ずcrontab -lでバックアップ |
| crontabの書式 | 分 時 日 月 曜日 コマンド | *=毎回、*/2=2つおき、1-5=範囲、1,3=複数 |
| /etc/crontab | システム全体のcron | ユーザー名フィールドが追加される |
| /etc/cron.d/ | アプリ固有のcron設定 | パーミッション644が必須 |
| at | 1回限りのジョブ実行 | atqで確認、atrmでキャンセル |
| systemctl enable mybackup.timer | systemd timerを有効化 | daemon-reload後に実行する |
| systemctl list-timers --all | 全タイマーの一覧・次回実行日時を表示 | 次回実行予定の確認に使う |
| journalctl -u mybackup.service | systemd timerのジョブログ確認 | cronより詳細なログが取れる |
cronの最大の落とし穴は「手動では動くのにcronで動かない」という問題です。
環境変数（PATH・LANG）をスクリプト内で明示し、すべてのパスをフルパスで書く習慣をつければ、ほとんどのトラブルは防げます。
そして
crontab -rは「操作前に必ずcrontab -lでバックアップ」を鉄則にしてください。さらに一歩進めたい方は、cronよりもログが追いやすく、停止中のジョブを自動補完できるsystemd timerへの移行も検討してみてください。
Linuxのジョブ管理・サーバー運用を体系的に学びたい方へ
cronによる定期実行の自動化は、Linuxサーバー運用の基礎スキルです。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、「Linuxサーバー構築入門マニュアル（図解60P）」を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：CentOS7の新機能｜アーキテクチャ・systemd・firewalld・XFSの主要変更点
- 前のページへ：CentOS7で変わったinit廃止とsystemd導入｜ランレベルとターゲットの対応関係を解説
- この記事の属するカテゴリ：Linuxtipsへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます