GPT-Image-2-All 画像生成/編集

すべての画像APIは同期型です。ポーリングするためのタスクIDはなく、クライアントが切断されると、リクエストが処理中でも結果は失われ、課金は発生します。このモデルでは十分に長いtimeoutを設定してください。詳細は Image API Essentials & Best Practices をご覧ください。

概要

gpt-image-2-all は、APIYI プラットフォームで利用できる GPT 画像生成のリバースエンジニアリングモデル（ChatGPT Web 系）です。1 回の呼び出しあたり $0.03/image という非常に競争力のある価格で、約 30–60 秒 で画像を生成し、text-to-image / single-image editing / multi-image fusion / natural-language editing をサポートします。さらに、高い文字描画忠実度と、中国語 prompt のネイティブサポートを備えています。

🎨 ハイライト: 固定 $0.03/image レートの、信頼性の高いリバースエンジニアリング経路です。サイズ / 品質 / n パラメータを気にする必要はありません。prompt でサイズとスタイルを指定するだけです。OpenAI Images API の標準エンドポイントである /v1/images/generations（text-to-image）と /v1/images/edits（image editing）を使用します。出力サイズや 4K を固定したいですか？ 姉妹モデル gpt-image-2-vip に切り替えてください。呼び出し形式は同じで、追加の size フィールドが 1 つ増えるだけです。

テキストから画像生成 API

/v1/images/generations — text prompt から画像を生成します。

画像編集 API

/v1/images/edits — 編集 / 融合指示を含む multipart アップロードです。

主な機能

非常に競争力のある価格設定

1回ごとの一律料金は $0.03/image で、解像度別の料金区分はなく、コストを予測しやすいです

高精度なテキストレンダリング

中国語/英語のテキスト、看板、ポスター文字を安定してレンダリングでき、インフォグラフィックやマーケティング用素材に最適です

中国語プロンプトに対応

翻訳なしで中国語の説明をネイティブに理解します

マルチ画像融合

複数の参照画像をサポートし、プロンプトでは「image1/image2/image3」として参照できます

より高速な出力

生成時間は約30〜60秒で、gpt-image-2-vip と公式リレーの gpt-image-2 の両方より高速です

R2 CDN 高速化

低遅延のグローバル配信を行う R2 CDN リンクには、response_format: "url" を明示的に指定してください

自然言語による編集

会話形式の説明で編集でき、マスクは不要です。複数ターンの反復にも対応します

標準エンドポイント対応

OpenAI の Images API の標準エンドポイント /images/generations と /images/edits に対応しています

料金

モデル	課金	価格	出力
`gpt-image-2-all`	呼び出しごと	$0.03 / image	1 image / 呼び出し

課金に関する注意:

一律料金で、解像度、品質、prompt の長さによる段階はありません
失敗したリクエストには課金されません（認証失敗、パラメータ検証エラー）
N 枚の image が必要な場合は、API を並列で N 回呼び出してください

同価格の姉妹モデル: gpt-image-2-vip（Codex の逆系統）— 価格は同じ $0.03/image で、30 種類の明示サイズ（4K を含む）をサポートし、呼び出し形式も同じです。出力寸法を固定したい場合に切り替えてください。

グループ設定

gpt-image-2-all は Default グループ上にあります — 追加のグループは不要です。リバースチャネルは現在安定供給があるため、official-relay gpt-image-2 のようなエンタープライズ・グループへのフォールバック構成はありません。

モデル	グループ	備考
`gpt-image-2-all`	`Default`	ChatGPT-web リバース、固定 $0.03/img、約 30〜60 秒
`gpt-image-2-all`	`image2_OSS`	1x レート倍率（追加料金なし）、決定的な URL 出力 — デフォルトグループが高負荷でも base64 にフォールバックしません

決定的な URL 出力が必要ですか → `image2_OSS` グループに切り替えてください

2026 年 7 月にデフォルトグループで計測したところ、gpt-image-2-all（および gpt-image-2-vip）は response_format を省略すると b64_json を返します。画像 URL を得るには response_format: "url" を明示的に渡してください。デフォルトグループの出力形式は保証されません — これまでの既定は url で、高負荷時には b64_json にフォールバックしており、チャネルのバージョンごとに変わってきました。ビジネスが URL 出力に依存している（URL をそのままデータベースに書き込む、フロントエンドで URL で描画する、base64 は許容できない）場合は、token のグループを image2_OSS に切り替えてください。これは 決定的な URL 出力 のために作られたグループで、1x レート倍率（追加料金なし）、reverse モデル gpt-image-2-all と gpt-image-2-vip の両方で有効です。応答には常に画像 URL が含まれ、base64 にフォールバックすることはありません。

