AI画像生成ワークフロー：修正・再生成・採用を決めるレビューゲート

AI画像生成のワークフローで時間の大半を占めるのは、プロンプトを書くことではない。上がってきた画像を見て、どう扱うかを決めることだ。これを残す、この輪郭を直す、やり直す、あるいはレタッチャーに丸ごと渡す。この判断を勘でやっていると、作業はループになる。どの画像も直前のものより少しだけ良く見えるので、どの画像にももう一ラウンドの価値があるように思え、後から「なぜあのファイルが承認されたのか」を誰も説明できない。

レビューゲートは、判断を明示的なものにすることでこのループを断ち切る。構成要素は四つ。最初のレンダリングの前に書く合格基準、チェックの固定順序、候補を比較する一つの方法、そして修正・再生成・合成のどれを選ぶかを決めるルールだ。ゲートはモデルに良い画像を出させるものではない。不要なラウンドに払うコストを止めるものだ。

最初のレンダリングの前に合格基準を書く

四行で足りる。所要時間は五分だ。

• 納品サイズとクロップ：1200ピクセルのインライン画像、3000ピクセルのヒーロー、正方形のソーシャルカード、4:5の縦位置。
• フレーム内で数えられるべきもの：製品一つ、人物二人、ボトル三本、読める見出し一つ。
• 動いてはいけないもの：ラベルのアートワーク、製品のプロポーション、クライアントのマーク、地平線。
• 画像が最も小さく見られる場所：関連記事のサムネイル、検索結果、スマートフォンのフィード。

各行は後でチェック項目になる。「いい感じ」は議論の余地がないが、「320ピクセル幅でラベルが読める」は、プロンプトを書いていない人でも十秒で合否を判定できる。基準はレビュアーが代わっても生き残る。画像を生成する人と承認する人が別人であるとき、これは効いてくる。

出荷するサイズで生成する

解像度はレビューの変数であって、書き出しの設定ではない。現行の Nano Banana モデルでは、出力は1Kから始まり、2Kまたは4Kを指定できる。Google の Nano Banana 2.1 のモデルドキュメントには、1Kがデフォルトで2Kと4Kが選択可能とあり、Nano Banana Pro の仕様ページにも同じ三つの出力サイズが記載されている。これがレビュー時に効くのは、欠陥が均等に拡大しないからだ。細かい文字、細いストラップ、髪の輪郭、小さな製品の文字は1Kではきれいに見えても4Kで破綻することがあり、逆にサムネイルで崩れる構図が原寸で見るとまったく妥当に見えることもある。

現実的な妥協点は、意図的に安いラウンドを一度だけ回すことだ。小さくレンダリングし、構図だけを見て、そのファイルは捨てる前提で臨む。構図が決まったら納品解像度に移り、そこでディテールを判断する。4Kで出荷する素材は4Kで、100パーセント表示でレビューすべきだ。避けるために対価を払っている不具合が見えるのは、その表示だけだからだ。

構造を先に、ディテールを次に、適合性を最後に

パスはこの順序で回し、先へ飛ばさない。

構造パスでは、そのフレームが正しいフレームかどうかを問う。被写体を数え、要求された比率に対してクロップを確認し、重要なものがセーフエリアの外に出ていないことを確かめる。視線がどこに落ちるかを見つけ、そこがメッセージの置かれるべき場所かどうかを判断する。コピーや商品バッジが入る余白を探す。高くつく失敗の多くはここで起き、しかも最も安く見つかる。

ディテールパスでは、フレームが正しく描画されているかを問う。被写体と背景の境目に沿って輪郭をたどる。手、ストラップ、工具の柄、反射、落ち影を見て、影の向きが光と一致しているかを確認する。文字はすべて声に出して一文字ずつ読む。流し見で済ませない。大きな平坦面を走査して、生成された表面らしさを露呈する繰り返しのテクスチャがないかを見て、遠景に誰も頼んでいない物体がないかを確認する。

適合性パスでは、その画像が実際に使われる場所で機能するかを問う。納品サイズで、掲載される面の上に表示し、次にそれが見られる最小の場所まで縮小する。サムネイル幅で被写体が読めなくなるなら、悪いのはディテールではなく構図であり、修正ラウンドでは直らない。

順序そのものが要点だ。これから差し替えるフレームにディテール修正を施すのは、同じ時間を二度払うことになる。しかもディテールパスは最も遅い。

候補は同じサイズで並べて比較する

人間の判断は、画像が一枚ずつ届くとぶれる。最新のレンダリングはたいてい直近に見たものなので、最も完成しているように感じる。最初のレンダリングは、頭の中で承認した記憶として残っているものだ。どちらの効果も品質のシグナルではない。

