複数の参照画像で起きるドリフト対策：構図とスタイルを分ける

レイアウトの参照画像、スタイルの参照画像、被写体の画像を生成ツールに渡したとします。リクエスト自体は成功しているのに、出力はありきたりなストック画像のようになり、被写体の位置がずれ、見出し用の余白が消え、複数の画風が曖昧な「AIっぽさ」に平均化されることがあります。ここでプロンプトを長くするだけでは問題を切り分けられません。まず各参照画像に一つずつ明確な仕事を与え、その後で意図した構図と出力を項目別に比較します。

公開されている一件の報告では、エージェントが複数のスタイル参照を一つのフラットなパラメータに連結していました。モデルは入力を平均したような結果を返し、汎用的なテクスチャに寄った一方で、APIエラーは発生しませんでした。この一例だけであらゆるモデルの挙動を一般化することはできませんが、重要な区別を示しています。技術的に成功したリクエストと、視覚的に成功したタスクは同じではありません。

実用上の原則：構図を決める画像と見た目を決める画像を分ける

最も効果があるのは、すべての画像を「同じ重みを持つ説明なしの参照リスト」として扱わないことです。少なくとも次の三つの役割を分けます。

参照画像の役割	制御させる要素	制御させない要素
構図参照	被写体数、位置、相対サイズ、カメラ、トリミング、余白	色、素材感、筆致、照明スタイル
被写体参照	人物や物体の同一性、形状、特徴的なディテール	画面全体の配置や無関係な背景物
スタイル参照	配色、質感、線の性質、粒状感、照明、レンダリング表現	画像内の物体、文字、構図

必要なのが構図とスタイルだけなら、その二枚だけを使います。参照画像を増やしても、必ずしも制御が強くなるわけではありません。むしろ、システムが調停しなければならない競合信号を増やす場合があります。

フラットな参照リストが無難な折衷案を生みやすい理由

フラットなリストが伝えるのは「これらの画像はすべて重要」ということだけで、各画像が何のために重要なのかは示しません。モデルや中間エージェントが関係を推測することになり、ある画像から色、別の画像から質感、三枚目から不要な物体を拾い、もっともらしいものの目的から外れた折衷案を作る可能性があります。

この失敗では、構造上のエラーが出ないこともあります。認証、アップロード、リクエスト構文、レスポンス解析がすべて正常でも、画像は要件を満たしません。したがって、HTTPの成功ステータスや「generation completed」という表示は視覚的な合格判定には使えません。生成後に構図を検査する工程が必要です。

手順1：各参照画像の役割契約を書く

長いプロンプトを書く前に、各画像について次の四点を決めます。

1. 必ず保持するものは何か。 例：被写体は左下、上部は見出し用に空け、カメラはローアングルを維持する。
2. 無視するものは何か。 例：スタイル参照に写る人物の同一性、ブランド文字、背景建築は取り込まない。
3. どの程度厳密か。 構図は絶対条件で色は希望なのか、逆なのかを明確にする。
4. 参照同士が衝突したら何を優先するか。 例：物体配置はスタイル画像が暗示する位置より構図参照を優先する。

実用的な役割契約は次のように書けます。

ファイル	役割	保持する要素	無視する要素	衝突時のルール
layout.png	構図	二つの被写体の大小関係、右側の余白、俯瞰視点	色と素材	空間関係は他の参照より優先
subject.png	被写体	シルエットと特徴的なディテール	元の背景とカメラ	構図内の位置を動かさず被写体だけ置換
style.png	スタイル	暖色寄りのグレー、紙の粒子、柔らかい影	人物と文字	見た目だけ移し、内容はコピーしない

「参照1、参照2、参照3」と並べるより、欲しい信号と移してはいけない要素の両方が明確になります。

手順2：フラットなリストを階層化された依頼に変える

実際のAPIフィールドはツールごとに異なります。次の例は考え方を表す概念的な構造であり、特定ベンダーの実在するAPI仕様ではありません。 エージェントが最終リクエストまで役割情報を維持しているか確認するために使います。

references:
  - id: layout
    source: layout.png
    role: composition
    preserve: [subject_count, position, scale, camera, negative_space]
  - id: subject
    source: subject.png
    role: identity
    preserve: [shape, distinctive_details]
  - id: style
    source: style.png
    role: appearance
    preserve: [palette, texture, line_quality, lighting]
    exclude: [objects, text, composition]
priority:
  - layout
  - subject
  - style
acceptance_reference: layout.png

重要なのは、APIがこのフィールド名を使うかどうかではありません。同じ意味が処理の最後まで残るかどうかです。エージェントが実際に送信したリクエストを確認してください。画像配列が一つの連結文字列に変換されていないか、役割説明が普通の文章に埋もれていないか、再試行やバッチ処理でファイル順が変わっていないかを調べます。

対象APIが参照タイプ、重み、編集マスクを明示的にサポートしている場合は、役割契約をその公式スキーマに対応させます。サポートしていない場合は、存在しないパラメータを作らず、段階方式に切り替えます。

手順3：役割を表現できないツールでは二段階に分ける

インターフェースが区別のない画像セットしか受け取れないなら、先に構図を固定し、後からスタイルを適用します。すべての信号を一回の依頼に押し込むより、問題箇所を診断しやすくなります。

