Imagen 4.0 Ultra プロンプトレシピ：リアルなディテールとライティングを実現するコピー＆ペースト可能なプロンプト

Ultra グレードでプロンプト構造が特に重要な理由

画像モデルの最高品質グレードは魔法のボタンではない。プロンプトにはより忠実に従うが、これは諸刃の剣だ。曖昧なプロンプトは精緻だが平凡な画像を返し、自己矛盾したプロンプトは自信ありげに見えて実際には誤った結果を返す。Ultra グレードでは、支払っているのは忠実度であり、それゆえプロンプトそのものが主な制御変数となる。

キーワードの羅列はよくある失敗パターンだ。4k, ultra detailed, masterpiece, hyperrealistic, sharp focus, trending のようなリストは、モデルに何をレンダリングするかもどうライティングするかも伝えない。大半は単なるノイズを増やすだけで、毎回の生成がフル品質の呼び出しである場合、そのノイズのコストは高い。

構造化されたプロンプトは同時に三つのことを実現する：

• 出力を再現可能にする。 プロンプトに固定スロットがあれば、一つのスロットだけを変えて、何が差異を生んだのかを明確に把握できる。
• デバッグを可能にする。 画像に問題があるとき、全体を書き直すのではなく、失敗したブロック（多くの場合ライティングやカメラ）を特定できる。
• 統合をテスト可能にする。 プロンプトテキストはバージョン管理できる資産となり、記録・差分比較・A/B テストができる。関数呼び出しの中の一つの文字列に埋め込まれることはない。

本ガイドの残りの部分では、骨組み、ライティング語彙、ネガティブプロンプトに関する短いルール、そして HiAPI.ai の統一インターフェースを通じて自分の呼び出しに貼り付け、そこから調整できるレシピ群を提供する。

五ブロックのプロンプト骨組み

毎回、同じ五つのブロックを同じ順序で使う。順序は一貫性ほど重要ではないが、主体を先に読む方式が最も効果的だ。後続のブロックはすでに確立されたシーンへの修飾だからだ。

[主体] + [ディテール] + [ライティング] + [カメラ] + [スタイル]

第 1 ブロック：主体

一文で主要な対象とその動作や状態を示す。具体的な名詞は形容詞に勝る。

木製のテーブルに置かれた陶器のコーヒーカップ、湯気が立ち上る

第 2 ブロック：ディテール

主体を具体的に見せるもの——素材、摩耗、テクスチャ、微妙な傷。リアルさはここで得られる。

……釉薬をかけた粗陶器、縁に欠け、外側に細かな結露、木目に目に見える傷

第 3 ブロック：ライティング

最もレバレッジの効くブロック。光源、方向、質感を明示する。次の節で詳しく展開する。

……左側からの窓光に照らされ、柔らかく、曇りの午後

第 4 ブロック：カメラ

構図、距離、レンズ特性。簡潔に保つ：クローズアップ、50mm、浅い被写界深度 で通常は十分だ。

……クローズアップ、50mm、浅い被写界深度

第 5 ブロック：スタイル

ここに至って初めてレンダリング意図を加える：エディトリアル製品写真、ドキュメンタリースタイル、映画のスチル。中立的な出力が欲しいなら完全に省略する。

……エディトリアル製品写真

組み立てると、完全なプロンプトは一行になる：

木製のテーブルに置かれた陶器のコーヒーカップ、湯気が立ち上る、釉薬をかけた粗陶器、縁に欠け、外側に細かな結露、木目に目に見える傷、左側からの窓光に照らされ、柔らかく、曇りの午後、クローズアップ、50mm、浅い被写界深度、エディトリアル製品写真

二つの経験則。第一に、あるブロックに有用な内容がなければ、埋め草で埋めるのではなく省略する。第二に、全体の長さを制御する——五つの具体的な節からなるコンパクトなプロンプトは、通常、修飾語の段落より優れている。

プロンプトで光と影を制御する

