GPT Image 2.6 実践：ピクセルアニメーション GIF、SVG ベクターロゴ、mask_url による部分修正

まずはライン選択：Flare か Sunburst か

同じパラメータで、2つのラインがあります。GPT Image 2.6 には4つのモデル ID があります：gpt-image-2.6-flare/text-to-image、gpt-image-2.6-flare/image-to-image、gpt-image-2.6-sunburst/text-to-image、gpt-image-2.6-sunburst/image-to-image。

選定の基準は1つだけ：今回のラウンドで求めるのは速度か、それともディテールの一貫性か。

• Flare：画像生成がより高速で、素早いイテレーションやバッチ生成に適しています。デフォルトではこれを選びます。

• Sunburst：ディテールをより重視。medium 以上の品質で複数ラウンドの編集を行う場合、キャラクター、製品、レイアウトの一貫性がより良好です。

両ラインのパラメータ、使い方、価格は完全に同一です。つまり、以下の3つのシナリオの各行の設定は、ラインを切り替えても1文字も変更する必要がありません。まず Flare でパラメータを調整して動作確認し、その後 Sunburst に切り替えて最終稿を生成できます。

モデルページ：

• gpt-image-2.6-flare/text-to-image

• gpt-image-2.6-flare/image-to-image

• gpt-image-2.6-sunburst/text-to-image

• gpt-image-2.6-sunburst/image-to-image

シナリオ1：ピクセル風の小さなアニメーションを GIF で出力する

GIF はテキストからの画像生成でのみ利用可能で、output_format に gif を指定します。3つの専用パラメータが完成品を決定します：frame_size、frame_count、frame_duration_ms。

そのまま真似できる設定

{
  "model": "gpt-image-2.6-flare/text-to-image",
  "prompt": "pixel art loop, a small slime bouncing on grass tiles, 16-bit palette, plain light background",
  "quality": "high",
  "resolution": "1K",
  "output_format": "gif",
  "frame_size": "512x512",
  "frame_count": 8,
  "frame_duration_ms": 120
}

以下は GPT Image 2.6 Flare が実際に生成した GIF です：512×512、12フレーム、各フレーム 120ms。

各パラメータの理解

• frame_size：各フレームのピクセル幅×高さ。512x512 の形式で、両辺は16の倍数である必要があり、デフォルトは 512x512。これは GIF の比率を決定するもので、resolution ではありません。1:1 のような記法に変更しようとすると直接拒否されます——ここで必要なのはピクセル値であり、比率文字列ではありません。

• frame_count：2–16、デフォルトは9。ピクセル風の小さなアニメーションは6–10フレームに抑えると通常ループに十分です。フレーム数が多いほど、モデルが1つのキャンバスに配置する内容が増えます。

• frame_duration_ms：各フレームの長さ、≥20、デフォルトは200、10ms 単位で丸められます。ピクセルアニメーションでは100–150ms が一般的で、「フレームごとの感覚」を追求するなら80–120ms まで下げます。

フレーム取得の考え方

モデルは frame_count フレームを1枚の大きな画像に結合して一度に生成し、その後 frame_size で分割します。そのため、プロンプトには「1枚の画像」ではなく「一連の連続したアクションシーケンス」を書く必要があります。開始と終了のつながり方、被写体の画面内での位置が固定かどうかを明記することで、ループに跳びが生じません。ピクセル風の場合はさらにパレットと輪郭スタイルを限定する一文を加えると、フレーム間の一貫性がより安定します。

お忘れなく

GIF 生成時は aspect_ratio を指定しないか auto を指定します。比率は frame_size で決まるため、ここに別の値を入れると競合を生むだけです。

GIF の境界：どのような場合に直接拒否されるか

GIF の制限は通常の画像生成より多く、すべて送信段階に集中しています——超過しても「無理に生成」されることはなく、直接拒否され、全額返金、課金なしです。ですから安心して試せますが、なぜ拒否されたかを理解しておく必要があります。

4つの厳格な制限

• フレーム数：2–16。ただし 768x768 は最大12フレーム。

• 結合画像の各辺：≤3840。

• 結合画像の総ピクセル数：≤8,294,400。おおよそ frame_size の幅 × 高さ × frame_count に相当。

• 結合画像のアスペクト比：≤3:1。