段階A：構図と被写体を確定する

構図参照を使い、必要な場合だけ被写体参照を追加します。被写体数、位置、カメラ、トリミング、余白を明記し、素材感やレンダリング表現はこの段階から外します。目的は、まだ素朴に見えても、構造が正しい画像を得ることです。

段階B：シーンを作り直さずに見た目だけ変える

段階Aの出力を新しいベース画像にし、スタイル参照を使って編集または再描画します。被写体の位置と境界、カメラ、トリミング、余白は固定し、変更できるのは配色、質感、線の性質、照明だけだと指定します。

マスクに対応しているなら、変更が必要な領域だけを公開します。編集モードがない場合は、段階Aの画像を主参照、スタイル画像を副参照として扱います。明示的な重み付けが使えるかどうかは、利用中のツールの最新ドキュメントで確認します。

手順4：四つの統制比較で信号が失われる場所を特定する

複雑な依頼を少しずつ変更し続けるのではなく、プロンプト、寸法、その他の制御可能な設定を固定し、次の四パターンを作ります。

テスト	入力	確認すること
A	構図参照のみ	被写体数、位置、カメラ、トリミング、余白を保持できるか
B	スタイル参照のみ	配色、質感、線、照明のどの特徴が実際に移るか
C	構図とスタイルをフラットなリストで指定	折衷、スタイルの平均化、不要な内容の混入が起きるか
D	構図とスタイルに明示的な役割と優先順位を指定	各目標がテストCより意図に近づくか

これはモデルを「良い」「悪い」と判定するテストではありません。単一画像の解釈、複数画像の統合、エージェントのパラメータ処理のどこから崩れたかを切り分けるためのテストです。AとBは機能し、Cで崩れ、Dで改善するなら、役割の曖昧さが有力な原因候補です。DとCが同じなら、最終ペイロードを確認するか段階方式を使います。

ツールがseedをサポートする場合は、ランダム差を減らすため全パターンで同じ値を使います。seedがない場合は、比較を決定的なものとして扱わず、各パターンを複数回生成して繰り返し現れる構造的な失敗を探します。

手順5：「きれいに見える」ではなく目標構図に照らして合否を決める

危険な出力は、必ずしも見栄えが悪いとは限りません。軽いレビューなら通るほど洗練されていても、本来のテンプレートを外していることがあります。スタイルを評価する前に、まず必須条件を確認します。

必須条件：一つでも誤っていれば不合格

• 被写体の数が正しい。
• 位置と相対サイズがレイアウトに一致する。
• カメラ方向、トリミング、視点が正しい。
• 文字用の予約領域や余白が残っている。
• スタイル参照の物体、人物、文字が出力に混入していない。
• 被写体の特徴的な要素が識別できる。

希望条件：必須条件を通った候補の順位付けに使う

• 配色が目標に近い。
• 質感や粒状感が濁りではなく意図として見える。
• 線、輪郭、影が目指す視覚表現に合う。
• 複数スタイルの平均ではなく、全体が一貫して見える。

構図参照と各候補を横に並べ、必須条件ごとに合格・不合格を記録します。最終画像だけでなく、リクエストの版、参照画像の順番、エージェントが送った正確なペイロードも保存します。これがあれば、次に起きたドリフトを再現して調べられます。

よくある症状は正しい順番で診断する

症状	最初に確認すること	推奨する対応
スタイルは強いが構図が変わる	スタイル画像が同格の主参照として扱われていないか	構図の優先度を上げるか二段階に分ける
構図は正しいがスタイルが弱い	プロンプトが抽象的な雰囲気語だけになっていないか	配色、素材、線、照明を観察可能な表現で指定する
複数のスタイルが汎用的な見た目に溶ける	競合するスタイル画像を同時に入れていないか	主スタイルを一つ決め、他は一つの特徴だけ担当させる
スタイル画像の被写体が出力に現れる	見た目だけを移すと明示したか	物体、文字、構図を明示的に除外する
プロンプト変更が出力に反映されない	エージェントが新しいパラメータを送ったか	上流のフォームではなく最終ペイロードを比較する
APIは成功するがドリフトが続く	技術的成功を視覚的合格としていないか	構図の必須ゲートと統制比較を追加する

再利用できる最小ワークフロー

1. タスクに必要な参照画像だけを選ぶ。
2. 各画像に主な役割を一つ与え、保持、無視、衝突時のルールを書く。
3. 最終リクエストを確認し、配列、順番、役割情報がフラット化されていないことを確かめる。
4. フラット版と役割分離版を比べる前に、構図のみ、スタイルのみの基準画像を作る。
5. スタイルを比較する前に、構図の必須条件で候補を除外する。
6. 候補画像、参照画像、リクエスト版、合否結果を一緒に保存する。
7. インターフェースが役割を表現できない場合は、構図を先に、スタイルを後に処理する。

目標はプロンプトを長くすることではありません。各視覚信号に担当者がいるワークフローを作ることです。「この属性はどの画像が制御するか」「衝突時にどのルールが勝つか」「何をもって合格とするか」に答えられれば、複数の参照画像はモデルが独力で解釈する曖昧な画像の山ではなくなります。