記事の中身はWordPressに届けられるようになりました。あとは記事に添える画像の話です。第4章では書き終えた原稿をWordPressの下書きに送る仕組みを掘り下げました。今回はその横で動いている、記事に添える画像を自動で集める部分。「タダで使えて商用OKな画像だけ」というライセンスの縛りをどうかいくぐるか、日本語で書かれた見出しから海外の画像サービスをどう検索するか——第1章で課金トラブルの元凶だった小さなAPIキーの正体も、ここでようやく明かします。
なぜ画像集めが意外とやっかいなのか——著作権フリーという制約
自動化のいちばんはじめに突き当たる壁は「著作権」でした。
ブログに載せる画像は、当たり前ですが、自分で撮った写真か、使ってよいと明示された画像だけ。Googleで見つけた写真をひょいと保存して貼る、みたいなやり方は取れません。個人ブログの体感では甘く見られがちですが、商用ブログを長く続けるつもりなら、ここは最初にがっちり縛らないと、後で全部差し替える羽目になります。
そこでトリヴィペディアでは、画像ソースを3つに絞り、優先順位を決めました。
- Pexels：無料・商用利用可・クレジット表示も不要。まず最初に叩く画像の主戦場
- Unsplash：Pexelsで見つからなかったときのサブ。同じく無料・商用利用可・クレジット不要
- Wikimedia Commons：上の2つが空振りしたときの最終手段。ただし使うのは CC BY / CC BY-SA / CC0 / パブリックドメインだけ。CC BY-NC（非商用限定）や CC BY-ND（改変禁止）は必ず除外する
CC（クリエイティブ・コモンズ）は「著作者が明示した使用条件のセット」のこと。BYは「作者名を明記すればOK」、SAは「同じ条件で改変・再配布OK」、NCは「非商用に限る」、NDは「改変禁止」、0は「著作権を主張しない」を意味します。この組み合わせで許可範囲が変わるので、ブログで使えるのは BY / BY-SA / CC0 / PD（パブリックドメイン） の4つ、と割り切って設計しました。BY 系はクレジット表記が必須なので、画像の直下に「出典：Wikimedia Commons / 作者名（ライセンス名）」を自動で入れる仕組みも、変換工程に組み込んであります。
もう一つ大事なのが、アイキャッチ画像にはWikimedia Commonsを使わないという決めです。アイキャッチはサムネイル的に表示されるので、CC BY 系のクレジット表記を埋め込む場所がありません。だからアイキャッチは Pexels → Unsplash の2択、と割り切っています。
「無料でどこでも取ってこられる」ではなく、「使っていい画像だけを取ってこられる」設計になっているのが、ここのポイントです。手作業だと毎回ライセンスをチェックする必要があったのが、ここが自動で守られているだけで気楽さがまるで違います。
日本語の見出しから、なぜ英語で画像を探すのか（第1章の回収）
次にぶつかったのが、検索キーワードの言語問題です。
Pexels も Unsplash も、日本の写真家がアップロードした画像はごく少数で、大多数は海外ユーザーが英語のタグを付けています。試しに「桜」と入れるとほぼゼロヒット、「cherry blossom」と入れると数千件、というレベルで結果が違う。日本語のままでは事実上検索が機能しないのです。
そこで、記事の見出しやタイトルをそのまま画像検索に投げるのではなく、いったん英語のキーワードに置き換える一手間を挟んでいます。ここで使うのが、Anthropic の Haiku という軽量モデル。用途は「日本語の見出しを、画像検索に効きそうな英語キーワード数語に翻訳する」だけ。正確な意訳というより、画像タグとして機能しそうな語（"photography" を足す、抽象語を具体名に置き換える、など）を選んでもらう感覚です。
ちなみに、この処理が 第1章で課金トラブルの元凶だった、あの小さなAPIキーの正体 です。「あのキー、そもそも何のためにあったの？」と気になっていた方は、これで謎解きです。1見出しあたりの呼び出しは1回・処理も短いので、月の請求は実測で1〜2円程度。「重い仕事はサブスクリプションのClaude Codeに任せ、この軽い翻訳仕事だけ従量制のAPIに任せる」 という役割分担にしています。
同じ翻訳結果は使い回せるので、一度呼んだ「日本語見出し→英語キーワード」の変換は、キャッシュファイルに保存しておく設計です。同じ記事にリトライをかけたときや、似た見出しの記事を作ったときには、そのキャッシュを使うのでAPI呼び出しはさらに減る。地味な工夫ですが、月の請求が1〜2円で済んでいるのは、この積み重ねの結果でもあります。
そしてもう一つ、この設計の副次効果として、「画像用APIキーは画像取得スクリプトからしか使わない」 という切り分けが徹底できるようになりました。第1章で紹介した「set -a方式を避ける」「claudeコマンド実行前にunsetする」といった安全装置は、この切り分けを外部から誤って壊さないための保険です。仕組みは連動しています。
画像を"入れすぎない"という判断
自動化を組み始めた当初、私はもっと欲張っていました。「全部おまかせだ」の勢いで、H2ごと・H3ごとに画像が自動で挿入される設定を試したのです。
結果は、記事の中身とちぐはぐな画像が並ぶ、間延びした記事でした。
たとえば「魚偏の漢字一覧」のような記事だと、あるH3の英訳が思わぬ単語に化けて、まったく別のモチーフの写真が挟まる、ということが起きました。技術的には全部おまかせで動くのですが、質の面では 「AIが選んだ画像は7〜8割微妙」 というのが正直な実感です。
もう一つ気づいたのは、画像を入れすぎると記事が読みにくくなるということでした。スマホで縦にスクロールしながら読むタイプの記事だと、画像1枚で1画面近く占有します。3〜4枚並ぶと、テキストが飛び飛びに現れて、話の筋を追いづらい。読み物としての情報密度が下がってしまう。
そこで方針を切り替えました。トリヴィペディアの本文画像は、原則として アイキャッチ1枚だけ。本文の中には画像を自動挿入しない。どうしても入れたい記事だけは、書き手が個別にモードを指定する。デフォルトは"入れない"、必要なときだけ"入れる"、という設計に倒しました。
これは、連載を通して言い続けている 「自動化できる＝最大限やる、ではない」 という思想の延長線上にあります。手動でやるより速いからといって、質を下げる方向に自動化を回してしまえば本末転倒。自動化は"どれだけ楽になるか"ではなく、"どれだけ質を落とさずに楽になるか" で考える。この感覚は、画像に限らず、これから自動化を組む人みんなに共有したい話です。
まとめ
画像の自動取得は、ライセンス縛り・言語の壁・質の判断という3つの制約に囲まれた工程でした。使っていい画像だけを取ってきて、日本語の見出しをAI経由で英語に変換して探し、必要以上には入れない——地味ですが、記事の"顔つき"を左右する大事な部分です。
次章（第6章）では、これまでの工程を毎日決まった時間に自動で走らせる仕組みを扱います。定期実行を組む方法と、暴走を止めるための安全装置の話。1コマンドで動くところまで来たら、あとはそれを"勝手に動かす"設定と、"勝手に動かしすぎない"抑えのバランスをどう取るか、というテーマです。
なお、この章で触れた image-fetcher.py の実ファイル・Haiku呼び出しのプロンプト・具体的なAPIキーの設定方法・画像挿入ロジックの実装詳細については、シリーズがひととおり出そろったところで、まとめて別途公開する予定です。動く形で手元に置きたい方は、その段になったらまた見に来てください。
