画像生成 AI で図解や挿絵を作成する際、「プロンプト内のテキストラベルは、単語の断片（例: Tomato）ではなく、明確な意味を持つ完結した文・表現にすると誤生成を防ぎやすい」というノウハウが知られています。単語単体だと AI が一般的な概念と混同しやすいのに対し、文脈を持たせることで意図通りの文字を出力させやすくするテクニックです。

しかし、どれほど丁寧にプロンプトのラベルを「完結文」として設計していても、 同型要素を5個横並びで一括生成させる配置 を行うと、AI は隣接するラベル同士を混同して誤生成を起こすことが手元での実験・検証ログで判明しました。

この記事では、実際の図解制作で発生したラベル混同の具体例と、2箇所の誤りのみピンポイント修正しようとしてかえって悪化した失敗談、そして全ラベルを再提示して解決したプロセスと実務上の教訓を共有します。

はじめに: ラベルを「完結文」に整えればAI画像生成の誤字は防げるか？

画像生成 AI（Imagen 3 や各種 Diffusion モデルなど）の進化により、画像内に日本語や英語のテキストを描画する精度は飛躍的に向上しました。プロンプトエンジニアリングの現場では、テキスト描画を成功させるコツとして「ラベルを完結した名詞句・文にする」手法が推奨されています。

しかし、このノウハウを適用しても、一枚の画像の中に同型のカードやノードを多数並べるレイアウトでは、AI が文字と位置関係を内部で混同してしまう現象（属性漏れ: Attribute Leakage）が発生します。

そもそも、Google Gemini API Imagen 3 Prompt Guide の公式仕様においても、テキスト描画成功の推奨条件は 「1画像あたり描画するフレーズ数は2〜3個以下」「各フレーズは25文字以内」 と明示されています1。

今回の検証事例では、一枚の図解の中に一括で 14個ものテキストフレーズ の描画を依頼していました。これは公式が推奨する上限（2〜3個）を 4〜5倍 大幅に超過していたことになります。一般的な Diffusion モデルは潜在空間全体で一枚の画像を同時に描画するため、高密度のテキスト要求に対しては構造的に文字崩れや混同のエラーが起こりやすくなります2。

実証実験のプロンプト設計: Product/Creatorペア5組の高密度図解

今回検証の対象となったのは、ソフトウェアデザインパターン（Factory Method パターン）を解説する技術記事の挿絵作成プロセスです。

プロンプトの段階では、すべてのラベルを単語の断片ではなく完結文・完結名詞で丁寧に定義していました。

図解のラベル構成（全14個の完結文ラベル）

  • 上部2頂点:
    • trait Seedling（Product役）
    • trait SeedlingFactory（Creator役）
  • 横並び5品種の独立ペア（Product / Creator）:
    • トマト組: TomatoSeedling / TomatoFactory
    • キュウリ組: キュウリの苗（専用Product） / キュウリのFactory
    • ナス組: ナスの苗（専用Product） / ナスのFactory
    • ピーマン組: ピーマンの苗（専用Product） / ピーマンのFactory
    • バジル組: バジルの苗（専用Product） / バジルのFactory
  • 属性フィールド例: needs_support: bool

5組のペア間には水平方向の接続線はなく、それぞれが独立したカードとして横一列に並び、上部の2頂点と垂直に接続する整然とした高密度レイアウトです。「短い単語ではなく完結文にする」という既知の対策は、この設計の時点で完全に満たされていました。

失敗実録1: 完結文でも防げなかった「同型5組横並び」のラベル混同

プロンプトで全14個のラベルを完結文で指定して初回生成を実行したところ、生成結果の検証で 2件のテキスト不一致 が検出されました。

1回目の生成で発生した2件の誤生成
  1. TomatoFactory → Tomato Factory （キャメルケースの間に不要なスペースが混入し、2行に分割表記された）
  2. ナスのFactory → ナスウリのFactory （隣接する「キュウリのFactory」の「ウリ」の文字が混入した造語が発生した）

プロンプトの設計自体に落ち度はなかったにもかかわらず、なぜこのような誤生成が発生したのでしょうか。ここには2つの異なる技術的メカニズムが関係しています。

1. Cross-Attention の空間干渉（Attribute Leakage / 属性漏れ）

ナスのFactory が ナスウリのFactory に化けた現象は、まさに典型的な Attribute Leakage（属性漏れ） です3。 Diffusion モデルがテキスト指示を画像に反映させる「Cross-Attention」という仕組みにおいて、隣接する同型カード（キュウリのカードとナスのカード）のアテンション領域がオーバーラップした結果、「キュウリ」の文字列トークンが隣の「ナス」の描画領域へ漏れ出し、両者が合体した「ナスウリ」という造語が生み出されてしまいました45。

2. BPE トークナイザーと視覚的スペースの補間

TomatoFactory が Tomato Factory に分割された現象は、言語モデルの単語分割（BPE トークナイザー）に起因します。キャメルケースの識別子は Tomato と Factory という2つのサブワードに分割して処理されます。明確な単語境界の幾何制約がない場合、画像生成デコーダーはトークン境界に視覚的な空白（スペース）を補間してしまう性質があります。

失敗実録2: 誤り2箇所だけを直すピンポイント修正の失敗と「ナスu_nの」への悪化

2件の誤生成を検出したため、参照画像編集（Inpainting / 局所修正）機能を使って修正を試みました。この際、「誤っている2箇所だけをピンポイントで直す」という短い指示を出しました。

【1回目の修正指示（失敗）】
上段左の Tomato Factory のスペースを削除して 1 単語の TomatoFactory にし、
ナスウリのFactory の「ウリ」を削除して ナスのFactory に修正してください。

