WordPressでは、予約投稿、更新確認、一部プラグインの定期処理などを決められたタイミングで実行するために「WP-Cron」という仕組みが使われています。
ただし、WP-CronはLinuxのcronのようにOSが正確な時刻に実行する仕組みではありません。基本的にはサイトへのアクセスをきっかけに、実行予定時刻を過ぎた処理がないか確認して動かす仕組みです。
30秒でわかる結論
- WP-CronはWordPress内の予約・定期処理を動かす仕組み
- 予約投稿、更新確認、プラグインの定期処理などで使われる
- OSのcronとは違い、通常はサイトへのアクセスをきっかけに動く
- アクセスが少ないサイトでは、予定時刻より遅れて実行されることがある
- 動かないときは、サイトヘルス、ループバック、プラグイン、サーバー制限などを確認する
- 高アクセス・重要処理があるサイトでは、system cronからwp-cron.phpを定期実行する方法もある
- 通常の共用レンタルサーバー利用者は、問題がなければWP-Cronを無理に変更しなくてよい
WP-Cronとは?
WP-Cronは、WordPressが時間指定の処理を管理するための仕組みです。
WordPress本体やプラグインは、「○時になったら実行」「1時間ごとに実行」「1日ごとに実行」といった処理をWP-Cronへ登録できます。
代表的な用途
- 予約投稿の公開
- WordPress本体の更新確認
- プラグイン・テーマの更新確認
- 一部プラグインのメール送信
- バックアップ処理
- データ整理・一時データ削除
- 外部サービスとの定期同期
WordPress公式では、WP-Cronを「時間ベースのタスクを扱う仕組み」と説明しています。
WP-Cronはどうやって動く?
WP-Cronは、通常のOSレベルのcronと違って常時動作しているわけではありません。
基本的には、サイトへアクセスがあったときに「実行時刻を過ぎた処理がないか」を確認します。
例:15:00に予約投稿
ただしWP-Cronは常時監視していない
期限を過ぎたイベントがないか確認
予約投稿などが処理される
アクセスが少ないサイトの例
15:00に予約投稿を設定していても、15:00以降に誰もサイトへアクセスせず、最初のアクセスが15:20だった場合、投稿処理が15:20ごろまで遅れることがあります。
WP-CronとLinuxのcronの違い
| 項目 | WP-Cron | Linux cron |
|---|---|---|
| 動作主体 | WordPress | OS |
| 実行契機 | 通常はサイトアクセス | 設定した時刻・間隔 |
| 時刻の正確さ | アクセス状況で遅れることがある | 比較的正確 |
| 初心者の扱いやすさ | 設定不要で使える | サーバー設定が必要 |
| 共用サーバー | 標準で使いやすい | 利用可否はサービス次第 |
通常サイトはWP-Cronでよい
一般的な個人ブログや会社サイトで問題が起きていないなら、WP-CronをLinux cronへ置き換える必要はありません。
WP-Cronで使われる主な実行間隔
WordPressには標準でいくつかのスケジュール間隔があります。
| 名称 | 間隔 |
|---|---|
| hourly | 1時間ごと |
| twicedaily | 12時間ごと |
| daily | 24時間ごと |
| weekly | 7日ごと |
プラグインは独自の間隔を追加することもできます。
「1時間ごと=毎時00分」ではない
WP-Cronは基本的に「最初の実行時刻から1時間後」のような間隔管理です。さらにサイトアクセスが契機になるため、正確に毎時00分へ実行されるとは限りません。
WP-Cronが動かないと何が起こる?
WP-Cronが正常に動かないと、WordPress本体よりもまず「時間で実行する処理」に影響が出ます。
予定時刻になっても公開されない、または遅れて公開されることがあります。
WP-Cronを利用するプラグインでは定期バックアップが実行されない可能性があります。
WordPress本体・テーマ・プラグインの更新確認が遅れる場合があります。
メール送信・データ同期・一時データ削除などが止まる場合があります。
WP-Cronが動かない主な原因
サイトへのアクセスがほとんどない
WP-Cronは通常、ページ読み込みをきっかけに動くため、アクセスが少ないサイトでは予定時刻を過ぎても処理が始まらないことがあります。
ループバックリクエストが失敗している
WordPressは自分自身のURLへ接続する「ループバックリクエスト」を利用してWP-Cronを起動します。
ファイアウォール、Basic認証、DNS、SSL、サーバー設定、セキュリティプラグインなどが原因で自分自身へ接続できないと、WP-Cronが正常に起動できないことがあります。
wp-config.phpでWP-Cronが無効化されている
wp-config.phpに次のような設定があると、通常のWP-Cron起動は無効になります。
define( 'DISABLE_WP_CRON', true );
この設定を使う場合は、代わりにsystem cronなどからwp-cron.phpを定期実行する構成が必要です。
プラグイン・テーマの競合
WordPress公式でも、ループバック失敗の代表的な原因としてプラグイン・テーマの競合を挙げています。
サーバー側の制限
ファイアウォール、WAF、HTTP認証、外部通信制限、DNS設定など、WordPress以外のサーバー環境が原因になる場合もあります。
WP-Cronが動かないときの確認手順
予約投稿だけか、複数の定期処理が止まっているか確認
ループバック関連の警告がないか見る
DISABLE_WP_CRONが設定されていないか確認
競合がないか確認
WAF・Basic認証・DNS・SSLなどを確認
アクセス依存を避ける必要がある場合だけ検討
サイトヘルスで確認する
WordPress管理画面の「ツール → サイトヘルス」では、ループバックリクエストや予約イベントに関する問題が表示されることがあります。
確認する項目
- 重大な問題が出ていないか
- ループバックリクエストに失敗していないか
- バックグラウンド更新に問題がないか
- REST APIなど他の通信エラーも同時に出ていないか
WP-Cronだけでなく複数の通信系エラーが出ている場合、サーバー側のHTTP通信やセキュリティ設定を疑います。
予約投稿が失敗するときの確認ポイント
「予約投稿の失敗」はWP-Cronの異常を発見する代表的な症状です。
確認順
- サイトへ通常アクセスできるか
- サイトヘルスにループバックエラーがないか
- タイムゾーン設定が正しいか
- WP-Cronが無効化されていないか
- セキュリティプラグインが通信を遮断していないか
- サーバー会社の障害・制限がないか
予約投稿だけ失敗する場合でも、まずWordPress本体・プラグイン・サーバーのどこが原因かを切り分けてください。
WP-Cronのイベントを確認する方法
技術者向けには、WP-CLIを使ってWP-Cronの状態を確認できます。
WP-CLIには、WP-Cronの起動テスト、イベント一覧、期限到来イベントの実行などのコマンドがあります。
代表的な確認
wp cron test:WP-Cronの起動システムをテストwp cron event list:登録イベントを一覧表示wp cron event run --due-now:期限到来イベントを実行
初心者は無理にWP-CLIを使わなくてよい
共用レンタルサーバーではWP-CLIが利用できない場合もあります。まずサイトヘルスとサーバー管理画面、公式サポートで確認すれば十分です。
system cronへ切り替える方法は必要?
WP-Cronのアクセス依存を避けたい場合、サーバー側のcronからwp-cron.phpを定期実行する方法があります。
その場合、通常のページアクセス時にWP-Cronを起動しないよう、wp-config.phpでWP-Cronを無効化し、代わりのcronを確実に設定します。
切り替えを検討するサイト
- 予約処理の時刻精度が重要
- アクセスが極端に少ない
- 高アクセスで毎回のcron確認を減らしたい
- EC・会員サイトなどで定期処理が重要
- VPSなど自分でcronを管理できる
ただし、WordPress公式もWP-Cronは性能を考慮して設計されており、必要性がなければ置き換えは必須ではないとしています。
system cronへ切り替えるときの注意点
先にDISABLE_WP_CRONだけ設定しない
WP-Cronを無効化したのに代わりのcronを設定していなければ、予約処理が止まります。
実行間隔を短くしすぎない
1分ごとなど高頻度で実行すると、そのサイトに必要以上の負荷をかける場合があります。用途とサーバー仕様に合わせます。
レンタルサーバーの公式手順を優先する
cronの登録方法、PHPパス、実行コマンド、最小実行間隔はサービスごとに異なります。
切り替え後に予約投稿などをテストする
設定しただけで終わらず、実際に予約投稿やプラグインの定期処理が動くか確認します。
通常の共用レンタルサーバー利用者は何をすればよい?
予約投稿などが正常なら何もしなくて構いません。
自動更新・バックアップ・予約投稿に問題がないか定期確認します。
予約処理が遅れるならsystem cronなどを検討します。
定期処理の重要度と負荷を確認し、system cronによる安定運用を検討します。
教科書判定
初心者はWP-Cronを自分で設定し直す必要はない。予約投稿や定期処理に問題が出たときだけ確認する
一般的な共用レンタルサーバーでは、WordPress標準のWP-Cronで十分なケースが多いです。
「高速化のため」という理由だけでDISABLE_WP_CRONを設定するのは避けてください。代替cronを用意しなければ予約投稿や定期処理が止まります。
アクセスが少なく実行時刻が遅れるサイト、またはEC・会員サイトなど定期処理が重要なサイトでは、レンタルサーバーのcron機能やsystem cronへの切り替えを検討してください。
FAQ
Q.WP-Cronは普通のcronと同じですか?
違います。WP-CronはWordPress内の疑似的なスケジューラで、通常はサイトアクセスをきっかけに実行されます。OSのcronは設定した時刻や間隔でサーバー側から実行されます。
Q.WP-Cronを無効化するとWordPressは速くなりますか?
必ず速くなるとは限りません。WordPress公式もWP-Cronは比較的軽量に設計されているとしており、問題がなければ無理に置き換える必要はありません。
Q.予約投稿が数分遅れるのはWP-Cronが原因ですか?
可能性があります。特にアクセスが少ないサイトでは、予定時刻後のアクセスまでWP-Cronが起動せず、遅れて実行されることがあります。
Q.wp-cron.phpは削除してよいですか?
削除しないでください。WordPressの定期処理に使われるコアファイルです。WP-Cronをsystem cronから起動する構成でもwp-cron.phpを利用する場合があります。
Q.WP-Cronが動いているか初心者でも確認できますか?
まず予約投稿が正常に公開されるか、サイトヘルスにループバックや予約イベントのエラーがないかを確認してください。技術者はWP-CLIなどでも詳細確認できます。
まとめ
この記事の結論
- WP-CronはWordPressの予約・定期処理を動かす仕組み
- 通常はサイトアクセスをきっかけに期限到来イベントを実行する
- 予約投稿・更新確認・プラグインの定期処理などに使われる
- アクセスが少ないと予定時刻より遅れることがある
- 動かない場合はサイトヘルス・ループバック・wp-config.php・プラグイン・サーバー設定を確認する
- system cronへの切り替えは必要なサイトだけでよい
- DISABLE_WP_CRONだけ設定して代替cronを用意しないのは避ける
- 通常の共用レンタルサーバー利用者は問題がなければ標準設定のままでよい
「cronとは?定期処理の仕組みを初心者向けに解説」もあわせて確認してください。