レシピで一つだけ変えるなら、ライティングブロックを変えよう。光は雰囲気を決め、テクスチャを浮かび上がらせ、画像を「レンダリングされたもの」から「撮影されたもの」へ変える最速の手段だ。

四つの属性を明示する：

• 光源： 窓、曇り空、裸電球、ろうそく、ソフトボックス、スクリーン光、街灯。
• 方向： 左側から、逆光、トップ光、ローサイド光、フロント四分の三。
• 硬さ： 柔らかい拡散光か、硬い指向性光か。これは他のどの要素よりも影のエッジを左右する。
• 時間帯： 曇りの午後、ゴールデンアワー、ブルーアワー、真昼の陽光、夜。

汎用性の高い語彙

左側からの柔らかな窓光、なだらかな減衰
強い真昼の陽光、くっきりとした影、高コントラスト
逆光でリムライト、主体は影の中
曇天の日光、平坦で均一、影はごく少ない
一つの暖色のランプ、周囲は暗闇、光のプール

よくあるライティングの誤り

矛盾。 柔らかい光、強い影 はモデルに相容れない二つの指示を与える。どちらか一つを選ぶ。

方向の未指定。 良いライティング は制御項目ではなく願望だ。光がどこから来るのかを必ず述べる。

ライティングとカメラの衝突。 逆光 と 均一に照らされたクローズアップ は逆方向に引っ張り合う。ライティングブロックに決定させ、カメラブロックは構図のみを記述させる。

時間帯を調味料扱いする。 ゴールデンアワー は現実的で拘束力のある条件だ。美しい光 はそうではない。

有用な習慣：ディテールブロックより先にライティングブロックを書く。強いサイド光が欲しいと分かっていれば、テクスチャが強いコントラストの中でも識別可能でなければならないと分かり、ディテールブロックで何を強調すべきかが分かる。

ネガティブプロンプトを使うべき時と方法

ネガティブプロンプトは短い回避項目リストであり、二つ目のプロンプトではない。別の画像の完全な記述にまで拡張されると、ポジティブプロンプトと競合し、混乱した結果を生む。

ネガティブプロンプトが得意なこと

• 繰り返し現れるアーティファクトの除去： 主体にいつも看板が生えてくるなら、テキスト、透かし、ロゴ。
• 構図をデフォルトから逸らす： モデルがいつも平坦で中央寄せのレイアウトを既定にするなら、中央構図、対称。
• 特定の不要なスタイルの排除： 写真的な出力が欲しいなら、漫画、3D レンダリング、イラスト。
• 不要な要素の抑制： クリーンな製品写真を撮るとき、群衆、背景の人物。

ネガティブプロンプトにできないこと

人体構造、手、テキストレンダリングを確実に修正することはできない——これらはプロンプトではなくモデルレベルの制約だ。また、ポジティブプロンプトが一度も要求していないディテールを追加することもできない。繊細なテクスチャが欲しいなら繊細なテクスチャを記述しよう。ぼやけ を列挙して効くことを期待してはいけない。

三〜六項目に保つ

テキスト、透かし、余分な指、彩度過多、漫画

これは健全なリストだ。二十語のリストは通常、ポジティブプロンプトの記述不足を示している——まずそれを直し、より短いネガティブリストで再テストする。ネガティブプロンプトはシーンごとに使い回すのではなく、レシピに合わせて再構築しよう。肖像画に役立つネガティブ項目は、風景にはしばしば有害だ。

出発点として使えるコピー＆ペースト可能なレシピ

以下の各レシピは五ブロックの骨組みに従う。貼り付けてから、一つの変数——太字で示されたもの——だけを変え、ベースラインと比較しよう。最終的な答えではなく、出発点として扱うこと。

レシピ 1：リアルな質感を持つ製品クローズアップ

コンクリートの机に置かれたマットブラックのメカニカルキーボード、キーキャップに目に見える摩耗、隙間にほこり、右側からの強いサイド光、くっきりとした影、85mm、浅い被写界深度、エディトリアル製品写真