3番目と4番目は最も見落とされやすい項目です。これらは単一のパラメータではなく、結合後の結果に依存するためです。考え方としては、まず 幅 × 高さ × フレーム数 を計算し、次に結合画像のアスペクト比が3:1を超えていないか確認します。

2つの典型的な落とし穴

• 512x512 で16フレームは問題ありませんが、同じ16フレームでも 768x768 にすると拒否されます。768x768 は最大12フレームです。

• ワイドなバナーアニメーションを望み、frame_size を非常に扁平な比率に設定し、さらにフレーム数を増やすと、結合画像のアスペクト比が3:1を超えます。

送信前のセルフチェック

• frame_size の両辺は16の倍数か？

• 1:1 のような比率記法を誤って指定していないか？

• aspect_ratio は空欄または auto か？

• frame_duration_ms は ≥20 か？（自動的に10ms 単位で丸められます）

これらすべてをクリアすれば、GIF が送信段階で止まることはありません。

シナリオ2：モデルに真の SVG ベクターロゴを出力させる

svg もテキストからの画像生成でのみ利用可能で、output_format に svg を指定します。出力はスケーラブルなベクターで、任意のサイズに拡大してもぼやけません——これはロゴ、アイコン、モノクロマークに最も必要な性質です。

そのまま真似できる設定

{
  "model": "gpt-image-2.6-flare/text-to-image",
  "prompt": "minimal geometric fox head logo, flat vector, two colors, thick even strokes, centered, plain white background, no text",
  "quality": "high",
  "resolution": "1K",
  "background": "opaque",
  "output_format": "svg"
}

以下は GPT Image 2.6 Flare が low 設定で生成した SVG ロゴです。ファイルはわずか3 KBで、任意のサイズに拡大しても鮮明です：

ロゴを記述する書き方

ベクターロゴに必要なのは「ベクター化可能」な形態であり、プロンプトはその方向に寄せます：

• flat vector、thick even strokes を明記し、グラデーション、ノイズ、グロー、写実的な質感を避ける。

• 色数を限定する。「two colors」の方が「colorful」よりクリーンな結果を得やすい。

• centered、余白の要件を書き、端に寄せない。

• 純粋なマークが必要な場合は no text を加え、モデルに文字を入れさせない。

complexity は計画階層を制御し、quality とは独立で、デフォルトは high。ロゴのような構造がシンプルな対象では、quality は medium または high から始めれば十分です。予算は一度で最大に引き上げるよりも、繰り返し再生成に使う方が割に合います。

価格差

SVG の価格は同档位 PNG の価格に 0.030 を加算したものです。例えば low、1K 档は 0.053、max、4K 档は 0.666。ですからまず medium + 1K で構図を固め、確認後に high + 2K（または 4K）で最終稿を出力します。

注意：background: transparent には png または webp が必要で、SVG と透明背景の組み合わせはサポート範囲外です。opaque の方が安定します。

シナリオ3：mask_url による部分修正

画像からの画像生成は1–16枚のソース画像（jpeg/png/webp）をサポートし、出力は png、jpeg、webp のみです。部分修正には2つの方法があります：mask_url と markup_url で、どちらか一方のみ選択できます。

ルート A：mask_url で修正箇所を正確に指定

mask_url は最初のソース画像と同じサイズの RGBA PNG です。透明ピクセルが変更する領域を表し、不透明ピクセルが保持する領域を表します。

{
  "model": "gpt-image-2.6-flare/image-to-image",
  "prompt": "replace the background with a soft studio gradient, keep the product untouched",
  "image_urls": ["https://example.com/product.png"],
  "mask_url": "https://example.com/product-mask.png",
  "quality": "high",
  "resolution": "2K",
  "output_format": "png"
}

マスク作成の3つのポイント：

• サイズは最初のソース画像と完全に一致する必要があり、1ピクセルでも違うと合いません。

• アルファチャンネル付きの PNG である必要があり、透明で「変更する」ことを表します。

• マスクの境界は少し外側に広げると、新旧コンテンツの継ぎ目が不自然になるのを避けられます。

ルート B：markup_url で囲むだけ

markup_url は透明な PNG 注釈画像で、その上で変更する位置を囲むだけで済みます。注釈は結果に現れません。これは「どこがおかしいかはわかるが、正確なマスクを作るのが面倒」なシナリオに適しています——例えば画面内の特定の人物を囲み、「このコートに替えて」と指示するような場合です。

必ず知っておくべきこと

