こんにちは、パレイド思想部の橘です。
前回は、pareido.jp のアイキャッチ自動生成パイプラインの 5 要件を並べ直し、ERNIE-Image-Turbo ならばその大半をプロンプトの自然言語で引き受けられそう、という整理をしました。その終わりに残した問いはこうでした——自然言語でアイキャッチを記述できるようになったとき、わたしが書き残したい「このアイキャッチの意図」は、プロンプトのどこに混ぜておくべきか。今回は実装編①として、この問いを動くコードのかたちで引き受けた記録を残します。
本記事は LLM による自動執筆パイプラインで生成されました。現在は人間が補助していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
最小実装による実験
前回「管理単位は機械可読の JSON から人間可読の自然言語に戻る」と書きましたが、これまでフォントやタイトルの情報は、Pillow での処理を前提に画像とセットで管理していましたが、こうした情報を今後はプロンプトに統合できそうです。再生性が必要になったら、テキストとして保存しておいたプロンプトを開いて該当箇所を書き換える。seed は固定値。そういう役割分担でフローの設計を見直します。
5 要件をプロンプトへ写像するという設計判断
前回挙げた 5 要件（中央配置 / 可読性 / フォントファミリー / キーワードハイライト / タイトル差し替え）は、プロンプト文のセクションごとに役割を割り振りました。残しておきたい設計判断は 3 つです。
1 つ目は、日本語タイトルを原文のまま二重引用符で囲んでプロンプトに埋め込むこと。ローマ字化や翻訳は挟まず、with a prominent bold Japanese title "日本語が読める画像AIの現在地" positioned at the center-upper のように、人間が読んでも意味の通る形で書いておく。「タイトル文字列を書き換えれば別のアイキャッチに化ける」性質を活かすには、その文字列がプロンプトの中で一箇所に、そのままの形で置かれているほうが扱いやすい。
2 つ目は、既存の thumbgen 側のプロンプト生成器に入っていた「テキスト・文字・ロゴを含まないこと」という禁止条項を外したこと。1 月の設計思想は「画像 AI が文字を崩すから生成物に文字を出させないよう抑制する」でした。2026 年春のモデルに対してはこの抑制自体が足枷になります。代わりにタイトル文字列を明示し、77 トークンの上限も取り払いました。抑制的に書く文化から、具体的に書き切る文化へ——書き手側の姿勢の転換が、このコード差分には現れている気がします。
3 つ目は、既存の ComfyUI ランナーを流用すること。ERNIE-Image もしくは Turbo は、ComfyUI で公式にテンプレートが提供されています。以前のSDXL系チェックポイントを API 経由で叩く薄い関数を持っていたので、これを流用できました。このクライアント層のシグネチャは既存SDXL向けパイプラインと概ね同一ですが、ネガティブプロンプトがないこと、また後述する試験結果からseedを変える意味があまりないことがわかっているので、このあたりは調整してあります。
実践で動かしてみる — 第 1 回記事用にアイキャッチを生成する
プロンプト組み立てまでができたら、あとは素振りです。連載第 1 回の記事ファイルを --file 引数に渡し、--keywords "ERNIE,プロンプト,自然言語" で副題を添え、--style cinematic で思想部側の落ち着いたトーンを指定、--seed 42 で固定。ComfyUI 側の ERNIE-Image-Turbo に投げ、戻ってきたのがこの 1 枚です。
所要時間は当サイトのWindows環境で 33.5 秒。
中央上部に日本語のメインタイトルが長文のまま破綻なく乗り、下部に「ERNIE / プロンプト / 自然言語」の英字混じりサブコピーが配置されている。背景は cinematic preset が効いて、室内の暗めのトーンの中に人物像がシネマチックな光でフレーミングされる。ひとまず、動いた、という素朴な観察を書き留めておきます。
前回の記事で「自然言語のプロンプト + seed を管理単位にする」と書いたことが、実物として動いた——.prompt.txt 1 本と .meta.json の seed フィールドだけがあれば、同じ画像を呼び戻せる状態になりました。
replay でタイトルを差し替えてみる — 構図は維持、字形は揺れる
続けて試したのが、前回の主題だった「タイトル差し替え」の実機検証です。いま生成した .prompt.txt を読み込み、二重引用符で囲われた最初のブロック——つまりタイトル文字列——だけを書き換え、同じ seed=42 で再投入する replay サブコマンドを走らせました。書き換え後のタイトルは意図的に「日本語が読める画像AIの現在地(改題)｜タイトル差し替えテスト」としています。
今度は所要時間 22.4 秒。観察したいことが 2 つあります。
1 つ目は、構図はほぼ維持されたこと。中央の人物の姿勢、背景の暗めのトーン、下部サブコピーの位置——どれも最初の画像とよく似た配置で返ってきました。seed を固定し、プロンプトの大半を同一に保ち、一箇所だけ書き換える——この操作に対して、モデルは「同じ構図のバリエーション」を返してきた。Pillow 時代に JSON の title キーだけを書き換えて再レンダリングしていた運用と、手触りはほとんど同じです。
2 つ目が今回のハイライトで、注意深く見てほしいのはタイトルの 2 行目です。「タイトル差し替えテスト」と書いたはずが、画像では「タイル差し替えテスト」と「ト」が 1 文字落ちている。プロンプト文字列のレベルでは正確に "...｜タイトル差し替えテスト" と書いて投げたのに、返ってきた画像では最後の 4 文字の字形が揺れました。
この観察は、第 4 回のテーゼに対する注釈になります。「prompt + seed を管理単位にする」と書いたとき、わたしは暗黙に「同じ入力からは同じ出力が返る」という確定性を前提にしていました。実際には、seed は構図の再現性を保証するものの、字形の再現性までは保証しない。8 step 蒸留（Turbo）で拡散ステップが削られていることと、タイトル文字列が変わればトークン列が変わって潜在空間の通過経路も微妙にずれることの、合わせ技だと思われます。
この差分を見て、わたしは「管理単位は prompt + seed である」という 1 文を、「管理単位は prompt + seed であり、字形の最終確認は人間の目で行う」に書き換える必要を感じました。自動生成に完全委任せず、公開直前のプレビューで字形を見る工程は残す——設計の素朴な 1 行が増えます。
Turbo の弱点 — 3 本腕と negative_prompt の不在
ここで、ERNIE-Image-Turbo の弱点をフェアに書いておきます。連載の中で ERNIE の強みばかりを書いてきましたが、動くツールを 1 つ作り終えたいま、同じ画像群を別の目で読み直すことができます。
第 1 回と第 3 回で掲載した 04_comic_panel のマンガ調画像——「実測！」の吹き出しが日本語として完璧に描けている 1 枚——をもう一度引いてきます。
文字描画の観点に注目していると気が付きにくいのですが、人物の身体をよく見ると右腕が 2 本あります。肘から先がもう 1 本、机の方向に別経路で伸びている。机の上の GPU と配線も、配線の行き先と始点が遠近法的に合っていない。情報の構造としては「エンジニアが GPU のあるデスクで作業している」という場面が強く伝わってくるのに、細部の整合性は静かに破綻している。8 step 蒸留の副作用がいちばんよく現れる領域です。
運用上の回避策は 3 つに整理できます。seed を複数振って最良を採るガチャ運用、Full 版（50 step、概ね 6 倍の時間）への切替、プロンプトに with two hands only, anatomically correct のような正の表現で制約を書き足すやり方。いずれも確実性を上げる代わりに、速度や運用工数とのトレードオフが付いてきます。補足として、ERNIE は negative_prompt を受け取らない設計のため、SDXL 系で定番の extra limbs, bad anatomy, deformed といった抑制型の記述は、そもそも API の入口で捨てられます。
思想部として、この弱点をどう意味づけるか。ひとつの読み方はこうです——情報構造を先回りで整えてくれる編集者は、細部の整合性チェックは抜けがちな編集者でもある。ERNIE は、タイトル文字列を壊さず描き、情報階層を整理して返してくれる意味で「情報グラフィックの編集者」の役割を果たす。
同じモデルが同時に、体の本数や机の奥行きという身体と空間の整合性の部分では、SDXL base 1.0 よりも目に見えて崩れる。つまり、1 つのモデルの中で情報密度と細部整合性は別の層で管理されているらしい——これが ERNIE を動かしてみて得た仮説です。DiT + LLM エンコーダという構造が情報階層の理解を上げる一方で、8 step 蒸留は身体図式や遠近法の内部参照を軽量化してしまう。強みと弱みが、同じ設計判断の表裏に並んでいる。
次回への布石 — 置換 or 併存を決める回
ここまでで、eyecatch_v2 は最低限の動作確認を済ませました。記事 md から自然言語プロンプトを組み立て、ERNIE に投げ、日本語込みのアイキャッチを 1 枚で返し、replay でタイトルを差し替えられる。前回コードなしで書いた設計図は、少なくとも動くコードになりました。同時に、字形の最終確認・Turbo 弱点の許容範囲・seed ガチャと Full 版のコストバランス、という 3 つの宿題が新しく見えてきた。どれも「実装ができたので本番に入れる」とは単純に進めない理由になります。
次回の第 6 回は、pareido.jp のアイキャッチパイプラインにおける eyecatch_v2 の居場所を決める回です。RealVisXL + Pillow の現行パイプラインを全面置換するのか、記事ジャンル（写実 / マンガ / ポスター）や質の要求水準で使い分けるのか、併存させるなら振り分けの基準は何か——実装編①で浮上した宿題を束ねて、本番運用の設計判断として書きます。
終盤に残したい問いはこうです——動くツールを手にしたとき、わたしたちは動くことそのものではなく「どこで使い、どこで使わないか」の判断を求められ始める。自動化できる範囲が広がるたびに、どこまでを自動化の射程に入れ、どこからを人間の目の射程に残すか、という割り振りの編集責任が手元に戻ってきます。次回、この問いを具体的な運用ポリシーのかたちで引き受けます。
