GPT-Image-2 テキスト・トゥ・イメージ用プロンプトレシピ：開発者向けのコピー＆ペースト可能なプロンプト集

なぜプロンプトレシピが使い捨てプロンプトに勝るのか

多くの開発者は画像生成をスロットマシンのように扱っている。一文を入力し、レバーを引いて、結果を見て、肩をすくめて、また試す。デモならそれでいい。しかし、同じ種類の画像を十数のエンドポイント、一度のUIリニューアル、あるいは並行して進む3つのクライアントプロジェクトにまたがって必要になった途端、このやり方は破綻する。

プロンプトレシピはそうではない。それは特定の1枚の画像ではなく、ある種類の画像をどう産出するかを記述した、小さくバージョン管理可能なドキュメントだ。構造化されているからこそ、テストでき、差分を比較でき、共有できる。

レシピは通常4つのモジュールで構成される：

• 主体 —— 画面に実際に何があるか（物体、キャラクター、シーン、抽象的形態）。
• スタイル —— 視覚言語：写真、フラットベクター、アイソメトリック、水彩、3Dレンダリングなど。
• 構図 —— フレーミング、カメラ角度、ネガティブスペース、主体の位置。
• 出力制約 —— アスペクト比、想定用途、そしてあらゆる品質や解像度の意図。

利点は一貫性にある。同じレシピから主体だけを差し替えた2枚の画像は、まるで兄弟のように見える。使い捨てプロンプトから生まれた画像同士は、まるで他人のように見える。プロダクトUIにおいて——オンボーディングのイラスト、マーケティングバナー、空状態——兄弟のような類似性こそが肝心なのだ。

レシピは失敗をデバッグ可能にもする。出力が違っていれば、すべてを書き直すのではなく、どのモジュールが問題だったかを問える。そして各モジュールはプレーンテキストなので、レシピをコードと一緒に置き、diffをレビューするようにプロンプトの変更をレビューできる。

gpt-image-2/text-to-image@ext では、この規律はほとんどコストがかからない：レシピとは、適切に順序付けられたプロンプトと少数のリクエストパラメータにすぎない。以下のセクションでは、レシピの解剖、アスペクト比の扱い、解像度の注意点、そしてすぐにコピーできるレシピ集を示す。

コピー＆ペースト可能なレシピの解剖

実用に耐えるレシピには、固定された骨格と可変のスロットがある。以下がその骨格で、コードコメントにそのまま貼り付けて埋められるように書いてある：

SUBJECT: <この画像が唯一表現すべきもの>
DETAIL: <2〜4個の具体的属性：素材、色、質感、年代>
STYLE: <名前のついた視覚スタイル + 参照形容詞を1つ>
COMPOSITION: <フレーミング、角度、主体位置、ネガティブスペース>
LIGHT & COLOR: <光の方向、色調、コントラスト>
CONSTRAINTS: <必ずある / 絶対にあってはならない>
INTENT: <この画像をどこで使うか>

順序は見た目以上に重要だ。主体を先頭に置き、モデルにまずそれをアンカーさせる。制約は最後に置き、初期のノイズではなく最終命令として読ませる。各行は具体的に——「マットなセラミック」は「良い素材」に勝り、「やや高めからの3/4ビュー」は「良いアングル」に勝る。

以下はそのままコピーできる記入済みの例だ：

SUBJECT: セラミックのコーヒーカップ
DETAIL: マットなアイボリー釉薬、ろくろ目が視認できる、縁に沿った細い無釉の帯、右側に小さな取っ手
STYLE: プロダクトフォトグラフィー、ソフトミニマル
COMPOSITION: 中央配置、やや高めからの3/4ビュー、被写体の周囲に十分な余白、小道具なし
LIGHT & COLOR: 左上からの大きなソフトライト、右下へと柔らかく減衰する影、ニュートラルな暖色ホワイトの背景
CONSTRAINTS: 文字なし、ロゴなし、手なし、人物の映り込みなし
INTENT: ECの商品タイル、正方形にトリミングされる

この骨格を支えるいくつかの習慣：

