imagen4-fast プロンプトレシピ：開発者がコピー＆ペーストできるプロンプト

なぜプロンプトレシピが一度きりのプロンプトに勝るのか

画像生成の問題のほとんどはモデルの問題ではなくプロンプトの問題であり、しかも修正が難しい。なぜならプロンプトは誰かのチャット履歴や古くなったドキュメントの中にしか存在しないことが多いからだ。火曜日には優れた結果を出した一度きりのプロンプトが、金曜日には再現できない。中身に何が書かれていたのか正確に言えないからだ。

プロンプトレシピはこれを、関数がコピー＆ペーストのロジックを解決するのと同じように解決する。固定された構造、名前付きのスロット、安定した識別子を持ち、後から参照できる。出力が変化したとき、比較できるものがある。

実際の利点はすぐに現れる：

• 呼び出し間の一貫性。 同じレシピと同じ入力なら、比較可能な構図とスタイルが得られる。1つのページがグリッド内に12枚のカード画像をレンダリングする場合、これは極めて重要だ。
• 低コストの反復。 自由気ままな散文を書き直して有効だった部分を失うのではなく、一度に1つのスロットだけを変更する。
• 追跡可能性。 レシピにはバージョンがある。ブランドチームがなぜサムネイルが先月より平坦に見えるのかと尋ねたら、二分探索で切り分けられる。
• レビュー可能性。 レシピは他のアセットと同様にプルリクエストでレビューできる。レビュアーがプロンプトを書いて生計を立てている人である必要はない。

本記事の残りはハンドブックだ。各レシピは同じ骨格に従うので、1つ読んで改造し、リファクタリングせずにコードベースに入れられる。モデルはコンポーネントとして扱い、レシピはその上に構築するインターフェースとして扱おう。

覚えておくべき考え方が1つある：レシピは魔法の呪文ではない。下流のUIスロットと生成呼び出しの間の契約だ。UIスロットが画幅を決め、レシピが何でそれを埋めるかを決める。

基本プロンプト骨格

このハンドブックのすべてのレシピは、同じ4部構成の骨格で成り立っている。これをコピーしてスロットを埋めてほしい：

[subject] — [composition] — [style] — [constraints]

核心はこれだけだ。以下はそのまま貼り付けて使える、埋めたバージョンだ：

A lone ceramic coffee cup on a pale oak desk, three-quarter view, shallow depth of field,
soft morning light from the left, minimal editorial product photography, muted warm palette,
no text, no logos, no hands, centered subject with breathing room on all sides

各スロットの役割

主体（Subject）は画像が扱う唯一のものだ。具体的に名付ける：「コーヒーの雰囲気」ではなく「陶器のコーヒーカップ」。主体に動作や状態がある場合はここに置く：「薄暗い机でキーボードを打つ途中の開発者」。2つ目の主体を追加したくなるのをこらえること。これが結果を雑然とさせる最も一般的な原因だ。

構図（Composition）は画幅を制御する。視点（斜め45度、俯瞰、アイレベル）、主体の位置（中央、3分割法の左）、クロップ（フルフレーム、タイトクロップ）、被写界深度がここに属する。このスロットはアスペクト比の意図を言葉でエンコードする場所だ。実際の比率が別のパラメータであっても変わりない。

スタイル（Style）は短い視覚ボキャブラリーだ：媒体（写真、フラットベクター、水彩）、光（柔らかな朝光、硬いリムライト）、色調（落ち着いた暖色、高コントラストのモノクロ）、質感（マット、光沢、粒子）。1〜3文に抑える。長いスタイルブロックはしばしば互いに衝突する。

制約（Constraints）はネガティブスペースだ。何が現れてはならないか：文字、ロゴ、ウォーターマーク、余分な手足、雑然とした背景、不自然な影。制約は安価な保険であり、レシピが問題を起こしたときに最初に拡張すべき部分だ。

常備しておく価値のある2つのバリアント

ミニマルな物撮り：

