Skip to main content
gpt-image-2、gpt-image-2.5-flare、gpt-image-2.5-sunburstを使って商品画像、広告素材、デザイン案を生成するとき、開発者は次のような悩みに直面することがあります。
  • 同じモデル、同じパラメータなのに、呼び出すタイミングによって結果が違うのはなぜか?
  • 4Kや指定サイズを渡したのに、縮小された1K画像が返るのはなぜか?
  • Maskによる部分編集やquality=highは本当に適用されているのか?最終的に何を基準に課金されるのか?
日常的なAPI呼び出しでは、HTTPステータスが200 OKかどうかを見るだけでは不十分です。画像が生成できること、目的のレイアウトに使えること、費用が透明で予測可能であることの3つを同時に満たす必要があります。 開発者がこれら3モデルの実際の挙動を把握できるよう、BetterTokenはゲートウェイ層で能力に基づくインテリジェントなルーティング、デフォルトパラメータの正規化、不正パラメータの事前遮断、実際に納品されたピクセルに基づく透明な課金を実装しました。本ガイドは2026年10月19日時点の最新テストデータと価格スナップショットに基づき、実際に生成した画像と請求記録を使って、呼び出し方法、得られる結果、モデルに残る客観的な制約を紹介します。
注:本ガイドではgpt-image-2、gpt-image-2.5-flare、gpt-image-2.5-sunburstを扱います。Nano Bananaシリーズはパラメータと課金体系が異なるため、混同を避けるために別途詳しく説明します。

1. 同じモデル・同じパラメータでも結果が異なるのはなぜ?

実際の利用では、同じモデル名の背後にあるサービスノードごとに、実能力や安定性が異なることがあります。基本的な1K画像生成のみをサポートする経路もあれば、2048×2048、さらには3840×2160の高解像度画像を納品できる経路もあります。qualityの値、参照画像編集、Maskマスクへの対応状況もノードによって異なります。 プラットフォームがモデル名だけで単純にリクエストを転送すると、「4Kを指定したのに小さな1K画像が返る」「Maskを渡したらエラーになる」「パラメータを何度も調整する」といった問題が頻繁に起こります。そのため、「APIがパラメータを受け付けたか」と「実際にどのような結果が納品されたか」を分けて検証する厳格なテスト基準が必要です。

2. どのようにテストしたか:「サポート」の判定基準

結論の客観性と信頼性を確保するため、正式版の回帰テストでは22件の標準テストシナリオを設計しました(有効なリクエスト17件で画像18枚を正常に納品し、不正パラメータのシナリオ5件は想定どおり遮断され、課金されませんでした)。さらに、ECでよく使われる商品画像とMask編集のサンプルも生成しました。 検証基準は明確です。
  1. 元ファイルのピクセルをデコード:APIの宣言だけを信用せず、納品された各画像の元ファイルをデコードして幅と高さを読み取り、レスポンスの課金区分とアカウントの実際の引き落とし額を照合します。
  2. サイズが目標を満たすか判定:明示された幅・高さごとに実際のサイズを比較します。実際のサイズが大きければ合格です。いずれか一辺が目標サイズより5%を超えて小さい場合は不合格とします(注:この基準はテスト結果を厳格に評価するためのもので、APIがサイズ未達の有効画像を自動的に破棄するという意味ではありません)。サイズを省略するかautoを指定した場合、固定キャンバスの目標はないものとして扱います。
  3. パラメータの受付と実際の効果を分けて判定:エラーがないことは「パラメータが受け付けられた」ことしか示しません。Maskが厳密な領域分離を実現するか、quality=highに目視できる改善があるかは、最終画像を確認して判定する必要があります。

3. 実測で分かったこと:誤解されやすいパラメータは?

リクエストパラメータ、実際に納品されたピクセル、最終請求額を並べて比較したところ、開発者が誤解しやすい重要な事実がいくつか分かりました。 パラメータ互換性とエラー処理については、次の結果も得られました。
  • デフォルトパラメータの許容性:qualityとsizeを省略する場合、nullを渡す場合、明示的に"auto"を指定する場合のいずれも正常に生成できます。
  • 4Kの正しい指定方法:「4K」は課金区分の概念であり、4096x4096の正方形画像をサポートするという意味ではありません。 4K相当の高解像度画像が必要な場合は、横長サイズの3840x2160を使用してください。
  • 不正パラメータを課金なしで遮断:4096x4096、stream=true、空文字列のquality=""、空文字列のsize=""、n=0を渡したテストリクエストはすべてHTTP 400エラーとなり、一切課金されませんでした。

