Archive for the
‘AI×アフィリエイト実録’ Category

【概　要】

1人で事業を回していると、リサーチも執筆も戦略立案も、すべて自分の頭の中で切り替えながらこなすことになります。 私自身、当サイトの運営で「今日はキーワード調査の日」「今日は執筆の日」と役割を切り替えるたびに、前日の文脈を思い出すだけで30分近く溶けていく感覚がありました。

この「頭の切り替えコスト」を減らすために取り入れたのが、Claude Codeのサブエージェント機能です。マーケター・ライター・戦略コンサルといった役割ごとにAIを定義しておき、必要なときに仕事を振る。いわばファイル数枚で作れる「AI社員チーム」です。

この記事では、現暗号資産ニュースメディア編集長として編集部の分業体制を見てきた私が、その経験を1人起業向けに落とし込んだサブエージェントの作り方を、設定ファイルの中身・指示の出し方・出力の受け取り方まで手順として整理しました。最初に役割定義を雑に書いて、まったく呼ばれないエージェントを量産してしまった失敗談も書いてあります。

1. Claude Codeのサブエージェントとは何か

「専用の作業部屋」を持ったAIアシスタント

Claude Codeの公式ドキュメントでは、サブエージェントは特定のタスクを担当する専門のAIアシスタントと説明されています。ポイントは次の3つです。

• それぞれが独立したコンテキスト（会話の記憶領域）で動く
• 役割ごとに専用のシステムプロンプト（指示書）を持たせられる
• 使えるツール（ファイル読み込み・Web検索など）を役割ごとに制限できる

そして、サブエージェントが作業を終えると、メインの会話には最終結果（要約）だけが戻ってきます。 調査ログや大量の検索結果がメインの会話を埋め尽くさないので、長い作業でも「親」のClaudeが話の筋を見失いにくくなります。

編集部にたとえると、編集長（メインのClaude）が記者やリサーチャーに仕事を振り、上がってきた原稿だけを受け取るイメージです。編集長の机が資料の山で埋まらない、というのが最大のメリットだと感じています。

Agent Teamsとの違い

当サイトでは以前、Claude Code Agent Teamsで「AI社員チーム」を作る実演ガイドという記事も公開しました。Agent Teamsが複数のAIを同時並行で動かして協働させる仕組みなのに対し、サブエージェントは1つずつ役割を呼び出して仕事を振る、より基本的な仕組みです。まずはサブエージェントで「役割を定義して任せる」感覚をつかんでから、チーム運用に進む順番をおすすめします。

2. なぜ1人起業に「AI社員チーム」が効くのか

1つの会話に全部を詰め込むと、AIも人間も混乱する

サブエージェントを使う前の私は、1つのチャットの中で「キーワードを考えて」「構成を作って」「本文を書いて」「戦略的にこれで合っているか見て」と、立て続けに依頼していました。すると会話が長くなるにつれて、最初に伝えた前提（ターゲット読者や文体ルール）が薄れていく現象が起きます。

人間の編集部でも、1人の記者に企画・取材・執筆・校閲をすべて任せると品質がブレます。だからこそ編集部には役割分担があります。AIにも同じ発想で「役割ごとに部屋を分ける」と、出力の安定感が明らかに変わりました。

役割を分けると「自分の判断」に集中できる

役割を切り出しておくと、私の仕事は「誰に何を振るか」と「上がってきたものを判断すること」に絞られます。1人起業でいちばん貴重なのは自分の判断時間なので、作業ではなく判断に時間を使える構造を作ることが、AI社員チームの本当の価値だと考えています。

3. 準備：Claude Codeを使える環境を整える

料金プランの目安

Claude Codeを使うには、Anthropicの有料プランかAPI利用が必要です。執筆時点で複数の解説記事が報じている米国向け表示価格は、Proが月額20ドル、Maxが月額100ドル（Pro比5倍の利用枠）と200ドル（同20倍）です。料金や利用上限は改定されることがあるため、契約前に必ず公式の料金ページで最新情報を確認してください。

私の感覚では、サブエージェントを3人程度で回す程度ならまずProで始め、利用上限にたびたび当たるようならMaxを検討する、という順番で十分です。AIツールへの課金をどう判断したかは、AIツールに月3万円を投資して3か月検証した全記録で数字込みで公開しています。