token 作成画面: 課金モードはまず従量課金、グループ image2_OSS（1x レート倍率）、画像 URL を出力するグループ、gpt-image-2-all と gpt-image-2-vip に適しています — Token creation: set billing mode to "pay-as-you-go first" and pick the image2_OSS group (1x) — use it when you need deterministic URL output

上級編（gpt-image-2-vip と公式リレー gpt-image-2 も使う場合）: token が 3 つのモデルすべてをカバーするなら、token のグループ優先順位を次のように設定してください。

第 1 優先: image2Enterprise（1.2x のエンタープライズ・グループ、公式リレー専用の安定レーン）
デフォルトのフォールバック: Default（2 つの reverse モデルはここにあり、モデルごとにルーティングされます）

結果: official-relay gpt-image-2 は安定性のためにエンタープライズ・レーンを使い、2 つの reverse モデルはデフォルトグループに残ります — 1 つの token で 3 つすべてをカバーでき、干渉しません。

📖 image2Enterprise グループについて: /en/live/2026-04/image2-enterprise-stable

技術仕様

属性	値
モデル名	`gpt-image-2-all`
チャネル種別	公式リバースエンジニアリング（ChatGPT web）
課金	$0.03 / image、呼び出しごと
生成時間	約30〜60秒
出力解像度	明示的なサイズパラメータはありません。自動調整されます（promptで指定してください）
既定のレスポンス形式	`b64_json`（生のbase64、`data:` プレフィックスなし、2026-07時点で確認済み；`response_format` を必ず明示的に渡してください）
任意の形式	`url`（R2 CDN 高速化リンク、有効期間は約1日、明示的な `response_format: "url"` が必要）
中国語プロンプト	✅ ネイティブ対応
機能	テキストから画像生成、単一画像編集、複数画像融合、自然言語編集

このモデルは自動調整される出力サイズを持ち、公式のgpt-image-2 APIとは同等ではありません。厳密に固定された出力サイズや4Kが必要な場合は、gpt-image-2-vip（Codex リバースライン、4Kを含む30種類の明示的なサイズ）を使用してください。完全な公式API互換性が必要な場合は、gpt-image-2を使用してください。

⏰ 画像URLの有効期間: 約1日（デフォルト）url フィールドの url モードのレスポンスは、約24時間で期限切れになる R2 CDN リンクです。それ以降のリクエストは404になります。長期保存が必要な画像（製品写真、ユーザー作品、履歴記録など）については、生成後できるだけ早くダウンロードして自前のストレージに保存してください。代表的な方法は2つあります:

サーバー側ダウンロード: レスポンスを受け取ったらすぐに、requests / fetch を使って画像を取得し、S3 / OSS / R2 / ローカルディスクに保存します
b64_json レスポンス形式を使う: 画像を base64 データとして直接取得でき、余分なクロスオリジンダウンロードを省略できます — フロントエンドでのレンダリングやファイルへの直接書き込みに最適です

エンドポイント

エンドポイント	用途	Content-Type	最適用途
`POST /v1/images/generations`	テキストから画像生成	`application/json`	OpenAI Images API の標準フォーマット — 同じコードで公式チャネルとリバースチャネルの両方に対応できます
`POST /v1/images/edits`	画像編集（単体/複数）	`multipart/form-data`	OpenAI Images API の標準フォーマット — 同じコードで公式チャネルとリバースチャネルの両方に対応できます

OpenAI Images API を使う（/v1/images/generations + /v1/images/edits）理由は、2 つあります。

より安定している: Images API チャネルの上流リソース供給がより豊富なため、呼び出し成功率が高いです
公式リレーとの互換性があり、切り替えが簡単: 呼び出し方法と size のようなパラメータは公式リレーの gpt-image-2 と完全に互換性があります — リバースチャネルがリスクコントロールで不安定になったら、model 名を差し替えるだけでコード変更は不要です

チャットベースのエンドポイント（/v1/chat/completions、現在は非推奨）もあります。下の FAQ をご覧ください。

ドメインオプション: api.apiyi.com がメインドメインです。b.apiyi.com / vip.apiyi.com などの代替ゲートウェイドメインも使用できます。レスポンスの挙動は同じです。