• 1つのレシピに1つの主体。 「と」を書き始めたら、分割する。
• スタイルに名前をつける。 「ミニマル」は曖昧だが、「2pxストロークのフラットベクターイラスト」はレシピになる。
• 何を排除するかを明言する。 モデルは空白を埋めてしまう。画像がローカライズフローに合うよう文字なしでなければならないなら、そう明記する。
• INTENTは人間のデザイナーが読むつもりで書く。半年後にあなた自身が確かに読むのだから。

この骨格が自然になれば、本記事のどのレシピも単なる異なる穴埋めにすぎない。

16種のアスペクト比を扱う

gpt-image-2/text-to-image@ext は16種の出力アスペクト比を提供する。これは寛大であり、その寛大さこそが人々に再実行を無駄にさせる原因だ：感覚で比率を選び、合わない構図を得て、また生成し直す。

これを避けるには逆の順序で進める——先に配置先を決め、次に比率を選び、それから合った構図行を書く。

画像の配置先で比率をグループ化する

• ワイドバナーとヒーロービジュアル —— 横長比率、おおよそ16:9から21:9の範囲。構図行：ワイドな横長フレーミング、主体は片側に寄せ、反対側にテキストオーバーレイ用の大きな空白領域を残す。
• 正方形タイル、アバター、アプリアイコン —— 1:1。構図行：主体を中央に、タイトで対称なフレーミング、主体が画面の大部分を占め、余白はごく小さい。
• 縦型フィードとストーリー投稿 —— 縦長比率、おおよそ4:5から9:16の範囲。構図行：縦長フレーミング、主体は上部3分の2に配置、下部に柔らかな空白の帯を残す。
• ドキュメント、サムネイル、印刷風レイアウト —— 古典的な4:3や3:2風の比率。構図行：バランスの取れたフレーミング、主体を中央に、四辺の余白を均等に。

比率はリクエストパラメータだけでなくプロンプトにも書く

リクエストパラメータはキャンバスを決める。プロンプトはキャンバスに何を埋めるかを決める。パラメータだけを設定すると、ワイドなキャンバスなのに主体が正方形構図で描かれてしまうことがよくある——小さな物体が空間に浮いている状態だ。だから常に両者をペアにする：

COMPOSITION: ワイドな横長フレーミング、主体は左側3分の1に配置、
右側にタイトル用のきれいなネガティブスペースを残し、
中央線を越える要素はない

ほとんどの再実行をなくす2つのルール

1. スペースを確保していない限り、文字の配置を要求してはならない。 ネガティブスペースはプロンプト命令であり、後付けの考えではない。
2. 先に比率を選び、それからスタイルを反復する。 スタイル変更は再評価コストが低いが、新しい画角のために構図をやり直すのはそうではない。

2つの比率で迷ったら、まず正方形版を生成する。正方形に近い構図はワイドや縦長にトリミングしても損傷が最小で、未テストのレシピにとって最も安全な出発点になる。

4K出力向けにレシピを調整する

高解像度のリクエストは2つのことを変える：プロンプトで何を要求すべきか、そしてレスポンスで何を検証すべきか。キャンバスは大きくなるが、プロンプトの意図は自動的にそれに合わせて拡張されない。

プロンプトで変えること

より大きな出力は、モデルが細部を表現する余地を持つことを意味する。これは通常良いことだ——布地の質感、エッジの定義、繊細なグラデーション——だが、曖昧な文が目に見える瑕疵になることも意味する。

• 細部の下限を加える。 どの程度の細部が適切かを明示する：主体には繊細な表面のディテールが見え、背景はきれいでシンプル、煩雑なテクスチャはない。 これがないと、高解像度出力は空白領域をノイズで埋めてしまうことがよくある。
• 制約ブロックを引き締める。 小さいサイズでは余計な文字は染みにすぎない。大きいサイズでは読める意味不明な文字になる。排除項目を明示的に再確認する：文字なし、ウォーターマークなし、看板なし。
• エッジについて明示する。 素材がマスクや合成に使われるなら、主体と背景のきれいな分離、エッジの色にじみなしを要求する。
• 主体を増やし詰め込まない。 ピクセルが増えることはより多くの内容を収める許可ではなく、同じ内容をより高精細に表現する許可だ。

