61秒 vs 154秒：flareとsunburst、最上位品質の所要時間差

Azure OpenAI の画像生成が新世代の gpt-image-2.5 になり、速度優先の flare と品質優先の sunburst の2本立てになりました。どちらを既定にすべきか迷ったので、両モデルで品質5段を回して測りました。

先に、誰に向くかをはっきりさせます。

• flare が向く人: 生成結果を見ながら何度も試したい人、チャットや管理画面で待ち時間を短くしたい人、日常的に大量生成する人
• sunburst が向く人: 生成回数よりも1枚の仕上がりを優先したい人、人物の顔を保った編集など精度を重視する人
• sunburst が過剰になりやすい人: 下書き、アイデア出し、サムネイルの候補作りが中心の人。今回の条件では、最上位品質になると154秒かかりました

結論は3つです。

• 費用はモデル選択では動きません。 公式の単価が flare と sunburst で同一だからです。これは実測して驚いた話ではなく、料金表を読めば分かる仕様です
• だから決め手は時間になります。 品質を上げるほど差が開き、最上位では 2.5倍（61秒 対 154秒）になりました
• ゲートウェイ経由で使っているなら、課金集計を一度確認してください。 モデル名の付け方ひとつで、費用が永久にゼロ円と記録され続けます。エラーは一切出ません

日常用途は flare の下位2段を既定にする、というのが今回の運用結論です。品質を優先したい1枚だけ sunburst に切り替える構成にしました。

先に費用の話を片付けます。

画像生成の課金は「画像出力トークン数 × 単価」で決まります。そして公式の単価は、flare も sunburst も、さらに前世代の gpt-image-2 まで含めて完全に同一です。

画像出力トークン数のほうも、画像サイズと品質で決まる公表値です。つまり同じサイズ・同じ品質なら、どちらのモデルを選んでも請求は同じになります。仕様上そうなるように出来ています。

実測でも確認しました。同じ品質の階段を各1回ずつ両モデルで回し、その日の課金集計を引くと、両方とも $0.37646 でぴったり一致しました。

ただし、この金額の出どころは正直に書いておきます。これは Azure の請求書を読んだ値ではなく、ゲートウェイが内蔵の料金表を引いて計算した値です。単価そのものは公式と一致していますが、請求書と突き合わせた検証まではしていません。

したがって、この記事の費用比較から判断できるのは「flare と sunburst のどちらが安いか」ではなく、同じ料金なら待ち時間と品質のどちらを優先するかです。Azure の請求額を予算管理に使う場合は、ゲートウェイ集計だけで確定せず、請求書側でも確認してください。

費用が同じなら、残るのは時間です。ここには明確な差がありました。

同じ画像サイズ・同じプロンプトで、品質だけを5段変えて測った所要時間です。なお品質の指定値には、モデルに判断を任せる auto もあります。今回は待ち時間を比べるのが目的なので、値が固定される5段だけを測りました。

今回の実測条件では、flare最上位は61秒、sunburst最上位は154秒でした。

費用は同じでも時間は同じではない。品質を上げるほど2モデルの差は開く

差は品質を上げるほど開きます。最下位では1.2倍程度ですが、最上位では 2.5倍になります。

面白いのは、flare の最上位（61秒）が sunburst の3段目（55秒）とほぼ同じ時間だということです。同じ待ち時間を使うなら、flareを最上位にするか、sunburstを3段目にするかという判断になります。

前世代との比較も測りました。同じ画像サイズ・同じ3段目の品質で、旧 gpt-image-2 は 122秒かかりました。flare は同条件で23秒です。5.3倍の差があります。

さらに言えば、flare の最上位設定（61秒）でも旧モデルの3段目（122秒）の半分で終わります。移行するだけで体感が明確に変わりました。

⚠️ flare と sunburst の戻し方

モデルの既定値を変更する場合は、いきなり全トラフィックを切り替えず、まず1つのキーや用途だけで試します。

• 待ち時間が許容できない場合: 既定モデルを flare に戻す
• 仕上がりを優先したい場合: sunburst は既定にせず、必要なリクエストだけ明示的に指定する
• 変更後に権限エラーが出た場合: 後述の許可モデル一覧を、変更前の一覧へ戻す

