日本語が読める画像AIの現在地(4)|管理工程として — JSON+Pillow からプロンプト自然言語へ

日本語が読める画像AIの現在地(4)|管理工程として — JSON+Pillow からプロンプト自然言語へ — AI, 画像生成, 自動生成 AI画像

こんにちは、パレイド思想部の橘です。

前回までの 3 回で、日本語が描ける 4 モデルを横並びに眺めてきました。整理する編集者としての Nano Banana 2、過剰に奉仕する制作者としての GPT-Image 2 Thinking、引き算の誠実さの Qwen-Image 2.0、情報グラフィックの編集者としての ERNIE-Image-Turbo。4 社が 4 つの異なる世界観を示したあと、前回の終わりに「用途ごとに何を相棒として選ぶのか」という問いを残していました。今回はその問いを、pareido.jp のアイキャッチ自動生成という具体的なユースケースに落として検討します。観察から判断への切り替え回です。

本記事は LLM による自動執筆パイプラインで生成されました。現在は人間が補助していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。

観察から判断へ — 具体的ユースケースで整理する

4 つの世界観を並べて眺めることと、そのうちのどれを自分の工程に迎え入れるかは別の作業です。前者は景色を描くことで、後者は敷地の図面を書き換えることに近い。今回は後者の側に踏み込みます。

題材は pareido.jp のアイキャッチ自動生成です。1 月に組んだ仕組みの構造を一度ほどいて、「いまのモデルならこの工程のどこをどう任せられるか」を要件ごとに見直します。結論めいたところを先に置くなら、ERNIE-Image-Turbo ならプロンプトの自然言語で管理単位を巻き取れそうという示唆になります。ここに至るまでの組み直しが、今回の本題です。

諦めから始まった JSON+Pillow 分業

2026 年 1 月の時点で、わたしは画像生成 AI に日本語を描かせることを諦めていました。ChatGPT でも Gemini でも、タイトル部分の擬似グリフを受け入れられず、背景は画像 AI、文字は Pillow で後合成するという設計に落ち着けました。当時の記録は過去の記事に残っています。

この分業には、単に文字が描けないという以上の理由がありました。pareido.jp のアイキャッチには、実務的な要件が 5 つあります。

  1. 正方形クロップへの対応: 記事がカードとして引用される場面では、16:9 の中心部分が正方形で切り抜かれます。重要情報は中央に寄せないと、切り抜き先で見出しが端に逃げてしまう
  2. 読みやすさの担保: 文字領域の下に半透明の長方形を重ねて明度を落とし、背景の模様に文字が埋もれないようにする
  3. フォント指定: Noto Sans Serif など、サイト全体の視覚的な一貫性を保つ特定のフォントで書きたい
  4. キーワードのハイライト: タイトルの主題語を太字や色替えで強調したい
  5. タイトル差し替えの後追い性: 記事タイトルは公開後に変わることがあるため、画像だけ残っていても再現できないと困る。JSON でメタ情報を保管し、タイトルだけ書き換えれば再描画できる仕組みが必要

5 要件はいずれも「生成 AI が確定的に制御できない → 確実な後処理で補う」という発想から来ています。SDXL が文字を崩す以上、正確なタイポグラフィは Pillow の仕事に引き取る。中央を空けるレイアウトも、生成側で当てにならないなら合成側で確実に空ける。この分業は、画像 AI への信頼のなさが産んだ防衛的な設計でした。

興味深いのは、この設計が副次的に制作物を機械可読な構造として保存できる形に収束したことです。JSON ファイルに {"title": "...", "keywords": [...], "background_prompt": "..."} を残しておけば、タイトルが変わったときにそのキーを書き換えて再レンダリングするだけで済む。諦めから始まった工程が、メタデータ付きのアーカイブというもうひとつの価値を副産物として残していました。

5 要件を ERNIE 時代に読み直す

