Gemini 画像生成で同じ絵になる問題を構図ヒントを試す

画像のバリエーションを比較する。変える要素を決める:構図・表情・色などの差分を明示、維持したい要素も指示する。複数の結果を比較:同じ条件で候補を生成、意図した差分と意図しない変化を記録。使う前に確認:文字・形・参照との整合を確認、指示だけで一貫性を保証しない
モデルや更新版により結果が変わる。成功例は一般保証ではない。

この試行で使った画像生成モデルは、その無料枠の広さ(1日最大500枚)と生成品質の高さから、ブログのアイキャッチや記事内の挿絵作成に最適な画像生成モデルの一つです。筆者の主観的な印象ではありますが、約50スロット(150枚)の運用実績を通して、高度な画像生成API(例えばImagen 4など)と比べても遜色のない、高品質な画像を多く得られると感じています。商用利用に関する詳細は、Gemini API 公式料金ページ(2026年4月時点確認)でご確認いただけます。導入も非常に簡単で、Google AI Studioから無料で始められ、APIキーの取得も数分で完了します。

しかし、実際の運用を進める中で、ある課題に直面しました。それは、同じプロンプトで3枚の画像を連続生成すると、ほとんど同じ構図の絵が返ってくるという特性です。

例えば、以下のプロンプトで画像を生成してみましょう。

"cloud computing service, expensive cost"

このクエリで3枚生成すると、多くの場合、以下のような結果になります。

  • 1枚目: 青い雲のアイコンと上昇する折れ線グラフ
  • 2枚目: 青い雲のアイコンと上昇する折れ線グラフ(色味がわずかに異なる)
  • 3枚目: 青い雲のアイコンと上昇する折れ線グラフ(角度がわずかに異なる)

ユーザーに画像候補を「選択させる」UIを実装する際、構図がほぼ同一の3枚が並んでしまうと、選択肢としての意味が薄れてしまいます。細部のわずかな違いでは、ユーザー体験を損ねてしまう可能性があるのです。

先に結論

  • Gemini 2.5 Flash Imageの生成APIでは、seedパラメータが外部に公開されていません。(2026年4月時点、@google/generative-ai v0.x.x 環境で確認)
  • temperature パラメータは存在しますが、画像生成における出力の多様性を制御する効果は限定的です。
  • そこで、プロンプトの末尾に視点・画風・色調に関する「構図ヒント」を追記することで、視覚的に異なる複数の画像を安定して生成できるようになります。
  • この手法は、seedを外部から制御できない他の画像生成API(Imagenなど)でも応用可能です。

実現したかったこと

ブログ記事における画像運用のルールは以下の通りです。

  • アイキャッチ画像: 1枚
  • 記事内セクション画像: 3〜5枚

各スロットで3枚の候補画像を生成し、UI上で人間が最適なものを選ぶ設計を目指していました。しかし、候補画像が視覚的に明確に異なることが必須条件です。構図が同じ3枚では、選択UIを用意する意義が失われてしまいます。

// 画像選択UIのイメージを生成するためのプロンプト例
"A grid-based image selection interface showing multiple diverse image candidates for a blog post."

解決策: indexごとに構図ヒントを追記

生成する候補画像のインデックスごとに、構図・画風・色調の異なるヒントを用意し、基本プロンプトに付加します。以下に実装例を示します。

const VARIATION_HINTS = [
  "wide establishing shot, minimalist composition, flat illustration style",
  "close-up detail view, isometric perspective, vibrant color palette",
  "abstract conceptual illustration, alternate angle, muted tones",
];

このヒント群を、生成する各候補プロンプトに組み込みます。

function buildVariedQuery(baseQuery: string, index: number): string {
  const hint = VARIATION_HINTS[index % VARIATION_HINTS.length];
  return hint ? `${baseQuery}, ${hint}` : baseQuery;
}

for (let i = 0; i < 3; i++) {
  const prompt = buildVariedQuery(keywords.query, i);
  const image = await gemini.getImage({ query: prompt });
  candidates.push(image);
}

このアプローチにより、1枚目は「引きの視点でミニマルな表現」、2枚目は「寄りのアイソメトリック視点」、3枚目は「抽象的で別角度からの描写」といった具合に、視覚的な差異が明確な3枚の画像が揃うようになります。

ヒントの軸設計: なぜこの3軸か

目標は「候補を並べたときに一見して違いが分かる」ことです。この目的を達成するため、互いに独立性の高い3つの軸を設定しました。

軸 1枚目(軸A) 2枚目(軸B) 3枚目(軸C)
視点 wide establishing shot close-up detail view abstract conceptual
画風 flat illustration style isometric perspective abstract illustration
色調 minimalist composition vibrant color palette muted tones

各軸を選定した背景は以下の通りです。

  1. 視点の軸: 引き・寄り・抽象といった視点のレベル変動は、構図上の差異を最も大きく生み出します。
  2. 画風の軸: flat / isometric / abstract のようなスタイルキーワードの違いは、モデルが強く認識し、一貫性のある出力を生成しやすい特性があります。
  3. 色調の軸: minimalist / vibrant / muted といった配色指定は、見た目の印象を大きく変化させるため、並べた際に識別しやすくなります。

