Claude Codeでアイキャッチ画像を自動生成してWordPressに投稿する方法

※本記事にはアフィリエイト広告（PR）が含まれます。

【概　要】

記事の執筆はAIの自動投稿で10分程度で形になるのに、最後の最後、アイキャッチ画像で30分間も要してしまう。当サイトを運営していて一番「もったいない」と感じたのが、この工程でした。

本文を書き終えた高揚感のまま公開ボタンを押したいのに、画像素材を探し、サイズを合わせ、文字を載せ、書き出して、フォルダに入れて、管理画面でアップロードして、アイキャッチに設定する。作業自体は簡単ですが、1本あたり20〜30分の「手作業」が毎回入ると、記事の投稿頻度そのものが落ちます。

この記事では、現暗号資産ニュースメディア編集長の私が、Claude Codeを使ってアイキャッチ画像の生成からWordPressへの投稿・紐付けまでを一本のパイプラインにした手順を、実装レベルで公開します。画像生成AIの選び方と費用感、WordPressのメディアAPIを叩くときの具体的なHTTPヘッダー、そして実際に3回つまずいたエラーとその原因まで、遠回りも含めて詳しく紹介します。

コードを書いたことがない方でも、「Claude Codeに何をどう頼めばいいか」が分かるように構成しました。

【目　次】

1. なぜアイキャッチ作成を自動化しようと思ったのか

本文執筆の生産性は上がるも、公開までの時間があまり縮まらない

AIツールを導入すると、まず記事本文の執筆スピードが上がります。ところが実際に運用してみると、公開までのリードタイムはそれほど縮まりませんでした。原因を調べたところ、ボトルネックは本文ではなく「公開前の周辺作業」に移っていたのです。

内訳はざっくりこんな感じでした。

工程自動化前の所要時間主な作業内容
構成案づくり約15分キーワードから見出し設計
本文執筆約60〜90分AI下書き＋一次情報の肉付け
アイキャッチ作成約20〜30分素材探し・文字入れ・書き出し
投稿作業約10分管理画面での貼り付け・設定

本文が90分の作業に対してアイキャッチが30分。全体の2割強を、記事の中身とは直接関係のない画像作業に使っていたわけです。しかも疲れている最後のタイミングに来るので、「今日はアイキャッチなしで下書きのまま置いておこう」と先送りしてしまう日も何度かありました。

「後でやる」が一番良くない

アイキャッチ画像の制作を後回しにした記事は、たいてい公開されないまま残ります。私は実際に、本文が完成しているのに画像が用意できず、2週間近く下書きフォルダで寝かせてしまった記事がありました。自動化の目的は「かっこいい画像を作ること」ではなく、公開を止めない仕組みを作ることだと、この時にはっきり方向が定まりました。

2. 前提：Claude Code自体は画像を「描く」わけではない

ここは誤解が多いので、最初に整理しておきます。

Anthropicは公式に、Claudeが画像生成ツールのように写真やイラストを新規生成することはできないと明記しています（Claudeヘルプセンター「Can Claude produce images?」）。会話の中で図やグラフ、インタラクティブなビジュアルを組み立てることはできますが、いわゆる「テキストから絵を描くモデル」は持っていません。

つまりClaude Codeの役割は「絵を描くこと」ではなく、絵を作るための処理を組み立てて実行する“現場監督”になることです。具体的には、次のような分担になります。

  • 画像を生成する：画像生成AIのAPI、またはHTML/SVGからの書き出し
  • 生成した画像をファイルとして保存する：Claude Codeが書いたPythonスクリプト
  • WordPressにアップロードして記事に紐付ける：同じくスクリプト経由でREST APIを実行
  • 一連の流れを「1コマンドで」つなぐ：Claude Codeへの指示とプロジェクト設定ファイル

この役割分担さえ理解できていれば、あとは「どの画像生成ルートを選ぶか」と「WordPress側のAPIをどう叩くか」の2点に集約されます。

なお、Claude CodeでWordPressに自動投稿する環境そのもの（インストール、アプリケーションパスワードの発行、認証情報の保管）は、Claude CodeでWordPress自動投稿に挑む【中編】にまとめてあります。まだ環境が無い方は、先にそちらを済ませてから戻ってきてください。

3. 全体像：アイキャッチ自動化は4ステップで組む

私が実際に組んだパイプラインは、次の4ステップです。