三、四の候補を同じ寸法の一つのグリッドに並べ、自分では選んでいない順序にし、それぞれを互いではなく基準リストに照らして採点する。グリッドは次のラウンドまで残しておく。構造で負けた候補を、照明が最も良いという理由で救ってはいけない。そうやって妥協を一つずつ重ねて、惜しいだけの束が承認されていく。

決める：修正か、再生成か、合成か

ほぼすべてのレビューは三つの結果で片づく。どれを選ぶかを意識的に決めることが、ラウンド数を抑える。

修正は、構造が正しく欠陥が局所的なときだ。位置がずれた物体が一つ、色が違う箇所が一つ、輪郭が甘い辺が一つ、綴りが誤った語が一つ。修正とは、一ラウンドにつき変更一つ、それに加えて同一に保つものを明示した保存リストだ。保存リストのない編集指示は、フレーム全体を描き直すようモデルに促すことになる。

再生成は、構造が誤っているときだ。被写体の数が合わない、クロップに構図が収まらない、必須の要素が欠けている、あるいはシーンが伝える意味が違う。悪いレイアウトに修正ラウンドを重ねるのは、プロンプトを直すか参照画像を足して新しくレンダリングするより高くつき、その過程でアーティファクトが積み上がりやすい。

合成は、ピクセル単位の厳密な保持が要件のときだ。実在の製品ラベル、既存の写真、承認済みのマーク、動いてはならない手描きの要素など。ある領域が手を加えられないまま残ることを保証するプロンプトは存在しない。レイヤーを持つエディターなら保証できる。

同じ基準を二ラウンド続けて動かせないなら、それは言い回しではなくアプローチが間違っている合図だ。形容詞を足すのではなく、入力の種類を変える。対象領域を正確に描写する、参照画像を渡す、あるいは作業を別のツールに移す。

ラウンドログを残す

一ラウンドにつき一行、ブリーフと同じファイルに。モデル、解像度、プロンプトのバージョン、前のラウンドからの変更点、通った基準と落ちた基準、そして判定。レンダリング一回につき二分の記録で、三番目の候補がなぜ承認されたのかと誰かに聞かれた最初の場面で元が取れる。

ログはプロンプトも良くする。落ちた基準は「構図がぎこちない」ではなく「ボトルのキャップが上端で切れている」のように、画像の中で観察できる事実として書く。そうすれば次のラウンドに狙いができる。同じ基準が三回の試行で三つの異なる言い回しのまま落ち続けるなら、問題はたいてい文章ではなく入力画像かフレーミングにある。

モデル間の違いをレビュー入力として扱う

モデルのドキュメントは、試すべきことの一覧であって、飛ばしてよいことの一覧ではない。Google の Nano Banana 2.1 のページには、テキスト描画とインフォグラフィックのレイアウトの改善、選択可能な思考レベル、最大十四枚の参照画像によるキャラクターの一貫性（四人まで）とオブジェクトの忠実度（十個まで）、そして2Kと4Kで対処された極端なパノラマ比率でのタイル状アーティファクトが報告されている。それを知っているレビュアーは、小さな文字を意図的に試し、繰り返し登場する被写体には参照画像を使い、非常に横長のフレームでは継ぎ目に沿って目を走らせる。同じページを約束として読むレビュアーは、その三つすべてを飛ばす。

モデル同士の比較でも同じだ。軽いモデルと重いモデルのどちらも1K、2K、4Kで出力できても、あなたのブリーフが重視する一つの基準では差が出る。その基準で、同じゲート、同じサイズで採点し、負けたファイルはログとともに残す。次のバージョンが出たときに選択を再検討できる。

ファイルだけでなくレシピで承認する

レシピのない承認済み画像は、後から拡張できない成果物だ。採用したファイルには、プロンプトのバージョン、そこから生まれたモデルと解像度、ラウンド数、通った基準リスト、使った参照画像を添えて保管する。三か月後に別案が必要になった人は、幸運なレンダリングではなく、既知の出発点から始められる。

却下のメモも同じ記録に入れる。「2Kで手が融合する」「四ラウンド目でラベルの文字がずれる」は、二度目に書くときには安上がりな教訓になる。前四半期の失敗を参照できるレビュアーは、今四半期により良い基準を書ける。

KOOX AI でゲートを回す

KOOX AI Nano Banana Pro のページは、ゲートを練習するのに使える場所だ。四行の基準を書き、構造確認用に安いフレームを一本レンダリングし、納品サイズに移り、三つのパスを順に回し、出力の隣にログを置く。最初の一回はいつものループより遅く感じる。二回目はたいてい、ループより少ないレンダリング数で済む。