cronは、「毎日午前3時にバックアップする」「1時間ごとに集計する」といった定期処理を、サーバーで自動実行する仕組みです。自分のパソコンを起動しておく必要はありません。

レンタルサーバーでは、管理画面に実行時刻とコマンドを登録する方式がよく使われます。WordPressの通常の更新や投稿に必須ではありませんが、外部連携や決まった時刻の処理に役立ちます。ここでは時刻の読み方と、登録時につまずきやすい点を説明します。

cronの時刻は「分・時・日・月・曜日」で表します

一般的なcrontabでは、コマンドの前に五つの欄を並べます。*はその欄のすべての値を表します。crontabのマニュアルに記法が説明されています。

時刻の指定実行されるタイミング
0 3 * * *毎日3時0分
0 * * * *毎時0分
*/15 * * * *毎時0・15・30・45分
0 9 * * 1毎週月曜日の9時0分

表は時刻欄だけの例で、実行するコマンドは別に指定します。管理画面で各欄を選ぶサービスもあります。タイムゾーンと最短実行間隔はサーバー会社によって違うため、公式案内に合わせます。

「毎月31日」では31日がない月に動きません。また、5分間隔の処理に8分かかれば次の実行と重なるため、処理時間に余裕のある間隔か、重複を防ぐ仕組みが必要です。

対話シェルとcronの実行環境は同じではない

SSHで成功したコマンドがcronで失敗することがあります。cronでは利用できる環境変数や検索パスが限られ、開始ディレクトリも想定と違う場合があるためです。PHPや実行ファイル、対象スクリプト、出力先には確認済みの絶対パスを使います。

実行ユーザーも重要です。手動確認した利用者とcronが動く利用者が違えば、ファイルの読取・書込権限も変わります。秘密情報をコマンド行へ直接書くと管理画面やプロセス情報へ残る可能性があるため、事業者が提供する安全な設定方法を確認します。

処理が対話入力を待つ構成では自動実行が止まります。確認質問、パスワード入力、画面操作へ依存しないモードを用意します。まずcronと同じ利用者・作業ディレクトリ・環境で手動実行し、終了コードと生成物を確認します。

成功と失敗の出力を捨てずに受け取る

cronがコマンドを起動した記録と、業務処理が完了した記録は別です。起動時刻・終了時刻・処理件数・終了状態をログへ残します。個人情報や認証情報を出力しないよう、ログに必要な項目も先に決めます。

標準出力と標準エラーを無条件に破棄すると、失敗を知る手掛かりが消えます。メール通知・管理画面の実行履歴・監視サービスなどから、担当者が受け取れる経路を一つ以上用意します。通知先が旧担当者のアドレスになっていないかも確認します。

成功時と失敗時の通知を同じ頻度で送り続けると、重要な失敗が埋もれます。正常時は日次の集計へまとめ、失敗時はすぐ知らせる構成も検討します。ログ容量と保管期間を決め、書込失敗そのものを検知できるようにします。

再実行と重複に耐える処理へする

一度失敗した処理を再実行すると、メールの二重送信やデータの二重登録が起こる場合があります。処理済みの識別子や対象期間を記録し、同じ入力を再度扱っても結果を壊さない設計が理想です。難しい場合は、再実行前に確認する項目と戻し方を手順へ残します。

前回の処理が残ったまま次回を開始しないよう、ロックや同時実行制御を使います。ただし異常終了後に古いロックが残る方式では、以後の処理が止まります。ロックの所有者、期限、解除手順まで含めて実装を確認します。

外部サービスへ接続する処理は、相手の停止や通信遅延で長引きます。接続と処理にタイムアウトを設け、途中結果をどこまで確定したか記録します。無制限の自動再試行では相手へ負荷をかけるため、回数と間隔を決めます。

WP-Cronとシステムcronを混同しない

WordPress公式のWP-Cron解説によると、WP-Cronはページ読み込み時に期限を迎えた処理を確認します。システムcronのように常時動く仕組みではありません。アクセスが少ないサイトでは、予約投稿やプラグイン処理が予定時刻より遅れることがあります。

正確な起動が必要な場合は、レンタルサーバーのcronからWordPressの処理を呼ぶ構成があります。WordPress側には重複起動を抑える仕組みもありますが、ページ読み込みによる起動を残すと不要な呼び出しが増えます。公式の連携手順では、外部からの定期呼び出しを用意したうえで、通常のWP-Cron起動を無効にします。

WordPress本体やプラグインが登録した予定を、用途不明のまま一括削除しません。更新確認や予約公開へ影響するためです。遅延が起きた時刻と対象イベントを記録し、サイトアクセス・ループバック通信・プラグインのエラーを分けて調べます。

動かないときは時刻とパスから確認できます

登録したのに結果がない場合は、時刻・タイムゾーン、PHPやスクリプトの絶対パス、実行権限、ログの順に見ると原因を絞りやすくなります。手動では動くのにcronだけ失敗するなら、環境変数や作業ディレクトリの違いも候補です。

不要になった定期処理は、スクリプトを消す前にcron登録を停止します。逆に、使っている処理を止めるとバックアップや連携も止まるため、登録名だけでなく用途を確認してから変更する方が安全です。