さらに多くの候補が必要な場合はVARIATION_HINTSを拡張することも可能ですが、5を超えると「記事との関連性」が薄れ、かえって選択が難しくなります。候補数は選択作業と生成コストを見ながら決める。この記事では3候補で試した。

発展: 人物混入を抑制する配慮

この試行で使った画像生成モデルは、「computing cost」や「API design」といった抽象的なキーワードであっても、しばしば人物を含んだ画像を生成する傾向があります。約50スロット(150枚)の実運用を通して、オフィスでPCを操作するビジネスパーソンのような絵が比較的高頻度で出現することが確認されました。

プロンプトの末尾に否定指示を追加することで、人物の混入を効果的に軽減できます。

const NO_HUMAN_SUFFIX = 
  "no people, no person, no human, no face, no hands, no body, object-only scene";

function buildVariedQuery(baseQuery: string, index: number): string {
  const hint = VARIATION_HINTS[index % VARIATION_HINTS.length];
  return hint
    ? `${baseQuery}, ${hint}, ${NO_HUMAN_SUFFIX}`
    : `${baseQuery}, ${NO_HUMAN_SUFFIX}`;
}

この試行では人物を含む候補が減ったように見えたが、比較枚数と採点基準を残していないため効果量は示さない。ただし、base queryが「developer」や「team meeting」のように人物を強く示唆する場合は完全排除は難しいため、上流のLLMプロンプト段階からも人物除外ルールを指示することで効果を最大化できます。

## ルール(重要)
- 人物・顔・人体の部位は含めないこと(people, person, man, woman, face, hand 等は NG)
- 代わりに object / scenery / diagram / device / workspace など無人の題材を選ぶ

他の画像生成APIへ適用する際の注意

構図ヒントの効果は、モデル、API版、seed、入力、生成条件で変わる。この試行を他APIでの解決策として一般化しない。

  • DALL-E 3: 実際のAPI版と評価条件で候補の差異を確認する。
  • Imagen系: 提供状況と利用可能なパラメータを公式ドキュメントで確認する。
  • Midjourney: --sや--cなどのパラメータで多様性を制御できるため、サフィックスの重要度は相対的に下がります。しかし、併用することでさらに表現の幅を広げられます。

この試行では候補ごとに異なるヒントを付けた。多様性が増すかは、モデル・seed・入力・比較枚数をそろえて評価する必要がある。seedを操作できるAPIではseed制御が最も直接的な方法ですが、seedが公開されていないAPIにおいては、プロンプトの工夫によって出力に差分を生み出すことが、実用的な戦略となります。

具体的な効果検証

同じクエリ「cloud computing service, expensive cost」を2つのパターンで試した結果を比較してみましょう。

パターン1: プロンプト固定(同じプロンプトを3回実行)

  • 1枚目: 青い雲アイコン + 上昇グラフ
  • 2枚目: 青い雲アイコン + 上昇グラフ(配色が薄い)
  • 3枚目: 青い雲アイコン + 上昇グラフ(構図がほぼ同一)

パターン2: 構図ヒントを付加(各候補に異なるヒント)

  • 1枚目(wide + minimalist): データセンターの全景を、引きの角度からミニマルな表現で描写
  • 2枚目(close-up + isometric): サーバーラックを寄りのアイソメトリック視点で詳細に描写
  • 3枚目(abstract + muted): コスト上昇を幾何学的な抽象形で表現

これらを並べた際の「選択体験」は根本的に異なります。ヒント付加版であれば、3枚の中から「これを使いたい」と直感的に判断できる1枚が必ず見つかるようになるでしょう。

ヒント調整の実践例

運用を重ねる中で、ヒントの微調整が必要となるケースが2つありました。

ケース1: base queryが具体的すぎる場合

「Astro.js logo with Cloudflare logo」のように、base query自体が強く構図を規定している場合、サフィックスの効きが弱まることがあります。この場合は、base queryをより抽象的な表現に戻してからサフィックスを付加すると、差異が出やすくなります。

ケース2: ロゴやUIスクリーンショットが必須の場合

ブランドロゴや特定のUIインターフェースが必要な記事では、そもそも「候補から選ぶ」というアプローチ自体が合致しないことがあります。このようなケースでは、構図ヒントよりも「解像度・詳細度・スタイル」を変えるサフィックスの方が実用的になるため、記事のカテゴリーに応じてヒント戦略を切り替える工夫が必要です。

まとめ

同じプロンプトで生成した画像が似通ってしまうのは、入力が同一であるためです。Gemini 2.5 Flash Imageではseedを外部から制御できないため、プロンプトの末尾に構図ヒントを追記することで、意図的に差分を生み出すことが有効な解決策となります。

  • 視点・画風・色調といった独立した3つの軸を組み合わせることで、視覚的に異なる3枚の画像を安定して出力できます。
  • 人物の混入を減らしたい場合は、プロンプトにno people, no person, ...といった否定サフィックスを追加し、さらに上流のLLMにも人物除外ルールを指示することで、効果を最大化できます。
  • サフィックスの効きが弱いと感じる場合は、base queryの抽象度を見直すことから始めてみましょう。

この手法は、実装としてはわずか10行程度のコード変更で実現できますが、「複数候補から選べるようになる」というユーザー体験の劇的な改善に繋がります。Gemini 2.5 Flash Imageを用いた画像生成を検討されている方は、ぜひこのアプローチをお試しください。