4. BetterTokenが提供するもの:経路ごとの個別対応は不要

基盤モデルの複雑なサイズ変動やノード間の差異に対応するため、BetterTokenはゲートウェイ層で4つの処理を行います。経路ごとに個別の調整コードを書く必要はありません。
  1. 能力に基づくインテリジェントなルーティング:モデル、目標サイズ(2K/4Kなど)、画像編集/Maskパラメータの有無に応じて、対応能力を持つ利用可能なサービスを自動的に選択します。
  2. 統一インターフェースとパラメータのフォールバック:標準化されたPOST /v1/images/generations(画像生成)とPOST /v1/images/edits(参照画像/Mask編集)インターフェースが、null、auto、省略されたパラメータを自動処理し、不正な入力はゲートウェイ層で直接遮断します。
  3. 実サイズと課金明細を透明に返却:画像データとあわせて、レスポンスボディのbettertoken_image_billingフィールドが、画像の**実際にデコードされた幅・高さ(width/height)、課金区分(billing_resolution)、通貨、決済金額(settled_amount)**を返します。
  4. 2つの重要な概念を明確に区別:
    • Maskパラメータのサポート ≠ ピクセル単位で正確な領域編集:APIでは参照画像とMaskをアップロードして編集できますが、一部の実測結果ではマスク外の保護領域も変更されました。たとえば、幾何図形の二円テストでは、左側の円を透明にして色変更を指示し、右側の円を不透明にして保護するよう指定しましたが、最終的に左右両方の円の色が変わりました。そのため、Maskパラメータの送信には対応していますが、毎回厳密なピクセル単位の領域分離が実現するとは保証しません。
    • qualityパラメータのサポート ≠ 画質向上幅の保証:APIは"auto"や"high"などのパラメータを受け付け、適切にルーティングします。ただし、画像生成には毎回ランダム性があるため、単一サンプルを根拠にhighで必ず何パーセント画質が上がるとは約束しません。
⚠️ 利用開始前に理解しておくべき2つの実際の制約:
  1. 能力に基づくルーティングでも、ピクセルが毎回厳密に固定されるわけではありません:基盤サービスの出力差により、適切なノードにルーティングされても実際の出力ピクセルが変動する場合があります。たとえば本日も、1024x1024のリクエストで1024×936が返った例や、3840x2160のリクエストで3840×2161が返った例がありました。キャンバス比率が業務上きわめて重要な場合は、返却された実際の幅・高さに応じてトリミングや後処理を行ってください。
  2. 1Kリクエストでも最終的に1K課金とは限りません:課金システムは、実際に納品された有効画像の仕様に基づいて区分を決定します。本日、2つの2.5モデル(および一部のgpt-image-2)は1024x1024のリクエストに対して、より多くのピクセルを持つ1254×1254を返しました。システムはこれを2K区分と判定し、該当する料金で課金します。

5. 3モデルの対応状況:どのモデルを呼び、何を指定すればよい?

gpt-image-2、gpt-image-2.5-flare、gpt-image-2.5-sunburstの能力設定と実測範囲は次のとおりです。 注:表中の「今回の実測で納品」は、本日の回帰テストおよび事例生成で画像と請求サンプルを直接取得したことを指します。「ルーティング設定で対応を整合済み」は、プラットフォームで該当能力の経路設定が完了しているものの、本日の回帰テストで全組み合わせを個別に再リクエストしたわけではないことを指します。

6. 実画像のケース2例:実際の仕上がりは?

実際の生成品質を示すため、OpenAI公式の画像プロンプトガイドにある**「明確な被写体 + 素材の質感 + 光の方向 + 構図とアスペクト比 + 除外条件」**という書き方を参考にし、BetterTokenの実際のAPIで次のEC向けケースを生成しました(元の出力を保持し、後処理はしていません)。

ケースA:EC商品撮影、1K / 2K / 4Kのサイズと細部を比較