レスポンスで確認すること

• 実際に返されたサイズ —— 想定するのではなく、レスポンスが要求と一致することを確認する。
• 縮小の挙動 —— パイプラインがWeb配信用にサイズ調整するなら、生成後ではなく生成後にスケーリングを確認する。大きく生成してから縮小する方が、逆より細部を保持できる。
• ファイルサイズと形式 —— 大きな出力は帯域を消費する。大きなバリアントがアーカイブ素材か納品素材かを早めに決める。
• トリミング後の構図 —— 確保したネガティブスペースがより大きなサイズでも残っているか検証する。再構図はあまり起きないが、一見する価値はある。

実用的なデフォルトのやり方

レシピごとに2つのバリアントを保つ：反復用の draft バリアントと、上記のより厳格な細部行と制約行を持つ final バリアントだ。草稿で低コストに反復し、それから最終版を一度実行する。開発ループは高速に保たれ、本番素材はきれいに保たれる。

一般的な開発者ユースケース向けのレシピパターン

これらは出発点であり、完成された芸術ではない。1つコピーし、角括弧のスロットを埋め、配置先に合わせて構図行を調整する。

アイコンとグリフのレシピ

SUBJECT: [概念]アイコン
DETAIL: 単一のフラット形状、角丸、2pxの均一なストローク幅、塗りつぶし
STYLE: フラットベクター、幾何学的、ミニマル
COMPOSITION: 中央配置、主体が画面の約80%を占める、完全に対称、正方形フレーミング
LIGHT & COLOR: 単一のアクセントカラー、透過に適したニュートラルな背景、グラデーションなし
CONSTRAINTS: 文字なし、影なし、3Dパースなし、32px以下で崩れる細部なし
INTENT: UIアイコンセット、1:1

ここで最も重要な行は最後の制約だ。アイコンは小さいサイズで破綻するので、スケーリングに耐えられない細部を明示的に禁止する。

プロダクトモックアップのレシピ

SUBJECT: 実際のシーンに置かれた[製品]
DETAIL: [素材]、[表面仕上げ]、[見えるべき主要特征]
STYLE: クリーンなコマーシャルフォトグラフィー
COMPOSITION: 3/4ビュー、主体は右側、左側に説明文用の柔らかな空白面を残す、中程度の被写界深度
LIGHT & COLOR: 左側からのソフトなキーライト、控えめな色調、ニュートラルな背景
CONSTRAINTS: 文字なし、ブランドロゴなし、手なし、雑多な物なし
INTENT: ランディングページのヒーロービジュアル、16:9

製品ごとに主体行を差し替えれば、系列全体が視覚的に一貫し続ける——まさに製品カタログに必要なことだ。

背景とテクスチャのレシピ

SUBJECT: [シーン]用の抽象的な背景
DETAIL: 柔らかな幾何学形態、繊細な粒子、低コントラスト
STYLE: モダン、控えめ、エディトリアル風
COMPOSITION: 全面ブリード、フォーカスポイントなし、画面全体で視覚的重みが均一、四辺に十分なセーフマージン
LIGHT & COLOR: 拡散光、[色系]の色調、硬いハイライトなし
CONSTRAINTS: 文字なし、識別可能な物体なし、顔なし、前景の内容と競合する要素は一切なし
INTENT: UIテキスト背後に置くセクション背景、ワイド比率

背景はどの製品でも最も再利用される素材であり、同時に予期せぬフォーカスで最も壊されやすい素材だ。「フォーカスポイントなし」という行が大部分の役割を担う。

1つの基本レシピから3つに分岐させる

これら3つが1つの骨格を共有していることに注目してほしい。最もよく使うレシピから始め、STYLE と CONSTRAINTS を安定させたまま、SUBJECT、COMPOSITION、INTENT を変える。これが、テスト済みのプロンプトが再設計なしに系列へと変わる方法だ。

レシピをテストし、比較し、再利用する

レシピが再利用可能になるのは、それが良いかどうかを判断できるときだけだ。以下は軽量なループで、低コストで、早期にドリフトを発見できる。

1. テストセットを凍結する