調整する変数： 強いサイド光 を 柔らかな窓光 に変え、表面テクスチャがどれだけ保たれるか観察する。この一つの変更が、モデルのライティングへの応答を最もよく理解させてくれる。

レシピ 2：環境的文脈を持つポートレート

作業場に立つ四十代の女性、袖に木くず、かすかな微笑み、カメラの左後方の大きな窓からの曇天の日光、柔らかく均一な光、50mm、ミディアムショット、ドキュメンタリー写真

調整する変数： 時間帯。夕方の陽光、暖色のリムライト を試し、肌色と影の表現を比較する。

レシピ 3：妥当な光源の根拠を持つ室内シーン

夜の小さなアパートのキッチン、水切りかごで乾く食器、テーブルの上の暖色のペンダントライト、周囲は暗闇、光のプール、35mm、広角レンズ、自然な映画のスチル

調整する変数： 光源の数。廊下から差し込む冷たい光 を加えて二光源の混合を作る。室内シーンがリアルに見え始めるのはここからだ。

レシピ 4：装飾ではなく天候を持つ風景

干潮時の岩の海岸、濡れた石と海藻、遠くの霧堤、左上からの雲を抜ける柔らかな指向性光、24mm、広角レンズ、風景写真

調整する変数： 硬さ。同じシーンで 強い陽光、くっきりとした影 を試し、霧の表現を比較する。

レシピ 5：リアルな欠点を持つ食べ物

半分食べたサワードウトーストにバターを塗ったもの、リネンのナプキンにパンくず、トーストの縁は不揃い、左側からの暖かな窓光、柔らかな減衰、100mm マクロ、浅い被写界深度、フード写真

調整する変数： ディテールブロック。欠点の節を完全に取り除き、どれだけリアルさを失うか見てみよう——これでディテールブロックの価値が具体的に実感できる。

どのレシピを調整し、どの変数を変えたかを記録しよう。この記録が、自分自身のプロンプトライブラリの出発点になる。

自分のワークフローでレシピをテストする

レシピは、良くなったかどうかを判断できて初めて役に立つ。そのためには最小限のプロセスが必要だ——フレームワークではなく、規律である。

毎回の生成を記録する

毎回の呼び出しごとに保存する：プロンプトテキスト、レシピ ID、変更した単一変数（あれば）、そして出力。フラットな JSON ログか、実行ごとに一ファイルで十分だ。ログがなければ記憶で比較するしかなく、数十のバリエーションを前にして記憶は信頼できない。

一度に一変数だけ変える

ベースラインレシピを一つ選び、実行し、一つの節だけが異なるバリエーションを生成する。同じ呼び出しでライティングとディテールの両方を変えたら、結果を帰属させられない。確かに遅い。しかし、シーンをまたいで転移する直感を築く唯一の方法でもある。

目視だけでなく採点する

一貫して適用する短い評価基準を保つ：主体の正確さ、テクスチャのリアルさ、ライティングの正確さ、アーティファクト。各次元を簡単な三分制で採点するだけでも、画像の山を比較可能な集合に変えられる。

いつ納品できるかを知る

あるレシピが同じプロンプトの小規模な反復実行で許容可能な出力を生み、気にしている変数が変更時に予測可能に振る舞うなら、そのレシピは準備完了だ。一度しか成功しないレシピはレシピではない。

状況の変化に応じて再テストする

今日効く言い回しが後で違う振る舞いをするかもしれない。モデルのバージョンやプラットフォームの挙動は時間とともに変わるからだ。ドリフトに気づいたら、すべてを書き直すのではなく、ベースラインセットを再実行し、影響を受けたレシピを更新する。

HiAPI.ai の統一インターフェースでバリエーションを実行し、ログをコードと一緒に置こう。そうすればレシピの変更は、他のあらゆる資産と同じように、レビュー可能な差分になる。