本記事は、WordPressの擬似Cron（＝WP-Cron）を安定稼働へ導く実務ガイドです。対象は、予約投稿の遅延やバックアップ・通知の失敗に悩むサイト運用者です。読了後、擬似Cronの限界を補い、システムCron等へ移行して停止時間を減らせます。
■ 現状の課題
WP-Cronはアクセス依存のため、流量や環境で遅延・取りこぼしが起こります。
WP-Cron＝アクセス時に内部でタスクを起動する仕組みです。トラフィックが少ないと起動が遅れ、逆に高負荷やCDN設定で内部通信が遮断されると失敗します。
キャッシュ、ベーシック認証、外部Firewallの組み合わせでループバック通信が失敗し、ジョブが連鎖的に滞留する事例が増えています。
■ 解決の方向性
擬似Cronを最小化し、外部またはシステムCronで定期起動させます。
検知＝失敗ログを見える化し、遅延閾値を数値で管理します。切り分け＝WP内部要因と外部要因を分離し、順に除去します。復旧＝手動実行の標準手順を整備し、再発を防ぎます。
共有サーバーでは外部Cronサービス、VPSや専用環境ではシステムCron（＝OSのCron）を用い、安定起動と再試行を担保します。
■ 具体的な方法（実務手順）
・まずDISABLE_WP_CRONを有効にし、擬似Cronの自動起動を止める。
・管理画面やWP-CLIで未実行タスクと次回実行時刻を棚卸しする。
・共有サーバーでは外部Cronを5分間隔でwp-cron.phpへHTTP実行する。
・VPS等ではOSのCronでWP-CLIを使い、5分でイベントを確実に起動する。
・長時間タスクは分割し、実行時間上限とリトライ間隔を明示する。
・失敗時はステータスを記録し、Slack等へ即時通知する。
・月次で実行時間分布と失敗率を可視化し、閾値超過を運用改善へ繋げる。
■ 注意点とまとめ
二重起動、タイムゾーン差、タイムアウトの三点に注意します。
二重起動防止のため、ロックファイルやトランジェントで排他制御を設けます。タイムゾーンはJSTで統一し、サーバー時刻のずれを監視します。タイムアウトは上限を設定し、再試行戦略を事前に決めます。
まとめとして、擬似Cron依存を減らし、外部またはシステムCronで定期実行に切り替えることが、遅延と失敗を同時に減らす近道です。
まとめ
結論は、WP-Cronの起動責務をOSまたは外部Cronへ移し、監視と再試行で補強することです。
今日からの行動は、擬似Cron停止→5分Cron設定→失敗通知→月次レビューの順で固定化します。
よくある質問（FAQ）
Q1：共有サーバーでも効果はありますか？
A1：はい。外部Cronの5分間隔起動だけでも遅延は大幅に減ります。
Q2：二重実行が心配です。
A2：排他制御（ロック）を導入すれば防げます。長時間タスクは分割が有効です。
Q3：最適な実行間隔はどれくらいですか？
A3：多くのサイトは5分で十分です。負荷や要件に応じて短縮・延長します。
Q4：通知は何を見ればよいですか？
A4：失敗回数、最大遅延、平均実行時間の三指標を最低限モニタします。
Q5：キャッシュやCDNと競合しますか？
A5：内部実行（WP-CLI）なら影響は最小です。HTTP実行時は除外ルールを設けます。
Q6：予約投稿だけ直れば良いのですが？
A6：予約投稿もCron起動に依存します。全体設計を直す方が再発を防げます。
ご案内
本記事の内容に沿った運用整備（棚卸し表の作成支援、実行間隔の設計、通知ルートの整備、復旧手順の標準化）にもご対応可能です。事実に基づき、再現性を重視した設計を行い、特定ツールに依存しない内製化を大切にしています。万一の障害や緊急時にも、可能な限り迅速に対応いたしますので、どうぞ安心してご相談ください。
.png)
