ケーススタディ

サーバー移行が終わり、Webサイトもメールも問題なく動いている。
それなのに「予約投稿が公開されない」「定期配信メールが止まった」「自動更新処理が実行されていない」といった現象が起きることがあります。

これらの多くは Cron（クーロン）と呼ばれる自動実行処理 が、新しいサーバーで正しく動いていないことが原因です。
Cronは裏側で静かに動く仕組みのため、問題が起きても気づきにくく、移行後トラブルとして非常に多いポイントです。

Cron（クーロン）とは？

Cronとは、「決まった時間に、決まった処理を自動で実行する仕組み」 のことです。

代表的な利用例としては次のようなものがあり、人が操作しなくても裏側で実行される処理に使われています。

• WordPressの予約投稿
• 定期メール配信
• データの自動更新
• バックアップ処理
• 外部APIとの定期連携

サーバー移行後にCronが止まりやすい理由

サーバーを移行後にグローンが止まってしまうケースでよく見られる理由を見ていきましょう。

Cron設定が新サーバーに引き継がれていない

Cronはサーバーごとの設定のため、ファイルを移行しただけでは自動的に引き継がれません。
旧サーバーで設定していたCronは、新サーバーで再設定が必要です。

実行パス（コマンドパス）が変わっている

サーバーが変わると、少しの違いでCronは動かなくなります。
例えばPHPの実行パス、コマンドの場所が変わることがあります。

例）
旧サーバー：/usr/bin/php
新サーバー：/usr/local/bin/php

実行権限（パーミッション）の問題

Cronで実行するスクリプトに実行権限（755など）が付いていないと、処理は実行されません。

PHPバージョンの違い

PHPのバージョンが異なることで起こる問題と同様、Cron実行時のPHPバージョンが想定と違うことでエラーになるケースもあります。

関連記事：
サーバー移行後に画面が真っ白？PHPバージョン違いで起こる典型的トラブルと解決手順

メール通知設定がなく、失敗に気づかない

Cronは失敗しても、通知設定がなければエラーが目に見えないので、気づかないケースも散見されます。

よくあるCronトラブルの具体例

実際によく起こるクローンによるトラブルの例をいくつか見ていきましょう。

WordPressの予約投稿が公開されない

WordPressでは疑似Cron（WP-Cron）が使われており、サーバー設定やアクセス状況によって動かなくなることがあります。

定期メール・バッチ処理が止まる

ECサイトや業務システムでは特に注意が必要です。
「注文確認メール」「定期レポート送信」が問題なく送信できているか、テストして確認しておくとよいでしょう。

バックアップが取得されていない

自動バックアップがCronで設定されていた場合、移行後に一切バックアップが取られていないケースも少なくありません。

移行時に行うべきCron設定の確認手順

サーバー移行時に行う必要のあるクローン設定を確認していきます。

1. 旧サーバーのCron設定を必ず控える

• 実行コマンド
• 実行ユーザー
• 実行頻度（毎分／毎時／毎日など）
• 実行タイミング

2. 新サーバーでCronを再設定する

管理画面（cPanel等）またはSSHから、旧環境と同じ内容を新サーバーに設定します。

3. 実行パスを新サーバー用に修正

「which php」コマンドなどで、正しい実行パスを確認してから設定します。

4. 実行ログ・エラーログを確認

Cronのログを有効にし、「正常終了しているか」「エラーが出ていないか」を必ずチェックします。

5. テスト実行で動作確認を行う

本番稼働前に、手動実行やテストCronで正しく動くかを確認します。

トラブルを防ぐための運用ポイント

移行後の設定やテストで無事に正常に機能することが確認できたら、その後の運用についても対策をしておく必要があります。
ここからトラブルに発展しないために、次のポイントを抑えておきましょう。

まとめ：自動処理は「静かに止まる」からこそ注意

Cronやバッチ処理は、止まってもエラー表示が出ないため、気づくのが遅れがちです。
サーバー移行時には、次の内容を行うことで、重大なトラブルを未然に防ぐことができます。

• 設定の引き継ぎ確認
• 実行パスの修正
• ログ・通知の設定

使用するサーバーや契約プランなどにより、手順や必要な作業は異なります。本記事では一般的な内容をご紹介しておりますのでご了承くださいませ。
個別の相談につきましては、お問い合わせからお願いいたします。