2026年7月5日

WordPressのwp-cronが無効（DISABLE_WP_CRON）になっている場合のバックグラウンド処理の設定方法

エラー・白い画面

wp-config.php で DISABLE_WP_CRON が true になっていると、WordPressはアクセスをきっかけにした定期処理（WP-Cron）を自分では起動しなくなります。代わりにサーバーのcronなどで定期的に起動してあげないと、予約投稿・プラグインのキュー・バックアップといったバックグラウンド処理が止まります。この記事では、無効になっているかの確認、止まっている処理の見つけ方、サーバーcronでの起動方法と、つまずきやすい点を説明します。

WP-Cronが無効だと何が起きるか

WP-Cronは、ページが表示されたときに「実行時刻を過ぎた処理があるか」を確認し、あればバックグラウンドで wp-cron.php を呼び出す仕組みです。DISABLE_WP_CRON はこの自動起動だけを止める定数で、処理の登録自体は続きます。つまり、起動する仕組みを別に用意しないと、処理がたまっていく一方になります。

止まると影響が出やすいのは次のような処理です。

予約投稿の公開（「予約投稿の失敗」と表示される）
WordPress本体・プラグイン・テーマの更新チェックや自動更新
WooCommerceなどが使う Action Scheduler のキュー（注文後のメール、在庫処理など）
バックアップ、メール配信、外部サービスとの同期といったプラグインの定期処理

この定数は、アクセスの多いサイトで表示のたびにcron確認が走る負荷を避けるため、またはアクセスの少ないサイトで実行時刻を安定させるために、意図して設定されることがあります。一方で、ホスティングの初期設定や、別環境から wp-config.php を移したときにそのまま残っていることもあります。

無効になっているかを確認する

wp-config.php を見る

wp-config.php に次の行があるかを確認します。

define( 'DISABLE_WP_CRON', true );

WP-CLIが使える場合は、次のコマンドでも確認できます。

wp config get DISABLE_WP_CRON
wp cron test

wp cron test はWP-Cronの起動テストを行い、定数で無効化されている場合はその旨を表示します。

止まっている処理を見つける

wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence

next_run_gmt（UTCの予定時刻）が現在のUTC時刻より大きく過去になっているイベントがたくさんあれば、cronが起動されていません。実行時刻を過ぎたイベントは、next_run_relative の欄では「now」のように表示されるのが一般的です。管理画面では「ツール > サイトヘルス」に、予定された処理が遅れている旨の警告が出ることがあります。WooCommerceを使っている場合は、Action Scheduler の管理画面（「ツール > Scheduled Actions」またはWooCommerceのステータス画面内。表示場所は版により異なります）で、期限切れ（Past-due）の処理がたまっていないかも確認します。

対処法を選ぶ

選択肢は大きく3つです。

サーバーのcronで定期起動する（おすすめ。実行間隔が安定し、表示時の負荷もない）
定数を外してWP-Cronを有効に戻す（サーバーcronを設定できない場合）
**外部のcron実行サービスから wp-cron.php を呼ぶ**（サーバー側でcronが使えない場合の代替）

意図して無効にしているのに起動側が設定されていない、というケースが多いので、まず1を検討します。作業前に wp-config.php とcrontabのバックアップを取り、可能ならステージング環境で動作を確認してください。

方法1: サーバーのcronで起動する

WP-CLIを使う（VPS・専用サーバー向け）

WP-CLIがあるなら、実行時刻を過ぎたイベントを直接実行する方法が扱いやすいです。Webサーバーを経由しないので、タイムアウトの影響も受けにくくなります。

crontabは、Webサーバー（PHP）の実行ユーザーで登録します。rootで実行すると、処理中に作られたファイルの所有者がrootになり、あとでWordPressから書き込めなくなる原因になります。

# 例: www-data ユーザーの crontab を編集する（ユーザー名は環境に合わせる）
sudo crontab -u www-data -e

# 5分ごとに実行。flock で前回の処理が終わっていなければ重ねて起動しない
*/5 * * * * flock -n /tmp/wp-cron-example.lock /usr/local/bin/wp --path=/var/www/example.com cron event run --due-now --quiet >> /var/log/wp-cron-example.log 2>&1

