CreaTools LogoCreaTools
Tech Notes
Tips

crontab の書き方完全ガイド｜5つのフィールドとよく使うパターン

2026-03-09

結論：書式はこの1行

分 時 日 月 曜日 コマンド

5つのフィールドをスペースで区切る。これさえ覚えれば9割書ける。

即決チェック表

やりたいこと書き方
毎時0分に実行0 * * * *
毎日深夜3時0 3 * * *
5分ごと*/5 * * * *
平日の朝9時0 9 * * 1-5
毎月1日の0時0 0 1 * *
30分ごと*/30 * * * *
毎週月曜の朝9時0 9 * * 1
毎日2時と14時0 2,14 * * *

このまま crontab -e に貼って使える。

フィールドの意味

*    *    *    *    *
分   時   日   月   曜日
0-59 0-23 1-31 1-12 0-6（0=日曜）
フィールド範囲
分0〜59
時0〜23
日1〜31
月1〜12
曜日0〜6（0と7が日曜）

特殊文字

記号意味例
*すべての値* * * * * → 毎分
,複数指定0 9,12,18 * * * → 9時と12時と18時
-範囲指定0 9-17 * * * → 9時〜17時の毎時0分
/間隔指定*/15 * * * * → 15分ごと

組み合わせ

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

# 月曜・水曜・金曜の朝7時
0 7 * * 1,3,5

基本コマンド

編集

crontab -e

エディタが開く。保存すれば即反映。

一覧

crontab -l

現在の登録内容を表示。

全削除

crontab -r

⚠️ 取り消せない。削除前に crontab -l > backup.txt でバックアップ推奨。

他ユーザーの cron を編集（root権限）

sudo crontab -u username -e

実務でハマるポイント

1. PATH が通っていない

# ✗ ローカルでは動くが cron では動かない
0 3 * * * node /var/www/script.js

# ✓ 絶対パスで指定
0 3 * * * /usr/bin/node /var/www/script.js

cron の環境変数は最小限。コマンドはすべて絶対パスで書く。

確認方法：

which node
# → /usr/bin/node

2. 環境変数が読み込まれない

.bashrc や .profile の内容は cron では読まれない。

# crontab の先頭で必要な変数を定義
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=ja_JP.UTF-8

0 3 * * * /usr/bin/node /var/www/script.js

3. 出力が消える

cron は標準出力をデフォルトでメール送信しようとする。メール設定がないと結果が確認できない。

# ログをファイルに残す
0 3 * * * /usr/bin/node script.js >> /var/log/myscript.log 2>&1

# ログ不要なら破棄
0 3 * * * /usr/bin/node script.js > /dev/null 2>&1

2>&1 は 標準エラーも標準出力に統合 する記法。デバッグ時は必ず付ける。

4. % が改行扱いされる

# ✗ % が改行になる
0 3 * * * date +"%Y-%m-%d"

# ✓ バックスラッシュでエスケープ
0 3 * * * date +"\%Y-\%m-\%d"

% は cron では特殊文字。日付フォーマットで頻発する罠。

動かないときのデバッグ

Step 1: cron 自体は動いているか

sudo systemctl status cron
# Active: active (running) であればOK

Step 2: 設定が登録されているか

crontab -l

Step 3: ログを確認

# Ubuntu / Debian
grep CRON /var/log/syslog

# CentOS / RHEL
grep CRON /var/log/cron

実行記録が残っていない → そもそも cron に拾われていない。

Step 4: コマンドを手動で実行できるか

# crontab に書いたコマンドを、そのままシェルで実行
/usr/bin/node /var/www/script.js

手動で動くのに cron で動かない → PATH か環境変数の問題。

Step 5: 1分後に実行する設定で試す

# 例：今が10:30なら
31 10 * * * /usr/bin/node /var/www/script.js >> /tmp/cron-test.log 2>&1

すぐに結果が確認できる。

よく使うパターン集

バックアップ系

# 毎日深夜2時にDBバックアップ
0 2 * * * /usr/bin/mysqldump -u root mydb > /backup/db_$(date +\%Y\%m\%d).sql

# 7日以上前のバックアップを削除
0 3 * * * find /backup -name "*.sql" -mtime +7 -delete

ログローテーション系

# 毎週月曜に古いログを圧縮
0 4 * * 1 gzip /var/log/myapp/*.log

監視系

# 5分ごとにヘルスチェック
*/5 * * * * curl -s https://example.com/health > /dev/null || echo "DOWN" | mail -s "Alert" admin@example.com

Web系

# WordPressのwp-cronを5分ごとに手動実行
*/5 * * * * /usr/bin/wget -q -O - https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

特殊文字列（短縮記法）

記法意味
@yearly0 0 1 1 *（毎年1月1日）
@monthly0 0 1 * *（毎月1日）
@weekly0 0 * * 0（毎週日曜）
@daily0 0 * * *（毎日0時）
@hourly0 * * * *（毎時0分）
@rebootシステム起動時
@daily /usr/bin/node /var/www/script.js

可読性は高いが、5フィールド形式の方がチームで共通認識を取りやすい。

crontab vs systemd timer

観点crontabsystemd timer
簡単さ◎△
ログ管理手動設定自動（journalctl）
失敗時の通知手動自動
依存関係の指定不可可能
実行時間の精度分単位秒単位

シンプルな定期実行なら crontab。 本格的な運用なら systemd timer を検討。

まとめ

やることコマンド
編集crontab -e
一覧crontab -l
全削除crontab -r（要バックアップ）
ログを残す>> /path/to/log 2>&1

書式は「分 時 日 月 曜日」。 動かないときはまず PATH と環境変数を疑う。

関連記事