【完全版】crontabの書き方と実用例まとめ｜Linux定期実行の設定方法を徹底解説

Linuxサーバーで「定期的にスクリプトを実行したい」場面は頻繁にあります。バックアップ・ログ整理・データ同期・監視・通知送信など、運用業務の自動化に欠かせない仕組みが cron（クーロン）です。

しかし、crontab の書き方には独特のルールがあり:

• * * * * * の5フィールドの意味を覚えにくい
• 「毎月15日に実行」「毎週月曜の朝9時」をどう書けば？
• 設定したのに動かない
• ログがどこに出るのか分からない
• 環境変数が読まれていない
• systemd timer と cron どっちを使えばいい？

など、つまづくポイントが多いツールです。

本記事では、crontabの書き方と実用パターンを、リファレンスとしてまとめ直しました。基本構文から、5フィールドの完全解説、特殊記号、便利な省略形、環境変数の扱い、ログ・デバッグ手法、systemd timerとの比較、トラブルシューティング、50超の実用例、FAQまで完全網羅。この1本をブックマークすれば、crontabに関するあらゆる疑問が解決します。

結論：今すぐ使えるパターン10選

時間がない方向けに、超頻出パターンを先に示します。

# 毎分実行（テスト用）
* * * * * /path/to/script.sh

# 毎時0分に実行
0 * * * * /path/to/script.sh

# 毎日午前3時に実行
0 3 * * * /path/to/script.sh

# 毎日午前3時と午後3時に実行
0 3,15 * * * /path/to/script.sh

# 5分ごとに実行
*/5 * * * * /path/to/script.sh

# 平日（月〜金）のみ朝9時
0 9 * * 1-5 /path/to/script.sh

# 毎月1日の午前6時
0 6 1 * * /path/to/script.sh

# 毎週日曜深夜0時
0 0 * * 0 /path/to/script.sh

# 起動時に実行
@reboot /path/to/script.sh

# 1時間ごと（@hourly）
@hourly /path/to/script.sh

詳細は以下で順に解説します。

crontab の基本構文

crontab は1行に5つの時刻フィールド+実行コマンドを書きます。

*  *  *  *  *  コマンド
│  │  │  │  │
│  │  │  │  └─── 曜日（0-7、0と7は日曜）
│  │  │  └────── 月（1-12）
│  │  └───────── 日（1-31）
│  └──────────── 時（0-23）
└─────────────── 分（0-59）

各フィールドの値範囲

最小単位の例

# 毎日12時30分に実行
30 12 * * * /path/to/script.sh

# 毎週月曜の午前8時に実行
0 8 * * 1 /path/to/script.sh

# 毎月1日の午前0時に実行
0 0 1 * * /path/to/script.sh

* は「そのフィールドで全部マッチ」を意味します。* * * * * だと「分・時・日・月・曜日のすべて」で毎分実行されます。

特殊記号の意味

時刻フィールドで使える特殊記号です。

* （アスタリスク）：すべて

# 毎分（全ての分）
* * * * * cmd

, （カンマ）：列挙

# 0分、15分、30分、45分に実行
0,15,30,45 * * * * cmd

# 朝9時と夕方5時に実行
0 9,17 * * * cmd

# 月・水・金の朝6時
0 6 * * 1,3,5 cmd

- （ハイフン）：範囲

# 9時から17時の間、毎時0分に実行
0 9-17 * * * cmd

# 平日（月-金）
0 9 * * 1-5 cmd

# 1月から6月の毎日
0 6 * 1-6 * cmd

/ （スラッシュ）：間隔（ステップ）

# 5分ごと
*/5 * * * * cmd

# 2時間ごと
0 */2 * * * cmd

# 6時から23時まで2時間ごと
0 6-23/2 * * * cmd

# 9-17時、20分間隔
*/20 9-17 * * * cmd

⚠️ */N は「Nで割り切れる時刻」を意味し、必ずしも「N分ごと」とは限りません。例: */7 * * * * は0分・7分・14分・21分・28分・35分・42分・49分・56分（次は0分）に実行され、本当の7分間隔ではありません。

組み合わせ