シーン設計(中国語での構想):
リアルなECスタジオ写真を生成する。コーラルレッドの陶器マグカップ(取っ手は右向き)が薄いグレーの石材カウンターに置かれ、左側に畳んだベージュのリネンクロスがある。カップには白い文字で「BETTER DAY」とはっきり印字されている。左上から柔らかなサイド光を当て、釉薬の微かな反射、リネンの繊維、自然な接地影を残す。カップ全体を中央に収め、背景はシンプルでニュートラルにする。他の物、透かし、追加の文字は入れない。
実際に使用した英語プロンプト:
gpt-image-2(quality="high"、1回につき1枚)を使用し、上記のプロンプトは一切変更しませんでした。プロンプトに「4K」と書いて高解像度に見せるのではなく、sizeパラメータだけで3段階のサイズをリクエストしました。 1. 1024x1024リクエストの元画像(実際の返却サイズ:1254×1254):
GPT Image 2の商品画像:1024×1024をリクエストし、1254×1254が返却
2. 2048x2048リクエストの元画像(実際の返却サイズ:2048×2048):
GPT Image 2の商品画像:リクエストと実際の納品サイズはいずれも2048×2048
3. 3840x2160リクエストの元画像(実際の返却サイズ:3840×2161):
GPT Image 2の横長商品画像:3840×2160をリクエストし、3840×2161が返却
4. 3サイズの画像から対応部分を元寸法で切り出して比較(カップの文字と素材の細部):
実測所見:
  • 高い描写完成度:3枚とも、コーラルレッドの釉薬の反射、右側の取っ手、薄いグレーの石材カウンター、ベージュのリネン繊維、読みやすい白い「BETTER DAY」の文字が表現されています。
  • 独立サンプリングによる違い:生成ごとに独立したサンプリングが行われるため、カップの縦横比、文字の太さ、布の折り方には自然な違いがあります(たとえば4K横長画像では文字が2行に配置されています)。切り出し画像は各画像の実際の細部を示すものであり、構図を厳密に揃えた光学的な鮮明度テストではありません。
  • 課金の境界を直接確認:最初のリクエストは1024x1024でしたが、高解像度の正方形画像1254×1254が実際に納品されたため、2枚目の2048×2048画像と同じ**2K区分(¥0.11)**で課金されました。

ケースB:商品の部分的な色変更、Maskの実際の効果と制約

ケースAの最初の商品画像(1254×1254)を入力元画像とし、同じサイズのアルファチャンネル付きMask画像mask-mug.pngを作成しました。カップ本体の多角形領域だけを透明(再描画可能)にし、取っ手、飲み口の内側、背景は不透明(保持対象)にしています。カップの文字は透明領域内にあり、プロンプトでは保持するよう指示しています。
Mask範囲の図:黒は透明で変更可能な領域、白は不透明で保持する領域
(注:上図は白黒の可視化イメージです。黒は変更可能な領域、白は保持する領域を表します。APIに実際にアップロードするのは、透明チャンネルを持つmask-mug.pngです。) シーン設計(中国語での構想):
透明なMask領域内にあるコーラルレッドのカップ本体だけを濃いネイビーブルーに変更する。陶器の質感、光、反射は維持する。白い「BETTER DAY」の文字、赤い取っ手、リネンクロス、カウンター、背景、全体の構図は変えない。物を追加・削除しない。
実際に使用した英語プロンプト(モデル:gpt-image-2、size="2048x2048"、quality="high"):
実際の編集結果(2048×2048、38.51秒、料金¥0.11):
GPT Image 2のMask編集結果:本体は濃い青、取っ手は赤のままだが、飲み口の内側も色が変わった
保護領域を越えて変更された部分の比較:
反例:回帰テストでの「2つの円の色が変わった」サンプル(Mask受付 ≠ 正確な領域分離)
実測所見(制約を明示):
  • 色変更の主目的は達成:マグカップ本体の外側は濃いネイビーブルーに変わり、陶器のハイライトも保たれました。Mask外の赤い取っ手、左側のリネンクロス、背景は全体として維持され、Mask内の「BETTER DAY」の文字も読み取れます。
  • 厳密なMask境界は不合格(領域外への変更あり):飲み口の縁と内側をよく見ると、もともと不透明の保護領域だったコーラルレッドの部分も濃い青に変更されています。さらに極端な幾何図形の「2つの円の色変更」テストでは、マスクされていない右側の円も色が変わりました。
  • 利用上の推奨事項:参照画像とMaskをアップロードする際は、両者のキャンバスサイズを一致させ(変更箇所は透明、保持箇所は不透明)、プロンプトでは「変更する内容」と「保持する内容」の両方を明記してください。ブランドロゴ、パッケージの小さな文字、厳格なエッジ要件を含む工業・商業用途の画像では、生成後に拡大して保護領域の境界を必ず確認してください。

7. 価格と実際の利用コスト:最終的な課金額は?