今回の運用では、flareの品質2段目を通常設定、sunburstを個別指定に戻せる状態にしています。これなら品質を試した後でも、全体設定を戻す必要がありません。

実際に生成した画像です。同じプロンプト・同じ画像サイズで、品質設定だけを変えています。

flare・最下位品質。17秒、約0.006ドル

flare・最上位品質。61秒、約0.21ドル

モデル選択では費用は動きませんが、品質パラメータでは大きく動きます。1枚あたりの実費です。

最下位と最上位で 約35倍の開きがあります。日本円にすると1枚あたり1円弱と30円強くらいの差です。

大量に生成する用途なら、この差は無視できません。逆に言えば、下位2段で足りる場面が多いなら費用はほとんどかかりません。

自分の結論としては、日常的な生成は2段目まで、上位2段は「ここぞという1枚」のための設定、という使い分けにしました。上位設定を常用する理由は見つかりませんでした。

なお、3段目と4段目については個別の金額を分離できませんでした。理由は後述の課金記録の癖です。2つ合わせて約0.15ドルでした。

同じ条件を sunburst でも回した結果です。費用は flare と同額で、変わるのは時間だけです。

sunburst・最下位品質。21秒、費用は flare と同額

sunburst・最上位品質。154秒、flare の2.5倍の時間

今回の検証では、最初に考えた構成をそのまま採用しませんでした。

まず、1枚ごとの単価を「生成前の累計額」と「生成後の累計額」の差分で出す方法はやめました。課金記録が非同期で反映されるため、ゼロ円の行と、2枚分が合算された行が発生したからです。単価の比較には日次集計を使うほうが安全でした。

また、デプロイ名に独自の接頭辞を付ける運用もやめました。ゲートウェイの料金表と名前が一致せず、生成自体は成功するのに課金集計だけがゼロになったためです。

課金のためだけにデプロイ名を変えるのが難しい場合は、少なくとも次の2つを別々に確認します。

1. Azure 側のデプロイ名
2. ゲートウェイが料金計算のキーとして参照するモデル名

この2つを「同じ意味の名前だから大丈夫」と扱わず、実際の集計結果で確認するのがポイントです。

ここからは、同じ構成で運用している人が踏みそうな罠を3つ書きます。実害の大きさではこれが一番です。

移行作業の途中で、画像生成の費用がずっとゼロ円で記録されていたことに気づきました。実際には課金されているのに、手元の集計では無料に見えていたのです。

原因はモデルの参照名でした。ゲートウェイは内部に料金表を持っていて、モデル名をキーにして単価を引きます。ところが自分の環境では、デプロイに独自の接頭辞を付けた名前を使っていました。その名前は料金表のどのキーとも一致しません。一致しなければ単価が引けず、結果としてゼロ円が記録され続けます。

厄介なのは、エラーが一切出ないことです。画像は正常に生成され、保存され、何も警告されません。集計を見ても「無料で使えている」としか読めない。請求書と突き合わせて初めて気づく類の問題です。

最初は「設定ファイルに単価を直接書けばいい」と考えました。料金表への名前の一致を期待せず、明示的に指定する。理屈としては通りそうです。

これは効きませんでした。 単価を書いてゲートウェイを再起動しても、集計はゼロのままでした。

調べると、画像生成の課金計算はモデルごとの設定を見ておらず、内部の料金表をモデル名で引く実装になっていました。つまり名前が一致しない限り、設定に何を書いても無視されます。

一方、新世代のモデルは何もしなくても正しく記録されました。違いは名前だけです。新しい方はデプロイを作ったときの既定名をそのまま使っており、それがたまたま料金表のキーと一致していました。

教訓は「デプロイ名にオリジナルの接頭辞を付けない」です。 ベンダーのモデル名をそのまま使う。管理しやすいように独自の命名規則を作りたくなりますが、それが課金計算を静かに壊します。

旧モデル側は、この記事を書いている時点でまだゼロ計上のままです。直すにはデプロイを作り直す必要があり、移行が済めば消す予定なのでそのままにしました。

⚠️ LiteLLM の課金集計がゼロの場合の戻し方

ゼロ円表示だけを見て「無料で使えている」と判断しないでください。次の順番で切り分けます。

