GPT-Image-2.5の料金|単価が同じでも費用は違う
「新しい画像生成モデルが出た。うちの請求は上がるのか、下がるのか」——自動で画像を作る仕組みを業務に組み込んでいる方ほど、リリースのたびにこの確認が発生します。
結論から言うと、2026年9月8日に発表された GPT-Image-2.5(Flare / Sunburst)のトークン単価は、前世代の GPT-Image-2 と同じです。ただし「単価が同じ」は「1枚あたりの費用が同じ」を意味しません。OpenAI 自身が公式ドキュメントにそう明記しています。
株式会社Fyveは、SEO記事のサムネイルや図解を毎日自動生成する仕組みを自社で運用しています。この記事では料金表を並べるだけでなく、モデルが世代交代したときに実際に何を確認すればいいのかを、私が自分の運用で見ている順番でお伝えします。
結論:変わったのは単価ではなく「1枚あたりを事前に読む手段」
先に要点を3つにまとめます。2026年9月9日時点で、公式ドキュメントから確認できる事実です。
- トークン単価は据え置き。GPT-Image-2.5 Flare / Sunburst の画像出力は 100万トークンあたり $30 で、公式ドキュメントに「Token rates match GPT Image 2.(トークン単価は GPT Image 2 と一致する)」と明記されています
- 1枚あたりの費用は同じとは限らない。同じ公式ガイドに「Equal token rates don't mean equal cost per image(単価が同じでも、1枚あたりの費用が同じとは限らない)」と書かれています。消費トークン数がモデルと品質設定で変わるためです
- 旧世代の見積もりツールは使えない。「The GPT Image 2 calculator does not estimate GPT Image 2.5 token consumption.(GPT Image 2 の計算ツールは GPT Image 2.5 のトークン消費を見積もらない)」とあります
つまり、値上げでも値下げでもありません。「事前に金額を計算する道具」が、いまは手元にない状態になったというのが、実務上いちばん大きな変化です。
ここを「単価据え置き=影響なし」と読んでしまうと、月末の請求で驚くことになります。以下、根拠と対処を順に見ていきます。
2026年9月8日に発表された内容を整理する
まず何が出たのかを、公式発表の記述で確認します。ChatGPT 側の機能追加と、API 側の新モデル追加が同時に告知されました。
ChatGPT側:生成が最大50%速くなり、Sketchが追加された
公式発表には「We've also reduced image generation latency by up to 50% compared with Images 2.0(Images 2.0 と比べて画像生成のレイテンシを最大50%削減した)」とあります。ここで比較対象になっているのは ChatGPT 側の「Images 2.0」であって、API のモデル名ではない点に注意してください。
機能面では、ChatGPT 内に直接絵を描いて参照にできる Sketch(チャットで「@Sketch」と入力して起動)、ポスターやマーチャンダイズなど定番フォーマットのテンプレート、画像上にコメントを置いて部分的に編集する機能、使ったプロンプトを画像と一緒に共有する機能が追加されています。
提供範囲は「Images 2.5 is available to all ChatGPT, ChatGPT Work, and Codex users across desktop, mobile, and web.」——ChatGPT・ChatGPT Work・Codex の全ティアに、デスクトップ・モバイル・Web で展開される、と書かれています。
なお公式発表は冒頭で「Every week, people create more than 3 billion images across ChatGPT Images and the GPT-Image models in the API.(毎週30億枚以上の画像が ChatGPT Images と API の GPT-Image モデルで生成されている)」という規模を示しています。画像生成はもはや実験ではなく、業務プロセスの一部として動いている、という前提での更新です。
API側:FlareとSunburstの2モデルに分かれた
API では2つのモデルが追加されました。公式の説明を、そのまま訳して並べます。
- GPT-Image-2.5 Flare:「Fast, high-quality everyday image generation(速くて高品質な、日常的な画像生成)」。公式発表では「the default choice for most applications(ほとんどの用途での既定の選択肢)」とされ、「delivering higher-quality images than GPT-Image-2 at 50% lower latency(GPT-Image-2 より高品質な画像を、50%低いレイテンシで提供)」と説明されています
- GPT-Image-2.5 Sunburst:「Our most capable model for image generation and editing(画像生成と編集で最も高性能なモデル)」。「Use it for workflows where editing precision matters most(編集精度が最も重要なワークフローで使う)」とあり、発表側では「with longer generation times(生成時間はより長い)」と明記されています
ここで押さえておきたいのは、Sunburst は「上位版」ではなく「用途違い」として提示されていることです。速さを取るなら Flare、編集の精度を取るなら Sunburst。価格が同じなので、上下関係ではなく横並びの選択になります。
発表日は「モデルIDの日付」で裏が取れる
細かいことですが、実務では役に立つ確認方法があります。OpenAI のモデルには日付入りのスナップショットIDが用意されていて、公式ドキュメントの既定スナップショットはそれぞれ次のようになっています。
gpt-image-2.5-flare-2026-09-08gpt-image-2.5-sunburst-2026-09-08- (前世代)
gpt-image-2-2026-04-21
ニュース記事の公開日は媒体側の都合で1〜2日ずれることがありますが、モデルIDに埋め込まれた日付は提供元が付けたものです。「いつ出たのか」を社内で共有するときは、記事の日付ではなくこちらを使うと後から揉めません。
あわせて、前世代の GPT-Image-2 が 2026年4月21日のスナップショットであることも読み取れます。画像モデルの世代交代はおよそ4〜5か月間隔で起きている——自動化に組み込むなら、この頻度で確認作業が発生する前提で設計しておくべきです。
料金表:トークン単価は前世代と同じ
ここからが本題です。まず公式の価格ページとモデルドキュメントに掲載されている単価を、そのまま表にします。2026年9月9日時点の値です。
項目 | GPT-Image-2.5 Flare | GPT-Image-2.5 Sunburst |
|---|---|---|
テキスト入力 | $5.00 / 100万トークン | $5.00 / 100万トークン |
テキスト入力(キャッシュ) | $1.25 / 100万トークン | $1.25 / 100万トークン |
画像入力 | $8.00 / 100万トークン | $8.00 / 100万トークン |
画像入力(キャッシュ) | $2.00 / 100万トークン | $2.00 / 100万トークン |
画像出力 | $30.00 / 100万トークン | $30.00 / 100万トークン |
FlareとSunburstは完全に同額です。速いほうが安い、精度が高いほうが高い、という関係にはなっていません。
そして両モデルのドキュメントには、次の1文が添えられています。
「Token rates match GPT Image 2. The GPT Image 2 calculator does not estimate GPT Image 2.5 token consumption.」
前半が「単価は前世代と一致」、後半が「前世代の計算ツールは 2.5 の消費量を見積もらない」です。この2文が並んでいることに、今回の実務上の意味が凝縮されています。
なお、テキスト出力の課金は発生しません。ドキュメントには「Text output is not billed because this model outputs images, not text.(このモデルはテキストではなく画像を出力するため、テキスト出力は課金されない)」と明記されています。
為替や税の扱い、契約形態によって実際の請求額は変わります。導入判断に使う場合は、必ず公式の価格ページでその時点の値をご確認ください。
「同じ単価」を「同じ費用」と読んではいけない
ここが今回いちばん誤解されやすい点です。公式の画像生成ガイドには、こう書かれています。
「Equal token rates don't mean equal cost per image: token consumption can differ by model and quality setting.」
訳すと「単価が同じでも1枚あたりの費用が同じとは限らない。消費トークン数はモデルと品質設定によって変わりうる」。さらに別の箇所では「The models can use different token counts for the same quality setting(同じ品質設定でも、モデルごとに消費トークン数が異なりうる)」とも書かれています。
画像生成の請求は、次の掛け算で決まります。
- 単価(100万トークンあたりいくら)
- ×1枚が消費するトークン数(モデル・品質・サイズで変動)
- ×生成した枚数(ここが自動化で最も膨らむ)
ニュースやまとめ記事が扱うのは、たいてい1つ目の「単価」だけです。ところが実際の請求で効くのは2つ目と3つ目で、今回変わったのはまさに2つ目——しかも、その2つ目を事前に推定する公式ツールが 2.5 には用意されていない、という状態です。