BetterTokenは透明な価格設定を重視しています。以下は2026年10月19日時点の公開価格スナップショットです(CNYは企業向け人民元アカウント、USDは通常の米ドルアカウントに適用されます。両者は独立した価格であり、リアルタイム為替レートで換算されません)。 上記の公開単価で、生成した画像100枚すべてが実際に対応する課金区分で納品されると仮定した場合、100回呼び出しの参考コストは次のとおりです(算術上の推計)。
💡 予算計画で重要なのは、「リクエストパラメータ」ではなく「実際に納品された課金区分」を基準に見積もることです! 上記の実測例のとおり、本日flare、sunburst、gpt-image-2に1024x1024(1K)をリクエストした一部の呼び出しでは、1254×1254の画像が納品されました。この場合、システムは実際の納品物を2Kと判定し、1Kの¥0.035ではなく¥0.15または¥0.11を請求します。flareへの1024x1024リクエスト100回がすべて1254×1254で返った場合、現在の単価で100枚の費用は**¥15.00(算術上の推計)**です。 また、課金区分の判定では目標サイズと妥当な誤差しきい値(例:3840×2159は通常4K、1536×1024は1K)を総合的に考慮します。「長辺が1024を超えるか」だけで業務側に独自の再計算ロジックをハードコードしないでください。決済の基準には、必ずレスポンスボディのbettertoken_image_billingフィールドを使用してください。

表面的な「1枚あたりの安さ」だけでは不十分なのはなぜ?

複数プラットフォームの画像APIコストを比較する際、開発者は次の3つの費用を考慮してください。
  1. 実際の出力が目標サイズに達して初めて価格を比較できます:「4K対応、しかも非常に安い」とうたっていても、実際には縮小された1024画像しか返さないリクエストは、高解像度画像が必要な本番環境では使えません。4K価格の比較対象として有効ではありません。
  2. 失敗とやり直しのコストを含める:今回の不正パラメータテストは無料でした。有効な画像が納品されても結果に満足できず、再生成する場合は新しいリクエストとなるため、別途予算に含める必要があります。本ガイドで示した商品画像とMaskのケース画像4枚(生成3枚 + 編集1枚)は、それぞれ1回のリクエストで納品されました。Maskサンプルには上記のとおり領域外の色変更がありました。単価は¥0.11、¥0.11、¥0.13、¥0.11で、4枚の実費合計はわずか¥0.46です。請求記録とアカウントの引き落とし額は完全に一致しました。経路が不安定だったり、パラメータに互換性がなかったりして再生成が必要になると、1枚あたりの表示価格が低くても、使える素材を1枚得るための実質的な総コストは増える可能性があります。
  3. 隠れた開発・調整コストを削減:BetterTokenは、統一されたパラメータ規則、能力に基づくインテリジェントなルーティング、実ピクセルと課金フィールドのリアルタイム返却により、サービスごとの個別対応やサイズ・費用情報の集計に必要な開発作業を減らします。

8. すぐにコピーできる呼び出し例

BetterToken API Keyを環境変数BETTERTOKEN_API_KEYに保存すれば、以下のコマンドをコピーしてすぐに呼び出せます。

例1:JSONリクエストで高解像度の商品画像を生成(POST /v1/images/generations)

以下の例では、gpt-image-2を呼び出して2048x2048の高解像度商品画像を1枚生成します(modelはgpt-image-2.5-flareまたはgpt-image-2.5-sunburstに置き換えられます)。
  • サイズ指定に関する注意:4K横長画像が必要な場合は"size"を"3840x2160"に変更してください("4096x4096"は使用しないでください)。現在有効なサイズは、幅と高さがともに16の倍数、長辺が3840以下、長辺と短辺の比率が3:1以下、総ピクセル数が655,360〜8,294,400である必要があります。
  • ファイル形式の判別:リクエストで"output_format": "png"を指定しても、一部の基盤ノードがJPEG形式のバイナリを返すことがあります。画像を保存・処理する際は拡張子を固定せず、ヘッダー(Magic Bytes)から実際の画像形式を判定してください。

例2:Multipartで参照画像とMaskを使った部分編集(POST /v1/images/edits)

元画像product-1k-0.pngと、同じサイズの透明Maskmask-mug.pngを用意します(通常の参照画像編集だけを行う場合は、-F "mask=..."の行を削除してください)。

例3:実際の納品ピクセルと課金情報を読み取る(レスポンス構造と解析コード)

BetterTokenのレスポンスボディには、標準のdata[].b64_jsonに加えて、拡張フィールドbettertoken_image_billingが含まれます。
以下のPythonコードを使うと、画像のデコード、実際の形式の判別、サイズの読み取り、請求額の照合を一度に行えます。

参考資料: