※PR・広告を含みます
WordPressの管理画面でアイキャッチが表示されていても、画像形式まで正しいとは限りません。拡張子だけを見ず、投稿のfeatured_media、メディアのmime_type、source_url、画像実体を順番に照合すると、WebP設定を機械的に確認できます。
2026年7月30日、このサイトで3件の予約投稿へ画像担当ボットを実行し、メディアID32887・32888・32889を再取得しました。3件ともimage/webp、.webp URL、1280×720のWebP実体を確認できました。その時に使った検査手順を説明します。最終確認日：2026年7月30日
俺のクマ
大明司一利
具体的なチェック手順は、記事からメディアIDを取得し、REST項目を照合し、画像実体を開き、最後に記事との紐付けを再取得する流れです。例えば、どこか一項目が不一致なら、その時点を失敗として記録します。
- 記事のfeatured_media
- メディアのimage/webp
- source_urlの.webp拡張子
- 画像実体のWEBP形式と寸法
投稿からアイキャッチのメディアIDを取得する
検査の起点は画像一覧ではなく対象記事です。投稿IDを指定してWordPress REST APIから記事を取得し、featured_mediaの値を読みます。ゼロならアイキャッチ未設定、正の整数ならその番号が検査対象のメディアIDです。
対象記事を投稿IDで固定する
WordPress REST APIのPosts公式資料には、投稿データのfeatured_mediaがアイキャッチ画像のIDとして定義されています。タイトル検索だけでは同名記事を取り違えるため、予約処理で確定した投稿IDを使います。
取得時はstatus、date、title、featured_mediaを同時に記録します。画像が正しくても記事がdraftやpublishなら予約投稿の検査としては不合格なので、本文側の状態と画像側の状態を一つの記録へ残します。
featured_mediaがゼロなら画像処理を止める
featured_mediaが0の時は、メディア一覧から似た画像を推測してはいけません。画像担当へ対象投稿IDを渡して設定させた後、同じ記事を再取得します。
今回の3件では、画像生成前の旧メディアIDをバックアップへ残し、新しい画像の紐付けを確認してから処理を完了しました。旧画像は削除していないため、問題があれば元のIDへ戻せます。
メディアRESTでMIMEタイプとURLを照合する
featured_mediaで得たIDを使い、メディアREST APIから該当画像を取得します。ここで見る中心項目はmedia_type、mime_type、source_urlです。
mime_typeがimage/webpか確認する
WordPress REST APIのMedia公式資料では、mime_typeは添付ファイルのMIMEタイプ、source_urlは元ファイルのURLとして定義されています。WebP運用ならmime_typeがimage/webpであることを必須にします。
media_typeもimageであることを確認します。アップロード要求が成功しても、想定外のファイル種別や別メディアIDを返していればアイキャッチ検査は通しません。
source_urlの末尾が.webpか確認する
source_urlはクエリー文字列を除いたパスで判定し、拡張子が.webpか確認します。大文字小文字は正規化して比較しますが、.jpg.webpのような不自然な名前は記録して追加確認します。
MIMEタイプだけ合格してURLが.jpgのままなら、キャッシュや変換経路が想定と違う可能性があります。二つの条件が一致するまで成功扱いにしません。
画像ファイルの実体と寸法を確認する
RESTのメタデータだけでなく、source_urlから画像を読み取り、画像ライブラリでフォーマットと寸法を確認します。拡張子の付け替えや壊れたアップロードを検出するためです。
ダウンロードした実体がWEBPか検査する
画像を一時フォルダへ保存し、ファイルヘッダーを解釈できる画像ライブラリでformatを取得します。期待値はWEBPです。HTTPステータス、Content-Type、ファイルサイズも併記すると通信エラーとの切り分けができます。
今回の3画像は、REST上のimage/webpとURLだけでなく、ダウンロード後のformatもWEBPでした。三段階が一致したため、拡張子だけを変えた画像ではないと判断しました。
幅と高さがテンプレートどおりか確認する
画像実体から幅と高さを読み、担当ボットのテンプレートと比べます。このサイトでは1280×720を確認しました。極端に小さい画像や縦横比が違う画像は、文字切れやテーマ表示崩れの候補です。
寸法が合っても文字が切れる可能性はあるため、生成した新規画像は目視確認も行います。自動検査と目視の役割を分けると、空白画像やテキスト欠けを見逃しにくくなります。
記事と画像の紐付けを保存後に再確認する
メディア側のpost項目が0でも、記事側のfeatured_mediaが新しいメディアIDを指していればアイキャッチとして設定されます。判定の中心は記事を再取得した結果です。
記事のfeatured_mediaとメディアIDを一致させる
画像担当の終了コードやアップロード件数だけでは成功にしません。記事を再取得し、featured_mediaが生成されたメディアIDと一致することを確認します。
別記事へ画像が付いた場合、画像自体は正常でも誤サイト操作です。投稿ID、タイトル、予約日時、featured_media、メディアURLを同じ検証レコードへまとめます。
旧画像は削除せず復元経路を残す
新画像へ置き換えた直後に旧メディアを削除すると、表示不良が見つかった時の復元が難しくなります。旧IDをバックアップへ残し、検証完了後もメディアライブラリから消しません。
保存後の再取得で不一致があれば、対象記事だけ旧featured_mediaへ戻します。複数記事を一括で巻き戻さず、投稿IDごとに復元できる形が安全です。
WebP検査を毎日の投稿監査へ組み込む
毎日の監査では、新規記事がある時だけ新しいメディアを検査します。既存画像を毎回作り直さず、今回生成されたメディアIDの差分を対象にします。
記事保存と画像生成の担当を分離する
本文を予約する処理と、アイキャッチを作る処理を別プロジェクトへ分けます。記事側から有料画像APIを呼ばず、サイト専用ボットへ投稿IDだけを渡します。
担当を固定すると、別サイトの認証情報、配色、画像サイズを誤って使う事故を防げます。このサイトではdaimyouji専用の画像担当だけを使用します。
成功条件を四項目で記録する
最終記録には、記事のfeatured_media一致、mime_type=image/webp、.webp URL、画像実体WEBPを残します。必要に応じて寸法と目視結果も追加します。
WordPressのアイキャッチ確認は、管理画面で見えるかどうかだけでは足りません。投稿IDからメディアIDをたどり、REST情報と画像実体を照合することで、WebP運用を再現可能な検査にできます。