1. 画像生成が成功しているか確認する
2. ゲートウェイの集計で、モデル名が料金表のキーと一致しているか確認する
3. 独自接頭辞付きのデプロイ名を使っている場合は、既定のモデル名を使う構成へ戻す
4. 既存のデプロイを残す必要がある場合は、別名で再作成して1枚生成し、集計がゼロでないことを確認する
5. それでもゼロなら、ゲートウェイ集計を費用の根拠にせず、Azure 側の請求情報で確認する

ゲートウェイ経由で使っているなら、少なくともテスト画像を1枚生成した後に、集計がゼロになっていないか確かめることをお勧めします。

1枚ごとの単価を測ろうとして、「生成前の累計額」と「生成後の累計額」の差分を取る方法を使いました。ところが、一部の行がゼロ円になってしまいました。

理由は課金記録が非同期だからです。生成が終わっても、課金がデータベースに書き込まれるまでには遅れがあります。その遅れの間に次の観測をすると、前の分がまだ反映されていない。そして次の観測時にまとめて現れます。

結果として、ある行がゼロになり、次の行に2枚分が合算される形になりました。合計は正しいので大きな問題ではありませんが、1枚ごとの単価を出そうとすると壊れます。先ほど3段目と4段目を分離できなかったのは、これが理由です。

単価を測るなら日次の集計を使うのが確実です。 1枚ごとの差分でやるなら、生成の間に十分な待ちを入れ、次の生成前に集計が更新されたことを確認してください。

⚠️ 単価の差分がゼロになった場合の戻し方

差分がゼロでも、すぐに「無料」や「課金失敗」と判断しないことです。

• まず複数枚分の合計を確認する
• 行をまたいで金額が合算されていないか確認する
• 1枚ごとの比較をやめ、同じ品質を複数枚まとめた日次・バッチ単位で比較する
• 料金を確定する用途では、ゲートウェイ集計だけでなく Azure の請求情報を確認する

今回の $0.37646 も、ゲートウェイの内蔵料金表による集計値です。Azure 請求書との照合作業は未実施なので、予算報告の確定値としては扱っていません。

計測中に、品質を上げたはずなのに速くなるという矛盾した結果が出ました。最下位設定が94.6秒かかったのに、ひとつ上の設定が27秒だったのです。

再測定すると、同じ設定が21秒で終わりました。4倍以上の差です。デプロイ直後の初回だけが極端に遅かったことになります。要因は特定できていません。ウォームアップの類だろうと推測していますが、そこは未実測なので断定はしません。

危なかったのは、この94.6秒を実力だと思い込みかけたことです。そのまま記事にしていたら「品質優先モデルは速度優先モデルの7倍遅い」という、事実とかけ離れた数字を出すところでした。実際の差は最下位で1.2倍です。

ベンチマークを取るときは必ず2回目以降を採る。 当たり前のようでいて、1回きりの計測でそれらしい数字が出ると疑いにくいものです。

⚠️ 初回の遅さを本番値にしない戻し方

初回が極端に遅かった場合は、次の手順で計測をやり直します。

1. デプロイ直後の1回目をベンチマークから除外する
2. 同じプロンプト・画像サイズ・品質で再度生成する
3. 2回目以降の温間値を比較対象にする
4. 本番で初回遅延が許容できない場合は、事前にテスト生成してから利用する

今回の表は、検証環境での2回目以降の温間値です。デプロイ直後のユーザーが同じ待ち時間になると保証するものではありません。

最後に運用上の注意です。ゲートウェイに新しいモデルを追加するとき、設定ファイルに書くだけでは足りませんでした。

利用するキーごとに「使ってよいモデルの一覧」があり、そこにも追加する必要があります。片方だけだと、モデルは一覧に見えているのに呼ぶと権限エラーになります。

しかもこの一覧は上書き形式でした。新しいモデル名だけを送ると、それまで許可されていたモデルが全部消えます。既存の一覧を先に読み出して、新しい分を足した完全な一覧を送る必要がありました。ここを雑にやると、動いていた別のサービスを巻き込んで壊します。

⚠️ 許可モデル一覧を壊した場合の戻し方

変更前の許可モデル一覧を保存していない場合、追加したモデル名だけを再送してはいけません。