インストールがまだの方へ

Claude Code自体のインストールやターミナルの基本操作に不安がある方は、非エンジニアの私が環境構築でつまずいた過程をまとめたClaude Codeで非エンジニアがWordPress自動投稿に挑む【前編】から読んでいただくとスムーズです。

4. 手順1：サブエージェントの設定ファイルを作る

ファイルの置き場所は2種類

サブエージェントは、YAMLフロントマター付きのMarkdownファイル1枚で定義します。置き場所は主に次の2つです。

私はブログ用の作業フォルダ内に `.claude/agents/` を作り、事業ごとに社員を分けています。同じ名前のエージェントが両方にある場合は、プロジェクト側が優先されます。

フロントマターの基本項目

最低限必要なのは `name` と `description` の2項目だけです。よく使う項目を整理すると次のとおりです。

• name：エージェントの識別名（半角英数とハイフンが無難）
• description：「どんなときにこの社員を呼ぶか」の説明。Claudeが仕事を振る判断材料になる
• tools：使ってよいツールの許可リスト（省略すると基本的にメインと同じツールを使える）
• model：`sonnet`・`opus`・`haiku` などのモデル指定、または `inherit`（メインと同じ）

なお、作成方法はClaude Codeのバージョンによって画面が変わることがあります。いちばん確実なのは、Claude Codeに「マーケター役のサブエージェントを作って」と頼むか、自分でファイルを直接書く方法です。

5. 手順2：マーケター・ライター・戦略コンサルの役割を定義する

ここからが本題です。私が実際に使っている3人の定義を、骨格がわかる形で紹介します。

マーケター（キーワード・競合調査担当）

“`markdown

name: marketer description: 新しい記事のキーワード選定、検索意図の分析、競合記事の調査を行うときに使う。記事執筆の前段階で必ず呼ぶ。 tools: WebSearch, WebFetch, Read model: sonnet

あなたはアフィリエイトブログのWebマーケターです。 与えられたテーマについて、以下を調査して報告してください。

1. 想定読者と検索意図（顕在ニーズ・潜在ニーズ）
2. 上位記事に共通する見出しと、上位記事に足りない情報
3. 成約につながりそうな商材カテゴリ

推測と事実は必ず分けて書き、未確認の数値は書かないこと。 “`

マーケターにはファイル編集の権限を与えていません。 調査役が勝手に原稿を書き換えないようにするためです。

ライター（執筆担当）

“`markdown

name: writer description: マーケターの調査結果をもとに記事本文を執筆するときに使う。 tools: Read, Write, WebSearch model: inherit

あなたは元雑誌編集者のライターです。文体はですます調。 著者の実体験・失敗談を必ず1箇所以上入れ、太字は見出しごとに1〜2箇所まで。 最新の料金や統計は執筆時に検索して確認し、確認できなければ書かないこと。 “`

実はこの記事を含め、当サイトの記事下書きは、このライター役と同じ発想で作った執筆専用エージェントが担当しています。文体ルールや表記ルールを指示書に書いておけば、毎回プロンプトで説明し直す必要がなくなります。

戦略コンサル（レビュー・判断材料担当）

“`markdown

name: strategist description: 記事や企画が事業目標に合っているかレビューするとき、優先順位を決めたいときに使う。 tools: Read model: opus

あなたは個人事業専門の戦略コンサルタントです。 渡された原稿や企画について「収益への貢献」「既存記事との重複」 「今やるべきか」の3点で評価し、改善案を最大3つに絞って提案してください。 決定はしないこと。判断材料を出すのが役割です。 “`

戦略コンサルには「決定はしない」と明記しています。 最終判断まで任せると、自分が事業の方向性を把握しないまま物事が進んでしまうためです。

6. 手順3：AI社員への指示の出し方と出力の受け取り方

呼び出し方は3通り

公式ドキュメントで案内されている呼び出し方は、主に次の3つです。

1. 自動で振ってもらう：依頼内容と `description` が合えば、Claudeが自動で担当を選ぶ
2. 名前で頼む：「marketerのサブエージェントを使って、このテーマを調査して」
3. @メンションで指名する：`@` を入力して一覧から選ぶと、確実にそのエージェントが動く