[object] on a seamless [color] backdrop, centered, straight-on view, soft even studio light,
clean commercial product photography, no shadows on background, no text, no props

エディトリアルなシーン写真：

[scene subject] in [environment], wide establishing view, natural light, subtle film grain,
documentary photography, muted palette, no text, no logos, no visible brand marks

どちらも意図的に短く保っている。プロンプトが形容詞の寄せ集めになっているなら、構図スロットをどこかに紛れ込ませてしまっている可能性が高い。

プロンプトを書く前にアスペクト比を選ぶ

埋める穴の形を理解してからプロンプトを書こう。アスペクト比はプロダクトの決定であり、プロンプトの決定ではない。遅く選ぶと、すでに調整した構図の短文を書き直すことを強いられる。

ほとんどのUIをカバーする簡単なマッピング：

• ヒーローバナーとページヘッダー——ワイド画幅。構図の言い回し：「wide establishing view」、「horizon placed in the lower third」、「negative space on the left for headline overlay」。
• カードとグリッドタイル——正方形またはほぼ正方形。構図の言い回し：「centered subject」、「even margins」、「no important detail near the edges」。
• アバターとプロフィールの小画像——正方形、タイトクロップ、単一主体。構図の言い回し：「head and shoulders」、「centered face」、「plain background」。
• サムネイルとリスト行——小さなワイド幅または正方形クロップ。主体は縮小後も判別可能でなければならない。構図の言い回し：「single dominant subject」、「high contrast against background」、「no fine detail」。
• エディトリアルや長文記事の挿絵——縦画幅。構図の言い回し：「vertical composition」、「subject occupies the upper two thirds」、「foreground anchor at the bottom」。

なぜ言い回しが画幅に一致しなければならないのか

ワイドバナー用に書いた構図の短文（「negative space on the left」）は、正方形にクロップした途端に意味を失う。逆に言葉で記述したタイトな縦クロップは、ワイド画幅を要求すると押しつぶされる。プロンプトと比率は一致すべきだ。なぜなら同じ矩形を2回記述しているからだ——1回は言語で、1回はパラメータで。

実践的なワークフロー

1. 実際のUIスロットを確認し、そのアスペクト比と小さい画面でのクロップのされ方を記録する。
2. モデルに余白で偽装させるのではなく、最も近いサポート済みアスペクト比を選ぶ。
3. その画幅に合わせて構図スロットを書く。ネガティブスペースをどこに置くかも含めて。
4. 生成後は理想的なケースではなく、最悪のクロップ（モバイル、グリッド縮小）を確認する。

1つのレシピが大きく異なる2つのスロットにサービスしなければならないなら、2つのレシピにしよう。レシピを1つコピーするほうが、どこでも中途半端に機能する構図の短文を書くより割に合う。

UIごとに切り替え可能なスタイル手がかりブロック

スタイルスロットは最も頻繁に変更されることが予想される部分なので、モジュール化しよう。スタイルの手がかりを自己完結したブロックとして書き、基本骨格に掛け、UIやブランドトーンごとに1つずつ保持する。

ブランドセーフ / ニュートラル

minimal editorial photography, soft diffused light, muted neutral palette,
clean background, product-focused, no text, no logos

マーケティングページで、画像がコピーと注意を奪い合わず、ブランド主張を示唆しない場合に使う。

写真 / ドキュメンタリー

natural light, documentary photography, shallow depth of field, subtle grain,
unposed subject, realistic color, no heavy filters

エディトリアル挿絵やナラティブUIで、洗練よりもリアリティが効く場合に使う。

フラットイラスト

flat vector illustration, limited two-color palette, bold simple shapes,
no gradients, generous whitespace, geometric composition, no text

オンボーディング、空状態、ドキュメントで、画像がデザインシステムと一致する必要がある場合に使う。

スタジオ商品撮影

seamless studio backdrop, soft even key light, crisp shadows, high detail on the subject,
commercial catalog photography, no props, no text

商品カタログや比較グリッドで、個々の画像よりも複数画像間の一貫性が重要な場合に使う。

