画像生成の請求額を実際に左右するもの

テキストLLM向けに構築したゲートウェイに画像生成機能を追加し、モデル・解像度・画像枚数・品質という4つの変数にわたってコストを左右する要因を実測した。最大のレバーは品質（quality）であり、ほとんどの画像APIが公開しているにもかかわらず、多くの呼び出し元がデフォルトのまま使っているパラメータだ。解像度・プロンプトキャッシュ・バッチ処理は、一般に思われているほど影響が小さい。

画像モデルの違い

画像モデルは互いに単純な置き換えができるわけではない。複数の軸で異なる特性を持ち、そのうち価格に関わるのは課金形態の1軸だけだ。現行カタログを一覧すると：

あるモデルが別のモデルと同じ挙動をすると思い込むと痛い目を見る軸：

• 課金形態。 トークン単位（gpt-image、gemini）か画像単位の定額（qwen、wan、seedream）か。これが請求額を決める軸であり、次のセクションで詳しく扱う。
• quality 設定。 gpt-image のみが持つ（low/medium/high）。Gemini はモデルのティア（flash から pro）や image_size で精度を変える。定額モデルにはそのようなダイヤルがない。この1つの設定が請求額を約36倍も変動させるため、主要なコストレバーとなる。詳細は後述する。
• バッチ（n>1）はすべてのモデルで使えるわけではない。 gpt-image、qwen、wan は1回の呼び出しで複数枚の画像を返す。Gemini と Seedream の画像モデルはすべて1呼び出し1枚制限であり、n=2 を指定すると 400 エラーが返るため、N回のリクエストを発行してバッチを自前でオーケストレーションする必要がある。
• 解像度制限は双方向に影響する。 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²の範囲内で動作する。高解像度が常に利用可能とは限らず、コスト削減のために解像度を下げることが常に許可されているわけでもない。
• 制御パラメータと画像間変換の仕様は異なる。 seed、negative_prompt、guidance_scale を受け付けるモデルは一部に限られ、編集時の参照画像の上限は3枚（gemini-2.5）から16枚（gpt-image）まで幅がある。

quality 設定には直感に反する特性が1つある。gpt-image において、出力トークンは課金単位であり、受け取るファイルの計測値ではない。OpenAI は公開された（quality × size）ごとのレートテーブルからトークン数を割り当てる（gpt-image-1 の1024²では low / medium / high に対してそれぞれ272 / 1,056 / 4,160トークン）。つまりトークン数は quality によって決まり、返されるバイト数から導出されるわけではない。実際に確認したところ、1024²で同じプロンプトを3つのティアすべてで実行した結果、ほぼ同じファイルサイズ（約0.9 MB）の同一の1024×1024 PNGが生成されたにもかかわらず、課金されたトークン数はそれぞれ196、1,756、7,024だった。同じ解像度、同じバイトサイズで、コストは36倍。支払うのはピクセル数ではなくレンダリングの労力に対してであり、だからこそ出力を目視するのではなく usage を読む必要がある。

これらのモデルのいずれも持っていない機能の1つがプロンプトキャッシュだ。コスト削減策として真っ先に思い浮かぶことが多いが、画像生成はステートレスであり、再利用できる会話やKV状態が存在しない。usage オブジェクトにキャッシュフィールドは含まれず、後述の実測でも、バッチ処理でプロンプトが共有されることはない。キャッシュはチャット機能であり、画像機能ではない。これは画像コスト削減に関するよくある思い込みを否定するものだ。

実際に計測してみた

同一のECサイト風プロダクトプロンプトを使い、ゲートウェイ経由で実際に生成を行い、返却された usage と各モデルの公開レートからコストを算出した。5つの知見を、それぞれ独立したスイープから得た。

1. コストの主体は画像であり、プロンプトではない。 テキストから画像を生成する場合（テキスト入力→画像出力）、料金の97〜100%は出力トークンが占める。gpt-image-2 で1024²の画像を生成すると入力21トークン・出力196トークン（約$0.0001＋$0.0059）、gemini-2.5-flash-image は入力10トークンだ。書いたプロンプトは誤差の範囲に過ぎないが、それはテキストだからこそ言える話だ。代わりに画像を入力する場合（image-to-image、例：「このマグカップを青くして」）、入力のトークン数は大きく跳ね上がる。

