GPT Image 2.5 Flare と Sunburst の違い：どっちを選ぶべきか
クリエイティブ系 SaaS や EC の画像パイプラインを EvoLink で組もうとしている方なら、この違いはすぐに具体的な問題になります。レイアウト案が1枚ボツになっても、もう一度生成すれば済みます。しかし製品ラベルが気づかないうちに書き換わっていたら、見た目がどれだけ良くても素材としては使えません。同じ画像 API を使っていても、この2つのワークフローには別々の評価基準が必要です。
テスト結果が出たら、次の順序で判断します。
- Flare を維持する：タスクの必須要件と納期制限をクリアしており、Sunburst に切り替えても、追加コストや待ち時間に見合うほど手戻りが減らない場合。
- そのワークロードだけ Sunburst にする：ペア比較で、製品ディテールの改変のような致命的な失敗を Sunburst が解消し、かつ納品予算に収まる場合。他のワークロードは既存の設定のまま維持します。
- 既存のワークフローを維持するか手作業で編集する：どちらも要件を満たさない、あるいは差があるように見えてもサンプル数が少なすぎる場合。製品を完全に保持したいなら、生成した背景の上に元の製品画像を合成する方法が必要になることもあります。
Flare と Sunburst の違いを一目で確認
max を選んでも一方がもう一方に変わるわけではありません。リクエストで指定するモデル ID は別々で、以下に示す品質オプションは共通です。Flare モデルリファレンス、Sunburst モデルリファレンス| 判断項目 | Flare | Sunburst |
|---|---|---|
| 公式モデル ID | gpt-image-2.5-flare | gpt-image-2.5-sunburst |
| OpenAI の位置づけ | 日常的な生成、素早い試行錯誤、ほとんどのアプリケーションのデフォルト | 精度が最も重要な生成・編集 |
| 評価の出発点 | 採用基準が明確で、ドラフトやバリエーションを頻繁に作る用途 | 承認済みのディテールを保持することが不可欠な編集 |
| OpenAI の品質設定 | low、medium、high、xhigh、max、auto | low、medium、high、xhigh、max、auto |
| 入力と出力 | テキストと画像を入力、画像を出力 | テキストと画像を入力、画像を出力 |
| 標準トークン単価 | Sunburst と同じ公開単価 | Flare と同じ公開単価 |
| 自分のワークロードで確かめること | 速く回せるだけでなく、採用できる結果が十分に出るか | 採用率の向上が追加の待ち時間に見合うか |
low から max までの5つの明示的な品質設定に対応し、既定値は medium です。公式表にある auto は EvoLink の品質オプションではありません。Flare のパラメータ概要と Sunburst のパラメータ概要を参照してください。「使える画像」の条件からモデルを選ぶ
まず、生成後に取り戻すのが最も難しい要件から書き出します。レイアウト案なら、情報の階層が一目で分かることかもしれません。製品写真なら、ラベルの正確な形と位置かもしれません。出力を比べる前にその要件を文章にしておかないと、見た目の魅力に引っ張られて、指示を満たしていないことを見落としがちです。
以下は、OpenAI の位置づけを一般的なワークロードに当てはめた出発点です。あくまで仮説なので、自分の素材で検証してください。
| ワークフロー | 最初に評価するモデル | 合格の条件 | 見直すタイミング |
|---|---|---|---|
| UI コンセプト、ランディングページのドラフト | Flare（Sunburst の比較セットも用意） | 正しい階層、読めるラベル、必須の参照要素、使える構図 | 別のモデルや設定のほうがレイアウト修正を一貫して減らせる場合 |
| 複数フォーマットの SNS 素材 | Flare | 正確なコピー、ブランドらしさ、必要サイズすべてで使えるトリミング | 却下が繰り返され、レイテンシやコストの利点が消える場合 |
| 製品画像の背景差し替え | Sunburst（Flare とペアで） | 製品の形状、色、ラベル、承認済みディテールが許容範囲内 | どちらかが保護対象のディテールを変えてしまう場合。納品前に必ずレビュー |
| 人物を別のシーンに配置 | 同じ参照セットで両方 | 同一性、ライティング、質感、シーンの整合性がレビューを通る | 見栄えの良いサンプルが、セット全体で同一性や質感チェックに落ちる場合 |
| 複数回にわたる局所編集 | Sunburst（Flare とペアで） | 前の編集が残り、触っていない領域も許容範囲内 | ずれが積み重なり、以前の承認済み画像に戻す必要が出る場合 |
| ポスター、透過ブランド素材 | 出力設定を明示して両方 | 正確なテキスト、使えるエッジ、正しい構図、必要な透過 | 品質設定を上げても、その納品要件を満たせない場合 |
2つのタスク例：入力からモデル決定まで
以下の例は、Flare の「日常的な生成」、Sunburst の「編集重視」という位置づけを、それぞれ異なる採用テストに落とし込む方法を示すものです。どちらのモデルの合格率も予測していません。
タスク1：デザイナーに引き渡せる UI ドラフト
自分の参照素材と一緒に、次のタスクプロンプトをそのまま使えます（英語のまま利用可）。
Create a desktop dashboard concept using the attached wireframe.
Preserve its four regions: navigation, upload, job queue, usage summary.
Use these labels exactly: "Upload images", "Queue", "Usage", "Settings".
Keep the supplied logo unchanged. Use a neutral background and teal accents.
Do not add features, pricing cards, or navigation items.
The deliverable is a visual design reference, not working interface code.ビジュアルのスタイルより先に、必須要素をレビューします。
| チェック項目 | 合格 | 不合格 / 次のアクション |
|---|---|---|
| 情報設計 | 4つの領域と必須コントロールがすべて存在する | アップロードやキューが欠落：不合格。参照素材とプロンプトの整合性を確認 |
| コピーとブランディング | 必須ラベルが正確で、ロゴが使える状態 | ラベルやロゴが変更：不合格。正確なテキストやロゴはデザインツール側で配置することを検討 |
| 引き渡しでの有用性 | 画面を再設計せずに階層と余白を実装できる | 見栄えは良いが構造が分かりにくい：レイアウト失敗として記録 |
これはドラフトを繰り返し作る仕事なので、Flare から始めます。Flare の出力がこれらの基準を満たし、Sunburst の違いが主に見た目の雰囲気だけなら、納品コストやレイテンシの実測値が良いほうの Flare を維持します。逆に、Flare が必須領域を繰り返し落とし、Sunburst が比較セット全体でそれを保持するなら、この種の指示では Sunburst を検討します。Sunburst の見栄えの良い画像が1枚あるだけでは、その傾向を裏づけたことにはなりません。
両方とも正確なタイポグラフィに失敗するなら、品質設定を上げ続けるのではなく、構図の生成とテキスト配置を分離してください。その要件はデザインツールのほうが向いているかもしれません。完成した引き渡し物を比較する際は、この仕上げの時間も含めてください。
タスク2：製品を変えずに背景だけ差し替える
Replace the background of the attached product photograph with a light
stone surface and a warm off-white wall. Match the reference background's
lighting. Add a natural contact shadow beneath the bottle.
Preserve the bottle shape, cap, label lettering, logo, and liquid color.
Do not add props, alter the camera angle, crop the bottle, or redesign it.ここでは編集精度が中心的な要件なので、Sunburst が最初の候補です。ただし Flare も比較に含めてください。「編集重視」という位置づけだけでは、単純な背景差し替えのすべてに Sunburst が必要だとは言えません。
次に、短い編集シーケンスをテストします：壁の色を暖かくする、影を柔らかくする、背景の気になる汚れを消す。このタスクでは各ブランチで3回の編集を行い、中間画像をすべて保存します。編集のたびに保護対象のディテールをすべて確認し、前回依頼した変更が残っているかも併せて見ます。最終納品物がチェックリストを全項目クリアした場合のみ、そのシーケンスを採用とカウントします。
採用画像1枚あたりのコストで比較する
usage を計測するよう案内しており、消費量はモデルと設定に依存します。OpenAI の出力見積もりツールは出力コストを対象としており、完全なリクエストには入力分も含まれます。Responses API のワークフローでは、さらにメインモデルの使用量も発生します。OpenAI のコストとレイテンシに関するガイダンス比較にあたっては、次のように定義します。
Cost per accepted image =
total actual generation and retry charges for the evaluation batch
/ number of images that pass the acceptance rules編集セッションでは、中間画像ではなく採用された最終納品物を数えます。すべてのステップとリトライの料金を含めてください。採用された納品物がゼロのバッチは失敗として報告し、その単価は「未定義」であって「ゼロ」ではありません。レビューと修正の人件費は別に記録し、総納品コストを比較するときに加算します。
計算例：バッチ全体の請求額が高くても割に合うケース
| 仮のバッチ | ジョブ数 | 合計料金 | 採用された最終画像 | 採用画像1枚あたりのコスト |
|---|---|---|---|---|
| Flare の例 | 20 | $4.00 | 10 | $0.40 |
| Sunburst の例 | 20 | $6.00 | 18 | 約 $0.33 |
この仮のバッチでは、Sunburst の請求額は50%高いものの、採用画像1枚あたりのコストは約17%低くなります。ただし、レイテンシやその他の納品要件も満たしている場合に限って、Sunburst のほうが望ましい設定になります。
損益分岐点を押さえておくと便利です。バッチ料金が $6 の場合、Sunburst が Flare の $0.40 に並ぶには採用画像が15枚必要で、上回るには16枚以上が必要です。逆に、Flare の別の設定が同じ $4 で16枚を採用できるなら、Flare は1枚あたり $0.25 となり、結論は逆転します。設定を変えれば請求額も変わりうるので、料金が固定だと仮定せず、両方の入力値を計算し直してください。
トークン単価が共通でも判断が決まらないのはこのためです。採用数という分母と、請求額全体を一緒に比較してください。タイムアウトや失敗したリクエストは、プロバイダーの課金ルールに照らして突き合わせます。失敗が無料だとも、二重課金されるとも決めつけないでください。
品質設定は別途比較が必要
auto は変動要因を1つ増やしますし、モデルが違えば同じ品質ラベルでも、計算量、視覚品質、総コストが等しいとは限りません。公式ガイドにはモデルごとのトークン見積もりが記載されており、消費量の確認には実際の usage を使うよう推奨されています。画像生成ガイドまず同じ明示設定どうしで比較し、次に、観察された失敗に対してだけ別の品質設定を試します。たとえば UI の設定で必須領域が欠落するなら、プロンプトの変更、品質の引き上げ、Sunburst への切り替えのどれがその欠落を解消するかを比較します。変数は一度に1つだけ変えてください。選んだ設定は固定し、採用前に新しい指示でテストします。同じサンプルで選定と検証を行うと、改善を過大評価しがちです。
max に送るルールは避けてください。ラベルのスペルミス、不完全な指示、不適切な参照画像、誤ったトリミングには、それぞれ原因の切り分けが必要です。品質設定の引き上げは対処法の候補の1つであって、失敗を理解する代わりにはなりません。テストを実行して判断ワークシートを埋める
設定記録として、正確なモデルまたはスナップショット、プロバイダー、プロンプトのバージョン、参照素材、品質、サイズ、出力設定、リトライポリシーを保存します。編集シーケンスでは、各親出力と依頼した変更も保存します。混雑した時間帯が一方のモデルだけに偏って影響しないよう、同程度の負荷の下でリクエストの順番を交互に入れ替えてください。移行の判断であれば、現行のワークフローもベースラインとして含めます。
好みより先に「納品できるか」を採点する
まず前述のタスク別の必須チェックを適用します。次に、構図、ライティングと視覚的整合性、仕上げの3つのソフト基準を0〜2で採点します：0 は大幅な手直しが必要、1 は軽微な修正が必要、2 は想定する引き渡しにそのまま使える状態。この例のルーブリックでは、必須チェックをすべて通過し、かつ合計5/6以上の出力だけを採用します。実際のしきい値は、モデル名を見る前に決めてください。
つまり、ラベルが変わってしまった製品画像は 6/6 でも不合格です。必須要素がすべてあり 2/2/1 の UI コンセプトは、この例のルーブリックでは合格です。残る修正時間は無料扱いにせず記録します。
run_log_reference で紐づけます。completed、failed、unfinished を、採用と納期の欄には yes/no を入力します。リクエストが完了しても、画像が採用できないことはあります。採用された出力がない場合、採用までの時間は空欄にします。課金は突き合わせが済むまで pending とし、保留中のジョブを省いたり無料扱いにしたりせず、バッチ全体の料金が確定してからコストを比較してください。ワークロードごとに個別に集計します。
| 判断項目 | Flare | Sunburst |
|---|---|---|
| 設定 ID とサンプル数 | 記入 | 記入 |
| 採用された最終納品物 / 実行ジョブ数 | 記入 | 記入 |
| 必須チェックの失敗（理由別） | 記入 | 記入 |
| 突き合わせ済みのバッチ料金 / 採用納品物数 | 記入 | 記入 |
| 採用納品物までの時間、未完了ジョブ | 記入 | 記入 |
| レビューと修正にかかった分数 | 記入 | 記入 |
| このワークロードの納品制限を満たすか | はい / いいえ / 証拠不十分 | はい / いいえ / 証拠不十分 |
時間を報告する際は、未完了ジョブを隠さないでください。失敗の多いモデルが、簡単に成功したものだけを計測して速く見えてはいけません。この小規模スクリーニングでは、観測した所要時間と納期超過を示すにとどめ、信頼できる p95 や幅広い性能の主張は出さないでください。
ワークシートを判断に変える
Flare が12件、Sunburst が18件で、記録した差が製品ラベルの保持の繰り返しなら、Sunburst を新しい製品編集の検証セットに進めます。追加の待ち時間が納期に違反するなら、納品判断としては依然として不合格です。どちらも16件に届かなければ、既存のワークフローを維持するか、タスクを見直すか、手作業で対応します。これらの数字は判断ルールを示すためのもので、観測結果でも汎用的な採用目標でもありません。
結果をルーティングポリシーに落とし込む
固定した設定が新しい検証を通過したら、そのワークロードの一部に限定して導入します。Flare と Sunburst の判断はタスクごとに分けてください。製品編集での改善は、UI ドラフトを移す理由にはなりません。コスト、却下率、納品時間が上限を超えたときに戻せるよう、以前の動作する設定と承認済み素材は保持しておきます。
初期ポリシーでは、次の4つの結果を区別できます。
| 結果 | 提案するアクション |
|---|---|
| 出力がタスクの採用基準を満たす | 納品する。性能を振り返れるよう、設定と課金の証拠を十分に残す |
| 出力は完了したが、特定の視覚要件を満たさない | 失敗を記録し、リトライ予算内でテスト済みの代替設定を試すか、レビューに回す |
| 通信、レート制限、プロバイダーの可用性が原因でリクエストが失敗 | 文書化されたリトライ／ステータスの挙動に従い、適切なら検証済みのフォールバックを使う |
| 予算切れ、要件の矛盾、レビューでの繰り返し不合格 | 生成を止め、タスクを確認や手作業のために差し戻す |
技術的な失敗と品質の失敗は分けて扱います。モデルを切り替えれば同一性保持の結果は改善するかもしれませんが、モデルを何度変えても不正なリクエストは直りません。タイムアウト後は、チャネルが対応していればリクエストの状態を突き合わせてから、次の課金対象になりうるジョブを送ってください。
最後に承認した素材と動作する設定を保持します。新しいモデルが編集シーケンスの途中でずれたら、すでに採用できない結果を編集し続けるのではなく、承認済みのチェックポイントから復旧してください。導入後は、API レスポンスの成功総数だけを見るのではなく、ワークロードごとにレイテンシと採用率をレビューします。
EvoLink での適用方法
統合ゲートウェイを使うチームは、ワークロードのポリシーと、プロバイダー固有のリクエスト詳細を分けて管理してください。アプリケーション側は「なぜこのジョブにこの設定が必要か」を把握し、検証済みの連携が、受理されるモデル ID、パラメータ、課金の挙動を提供します。
本番トラフィックを EvoLink に切り替える前に、Flare と Sunburst を個別にテストしてください：受理されるパラメータ、生成と編集の結果を1つずつ、突き合わせ済みの課金をそれぞれ確認します。片方のバリアントで統合テストに合格しても、もう片方のテストの代わりにはなりません。どちらのバリアントもすでに EvoLink で利用できます。上記のポリシーはアプリケーション設計の話であり、EvoLink がこの2モデル間の自動フェイルオーバーを提供しているという主張ではありません。
よくある質問
Flare と Sunburst、最初に試すならどっちですか？
日常的な生成やバリエーションを頻繁に作る用途なら、最初の評価候補は Flare です。編集精度と承認済みディテールの保持が主な課題なら、Sunburst を優先してください。この出発点は OpenAI の位置づけに沿ったもので、最終的な選択は自分の採用基準に結びつけてください。
Sunburst は常に Flare より優れていますか？
本ガイドではそうとは言えません。ワークロードに必要なのは、レイテンシとコストの予算内で採用できる結果です。より重いモデル設定が有用なのは、その改善がそのタスクにとって意味がある場合だけです。デフォルトを決める前に、難しいケースで両方を評価してください。
Flare のほうが安いですか？
公式の標準トークン単価は同じです。実際の入力・出力の使用量、リトライ、採用された画像数を比較してください。特定のタスクでは Flare のほうが経済的かもしれませんが、モデル名や共通の料金表だけではその結論は出せません。
最終画像はすべて max 品質にすべきですか？
納品要件を満たす、テスト済みで最も低コストの設定を選んでください。低い設定が失敗したときに高い設定を評価に含め、それが実際の失敗を解消するかを確認します。レビュー時間とリトライもコスト比較に含めてください。
Sunburst なら編集しても製品ディテールが変わらないと保証されますか？
本記事で使った情報源からは、そのような保証は確認できません。保護対象のディテールは明示的な採用基準として扱ってください。編集シーケンス全体をテストし、復旧や手動合成のために承認済みの元画像を保持しておきます。
ドラフトは Flare、最終編集は Sunburst という使い分けはできますか？
評価する価値のある妥当なワークフローです。切り替え自体もテストしてください。2つ目のモデルが正しい参照素材を受け取り、承認済みの選択を保持する必要があります。2段階の総コストと完了時間を、1つのモデルでタスクを実行した場合と比較してください。
ChatGPT がどちらのモデルを使ったか、画像から分かりますか？
見た目だけでは判断できませんし、本記事は個々の ChatGPT や Codex のリクエストを検証していません。再現可能なテストのためには、画像モデルを明示的に選択して記録してください。両方の公式モデルページに、Images API と Responses の画像ツールでのモデル選択方法が記載されています。設定、試行回数、料金が添えられていないコミュニティのスクリーンショットでは、API でのペア比較の結果とは言えません。
EvoLink で両方のモデルを使えますか？
gpt-image-2.5 というエイリアスはないので、リクエストでバリアントを明示してください。情報源と更新方針
- Introducing ChatGPT Images 2.5 — 公式の位置づけとリリースの背景。2026年9月9日確認。
- GPT-Image-2.5 Flare モデルリファレンス — モデル ID、モダリティ、品質オプション、標準単価。2026年9月9日確認。
- GPT-Image-2.5 Sunburst モデルリファレンス — モデル ID、モダリティ、品質オプション、標準単価。2026年9月9日確認。
- OpenAI 画像生成ガイド — モデル選択と usage／コストのガイダンス。2026年9月9日確認。
- 12ui の作者が公開した UI 生成の比較 — 製品との利害関係を開示したコミュニティのデモ。独立して検証された性能情報源ではありません。
モデルの挙動、公式の設定、検証済みルートの提供状況、同等ワークロードでの結果が変わったときは、推奨内容を見直します。計測結果を追加する際は、正確な設定とテスト日を記録し、ベンダーの主張、第三者の報告、EvoLink 自身の結果を区別して保持してください。