劣化させずに切り替える方法

• スタイルブロックを変数として扱い、主体や構図の短文と決して混ぜない。スタイル語がプロンプト全体に散らばっていると、きれいに置き換えられない。
• 一度に1つのブロックだけを変更し、同じ主体と構図で再生成する。2つの変数が同時に動くと、どちらが変化を引き起こしたか判断できない。
• スタイルブロックがこっそり構図を持ち込んでいないか警戒する。「Centered」や「close-up」はスタイルではなく構図に属する。それらがスタイルブロックに住んでいると、アスペクト比への努力が静かに無効化される。
• 膨れ上がり続けるブロックを剪定する。スタイルの短文は通常3つで十分。5つになると互いに競争し始める。

有用なテスト：それ以外が完全に同一のレシピでスタイルブロックを置き換え、出力が同じUIスロットにまだ適合するか見る。適合するなら、そのブロックは適切に分離されている。

コードでプロンプトをパラメータ化する

レシピは各ハンドラに散らばった文字列リテラルではなく、テンプレートとして存在すべきだ。名前付き変数を持つテンプレートは、A/Bテスト、ロールバック、UIごとのオーバーライドを無料で提供してくれる。

テンプレートの形

RECIPE = {
    "id": "product-hero-v3",
    "template": (
        "{subject} — {composition} — {style} — {constraints}"
    ),
    "defaults": {
        "composition": "centered subject, generous margins, eye-level view",
        "style": "minimal editorial photography, soft diffused light, muted neutral palette",
        "constraints": "no text, no logos, no watermark, clean background",
    },
    "aspect_ratio": "1:1",
}


def render(recipe, **overrides):
    slots = {**recipe["defaults"], **overrides}
    return recipe["template"].format(**slots)

レシピオブジェクトはその識別子（id）、画幅（aspect_ratio）、デフォルト値を運ぶ。呼び出し側は差分だけを提供する。これにより呼び出し箇所が短く保たれ、2つのUI間の差異が一目でわかる。

A/Bテスト用のバリアント

バリアントは分岐した文字列ではなく、基本レシピへのオーバーライドとしてモデル化する：

variants = {
    "control": {},
    "warm": {"style": "minimal editorial photography, warm afternoon light, muted warm palette"},
    "tight": {"composition": "tight crop, subject fills the frame, eye-level view"},
}

各バリアントが主体と制約を共有するので、結果の差異を変更したスロットに帰属させられる。これがこの練習の価値のすべてだ。

ロールバックと固定

• idに各レシピのバージョンを持たせ、各生成リクエストで記録する。出力が変化したとき、ログがどのレシピバージョンが何を生成したかを教えてくれる。
• 一定期間、旧バージョンをアドレス可能に保つ。ロールバックは設定変更であるべきで、プレッシャー下でのコードリバートであってはならない。
• 独自の分析システムに渡すときは、レンダリング後の文字列ではなくレシピIDを使う。これにより正確なプロンプトテキストではなくレシピごとに結果をグループ化できる。
• APIを呼び出す前にスロットを検証する——空のsubjectは曖昧な画像を生成するのではなく、アプリ内で早期に失敗すべきだ。

アスペクト比はテンプレートと並ぶ一級のパラメータとして扱う。UIスロットによって決まり、プロンプトテキストによって決まるのではないからだ。APIに必要なものはすべて1つのレシピオブジェクトから導出され、各UIに単一の真実の源ができる。

よくある失敗パターンとデバッグ方法

悪い出力のほとんどは1つのスロットに遡れる。このチェックリストで、プロンプト全体を書き直す前に骨格のどの部分を調整すべきか判断しよう。

主体が切れている、または画面外

症状：頭が切れている、物体が端からはみ出している、重要な詳細がセーフエリアの外にある。

まず構図スロットを直す。スタイルではない。明示的なフレーミング言語（「full subject in frame」、「generous margins on all sides」）を加え、アスペクト比が意図した画幅と一致するか確認する。主体自体が高くスロットが広いなら、それはプロンプトではなく画幅が間違っている。