• 変更前の一覧が残っていれば、その完全な一覧を再登録する
• 分からない場合は、稼働中のサービスが使っているモデル名を洗い出す
• 新モデルを足すときは、既存モデルを残した完全な配列として上書きする
• 変更後は、既存サービスと新モデルの両方を1回ずつ呼び出す

モデル追加の変更は、まずテスト用のキーで行うのが安全です。本番キーの一覧を直接置き換える運用は避けたほうがよいでしょう。

今回の実測で運用判断はできましたが、まだ割り切れていない点もあります。

• 品質ごとの生成は各1回なので、同じ条件でのばらつきまでは評価できていない
• プロンプトは1種類で、画像の内容による品質差は確認していない
• 94.6秒になった初回遅延の原因は特定できていない
• ゲートウェイの金額は Azure 請求書と突き合わせていない
• 3段目と4段目の単価は、非同期反映のため分離できていない

特に費用については、「flare と sunburst の公式単価が同じ」ことと、「今回のゲートウェイ集計が一致した」ことは確認できましたが、請求書との照合までは済んでいません。 そのため、この記事の金額はモデル選択の方向性を判断する材料として使い、厳密な請求額の確定には使わないでください。

実測を踏まえた自分の結論です。

• 既定は flare にする。 費用は sunburst と同じで、速い。前世代からの乗り換えは、同じ値段で速くなるだけなので迷う理由がない
• sunburst は使い分けで呼ぶ。 追加料金はかからないので、人物の顔を保ったまま編集するような精密さが要る場面では遠慮なく使う
• 品質パラメータは下2段を常用する。 上位2段は費用が一桁変わるので、ここぞという時だけ
• ゲートウェイ経由なら課金集計がゼロになっていないか確かめる。 気づかないまま使い続けるのが一番こわい
• 課金を確定する前に、Azure の請求情報と照合する。 今回の検証ではそこまでは実施していない

判断に迷ったら、まず自分の用途で同じ画像サイズ・同じプロンプトを使い、flare と sunburst を品質5段で1回ずつ比較してください。今回の条件では、flareの最上位が61秒、sunburstの最上位が154秒でした。この待ち時間を許容できるか、最上位品質に約35倍の費用を払う価値があるかで、設定は決められます。

モデル名を眺めて悩む時間より、5段回して時計を見るほうが早く決まりました。

• 検証日: 2026年9月12日
• 対象: gpt-image-2.5 の2モデル（速度優先 flare / 品質優先 sunburst）、比較対象として前世代の gpt-image-2
• 経路: Azure OpenAI のサーバーレスデプロイを、自宅サーバー上の LiteLLM ゲートウェイ経由で呼び出し
• 条件: 画像サイズ 1024x1024、同一プロンプト、品質は各段1回ずつ、所要時間は2回目以降の温間値
• 計測: 所要時間はクライアント側の実時間。費用はゲートウェイの課金集計（内蔵料金表からの算出値であり、請求書との突き合わせは未実施）
• 注意: 品質ごとの生成回数は各1回のため、生成結果や所要時間の統計的なばらつきまでは評価していない

• GPT-Image-2.5 Flare モデル仕様（OpenAI 公式）
• GPT-Image-2.5 Sunburst モデル仕様（OpenAI 公式）
• Azure OpenAI 画像生成の使い方（Microsoft Learn）

• BlogGPT-5.6 Luna xhigh: 知能49・タスク単価$0.04・待ち時間40秒、安い理由まで実測2026年7月30日の80%値下げ後、通常セッションのモデルをLunaに切り替えるべきか。OpenAI公式発表と第三者ベンチの実測データ（Intelligence Index、TTFT、タスク単価）から、API従量とCodex定額それぞれの判断材料を整理します。→
• Blogデータから見る化け物 GPT-5.6——公式ベンチ7枚を実測者が読み、結論を出すGPT-5.6限定プレビューの公式ベンチ7枚を、事実・分析・推測に分けて読み解く。生の実力と逸脱の影を整理します。→
• BlogGPT-5.6 Sol×Terra、コスパ最強のEffort組み合わせは？実測で検証GPT-5.6 Sol（設計・計画役）とTerra（コーディング実装役）を組み合わせて使う際、どのreasoning effortが最もコスパが良いかをArtificial Analysisの実測データで検証。Solはhighで頭打ち、Terraはhighまで気軽に上げてよい理由を出典付きチャートで確認します。→

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！