WordPress予約投稿を7日分確保して停止に備える方法

記事投稿ツールが一時停止しても、WordPressにfuture予約が残っていれば公開は続きます。ただし予約総数が多いだけでは不十分です。翌日から各日に最低一件が入り、途中に空白日がないかを確認する必要があります。

2026年7月30日にこのサイトを認証付きRESTで再取得したところ、公開469件、予約1件、下書き37件でした。予約は7月31日だけで、8月1日から6日分が不足していました。この実測をもとに、連続7日を最低安全在庫として補充する手順を説明します。最終確認日：2026年7月30日

予約安全在庫を日付の連続性で測る

安全在庫は『futureが何件あるか』ではなく、『明日から何日連続で一件以上あるか』で測ります。遠い日付に予約が集中していても、手前に空白日があれば自動公開はそこで途切れます。具体的なチェック項目は次の四つです。

• 翌日からの連続予約日数
• 最初の不足日
• 連続区間の最終予約日
• 日別のfuture件数

翌日を起点に一日ずつ確認する

日本時間の翌日を起点に、future投稿を日付ごとに数えます。最初のゼロ件の日で連続日数を止め、その日から7日目までを不足日として一覧にします。

今回の監査では7月31日に一件あり、8月1日が最初の空白でした。そのため連続予約日数は一日、最低7日基準に対する不足は6日です。8月4日以降に予約があっても、この不足判定は変えません。

サーバー時刻ではなく運用時刻へそろえる

WordPressのdateはサイト設定の時刻、date_gmtは協定世界時です。監査側で混在させると公開日を一日ずらして数える可能性があります。サイトのタイムゾーンを確認し、集計と保存を日本時間へ統一します。

日付境界に近い処理では特に注意が必要です。翌日の定義をローカル時刻で固定し、予約日時は時刻まで表示して確認します。

WordPressの全状態を取得して候補を分ける

WordPress REST APIのPosts公式資料では、futureのほかpublish、draft、pending、privateなどの状態を扱えます。安全在庫補充では、予約枠の確認と重複確認で参照範囲を分けます。

予約枠はfutureだけで集計する

公開済み記事を予約在庫へ数えず、futureだけを予約日別に集計します。期限を過ぎてもfutureのまま残る投稿があれば、正常な在庫ではなく公開失敗候補として別に扱います。

同じ日に既に一件ある場合は上書きせず、次の不足日へ進みます。一日一件運用なら、追加記事を同じ日へ詰め込んでも停止期間を延ばせません。

重複確認では公開・予約・下書きを見る

候補記事の重複はpublishとfutureだけでなく、draftも含めて確認します。タイトルが違っても、想定読者、検索意図、結論、見出しが重なる記事は補充候補から外します。

下書きが多いからといって、日付だけ変えて予約してはいけません。今回の37下書きは構文とSEOの再確認が必要だったため、実運用の根拠を追加できる記事から個別に直しました。

不足日の早い順に一回最大三件を補充する

安全在庫が不足している時は、通常の一日一記事作成より補充を優先します。ただし一度に大量変更すると検証漏れが増えるため、一回最大三件に区切ります。

最初の空白日から予約する

例えば今回なら8月1日、2日、3日の順に候補を割り当てます。遠い日から埋めると、直近の停止耐性が上がりません。各日9時の既存枠を再確認し、空いている場合だけ保存します。

三件を予約した後は、futureを全件取り直して連続日数を再計算します。今回の一回だけでは7日へ届かないため、次回は残る不足日の早い順に続けます。

品質基準を在庫不足の理由で下げない

不足を埋めるために一般論の記事や重複記事を公開すると、AdSenseや検索品質の別問題を増やします。一次情報、固有の検索意図、実測値、注意点、本文形式、SEOを満たさない候補は下書きへ残します。

Googleの人を第一に考えたコンテンツの公式資料でも、独自情報、実体験、明確な出典、読者が目的を達成できる内容が確認項目として示されています。在庫日数は品質免除の条件ではありません。

保存前後の検査を記事単位で残す

補充対象ごとに、投稿前ガード、変更前バックアップ、保存後REST再取得を行います。三件をまとめて保存して最後に見るのではなく、一件ずつ完了させる方が復元範囲を限定できます。

本文・SEO・画像を別項目で確認する

本文は見出し、リンク、ショートコード、禁止表現を確認し、focus keywordは記事ごとに固有の語を設定します。アイキャッチは担当ツールでWebP化し、元画像は削除しません。

保存後はstatus=future、投稿ID、予約日時、タイトル、本文、カテゴリー、タグ、featured_mediaを再取得します。画像はメディアID、image/webp、.webp URLの三点を照合します。

失敗した記事だけを変更前へ戻す

二件目のSEO設定や画像処理が失敗した場合、一件目まで取り消す必要はありません。投稿ID別バックアップを使い、失敗した記事だけdraftと元の本文・日時・画像へ戻します。

復元後もfutureを再取得し、成功した記事と空白日を再計算します。部分成功を全件成功と誤認しないためです。

毎朝の監査で7日分を維持する

七日分を一度用意しても、毎日一件ずつ公開されるため残日数は減ります。毎朝の投稿処理後に安全在庫を計算し、不足が出たら最初の空白日へ補充します。

公開成功と予約補充を分けて監視する

昨日の予約記事が公開されたか、翌日以降の在庫が残っているかは別の確認です。公開済みへ移った記事をfuture在庫に数えず、公開失敗のfuture残留も検出します。

専用タスクが実行されなかった日は、記事生成を始める前に原因を確認します。認証、ネットワーク、権限の問題があれば外部サービスへ切り替えず、既存のfutureが何日持つかを報告します。

連続日数と最終予約日を毎回報告する

監査結果にはfuture総件数だけでなく、翌日からの連続予約日数、最終予約日、不足日、今回補充した投稿IDを残します。この四項目があれば、停止へ備えられる残り時間を判断できます。

予約安全在庫の目的は記事を大量にためることではありません。品質を保ったまま、Codexや専用タスクが止まってもWordPress単独で公開を続けられる時間を作ることです。