size パラメータで出力サイズを固定したいですか？ 姉妹モデル gpt-image-2-vip を使ってください — エンドポイントは同一で、size フィールドが 1 つ増えるだけです（4K を含む 30 種類の明示サイズ）。

サイズとアスペクト比の制御（prompt 内に記述）

gpt-image-2-all には size パラメータがありません。サイズは prompt に記述します。出力サイズを厳密に固定したい場合（EC のヒーロー画像、ポスターテンプレート、4K 壁紙など）は、代わりに gpt-image-2-vip を使用してください。

検証済みの「prompt の表現 → 実際の解像度」表

以下の 8 つの表現は、実際に安定して再現されることが確認済みです。第 1 列の表現を prompt の先頭に置くと、第 2 列に示した解像度が得られます（いずれの出力もおよそ 1.5K ピクセル帯です）。

Prompt の表現（そのまま記述）	検証済みの解像度	おおよそのサイズ	実際の比率
`横版 16:9` (Landscape 16:9)	1672 × 941	約 1.9 MB	16:9
`竖屏 9:16` (Portrait 9:16)	941 × 1672	約 2.1 MB	9:16
`4:3`	1448 × 1086	約 2.3 MB	4:3
`3:4`	1086 × 1448	約 2.5 MB	3:4
`3:2 尺寸` (3:2 size)	1536 × 1024	約 2.9 MB	3:2
`2:3 尺寸` (2:3 size)	1024 × 1536	約 3.0 MB	2:3
`2:5 竖屏` (2:5 portrait)	793 × 1983	約 1.9 MB	2:5
`5:2 横屏` (5:2 landscape)	1983 × 793	約 1.9 MB	5:2

注記:

すべての出力は 約 1.5K ピクセル帯（長辺 1500〜2000 px）です。これはモデルの実質的な上限であり、本当に「任意の解像度」ではありません。
prompt に表の表現以外を 入れない ときが、再現性が最も高くなります。ほかの構図に関する語を混ぜると、ずれが生じます。
中国語の文字列は実際に送信する値です。翻訳せず、そのまま使うことをおすすめします。

スタイル用の表現（固定解像度なし）

以下の表現には検証済みの解像度がありません。上の表と組み合わせて、スタイル修飾子としてのみ使用してください。

必要なもの	表現（スタイルのガイダンスのみ — 解像度の保証なし）
正方形	`1024×1024 square` / `1:1 square composition`
超横長バナー	`Banner 21:9 ultra-widescreen`
スタイル修飾子	`cinematic` / `phone poster` / `square composition`

ヒント: サイズや構図を表す語は、prompt の先頭に置くとより反映されやすくなります。

この表をエンドユーザーに公開する

gpt-image-2-all には size パラメータがありませんが、ユーザーに「サイズ / アスペクト比」ドロップダウンを用意して、公式の size フィールドのように見せる ことはできます。

上の表にある prompt の表現を、オプションの value として使用します（例: 横版 16:9）
ユーザーが何を得られるか分かるように、オプションラベルに 予想解像度 を表示します（例: Landscape 16:9 (1672×941)）
バックエンドでは、選択された表現をユーザーの元の prompt の先頭に付けてから API に送信します

const SIZE_OPTIONS = [
  { label: "Landscape 16:9 (1672×941)", prefix: "横版 16:9" },
  { label: "Portrait 9:16 (941×1672)",  prefix: "竖屏 9:16" },
  { label: "4:3 (1448×1086)",           prefix: "4:3" },
  { label: "3:4 (1086×1448)",           prefix: "3:4" },
  { label: "3:2 (1536×1024)",           prefix: "3:2 尺寸" },
  { label: "2:3 (1024×1536)",           prefix: "2:3 尺寸" },
  { label: "2:5 portrait (793×1983)",   prefix: "2:5 竖屏" },
  { label: "5:2 landscape (1983×793)",  prefix: "5:2 横屏" },
];

const finalPrompt = `${selected.prefix}, ${userPrompt}`;

基盤モデルは引き続き 適応的 です。ピクセル単位のわずかなずれは正常です。エンドユーザーに対して、完全一致の出力を約束しないでください。出力サイズを厳密に固定したい場合（EC のヒーロー画像、ポスターテンプレート、4K 壁紙など）は、姉妹モデル gpt-image-2-vip を使用してください。価格は同じ、呼び出しコードも同じで、追加の size フィールドが 1 つあるだけです。

ベストプラクティス

入力画像を1.5MB未満に圧縮する（画像編集 / マルチ画像融合）

