cron式が読めると何ができる？サーバー運用の基本

5つの数字は覚えられても、事故はそこでは起きない

cron式は5つの数字が左から「分・時・日・月・曜日」の順に並んでいるだけの、非常に単純な仕組みです。読めるようになるのに必要な知識は、この並び順と、*（毎回）・*/n（n おきに）・,（複数指定）・-（範囲）の4記号だけです。

一方で、cronの事故はほぼすべて「書式を間違えた」ではなく「実行環境の前提を勘違いした」ことで起きます。この記事では書式そのものより、そちらの落とし穴に重点を置いて説明します。

cron式は5つの数字（記号）の組み合わせ

cronはLinux系サーバーで定番の「定期実行」の仕組みです。書式は次の5つのフィールドで構成されます。

分	時	日	月	曜日
0-59	0-23	1-31	1-12	0-7（日曜=0/7）

例えば 0 3 * * * は「毎日 3:00 に実行」、*/15 * * * * は「15分ごとに実行」という意味です。* は「毎回」を表します。

記号は4つ覚えれば足ります。* が「毎回」、*/5 が「5おきに」、1,15 が「1と15のとき」、1-5 が「1から5まで」です。これを組み合わせると、30 9 * * 1-5 で「平日の朝9時30分」、0 0 1 * * で「毎月1日の0時」と書けます。

実務でよくある使いどころ

• バックアップの自動化：深夜にDBやファイルを自動でバックアップ。
• 定期レポート：毎朝、前日のアクセス数や売上を集計してメール送信。
• キャッシュのクリア・再生成：一定時間ごとにキャッシュを最新化。
• 外部APIの定期取得：為替レートや在庫情報などを定期的に取得して更新。

自分やチームが書いたcron式が正しいか不安なときは、こでっとのcron式の解説に貼り付ければ、意味を日本語でその場で確認できます。設定ミスによる「動くはずが動いていなかった」を防げます。

よく使う書き方の早見表

実務で書くcron式は、だいたい次のパターンのどれかに収まります。ゼロから考えるより、近いものを選んで数字を差し替えるほうが速く、間違いも減ります。

やりたいこと	書き方
毎日 深夜3時	0 3 * * *
1時間ごと（毎時0分）	0 * * * *
10分ごと	*/10 * * * *
平日の朝9時30分	30 9 * * 1-5
毎週月曜の朝8時	0 8 * * 1
毎月1日の0時	0 0 1 * *
1日2回（朝9時と夜21時）	0 9,21 * * *

実行間隔を決めるときは「失敗しても次回で取り返せるか」を基準にすると安全です。

1日1回の処理が落ちると復旧まで丸一日ずれますが、1時間ごとなら次の回で追いつきます。逆に外部APIを叩く処理は、間隔を詰めすぎると相手側の利用制限に触れるので、必要な鮮度から逆算して決めてください。

つまずきやすい点：事故はたいてい書式以外で起きる

• サーバーのタイムゾーンが日本時間とは限らない：多くの環境で既定はUTCです。UTCのままだと 0 3 * * * は日本時間の正午に動きます。まず date コマンドでサーバーの現在時刻を確認してください。
• 実行時の環境変数が、ログイン時と違う：cronは非常に限られた環境で動くため、手元では通るコマンドが「command not found」で落ちることがあります。プログラムはフルパスで書くのが安全です。
• カレントディレクトリが想定と違う：cronの実行開始位置はホームディレクトリです。相対パスでファイルを読み書きしていると、意図しない場所を触ります。
• 前回の処理が終わる前に次が始まる：*/5 のような短い間隔で、処理に5分以上かかると多重起動します。ロックファイルなどで排他制御を入れてください。
• エラーに気づけない：cronは標準出力・標準エラーをメール送信しようとしますが、メールが設定されていない環境では黙って消えます。ログファイルへリダイレクトしておくのが確実です。
• 「日」と「曜日」を両方指定すると OR になる：0 0 1 * 1 は「1日かつ月曜」ではなく「1日、または月曜」です。直感と逆なので注意してください。

個人開発でサーバーを選ぶときの考え方

定期実行を含めて自分のサービスを24時間動かし続けるには、どこかにサーバーを置く必要があります。個人開発・小規模運用でよく比較されるのは次の2タイプです。

• レンタルサーバー：管理画面からcronやメール、データベースを設定でき、初期設定の手間が少ないタイプ。まずサーバーに慣れたい人向け。
• VPS（仮想専用サーバー）：root権限があり、Docker等も自由に使える分、自分でOSやセキュリティも管理する必要があるタイプ。構成の自由度を優先したい人向け。

判断の軸は「OSの管理を自分でやりたいか」の一点に絞ると迷いません。

やりたくない・時間を使いたくないならレンタルサーバー、構成を自由に決めたい・学習も兼ねたいならVPSです。なお、決まった時刻に短い処理を動かすだけなら、クラウドの定期実行サービスを使ってサーバー自体を持たない選択肢もあります。

cron以外の選択肢も知っておく

定期実行の手段はcronだけではありません。常時起動のサーバーを持たずに済むなら、そのほうが運用は軽くなります。GitHubにコードを置いているならGitHub Actionsのスケジュール実行、クラウドを使うならマネージドの定期実行サービス、Linuxサーバー上でより細かく制御したいならsystemdのタイマーという選択肢があります。

選び方の目安は「処理時間」と「失敗に気づく必要があるか」です。数秒〜数分で終わる処理で、失敗をメールやチャットに飛ばしたいなら、通知機能が最初から付いているマネージドサービスが楽です。逆に、既存のサーバー上のファイルやデータベースを直接触る処理なら、素直に同じサーバーのcronで動かすほうが構成がシンプルになります。

よくある質問

cron式の5つのフィールドは何を表しますか？

左から順に「分（0-59）」「時（0-23）」「日（1-31）」「月（1-12）」「曜日（0-7、日曜が0または7）」です。それぞれに *（毎回）、*/n（n おきに）、1,15（複数指定）、1-5（範囲）を書けます。曜日だけ0と7の両方が日曜を指す点が例外的なので、そこだけ覚えておけば読み書きに困りません。

個人開発ならレンタルサーバーとVPS、どちらを選ぶべきですか？

OSの管理を自分でやりたいかどうかで決めるのが一番はっきりします。管理画面からcronを設定できて手間が少ないのがレンタルサーバー、root権限があって構成の自由度が高いかわりにセキュリティ更新まで自分の責任になるのがVPSです。短い処理を決まった時刻に動かすだけなら、クラウドの定期実行サービスを使ってサーバーを持たない選択肢もあります。

cron式はどこで確認できますか？

こでっとのcron式の解説に貼り付けると、その式が何時に動くのかを日本語で確認できます。設定前に一度通しておくと、「毎日1回のつもりが1分ごとに動いていた」といった事故を防げます。

設定したのに動きません。何から確認すればよいですか？

順に4点を確認してください。1つ目はサーバーのタイムゾーン（date で現在時刻を確認）、2つ目はコマンドをフルパスで書いているか、3つ目はスクリプトに実行権限があるか、4つ目は出力をログファイルにリダイレクトしてエラー内容を残しているかです。cronの不具合はこの4つでほぼ説明がつきます。

関連ツール