# 平日の9時〜17時、30分ごと
*/30 9-17 * * 1-5 cmd

# 毎月1日・15日の朝6時と夕方6時
0 6,18 1,15 * * cmd

便利な省略形（@表記）

@から始まる短縮形でよく使われる時刻指定が簡潔に書けます。

使用例

# システム起動時に実行
@reboot /home/user/startup.sh

# 毎日0時にバックアップ
@daily /usr/local/bin/backup.sh

# 1時間に1回ログ整理
@hourly /usr/local/bin/log-clean.sh

# 月初にレポート生成
@monthly /usr/local/bin/monthly-report.sh

@rebootはブート時に1回だけ実行されます。常駐プロセスの起動などに便利。

crontab の編集・確認・削除

crontab コマンドの基本

# crontab を編集（標準エディタが起動）
crontab -e

# 現在の crontab を表示
crontab -l

# crontab を全削除（確認なしで実行されるので注意）
crontab -r

# 削除前に確認プロンプト
crontab -i -r

別ユーザーの crontab 操作（要root）

# root が user1 の crontab を編集
sudo crontab -u user1 -e

# user1 の crontab を表示
sudo crontab -u user1 -l

一時的にファイルから登録

# my_cron.txt の内容を crontab にセット
crontab my_cron.txt

# 既存設定をバックアップしてから書き換え
crontab -l > backup.cron
crontab new.cron

# 既存に追加する場合
(crontab -l 2>/dev/null; echo "0 3 * * * /path/script.sh") | crontab -

編集時のエディタ変更

# 一時的に nano で編集
EDITOR=nano crontab -e

# 永続化（~/.bashrc に追加）
export EDITOR=nano
# または
export VISUAL=nano

ターミナルでviに不慣れな方にはnanoが便利です。

crontab で使えるコマンドの書き方

絶対パスで書く

# ❌ 動かないことがある（PATHが限定されている）
0 3 * * * mybackup.sh

# ✅ 絶対パスで指定
0 3 * * * /usr/local/bin/mybackup.sh

スクリプトと引数

# 引数付き
0 3 * * * /usr/local/bin/backup.sh --full --dest /mnt/backup

# 複数コマンド
0 3 * * * cd /var/log && /usr/local/bin/rotate.sh

# 結果に応じて連続実行
0 3 * * * /script1.sh && /script2.sh

出力をログに残す

# 標準出力をファイルに（上書き）
0 3 * * * /path/script.sh > /var/log/script.log

# 追記
0 3 * * * /path/script.sh >> /var/log/script.log

# 標準エラーも一緒に
0 3 * * * /path/script.sh >> /var/log/script.log 2>&1

# 何も出力しない（捨てる）
0 3 * * * /path/script.sh > /dev/null 2>&1

2>&1 を使うことでエラー出力もキャプチャできます。

日時付きログ

# 日付付きログファイル
0 3 * * * /path/script.sh >> /var/log/script.$(date +\%Y\%m\%d).log 2>&1

⚠️ crontab内では % を \% でエスケープが必要。

環境変数の設定

cron実行時の環境変数は対話シェルとまったく違うため、よく問題になります。

crontab 内での環境変数設定

# crontab 冒頭で環境変数を定義
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOME=/home/user
MAILTO=alert@example.com
LANG=ja_JP.UTF-8

# 以降のジョブで環境変数が使える
0 3 * * * mybackup.sh
0 4 * * * /home/user/scripts/cleanup.sh

よく問題になる環境変数

スクリプト側で環境を読み込む

cronで.bashrcや.profileは読まれません。明示的に読み込ませる:

#!/bin/bash
# スクリプトの冒頭で
source /home/user/.bashrc
source /home/user/.bash_profile

# あるいは特定の変数だけ
export PATH=/usr/local/bin:$PATH
export DATABASE_URL="postgresql://..."

MAILTO によるメール通知

# ジョブの出力をメールで通知
MAILTO=admin@example.com

0 3 * * * /path/script.sh

スクリプトが何か出力するとメール送信されます。通知不要なら必ず出力をリダイレクトするか:

MAILTO=""

メール送信を無効化。

ログ・デバッグ

cronが動いていない時の調査手順です。

cron 自体のログ

# Ubuntu/Debian
sudo tail -100 /var/log/syslog | grep CRON

# RHEL/CentOS
sudo tail -100 /var/log/cron

# Systemd ログ全般
sudo journalctl -u cron
sudo journalctl -u crond     # RHEL系の場合

実行されたか確認

# CRON 実行ログ
sudo grep CRON /var/log/syslog | tail -20

# 出力例
Jun 17 10:00:01 server CRON[12345]: (user) CMD (/path/script.sh)

CMDの行があれば実行は試みられたことを意味します。それでも結果が期待通りでないなら、スクリプト側の問題です。

デバッグ用のスクリプト

#!/bin/bash
# debug.sh
{
    echo "=== $(date) ==="
    echo "PWD: $(pwd)"
    echo "USER: $(whoami)"
    echo "PATH: $PATH"
    echo "HOME: $HOME"
    echo "Environment:"
    env
} >> /tmp/cron_debug.log 2>&1

* * * * * /home/user/debug.sh

これでcron実行時の環境が分かります。問題切り分け後はcron登録を削除。

スクリプトの実行確認

# スクリプトに実行権限があるか
ls -l /path/script.sh
# -rwxr-xr-x  になっているか確認

# なければ付与
chmod +x /path/script.sh

ドライランで動作確認

# crontab で書いたコマンドを直接実行してテスト
/bin/sh -c "/path/script.sh > /tmp/out.log 2>&1"
cat /tmp/out.log

ユーザー別 crontab vs システム crontab

cronには2種類の管理方式があります。

ユーザー別 crontab（crontab -e）

• 各ユーザーがcrontab -eで編集
• 実体は /var/spool/cron/crontabs/USER または /var/spool/cron/USER
• そのユーザーの権限で実行

システム crontab（/etc/crontab）

sudo vi /etc/crontab

書き方は通常のcrontabと似ていますが、実行ユーザー指定が追加されます:

# 分 時 日 月 曜 ユーザー コマンド
0 3 * * * root /usr/local/bin/system-backup.sh
0 4 * * * www-data /var/www/cleanup.sh

ユーザー別と違い、USERフィールドが必須です。

/etc/cron.{hourly,daily,weekly,monthly}

実行スクリプトを置くだけで定期実行されるディレクトリです:

# 毎時実行
sudo cp myscript.sh /etc/cron.hourly/

# 毎日実行（通常は深夜）
sudo cp daily-backup.sh /etc/cron.daily/

# 実行権限必須
sudo chmod +x /etc/cron.daily/daily-backup.sh

ファイル名は .sh等の拡張子を付けないのが推奨（run-partsの仕様）。

/etc/cron.d/

特定アプリ用のcron設定をディレクトリに分けて管理:

# 例: /etc/cron.d/myapp
sudo cat << EOF | sudo tee /etc/cron.d/myapp
# myapp のバックアップ
MAILTO=admin@example.com
0 3 * * * root /opt/myapp/bin/backup.sh
EOF

パッケージ管理時に便利。アンインストール時にファイルごと削除できます。

各場所の使い分け

cron と systemd timer の違い

最近のLinuxではsystemd timerもよく使われます。

機能比較

systemd timer の例

/etc/systemd/system/backup.timer:

[Unit]
Description=Daily backup timer

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

[Install]
WantedBy=timers.target

/etc/systemd/system/backup.service:

[Unit]
Description=Daily backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
User=backup
Environment="DATABASE_URL=postgresql://..."

有効化:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

# 状態確認
sudo systemctl list-timers

使い分け

• シンプルな定期実行 → cron で十分
• 複雑な依存関係・ログ管理 → systemd timer
• モダンなUbuntuサーバー（22.04+） → systemd timer 推奨の風潮
• 既存スクリプトの移行 → 現状の cron を維持してOK

macOS / WSL での挙動

macOS

macOS でも cron は使えますが、SIPの影響でフルディスクアクセス権限が必要なケースがあります。