結果が雑然としている

症状：複数の競合する焦点、煩雑な背景、要求していない小道具。

主体スロットを直す。1つの主体、1つの状態に絞る。小道具として読まれるものを制約に除外項目として移す。雑然さは通常、モデルの過剰な熱意ではなく主体の曖昧さだ。

バッチ内でスタイルが一貫しない

症状：グリッド内で写真のように見えるものとイラストのように見えるものが混在する。色調が漂う。

スタイルブロックを直す。1つの媒体、1つの光の短文、1つの色調の短文に短縮する。他のスロットに漏れているスタイル語を除去し、2つの異なるUIに同時にサービスしているレシピを分割する。バッチ内の不一致は、スタイルブロックが呼び出しごとに異なる症状であることが多い。

文字やロゴが現れる

症状：意味不明な文字、偽のウォーターマーク、ブランドマークらしきもの。

制約を拡張する：「no text, no lettering, no logos, no watermarks, no signage」。構図が通常文字のある媒体（画面、パッケージ、ポスター）を示唆しているなら、明示するか構図を変える。

出力が要求したムードを無視している

症状：画像は正しいが、平坦、硬い、またはありきたりに感じる。

スタイルブロックを直す。一度に1つの短文。光が通常最もてこの効く変更で、色調が次だ。同じ主体と構図で再生成し、比較を誠実にする。

その他すべての場合

2つのスロットが疑わしいなら、1つを変えて再生成する。それでも正しくないなら、一歩下がって、レシピが書かれたことのないUIスロットにサービスするよう要求されていないか確認する——それはプロンプトの欠陥ではなく、プロダクトの不整合だ。

レシピライブラリを公開する

レシピがバージョン付きテンプレートになれば、チームがコードとともに維持するアセットになる。目標は、誰もがあるUIの背後にあるレシピを見つけ、なぜそうなっているかを理解し、安全に変更できることだ。

プロンプトテキストではなくUIで整理する

レシピをレンダリング位置でグループ化する：hero、card、avatar、thumbnail、editorial-figure。価格ページを見ている開発者は、そのページで使われているレシピにたどり着くべきで、アルファベット順の形容詞リストではない。各レシピに安定したIDとバージョン接尾辞を与え、デフォルト値をレシピオブジェクト内に保つ。

プルリクエストでレシピをレビューする

レシピの変更をコンポーネントの変更として扱う。差分はどのスロットが動いたか、なぜ動いたかを示すべきだ。レビュアーは有用な質問ができる：構図はまだ画幅と一致しているか、スタイル語が構図に漏れていないか、制約が縮んでいないか。小さな単一スロットの差分はレビューしやすいが、全面的な書き直しはそうではない。

バージョン管理、記録、クリーンアップ

• 各生成リクエストでレシピIDとバージョンを記録し、出力の変化をある変更に追跡できるようにする。
• どのUIも参照しなくなるまで非推奨バージョンをアドレス可能に保ち、その後は1回のクリーンアップで削除する。死んだレシピを永遠に残さない。
• バリアントを追加するときは、A/Bブランチを恒久的なパスとして残すのではなく、勝者を新バージョンに昇格させる。

契約を文書化する

各レシピについて、想定されるUIスロット、アスペクト比、捨ててはならない制約を記録する。2文で足りる。次にこのレシピを触る人は、何を壊してはならないかを知る必要がある。

ループを短く保つ

レシピはデザイン変更後に誰も再生成しないと腐る。画像スロットを変更するUI作業に小さなレビューステップを組み込み、その変更の一部として影響を受けるレシピを再実行する。フィードバックループが短く保たれて初めて、システム全体が低コストに保たれる。

基本骨格から始め、UIごとに1つのスタイルブロックを加え、レシピライブラリを仮想のスロットではなく実際のスロットから育てよう。生成をアプリに組み込むなら、呼び出し箇所を軽く保ち、レシピオブジェクトに意思決定を運ばせよう。