生成AIの使い方を独学ではなく、講座で体系的に学ぶ方法もあります。たとえばDMM 生成AI CAMP 学び放題のような選択肢があります。（広告）

  1. 記事のタイトル・テーマから、アイキャッチの「設計文（プロンプト）」を生成する
  2. 画像生成ルートを通して、PNG/JPEGファイルを記事フォルダに保存する
  3. WordPressのメディアAPI（/wp-json/wp/v2/media）に画像をアップロードして、メディアIDを受け取る
  4. 受け取ったIDを、記事投稿時の featured_media に渡して紐付ける

重要なのは、3と4を必ず同じ実行の中で連続させることです。画像アップロードと記事投稿を別々のコマンドに分けると、「画像はメディアライブラリに上がっているのに、記事のアイキャッチは空のまま」という中途半端な状態が生まれます。私は最初これをやってしまい、メディアライブラリに孤児の画像を10枚以上作りました。

当サイトの投稿スクリプトでは、記事ファイルのフロントマターに「eyecatch: ファイル名」を1行足すだけで、3と4が自動で走るようにしています。原稿を書く側は、画像ファイルを記事と同じフォルダに置いて1行書くだけ。設定ファイルではなく原稿の中に指定を書ける形にしたのが、運用が続いた一番の理由でした。

4. ステップ1〜2：画像をどう作るか、3つのルートと費用感

ルートA：画像生成AIのAPIを直接叩く

もっとも自由度が高いのが、画像生成モデルのAPIをスクリプトから呼ぶ方法です。GoogleのGemini系画像モデルや、OpenAIのGPT Image系モデルが代表格になります。

画像生成AIをブラウザだけで試したい場合は、ブラウザだけでできる 本格的なAI画像生成 【ConoHa AI Canvas】のようなサービスもあります。（広告）

費用は解像度と品質設定で変わりますが、各社の公開価格を見るかぎり、1024px前後の画像1枚でおおむね0.01〜0.17ドル程度、4K級で0.2ドル台というレンジです（価格改定が頻繁なので、導入前に必ず公式の料金ページで最新の単価を確認してください）。仮に1枚15円としても、月20本の記事で300円。個人ブログのコストとしては十分許容範囲です。

ただし注意点があります。GoogleのGemini API側は、画像生成モデルについて無料枠が設定されていない（Gemini API公式の料金ページ）ため、有料アカウントの登録が前提になります。「とりあえず無料で試す」ができない点は、始める前に知っておいたほうがいいでしょう。

ルートB：HTML/SVGテンプレートから書き出す（実質無料）

意外と強いのがこちらです。背景画像を1枚だけ用意し、タイトル文字はHTMLかSVGのテンプレートに流し込み、ヘッドレスブラウザでスクリーンショットを撮ってPNGにする。この方法ならAPI課金はゼロ、しかも日本語の文字が一切崩れません。

Claude Codeに「記事タイトルを受け取ってSVGに流し込み、PNGで書き出すスクリプトを作って」と頼めば、テンプレートごと作ってくれます。ブランドカラーやフォントを固定できるので、サイト全体のアイキャッチのトーンが揃うのもメリットです。

無料ツールを組み合わせて費用をかけずに成果物を作る発想は、AI動画生成を無料で作る5ステップ工作法でも書いた考え方とまったく同じです。「全部を高性能な有料AIでやる」より、役割ごとに安い手段を組み合わせたほうが、結果的に破綻しにくいというのが実感です。

ルートC：Canva Proのテンプレートで半自動化する

デザインの見栄えを最優先するなら、Canva Proのようなデザインツールでブランドテンプレートを作っておき、文字だけ差し替える運用も現実的です。完全自動にはなりませんが、1本あたり3〜5分まで短縮できます。「自動化の前に、まずテンプレート化」という段階を踏みたい方には、ここから入るのが安全です。

3ルートの比較

ルート費用日本語文字の精度絵の自由度自動化しやすさ
A. 画像生成API1枚あたり数円〜数十円苦手（崩れやすい）非常に高い高い
B. HTML/SVG書き出しほぼ無料完璧低い（背景は使い回し）高い
C. Canva Proテンプレート月額サブスク完璧中〜高中（半自動）

結論：私はA＋Bのハイブリッドに落ち着いた

いろいろ試した結果、背景ビジュアルはルートAで生成し、その上に載せるタイトル文字はルートBで合成するという形に落ち着きました。理由は単純で、画像生成AIに日本語のタイトル文字を描かせると、ほぼ確実に崩れるからです。

「AIアフィリエイト」と書かせたはずが「AIアフイリエ一ト」のような、遠目には気づかないレベルの崩れ方をするのが厄介でした。公開後に読者から指摘されて初めて気づいた回もあります。画像生成AIに文字を任せない。これは今のところ例外なく守っているルールです。