ここからが今回の主題です。画像 AI 側が日本語を描き、構図を理解し、情報階層を組み立ててくれるようになった 2026 年春に、同じ 5 要件はどこまでプロンプトで引き受けられるのか。採点表を眺めながら要件別に確かめます。

1. 中央空けレイアウト

「中央を空けて、後から文字を載せる前提の構図」を指示するのが 1 つ目の要件でした。ERNIE-Image-Turbo に leaving center area visually calm for overlay text と書いて投げたプロンプト (03_abstract_neural) の結果がこれです。

ERNIE-Image-Turbo で生成した、中央にテキストを重ねる余白を残した抽象ニューラル背景

採点表で構図再現率が「優」だった 1 枚です。画面中央が落ち着いた色面で、周縁にニューラルネットワーク風の青い線条が配置されている。中央を空けろ、という指示が、中央を空けた画像として返ってきている——SDXL 時代には難しかった水準の忠実性です。これまで Pillow 側で確実に担保していた「中央空け」は、プロンプトの一文でモデル側に渡せる範囲に入ってきました。

2. 図形オーバーレイ + 明度調整

文字領域の可読性を担保するため、半透明の黒い長方形を重ねて明度を落とす——これが 2 つ目です。ERNIE や GPT-Image 2 に cinematic lightingdark moody photorealisticstrong vignette in the center のようなライティング指示を入れると、画像の中で文字が乗るはずの領域だけ暗くなる挙動が十分に引き出せます。合成で 1 枚貼り足さなくても、1 枚の中で階層のコントラストがついて返ってくる。完全に Pillow 代替とは言えませんが、少なくとも「コントラストを足すために必ず後処理が必要」という強い前提は崩れました。

3. フォント指定

3 つ目は、わたしの側に諦めが残ります。Noto Sans Serif のようにフォント名そのものを指示することは、まだ通りません。プロンプトで指示できるのは bold Japanese fontserifcondensed sans-serif3D metallicneon handwriting といったファミリー粒度のトーンまでです。前回の 06 で GPT-Image 2 Thinking が返してきた映画ポスター級のメタリック 3D 文字も、「80s retro 3D chrome type」のようなスタイル記述から来ている範囲で、特定書体に一致しているわけではない。ただしサイト全体のトーンを合わせる目的なら、書体名でなくスタイル語彙で十分というのが実物を見ての印象です。書体の完全一致は諦める、トーンの一致は指示できる——この割り切りになります。

4. キーワードハイライト

タイトル中の主題語を強調するのが 4 つ目。ERNIE-Image-Turbo の 06 (06_poster_mixed) が、この要件の手触りを最もよく伝えてくれる 1 枚です。

ERNIE-Image-Turbo で生成した、ERNIE Image Full のメタリック主題 + MacBook Air M5 実測 の日本語副題が階層化された 80s ポスター

前回の第 3 回では、この画像を「情報グラフィックの編集者」としての ERNIE の例として紹介しました。今回は別の見方をします。主題の「ERNIE Image Full」は立体的に浮き上がり、副題の「MacBook Air M5 実測」は別階層のラベルとして抑えて置かれている。指定した主題語が、それらしい装飾で強調されて返ってきている。1 月の仕組みで Pillow を呼んで色替え・サイズ違いを当てていた作業が、プロンプトで「3D metallic main title with Japanese subtitle label」と書くだけで画像の内部に組み込まれて返ってくる。ここはむしろプロンプト側のほうが表現幅が広いくらいです。

5. タイトル差し替えの後追い性

最後の 5 つ目——タイトルが後から変わる、という運用要件。ここが今回いちばん転換があるところです。ERNIE-Image-Turbo の 02 (02_workspace_ja_title) を、別の視点から読み直します。

ERNIE-Image-Turbo で生成した、壁ポスターにサムネイル / 自動生成 / 自動生成ツール + 英字サブコピーが組み込まれたワークスペース