慣れないうちは2か3で明示的に指名するほうが、どの社員が何をしたのか追いやすくおすすめです。

指示には「前提」を必ず書く

ここが一番大事なポイントです。サブエージェントは、メインの会話の履歴を見ていません。 公式ドキュメントにも、サブエージェントは新しいコンテキストで起動し、それまでの会話やメインで読んだファイルは引き継がれないと書かれています（プロジェクトのCLAUDE.mdは読み込まれます）。

そのため、指示は次のように「単体で読んでも分かる」形にします。

“` marketerに依頼： テーマ「Claude Code サブエージェント 使い方」。 想定読者は30〜40代の1人起業家で、プログラミング経験なし。 結果は docs/research.md に書き出せるよう、見出し付きでまとめて報告して。 “`

出力の受け取り方（実際の流れ）

私の実際の運用は「マーケター→ライター→戦略コンサル→自分」の順番です。流れを再構成すると、次のようになります。

• マーケターの報告：想定読者の検索意図、上位記事に共通する見出し、上位記事にない切り口（例：「失敗談」や「役割定義の具体例」が少ない）が箇条書きで返ってくる
• ライターの下書き：マーケターの報告を渡すと、指示書のルールに沿った本文がファイルとして保存される
• 戦略コンサルのレビュー：「既存記事との重複が大きい見出し」「成約導線が弱い箇所」など、改善案が3つ程度返ってくる

最後に私が、レビューを見ながら自分の体験談を足し、採用する改善案を決める。AI社員がいくら優秀でも、この最終工程だけは手放さないようにしています。

7. 私がつまずいた失敗談：「呼ばれない社員」と「越権する社員」

失敗1：descriptionが曖昧で、まったく呼ばれなかった

最初に作ったときは、description に「マーケティングを担当します」としか書いていませんでした。その結果、キーワード調査を頼んでもClaudeがマーケターを呼ばず、メインのClaudeが自分で調べ始めることが何度もありました。

descriptionは、Claudeが「この仕事は誰に振るべきか」を判断する材料です。「どんな依頼のときに呼ぶか」「どの工程で使うか」まで具体的に書き直したところ、自動で振ってもらえる頻度が目に見えて上がりました。

失敗2：権限を与えすぎて、調査役が原稿を書き換えた

もう1つは、tools を省略したまま運用していたことです。マーケターに「この記事の競合を調べて」と頼んだら、親切心なのか、調査結果をもとに既存の原稿まで書き換えてしまったことがありました。幸い元の原稿は手元に残っていましたが、以来、役割に必要なツールだけを tools に明記するルールにしています。

どちらの失敗も、人間の組織でいえば「職務記述書があいまい」という問題です。編集部で新人に仕事を頼むときと同じく、役割と権限の線引きを最初に文章にしておくことが、AI社員チームでも一番効きました。

なお、社員ごとの成果物や依頼履歴は、Notionのデータベースで管理するとあとから振り返りやすくなります。私の管理方法は副業ブログを「AI×Notion」で管理したら挫折しなくなった理由にまとめています。

8. まとめ：AI社員チームを作るチェックリスト

最後に、サブエージェントでAI社員チームを作る手順をチェックリストとして整理します。

• 環境：Claude Codeが使える有料プラン（またはAPI）を用意し、料金は公式ページで最新を確認する
• 置き場所：事業専用なら `.claude/agents/`、汎用なら `~/.claude/agents/` に置く
• description：「どんな依頼のとき・どの工程で呼ぶか」まで具体的に書く
• tools：役割に必要なツールだけを許可し、調査役には編集権限を与えない
• 指示書：文体ルール・禁止事項・「推測と事実を分ける」などの品質基準を書いておく
• 依頼文：サブエージェントは会話履歴を見ないので、前提を毎回書く
• 最終判断：体験談の追加と改善案の採否は、必ず自分で行う

AI社員チームの価値は、作業の自動化そのものより「自分が判断に集中できる構造」を作れることにある、というのが当サイトで運用してみた実感です。まずはマーケター1人からでも作ってみて、「役割を分けて任せる」感覚をつかんでみてください。

FAQ

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

【概　要】

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

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

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

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

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

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

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

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

本文が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＋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に切り替えるほうが、原因の切り分けが簡単です。