5. ステップ3〜4：メディアAPIへのアップロードとfeatured_mediaの紐付け

ここが実装の核心です。WordPressのREST APIに画像を上げるとき、多くの人が「multipart/form-dataで送らないといけないのでは」と身構えますが、実際はバイナリをそのままPOSTするだけで通ります。

必要なのは、次の3点だけです。

  • エンドポイント：サイトURL + /wp-json/wp/v2/media に POST
  • 認証ヘッダー：Authorization に、ユーザー名とアプリケーションパスワードをBase64化したBasic認証を指定
  • ファイル情報のヘッダー：Content-Type に画像のMIMEタイプ（image/png など）、Content-Disposition に attachment; filename=”ファイル名” を指定

レスポンスのJSONに含まれる id が、そのままメディアIDです。あとは記事を投稿するときのリクエストボディに featured_media: そのID を入れれば、アイキャッチとして紐付きます。この2行のつながりさえ押さえれば、アイキャッチ自動化の9割は終わりです。

MIMEタイプは手で書かず、Pythonの mimetypes モジュールで拡張子から自動判定させるのがおすすめです。判定できなかった場合に application/octet-stream を入れて送るとWordPress側に弾かれるので、判定に失敗したら処理を止めて警告を出すようにしておくと、原因がすぐ分かります。

また、画像アップロードは本文のPOSTより時間がかかります。タイムアウトは60秒では足りないことがあり、私は180秒まで延ばしました。実装の詳細と、そこに至るまでの試行錯誤はClaude CodeでWordPress自動投稿に挑む【後編】にも書いています。

6. 実際にハマった3つのエラーと、その原因

ここからが本題かもしれません。順調に見える手順にも、実際には何度も引っかかりました。

エラー1：日本語ファイル名で400エラー／文字化け

最初にやらかしたのがこれです。「アイキャッチ_第3回.png」のような日本語ファイル名で送ったところ、アップロードが400で落ちたり、通ってもメディアライブラリ上でファイル名が文字化けしたりしました。

原因は、Content-Dispositionヘッダーにマルチバイト文字をそのまま入れていたことです。対策は2つあります。

  1. ファイル名がASCIIに収まらない場合は、filename*=UTF-8” に続けてパーセントエンコードした名前を渡す形式に切り替える
  2. そもそもアイキャッチのファイル名は半角英数字とハイフンだけで作る運用に統一する

スクリプト側では1を実装したうえで、運用では2を徹底しています。エラーを技術で吸収しつつ、そもそもエラーが起きない運用に寄せるのが、個人で回す自動化では結局いちばん楽でした。

エラー2：メディアAPIだけ403が返ってくる

記事本文の投稿は通るのに、画像アップロードのときだけ403が返る——これに丸一日溶かしました。認証が原因だと思い込んでアプリケーションパスワードを3回も再発行しましたが、犯人はレンタルサーバー側のWAF（Web Application Firewall）でした。

エックスサーバーをはじめ多くの共用サーバーでは、バイナリを含むPOSTリクエストが攻撃と判定されてブロックされることがあります。認証エラー（401）ではなく403が返っている時点で、まず疑うべきはサーバー側の防御設定です。管理画面からWAFを一時的にOFFにして再試行すれば、切り分けは数分で終わります。

なお、アップロードできる画像サイズの上限もサーバーのPHP設定（upload_max_filesize、post_max_size）に依存します。4Kで生成した画像がそのままだと上限に引っかかるケースがあるので、生成段階で1200×630px前後に抑えておくのが無難です。アイキャッチはSNSのOGP表示で使われるサイズが基準になるため、そもそも4Kは不要でした。

エラー3：画像は上がったのに記事に反映されない

3つめは前述した「順序の問題」です。アップロード用スクリプトと投稿用スクリプトを分けていた時期に、メディアIDを控え忘れて記事側に渡せず、結局管理画面で手作業でアイキャッチを選び直す、という本末転倒な運用をしていました。

Claude Codeに「アップロードと投稿を1つのスクリプトにまとめて、アップロード結果のIDをそのまま投稿ペイロードに渡して」と指示し直したことで解消しました。AIに自動化を頼むときは、機能単位ではなく“自分が実際に行う一連の流れ”の単位で頼むほうが、結果的に手戻りが少ないという学びです。

7. 自動化して良かった部分と、手作業に戻した部分

正直に書くと、すべてを自動化するのは失敗でした。