アップロードする各画像は1.5MB未満（JPEG品質80〜90 / 解像度縮小）に圧縮してください。マルチ画像融合でも、1枚ごとに同じ上限を適用します。断続的なサーバー側エラーは、サイズ超過の入力が原因で起きることが最も多く、圧縮すると成功率とレイテンシが目に見えて改善します。出力解像度は入力サイズではなく prompt の表現によって決まります — 入力を小さくすると処理が速くなるだけで、品質は落ちません。prompt に4K / 8K を詰め込んでも高解像度画像にはなりません。より大きい出力を安定して得るには、上の「検証済みのprompt表現 → 実際の解像度」表の表現を使ってください。

サイズはpromptの先頭に置く

比率、解像度、構図に関する語を先頭に置くと、指示への追従性が高まります。

テキスト要素を自信を持って使う

文字描画の忠実度は大きな強みです — 中国語/英語のテキストを含む看板、ポスター、インフォグラフィックはどれもよく動作します。

マルチ画像の順序を明記する

image フィールドを繰り返す順序には意味があります。prompt では「image1/image2/image3」と明示的に参照してください。

必要に応じてレスポンス形式を選ぶ

b64_json は直接Web描画用、url はサーバー側での保存/転送用です。

300秒のタイムアウトを使う

通常の生成は30〜60秒ですが、画像のアップロード / ダウンロード時間や逆チャネルのピーク時テールにより、実際のエンドツーエンド時間は大きく変動します。誤検知のタイムアウトを避けるため、300秒を保守的な基準として設定してください。

拒否されるパラメータを削る

gpt-image-2-all は size, n, quality, aspect_ratio を拒否します — 送信すると検証エラーが発生することがあります。size を通すには、gpt-image-2-vip に切り替えてください。

エラーコードと再試行

Status	意味	推奨
`401`	無効な token	Bearer Token を確認してください
`429`	rate limit / quota 超過	指数バックオフで再試行
`5xx`	一時的な gateway/backend エラー	1〜2回再試行
タイムアウト	リバースチャネルのピーク + 画像のアップロード/ダウンロードのロングテール	クライアントのタイムアウトを ≥ 300s に設定してください（保守的）

クライアントの推奨事項:

リクエストタイムアウトは 300秒から に設定してください（保守的。一般的には 30〜60s ですが、画像のアップロード / ダウンロードとリバースチャネルのピークテールにより変動が大きく、120s では誤タイムアウトが頻発します）
5xx とタイムアウトには 指数バックオフ を使用してください（2〜3回の再試行を推奨）
デバッグのために request-id レスポンスヘッダーをログに記録してください

よくある質問

gpt-image-2-all と gpt-image-2-vip の両方がありますが、どちらを選べばよいですか？

どちらも同じ価格（$0.03/call）のリバースエンジニアリングされたチャネルで、呼び出しフォーマットは完全に同一です。違いは size の対応と生成時間です。

厳密なサイズ制御は不要で、より速い出力がほしい → gpt-image-2-all（約30〜60秒、サイズは prompt に記述してください）。
出力サイズを固定したい、または4Kが必要 → gpt-image-2-vip（約90〜150秒、4Kを含む30種類の明示サイズ）。
quality のノブや OpenAI-API のフィールド完全互換が必要 → 公式の gpt-image-2 を使ってください。

一度に複数枚の画像を生成できますか？

いいえ。このモデルは1回の call につき1枚の画像を返します。N枚必要な場合は、API を N 回並列で呼び出してください。各 call は個別に $0.03 で課金されます。

n パラメータはサポートしていますか？ n=3 を渡すとどうなりますか？

いいえ。 このモデルは1回の call につき1枚の画像を返します。複数画像が必要な場合は、繰り返し呼び出し／並列呼び出しを使ってください。⚠️ 重要: リクエストで n=3 を渡すと、課金は 0.03 × 3 = $0.09 になりますが、実際に返るのは1枚だけです。無駄な課金を避けるため、リクエストから n フィールドを必ず外してください。

コンテンツが拒否されたり、モデルが「それはできません」と返した場合、課金されますか？

これは 同期的なチャットスタイルのレスポンス を使うリバースエンジニアリングされたチャネルです。結果は 課金ルールが異なる 2つのケースに分かれます。1) HTTP 5xx が返る → 課金されない上流のコンテンツポリシーでリクエストが強制ブロックされた場合、次のような内容が表示されます:

{
  "error": {
    "message": "Image was not generated as expected. Please adjust the prompt and retry (traceid: 0672821c6951af183dbf847130caaf16)",
    "localized_message": "Unknown error",
    "type": "invalid_request_error",
    "param": "",
    "code": null
  }
}

こうしたハードエラーは 課金されません。ユーザーに prompt の調整を依頼して、再試行してください。2) HTTP 200 でテキストの「ソフト拒否」 → 課金されるモデルが会話の中でソフト拒否した場合（例: 「それはできません」「申し訳ありませんが、このリクエストには…」）、プロトコル上は通常の chat completion に見えるため、課金されます。リバースチャネルはプロトコル層では「拒否テキスト」と「画像出力」を信頼性高く区別できません。なぜソフト拒否を単純に免除できないのかすべてのソフト拒否を自動で免除すると、プラットフォーム側が失敗した上流 call のコストをすべて負担することになります。さらに重要なのは、上流でコンテンツ安全性が頻繁に発動すると、供給元のアカウントが ban されるリスクも高まる ことです。これは供給側の実コストであり、完全には回避できません。統合者向けの推奨事項

✅ 事前フィルタリングとユーザーへの警告: フロントエンドまたは gateway でキーワード／シナリオフィルタ（実在人物名、著作権キャラクター、センシティブな話題など）を追加し、「有名人 / IP 系の話題は失敗し、上流ポリシーにより課金される場合があります」のような UI ヒントを表示してください。無駄な課金を大幅に減らせます。
✅ コンシューマー向け製品の月次補償: コンシューマー向け製品では、ユーザー入力を完全には制御できないことを理解しています。月間支出が十分大きい場合（$1000+/month）、ログを月次でまとめて（短い latency の call は通常ソフト拒否です）サポートに連絡すれば、一度限りの手動クレジットを受けられる場合があります。call ごとの異議申し立ては不要です。

b64_json に data:image/png;base64, プレフィックスを付ける必要はありますか？

まず判定してから処理してください。 2026年7月時点の確認では、返される b64_json は data: プレフィックスのない生の base64 です。ファイルに書き出すにはデコードするか、描画前に自分でプレフィックスを付けてください。以前のバージョンにはプレフィックスが含まれていました。コードには startsWith('data:') チェックを追加してください。プレフィックスがある場合は値をそのまま img src として使い、ない場合は先にデコードするかプレフィックスを付与してください。これで、二重プレフィックス付与や、プレフィックス付き文字列をデコードして壊れた画像になるのを防げます。

prompt に 1024x1024 と書いても、なぜ別のサイズになるのですか？

適応型モデルはサイズの記述を「強制」ではなく「ガイダンス」として扱います。従わせやすくするには、サイズ／構図の言葉を prompt の最初に置き、スタイル記述と組み合わせてください（例: cinematic、phone poster、square composition）。特定の解像度に 確実に 対応する表現については、このページ上部の「検証済み prompt 表現 → 実際の解像度」表（「サイズとアスペクト比の制御」内）を参照してください。

入力画像は圧縮すべきですか？ prompt に 4K / 8K と書くと効果がありますか？

はい、強く推奨します。 各入力画像は 1.5MB 未満 に圧縮してください（JPEG 品質 80-90 / 解像度を縮小）：断続的なサーバー側エラーは、ほとんどがサイズ過大の入力で発生します。圧縮すると、成功率と latency が明確に改善します。なお、1.5MB は信頼性と速度のための 推奨上限 であり、上の FAQ にある 10MB はゲートウェイのハード上限です。圧縮で品質が落ちる心配は不要です — このモデルの出力解像度は、入力サイズではなく prompt の構図指定文言で決まります。入力を小さくしても、単に高速化するだけです。prompt に 4K / 8K を詰め込んでも、実際には高解像度画像にはなりません。これらの語は飾りであり、それによってモデルの解像度が上がるわけではありません。より大きい出力を確実に得たい場合は、上の「検証済み prompt 表現 → 実際の解像度」表にある検証済みの表現を使ってください（例: cinematic、phone poster、square composition）。サイズ固定や4Kが必要な場合は、gpt-image-2-vip に切り替えてください（4K を含む30種類の明示サイズ、固定 $0.03/image）。

参照画像の最大サイズと対応フォーマットは何ですか？

推奨は 画像あたり ≤ 10MB、対応フォーマットは png / jpg / webp です。大きすぎる画像は gateway の制限に達する場合があります。複数画像融合では、各画像がこの制限を満たす必要があります。

返される image URL はどのくらい有効ですか？ダウンロードする必要はありますか？

