GPT Image 2でブログサムネを自動生成｜設計・コスト圧縮・全記事への一括適用【サムネイル編】

2026-07-10 2026-07-10 23分12秒

「AIブログの自動化」シリーズも、そろそろ運用面のブランディングに踏み込みたい。今回のテーマはサムネイル画像です。この記事を書いている時点で、当ブログには171本の公開記事がありますが、そのすべてのアイキャッチが GPT Image 2 で生成した紺×金の統一デザインに切り替わったばかりです。Pexels/Unsplashから拾ってきた無関係な写真から、記事の主題を象徴するイラスト調のオリジナル画像への全面移行。総コスト約2ドル、1枚あたり約1円で、171記事分のブランド統一を実現した実装記録を残しておきます。

この記事の目次

Pexels/Unsplash 時代のサムネイル、その限界

前段のAIブログの画像を自動で集める仕組み【第5章】で紹介した通り、これまでは image-fetcher.py という自作スクリプトで、Pexels と Unsplash から記事タイトルに関連する写真を自動取得し、それをアイキャッチとして貼っていました。

このやり方には次のようなメリットがありました。

完全無料（両サービスとも API 利用料ゼロ・商用可）
クレジット表示も不要
記事投稿と同時に自動で featured_media が設定される
数百記事のスケールでも問題なし

一方で、避けようのない限界も抱えていました。

問題1：記事内容と関係の薄い写真が並ぶ
「厨二病用語300種まとめ」の記事に、ぼんやりとしたビジネスマンの手元の写真が付いてしまう、といったミスマッチが日常茶飯事でした。API の検索キーワードは記事タイトルから機械的に抽出しているため、ストックフォトサイト側の在庫と噛み合わないと、遠い写真が返ってきます。

問題2：デザインの統一感が皆無
Pexels/Unsplash はカメラマンが投稿したストックフォト集で、色調・構図・雰囲気がバラバラです。ある記事は暗い青系、次の記事は明るい黄色系、その次は白背景の抽象写真、という具合で、ブログの一覧画面や関連記事枠でデザインの一貫性がまったくありませんでした。

問題3：記事の主題を象徴できない
そもそも「無量大数」「厨二病用語」「フォビア」といった雑学系のテーマは、既存のストックフォトで象徴的に表現できるものではありません。写真が撮れないものについて、写真で説明しようとすること自体に無理がありました。

このモヤモヤは以前から抱えていて、「ブログ全体のデザインを引き上げるなら、次はサムネだ」というのは自明の課題でした。ちょうど GPT Image 2 が出てきたので、これを機に全面刷新に挑むことにしました。

GPT Image 2 で最初にぶつかった3つの課題

「AI に画像を生成させるだけなら簡単でしょう」と思ってスタートしたら、想像より遥かに深い沼でした。プロンプトを書いて出力を見て、また書き直して、を数十回繰り返した末に、根本的な課題として整理できたのは以下の3つでした。

課題1：数字の捏造

たとえば「キーボード配列の種類一覧」という、タイトルに数字を含まない記事を生成させると、モデルは勝手に「4」という数字を金色特大で描き込んできました。おそらく本文中の「QWERTY・Dvorak・JIS・親指シフト」という4つの例示から「4種類ある」と推論して数字を作り出したのです。しかし記事内では実際には10種類以上を紹介しています。タイトルから記事の総項目数を推論すると、記事の実際の内容と食い違ったサムネになってしまうわけです。

課題2：和柄の全テーマ固定

最初に用意した5枚の参照画像がすべて和柄テンプレート（青海波・金雲・和紋様）でした。GPT Image 2 の images.edit は参照画像のテイストを非常に強く引き継ぐため、音楽記事にも、IT記事にも、海外文化記事にも、すべてに和柄が付いてしまいました。「HTTPステータスコード一覧」の記事に青海波が敷かれている絵面は、はっきり言って違和感しかありませんでした。

課題3：文字の見切れ

生成時のキャンバスは 1536×1024 で、最終出力の 1200×630 に合わせてトリミングする必要があります。当初はレターボックス方式（アスペクト比を保って白帯を追加）を採用していたのですが、GPT Image 2 のバッファ幅の解釈が甘く、文字が 1200×630 の外周ギリギリに描かれてクロップ時に切れる、という事故が頻発しました。