# macOSでもcrontabコマンドは標準搭載
crontab -e
crontab -l

最近のmacOSでは launchd（launchctl）が推奨され、/Library/LaunchDaemons/配下のplistで設定するのが標準的です。

WSL2

WSL2でcronを使うには、起動時に手動で起動する必要があります（systemdが有効化されていない場合）:

# cron 起動
sudo service cron start

# 自動起動するには ~/.bashrc に追加
if ! pgrep -x cron > /dev/null; then
    sudo service cron start
fi

WSL2でsystemdが有効化されていれば（/etc/wsl.confでsystemd=true）、sudo systemctl enable cronで永続化可能です。

トラブルシューティング

設定したのに動かない

チェック1: crondサービスが動いているか

# Debian/Ubuntu
sudo systemctl status cron

# RHEL/CentOS
sudo systemctl status crond

# 停止している場合
sudo systemctl start cron
sudo systemctl enable cron  # 自動起動

チェック2: 構文エラーがないか

crontab -l

無効な行はcronが警告を出すか、無視します。

チェック3: ログを確認

sudo grep CRON /var/log/syslog | tail -20

実行が試みられたか確認。

チェック4: 環境変数の問題

cron実行環境はPATHが狭いため、コマンドのフルパス指定で確実に動作させる:

# ❌
0 3 * * * mycmd

# ✅
0 3 * * * /usr/local/bin/mycmd

チェック5: 実行権限

ls -l /path/script.sh
chmod +x /path/script.sh

% がエスケープされない

# ❌ % が改行扱いされて壊れる
0 3 * * * cp file file.$(date +%Y%m%d)

# ✅ \ でエスケープ
0 3 * * * cp file file.$(date +\%Y\%m\%d)

ロケール・文字コード

# 日本語環境を設定
LANG=ja_JP.UTF-8
LC_ALL=ja_JP.UTF-8

0 3 * * * /path/script-with-japanese.sh

ジョブが多重起動する

長時間ジョブの完了前に次の実行時刻が来ると、複数プロセスが同時実行されます:

# flock でロック
* * * * * flock -n /tmp/myjob.lock /path/script.sh

-n でロック取得失敗時は即時終了（待たない）。

ジョブが意図しない時刻に動く

タイムゾーンの問題かも:

# システムのタイムゾーン確認
timedatectl
date

UTC設定のサーバーで「日本時間 朝9時」に動かしたいなら:

# 0時UTC = 9時JST
0 0 * * * /path/script.sh

# またはタイムゾーン指定（systemd timer なら可能）
CRON_TZ=Asia/Tokyo
0 9 * * * /path/script.sh

CRON_TZ は対応するcron実装のみ（Vixie cronなど）で動作します。

実用パターン集

実務でよく使う設定例を網羅します。

バックアップ系

# 毎日午前3時にDBダンプ
0 3 * * * /usr/local/bin/db-backup.sh >> /var/log/db-backup.log 2>&1

# 毎週日曜にフルバックアップ
0 2 * * 0 /usr/local/bin/full-backup.sh

# 毎月1日にアーカイブ作成
0 4 1 * * tar czf /backup/archive-$(date +\%Y\%m).tar.gz /data

ログローテーション

# 毎日深夜にログを別フォルダへ移動
0 0 * * * find /var/log/myapp -name "*.log" -mtime +7 -exec gzip {} \;

# 古いログを削除（30日以上前）
0 1 * * * find /var/log/myapp -name "*.log.gz" -mtime +30 -delete

# ApacheログをCloudStorageへアップロード
0 2 * * * gsutil cp /var/log/apache2/*.log.1 gs://my-bucket/logs/

監視・通知系

# 5分ごとにサービス監視
*/5 * * * * /usr/local/bin/check-service.sh > /dev/null 2>&1 || \
    echo "Service down at $(date)" | mail -s "Alert" admin@example.com

# ディスク使用量を毎時チェック
0 * * * * /usr/local/bin/disk-check.sh

# 死活監視
*/1 * * * * curl -sf https://example.com/health > /dev/null || \
    /usr/local/bin/restart-service.sh

データ処理系

