使用ガイド
gpt-image-2.5-sunburst プロンプト：開発者向けのコピー＆ペースト可能なテキスト画像生成レシピ
これらのプロンプトレシピの構造
本記事の各レシピは、すべて同じ5フィールド構造に従っています。このパターンに気づけば、ここにあるどのプロンプトも関数シグネチャを読むように理解できます。各フィールドは明確な役割を持つ名前付き入力であり、そのうち1つを差し替えれば、出力は予測可能な形で変化します。
- subject（主体）——描かれる具体的な対象。具体的かつ単一に保ちます。「ある製品」よりも「マットなセラミックボトル1本」のほうが、モデルが下すべき判断のカテゴリを丸ごと排除できるため優れています。
- style（スタイル）——レンダリングの言語：フラットベクター、柔らかな3Dレンダー、エディトリアル風線画、写真。スタイル語は積み重なるため、通常は2つで十分であり、5つになると互いに衝突し始めます。
- composition（構図）——主体の位置とそれが占める空間。中央配置で余白あり、偏心、タイル状、全面。このフィールドは他のどのフィールドよりも確実にレイアウトを制御します。
- lighting（ライティング）——方向、柔らかさ、コントラスト。「左上からの柔らかな方向性ライト」は使える指示です。「良いライティング」はそうではありません。
- constraints（制約）——ガードレール。何が現れてはならないか、何が読み取り可能なままであるべきか、どの色範囲が許されるか。制約は最も多くの人が飛ばすフィールドであり、同時にプロンプトを再利用可能にするフィールドです。
テンプレートとして書くと、次のようになります：
{subject}, {style}, {composition}, {lighting}, {constraints}
この構造の価値は見た目の美しさではありません。各フィールドが変数となり、プログラムから値を埋めたり、バージョン間で diff を取ったり、複数回の呼び出し間で回帰テストを行ったりできる点にあります。一度きりのプロンプト文字列はマジックナンバーですが、5フィールドのテンプレートはスキーマです。
自分でレシピを書くときは、フィールドの順序を安定させてください。実際には、モデルは前方のトークンをより重視するため、順序を一貫させれば、出力の変化を実際に変更した変数に起因させられ、順序が崩れたプロンプトによるものではなくなります。
コピー＆ペースト可能なレシピワークフローを構築する
このワークフローは意図的に退屈に保たれています：テンプレート、埋め込み、呼び出し、保存。退屈であることこそが、画像生成を十分に再現可能で、本番投入できるものにする理由です。
1. 文字列ではなくテンプレートを保存する
各レシピを名前付きプレースホルダー付きのテンプレートとして保存します。完成したプロンプトを呼び出しコードに直接貼り付けないでください。そうすると、後で変更したくなったときに考古学でもしない限り復元できなくなります。
template = (
"{subject}, {style}, {composition}, {lighting}, {constraints}"
)
def build_prompt(**kwargs):
return template.format(**kwargs)
2. 辞書から変数を埋める
変数の集合をデータとして扱います。これにより、同じレシピから設定ファイルやデータベースの行に基づいて画像群を生成できます。
recipe = {
"subject": "a single matte ceramic bottle with a minimalist label",
"style": "clean product photography, soft 3D render",
"composition": "centered, generous negative space on the right",
"lighting": "soft directional light from upper left, gentle falloff",
"constraints": "no text artifacts, no clutter, neutral background",
}
prompt = build_prompt(**recipe)
3. エンドポイントを呼び出す
HiAPI.ai の統一インターフェースを通じて、組み立てたプロンプトを gpt-image-2.5-sunburst/text-to-image に送信します。リクエストパラメータ（サイズ、形式、数量）を変数と同じ設定オブジェクトにまとめることで、1つのレコードが完全な生成1回分を記述できるようになります。
4. 出力だけでなく完全な入力を記録する
埋め込んだプロンプト、レシピのバージョン、パラメータセットを、返却された各画像と一緒に永続化して保存します。3週間後に出力がおかしく見えたとき、ログはプロンプトが変わったのかモデルが変わったのかを教えてくれます。
この4ステップのサイクルがシステム全体です。本記事の残りの内容は、このシステムに接続するレシピにすぎません。
レシピ1：製品風キービジュアル
これはランディングページ、ドキュメントのヘッダー、ストアのタイル向けの主力レシピです。有効なのは、構図フィールドがレイアウトを担い、制約フィールドがタイトル用の空間を確保するからです。
プロンプト
{subject}, clean product photography with soft 3D render finish,
centered subject with generous negative space on the right,
soft directional light from upper left with gentle falloff,
neutral seamless background, no text artifacts, no clutter, no harsh shadows
埋め込み後の例：
a single matte ceramic bottle with a minimalist label, clean product
photography with soft 3D render finish, centered subject with generous
negative space on the right, soft directional light from upper left with
gentle falloff, neutral seamless background, no text artifacts, no
clutter, no harsh shadows
実際の出力が示すもの
実際には、このレシピは主体をほぼ中央に配置し、右側に明確な空白の背景領域を残します。これにより、レタッチなしでそのままタイトルを重ねられます。ライティングは平板な環境光ではなく、単一の柔らかな光源のように読め、物体の受光側には明確なエッジが立ち、反対側は柔らかく影へと移行します。
制約語はここで測定可能な効果を発揮します。「no text artifacts」がないと、ラベルには文字が勝手に生えてくることがよくあります。あれば、ラベルは抽象的なまま保たれます。「no harsh shadows」がないと、減衰はスタジオのハードライトに近い形で引き締まります。どちらの変化も目に見え、どちらもページに到達する前に捕捉したい回帰の種類です。
安全に変化させる
subject は自由に置き換えてかまいません。ボトル、ヘッドホン、箱、デバイスなど、どれでも構図は保たれます。特定のレイアウト上の理由がない限り、composition と lighting は動かさないでください。これら2つのフィールドこそが、出力を再設計なしでテンプレートに直接はめ込めるようにしているからです。
レシピ2：色調の揃ったエディトリアル風イラスト
エディトリアル風レシピは、パレット変数が真価を発揮する場所です。目標は、シリーズ作品の一部に見えるイラスト——十数本の記事が同じ視覚ファミリーを保つ——を、毎回ゼロから再生成せずに作ることです。
プロンプト
{subject}, flat editorial illustration with subtle line texture,
{composition}, limited palette of {palette},
soft even lighting with no dramatic shadows,
no gradients, no photorealism, no text elements
埋め込み後の例：
an abstract diagram of connected ideas, flat editorial illustration with
subtle line texture, centered composition with breathing room around the
edge, limited palette of deep teal, warm sand, and off-white, soft even
lighting with no dramatic shadows, no gradients, no photorealism, no
text elements
パレット変数の挙動
2〜3色と中性色を1つ指定すると、安定して一貫性が保たれます。出力は指定された色相を支配的な色系として尊重し、中性色を下地として使います。これがシリーズの連続性を保つ理由です。
実際の出力では2つの失敗パターンが現れます。第一に、5色以上を指定すると虹に近い効果が生まれ、パレットが限定的に読めなくなり、イラストはエディトリアル風の抑制を失います。第二に、中性色を完全に省略すると（「深いティールと暖かい砂」だけなど）、背景が2つのアクセントカラーのどちらかで埋められがちになり、狙ったコントラストが平坦になります。
シリーズの規律
シリーズ全体で style と constraints を固定し、subject だけを変え、時折 composition を変えます。新しい記事が独自のイラストを必要とするとき、変更するフィールドは1つだけであり、得られるのは他人ではなく兄弟です。これがレシピの意義のすべてです。視覚的一貫性は、毎週繰り返すアートディレクション作業ではなく、パラメータ規律の副産物なのです。
レシピ3：UIに寄り添う背景パターン
背景テクスチャは最も地味なレシピであり、最も頻繁に本番で問題を起こすレシピでもあります。単体では問題なく見えるテクスチャが、段落の背後に置かれた途端にテキストの可読性を台無しにすることがあるからです。
プロンプト
{subject}, subtle abstract texture pattern, {scale} scale repetition,
low contrast with soft tonal variation, muted palette of {palette},
even flat lighting, no focal point, no text, no high-frequency detail,
keeps center area clear and low-contrast for text overlay
埋め込み後の例：
organic flowing line shapes, subtle abstract texture pattern, medium
scale repetition, low contrast with soft tonal variation, muted palette
of pale slate and warm grey, even flat lighting, no focal point, no
text, no high-frequency detail, keeps center area clear and low-contrast
for text overlay
制約語が重要な理由
「no focal point」は構造を支えるフレーズです。これがないと、テクスチャは画面中央の支配的な形状を中心に構成されがちです。そしてそこがまさにタイトルを置く場所です。「no high-frequency detail」は、小さな斑点が小さい文字サイズの背後で視覚的ノイズになるのを防ぎます。特に低 DPI のディスプレイでは重要です。
最後の節——中心を明瞭かつ低コントラストに保つ——は、スタイル制約ではなく構図制約です。パターンの複雑な部分を端へ押しやることで、追加のマスクレイヤーなしにテキスト用の安全領域を提供します。
変数としてのスケール
scale は安全に変更でき、テクスチャの印象を大きく変えます。小さいスケールは紙の粒子のように読め、密度の高い UI パネルに適しています。大きいスケールはエディトリアル風の見開き背景のように読め、ワイドなヘッダーに適しています。2つのスケールでそれぞれ再レンダリングし、1枚で全場面をまかなおうとするのではなく、表面ごとに選んでください。
出力を壊さずにプロンプト変数を差し替える
すべてのフィールドが同じ重要性を持つわけではありません。これらのレシピの実際の出力に基づく、実用的なリスクマップを以下に示します。
低リスクの差し替え
- subject——最も価値の高い変数で、同じカテゴリ内に留まる限り通常は安全です。ボトルをヘッドホンに変えるのは問題ありませんが、ボトルを群衆のシーンに変えるのは不可です。構図フィールドが単一の中央物体向けに書かれているからです。
- palette（限度内）——色名は自由に変えられますが、数は2〜3色と中性色1つに保ってください。
- scale——構造を壊さずに特徴を変えられます。
中リスクの差し替え
- composition——互換性のあるレイアウト間（中央、偏心、タイル状）での移動は安全ですが、変更のたびに得られるネガティブスペースの量が変わります。下流のテンプレートが特定の空白領域に依存している場合は、変更後に検証してください。
- lighting——方向の変化は明確に読め、通常は機能します。柔らかな光からハードライトへの切り替えは全体の雰囲気を変え、「クリーン」や「繊細」といったスタイル語と衝突する可能性があります。
高リスクの差し替え
- style——フラットベクターと写真の間で差し替えると、実質的に新しいレシピになります。構図と制約語は1つのレンダリング言語向けに書かれており、別の言語ではしばしば妥当でなくなります。
- constraints——制約を削除することは、以前は機能していたプロンプトが今では使えない出力を生む最も一般的な原因です。制約の編集はコード変更と同様に扱ってください。意識的に行い、結果を再確認します。
実用的なルール
新しい画像が必要なときは、一度に1つのフィールドだけを変え、以前の出力と比較してください。2つ変えてしまうと、どちらが回帰を引き起こしたか判断できません。他のあらゆるパラメータ化システムに適用するデバッグ規律がここでも同様に当てはまり、これがプロンプトライブラリを有用なまま保つか、静かに腐らせるかの分かれ目です。
生成画像を評価して納品する
画像が製品のインターフェースに入る前に、短く固定されたチェックリストで項目ごとに確認します。基準は毎回まったく同じであるべきで、そうすることで「合格」の意味が呼び出し間、レシピ間、チームメンバー間で一貫します。
4点チェック
- 制約遵守。出力は否定条項に本当に従っているか？勝手に現れた文字はないか、本来ないはずの焦点はないか、パレットは指定範囲内か。これは最初の関門です。制約の失敗は下流で最も修正が難しいからです。
- 構図の安定性。主体はレシピが約束した位置にあり、レイアウトに必要なネガティブスペースを備えているか？テンプレートが右側に明確な領域を期待しているなら、目視ではなく計測してください。
- 文脈内での可読性。テキストの背後や隣に置かれるすべてのものについて、実際のフォントサイズと実際のコピーで合成して確認します。単体では合格に見えるテクスチャやイラストが、ここで頻繁に失敗します。
- シリーズの一貫性。この画像がグループの一部なら、兄弟画像2枚の隣に並べます。同じパレットファミリー、同じ線幅、同じディテールレベル。1つの外れ値は、1枚の弱い画像よりもセット全体を壊します。
納品の規律
保持する各画像には、レシピのバージョン、埋め込んだプロンプト、パラメータセットを添付してください。後で出力がおかしく見えたとき、まったく同じ呼び出しを再実行して、入力がずれたのかモデルの挙動が変わったのかを判断できます。さらに、チャット履歴を探し回ることなく、保存したレシピからシリーズ全体を再生成できます。
コピー＆ペースト可能性が一貫した主軸です。チームの誰もが本記事からレシピを取り、変数を埋め、一言一句再調整することなく結果を再現できるべきです。こうしてプロンプトライブラリを構築すれば、画像生成は画像ごとの交渉ではなくなり、チームが呼び出す1つのサービスになります。