これら3つは「AI が生成すればいい」だけでは解決しません。プロンプトの書き方、参照画像の選び方、後処理のパイプライン、それぞれに設計判断が必要でした。

試行錯誤の系譜 — 3つの発見

3つの課題を解決するまでに、方針転換を含む複数の段階がありました。ここでは特に転機となった3つの発見を時系列で書きます。

発見1：参照固定 → generate 単調化

第一の対応として、和柄が伝染する参照画像方式（images.edit）をやめ、参照なしのプロンプト単独方式（images.generate）に切り替えました。プロンプトを一枚岩の仕様書として書き直し、「和柄は和・伝統テーマのときだけ、それ以外は禁止」といった条件分岐を書き込んだ結果、和柄の全テーマ固定は解消しました。

しかしこの方式には別の副作用がありました。「参照画像に引っ張られない」自由度と引き換えに、モデルの出力が単調化したのです。装飾がフラットな二色のベタ塗りになり、モチーフも「アイコン1点＋文字のみ」の淡白な絵面が続きました。参照画像時代の「描き込みの豊かさ」がまるごと失われてしまいました。

発見2：当たり画像を新参照に再構成

ここで発想を切り替えました。「参照画像そのものが有害だったのではなく、5枚全部が和柄だったのが問題だっただけではないか」と考えたのです。参照は images.edit で「デザインシステムの見本」として強く働きます。5枚が同じテイストなら全出力がそのテイストに寄る。ならば、テーマ別のバリエーションを揃えた参照セットに組み直せば、モデルは「テイストの幅」を学べるのではないか。

これまでの試行錯誤で出力してきた画像の中から「当たり」と思えるものを、テーマ別に10枚選んで新しい参照セットとして配置し直しました。参照は 600×315 の軽量 WebP に統一（1枚あたり 300KB → 30KB、およそ1/10のサイズに軽量化）した上で、images.edit 方式に戻しました。

結果、描き込みの豊かさは復活し、しかも和柄の全テーマ固定は再発しませんでした。テーマ別に散らばった参照は、モデルが「タイトルに応じて近い系統を選ぶ」自律判断を可能にしたのです。

発見3：flood fill による背景色の固定

生成された画像を並べると、背景色が微妙にバラついていました。狙いは #fcf9f3 のオフホワイトで統一したかったのですが、モデルの出力はタイトルによって RGB で幅 6〜8 の変動を出してきます。GPT Image 2 の API には background="transparent" パラメータがあるはずと思って試したのですが、400 error で「Transparent background is not supported for this model」と返ってきました（この機能はモデルによっては使えるものの、GPT Image 2 では非対応でした）。

そこで API 側での透過生成は諦めて、Pillow の flood fill による後処理で背景色を固定することにしました。仕組みはこうです。

1200×630 の最終画像に対して、四辺のいずれかに接する「近似背景色」（R,G,B すべて 235 以上）の連結成分をラベリング
検出された連結領域だけを #fcf9f3 に置換
境界1px は元色と #fcf9f3 の50%ブレンドでハローを緩和

この設計の妙は、モチーフ内部の白（画像中央の金色文字の白い縁取り、アイコンの白ハイライト等）は「外周と非連結」なので保護されるところにあります。単純に「明るい色を全部塗り替える」だと文字がボロボロになりますが、flood fill で「四辺に接する連結領域」だけに絞ることで、モチーフには一切触れずに背景だけを固定できます。

参照画像とプロンプトの役割分担 — これが核心

ここまでの試行錯誤を経て、GPT Image 2 で狙ったブランド統一サムネを安定生成する要は、参照画像とプロンプトの役割分担にあると分かってきました。

この記事で伝えたい核心はこれだけと言ってもいい。以降の設計判断はほとんどこの原則から派生しています。

参照画像 = デザインの「骨格」

参照画像が担うべきなのは、レイアウトの型、配色の目安、装飾の粒度、モチーフの描き込み度合いといった「骨格」です。人間のデザイナーが新しい素材を作るときに「ブランドガイドライン」を参照するのに近い役割ですね。

参照が有害になるのは「骨格ではなく個別スタイルを渡してしまう」ときです。5枚とも和柄だったことが致命的だったのは、「和柄は特定テーマの装飾スタイルであって、ブランドの骨格ではない」ものを、モデルが「これがブランドの骨格だ」と受け取ってしまったからでした。

プロンプト = テーマ固有の「判断」

一方でプロンプトが担うべきは、テーマ固有の判断です。タイトルの内容を解釈して、和柄OK/NG を切り替えたり、数字を強調する/しないを決めたり、モチーフの主題を選んだりする「その日限りのルール」を指定します。

プロンプト全文はブログの競争優位に関わるため公開しませんが、重要な設計指針だけ紹介しておきます。

6セクション構成の一枚岩仕様書：必須要素チェックリスト／文字の階層／モチーフのスタイル／背景装飾のルール／キャンバスの塗り足し／憶測防止。継ぎ足しではなく再構成として書き直した
背景装飾はテーマ連動：和・日本語・伝統・歴史のときだけ和柄OK、それ以外は現代的・中立な装飾。「迷ったら和柄なし」の fallback を明示
数字強調は3段階の優先順位：①タイトルに数字＋助数詞があれば必ずそれを描く（省略禁止）、②なければ定型ワード（一覧・まとめ・なぜ・？等）を金色で強調、③それもなければ主題を最もよく表す語を強調
憶測防止セクション：タイトルにない機能・特徴・数字を勝手に作らない、実在意匠の正確再現禁止

これらは「タイトルから文脈を読み取ってその場で判断する」設計で、テーマ分類器を別途走らせなくても、モデルが1度の呼び出しで自律的にこなしてくれます。分類→切替のパイプラインを組むより、プロンプトに条件分岐を書いて任せる方が、判定精度・分岐ロジック・失敗パターンをすべて1箇所で吸収できてシンプルでした。

「教科書」と「その日の授業ルール」

例えるならこうです。参照画像は、モデルに渡す「教科書」に相当します。ページを開けば「このブランドはこういう配色、こういう装飾で作られている」というデザインシステムが載っています。プロンプトは「今日の授業のルール」です。「今日は和柄の日ではない。IT の話をするから、代わりに幾何学ラインを使う。数字を書くな。実在の商標を描くな」といった、その1本の記事のための可変ルールを渡します。

この2つが噛み合うと、ブランド一貫性とテーマ多様性を両立できます。参照だけで頑張ると参照の主張がテーマを乗っ取り、プロンプトだけで頑張ると生成が単調化する。両輪が要る、と言ってもいいでしょう。

コスト圧縮 — high から low へ、約1/25に

サムネ生成の単価も、この試行錯誤の中で大きく圧縮できました。最初は GPT Image 2 のデフォルト設定である quality=high で走らせていたので、1枚あたり約 $0.25 でした。171記事分だと約 $42.5、日本円で6,000円超。刷新は1度しかしないとはいえ、まあまあの金額です。

段階的に品質を落として実用性を測っていったのが以下の流れです。

Step 1: quality=high → medium（単価 $0.25 → $0.084、約1/3）
描き込みは明確に薄くなりますが、レイアウト・文字・数字強調は同水準。数字ありタイトルなら medium で十分実用に耐えます。数字なしタイトルの定型ワード強調は若干弱まる傾向がありましたが、目視で問題なしと判断しました。

Step 2: quality=medium → low（単価 $0.084 → 約 $0.01、さらに約1/8）
low ではさらに描き込みが薄くなります。金色強調要素の彩度・階調が下がり、数字なしタイトルでは金強調の位置揺らぎがやや目立ちました。ただ実運用では「読者が記事を象徴するデザインに感じる」水準は保たれていました。看板記事など個別に高品質で作りたい場合は --quality high を明示指定する運用にしています。

Step 3: 参照画像の軽量化（生成時間約半減）
参照画像を 1200×630 PNG（1枚 300KB 前後）から 600×315 WebP（1枚 30KB 前後）に切り替えました。1枚あたりのサイズがおよそ1/10になり、生成時間は初期の 60秒/枚（medium＋PNG参照）から 34〜38秒/枚（low＋WebP参照）まで縮みました。API コストは変わりませんが、待ち時間の圧縮効果が大きく、運用のストレスが減りました。

合計：初期の high 方式（$0.25/枚・約60秒）→ 現行の low+WebP参照方式（約$0.01/枚・約35秒）で、約1/25 のコスト・約半分の時間まで圧縮できました。

品質許容の判断で心がけたのは、「1枚を目で見て『この記事のサムネとして耐えるか』」というシンプルな基準です。数値上の四隅一致率や文字強調比率は補助指標として使いましたが、最終判断は「これでブログの一覧画面に出したときに恥ずかしくないか」でした。運用171枚の中で「low で作り直したい」と思った記事はゼロでした。

171記事の一括差し替え — 実運用の学び

刷新の実装が固まったので、いよいよ全171記事のサムネを差し替える段階に入りました。ここでも運用上の学びがいくつかありました。

バッチ差し替えスクリプト（thumbnail-apply.py）
記事 ID を引数で渡すと、WP REST API から現行タイトルを取得、GPT Image 2 でサムネ生成、WPメディアにアップロード、featured_media だけを PATCH で更新（本文・status には触らない）、GET で反映確認、というフローを実装しました。1本失敗しても後続を継続する設計で、10〜30本まとめて回しました。

エッジ検品と自動リトライ
生成した画像の四辺エッジ帯（外側10px）に紺系ピクセルが連続していないかを自動チェックし、文字が外周に達していたら「はみ出し疑い」として自動で1回だけ再生成する。GPT Image 2 の稀な暴走をキャッチする安全網で、実運用中でも数件発動しました。

停止ルール
バッチ処理中に「異常」と判定して人間の目視を挟むタイミングは意外と設計が難しい。最初は「画像の四隅がブランド色に一致しない画像が3枚以上あったら停止」というルールにしていましたが、実は「四隅の1つが不一致」なケースの多くは、モチーフや装飾が隅まで伸びていて flood fill が正しく保護している「正常動作」でした。運用中に「1〜2隅の不一致は正常」と判明したので、停止条件を「四隅全部が不一致 or 生成失敗3件以上 or 429レート制限」に見直しました。真の異常だけを拾い、正常動作の副作用で止まらない設計に整えました。

逆引き検算で「真の残ゼロ」確認
全ラウンドが終わったあと、WP REST API から全公開記事を取得し、それぞれの featured_media が今回のバッチで発行された新しいメディア ID のどれかに一致するか、逆引きで検算しました。171/171 が新FMでカバーされ、未反映ゼロを確認できました。この検算をやると「見落としがあるかも」の不安が消えます。

実測コスト
最終的な API 消費は約200枚（生成失敗リトライ、エッジ検品リトライを含む）で、実測コストは Usage ページで確認できる範囲では約 $2.00 でした。171記事分のブランド統一サムネが2ドルで整うなら、迷いなく踏み切れる規模ですね。

接続断・レート制限
10〜30本のバッチを複数ラウンド回した中で、429（レート制限）は1度も出ませんでした。連続処理での接続断は1件だけ発生しましたが、既存 webp の再利用モードで即座にリトライ復旧できました。全体として GPT Image 2 の API 側は非常に安定していました。

Python 自作版という「保険」

サムネ自動生成を GPT Image 2 に依存する構成にする以上、避けたい未来のリスクとして「OpenAI の API 停止・仕様変更・大幅値上げ」があります。そのため、完全ローカル・費用ゼロで動く Python 自作版のジェネレータも並行して用意しています。

構成は次の通りです。

Pillow（Python の画像処理ライブラリ）でキャンバスを描画
Noto Sans JP / Noto Serif JP（Google Fonts）で日本語文字をレンダリング
Tabler Icons（MIT ライセンスのアイコン集）を紺色に再着色してモチーフ配置
タイトル内キーワード → アイコン名の対応辞書で自律的にモチーフを選択
1枚あたり生成 0.8秒・費用ゼロ

これだけ聞くとよく出来ているように見えますが、実際には本番運用の主軸には据えていません。理由を正直に書いておきます。

キーワード辞書のメンテコストが高い（新テーマが増えるたびに手動更新が必要）
モチーフが「モノトーンアイコン集」由来なので、AI 生成の「豊かな描き込み」には到底届かない
装飾のバリエーションが限定的で、単調な仕上がりになる
キーワードがマッチしないタイトルはフォールバックのタイポグラフィ版になるが、これも紺と金のベタで淡白

つまり、メインでは使えない品質だが、緊急時の代替として動くコード資産として置いています。もし将来 OpenAI の GPT Image 系が大幅値上げされたり停止されたりしたら、この Python 版を再有効化して繋ぎます。中途半端に美化するのではなく、「メインが止まった時にゼロ画像で公開するよりはマシ」というレベルの保険として位置づけています。

依存先が1本しかないシステムには、動かなくなったときの代替を1つ持っておく。これが自動化を続けるうえでの静かな安全弁ですね。