私がこの構造を強く意識しているのは、テキスト側のモデルで同じ落とし穴を一度通っているからです。単価と総額は別物で、条件次第で逆転します。
参考:前世代より前のモデルで公開されていた「跳ね方」
では消費トークン数はどのくらい変動するのか。2.5 の数値は公表されていませんが、公式ガイドには gpt-image-2 より前の世代について、参考値の表が残っています。
品質 | 正方形(1024×1024) | 縦長(1024×1536) | 横長(1536×1024) |
|---|---|---|---|
Low | 272トークン | 408トークン | 400トークン |
Medium | 1,056トークン | 1,584トークン | 1,568トークン |
High | 4,160トークン | 6,240トークン | 6,208トークン |
🔴 この数値は GPT-Image-2.5 には適用できません(公式が「models prior to gpt-image-2=gpt-image-2 より前のモデル」の値だと明記しています)。ここで見てほしいのは絶対値ではなく比率です。
正方形で比べると、Low の272トークンに対して High は4,160トークン。品質設定を上げるだけで、1枚の消費が約15倍になります。同じ単価表を見ていても、品質の指定ひとつで請求は桁が変わる、という構造がここに出ています。
だからこそ「単価が同じだから影響なし」という判断が危ないわけです。単価は掛け算の1項目でしかありません。
事前見積もりの代わりに、公式が指示しているのは「実測」
計算ツールが使えないなら、どうやって費用を把握するのか。公式ガイドは明確に指示しています。
「Use the response's usage to measure token consumption for your prompts, sizes, and quality settings.(自分のプロンプト・サイズ・品質設定でのトークン消費は、レスポンスの usage で測れ)」
つまり「見積もる」から「測る」へ運用を切り替えろ、ということです。これは面倒に聞こえますが、実務的にはむしろ健全です。
自動化に組み込んだ画像生成は、プロンプトの長さも参照画像の有無も現場ごとに違います。汎用の計算ツールで出した理論値より、自分の実際のリクエストで返ってきた usage を数十回ぶん集計したほうが、はるかに正確です。
具体的には、次の順番をおすすめします。
- 本番と同じプロンプト・同じサイズ・同じ品質で 10〜30枚 生成する
- 各レスポンスの
usageを記録し、1枚あたりの画像出力トークンの中央値と最大値を出す(平均値だけだと外れ値を見落とします) - 中央値 × 月間の想定枚数 × 単価で月額の目安を出し、最大値で上振れの天井を出す
- この2つの数字を持って、はじめて「乗り換えるか」を判断する
ここまでやって初めて、モデル変更の是非が数字で言えます。逆に言えば、この実測をしていない状態での「安くなった/高くなった」は、全部推測です。
見落としやすい差分:バッチAPIが使えない
料金表よりも実害が大きい可能性があるのが、こちらです。公式モデルドキュメントの対応エンドポイント表を比べると、はっきりした差があります。
エンドポイント | GPT-Image-2 | GPT-Image-2.5 Flare / Sunburst |
|---|---|---|
画像生成 | 対応 | 対応 |
画像編集 | 対応 | 対応 |
バッチ | 対応 | 非対応 |
バッチAPIは「急がない処理をまとめて投げる代わりに安くする」仕組みです。公式の価格ページに載っている gpt-image-2 のバッチ単価は次のとおりで、通常価格のちょうど半額になっています。
項目 | 通常 | バッチ(gpt-image-2) |
|---|---|---|
テキスト入力 | $5.00 | $2.50 |
テキスト入力(キャッシュ) | $1.25 | $0.625 |
画像入力 | $8.00 | $4.00 |
画像入力(キャッシュ) | $2.00 | $1.00 |
画像出力 | $30.00 | $15.00 |
ここから導かれる結論は、けっこう重いです。
夜間にまとめて画像を生成する処理をバッチで組んでいる場合、GPT-Image-2.5 に乗り換えると、単価は据え置きでも実質的に2倍払うことになります。半額の経路が塞がるからです。
これは「値上げ」とはどこにも書かれていません。単価表を見比べても差は出ません。対応エンドポイントの表を見て初めて分かる差分で、まとめ記事の類ではまず触れられない部分です。
したがって、乗り換え判断は次のように分岐します。
- バッチを使っていない(ユーザー操作に対してその場で生成している)→ 単価は同じなので、消費トークン数の実測だけ確認すれば乗り換えてよい
- バッチを使っている→ 「速度と品質」対「半額」の比較になる。急がない処理なら前世代に留まるほうが安い場合がある
速さで得たものを、割引の喪失で払っている——そういう形の値上げが起きうる、ということです。

