WordPress更新で下書きになる・画像が表示されない時のreadback検証

公開済みの記事に画像を2枚追加し、更新処理は成功と表示されました。画像の登録、本文への挿入、処理の正常終了まで確認できていたため、一見すると問題はありません。

ところが更新後に読み直すと、記事は下書きになっていました。本文には画像が残っていても、読者が読む公開状態は失われていたのです。

WordPressをREST APIなどで更新している運用者にとって、怖いのは書き込みの失敗だけではありません。「反映された」という応答を受け取った後で、公開面が期待どおりでないことです。

書き込み確認と読者確認は別の検査です

更新応答、本文内の要素、メディア登録は必要な証拠です。ただし、読者が受け取れることを示すものではありません。公開済み記事の更新では、公開状態、既存の代表画像、公開ページ、HTML内の各画像URLまで確認します。

以前にまとめた「生きているか」ではなく「働いているか」— 監視を実装するという考え方は、公開更新にも当てはまります。処理が動いたことと、期待した役割を果たしたことは同じではありません。

第1段階：本文は正しくても、記事が公開されていない

最初の更新では、AI生成の構成図を本文の区切りとして2枚追加しました。いずれも実際の製品写真ではないことを注記し、登録と本文への挿入を確認しています。

それでもreadbackでは記事が下書きへ遷移していました。公開状態として復旧後、本文中の2画像、2つのAI生成注記、既存の代表画像が保たれていることを確認しました。公開停止に相当した時間は約1分で、本文・代表画像・登録済み画像の消失はありませんでした。

本文の差分が正しいことと、投稿の状態が正しいことは別の条件です。更新応答に含まれる状態が要求した公開状態と異なるなら、成功として通過させない設計が必要です。

第2段階：公開ページが開いても、画像が読者に届かない

別の記事では、投稿の公開状態、本文マーカー、画像注記、代表画像の不変を確認し、ページ本体もHTTP 200で返っていました。

しかし公開ページから実際のimg srcを取り出して画像本体を取得すると、画像URLが読者向けではないoriginを向いていることが分かりました。ページ内に画像要素があり、運用側から取得できても、外部の読者が表示できるとは限りません。

復旧では本文内の画像URLを公開originへ置き換え、2記事で合計4本の画像URLについて、公開HTTPS URLからHTTP 200、image/png、PNG signatureを確認しました。投稿は公開状態を維持し、既存の代表画像も変わっていません。

完了条件を5項目に分ける

1. 本文に意図した要素がある。
2. 記事の公開状態が期待値である。
3. 代表画像など、意図しない既存要素の変更がない。
4. 公開ページが応答する。
5. HTML中の各img srcが読者向けHTTPS URLで実取得できる。

リンク、埋め込み、ダウンロードファイル、表示状態も同じです。書き込み側の応答は途中経過であり、公開面で取得できることが最後の証拠になります。

人の注意力ではなく、成功判定を変える

恒久対応では、更新応答の状態が要求値と一致しなければ失敗として扱い、本文へ入れる前にMedia URLのoriginを正規化し、公開ページのHTMLから取得した画像URLを公開HTTPS経由で検査するようにしました。関連するfocused testsは67件通過しています。

「反映された」は完了ではありません。公開状態と読者の取得を含めて、初めて完了です。自動化の終点は、こちらが書き込んだ瞬間ではありません。相手が受け取った瞬間です。