画像生成AIの漢字崩れ、実装で打てる対策はどれが効くか — 6案を実験で比較した
先に結論
- 読み（かな）ヒントをプロンプトに足すのは効かない。片方の語では効いたが、もう片方では全滅。前々回の「なぜ」記事どおり、モデルは文字ブラインドなので“読み”を足しても字形は得られない。
- gpt-image-2（不透明）に切り替えるのがいちばん費用対効果が高い。quality=low のまま難字2語で6/6。
- 文字をフォントで合成するのは決定論的に100%（崩れようがない）。
- 品質を上げる（medium/high）と旧モデルでも直るが、トークン消費が増える。
- 崩れた生成は edit API で事後修正できる（3/3で正常化）。生成→検証→修正のループに組める。
1. 試した6案（仕組みのどこを突くか）
対策は「なぜ崩れるか」の3つの仕組み——①文字ブラインドなトークナイザ ②長尾データ ③高周波の喪失——のどこを外すか、で整理できる。モデルを再学習せずに、API利用者が実装でやれることだけを並べた。
| 案 | やること | 狙う仕組み |
|---|---|---|
| M0 ベースライン | gpt-image-1.5 / 透過 / low（＝崩れる経路） | — |
| M1 読みヒント | プロンプトに「読み（かな）」と「一字ずつ正確に」を付与 | ①（字の同定を助けたい） |
| M2 / M3 品質up | quality を medium / high に上げる | ③（トークン予算＝レートを増やす） |
| M4 / M5 モデル切替 | gpt-image-2・不透明（＋high）に変える | ①②③（多言語に強いLLM・大語彙） |
| M6 edit修正 | 崩れた画像を edit API で「文字だけ正しく直す」 | パイプライン（事後リカバリ） |
| M7 フォント合成 | 文字なし背景を生成→コードでNotoSansJPを重畳 | 回避（モデルに描かせない） |
2. 実験結果（難字2語 × 各案の成功率）
わざと崩れる難字タイトル2つ——「籠細工の特別展」（籠＝22画）と「鷹狩り体験フェア」（鷹＝24画）——で各案を生成し、文字単位で判定した（“perfect”＝全字正しい）。
| 案 | 籠細工の特別展 | 鷹狩り体験フェア | 評価 |
|---|---|---|---|
| M0 ベースライン（1.5/透過/low） | 0/3 | 0/3 | ❌ 崩れる |
| M1 読みヒント | 2/3 | 0/3 | ⚠️ 不安定（効かない） |
| M2 medium | 3/3 | — | ✅（コスト増） |
| M3 high | 2/2 | — | ✅（コスト大） |
| M4 gpt-image-2/不透明/low | 3/3 | 3/3 | ✅✅ lowのまま |
| M5 gpt-image-2/不透明/high | 2/2 | — | ✅（過剰） |
| M6 edit修正 | 3/3 | — | ✅ 崩れを救える |
| M7 フォント合成 | 1/1 | 1/1 | ✅✅ 決定論100% |
ベースラインは同じ low 品質でも崩れるのに、モデルを gpt-image-2・不透明にするだけで（品質も解像度も上げずに）直る。
3. 効かなかった対策：読み（かな）ヒント
これは試す前は効きそうに思えた。「正しい表記は『鷹狩り体験フェア』（読み：たかがりたいけんフェア）。一字ずつ正確に」とプロンプトに足す案だ。籠細工では改善したように見えた（2/3）が、鷹狩りでは0/3で全滅。語によって当たり外れがあり、信頼できる対策ではない。
4. 効いた対策
本命A：gpt-image-2・不透明に寄せる（lowのまま）
いちばん割が良い。品質も解像度も上げず、モデルと背景を変えるだけで難字2語が6/6。前回の実測では gpt-image-2 の low は出力トークンが旧経路より少ないくらいなので、品質改善とコスト削減を同時に達成できる。透過が必要なら「不透明で生成→後段で背景除去」に回す。
本命B：文字はフォントで合成する（決定論100%）
確定しているテキスト（タイトル・サービス名）なら、これが最強。文字なしの背景だけをlowで生成し、コードでNotoSansJP等を重畳する。glyphは常に正しい。崩れる余地が原理的に無い。狙ったフォントを選ぶ方法・決定論（毎回バイト一致）・グリフ被覆の落とし穴は 実践編「狙ったフォントを画像に入れる」 で詳しく検証している。
補助：崩れた生成を edit API で事後修正する
すでに崩れた画像があるとき、edit（画像編集）API で「絵柄はそのまま、文字だけ正しい『…』に直す」と頼むと、3/3で正常化できた（編集は gpt-image-2 系を使う経路）。生成と検証を回すパイプラインに組み込みやすい。
確実だがコスト増：品質を上げる
旧モデル（1.5）のままでも quality を medium/high にすれば難字が直る（medium 3/3, high 2/2）。ただし出力トークンが数倍〜十数倍になるので、難字を含む画像だけ局所的に上げるのが現実的。
5. 実装の指針（フロー）
- テキストが確定している（タイトル・固有名詞）→ フォント合成（モデルに描かせない）。いちばん確実で安い。
- モデルに描かせたい → gpt-image-2・不透明・短文・主役配置。難字は避ける。
- それでも崩れたら → edit API で文字だけ修正、または生成→検証ループ（後述）。
- やらない：プロンプトに「正しく描いて」「読みは…」と書くだけの対策（効かない）。
注意（実験の規模）
各案2〜3回×難字2語の小規模な実験です。傾向ははっきり出ていますが（特に「読みヒントは効かない」「gpt-image-2/不透明は強い」）、成功率の正確な数値は目安として読んでください。確定テキストはフォント合成が原理的に最強、という結論は規模に依りません。
まとめ
「なぜ崩れるか」が分かると、効く対策と効かない対策がきれいに分かれました。プロンプトでお願いする系（読みヒント）は効かない。効くのは仕組みを外す手——モデルを gpt-image-2/不透明に変える、品質を上げる、そしてそもそも文字をモデルに描かせずフォントで合成する。崩れたら edit で救う。実装するなら、確定テキストは合成、可変テキストは gpt-image-2＋検証ループ、が落とし所です。