マスクを使用しても、マスク外の領域もわずかに変化する可能性があります。完全に保持したい要素（ロゴ、文字、人物の顔）については、マスクを保険として期待せず、「変更しない」ことをプロンプトに書き込み、生成後に1枚ずつ比較してください。複数ラウンドの編集では、Sunburst が medium 以上の品質でディテールの一貫性がより良好であり、これが画像編集シナリオで切り替える価値がある理由です。

どちらを選ぶか

• 変更する形状の境界が明確で、正確さが必須 → mask_url。

• 位置を示すだけで、領域が不規則で、手間を省きたい → markup_url。

• 両方を指定 → 直接拒否され、1回の送信を無駄にするだけ。

3つのシナリオをまとめて計算：档位別価格とよくある誤解

価格はすべて枚単位で計算されます。完全な档位別表は価格ページを参照し、ここでは間違えやすい3つのルールを説明します。

ルール1：GIF は品質のみで課金され、解像度とは無関係

GIF は 1K を指定したか 4K を指定したかを見ず、quality のみを見ます。low、medium、high、xhigh、max がそれぞれ固定価格に対応し、0.070 から 0.598 までです。ですから GIF に resolution: "4K" を加えても、高くもならず、鮮明にもなりません——鮮明さは frame_size で決まります。

ルール2：SVG は同档位 PNG に 0.030 を加算

ベクター出力は固定の追加料金で、同档位 PNG の価格に上乗せされます。例えば medium 1K の SVG は $0.071、high 2K は $0.120。コストを抑えたい場合は、低い档位で複数バージョンを試し、選定後に档位を上げて最終稿を出力します。

ルール3：画像からの画像生成は参照画像1枚につき 0.012 を加算

基本価格はテキストからの画像生成と同じで、その後参照画像の枚数に応じて加算され、1枚につき 0.012。high 2K を例にすると、2枚指定で $0.114、16枚指定で $0.282。本当に必要な参照画像のみを指定してください。

送信拒否は課金されない

パラメータが不正、GIF サイズ超過などは、すべて送信段階でブロックされ、全額返金、課金なしです。ですから無駄を恐れてパラメータ調整を躊躇しないでください。本当のコストは「動作したが結果に満足できない」再生成から生じます。

3つのよくある誤解

• GIF は解像度が高いほど良いと思っている：resolution は GIF には無意味で、frame_size がピクセルの源泉です。

• マスクを使えばピクセル単位で固定されると思っている：マスク外もわずかに変化する可能性があります。

• 2つのラインには2つの設定が必要だと思っている：Flare と Sunburst はパラメータ、価格が完全に同一で、ラインの切り替えは「移行」ではなく、モデル ID を変えるだけです。

リリース前チェックリスト

送信前に以下の順序で確認すると、ほとんどの拒否と手戻りを防げます。

1. まず output_format を決定

• gif / svg → テキストからの画像生成のみ。画像からの画像生成をする？ png / jpeg / webp に戻る。

• jpeg / webp → output_compression（0–100）が使用可能。

• background: transparent → png または webp でなければならない。

2. シナリオ別にパラメータを検証

GIF

• frame_size の両辺は16の倍数で、1:1 と書いていない。

• frame_count は 2–16、768x768 の場合は ≤12。

• 幅 × 高さ × フレーム数 ≤ 8,294,400、結合画像のアスペクト比 ≤3:1。

• frame_duration_ms ≥20（自動的に10ms 単位で丸められます）。

• aspect_ratio は空欄または auto。

SVG

• プロンプトにグラデーション、ノイズ、写実的質感など反ベクター的な記述がないか。

• background は opaque か（透明と svg の競合を避ける）。

mask_url / markup_url

• どちらか一方のみを指定している。

• mask_url は最初のソース画像とサイズが一致し、RGBA PNG である。

• プロンプトにどの領域を「変更しない」かが明記されている。

3. ラインと档位を再確認

• バッチ試行錯誤は Flare、複数ラウンド編集は Sunburst（medium 以上）。

• quality、resolution、complexity の3つは独立しており、complexity を画質档位と混同しない。

4. 送信

すべて通過してから送信します。拒否は課金されませんが、再試行のたびに時間を消費します——チェックリストの価値は往復を減らすことであり、節約ではありません。

3つのシナリオの設定はすべてそのまま真似できます。まず動作させてから調整するのが、GPT Image 2.6 を習得する最速の道です。