# 毎時0分にCSVをインポート
0 * * * * /usr/local/bin/import-csv.sh

# 毎日朝6時にレポート生成
0 6 * * * /usr/local/bin/generate-report.sh | mail -s "Daily Report" team@example.com

# 平日17時に集計バッチ
0 17 * * 1-5 /usr/local/bin/daily-aggregate.sh

システムメンテナンス系

# 毎日深夜にパッケージ更新確認
0 2 * * * /usr/bin/apt-get update > /dev/null 2>&1

# 毎週日曜にDocker未使用リソース削除
0 3 * * 0 /usr/bin/docker system prune -af --filter "until=168h" > /dev/null 2>&1

# 毎月最終日にメトリクス集計
0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /usr/local/bin/monthly-metrics.sh

最終日の判定は「明日が1日なら最終日」の論理です。

Web系（Webhook、API）

# 毎時 webhook 送信
0 * * * * curl -X POST https://api.example.com/webhook -d "trigger=hourly"

# 毎朝Slack通知
0 9 * * 1-5 curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"おはようございます"}' $SLACK_WEBHOOK_URL

# 毎日のレート更新
0 9 * * * /usr/bin/curl -o /var/data/rates.json https://api.exchange.com/rates

SSL証明書系

# 毎日午前2時にcertbot更新
0 2 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"

# 毎週月曜に証明書期限チェック
0 9 * * 1 /usr/local/bin/cert-expiry-check.sh

データベース系

# 毎晩MySQLバックアップ
0 1 * * * mysqldump -u root --all-databases | gzip > /backup/mysql-$(date +\%Y\%m\%d).sql.gz

# PostgreSQLバックアップ
0 1 * * * sudo -u postgres pg_dumpall | gzip > /backup/pg-$(date +\%Y\%m\%d).sql.gz

# 毎週バックアップ古い分を削除（30日より前）
0 3 * * 0 find /backup -name "*.sql.gz" -mtime +30 -delete

Git連携

# 毎時、リポジトリを最新化
0 * * * * cd /opt/myrepo && git pull > /dev/null 2>&1

# 毎日深夜に設定ファイルをGitコミット
0 4 * * * cd /etc && git add . && git commit -m "Daily commit $(date +\%F)" > /dev/null 2>&1

crontab 書式チェックツール

設定する前に書式を確認できるツールです。

crontab.guru（オンライン）

crontab.guru はWebブラウザで cron 式を確認できる定番ツール:

• 「0 3 * * 1-5」を入力
• 「At 03:00 on every day-of-week from Monday through Friday」と日本語/英語で解釈表示

コマンドラインで構文確認

# 多くのディストリビューションでは設定時に自動チェック
crontab -e
# 保存時にエラーがあれば警告

# 一度ファイルに書いてからチェック
crontab -T mycron.txt   # ファイル構文チェック（環境依存）

次回実行時刻の確認

# crondumpコマンド（ない環境もある）
crondump

# または systemd timer で確認
systemctl list-timers

よくある質問（FAQ）

Q1. crontab で何度試してもジョブが動きません

最頻出原因と確認順:

1. cronサービス起動確認: systemctl status cron
2. 構文ミス: crontab -lで確認
3. PATH不足: コマンドをフルパスで書く
4. 権限: スクリプトに実行権限あるか
5. ログ確認: grep CRON /var/log/syslog

Q2. 5分ごとに動かしたい

*/5 * * * * /path/script.sh

Q3. 平日のみ動かしたい

0 9 * * 1-5 /path/script.sh
# または
0 9 * * mon-fri /path/script.sh

Q4. 月末に動かしたい

cronには「月末」を直接表現する構文がありません。月末判定ロジックをスクリプト側で:

# 28〜31日に毎日試行し、明日が1日なら実行
0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /path/script.sh

または毎月1日0時に実行して「前月のデータ」を扱う設計が綺麗:

# 毎月1日に前月分の集計
0 0 1 * * /path/monthly-summary.sh

Q5. 失敗時にメールを受け取りたい

MAILTO=admin@example.com

# スクリプトが何か出力するとメール送信
0 3 * * * /path/script.sh

