WordPressの予約投稿に失敗する|WP-Cronの確認と定期実行への切り替え
予約投稿が時刻どおり公開されないときに、時刻設定・アクセス・WP-Cronイベント・ループバック・サーバーcronを順番に確認する手順です。
この記事でわかること
先に答え:WP-Cronは「指定時刻に常駐して動く時計」ではない
WordPressの予約投稿や一部の更新確認、プラグインの定期処理にはWP-Cronが使われます。WordPress公式資料によると、WP-Cronはページが読み込まれたときに期限を過ぎたタスクを確認して実行します。システムのcronのように常時動作しているわけではありません。
そのためアクセスが少ないサイトでは、14時に予約した投稿が14時ちょうどに公開されず、次にページが読み込まれた機会に実行される場合があります。まず、管理画面の時刻設定・投稿状態と、WP-Cronそのものの遅延を分けて確認します。
「予約時刻の間違い」と「Cronが動かない」を分ける
予約投稿が出ないときは、いきなりプラグインを追加せず、画面上で確認できる範囲から始めます。
| 確認 | 見る場所 | 判断 |
|---|---|---|
| サイトのタイムゾーン | 設定→一般 | UTCとの差、都市指定を確認 |
| 投稿状態 | 投稿一覧・編集画面 | 下書き、予約済み、予約投稿の失敗を区別 |
| 予約日時 | 編集画面 | 日付、午前・午後、タイムゾーン |
| 現在時刻 | サイトヘルスや管理画面 | サーバー時刻だけで断定しない |
| 直前の変更 | 更新履歴 | キャッシュ、保守、プラグイン、移転 |
手動で「公開」すると表示できる場合、記事本文やテーマではなく予約処理側が疑われます。ただし、手動公開すると元の失敗状態が消えて調査材料が減るため、投稿ID、予約時刻、画面の状態、確認時刻を先に記録します。
WP-Cronの動きを理解して切り分ける
WordPress公式は、WP-Cronが各ページ読み込みで予定タスクの一覧を確認し、実行時刻を過ぎたタスクを呼び出すと説明しています。アクセスがなければ遅れる可能性があります。一方、アクセスがあるのに長時間動かない場合は別の原因を疑います。
- 公開ページを通常どおり一度開き、数分後に投稿状態を再確認する。
- 同じ時刻帯に複数の予約投稿・バックアップ・メール送信等が集中していないか確認する。
wp-config.phpにDISABLE_WP_CRONがあるか、値がtrueかを担当者へ確認する。- セキュリティ機能、Basic認証、CDN、WAF等が
wp-cron.phpやループバックを妨げていないか確認する。 - PHPエラー、メモリ不足、実行時間超過、データベースエラーを同時刻のログで確認する。
- WP-CLIを使える場合、予定イベントの一覧と期限超過を確認する。
wp cron event list
wp cron event run --due-nowwp cron event run --due-now は実行期限を迎えたイベントをその場で実行します。これは確認・復旧の手段であり、失敗原因を直す代わりではありません。実行前にバックアップ、対象環境、コマンド権限を確認し、本番で何度も繰り返しません。
イベント一覧から分かること
WP-CLIの wp cron event list は、hook、次回実行時刻、相対時間、繰り返し間隔等を表示します。予約投稿に関係するイベントがない場合と、あるのに期限を過ぎている場合では調査先が違います。
| 状態 | 疑う場所 | 次の確認 |
|---|---|---|
| 対象イベントがない | 予約登録、投稿状態、プラグイン | 投稿IDと予約時刻、再予約の結果 |
| イベントが期限超過 | WP-Cron起動、ロック、ループバック | DISABLE_WP_CRON、アクセス、ログ |
| 実行するとエラー | hook先の処理、PHP、DB | エラーログと該当プラグイン |
| イベントが大量重複 | 登録コード、プラグイン | 同じhookの重複、更新前後の差分 |
| 一度動くがまた遅れる | 低アクセス、処理集中 | システムcron化、間隔、監視 |
WordPressの開発資料は、同じイベントをページ読み込みごとに無条件で登録すると重複が大量に作られるため、wp_next_scheduled() で既存予定を確認するよう案内しています。イベント数が異常に多い場合は、予約投稿だけでなくプラグイン実装も調査対象です。
時刻どおり必要なら、サーバーのタスクスケジューラーを検討する
更新通知や予約投稿を一定間隔で確実に起動したい場合、ホスティングが提供するcron・タスクスケジューラーでWordPressのCronを呼び出す構成を検討します。共有サーバーでは画面に「Cron設定」「定期実行」等が用意されている場合があります。
重要なのは順番です。先にサーバー側の定期実行が成功することを確認し、その後で必要ならページ読み込み時のWP-Cronを無効化します。 DISABLE_WP_CRON だけを先に設定すると、代替の呼び出しがなくなり、予約投稿だけでなく他の定期処理も止まり得ます。
WordPress公式の2025年3月20日更新資料は、システムのタスクスケジューラーから wp-cron.php を呼び出し、重複実行を避けるため wp-config.php に次を設定する方法を示しています。
define( 'DISABLE_WP_CRON', true );ただし、呼び出し方法、最短間隔、実行ユーザー、PHPパス、外部HTTPの可否はホスティングごとに異なります。記事のコマンドをそのまま貼らず、契約先の公式手順を使います。
切り替え後の確認
- サーバー側ジョブの実行履歴・終了状態を確認する。
wp cron event listで期限超過が解消するか確認する。- 数分後の架空テスト投稿を一つ予約し、公開時刻を記録する。
- 公開ページ、サイトマップ、キャッシュ、通知を確認する。
- バックアップやメール等、他の定期処理も止まっていないか確認する。
- ジョブ失敗時の通知先と復旧手順を残す。
失敗したときの分岐
| 現象 | 最初に確認 | 対応の方向 |
|---|---|---|
| 低アクセス時だけ遅れる | ページ読み込み依存 | サーバーcronを検討 |
| すべての定期処理が止まる | DISABLE_WP_CRON と代替ジョブ | 先に有効な起動経路を復旧 |
| 予約投稿だけ失敗 | 投稿状態、時刻、関連hook | 投稿IDとイベントを照合 |
| Cron実行で500/PHPエラー | エラーログ、メモリ、プラグイン | 原因処理を特定し更新・修正 |
| 同じ処理が何度も走る | 重複イベント、二重起動 | ページ起動とシステムcronの構成を確認 |
| 管理画面では成功、公開側が古い | ページ/CDNキャッシュ | 公開URLの応答とキャッシュを別確認 |
そのまま使える調査・変更依頼文
対象サイト:https://example.com/
投稿ID:____
予約日時(サイト表示):2026-10-13 09:00
サイトのタイムゾーン:____
確認日時(UTC):____
投稿状態:予約済み/予約投稿の失敗/下書き
公開ページを開いた後の変化:____
DISABLE_WP_CRON:なし/false/true/未確認
wp cron event list の対象行:____
同時刻のPHP・サーバーログ:____
サーバーcron:未設定/設定済み(間隔__分)
切り替え順:代替ジョブ成功確認→WP-Cron無効化
戻し方:____予約投稿の「予定」は秒単位の配信保証ではありません。必要な時刻精度とサイトのアクセス量を整理し、重要な運用では定期実行の成否を監視できる構成にします。
SITE PORTを検討するときの確認ポイント
サイト制作を依頼する場合は、画面の見た目だけでなく、この記事で扱った設定を誰が担当するか、公開後の変更や障害確認をどこまで依頼できるかを先に確認します。SITE PORTの完成例と編集デモでは、完成イメージと日常的な編集の流れを確認できます。DNS、サーバー、WordPressの定期処理、HTTPヘッダー等は通常の本文編集と同じ範囲で扱えるとは限らないため、必要な作業を具体的に伝え、対応範囲を確認してください。
関連記事
[WordPress更新の確認手順](/articles/wordpress-update-rollback-checklist)・[WordPressバックアップの準備](/articles/wordpress-backup-restore-plan)・[更新が反映されないとき](/articles/website-update-not-visible)
出典・確認情報
確認日:2026-10-12 / 公式情報の要点と編集部の提案を整理しています。価格・機能・条件は変更される場合があります。
WordPress Plugin Handbook:CronWordPress:Understanding WP-Cron SchedulingWordPress:Hooking WP-Cron Into the System Task SchedulerWP-CLI:wp cron event listWP-CLI:wp cron event run