入力は50〜130倍に跳ね上がり、線形にスケールする。gpt-image-2 では参照画像を追加するたびに約1,025トークンが加算される（参照1・2・3枚でそれぞれ1,043・2,068・3,093トークンを計測）。低品質設定では、入力トークンが生成出力の5倍に達する。いずれにせよ原則は同じだ。コストの主体は画像であり、生成するにせよ入力するにせよ変わらない。プロンプトがコストの主体になることはない。本記事の残りはテキスト→画像に絞る。image-to-imageのコスト構造については別途フォローアップ記事で扱う。

2. モデル選択は6倍のレバーになる。 同一の1024²リクエスト、デフォルト品質での比較：

最安値と最高値の間に6.4倍の開きがあり、その差は各モデルが出力するトークン数だけで決まる。

3. 解像度はほとんど影響しない。 gpt-image-2 を1024²から2048²にスイープしても、1枚あたりのコストはほぼ横ばいだった（$0.0060→$0.0121）。出力トークン数はピクセル数に比例しない。gemini-2.5-flash-image はリクエストするサイズに関わらず常に1,290トークンを返した。これは1Kのみ対応であり、size はアスペクト比を変えるだけだからだ（gemini-3 の画像ティアは image_size を反映し、1Kから4Kでコストがほぼ2倍になるが、本記事でコストを計測した 2.5-flash-image はそうではない）。リクエスト単位の固定料金モデルは定義上、解像度に依存しない。現時点では、トークン課金モデルが依然として有利に見える。

4. 品質設定がコストの分岐点になる。 gpt-image-2 を品質ティアでスイープした結果：

出力トークンはlowからmediumで約9倍、lowからhighで約36倍にスケールする。低品質ではトークン課金モデルが最安だが、mediumまたはhighでは固定料金モデル（$0.03〜$0.035）を上回る。分岐点は計算通りの位置、出力トークン約1,000（$0.03 ÷ $30/M）にある。low はその下、medium はその上だ。これは以前の我々の結論を修正するものでもある。「トークン課金は常に最安」という結論は、デフォルトの低品質でテストしていたことによるアーティファクトだった。

同一プロンプト、gpt-image-2、1024²。low / medium / high でそれぞれ196 / 1,756 / 7,024出力トークン、$0.006 / $0.053 / $0.215が課金される。同一解像度で36倍の開きだ。このようなシンプルなプロダクト写真では3つの品質を見分けるのは難しいため、最安ティアで十分なことが多い。quality はデフォルトで high にするのではなく、用途に合わせて設定しよう。

5. 複数画像でプロンプトコストを分散させることはできない。 1回のAPIコールで n 枚の画像を生成しても、プロンプトコストは按分されない。gpt-image-2 では n=4 時に入力トークンが28から112に増加し、長いブランドプロンプトでは499から1,996に増加した。n=1 と n=4 で1枚あたりのコストは同一だった。キャッシュも存在しないため、画像生成においてプロンプトコストを共有する仕組みはない。出力画像1枚ごとに料金が発生し、プロンプトはその都度再課金される。

判断ルール

テキストから画像生成においては、一般的に想定されることではなく、品質が判断の鍵となります。