「ピンポイントで指定したのだから一発で直るだろう」という期待に反し、この1回目の修正指示は 失敗 しました。

1回目修正後の確認結果
  • Tomato Factory: 不変 （スペースは消えずそのまま）
  • ナスウリのFactory: ナスu_nのFactory に悪化 （「ウリ」が消えるどころか、アルファベットと記号が混ざった崩れた文字列に変化した）

なぜピンポイント修正で悪化したのか？

  • Context Window（文脈領域）の喪失: 編集指示のマスク領域（Inpainting Mask）を誤り2箇所だけに絞りすぎた結果、AI モデルが認識できる周囲の文脈領域が極小化しました67。
  • Glyph Degeneration（文字構造の壊滅的崩壊）: 逆拡散過程で日本語漢字・仮名のアテンション活性化が保てなくなり、形状の似たラテン文字や記号ノイズ（u_n）へと文字構造が退化してしまいました8。

「ピンポイントで誤りだけを直す」という直感的なアプローチは、AI 画像生成においては周囲の文脈を失わせ、かえって文字崩れを悪化させるリスクがあることがわかりました。

解決策: 全14ラベルの逐語列挙と変更禁止指定（Prompt Anchoring）

1回目の修正失敗を踏まえ、2回目の修正ではアプローチを大幅に変更しました。修正したい2箇所だけでなく、 変更不要な残り12個のラベルも含めて全14個のラベルすべてをプロンプト内で再提示 しました。

【2回目の修正指示（成功）】
参照画像の図解を修正してください。
1. 左から2番目のカード: 「Tomato Factory」（スペースなし・改行なし・1単語）
2. 左から4番目のカード: 「ナスのFactory」（「ナス」＋「の」＋「Factory」の3要素、余計な文字なし）

【変更禁止の全体固定リスト】
以下の残り 12 個のテキスト要素は一字一句変更せず、そのまま維持してください：
- trait Seedling（Product役）
- trait SeedlingFactory（Creator役）
- TomatoSeedling
- キュウリの苗（専用Product）
- キュウリのFactory
- ナスの苗（専用Product）
- ピーマンの苗（専用Product）
- ピーマンのFactory
- バジルの苗（専用Product）
- バジルのFactory
- needs_support: bool (各カード内)

この修正指示を実行した結果、 全14個のラベルが完璧に一致（テキスト忠実度 100%） し、誤生成を修復することに成功しました。

修復成功の要因: Prompt Anchoring（プロンプト再固定）

画像全体のすべてのテキスト要素をプロンプト内で明示的に再提示することにより、Cross-Attention 行列全体が固定（Prompt Anchoring）され、未編集領域の再計算による崩れや文脈の断片化を防止できました8。

テキスト修正と構図（アスペクト比）のトレードオフ

なお、この修正プロセスの副産物として、画像のアスペクト比が当初指定していた「正方形（比率 1:1）」から 1376x768（16:9 相当） へと変化しました（実際の生成画像 infographic_2.webp で確認）。

テキストの忠実度を最優先して潜在空間を最適化した結果、AI が画像全体の縦横比率を再計算したためです。実務においては、「テキストの正確性を取るか、完璧な構図比率を取るか」というトレードオフが発生することを考慮しておく必要があります。

まとめ: 画像生成AI運用における「検証習慣」と「人間による修正プロセス」

プロンプトのラベルを「完結文」にするテクニックは非常に有効ですが、同型要素を5個横並びで配置するような高密度レイアウトにおいては、それ単体で誤生成を完全に防ぐことはできません。

今回の検証から得られた実務上のガイドラインは以下の3点です。

  1. 文字単位での目視チェック（HITL）を必須化する: AI に「一発で完璧な図解を出力させる」ことや「完全自動化する」ことの限界を認識し、人間が目視で確認する工程を運用に組み込む。
  2. 局所修正時は「全要素の再提示＋変更禁止指定」を行う: 誤り箇所だけのピンポイント指示は文字崩れを悪化させるため、全体のテキスト要素を列挙して Prompt Anchoring を効かせる。
  3. 構図のトレードオフを許容する: テキストの完全修正を行う際、アスペクト比や周辺デザインの微細な変化が起きることを前提とした柔軟な制作フローを持つ。

AI 画像生成をビジネスやコンテンツ制作に組み込む際は、「一発生成の幻想」を捨て、適切な検証と多段階の修正プロトコルを運用することが、最も確実で高品質な成果物への近道となります。

AI 活用や業務プロセスの自動化、生成AI導入における品質管理のご相談は コンタクトフォーム よりお気軽にお問い合わせください。

参考文献

Footnotes

  1. Google Gemini API Imagen 3 Prompt Guide, https://ai.google.dev/gemini-api/docs/imagen ↩

  2. TextDiffuser: Diffusion Models as Text Painters, https://arxiv.org/abs/2305.10855 ↩

  3. SynGen: Linguistic Binding in Diffusion Models, https://arxiv.org/abs/2306.08877 ↩

  4. T2I-CompBench: A Comprehensive Benchmark for Open-World Text-to-Image Generation, https://arxiv.org/abs/2303.16198 ↩

  5. Attend-and-Excite: Attention-Based Semantic Guidance for Text-to-Image Diffusion Models, https://arxiv.org/abs/2301.13826 ↩

  6. InstructPix2Pix: Learning to Follow Image Editing Instructions, https://arxiv.org/abs/2211.09800 ↩

  7. SDEdit: Guided Image Synthesis and Editing with Stochastic Differential Equations, https://arxiv.org/abs/2108.01073 ↩

  8. AnyText: Multilingual Visual Text Generation And Editing, https://arxiv.org/abs/2311.03054 ↩ ↩2