一時期は「記事タイトルを渡せば全自動でアイキャッチが決まる」状態を目指していたのですが、出来上がった画像を並べて見ると、どれも似た雰囲気で、記事の内容と微妙にズレているものが混ざっていました。実体験や検証を売りにしている記事に、いかにもAIが描いた汎用イメージが載っていると、記事の説得力まで薄まってしまいます。

この感覚は、AI記事の量産で3ヶ月やって失敗したこと5つで書いた「テンプレの固めすぎ」とまったく同じ構造の失敗でした。効率化そのものは正しいのに、判断まで手放すと質が落ちる。

そこで今は、次のように線を引いています。

  • 自動化したまま：ファイル名の生成、サイズ調整、メディアAPIへのアップロード、featured_mediaの紐付け
  • 自動化したまま：背景ビジュアルの生成（候補を2〜3枚出させる）
  • 手作業に戻した：どの候補を採用するかの選択
  • 手作業に戻した：タイトル文字の言い回しと配置の最終確認

結果として、1本あたりの所要時間は20〜30分からおおむね5分前後まで下がりました。ゼロにはなりませんでしたが、「公開を止めない」という当初の目的は完全に達成できています。ゼロを狙って質を落とすより、5分残して納得できる画像を出すほうが、長く続けるうえでは正解でした。

8. まとめ：アイキャッチ自動化のチェックリスト

これから同じ仕組みを作る方向けに、要点を整理します。

  • 目的を「時短」ではなく「公開を止めないこと」に置く。凝ったデザインを自動生成しようとすると、たいてい途中で挫折する
  • Claude Codeは絵を描かない。画像生成API、またはHTML/SVG書き出しと組み合わせて役割分担する
  • 日本語のタイトル文字は画像生成AIに任せない。背景はAI、文字はSVG/HTML合成のハイブリッドが安定する
  • メディアAPIはバイナリ直POSTでよい。Authorization、Content-Type、Content-Dispositionの3つのヘッダーを正しく付ける
  • アップロードと投稿は必ず1つの実行にまとめる。分けるとメディアIDの受け渡しで事故る
  • ファイル名は半角英数字とハイフンのみにする。日本語ファイル名は避けるのが最も確実
  • 画像だけ403が返るときはWAFを疑う。認証情報を疑い始めると迷路に入る
  • 画像サイズは1200×630px前後で十分。4Kはサーバーの上限に当たるだけで、アイキャッチ用途では過剰
  • 最終的な採用判断は人が握る。ここまで自動化すると、記事全体の信頼性が下がる

環境構築の初期投資としては、Claude Proなどのサブスクと、画像生成APIの従量課金が数百円程度。月に何本も記事を出す人ほど、早い段階で組んでおく価値がある仕組みだと思います。

FAQ

Q. プログラミング経験がなくても実装できますか？

A. コードを自分で書く必要はありません。ただし「どのファイルをどこに置いたか」「エラーメッセージの全文をそのままAIに渡す」といった基本的な作法は必要です。私自身も編集者出身でコードは書けませんが、エラーメッセージを省略せずに貼ることを徹底したら、かなりの部分は解決できました。

Q. 画像生成AIの費用は月にどれくらいかかりますか？

A. 各社の公開単価を見るかぎり、1024px前後の画像1枚でおおむね0.01〜0.17ドル程度です。候補を3枚ずつ出して月20本作っても、数百円のレンジに収まる計算になります。ただし料金改定やモデルの入れ替わりが頻繁なので、導入前に必ず公式の料金ページで最新の単価を確認してください。

Q. アイキャッチのサイズは何pxがいいですか？

A. 私は1200×630pxを基準にしています。SNSでシェアされたときのOGP表示に適したサイズで、テーマ側のトリミングにも収まりやすいためです。それ以上の高解像度は、サーバーのアップロード上限に当たるリスクが増えるだけであまり利点がありませんでした。

Q. Claude以外のAIでも同じことはできますか？

A. できます。仕組みの中身は「画像を作る」「WordPressのREST APIを叩く」という汎用的な処理なので、他のコーディング支援AIでも構成は同じです。私がClaude Codeを使っているのは、ローカルのファイル操作とスクリプト実行を一連の流れで任せやすいという理由からです。

Q. WebPで投稿しても大丈夫ですか？

A. WordPress本体は現行バージョンでWebPに対応していますが、テーマやプラグイン、サーバー設定によっては扱いが変わることがあります。まずはPNGかJPEGで仕組みを完成させて、動くことを確認してからWebPに切り替えるほうが、原因の切り分けが簡単です。