品質設定が3段から5段に増えた
もうひとつ、費用に直結する変更があります。公式ガイドの記述です。
「For gpt-image-2.5-sunburst and gpt-image-2.5-flare, the quality options are low, medium, high, xhigh, and max. For gpt-image-2, the options are low, medium, and high.」
GPT-Image-2 | GPT-Image-2.5 | |
|---|---|---|
品質設定 | low / medium / high(3段) | low / medium / high / xhigh / max(5段) |
上に2段(xhigh・max)増えました。表現の幅が広がったのは良いことですが、費用の観点では上振れの余地が増えたということでもあります。
前世代より前の参考値で見たとおり、品質を1段上げるだけで消費トークンは数倍に跳ねます。段が2つ増えたということは、「とりあえず最高品質で」と設定した瞬間に、想定していた額を大きく超える可能性がこれまでより高くなったという意味です。
加えて auto という設定もありますが、公式は「auto depends on the generated image.(auto は生成される画像に依存する)」として、見積もりには明示的な品質とサイズを使うよう指示しています。費用を読みたい処理で auto を使わない——これは自動化に組み込むうえで守るべき原則です。
自動化に組み込んでいる場合に効く、その他の制約
レート制限は前世代と同じ
公式ドキュメントのレート制限表を比べたところ、GPT-Image-2 と GPT-Image-2.5 の既定値は同一でした。
ティア | TPM(1分あたりトークン) | IPM(1分あたり画像数) |
|---|---|---|
Tier 1 | 100,000 | 5 |
Tier 2 | 250,000 | 20 |
Tier 3 | 800,000 | 50 |
Tier 4 | 3,000,000 | 150 |
Tier 5 | 8,000,000 | 250 |
使い始めたばかりの Tier 1 では1分あたり5枚です。生成が50%速くなっても、この上限に当たれば速度は活かせません。「速くなったから一気に回せる」と考えて設計すると、待たされるのはモデルではなく制限のほうです。
ここは変わっていない、という確認も世代交代時には必要な作業です。「変わったところ」だけを見て「変わらなかったところ」を確認しないと、変更点リストは作れても影響範囲は出せません。
途中経過を受け取ると1枚につき100トークン加算される
生成の途中経過をストリーミングで受け取る partial_images を使う場合、公式ガイドに「each partial image will incur an additional 100 image output tokens(各途中画像に画像出力トークンが100加算される)」とあります。
1枚では誤差ですが、途中経過を複数枚受け取る設定で月に数千枚生成するなら、無視できない量になります。ユーザーに見せる必要がない自動処理では、途中経過を受け取らないのが素直な設計です。
透かしとメタデータは入る
公式発表には「We continue to use C2PA metadata and invisible watermarking to help identify images made with our tools.(当社ツールで作られた画像を識別するため、C2PAメタデータと不可視の透かしを引き続き使用する)」とあります。
商用で使う画像に生成元を示すメタデータが埋まる点は、社内規程やクライアントの要件によっては確認が必要です。費用の話ではありませんが、業務利用の可否を決める要素なので、乗り換え検討時のチェック項目に入れておくことをおすすめします。
FlareとSunburstをどう使い分けるか
価格が同じなので、判断軸は「速度」対「編集精度」だけになります。公式の説明に沿って整理すると、次のようになります。
Flare | Sunburst | |
|---|---|---|
公式の位置づけ | ほとんどの用途での既定 | 編集精度が最優先のワークフロー |
速度 | 速い(GPT-Image-2比で50%低レイテンシ) | 生成時間はより長い |
想定用途 | クリエイター向け・SNS用素材・製品体験・試作・大量生成 | キャンペーン用の本番クリエイティブ・仕上げた製品画像 |
料金 | 同額 | |
実務的な判断はシンプルです。1枚を何度も直して仕上げる仕事なら Sunburst、数を回して当たりを選ぶ仕事なら Flare。中小企業の現場で多いのは後者だと思います。
「編集の精度」が効くのは、すでに合意が取れた画像の一部だけを差し替えるような場面です。公式発表も「update a single element—such as a product, background, or piece of copy—while preserving the subject, composition, and brand treatment around it(被写体・構図・ブランド表現を保ったまま、製品や背景やコピーといった単一要素だけを更新する)」という使い方を挙げています。ここに当てはまる業務がないなら、Flare で十分です。
私がサブスク枠を主経路にしている理由
ここまで API の料金の話をしてきましたが、私自身の運用ではAPI従量課金を主経路にしていません。
私は毎日、公開するSEO記事のサムネイル画像を自動生成しています。1日に数枚、月にすると百枚前後。この処理の主経路はサブスクリプション枠の中で完結する呼び出しで、API に出るのは主経路が失敗したときのフォールバックだけ、という二段構えにしています。
理由は単価ではなく、枚数が自分の意思と関係なく増えるからです。
自動生成には必ず作り直しが発生します。日本語の文字が崩れる、構図が意図とずれる、指定した比率で返ってこない——そのたびに再生成が走ります。人が手で作っているうちは「まあいいか」で1枚に収まるものが、機械に任せると品質チェックに引っかかるたびに枚数が積み上がるのです。
従量課金でこれをやると、請求額が「その月にどれだけ品質チェックに引っかかったか」で決まってしまいます。金額の予測が立たない支出を、毎日走る自動処理に置きたくない。だから定額の枠に押し込んで、上限を構造で決めてしまう設計にしています。
この判断の詳細は、以前に入口の選び方として整理しました。
サブスク枠経由で画像生成を回す具体的な手順は、こちらにまとめています。
そして、この構造にしているおかげで、今回のような世代交代のニュースが出ても、主経路の請求額は動きません。確認が必要なのは「出力の品質が変わったか」だけで、費用の再計算は発生しない。世代交代のたびに費用を計算し直す作業そのものを、設計で消しているわけです。
もちろん、大量生成やプロダクト組み込みでは API 従量課金が必要になります。その場合に効いてくるのが、次の確認手順です。
モデルが世代交代したときに実際にやる確認手順
自動化に画像生成を組み込んでいる場合、新モデルが出たときにやることを5段階に整理しました。上から順に、コストが低く効果が大きい順です。
- 単価表を見る前に、対応エンドポイントの表を見る。バッチや特定のAPI経路が落ちていないか。今回のバッチ非対応のように、単価に現れない実質的な値上げはここに出る
- 品質設定の選択肢が増減していないか確認する。段が増えている場合、自分のコードが指定している値が有効かを確かめる。無効な値を渡してエラーで止まるより、黙って既定値で動くほうが厄介
- 同じ条件で10〜30枚生成し、
usageの実測を取る。単価が同じでも消費トークン数は変わりうる。中央値と最大値の両方を記録する - レート制限を確認する。速くなっても上限に当たれば意味がない。とくに新規に課金を始めたばかりのティアは制限が低い
- モデルIDを日付付きスナップショットで固定するか決める。
gpt-image-2.5-flareのような日付なしのIDは、提供元の判断で中身が更新されます。品質を固定したい本番処理では日付付きを指定する
5番目は特に、自動処理を組んでいる方に強調しておきたい点です。日付なしのIDを使うということは、「提供元が中身を差し替えたら、こちらの承認なしに出力が変わってよい」と宣言しているのと同じです。それが望ましい処理(常に最新を使いたい)と、望ましくない処理(品質を一定に保ちたい)を分けて指定してください。
中小企業がこの手のニュースで判断を誤りやすい3点
1. 単価の比較だけで結論を出してしまう
私はこの記事を書く前に、まず検索結果の要約で価格の概況をつかもうとしました。そこには「API価格は前世代の2倍」という趣旨の記述が含まれていました。ところが公式のモデルドキュメントに当たると「Token rates match GPT Image 2.(単価は GPT Image 2 と一致)」と明記されており、一次情報では逆の結論になりました。
料金の話は、まとめ記事や検索結果の要約を根拠にしないでください。金額は判断に直結するので、必ず提供元の価格ページとモデルドキュメントで、自分の目で確認する。これは私が社内ルールとして明文化している項目でもあります。
2. 「速くなった」を「安くなった」と読んでしまう
レイテンシの改善は嬉しい変化ですが、費用とは別の軸です。むしろ自動処理においては、速くなると同じ時間により多く回せるので、枚数が増えて総額が上がる方向に働きます。
速度改善は「待ち時間が減る」という価値であって、「支払いが減る」という価値ではありません。ここを混ぜると、導入の稟議で説明できない差が出ます。
3. 新機能に合わせて業務を変えようとしてしまう
Sketch もテンプレートも便利な機能ですが、いまの業務にその工程が無いなら、無理に使う必要はありません。新機能が出るたびに業務を作り直していると、いつまでも定着しません。
判断の順番は逆です。「この新機能で何ができるか」ではなく、「いま手作業で時間を取られている工程はどれか」から始めて、そこに当てはまる道具があれば使う。当てはまらなければ見送る。それだけです。
画像生成まわりで手戻りが多い方は、そもそも指示の渡し方に原因があるケースもあります。
まとめ
2026年9月8日に発表された GPT-Image-2.5 について、公式ドキュメントから確認できた要点を整理します。
- トークン単価は GPT-Image-2 と同じ(画像出力 $30 / 100万トークン、2026年9月9日時点)。Flare と Sunburst も同額
- ただし1枚あたりの費用は同じとは限らない。公式が「単価が同じでも1枚あたりの費用が同じとは限らない」と明記しており、旧世代の計算ツールも 2.5 には使えない
- 費用把握は「見積もる」から「測る」へ。レスポンスの
usageを実測するよう公式が指示している - バッチAPIが非対応。前世代はバッチで半額だったため、夜間まとめ生成を組んでいる場合は実質的な値上げになる
- 品質設定が3段から5段へ。上振れの余地が増えたので、自動処理では
autoを使わず明示的に指定する - レート制限は据え置き。Tier 1 は1分あたり5枚で、速度改善だけでは突破できない
単価だけを見て「変わらない」と判断するのが、いちばん危ない読み方です。画像生成の請求は単価 × 1枚あたりのトークン数 × 枚数で決まり、今回変わったのは真ん中の項目でした。
そして自動化に組み込んでいる場合、最も膨らむのは3つ目の「枚数」です。私が定額の枠を主経路に据えているのは、まさにそこを構造で抑えるためでした。
株式会社Fyveでは、こうしたAIツールの費用構造の見極めから、実際の業務への組み込みまでを月額で伴走しています。「新しいモデルが出るたびに調べ直す時間がない」という段階でご相談いただくのが、いちばん無駄が出ません。
AIを使う会社と、使わない会社。
その差は、開き始めています。
ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。
