cronは、決めた日時にコマンドを起動する仕組みです。バックアップ・データ集計・在庫連携などを自動化できますが、管理画面で「登録済み」と表示されても処理の成功までは保証しません。起動後の終了状態と出力を確認できる設計が必要です。

レンタルサーバーでは、実行間隔・利用コマンド・同時実行数に独自の制限があります。登録例を貼り付ける前に、対象プランの仕様と実行ユーザーを確認します。そのうえで手動実行、限定的な定期実行、通知確認の順に進めます。

予定時刻と実行条件を先に言葉へ直す

「毎日実行する」だけでは設定条件が足りません。どのタイムゾーンの何時に始め、休日も動かすのかを決めます。サーバーの時刻が日本時間とは限らないため、管理画面の表示と実際の実行時刻を公式マニュアルで照合します。

処理の締め時刻も考えます。日付が変わった直後に集計する場合、前日の入力がまだ続いていないかを確認します。月末処理では月の日数が変わるため、「毎月31日」のように存在しない日が生じる条件をそのまま登録しません。

一回の処理にかかる最長時間を測り、次の開始時刻までに終わるかを判断します。五分間隔で起動する処理が八分かかれば、前回と次回が重なる可能性があります。重複しても安全な処理か、一つだけ動かすロックが必要かを開発担当者と決めます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

正確な起動が必要な場合は、レンタルサーバーのcronからWordPressの処理を呼ぶ構成があります。この切り替えでは、ページ読み込みによる従来の起動を残すと二重実行の可能性が生じます。WordPress公式のシステムスケジューラー連携手順を確認し、起動経路を一つにします。

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

登録した処理には廃止日まで持たせる

本番登録後は、最初の数回を予定時刻に確認します。起動・終了・生成物・通知がそろって初めて運用開始です。一回成功した後も、月替わりやデータ量増加で実行時間が変わるため定期的に見直します。

台帳には目的・所有者・実行時刻・コマンドの所在を残します。実行ユーザー・通知先・最終成功時刻・停止方法も必要です。スクリプトを更新したときは手動確認をやり直し、cron側だけ古いパスを参照していないか確かめます。

不要になった定期処理はスクリプトを消す前にcron登録を停止します。停止後に呼び出しがないことを確認し、ログと秘密情報を保管規則に沿って処理します。cronの管理は登録件数を増やすことではなく、動いている理由と結果を担当者が説明できる状態を維持することです。