WordPressで本文画像が消える時の確認方法｜連続挿入と保存競合を防ぐ

結論：アップロード済みと本文反映済みは別の状態

WordPressの本文画像は、「画像ファイルがサーバーへ届いた」「メディア項目が作られた」「記事本文に画像ブロックが保存された」「公開ページで画像が読み込まれた」という複数の段階を通ります。メディアライブラリに画像があるだけでは、記事本文へ入ったとは言えません。反対に、本文に古い画像ブロックが残っていても、参照先ファイルが消えていれば公開面では表示できません。

最初にやることは再アップロードではなく、どの段階まで成功しているかの確認です。画像を何度もアップロードすると、同じ名前の添付ファイルが増え、どれが正本か分かりにくくなります。記事ID、メディアID、画像URL、本文内の画像ブロックを対応させれば、必要な再作業だけに絞れます。

WordPress本文画像が表示される4段階

1. 画像ファイルがアップロードされる

最初の段階は、WebP、JPEG、PNGなどのファイルがWordPressへ送信されることです。WordPressのREST APIでは、メディアは投稿とは別のリソースとして扱われ、作成後に固有のID、URL、MIMEタイプ、サイズ、代替テキストなどを持ちます。ここで失敗するとメディアライブラリにも現れません。

2. メディア項目とメタ情報が保存される

アップロードが終わると、画像にはメディアIDが付きます。ALT、タイトル、キャプション、説明は画像ファイルそのものではなく、WordPress側の添付情報として管理されます。記事用画像では、形式と寸法だけでなく、意図したALTがそのメディアIDに入っているかを確認します。

3. 記事のpost_contentへ画像ブロックが保存される

Gutenbergは、編集画面のブロックをコメント付きのHTMLへ直列化し、記事のpost_contentへ保存します。画像を本文へ表示するには、対象メディアIDと画像URLを含むcore/imageブロックが記事本文に必要です。メディア項目の作成に成功しても、この本文更新が失敗または上書きされれば画像は記事に出ません。

4. 公開HTMLから画像URLが読み込まれる

最後に、公開URLをログアウト状態で開きます。画像ブロックがHTMLにあること、画像URLがHTTP 200を返すこと、PCとスマートフォン幅で本文からはみ出さないことを確認します。編集画面の見た目だけで判断せず、読者が見る公開ページを完了判定に使います。

確認場所	分かること	失敗時の次の行動
メディアライブラリ	画像ファイルとメディアIDの有無	なければアップロードをやり直す
メディア詳細	形式、寸法、ALT、画像URL	該当項目だけ修正する
記事編集画面	画像ブロックの位置と件数	対象スロットへ再挿入する
RESTの本文	保存済みの画像IDとURL	保存競合や上書きを疑う
公開ページ	読者が実際に見られる状態	URL、キャッシュ、表示崩れを確認する

画像が消える主な原因を順番に切り分ける

メディアにない場合：アップロード段階の失敗

メディアライブラリに画像がなく、検索しても見つからない場合は、ファイル送信、形式、容量、権限、通信エラーを確認します。ここでは本文の編集を繰り返しても直りません。元ファイルが破損していないことを開いて確認し、WebPなら意図した寸法で保存できているかを見ます。

メディアにある場合：本文反映段階の失敗

メディアIDと画像URLがあるのに記事へ出ない場合は、同じファイルを再送する前に本文を確認します。画像ブロックが存在しない、別の記事IDへ入れた、別のスロットを置き換えた、保存前の内容で上書きした、という可能性があります。記事の編集履歴やRESTのcontent.rawで、意図したwp-image-番号があるかを見ると切り分けが早くなります。

本文にある場合：公開面の読み込み失敗

本文に画像IDがあるのに公開面だけ空く場合は、画像URLのHTTP状態、URLの誤り、キャッシュ、遅延読み込み、CSSによる非表示を確認します。画像ファイルへ直接アクセスして200なら、記事側のHTMLと表示処理へ範囲を絞れます。404なら、本文ブロックではなく参照先ファイルの問題です。

連続挿入で起きる保存競合とは

複数画像を短時間に挿入する機能では、各操作が「現在の本文を読み、画像ブロックを追加し、本文全体を保存する」流れになることがあります。処理Aと処理Bがほぼ同時に古い本文を読み込むと、後から完了した保存が先の変更を含まず、一枚だけ消えたように見える場合があります。これは画像ファイルが壊れたのではなく、本文全体の保存順が競合した状態です。

手動操作でも、複数タブで同じ記事を編集する、保存完了前に別の自動処理を走らせる、古い編集画面を後から保存する、といった状況で似た上書きが起こり得ます。同じ記事を一つの正本画面で扱い、保存完了を確認してから次へ進むことが基本です。

ACS Article Generator v1.3.3の対策範囲

ACS Article Generator v1.3.3では、生成履歴から本文画像を続けて挿入した時の反映欠けを防ぐため、記事ID単位で短時間のロックを取得します。ロック後に最新のpost_contentを読み直し、対象の画像スロットだけを差し替えます。保存後は、スロットを示すマーカーと対象画像IDが本文に存在するかを確認し、確認できなければ成功扱いにしません。

この対策は、他のプラグインや別タブから行われるすべての編集競合を自動解決するものではありません。また、画像の内容、ALTの正確さ、公開面のレイアウトまでは人の確認が必要です。機能が「挿入成功」と返した後も、記事ごとの画像数と公開ページを確認してください。

再挿入する前のチェックリスト

• 対象の記事IDと公開URLが一致している
• メディアライブラリに意図した画像が一件だけある
• メディアID、画像URL、形式、寸法、ALTを記録した
• 記事本文に意図した画像IDがあるか確認した
• 同じ記事を複数タブや複数人で同時編集していない
• 自動保存や画像挿入の完了前に次の処理を重ねていない
• 再挿入するなら欠けたスロットだけを対象にする
• 再保存後に公開HTMLと画像URLを確認する

向いている対応・避けたい対応

よくある質問

まとめ

1. 画像ファイル、メディア項目、本文ブロック、公開HTMLを分ける
2. メディアIDと記事IDを対応させる
3. 連続保存では最新本文の上書き競合を疑う
4. 欠けたスロットだけを再挿入する
5. 公開URLと画像URLのHTTP 200まで確認する

画像を入れて公開まで仕上げる全体手順は「生成履歴・WebP・ALTの公開前チェック」で確認できます。製品の使い方、無料版、ライセンス別の範囲は「ACS Article Generator記事ハブ」にまとめています。

公式情報

• WordPress REST API Handbook: Media
• WordPress Block Editor Handbook: Parser Filters

透過画像を書き出す時の画質と容量を比較する場合は、PNG32とPNG8の違いと選び方も確認してください。