第 1 回では「読める日本語」の証拠として、第 3 回では「情報階層の補完」の例として掲げた 1 枚です。今回の視点は 3 つ目——プロンプト文字列の該当箇所を書き換えれば、新しいタイトルで再生成できる。タイトルを差し替えたくなったら、プロンプトの "サムネイル 自動生成" の部分を別の文字列に入れ替えて、seed を同じ 42 に固定して投げ直すだけです。JSON の title キーを書き換えて Pillow に再レンダリングさせていた運用と、手触りはほとんど同じになります。違いは、機械可読のキー・バリューではなく、人間可読の自然言語そのものが管理単位に変わったことのほうです。

5 モデル × 要件のマトリクス

要件別の読み直しを表に落とします。現行パイプラインと、比較した 4 モデルを並べました。

要件SDXL + Pillow (現行)Nano Banana 2GPT-Image 2 ThinkingQwen-Image 2.0ERNIE-Image-Turbo
中央空けレイアウトPillow 配置で確実プロンプト指示で可、構図整理が強いプロンプト指示で可、埋めがちな傾向プロンプト指示に忠実プロンプト指示で確実
図形 + 明度調整Pillow オーバーレイで確実画像内ライティングで部分的に可画像内で情報密度を高く処理シンプルに処理画像内で複雑な階層を処理
フォント指定Pillow で完全制御ファミリー粒度ファミリー粒度ファミリー粒度ファミリー粒度
キーワードハイライトPillow で任意の装飾自発的に追加する傾向過剰に装飾を追加抑制的情報階層として組み込み
タイトル差し替えJSON 1 フィールド書き換えプロンプト文字列書き換えプロンプト + aspect 明示が必要プロンプト文字列プロンプト文字列、seed 固定で確定的
管理単位JSON (機械可読)プロンプト + Web UI 履歴プロンプト + Web UI 履歴プロンプト + Web UI 履歴プロンプト自然言語 + seed
所有関係ローカルクラウドクラウドクラウドローカル、Apache 2.0

表の下段の 2 行——管理単位と所有関係——が、今回の判断の核になります。3 クラウドモデルは、プロンプトが管理単位としては機能しますが、再生成時の確定性が弱い (seed を固定できない)。ERNIE-Image-Turbo だけが、プロンプト文字列 + seedを手元に保管しておけば、同じプロンプトから同じ画像が返ってくるという確定性を持ちます。pareido.jp の 5 要件をほぼすべてプロンプトの自然言語で指示でき、かつローカル完結で再現性も確保できる——という意味で、管理工程として適正なのは、現時点では ERNIE かもしれません。

JSON から自然言語へ、という転換

ここから 1 段引いて、転換そのものの意味を書いておきます。

1 月のパイプラインの管理単位は JSON でした。{"title": "...", "keywords": [...], "prompt": "..."} のような構造化データに、機械可読であることと、タイトルだけを書き換えて再現できることを託していた。画像生成 AI を信頼できなかったからこそ、確定的に扱える機械可読のメタデータを制作物の隣に並走させていた

2026 年春のモデルで同じ 5 要件を満たそうとすると、管理単位はプロンプトの自然言語に変わります。"壁ポスターに『サムネイル 自動生成』と書かれたワークスペース、cinematic lighting、leaving center area visually calm"——機械のための構造ではなく、人間のための言葉が管理単位になる。seed を固定すれば、この言葉のスナップショットから同じ画像が返ってきます。

機械可読から人間可読に、管理の粒度が戻った。これが今回の記事でいちばん書いておきたい観察です。JSON で管理していた時代にも、わたしは prompt キーに長い英文を書いていました。ただしそれは構造の中の 1 フィールドで、上位のキーの意味 (title, keywords) を通して読まれる。いまは逆で、自然言語のプロンプトそのものが上位にあり、タイトルやキーワードはその文字列のどこかにある単語として流れ込んでいる。

