GitHub ActionsからWordPressへ記事を自動投稿するとき、本文だけならREST APIのposts endpointで送れます。しかし実運用では、アイキャッチ画像まで自動設定できないと、公開後に手作業が残りやすくなります。WordPressでは投稿とメディアが別リソースなので、画像URLをそのまま投稿へ渡すのではなく、先にmedia endpointへ画像を登録し、返されたmedia IDをposts endpointのfeatured_mediaへ設定するのが基本です。
この記事では、単にAPIの使い方を並べるのではなく、画像登録→ID取得→alt設定→記事公開→production QA→失敗時cleanupまでを一連の運用として整理します。GitHub Actionsからの認証設計はApplication PasswordsとGitHub Actions Secretsの安全な使い方、投稿全体の構成はGitHub ActionsでWordPress投稿を自動化する方法とあわせて読むと理解しやすくなります。
結論：画像を先に登録し、返されたmedia IDをfeatured_mediaへ渡す
WordPress公式REST APIでは、メディア作成用に/wp/v2/mediaが用意されています。画像をアップロードするとメディア項目が作成され、レスポンスのidを取得できます。投稿側のposts endpointにはfeatured_mediaフィールドがあり、この整数IDを指定することでアイキャッチ画像として関連付けられます。
- 画像ファイルを用意する
POST /wp-json/wp/v2/mediaでアップロードする- レスポンスからmedia IDを取得する
- 必要に応じて
alt_textを設定する - 投稿作成・更新時に
featured_mediaへIDを渡す - REST APIと公開URLの両方で結果を確認する
- 途中失敗なら今回作成した未使用メディアだけをcleanupする
media endpointへのアップロードで守るポイント
画像アップロードでは、認証済みリクエストに画像バイナリを送り、MIME typeに合ったContent-Typeとファイル名を示すContent-Dispositionを設定します。認証情報はGitHub Secretsから環境変数へ渡し、workflowや記事ファイルへ固定値として保存しません。またデバッグ時にAuthorizationヘッダー全体をログ出力しない設計が必要です。
POST /wp-json/wp/v2/media
Content-Type: image/png
Content-Disposition: attachment; filename="article-featured.png"
Authorization: Basic ...アップロード成功後は、ファイル名やURLから後検索するのではなく、そのレスポンスに含まれるidをそのrun内で保持する方が安全です。同名ファイルが複数ある環境でも、今回作成した画像を取り違えにくくなります。
featured_mediaには画像URLではなく整数IDを入れる
posts endpointのfeatured_mediaへ渡すのは画像URLではなくmedia IDです。新規投稿なら、画像登録成功後に記事payloadへIDを含めます。
{
"title": "記事タイトル",
"slug": "article-slug",
"status": "publish",
"content": "...",
"featured_media": 1234
}ここで重要なのは、同一slugの既存投稿を不用意に上書きしないことです。新規公開workflowでは事前にslug重複を確認し、既存記事が見つかった場合は明示的に更新を許可していない限りfail-closedにする方が安全です。
alt textはメディア側で設定する
アイキャッチ画像を自動生成・自動登録する場合でも、alt textを放置する必要はありません。media endpointで作成したmedia IDに対して更新を行い、画像内容を自然に説明するalt_textを設定できます。SEO目的でキーワードを詰め込むのではなく、実際の画像と一致する説明にします。
既存記事のリライトでは逆に、更新前のfeatured_mediaを保持し、本文更新が誤って0や別IDへ変えていないことをQAする必要があります。新規公開と既存更新では「新しい画像を関連付ける処理」と「既存画像を保持する処理」を分けます。
公開後QAは画像IDだけで終わらせない
REST APIでfeatured_mediaが設定されていても、本番成功とは限りません。テーマ側の表示、canonical、robots、キャッシュ、記事本文など別レイヤーの問題が残る可能性があります。公開後は最低でも次を確認します。
- 公開URLがHTTP 200
- 想定タイトルと固有本文が表示される
- canonicalが公開URL自身を指す
- 公開対象なのにnoindexが付いていない
- REST API上の
featured_mediaが0ではない - 内部リンクが正しいURLを向く
- PHP fatal errorなどの異常表示がない
公開後検証の設計はWordPress自動投稿の公開後QA設計で詳しく整理しています。画像設定はproduction QAの一部であり、画像アップロード成功だけを完了条件にしないことが重要です。
途中失敗時は今回作った未使用メディアだけをcleanupする
自動化では「画像アップロードは成功したが記事公開は失敗した」という中間状態が発生します。これを放置すると未使用メディアが増え続けます。cleanup対象は今回のrunで新しく作ったmedia IDだけに限定し、既存記事で使われていた画像を削除しないようにします。
記事作成後のQAで失敗した場合は、新規記事なら下書きへ戻す、既存記事更新なら更新前の本文やfeatured_mediaへrollbackするなど、書き込み対象に応じて復旧方法を変えます。例外を握りつぶしてActionsが終了しただけで成功扱いにしないことが重要です。
GitHub Actionsでは責務を分ける
運用を安定させるには、1つの巨大スクリプトへ全部を埋め込むより、content gate、media uploader、post publisher、production verifier、state recorderに責務を分ける方が保守しやすくなります。認証値はSecretsから渡し、必要以上のGITHUB_TOKEN権限を与えません。
AIBlogBaseでは、単にAIで記事を書くことより、公開後に壊れた状態を残さない運用を重視しています。無料のAIBlogBase Liteを使う場合でも、最初から全工程を自動化する必要はありません。まず通常投稿を安定させ、その後に認証、本文投稿、メディア、production QAの順で機能を追加すると障害箇所を切り分けやすくなります。
まとめ
WordPress REST APIでアイキャッチ画像を自動設定するときは、media endpointへ画像を登録し、返されたmedia IDをposts endpointのfeatured_mediaへ設定します。安全な本番運用では、ID取得、alt設定、既存slug guard、公開後HTTP・canonical・indexability・本文QA、失敗時cleanupまでを一つの処理として設計します。
この流れをGitHub Actionsに組み込むことで、「画像は登録されたが記事が壊れた」「記事は公開されたが画像が紐づいていない」といった途中成功を完了扱いせず、再利用できるWordPress自動公開フローにできます。
