画像生成 API のコスト比較:5 モデルを検証($0.006–$0.039)
テキスト LLM 向けに作った gateway に画像生成を追加し、モデル、解像度、画像枚数、品質という 4 つの変数がコストにどう影響するかを測定した。最も影響が大きいのは品質だ。多くの画像 API がこのパラメータを提供しているが、ほとんどの caller はデフォルトのまま使っている。解像度、prompt caching、batching の影響は一般に思われているよりはるかに小さい。
TL;DR
- gpt-image の
quality設定は、同じ解像度でも料金を約 36 倍変える。1024x1024 の low/medium/high で、課金対象の output token は 196/1,756/7,024、料金は $0.0060/$0.053/$0.211 だった。 - モデル選択による差は 6.4 倍。gpt-image-2 の low quality は 1 枚 $0.0060、gemini-2.5-flash-image は $0.0387。
- 解像度の影響は小さい。gpt-image-2 を 1024x1024 から 2048x2048 に上げても、1 枚あたりのコストは 2 倍にしかならなかった。
- 画像生成に prompt caching はなく、
n=4ではプロンプトも 4 回分課金される。output token が約 1,000 未満なら token 課金、それを超えるなら画像 1 枚あたりの定額課金が安い。
画像生成モデルの違い
画像生成モデルは、そのまま差し替えて使えるものではない。違いはいくつもあり、価格に直接関係するのは課金方式だけだ。現在利用できるモデルをまとめると、次のようになる。
| Family | Billing | quality knob | Batch n>1 | Resolution |
|---|---|---|---|---|
gpt-image (OpenAI) | token 単位 | ✓ low/med/high | ✓ | 最大 ≈2K |
gemini-image (Google) | token 単位 | ✗ | ✗ 1/call | 1K(gemini-3:最大 4K) |
qwen-image / wan2.7 (Alibaba) | 画像ごとの定額 | ✗ | ✓ | 512²–2048² |
seedream (BytePlus) | 画像ごとの定額 | ✗ | ✗ 1/call | ≥1920²(4.5/5.0) |
どのモデルも同じように動くと思い込むと、次の違いが問題になる。
- 課金方式。 token 単位(
gpt-image、gemini)と、画像 1 枚ごとの定額(qwen、wan、seedream)がある。最終的な料金を決める要素であり、次のセクションで詳しく扱う。 quality設定。quality(low/medium/high)があるのはgpt-imageだけだ。Gemini はモデル tier(flashからpro)またはimage_sizeで品質を変える。定額モデルには同等の設定がない。この 1 つの設定だけで料金が約 36× 変わるため、コストを左右する最大の要素になる。- Batch(
n>1)はすべてのモデルで使えるわけではない。gpt-image、qwen、wanは 1 回の call で複数画像を返せる。Gemini と Seedream の全画像モデルは 1 call につき 1 枚のみで、n=2を指定すると400が返る。N 回 request を送り、batch の制御も自分で実装する必要がある。 - 解像度には上限だけでなく下限もある。
gemini-2.5-flash-imageの上限は 1K(1 MP)だが、gemini-3は 2K/4K に対応する。料金は 1K から 4K でおよそ 2 倍になる。Seedream 4.5/5.0 は約 1920² が下限で、それより小さい画像は拒否される。qwen-imageの範囲は 512²–2048²。高解像度を常に選べるとは限らず、コストを下げるために解像度を落とせない場合もある。 - 制御パラメータと image-to-image の仕様も異なる。
seed、negative_prompt、guidance_scaleに対応するモデルは限られる。編集時に渡せる参照画像の上限も、3 枚(gemini-2.5)から 16 枚(gpt-image)まで差がある。
quality には直感に反する性質が 1 つある。gpt-image の output token は、生成されたファイルを測る単位ではなく、課金単位だ。OpenAI は公開済みの(quality × size)単価表から token 数を決めている。gpt-image-1 の 1024² では、low/medium/high が 272/1,056/4,160 token だ。つまり token 数は返却された byte 数から算出されるのではなく、quality で決まる。実際に検証すると、同じプロンプトを 1024² で 3 つの tier に送った結果、いずれも同じ 1024×1024 の PNG が生成され、ファイルサイズも約 0.9 MB とほぼ同じだった。それでも課金された token 数は 196、1,756、7,024 だった。解像度も byte 数も同じなのに、コストは 36 倍違う。料金は pixel 数ではなく rendering effort に対して発生する。そのため、出力を見て推測するのではなく usage を確認する必要がある。
これらのモデルに共通して存在しない機能が prompt caching だ。コスト削減策として最初に検討されがちだが、画像生成は stateless であり、再利用できる会話や KV state がない。usage object にも cache field はなく、後述の測定結果どおり、batching でもプロンプトは共有されない。Caching は chat の機能であり、画像生成には適用されない。したがって、prompt caching で画像生成コストを削減できるという前提は成立しない。
実測結果
同じ EC 商品向けプロンプトを使い、gateway 経由で実際に画像を生成した。返却された usage と各モデルの公開単価からコストを計算している。個別の sweep から得られた 5 つの結果を紹介する。
1. コストの中心はプロンプトではなく画像。 text-to-image(プロンプトを入力して画像を出力する処理)の料金は、97〜100% が output token だ。1024² の gpt-image-2 では input が 21 token、output が 196 token で、それぞれ約 $0.0001 と $0.0059 になる。gemini-2.5-flash-image の input は 10 token だ。テキストのプロンプトは誤差に近い。ただし、input がテキストだから安いだけだ。画像を入力する image-to-image、たとえば「このマグカップを青くして」のような処理では、input token が大幅に増える。
| Model | t2i input | i2i input (1 ref) | Output |
|---|---|---|---|
gpt-image-2 (low) | 21 tok | 1,043 tok | 196 tok |
gemini-2.5-flash-image | 10 tok | 1,297 tok | 1,290 tok |
input は 50〜130× に増え、参照画像の枚数に比例する。gpt-image-2 では参照画像を 1、2、3 枚に増やすと、それぞれ 1,043、2,068、3,093 token になり、1 枚追加するごとに約 1,025 token 増えた。low quality では、この input token が生成された output token の 5 倍を超える。生成する場合でも入力として渡す場合でも、コストの中心は画像であり、プロンプトではない。以降は text-to-image に絞る。image-to-image の詳しいコスト構造は、別の記事で扱う。
2. モデル選択でコストは 6× 変わる。 同じ 1024²、デフォルト品質で request を送った結果は次のとおり。
| Model | Billing | Cost / image |
|---|---|---|
gpt-image-2 | token · quality 設定あり | $0.0060 |
gpt-image-1-mini | token · quality 設定あり | $0.0085 |
seedream-4-0 | request ごとの定額 | $0.030 |
qwen-image-2.0 | request ごとの定額 | $0.035 |
gemini-2.5-flash-image | token · quality 設定なし | $0.0387 |
最安と最高額の差は 6.4×。各モデルが生成する output token 数だけで、この差が生じている。
3. 解像度による変化は小さい。 gpt-image-2 を 1024² から 2048² まで変えても、1 枚あたりのコストは $0.0060 から $0.0121 で、ほぼ横ばいだった。output token は pixel 数に比例しない。gemini-2.5-flash-image では、指定した size に関係なく同じ 1,290 token が返った。このモデルは 1K 専用で、size は aspect ratio だけを変えるためだ。(gemini-3 の画像 tier は image_size を反映し、1K から 4K でコストが約 2 倍になる。ただし、今回測定した 2.5-flash-image は該当しない。)画像ごとの定額モデルは、定義上、解像度によって料金が変わらない。ここまでの結果では、token 単位のモデルが明確に有利に見える。
4. 分岐点を決めるのは品質。 gpt-image-2 の quality tier を変えた結果は次のとおり。
| quality | 1024² | 2048² |
|---|---|---|
| low | $0.0060 (196 tok) | $0.0121 (397 tok) |
| medium | $0.053 (1,756 tok) | $0.107 (3,568 tok) |
| high | $0.211 (7,024 tok) | $0.428 (14,272 tok) |
output token は low から medium で約 9×、low から high で約 36× に増える。low quality では token 単位のモデルが最安だが、medium または high では画像 1 枚あたりの定額($0.03–0.035)を上回る。計算上の分岐点は約 1,000 output token($0.03 ÷ $30/M)だ。low はこれを下回り、medium は上回る。この結果によって、以前の結論も訂正する必要がある。「token 課金は常に最安」という結論は、デフォルトの low quality だけで検証したために生じたものだった。