url フィールドの url モードのレスポンスは、約1日（24時間）で期限切れになる R2 CDN リンクです。以後のリクエストは 404 になります。強く推奨: 生成後すぐに、生成された画像を 自前の object storage（S3 / OSS / R2）、CDN、または database にダウンロードして永続化してください。返却された URL を長期的にホットリンクしないでください。推奨される2つの方法:

サーバーサイドプロキシ: レスポンス後すぐに requests.get(url) し、自分の storage に保存して、frontend には自前の URL を返す。
b64_json を使う: リクエストに "response_format": "b64_json" を追加して base64 画像データを直接取得する。クロスオリジンのダウンロードが1回減るため、frontend でのレンダリングやそのままファイルへの書き込みに最適です。

短時間表示のプレビュー（単一セッション表示）であれば、R2 URL はそのままでも永続化なしで使えます。

ストリーミングはサポートしていますか？

いいえ。このモデルは画像を一括で返すため、ストリーミングはサポートされていません。latency が重要な場合は、クライアント側で「生成中…」の進捗インジケーターを表示し、300秒のタイムアウト を設定してください（保守的な設定です）。

公式 OpenAI SDK は使えますか？

はい。base_url を https://api.apiyi.com/v1 に向け、api_key に APIYI token を設定してください。ただし、client.images.generate() は既定で size/n を送信しますが、このモデルはその両方のパラメータを拒否するため、requests / fetch を使って /v1/images/generations と /v1/images/edits に対する生の HTTP リクエストを送ることを推奨します。

中国語と英語の prompt で意味の違いはありますか？

このモデルは中国語をネイティブにサポートしており、結果も同等です。書道や伝統的な祭りの要素など、中国語固有のシナリオでは、中国語表現の方がより自然に感じられます。

/v1/chat/completions 経由でも画像を生成できますか？

はい、この endpoint はまだ動作しますが、もはや推奨されません。代わりに /v1/images/generations と /v1/images/edits を使ってください（より安定しており、同じ code が公式リレーの gpt-image-2 でも使えます）。chat ベースのスタイルが意味を持つのは、複数ターンの反復編集か、オンライン image URL を直接渡す場合の2つだけです。画像の意図が曖昧な場合、モデルは画像ではなくプレーンテキストを返すことがあります（意図を強めるため、prompt の先頭に「画像を生成:」のような固定プレフィックスを付けてください）。完全なパラメータは、chat ベースの API リファレンスを参照してください。

基本

基本API

画像API（公式）

動画API（公式）

マルチモーダル理解API

テキストAPI

GPT-Image-2-All 画像生成/編集

概要

テキストから画像生成 API

画像編集 API

主な機能

非常に競争力のある価格設定

高精度なテキストレンダリング

中国語プロンプトに対応

マルチ画像融合

より高速な出力

R2 CDN 高速化

自然言語による編集

標準エンドポイント対応

料金

グループ設定

決定的な URL 出力が必要ですか → `image2_OSS` グループに切り替えてください

技術仕様

エンドポイント

サイズとアスペクト比の制御（prompt 内に記述）

検証済みの「prompt の表現 → 実際の解像度」表

スタイル用の表現（固定解像度なし）

この表をエンドユーザーに公開する

ベストプラクティス

エラーコードと再試行

よくある質問

関連ドキュメント

​概要

テキストから画像生成 API

画像編集 API

​主な機能

非常に競争力のある価格設定

高精度なテキストレンダリング

中国語プロンプトに対応

マルチ画像融合

より高速な出力

R2 CDN 高速化

自然言語による編集

標準エンドポイント対応

​料金

​グループ設定

​決定的な URL 出力が必要ですか → image2_OSS グループに切り替えてください

​技術仕様

​エンドポイント

​サイズとアスペクト比の制御（prompt 内に記述）

​検証済みの「prompt の表現 → 実際の解像度」表

​スタイル用の表現（固定解像度なし）

​この表をエンドユーザーに公開する

​ベストプラクティス

​エラーコードと再試行

​よくある質問

​関連ドキュメント

概要

主な機能

料金

グループ設定

決定的な URL 出力が必要ですか → `image2_OSS` グループに切り替えてください

技術仕様

エンドポイント

サイズとアスペクト比の制御（prompt 内に記述）

検証済みの「prompt の表現 → 実際の解像度」表

スタイル用の表現（固定解像度なし）

この表をエンドユーザーに公開する

ベストプラクティス

エラーコードと再試行

よくある質問

関連ドキュメント