プロジェクトにとって重要な主体値を3〜5個選び、固定する。レシピを変更するたびに、同じ主体を再生成する。変化する主体間の比較は何も語らないが、固定セット間の比較はすべてを語る。

2. 一度に1つのモジュールだけ変える

出力が失望させるものなら、4行を書き直してはいけない。COMPOSITION を変え、再生成し、評価する。それから CONSTRAINTS を変える。1回の実行ごとに1変数にすることで原因を追跡可能に保つ——テスト実行前に3つの依存関係を変えないのと同じ理屈だ。

3. 好みではなく意図で採点する

出力を見る前に、INTENT 行から2〜3個の二値チェックを導き出す。例えば：確保した空白領域は本当に空か？主体は完全に画面内にあるか？文字は一切ないか？ 二値チェックは感覚に勝り、チームメイトが後でこのレシピを実行するときに唯一スケールするものでもある。

4. 勝者をテンプレートに昇格させる

レシピが継続的にチェックを通過するなら、それを昇格させる：

• 草稿プロンプトから名前付き定数または設定ファイルへ移す。
• 角括弧スロットを明示的なパラメータとして残す。
• 呼び出し側が推測しなくて済むよう、アスペクト比をレシピと一緒に記録する。
• このレシピが何に使われるかを説明する一行を加える。

この昇格ステップこそ、一度使ったプロンプトとプロジェクト全体で共有されるテンプレートの違いだ。

5. モデルやパラメータの変更後に再テストする

出力パラメータの変更——比率、解像度の意図——はすべてレシピの変更だ。凍結したテストセットを再実行する。ほとんどのリグレッションはスタイルの破損ではなく構図行の破損として現れるので、まずフレーミングを確認する。

ループは退屈で小さく保つ。5分の比較は1週間の撮り直しに勝る。

よくある失敗パターンと迅速な修正

ほとんどの悪い出力はレシピの特定の1行に対応する。症状から修正への対応を頭に入れておけば、デバッグが速くなる。

主体が小さく空間に浮いている

原因： キャンバスはワイドか縦長なのに、構図行は正方形向けに書かれている。 修正： COMPOSITION を書き直し、フレーミングを明示的に名指す——主体が縦方向の画面の大部分を占める、または主体を左側3分の1にアンカーする。比率パラメータだけに頼ってはならない。

不要な文字が現れる

原因： 宣言されていない制約、または看板（店先、スクリーン、ラベル）を招く構図。 修正： CONSTRAINTS に文字なし、アルファベットなし、看板なし、ウォーターマークなしを加え、それを招く物体を取り除く。

実行間でスタイルがドリフトする

原因： 曖昧な STYLE 行。「モダン」はスタイルではない。 修正： 媒体を名指しし、具体的な形容詞を1つ加える：フラットベクターイラスト、2pxストローク、限られた色調。 一貫したスタイル言語が一貫したスタイルを生む。

背景が煩雑でレイアウトを壊す

原因： ネガティブスペースの指示がない、または細部行がモデルに空白領域をテクスチャで埋めさせる。 修正： COMPOSITION でスペースを明示的に確保し、DETAIL でテクスチャを制限する：きれいでシンプルな背景、煩雑なテクスチャなし。

合成時にエッジがぼやける

原因： プロンプトが分離を一度も要求していない。 修正： 主体と背景のきれいな分離、エッジの色にじみなし、ハローなしを加える。これは出力サイズが大きいほど最も重要になる。

2つの主体が1つに融合する

原因： 主体行に「と」が含まれている。 修正： 1つのレシピに1つの主体。どうしてもシーンが必要なら、リストではなく、明確な主主体を持つシーンとして記述する。

画像自体は良いが、この配置に合わない

原因： INTENT が欠けているか無視されている。 修正： レシピに INTENT を保ち、配置先をプロンプト本文に書き込む。例えばワイドなヒーローバナー向けに設計、右側にタイトル用のスペースを残す。

ある修正が効いたら、それを（今入力した使い捨てプロンプトではなく）レシピに折り戻す。そうしてこそレシピは時間とともに信頼性を増し、スプリントごとに再発見されることがなくなる。