公開してよいと承認された記事でも、直ちに公開日時を更新するとは限りません。既存の予約と重ならない日時を選び、対象記事・本文版・日時を照合してから予約へ移す必要があります。
この記事が扱うのは、承認済みの記事を空いている枠へ予約する工程です。予約時刻を過ぎた後に実際に公開されたかを確かめる工程は、第9回（ID 212）の役割であり、ここでは扱いません。
承認と予約を別の判断にする
承認は「内容を公開候補として進められるか」の判断です。予約は「いつ公開するか」の運用判断です。二つを一つの操作にすると、本文の確認と日時の確認のどちらで誤りが起きたか追いにくくなります。
予約へ進める対象は、承認済みで、対象の本文版とレビュー結果が対応している記事に限ります。修正が入った場合は、古い承認をそのまま使わず、変更内容に応じて再確認します。
予約に必要な入力を固定する
予約前に、最低限の入力を一つの記録へそろえます。
| 項目 | 確認すること |
|---|---|
| 投稿ID | 更新対象を取り違えない一意のID |
| タイトルとslug | 予約する記事が意図したものか |
| 本文版 | 承認時に確認した版と一致するか |
| 承認結果 | 承認者、確認日、未解決事項 |
| 希望枠 | 日時、タイムゾーン、投稿頻度 |
| 実行者 | 変更を行う人または処理 |
この情報が分かれている状態で日時だけを更新すると、別の記事を予約するリスクがあります。機密情報や承認用の秘密値を本文や公開メタデータへ残さないことも必要です。
先に予約済み投稿を取得する
空き枠は、カレンダー上で空いて見える日時ではなく、WordPressに登録されている予約済み投稿を基準に判断します。投稿の状態には、公開済みの publish、予約済みの future、下書きの draft などがあります。WordPress公式の投稿ステータスを踏まえ、対象期間の予約済み投稿と、投稿頻度のルールを同時に確認します。
取得時には、投稿ID、タイトル、予定日時、タイムゾーン、ステータスを記録します。ほかの編集者が同時に予約を入れる可能性があるなら、取得から更新までの時間を長く空けず、更新直前にも再確認します。
空き枠の選び方を先に決める
「最も早く空いている日時」を自動的に選ぶだけでは、連続投稿や読者への告知予定を考慮できません。運用ルールとして、例えば次の条件を明文化します。
- 1日に公開できる本数の上限
- 曜日・時刻の基本枠
- 同じシリーズを続けて公開する間隔
- 緊急の訂正や季節性の高い記事を優先する条件
- 編集者が手動で上書きできる条件
ルールに該当する候補を出したら、最終的な日時は人が確認します。時間帯は投稿本文の言語や読者層だけでなく、WordPress側のタイムゾーンと一致しているかを照合します。
dry runで変更内容を読む
実際の更新前に、変更予定だけを表示するdry runを行います。dry runの出力には、少なくとも対象投稿ID、現在の状態、現在日時、候補日時、更新後の状態を含めます。
ここで確認するのは、処理が動いたことではなく、正しい投稿に正しい変更をする予定かどうかです。候補日時が既存予約と重なる、対象が下書きではない、承認情報と本文版が一致しない場合は、更新せず停止します。
予約更新後にWordPressから再取得する
人がdry runを確認した後にだけ、対象記事の日時と予約状態を更新します。更新要求が成功したという応答だけで、予約が正しく保存されたとは判断しません。WordPressから対象投稿を再取得し、投稿ID、ステータス、予定日時、タイムゾーン、slugを照合します。
意図しない日時や状態なら、次の自動処理へ進めず、手動で確認します。変更履歴には、実行日時、変更前後、判断者、停止理由を残すと、後から予約の理由を説明できます。
第9回の公開後検証へ渡す情報
予約が保存された時点では、公開はまだ確認できていません。次の工程へ渡すのは、対象投稿ID、予定日時、タイムゾーン、期待するURL、予約時点のステータスです。
第9回では、予定時刻を過ぎた後に投稿状態を再取得し、公開URLと実際の表示を確認します。この分離により、予約の成功と公開の成功を混同しません。