• 低品質 / ドラフト / サムネイル品質: トークン×品質モデル（gpt-image、約$0.006〜$0.012）。解像度が約2Kまでであれば、どの解像度でも最安値。
• 中品質 / 高品質: リクエスト単位の定額制（seedream / qwen、$0.03〜$0.035）。トークン課金では費用が膨らみ（検証では$0.05〜$0.43）、定額制の方が安くかつ品質に依存しない。
• gemini（デフォルト1Kで約$0.039）がコスト最適な選択肢になることはほとんどない。 低品質ではgpt-imageに、中品質・高品質ではリクエスト単位の定額制に下回られる。qualityの調整ダイヤルがなく、出力品質のためにProティアや高いimage_sizeを選ぶことになるが、価格面での優位性はない。
• 解像度変更によるコスト変動は同一品質ティア内で約2倍程度であり、 選択を覆すほどではない。選択を覆すのは品質だ。
• n>1、キャッシュ、バッチ処理はいずれも1枚あたりのコストを下げない。 共有できるものが何もない。
• 画像から画像への変換: デフォルトは定額の画像単位課金。 参照画像は入力であり、トークン課金モデルのみが追加料金を課す（1枚あたり約1,025トークン）。定額モデルは無料で含まれる。編集用途ではseedream / qwenが通常有利。gpt-imageが安くなるのは、参照画像が少ない低品質編集の場合のみ（約5枚で定額価格と交差）、品質や参照画像数が増えると逆転される。

Eコマースが最もわかりやすい例だ。カタログの各商品に対して同じ長いブランドプロンプトを送って商品写真を生成し、その繰り返しプロンプトをキャッシュすることでコストを節約できると想定しているとする。これは2つの理由で失敗する。プロンプトはそもそもコストの主因ではなく（画像がコストの主因）、生成においてキャッシュは機能しない。実際の商品画像は中品質以上であるため、正しい選択は定額の画像単位課金モデルであり、プロンプトがどれだけ繰り返されても安くかつ予測可能だ。

冒頭のセクションで述べた機能上の制約が選択を上書きする場合もある。1回のコールで1枚のみ生成可能なモデル、解像度の下限・上限、データレジデンシーの制限、そしてモデルが公開しているパラメータ（seed、negative_prompt、guidance_scale）などだ。まずコストで選び、次に機能要件を満たしているか確認する。

この数値が信頼できる理由

これらの数値は、各ベンダーの公表レートに対する実際のusageから得られたものであり、推定値ではない。当ゲートウェイにおける画像課金はセッションレスで、2xxレスポンス時のみ確定する（生成失敗時は課金されない）。支出前に最悪ケースのコストを事前チェックし、usageが欠落したレスポンスは$0として無視するのではなく上限値で課金する。原則は他のすべての箇所に適用しているものと同じだ。ベンダーが提示する数値ではなく、コストを信頼する。これはゲートウェイがキャッシュについて嘘をついているか監査する際に用いた手法と同じだ。

まとめ

画像生成は単なる別のエンドポイントのように見えるが、課金単位が変わっている。テキストから画像生成においてレバーはプロンプト（キャッシュなし、バッチ共有なし）でも解像度でもない。品質だ。gpt-imageは低品質で最安値、画像単位の定額制（seedream / qwen）は中品質・高品質で勝り、交差点は出力トークン約1,000付近にある。品質を意図的に設定し、それに合ったモデルを選び、コストを確認する。生成から編集へ移行し参照画像を入力する場合は、入力画像がコストの主因となるため、計算をやり直すこと。

FAQ

プロンプトキャッシュは画像生成コストを削減しますか？ いいえ。生成はステートレスです。usage オブジェクトにキャッシュフィールドはなく、バッチ処理では画像ごとにプロンプトが再課金されます。コストはテキストではなく出力画像に対して発生します。

トークン単価と画像単価、どちらが安いですか？ 品質によって異なります。低品質またはドラフト品質の場合、gpt-image のような quality 調整可能なモデル（約 $0.006〜$0.012）が有利です。中品質または高品質の場合、seedream/qwen のような画像単価の固定料金（$0.03〜$0.035）が有利です。トークン単価では費用がかさむためです。image-to-image の場合はさらに固定料金が有利になります。参照画像が無料で含まれる一方、トークン単価では参照画像1枚あたり約 1,025 トークンが追加課金されるためです。

出典

• OpenAI: Image generation API
• OpenAI: gpt-image per-token pricing
• Google: Gemini API pricing (image output tokens)
• OpenAI: Prompt caching (why it does not apply to image generation)

すべて 2026-06-19 時点で確認済み。金融アドバイスではありません。利用前に最新の料金をご確認ください。

← ブログに戻る