ポイントは次のとおりです。

cronの環境では PATH が短いため、wp やPHPはフルパスで書く（which wp で確認）
--path でWordPressのディレクトリを指定する
最初はログをファイルに残し、エラーが出ていないか確認してから出力を減らす
長時間かかる処理がある場合、flock -n で多重起動を防ぐ

マルチサイトでは、wp cron event run はサイトごとに実行する必要があります。

wp --path=/var/www/example.com site list --field=url | xargs -I{} /usr/local/bin/wp --path=/var/www/example.com cron event run --due-now --quiet --url={}

PHPで wp-cron.php を実行する（レンタルサーバー向け）

共用レンタルサーバーで、管理パネルからcronを設定できる場合は、PHPで wp-cron.php を直接実行する方法がよく使われます。PHPのパスやWordPressの設置パスはサーバーごとに異なるので、サーバー会社のマニュアルで確認してください。

*/5 * * * * /usr/bin/php /home/your-account/example.com/public_html/wp-cron.php > /dev/null 2>&1

実行間隔の目安

5分間隔が一般的です。Action Scheduler のキューが多いネットショップなどでは、1〜2分間隔にすることもあります。逆に、処理が少ないブログで1分間隔にしても負荷が増えるだけなので、処理量に合わせて決めます。

方法2: WP-Cronを有効に戻す

サーバーcronが設定できない場合は、wp-config.php の DISABLE_WP_CRON の行を削除するか、false にします。アクセスがあるたびに起動の確認が走るようになり、処理は再開します。ただし、アクセスがほとんどない時間帯は処理が遅れます。

有効に戻しても処理が動かない場合は、サーバーが自分自身へのHTTPリクエスト（ループバック）を送れていない可能性があります。サイトヘルスのループバックに関する項目を確認し、Basic認証やファイアウォールで wp-cron.php へのアクセスが遮断されていないかを見ます。どうしてもループバックが使えない環境向けに ALTERNATE_WP_CRON という定数もありますが、リダイレクトを使う方式で副作用もあるため、最後の手段と考えてください。

方法3: 外部サービスから呼び出す

サーバー側でcronが使えない場合は、外部の監視・cronサービスから https://example.com/wp-cron.php?doing_wp_cron に定期的にアクセスさせる方法もあります。Webサーバー経由になるので、処理が長いとタイムアウトしやすく、Basic認証などをかけているとアクセスできない点に注意します。

Action Scheduler を使うプラグインの場合

WooCommerceなどに含まれる Action Scheduler は、WP-Cronを入口にしてキューを処理します。サーバーcronでWP-Cronを起動していれば通常はそのまま動きますが、処理量が多いサイトでは、WP-CLIから直接キューを実行する wp action-scheduler run コマンドを使う方法もあります（2026年10月現在）。使えるオプションは Action Scheduler の版によって異なるため、wp help action-scheduler run で確認してください。

設定後の確認

数分待ってから wp cron event list を実行し、過去の時刻のまま残っているイベントが減っているか
テスト用の予約投稿を数分後に設定し、時刻どおりに公開されるか
cronのログにPHPのエラーや権限エラーが出ていないか
サイトヘルスの、予定された処理の遅延に関する警告が消えているか

一度動いたあとも、サーバー移行やPHPの更新でcronのパスが変わって止まることがあります。定期的にログを見るか、監視の仕組みを入れておくと安心です。

まとめ

DISABLE_WP_CRON はWP-Cronの自動起動を止める定数で、別の起動手段がないと予約投稿やキューが止まる
wp cron test と wp cron event list で、無効化の有無と処理のたまり具合を確認する
おすすめはサーバーのcronでの起動。WP-CLIなら wp cron event run --due-now、レンタルサーバーならPHPで wp-cron.php を実行する
crontabはWebサーバーの実行ユーザーで登録し、フルパス指定と多重起動の防止を忘れない
サーバーcronが使えなければ定数を外して有効に戻し、ループバック通信が通るかを確認する