> ## Documentation Index > Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt > Use this file to discover all available pages before exploring further. # GPT-Image-2 画像生成/編集 > OpenAIのフラッグシップ画像生成モデル gpt-image-2。ネイティブで2K/4K解像度に対応し、高忠実度な参照画像を自動適用、同一ティアで20〜30%安価です。テキストから画像生成、参照編集、マルチ画像融合、マスクインペインティングをサポートします。 すべての画像 API は **同期型** です — ポーリングするための task ID はなく、クライアントが切断されると、リクエストは課金されたまま結果は失われます。このモデルでは十分に長いタイムアウトを設定してください。[画像 API の基本とベストプラクティス](/ja/api-capabilities/image-api-best-practices)をご覧ください。 ## 概要 **gpt-image-2** は OpenAI の最新フラッグシップ画像生成モデルで、`gpt-image-1.5` のアップグレード版です。主なアップグレード: **有効な任意の解像度に対応（2K / 3840×2160 4K を含む）**, **参考画像に対する自動ハイフィデリティ**, **同じティアで 20-30% 安価**。APIYI のゲートウェイは OpenAI Images API と完全互換です。公式 OpenAI SDK の `base_url` をここに向けるだけで、コード不要で直接接続できます。 **🎨 主な特長**: 有効な任意の解像度にネイティブ対応（最大 3840×2160 4K）+ 参考画像編集時の自動ハイフィデリティ + 同じサイズと品質で 1.5 より 20-30% 低コスト + 中国語プロンプトのネイティブ対応。**サイズ/品質を厳密に制御する必要がある本番環境、OpenAI 公式 API と完全一致が必要な場合、または 4K 出力が必要なケースに最適です**。 `/v1/images/generations` — テキストプロンプトから画像を生成し、サイズ / 品質 / output\_format を制御できます。 `/v1/images/edits` — 参考画像を multipart でアップロード（最大16枚）し、編集/融合指示を指定できます。マスクのインペインティングにも対応しています。 ## APIYI の GPT-image-2 公式リレーを選ぶ理由? OpenAI の公式チャネルを基盤に、**信頼性**、**コスト**、**統合のしやすさ**の面でエンタープライズ本番ワークロード向けに徹底最適化されています: OpenAI の公式リレーを厳格に経由し、リクエストとレスポンスは **OpenAI公式と100%同一** です: フィールド、エラーコード、モデル挙動もすべて同じです。ロスレス品質で、サイレントな書き換えはありません。 OpenAI の **Tier ベースの RPM / TPM 上限** に縛られません。エンタープライズ規模のトラフィックも線形にスケールし、バッチ生成やピーク負荷のシナリオも容易に対応できます。 デフォルトの単価は OpenAI の公式価格と同じです。当社の [チャージボーナスイベント](/ja/faq/recharge-promotions) と組み合わせることで、**最大15%オフ** になり、長期的なコストを大きく抑えられます。 **海外サーバーやプロキシは不要** です。国内データセンター、自宅回線、海外ノードのいずれからでも `api.apiyi.com` に直接接続でき、安定したレイテンシで、越境向けの再設計も不要です。 リバースエンジニアリング版 [`gpt-image-2-all`](/ja/api-capabilities/gpt-image-2-all/overview)（\$0.03/image の一律料金）や、コスト重視の [Nano Banana Pro / 2](/ja/api-capabilities/nano-banana-2-image/overview) へシームレスに切り替え可能です — シナリオに応じて柔軟に使い分けられます。 当社チームは本番環境での画像生成導入を得意としており、モデル選定、チューニング、統合に深い知見があります — PoC から本番まで、エンドツーエンドでサポートします。 ## 主な機能 有効な出力サイズならどれでもサポートします。プリセットは 1K / 2K / 3840×2160 4K をカバーします。カスタムサイズは基本制約を満たすだけで十分です（辺は16の倍数、比率は 3:1 以下）。 参照画像編集では自動的に高精細が有効になります。ディテール、キャラクターの一貫性、テキスト保持が大幅に向上します。`input_fidelity` は**渡さないでください**（エラーになります）。 1024×1024 の高品質は、1.5 の \$0.25台から \$0.211/画像に下がります。2K/4K は token ベースの課金ですが、同様に下がります。長期コストは明らかに低くなります。 中国語の prompt をネイティブにサポートします。看板、ポスター、UI スクリーンショットにおける中国語/英語テキストのレンダリングが安定しています。細かい文字が `high` 品質でぼやけることはほとんどありません。 `image[]` 配列は最大16枚の参照画像を受け付けます。prompt で「image 1 / image 2 / image 3」を使うと、アップロード順で参照できます。 アルファチャンネル付きのマスクをアップロードします。透明部分がインペイント対象、不透明部分が保持対象です。 png（デフォルト）/ jpeg / webp をサポートします。jpeg/webp では `output_compression` を設定してファイルサイズを調整できます。 `base_url` を `https://api.apiyi.com/v1` に向けて、公式 OpenAI SDK で直接呼び出せます — コード不要で移行できます。 ## 料金 APIYIの`gpt-image-2`（デフォルトグループ）は**OpenAIの公式のリスト価格と完全に一致します**。割引は代わりにチャージ特典によるものです。**\$100 をチャージすると 10% のボーナス、最大 20% です**。📖 [チャージ特典について学ぶ](/ja/faq/recharge-promotions)。 ### トークンレート（OpenAI の価格表と同じ） トークン課金制 — 1 回のリクエスト = 入力テキスト + 入力画像 + 出力画像 token: | 課金項目 | 価格（1M tokens あたり） | 備考 | | ------- | ----------------------- | ------------------------------------------------------ | | テキスト入力 | \$5.00 | prompt のテキスト部分 | | 画像入力 | \$8.00 | 編集／融合リクエスト内の参照画像。Vision ルールに従って token 化されます | | 画像出力 | \$30.00 | **最も大きいコスト** — token 数はサイズ × 品質で決まります | | キャッシュ入力 | テキスト \$1.25 / 画像 \$2.00 | 設定はされていますが、同時実行数が高い場合はヒット率が限られます — [FAQ](#faq) をご覧ください | **なぜ画像入力のほうが高いのですか？** 画像入力は \$8.00 / 1M tokens で、テキスト入力の \$5.00 / 1M の **1.6 倍** です（これは APIYI の上乗せではなく、OpenAI 自身の標準価格です）。そのため、編集 / 複数画像融合リクエストは、単純なテキストから画像への生成よりも入力側のコストがかなり高くなります。参照画像は Vision ルールによって大量の画像 token に token 化され、それぞれの token はすでにテキスト token より 60% 高く設定されています。 ### 1枚あたりのコスト参照（公式表） 1K プリセットサイズにおける一般的な 1 枚あたりのコスト: | 品質 | 1024×1024 | 1024×1536 | 1536×1024 | | ------ | --------- | --------- | --------- | | Low | \$0.006 | \$0.005 | \$0.005 | | Medium | \$0.053 | \$0.041 | \$0.041 | | High | \$0.211 | \$0.165 | \$0.165 | **料金の注意点**: * 単価は OpenAI の一覧と一致します。[チャージ ボーナス](/ja/faq/recharge-promotions)（\$100 で 10%、最大 20%）を重ねると、実質コストは直接利用より低くなります * 2K / 4K には固定の 1 枚あたり価格がなく、実際の input + output token に基づいて課金されます * 編集リクエストは、高忠実度が強制されるため、テキストから画像生成より input token がかなり多くなります * ストリーミング（`stream: true` + `partial_images: N`）では、部分ごとに output image token がさらに 100 追加でかかります * 同じサイズと品質の `gpt-image-1.5` と比べると、`gpt-image-2` は約 20-30% 安くなります ### 複数の入力画像が価格に与える影響（2026年7月検証済み） よくあるお客様の質問: 「参照画像ごとに一律料金なのか、それとも大きい画像ほど消費する token が増えるのか？」答えは、**どちらも影響し、画像枚数は厳密に線形で加算されます**。`gpt-image-2` はすべての入力画像を強制的な高忠実度（`input_fidelity` は調整できません。渡すと 400 が返ります）で処理し、各参照画像はその寸法とアスペクト比に基づいて画像 token に変換されます。実測値（edits エンドポイント、2026-07-15）: | 参照画像の入力 | `image_tokens` | 入力コスト (\$8/M) | | ------------------- | --------------------- | ------------- | | 1 × 512×512 | 1024 | ≈\$0.0082 | | 1 × 1024×1024 | 1024 | ≈\$0.0082 | | 1 × 2048×2048 | 1521 | ≈\$0.0122 | | 1 × 4096×4096 | 1521 | ≈\$0.0122 | | 1 × 1024×1536 (縦向き) | 1536 | ≈\$0.0123 | | **4 × 1024×1024** | **4096 (= 4 × 1024)** | ≈\$0.0328 | 3つの目安: 1. **個数は厳密に線形です**: N 枚の参照画像 ≈ N × 1枚分の token。1024² の参照画像 16 枚 ≈ 16384 tokens ≈ \$0.13 — これは `high` の出力 1 回分（\$0.211）と同じ桁なので、複数画像の融合ではもはや無視できません。 2. **サイズには下限と上限の両方があります**: 1024² 以下の正方形画像はすべて 1024 tokens として課金されます（512 に縮小しても **何も節約できません**）。2048² と 4096² はどちらも 1521 tokens です（大きすぎる画像は変換前に縮小されるため、**上限がかかります**）。参照画像 1 枚あたりは、アスペクト比込みでおおむね 800〜1600 token の範囲に収まります。 3. **token 数はファイルサイズではなくピクセル寸法で決まります**: 1.5MB まで圧縮するとアップロードの安定性と速度は向上しますが、**画像 token は減りません**。逆に、50MB のオリジナルをアップロードしても請求額が跳ね上がることはありません（上限が適用されます）。 コスト感覚: `low` の出力（196 tokens ≈ \$0.006）では、参照画像 1 枚の入力コスト（≈\$0.008）のほうが実際には出力より高くなります。`high` の出力（≈\$0.211）では、参照画像 1 枚は約 4% にすぎません。**出力サイズと品質は、常に価格を左右する最大の要因です** — 参照画像の枚数はその次です。 ### 2K/4K のコスト見積もり（ピクセル比による外挿、⚠️ 公式の固定価格ではありません） OpenAI は 1K サイズについてのみ、画像ごとの固定価格表を公開しています — **2K/4K のサイズ別価格については公式のものがありません**。以下の表は、予算見積もり目的のみで、上の 1K の公式レートを基準にピクセル数でスケーリングした、APIYI 独自の外挿です。 | 品質 | 2048×2048（2K 正方形） | 2048×1152（2K 横長） | 3840×2160 / 2160×3840（4K） | | -- | ----------------- | ---------------- | ------------------------- | | 低 | ≈\$0.024 | ≈\$0.008 | ≈\$0.026 | | 中 | ≈\$0.212 | ≈\$0.062 | ≈\$0.216 | | 高 | ≈\$0.844 | ≈\$0.248 | ≈\$0.870 | **これは見積もりであり、公式の価格表ではありません。** 方法: 同じアスペクト比の 1K の公式行を基準値として取り、その後、対象サイズのピクセル数をその基準値に対して線形にスケーリングします（たとえば、2048×2048 は 1024×1024 の 4 倍のピクセル数なので、見積もりコストも 4 倍になります）。実際の出力画像 token 数は、コンテンツの複雑さに基づいてモデルが動的に決定するため、厳密には線形ではありません。そのため、**実際のレスポンスにある `usage.output_tokens` を唯一の基準として扱ってください**（下の「各呼び出しの実際の token 数を確認する方法」を参照してください）。`high` 品質で 2560×1440 を超えるサイズは、引き続き公式の実験的な階層であるため、そこでは見積もりの精度がやや低くなる場合があります。 ### SaaS サブスクリプション / クレジットベース課金との違い 画像生成ツールのベンダーは、通常 2 つの方式のどちらかで課金します。 * **月額サブスクリプションプラン**: 「月間 N 枚」のクォータに対して定額の月額料金を支払う方式です。このクォータは **過剰販売前提** を織り込んだ価格設定になっており、ベンダーは大半のユーザーが付与上限を使い切らないことを前提にしています。そのため、広告される「1 枚あたりのコスト」は、単にプラン料金をクォータ上限で割ったものにすぎず、実際に各画像を生成するのにあなたにとって本当にいくらかかるかを示すものではありません。 * **クレジット / ポイントベースの計測**: 品質やサイズの異なるジョブを、正体の分かりにくい「クレジット」に変換します。これは実態としては従量課金であり、実際の token 消費を隠すクレジット単位の背後に再パッケージされているだけです。 APIYI は **公式リレー + 実際の token 従量課金** モデルで動作します。プランのクォータもクレジットの抽象化レイヤーもありません。各呼び出しのコストは、単純にその実際の入力 / 出力 token 数 × 公式レートです。サブスクリプションにありがちな過剰販売や、上限超過時にスロットリングされるような動きは一切なく、呼び出しごとに正確に算出できます。 従量課金のトレードオフは、サブスクリプションのような毎月固定額の確実性ではなく、自分で使用量を見積もり / 監視する必要があることです。その代わり、使った分だけ支払えばよく、遊休分の無駄はありません。以下では、各呼び出しの実際の token 数をレスポンスから直接取り出し、その計算を自分で行う方法を説明します。 ### 各呼び出しの実際の token 数を確認する方法 `/v1/images/generations` と `/v1/images/edits` はどちらも `usage` フィールドを返し、**image input tokens と text input tokens は別々のフィールドとして返ります** — 見積もりは不要で、各呼び出しの正確なコストはそれらをそのまま読むだけで分かります。以下は、参照画像 1 枚を含む実際の edit リクエストから取得した完全な `usage` オブジェクトです（ライブ取得）: ```json theme={null} { "data": [ { "b64_json": "..." } ], "usage": { "input_tokens": 848, "input_tokens_details": { "image_tokens": 832, "text_tokens": 16 }, "output_tokens": 196, "output_tokens_details": { "image_tokens": 196, "text_tokens": 0 }, "total_tokens": 1044 } } ``` | フィールド | 意味 | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `usage.input_tokens_details.text_tokens` | prompt テキストで消費された token。課金は \$5.00 / 1M | | `usage.input_tokens_details.image_tokens` | Vision のルールに従って参照画像が変換される token 数。課金は \$8.00 / 1M。参照画像のない通常のテキストから画像への生成では常に 0 | | `usage.input_tokens` | 上記 2 つのフィールドの合計 | | `usage.output_tokens` | `quality × size` によって決まる生成画像用の token 数 — これは**最も大きなコスト**で、課金は \$30.00 / 1M。2K/4K リクエストでは特に注目すべき数値です（`output_tokens_details.image_tokens` はこれを反映し、`text_tokens` は常に 0 です） | | `usage.total_tokens` | input + output の合計 | セルフサービスのコスト式（正確）: ``` cost ≈ input_tokens_details.text_tokens × \$5.00 / 1,000,000 + input_tokens_details.image_tokens × \$8.00 / 1,000,000 + output_tokens × \$30.00 / 1,000,000 ``` 過去の呼び出しの実際の token 使用量と課金の詳細を確認するには、コンソールの「ログ」ページを確認してください: 📖 [呼び出しログを表示する方法](/ja/faq/call-logs) — ログ詳細ビューには text-input / image-input / output の価格が token 数とともに表示され、API の `usage.input_tokens_details` / `usage.output_tokens_details` と一致します。Responses API の `image_generation` ツールは、同じように token 数を `usage.input_tokens` / `usage.output_tokens` で報告します。詳細は [Responses ツール統合](/ja/api-capabilities/gpt-image-2/responses-image-tool) を参照してください。 ## グループ設定 `gpt-image-2` 公式リレーチャネルでは2つのグループを提供しています。ダッシュボード → **Token 設定 → グループ** で切り替えてください: | グループ | レート倍率 | 使用タイミング | | ------------------ | ----- | ----------------------------------------------------------------------- | | `Default` | 1.0x | OpenAI の定価と同じです — 容量に空きがあるときの第一候補です。ピーク時間帯には 429 / 同時実行数の逼迫が発生する場合があります | | `image2Enterprise` | 1.2x | デフォルトグループが逼迫しているときの安定したフォールバックです — 容量優先です | **なぜ 1.2x なのですか？** これは「1回 \$3,000 チャージのプロモーションで 20% ボーナス込み ≈ OpenAI の定価」を基準に調整されています。APIYI はこのルートでは利幅を取りません（税コストを除く）し、純粋な供給優先チャネルとして運用しています。デフォルトグループが不安定な場合は、スパイクをやり過ごすために token を `image2Enterprise` に切り替えてください。 Token 作成画面: 課金モード = 従量課金優先、グループ = image2Enterprise (1.2x)、高速な定価の GPT-image-2 エンタープライズ グループ 📖 安定性チェック（最近の呼び出しログ）: [/en/live/2026-04/image2-enterprise-stable](/en/live/2026-04/image2-enterprise-stable) ## 技術仕様 | Dimension | Value | | ---------------- | --------------------------------------------------------------------------------------- | | **モデル名** | `gpt-image-2` | | **速度** | 約120秒（4K高品質では約2分に近づきます） | | **出力解像度** | 有効な任意サイズ（1K/2K/4K、最大3840×2160） | | **品質レベル** | `auto` / `low` / `medium` / `high` | | **出力形式** | `png`（デフォルト） / `jpeg` / `webp` | | **中国語の prompt** | ✅ ネイティブ対応 | | **1回の呼び出し** | 1枚の画像（`n=1`） | | **参照画像上限** | 16（`image[]`） | | **画像ごとのサイズ上限** | multipart file: 各50MB未満（png/jpg/webp）；base64 data URL: フィールド上限は約20MiB、元画像は15MB以内にしてください | | **マスクインペインティング** | ✅ 対応（アルファチャンネル必須、PNGは4MB未満） | | **透過背景** | ❌ 未対応（`background: transparent` エラー） | | **応答フィールド** | `b64_json`（**生の base64、プレフィックスなし**） | ## エンドポイント | エンドポイント | 用途 | Content-Type | | ----------------------------- | ---------------------------- | --------------------- | | `POST /v1/images/generations` | テキストから画像 | `application/json` | | `POST /v1/images/edits` | 参照編集 / 複数画像融合 / マスクインペインティング | `multipart/form-data` | **ドメインの選択**: `api.apiyi.com` が主要ドメインです。`b.apiyi.com` / `vip.apiyi.com` のような他のゲートウェイドメインも同様に動作します。 ## サイズ参照 ### プリセットサイズ | size | 意味 | ピクセル | | ----------- | ----------- | ------ | | `auto` | 自動調整（デフォルト） | モデルが決定 | | `1024x1024` | 正方形 1:1 | 1K | | `1536x1024` | 横長 3:2 | 1K | | `1024x1536` | 縦長 2:3 | 1K | | `2048x2048` | 正方形 1:1 | 2K | | `2048x1152` | 横長 16:9 | 2K | | `3840x2160` | 横長 16:9 | 4K | | `2160x3840` | 縦長 9:16 | 4K | ### カスタムサイズの制約 `gpt-image-2` は、以下をすべて満たす **任意の有効なサイズ** を受け付けます: 1. **最大辺 ≤ 3840px** 2. **両方の辺が 16 の倍数** 3. **アスペクト比 ≤ 3:1** 4. **総ピクセル数 ∈ \[655,360, 8,294,400]**（約0.65MP～約8.3MP） **有効な例**: `1600x1200`, `1792x1024`, `2048x1536`, `3200x1800` **無効な例**: `1000x1000`（16 の倍数ではない）, `4000x4000`（最大値を超過）, `3840x1000`（比率 > 3:1） `2560×1440` を超える出力（約3.69MP）は公式に **実験的** とされ、品質が変動する場合があります。本番環境では、`2048x1152` / `2048x2048` / `3840x2160` のようなプリセットを推奨します。 ## 品質リファレンス ### 利用可能なティア | quality | 意味 | 注記 | | -------- | ------------- | ------------------------------------------ | | `auto` | 自動（**デフォルト**） | `quality` が省略されたときに使われる値です — モデルがティアを選択します | | `low` | 低品質 | 最速で最も安価 — 下書き / バッチ向けです | | `medium` | 中品質 | 日常利用 / 最終出力向けのバランスのよい選択です | | `high` | 高品質 | テキスト、細かな質感、印刷向け — レイテンシーとコストが最も高くなります | **デフォルトは `auto` であり、`medium` ではありません。** `quality` を省略することは `"quality": "auto"` を指定するのと同じです。モデルが品質ティアを自動選択しますが、**OpenAI はそれが `medium` に対応することを保証しません**。`auto` に解決されるティアは予測不能で、コスト、レイテンシー、課金の安定性に直接影響します。**コストを制御し予測可能性を確保したい場合は、`auto` に頼らず、`low` / `medium` / `high` を明示的に指定してください。** **従来の DALL·E の値 `standard` / `hd` は指定しないでください。** `quality` は公式の列挙値 `low` / `medium` / `high` / `auto` の4つだけを受け付けます。従来の DALL·E 3 の値 `standard` / `hd` はバックエンドチャネル間で挙動が一貫せず、すぐに 400（`invalid_value`）で失敗することもあれば、黙って無視されてリクエストが `auto` で実行されることもあります（コストは予測不能です）。必ず4つの公式値のいずれかを明示的に指定してください。 **価格への影響が最も大きいのは `quality` で、`size` よりも大きいです。** 出力画像の token 数は `quality × size` によって決まりますが、`quality` のほうがはるかに重要です。同じサイズでも、`low` から `high` に変えるだけで、1枚あたりのコストは **30×以上** 変わる可能性があります（上の「1画像あたりのコスト」表を参照してください。1024×1024 は `low` \$0.006 から `high` \$0.211 までの範囲です）。まず `quality` でコストを見積もり、そのあとで `size` の影響を加味してください。 ## ベストプラクティス **オンボーディングのヒント: まず`low`でAPIを動かし、その後スケールアップする** 新規導入者がいきなり`quality=high` + 高解像度に進み、**≈ 235秒（約4分）/画像**も待たされて、APIが止まっているのではと疑うケースを見てきました。`high`モードは推論の複雑さが最も高く、4Kでは5分近くかかることもあります。**本番投入前に、まず`quality=low`でエンドツーエンドに統合してください**（認証、SDK、パラメータ、タイムアウト、エラーハンドリングを含む） 。そのうえで、実際の品質要件に応じて`medium` / `high`へ上げてください。 新しい統合では、**`quality=low` + プリセットサイズ**から始めて、一連の呼び出しの流れ（認証、パラメータ、タイムアウト、エラーハンドリング）を検証してください。`low`は`high`より数倍高速なので、長いレイテンシーに隠されずに機能上の問題をすぐに見つけられます。 8つの公式プリセットは、安定した速度と品質に調整されています。カスタムサイズは、本当に特殊なアスペクト比の場合にのみ使ってください。 下書き / バッチ → `low`; 日常 / 最終 → `medium`; テキスト、細かなテクスチャ、印刷 → `high`。**`low` ↔ `high` は単なる視覚的忠実度の違いではなく、推論の複雑さが一段階変わることでもあります**。そのため、レイテンシーもそれに応じて変動します。 最終表示では、`output_format=jpeg` + `output_compression=85` は PNG より高速で、サイズもおよそ半分です。 テキスト描画は大きな強みですが、下位ティアではまだぼやけることがあります。看板やポスター用途では`quality=high`を固定してください。 各画像は最大50MB（実運用では1.5MB以内に圧縮してください）；PNG/JPEG/WebPに対応；最大16枚；prompt内で「image 1 / image 2」の順に参照します。 レイテンシーを左右する2つのパラメータは **`quality`** と **`size`** です。特に `quality` が重要です。ティアごとにクライアントのタイムアウトを設定してください。 | 品質 | 推奨クライアントタイムアウト | 実測レイテンシ | | -------- | -------------------- | -------------------------- | | `low` | ≥ **120秒** | 通常10〜40秒 | | `medium` | ≥ **240秒** | 通常30〜90秒 | | `high` | ≥ **600秒**（セーフティネット） | 2K/4Kは3〜5分。235秒超のロングテールを確認 | **`high`モードでは、キューイング、ロングテールのばらつき、上流側のジッターを吸収できるよう、600秒をセーフティネットのタイムアウトとして設定してください**。UIで進捗を表示し、サーバー側にタスクキューを用意することも検討してください。 `gpt-image-1.5`から移行する場合: `input_fidelity`は削除してください（高忠実度を強制するため、渡すとエラーになります）；`background: transparent`は使わないでください（未対応です）。 ## エラーとリトライ | ステータス | 意味 | 推奨アクション | | ------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `400` | 不正なパラメータ（サイズ制約違反、未対応フィールドなど） | サイズ制約を確認してください; **`input_fidelity` / `background: transparent` を送らないでください**; 編集エンドポイントでの `invalid_image_file` は通常 MPO のスマホ写真です — [よくある質問](#faq) を参照してください | | `401` | 無効な token | Bearer Token を確認してください | | `403` | コンテンツモデレーションによるブロック | prompt を調整するか、`moderation: low` を渡してください | | `429` | レート制限 / 残高不足 | 指数バックオフ | | `5xx` | ゲートウェイ / バックエンドエラー | 1〜2回再試行してください | | Timeout | ロングテール | `quality`ごとにクライアントのタイムアウトを段階的に設定: `low` ≥ **120s** / `medium` ≥ **240s** / `high` ≥ **600s**（high + 2K/4K の実行は 3〜5 分; ロングテールは 235+ 秒で観測） | **クライアントへの推奨事項**: * `quality`ごとにリクエストのタイムアウトを段階的に設定: `low` ≥ **120 seconds** / `medium` ≥ **240 seconds** / **`high` ≥ 600 seconds**（安全策 — 3〜5 分の観測あり; 120s/360s 前後に設定すると誤タイムアウトが多発します） * **まず `quality=low` と統合し**、その後、実際の品質要件に応じて `medium` / `high` へ引き上げてください * 5xx とタイムアウトでは指数バックオフで再試行してください（2回のリトライを推奨） * サポート用に `x-request-id` ヘッダーをログに記録してください ## FAQ **はい**. `gpt-image-2` は **生の base64 文字列**（プレフィックスなし）を返し、`gpt-image-2-all` とは異なります。クライアント側のパターンは 2 つです。 * **ファイルに書き込む**: `base64.b64decode(b64_str)` → ディスクに書き込む * **ブラウザで描画**: `img.src = 'data:image/png;base64,' + b64_str`（手動で先頭に付与） 1.5 時代の「すでにプレフィックス付き」の挙動を前提にしているコードだと、壊れた data URL になってしまいます。ここは明示的に処理してください。 `gpt-image-2` は参照画像に対する高精細処理を**強制**し、もはや `input_fidelity` を受け付けません。1.5 から移行する場合は、このフィールドを削除するだけで十分です。代替は不要です。 `gpt-image-2` は `background: transparent` を **サポートしていません**（エラーになります）。回避策は 2 つあります。 * `background` を `opaque` に設定する（または省略する）うえで、PIL / sharp / オンラインツールを使って自分で透過部分を抜き出す * 透過が本当に必要なシナリオでは、一時的に `gpt-image-1.5` にフォールバックする 1 画像（`n=1`）です。N 枚必要なら、N 件の並列リクエストを送ってください。各リクエストは個別に token 課金されます。 高解像度と高品質では出力画像 token が増えるため、当然ながら時間がかかります。実際の顧客統合では、**`quality=high` + 高解像度で 1 枚あたり約 235 秒（約 4 分）かかるケース**を確認しており、`3840×2160` + `high` の長尾では 5 分近くまで伸びることがあります。推奨事項: * **まず `quality=low` で統合する** ことで呼び出しの流れを検証し、実際の品質要件に応じて上げていく * クライアントのタイムアウトを品質ごとに分ける: `low` ≥ **120s** / `medium` ≥ **240s** / **`high` ≥ 600s**（安全策） * UI で「生成中」の進捗を表示する * 4K が不要なら 1024×1024 / 1536×1024 の 1K プリセットを使う **設定はされていますが、コスト予算にキャッシュ割引を織り込まないでください。** 公式のキャッシュ済み入力料金は text \$1.25 / image \$2.00 per 1M tokens で、APIYI チャネルではキャッシュが設定されています。リクエストがキャッシュにヒットすると、キャッシュ料金で課金されます。 率直な注意点があります。高い同時実行数を維持するため、APIYI はリクエストを複数の上流 OpenAI アカウントに分散しています（単一の OpenAI Tier-5 アカウントは 250 RPM しか許可されません）。OpenAI の prompt cache はアカウントをまたいで共有されないため、高い同時実行数では、同じプレフィックスを持つリクエストでも同じアカウントに乗らないことがあり、**キャッシュが単純にヒットしない**ことがあります。 良い知らせは、影響が小さいことです。画像生成の支配的コストは出力画像 token（\$30 / 1M）であり、キャッシュ割引は入力側にしか適用されないため、画像あたりの合計額はほとんど変わりません。予算は**入力の通常価格**で見積もり、cache hit はおまけの節約として扱ってください。 `gpt-image-2` が参照画像の高精細処理を自動で有効にするため、参照画像そのものが Vision の課金ルールに従って大きな input token 数へ変換されます。編集時の input token は text-to-image より明らかに多くなるため、それを踏まえて予算を組んでください。 **原因: `quality` が `auto` に設定されていた（または省略されていた）ためです。** 「サイズも解像度も参照画像も同じなのに、料金が上下する」という報告がありました。調査したところ、`size` と `quality` の両方が `auto` に設定されていました。 **犯人は `quality: auto` です**: auto モードではモデルが**リクエストを解釈し、生成ごとに異なる品質ティアをその場で選びます**。ティアが変われば出力画像 token 数が変わり、料金も変わります。以下は、\*\*入力は同一（各 1061 input tokens）\*\*なのに、料金が数倍違った実際の課金明細です。 | レイテンシ | Input tokens | Output tokens | 1 回あたりの料金 | | ----- | ------------ | ------------- | -------------- | | 53s | 1061 | 1286 | \$0.055082 | | 135s | 1061 | **5146** | **\$0.194042** | | 68s | 1061 | 1287 | \$0.055118 | 2 回目の呼び出しでは、`auto` がより高い品質ティアに解決され、output tokens が 5146 に跳ね上がり、価格は約 3.5 倍になりました。 **修正方法: `quality` を `auto` のままにしないでください。`low` / `medium` / `high` を明示的に渡してください。** ティアを固定すれば、同じ入力に対する output token 数と料金は安定し、予測可能になります。上の「品質リファレンス」セクションを参照してください。 `gpt-image-2` の image edit endpoint（`/v1/images/edits`）は、最大 **16** 枚の参照画像をサポートします。 * **multipart/form-data ファイルアップロード**: 各画像は **50MB 未満**、形式は `png` / `jpg` / `webp` * **base64 data URL**: フィールド長の上限は約 **20MiB**（schema `maxLength: 20971520` — 文字列フィールドの制限であり、50MB の multipart 上限とは**別**です）なので、元画像は **15MB** 以内に収めてください * **mask file**: 別途 **PNG 4MB 未満** に制限されます 実用上の注意として、一度に大きな画像を複数枚マックスまで使わないでください。サイズの大きすぎるリクエストボディは、ゲートウェイ / タイムアウト層で失敗しやすくなります。各画像を **1.5MB 以内** に圧縮するのが最も安定しており、出力品質は入力ファイルサイズと関係ありません。 このエラー（`code: invalid_image_file`）は、**N 枚目の参照画像が標準的な png / jpg / webp ファイルではない**ことを意味します（1 始まりの番号なので、該当画像の位置を番号で特定してください）。 最も一般的な原因は、スマホカメラ由来の **MPO 形式**です。`.jpg` の Huawei Mate 系端末からそのまま出したファイルには HDR gain-map のサブフレームが埋め込まれており、実体はマルチフレーム JPEG コンテナ（MPO）です。ヘッダーは同じ `FFD8` で、拡張子も `file` コマンドも JPEG と報告するため、見た目では判別できません。2026 年 7 月に確認済みです: MPO ファイルは常に拒否され、同じ画像を標準 JPEG/PNG として再エンコードすると **元の解像度のまま** 成功します（寸法、`image[]` フィールド名、`quality`/`size` パラメータとは無関係です）。このエラーは入力検証段階で返され、**課金されません**。 **修正方法**: アップロード前に Pillow で再エンコードしてください（`Image.open(f).format` が `"MPO"` を返す場合、変換が必要です）: ```python theme={null} from PIL import Image im = Image.open("photo.jpg") im.load() # for MPO, keeps only the first frame im.convert("RGB").save("photo_fixed.jpg", quality=92) ``` 詳細と検出方法: [画像編集 API — 参照画像フォーマット要件と前処理](/ja/api-capabilities/gpt-image-2/image-edit#reference-image-format-requirements-and-preprocessing)。 * 元画像と**同じサイズ**、**PNG 形式**、**4MB 未満** * **アルファチャンネル必須**: 透明（alpha=0）= inpaint 領域、不透明 = 保持 * 最初の画像にのみ適用されます * mask は「ソフトガイド」です。モデルはマスクされた領域の周囲を拡張または縮小する場合があります | 選択肢 | こんな場合 | | ------------------------- | ---------------------------------------------------------------------- | | **gpt-image-2**（公式） | サイズ / 品質を厳密に制御したい、OpenAI 公式と完全一致させたい、4K 出力が欲しい、mask による inpainting が必要 | | **gpt-image-2-all**（リバース） | 一律 \$0.03/画像、30〜60 秒のレンダリング、最小限のパラメータ、強い一貫性 / 中国語テキストが欲しい | はい、コード変更はゼロです。`base_url` を `https://api.apiyi.com/v1` に向け、`api_key` を APIYI トークンに設定してください: ```python theme={null} from openai import OpenAI client = OpenAI(api_key="sk-your-key", base_url="https://api.apiyi.com/v1") resp = client.images.generate(model="gpt-image-2", prompt="...", size="2048x1152", quality="high") ``` **いいえ**。`gpt-image-2` は OpenAI の公式同期 endpoint を使っているため、リクエストが送信されると「cancel」シグナルなしで完了まで実行されます。クライアントが切断しても、サーバーは生成を最後まで終え、通常どおり課金されます。クライアント側のタイムアウトは慎重に設定してください。「切断 = 無課金」とは考えないでください。 デフォルトは **100 RPM**（1 分あたり 100 リクエスト）です。実際に利用できる RPM は **プラットフォーム全体の同時実行数** に応じて動的に調整されます。さらに必要な場合は、想定 QPS / RPM を添えてご連絡ください。追加容量をプロビジョニングできます。 **いいえ**。`gpt-image-2` は OpenAI 公式 API を厳密にミラーしており、同期のみです。リクエストは結果が返るまでブロックします（`high` + 4K だと現実的には 1〜2 分）。非同期キューやコールバックの仕組みが必要な場合は: * ビジネス層でタスクキュー（Celery / BullMQ など）を使って自前でラップする * あるいは [`gpt-image-2-all`](/ja/api-capabilities/gpt-image-2-all/overview) を使う — 30〜60 秒で生成され、フロントエンドからポーリングしやすいです **いいえ**。OpenAI の組み込みコンテンツモデレーションが安全でない / 形式不正のリクエストを `400` エラーで拒否し、**課金は発生しません**。典型的な応答は次のとおりです。 ```json theme={null} { "status_code": 400, "error": { "message": "Your request was rejected by the safety system. ...", "type": "shell_api_error", "code": "moderation_blocked" } } ``` その他の無料エラー: `401`（無効な token）、`429`（レート制限）。**token 課金が発生するのは、リクエストが実際にモデル生成段階に到達し、`200` + `b64_json` を受信した後だけです。** ## 関連ドキュメント * [⚖️ 公式版とリバース版の比較](/ja/api-capabilities/gpt-image-2/vs-gpt-image-2-all) - 横並びの選定ガイド * [テキストから画像へのプレイグラウンド](/ja/api-capabilities/gpt-image-2/text-to-image) - `/v1/images/generations`のインタラクティブなテスト * [画像編集プレイグラウンド](/ja/api-capabilities/gpt-image-2/image-edit) - `/v1/images/edits`のマルチ画像融合 + マスク * [詳説: gpt-image-2 ローンチ](/en/news/gpt-image-2-launch) - ニュース記事 * [完全版統合ドキュメント](/ja/api-capabilities/gpt-image-2/overview) - 完全なAPIリファレンス * [GPT-Image-2-All（リバースエンジニアリング版）](/ja/api-capabilities/gpt-image-2-all/overview) - より安く、より高速な代替手段 * [コミュニティ: Luck GPT-Image 2 ComfyUI ノード](/ja/scenarios/ecosystem/luckgpt2-comfyui) - ComfyUIで`gpt-image-2`を直接呼び出す（マスク / 5枚の参照画像 / カスタムサイズ） * [コミュニティ: APIYI GPT-Image 2 スキル](/ja/scenarios/ecosystem/apiyi-gpt-image-skills) - Codex CLI / Cursor / Gemini CLI やその他のAIコーディングツールから、1文で呼び出せます * [API マニュアル](/ja/api-manual) - 一般的な使用ガイド `gpt-image-2` は OpenAI の公式フラッグシップで、token課金です。定額料金（\$0.03/画像）とより高速な生成（30–60秒）を重視する場合は、[gpt-image-2-all](/ja/api-capabilities/gpt-image-2-all/overview)をご覧ください。