粒度だけでなく可読性も変わります。半年後の自分が「なぜこのアイキャッチを作ったのか」を遡るとき、JSON の複数キーを横断するより、1 本の自然言語のプロンプトを読み返すほうが思考の跡が残っている感覚があります。記事タイトル、狙いたいトーン、空けたい空間——それらが 1 本の文に織り込まれている。JSON の行間には意図が置きにくく、プロンプトの行間には意図が自然に残る。

画像からプロンプトへ、という逆引き

もうひとつ、今回の構造変化で効いてきそうなのが、既存の画像からプロンプトを逆に書き起こすことの容易さです。Gemma や Qwen-VL、GPT-Image 2 側の「describe this image」機能を使えば、過去のアイキャッチ画像から「これに近い画像を生成するためのプロンプト」を再構築できる。JSON 時代はメタファイルが失われた画像はもう再現できませんでしたが、プロンプト時代は画像自体がメタデータの大半を抱えているため、復元の経路が増えます。

これが何を意味するかというと、過去のアイキャッチから新しいプロンプトを学ぶワークフローが実質的に成立するということです。気に入った画像を Vision LLM に渡して記述させ、その記述を微調整して次のアイキャッチを作る——というループが、同じ自然言語の土俵で完結します。JSON では構造化スキーマに挟まれてやりにくかった「画像と言葉を往復させる作業」が、自然言語に戻ったことで素直に行える。

思想部としての軸 — 道具が変わると考え方が変わる

技術が 1 段階進むと、効率や品質の数値が動くだけでなく、人間側の編集行為そのものの作法が変わることがあります。今回はその一例として読めそうです。画像制作が「構造化データと合成処理で組み上げる工程」から「自然言語で記述すれば返ってくる工程」に移ると、わたしたちが画像について考える語彙も変わる。書くべきは属性の集合ではなく、シーンの物語になる。

ただし、これは進歩の一方向な賞賛にはしたくないところです。プロンプトで書き切れるということは、すべてを言葉で書かなければならないということでもあります。中央を空けるのも、明度を落とすのも、主題を強調するのも、すべて言葉で指示する。Pillow で「座標 (600, 300) に半透明の黒を 120px」と書いていた確定的な制御が、「cinematic lighting with strong vignette in the center」という曖昧な記述に置き換わる。モデルの解釈に幅があるぶん、言語化の負荷は別のかたちで残ります。数値で書けば済んだことを、日常の言葉で書かないといけなくなる。

見方を変えると、確定的な数値管理から解放されるのは自由ですが、同時に「何をどう言葉にするか」という編集の責任が手元に戻ってきている。個人の拡張という思想部の視点から言えば、任せられる領域が広がるたびに、任せる側の語彙の解像度が問われる——ここは 4 月の 4 モデルを眺めていて静かに増えてきた感覚です。

次回への布石 — ERNIE を軸に新しいツールを作り始める

ここまでの整理で、pareido.jp のアイキャッチ自動生成パイプラインを ERNIE-Image-Turbo を軸に組み直す方向が見えてきました。5 要件のうち 4 つはプロンプトで引き受けられ、管理単位は自然言語に寄せられ、seed 固定の確定性とローカル完結の所有関係が揃っている。残る 1 つ (フォント) はファミリー粒度で妥協する。

次回からは実装編に入ります。第 5 回で、プロンプト自然言語を管理単位とする新しいアイキャッチツールを設計します。既存の JSON+Pillow パイプラインをいきなり置換せずに、ERNIE 側の工程をまず独立したツールとして組み立てて、新旧を並走させながら比較する準備を整える回になる予定です。

残したい問いはこうです——自然言語でアイキャッチを記述できるようになったとき、わたしが書き残したい「このアイキャッチの意図」は、プロンプトのどこに混ぜておくべきか。次回、この問いを設計のかたちで引き受けます。

タイトルとURLをコピーしました