# エラー時のみ通知（通常は出力なし、エラー時に出力）
0 3 * * * /path/script.sh > /dev/null

Q6. ジョブをスキップしたい時は？

# 先頭に # を付けてコメントアウト
# 0 3 * * * /path/script.sh

Q7. crontab の編集中に Ctrl+C で抜けたら設定が消えました

crontab -eは編集後に保存しないと反映されません。ただし「保存して終了」してから設定ミスで全削除になることはあります。心配なら定期バックアップ:

# 毎日 crontab をバックアップ
crontab -l > ~/cron-backup-$(date +%F).txt

Q8. 起動時にだけ動かしたい

@reboot /path/startup.sh

または systemd unit を使う方が確実です（cronはOS起動の比較的早い段階で動くため）。

Q9. ジョブを並列実行させたくない

flockを使ってロック:

* * * * * flock -n /tmp/myjob.lock /path/script.sh

-nで取得失敗時に即時終了。重複起動を防げます。

Q10. ロケールや日本語環境の問題

LANG=ja_JP.UTF-8
LC_ALL=ja_JP.UTF-8

# 以降のジョブで日本語が扱える
0 3 * * * /path/script-with-japanese.sh

Q11. cron と anacron の違い

• cron: 24時間動作前提。指定時刻にマシンが起動していないとスキップ
• anacron: ノートPC等の電源OFFを考慮。次回起動時に取り戻して実行

サーバー運用ならcron、ノートPC等ならanacronの活用も。

Q12. systemd-timer に移行すべきですか？

新規構築なら systemd timer 推奨。理由:

• ログがjournalctlで統一管理
• 失敗時の通知設定が柔軟
• 依存関係の表現が可能

既存のcron設定は無理に移行する必要なし。動いているなら維持で問題ありません。

参考リンク・関連資料

公式ドキュメント

• crontab(5) manページ（Ubuntu） – crontab 書式公式
• crontab(1) manページ – crontab コマンド
• cron(8) manページ – cron デーモン
• GNU mcron – 高機能なcron代替

systemd Timer

• systemd.timer manページ – 公式仕様
• systemd.time manページ – 時刻指定書式

オンラインツール

• crontab.guru – cron式を解釈してくれる定番ツール
• Cronitor crontab visualizer – 視覚的に書式確認

関連記事（本サイト）

• Linux find オプション一覧 – findコマンドリファレンス
• Linux grep オプション まとめ – grepコマンドリファレンス
• Docker「no space left on device」エラーの対処 – 容量問題（cron自動クリーンアップに活用）
• Ubuntuでアンインストールする全方法 – パッケージ管理

まとめ

crontabはLinuxの定期実行のための基本ツール。要点を再整理します。

• 5フィールド構文: 分 時 日 月 曜 コマンド
• 特殊記号: *（全部）、,（列挙）、-（範囲）、/（ステップ）
• 省略形: @reboot、@daily、@hourly等で簡潔に
• コマンドは絶対パスで: cron実行時のPATHは限定的
• 環境変数は明示: SHELL/PATH/LANG/MAILTOを冒頭で設定
• 出力はリダイレクト: > /var/log/script.log 2>&1 または > /dev/null 2>&1
• 管理場所の使い分け: crontab -e（個人）、/etc/crontab（システム）、/etc/cron.d/（パッケージ）、/etc/cron.{hourly,daily,weekly,monthly}（時刻不要）
• トラブル時: systemctl status cron、grep CRON /var/log/syslog、デバッグスクリプト
• モダンな代替: systemd timer（ログ統一・依存管理に強い）

これらの知識は、Linuxサーバー運用・自動化スクリプト・バックアップ・監視など、システム管理のあらゆる場面で必須です。本記事をブックマークしておけば、いつでも適切なcrontabを組み立てられるようになります。

本記事は2026年6月時点の情報をもとに、Vixie cron（Debian/Ubuntu）、cronie（RHEL系）での動作確認に基づき作成しています。crontab実装によって一部仕様が異なる場合があるため、最新の情報は公式マニュアルもあわせてご確認ください。