同じプロンプト、gpt-image-2、1024²。low/medium/high の課金は 196/1,756/7,024 output token、または $0.006/$0.053/$0.215。同じ解像度でも 36× の差がある。このようなシンプルな商品写真では 3 つの違いを見分けにくいため、最安の tier で十分なことが多い。high をデフォルトにせず、用途に合わせて quality を設定する。
5. 複数画像でプロンプトを共有できない。 1 回の call で n 枚生成しても、プロンプトのコストは分散されない。gpt-image-2 では N 回分が課金される。n=4 にすると input token は 28 から 112 に増え、長いブランドプロンプトでは 499 から 1,996 になった。1 枚あたりのコストは n=1 と n=4 で同じだった。Caching もないため、画像生成にはプロンプトのコストを共有する仕組みがない。output 画像ごとに料金が発生し、プロンプトも毎回課金される。
選択基準
text-to-image で判断材料になるのは、一般に想定される要素ではなく品質だ。
- Low/draft/thumbnail quality: quality を指定できる token 課金モデル(
gpt-image、約 $0.006–0.012)。約 2K までなら、どの解像度でも最安。 - Medium/high quality: request ごとの定額モデル(
seedream/qwen、$0.03–0.035)。token 課金は大きく膨らみ、今回の測定では $0.05–0.43 になった。定額モデルなら安く、品質を変えても料金は変わらない。 gemini(デフォルトの 1K で約 $0.039)がコスト面で最適になるケースは少ない。 low quality ではgpt-imageのほうが安く、medium と high では request ごとの定額モデルのほうが安い。quality設定はない。価格ではなく出力品質を求めて Pro tier または高いimage_sizeを選ぶモデルだ。- 同じ quality tier 内では、解像度によるコスト差は約 2×。 モデル選択を逆転させるほどではない。結果を変えるのは品質だ。
n>1、caching、batching のどれを使っても、1 枚あたりのコストは下がらない。 共有できるものがない。- Image-to-image:基本は画像 1 枚あたりの定額モデル。 参照画像は input であり、追加料金が発生するのは token 課金モデルだけだ。1 枚あたり約 1,025 token 増える。定額モデルなら追加料金はない。編集では通常、
seedream/qwenが有利になる。参照画像が少ない low quality の編集に限ればgpt-imageのほうが安いが、約 5 枚で定額料金を超える。品質または参照画像の枚数が増えれば不利になる。
EC が最も分かりやすい例だ。catalog 内の各商品に同じ長いブランドプロンプトを送って商品写真を生成し、繰り返し部分を cache すれば安くなると考えたとする。しかし、これは 2 つの理由で成立しない。そもそもコストの中心はプロンプトではなく画像であり、画像生成には caching もない。実際の商品画像には medium 以上の品質が必要になるため、適切なのは画像 1 枚あたりの定額モデルだ。プロンプトがどれだけ重複していても、安く、料金も予測しやすい。
冒頭で挙げた機能上の制約によって、コストだけでは決められない場合もある。1 call につき 1 枚という制限、解像度の下限と上限、data residency の制約、モデルが提供する設定(seed、negative_prompt、guidance_scale)などだ。まずコストで選び、その後に必要な機能を満たすか確認する。
この数値を信頼できる理由
ここで示した数値は推定ではない。各 vendor が公開している単価と、実際に返された usage から算出している。私たちの gateway では、画像生成の課金は sessionless で処理される。課金が確定するのは 2xx の場合だけで、生成に失敗しても料金は発生しない。支出前に最大コストを事前確認し、response に usage がない場合は黙って $0 とせず、上限額で課金する。原則は他の機能と同じだ。vendor が提示する数値ではなく、実際のコストを確認する。この方法は、gateway が cache について虚偽の情報を返していないか監査した記事でも使った。
結論
画像生成は単なる別 endpoint に見えるが、課金単位が異なる。text-to-image で重要なのは、プロンプトでも解像度でもない。prompt caching も batch 内での共有もない。コストを決めるのは品質だ。low では gpt-image が最安で、medium と high では画像 1 枚あたりの定額モデル(seedream/qwen)が有利になる。分岐点は約 1,000 output token だ。用途に合わせて品質を明示的に設定し、その品質に適したモデルを選び、実際のコストを確認する。生成から編集へ移り、参照画像を入力する場合は、もう一度計算し直す必要がある。input 画像自体がコストになるためだ。
FAQ
Prompt caching で画像生成コストは下がるか?
下がらない。画像生成は stateless で、usage object に cache field はない。batching でも画像ごとにプロンプトが再課金される。コストの中心はテキストではなく output 画像だ。
token 課金と画像単位の課金では、どちらが安いか?
品質による。low または draft quality なら、gpt-image のように quality を設定できるモデルが安い(約 $0.006–0.012)。medium または high なら、seedream/qwen のような画像ごとの定額モデル($0.03–0.035)が安い。token 課金では料金が大きく膨らむためだ。image-to-image では、さらに定額モデルが有利になる。定額モデルは参照画像に追加料金がかからないが、token 課金モデルでは 1 枚あたり約 1,025 token が加算される。
情報源
- OpenAI:画像生成 API
- OpenAI:gpt-image の token 単位料金
- Google:Gemini API の料金(画像 output token)
- OpenAI:Prompt caching(画像生成に適用されない理由)
すべて 2026-06-19 に確認済み。金融上の助言ではない。利用前に最新の料金を確認すること。