Grok Imagine 2 画像生成と編集

概要

Grok Imagine 2 は xAI の 最新の第2世代 画像モデルです。第1弾からパラメータ制御と編集の両面で大きく進化しており、アスペクト比と解像度が実際に反映され、2K ティアが利用でき、1回の呼び出しで最大 10 枚の画像を返し、参照編集では元画像がきちんと保持されます。 APIYI では 2 種類のバリエーションを提供しています: grok-imagine-image（標準）と grok-imagine-image-quality（高品質）です。どちらも同じエンドポイントとパラメータを共有しており、違いは出力忠実度と価格だけです。

主な特徴: リクエストごとの一律料金（1K と 2K は同額）、実際に反映される 5 種類のアスペクト比 x 2 種類の解像度ティア、1回の呼び出しで最大 10 枚、そしてアートスタイル、構図、配色、被写体の同一性を保持する高忠実度の参照編集です。1K 画像の生成には約 9 秒かかります。

モデル ID には 2 が含まれていません。 製品名は Grok Imagine 2 ですが、呼び出すモデル名は grok-imagine-image と grok-imagine-image-quality です — 存在しないモデルなので 503 を返す grok-imagine-2-image は書かないでください。

📌 まずこれを読んでください: 参照画像は編集エンドポイント /v1/images/edits でのみ動作します — テキストから画像生成では使えません。image / image_url / images を /v1/images/generations に渡すと 200 でごく普通の画像 が返りますが、参照は 静かに破棄され、それでも課金されます — いかなるエラーも発生しません。下記のエンドポイントをご覧ください。

すべての画像 API は 同期式 です。非同期タスク ID はないため、クライアントが切断されると結果は失われますが、リクエストは課金されたままになります。十分に長いタイムアウトを設定してください — 画像 API のベストプラクティスをご覧ください。

テキストから画像生成 API

テキスト prompt から画像を生成し、ライブテスト用のインタラクティブなプレイグラウンドを備えています。

画像編集 API

参照画像と指示をアップロードし、1〜3 枚の画像融合とプレイグラウンドを利用できます。

APIYIでGrok Imagine 2を使う理由

OpenAI互換フォーマット

標準の/v1/images/generationsおよび/v1/images/editsエンドポイントです。リクエストボディとレスポンスフィールドはOpenAI Images APIと一致しているため、公式のOpenAI SDKをそのまま利用でき、移行作業は不要です。

同時実行数の上限なし

RPM/RPD の厳しい上限はありません。100 RPMで余裕をもって計測済みで、チャネル容量にも十分な余裕があるため、バッチワークロードは線形にスケールします — クォータ申請や独自のスロットリングは不要です。

一律料金、予測しやすいコスト

画像ごとに固定価格で、解像度に依存しません — 2K画像は1Kと同じ料金です。正確な画像枚数で予算を組めて、チャージ特典を重ねるとさらに安くできます。

グローバルアクセス、障壁なし

海外サーバーやプロキシは不要です。 中国本土のデータセンター、家庭用ブロードバンド、海外ノードのいずれもapi.apiyi.comへ直接接続できます。

充実したモデルエコシステム

ほかにも利用できます: Nano Banana 2, GPT-Image-2, Seedream, FLUX, さらに Grok テキストモデルもあります。

専門サポート

当社チームは画像生成ワークロードに深く取り組んでおり、PoC から本番展開までエンタープライズ顧客をサポートできます。

主な機能

2つの解像度帯

1k 約1メガピクセル、2k 4.2〜4.5メガピクセル（16:9で2816x1584） — 同一価格

5種類のアスペクト比

1:1 / 16:9 / 9:16 / 4:3 / 3:4、実測ピクセル寸法が完全に一致します

1回あたり最大10枚

nは1〜10を受け付け、1回のリクエストで複数画像を返します — バッチ選択に最適です

高速な生成

1Kで約9秒、2Kで15〜17秒で、負荷下でもレイテンシーは安定しています — 100 RPMでも快適に動作します

真の参照編集

指定した内容だけを変更し — アートスタイル、構図、パレット、被写体の同一性はそのまま維持されます

マルチ画像融合

編集エンドポイントは1〜3枚の参照画像を受け付けます。たとえば、画像Aの被写体を画像Bのシーンとスタイルに配置できます

2つのレスポンス形式

url 直接リンクまたは b64_json 生の base64、両方のエンドポイントでサポートされています

OpenAI SDK対応

client.images.generate() と client.images.edit() はそのまま使えます — 手動のHTTP実装は不要です

価格

モデル	課金	APIYI価格	備考
`grok-imagine-image`	リクエストごとの定額	$0.02 / image	標準ティア、デフォルトの選択肢
`grok-imagine-image-quality`	リクエストごとの定額	$0.045 / image	要求の高い出力向けの高品質ティア

課金に関する注意事項

解像度に依存しません: 1k と 2k は同じ料金です — 2K でも追加料金はかかりません。
画像ごと: n=4 は、prompt の長さにかかわらず 4 画像分として課金されます。
編集の料金はテキストから画像生成と同じです — /v1/images/edits に追加料金はありません。
usage ブロックは照合に使用できません: prompt_tokens は常に 1000 x n であり、プレースホルダーです。代わりにコンソールの課金記録を使用してください。

グループ設定

Grok Imagine 2 は Default グループ（1.0x レート倍率） で動作し、上の価格表と一致します。Group の切り替えは不要です。 推奨の Token 課金モデル: Pay-as-you-go Priority. このファミリーはリクエストごとに課金され、Pay-as-you-go Priority と Pay-per-request の両方で正しくルーティングされます。Pay-as-you-go Priority を選ぶと、1つの Token でプラットフォーム上の他の token 課金モデルもカバーできます。

すでに Token が他の画像モデルをカバーしている場合は、Default を主グループのままにしておけば問題ありません。このファミリーには専用のグループも追加設定も不要です。

技術仕様

項目	仕様
モデル ID	`grok-imagine-image`, `grok-imagine-image-quality`
アスペクト比	5: `1:1` / `16:9` / `9:16` / `4:3` / `3:4`
解像度レベル	`1k` (~0.9-1.05 MP), `2k` (~4.2-4.5 MP)
出力形式	1K の JPEG（約220-300 KB）、2K の PNG（約5-6 MB）
1回の呼び出しあたりの画像数	`n` 1-10
参照画像	編集エンドポイントでは1-3枚（`image[]`を繰り返し）
マスク・インペインティング	❌ 未対応
再現可能な`seed`	❌ 未対応
`revised_prompt` エコー	❌ 返されません
レイテンシ	1K で約9秒、2K で約15-17秒
同時実行数 / レート	上限なし。100 RPM でも余裕で計測済み
推奨クライアントタイムアウト	360秒以上

エンドポイント

Capability	Method	Path	Content-Type
テキストから画像生成	`POST`	`/v1/images/generations`	`application/json`
画像編集	`POST`	`/v1/images/edits`	`multipart/form-data`
チャット形式の生成	`POST`	`/v1/chat/completions`	`application/json`

✅ 編集エンドポイントでは multipart/form-data のファイルアップロードが必要です/v1/images/edits に JSON を送信すると、常に 400 が返ります:

request Content-Type isn't multipart/form-data

これは、上流ベンダーのドキュメントから統合している場合に特に重要です — そのドキュメントでは、公開画像 URL を含む JSON 本文が説明されていますが、これは APIYI ゲートウェイ経由では 動作しません。代わりにこのページに従ってください: -F "[email protected]" を使ってファイルをアップロードします。完全な例は画像編集 API をご覧ください。ファイルフィールド名は image または image[] にする必要があります。images / image_file は 415 を返します。

⚠️ 参照画像は絶対にテキストから画像生成エンドポイントに送信しないでください/v1/images/generations が image / image_url / images を受け取っても、エラーは返しません。200 を返して、参照を完全に無視し、プロンプトだけから新しい画像を生成します — しかも課金は通常どおり発生します。エラーシグナルがないため、通常は出力が入力とまったく関係ないことに気づいたときに初めて表面化します。参照画像を使うワークフローでは必ず /v1/images/edits を使用してください。

メインドメイン https://api.apiyi.com、バックアップ https://vip.apiyi.com。チャット形式の生成（/v1/chat/completions）は動作しますが、推奨される方法ではありません — 下の FAQ をご覧ください。

GPT-Image-2 からの移行

すでに GPT-Image-2 を統合している場合、エンドポイントと呼び出し規約は同一（/v1/images/generations + /v1/images/edits、OpenAI SDK 互換）です — ただし パラメータ体系が異なる ため、モデル名を差し替えるだけでは動作しません。変更が必要な点は以下のとおりです。

パラメータ対応表

項目	GPT-Image-2	Grok Imagine 2	移行時の対応
出力サイズ	`size`（`1536x1024` のような明示的なピクセル指定）	`aspect_ratio` + `resolution`	書き換えが必須です; `size` ではエラーになりません
品質グレード	`quality`（`low`/`medium`/`high`/`auto`）	そのようなパラメータはありません — モデル名を使用してください	`quality` を削除し、`-quality` 版に切り替えてください
出力形式	`output_format`（png/jpeg/webp） + `output_compression`	そのようなパラメータはありません — 形式は解像度に従います	両方削除してください; 1K は常に JPEG、2K は常に PNG です
背景	`background`（`opaque`/`auto`）	そのようなパラメータはありません	削除してください
モデレーションレベル	`moderation`（`auto`/`low`）	そのようなパラメータはありません	削除してください
高忠実度	`input_fidelity` を送信してはいけません	そのようなパラメータはありません	削除してください
1回の呼び出しあたりの画像数	`n` は 1 のみ対応	`n` は 1～10 に対応	✅ クライアント側のファンアウトループを削除できます
参照画像（編集）	最大 16 枚	最大 3 枚	⚠️ 3 枚を超えて送信するフローは見直してください
マスクインペインティング	✅ 対応	❌ 非対応	⚠️ マスク依存のフローは移行できません
課金	token ごと（高品質では 1 画像あたり約 $0.21）	リクエストごとの定額、$0.02 / $0.045	予算モデルは使用量ベースから画像単位に変わります

最も起こしやすい 3 つのミス

1. デフォルトのレスポンス形式が逆になっています — 最も見落とされやすい変更点GPT-Image-2 は b64_json のみを返します（url はありません）が、Grok Imagine 2 は デフォルトで url を返します。パーサーが resp.data[0].b64_json を読む場合、移行後は None / undefined を受け取ることになります。次の 2 つの対処法のどちらかを選びます。

既存のコードを維持する → "response_format": "b64_json" を明示的に渡す
直接リンクに切り替える → data[0].url を読み取り、ダウンロードする

また、GPT-Image-2 の usage には 実際の token 数 が含まれますが、Grok Imagine 2 の usage は プレースホルダー（常に 1000 x n）です。usage を基にした課金集計スクリプトは、移行後に誤った数値を出力します。

2. size はエラーではなく静かに失敗しますGPT-Image-2 は厳密に検証し、無効な入力には通常 400 を返します。Grok Imagine 2 は寛容で、size、quality、style のような OpenAI 形式のフィールドは 黙って無視され、不正な aspect_ratio / resolution の値は 黙ってデフォルト値にフォールバックします。そのため、model だけを変更して size: "1536x1024" を削除し忘れると、リクエストは 200 を返して 1024x1024 の正方形画像を生成します — しかも、そのパラメータが無視されたことを示すものは何もありません。移行後は、最初の呼び出しで出力ピクセル寸法を確認し、aspect_ratio / resolution が実際に反映されたことを確かめてください。

3. 参照画像はもはやテキストから画像生成のエンドポイントに送れませんこの落とし穴はこのモデル特有です。参照画像を /v1/images/generations に送ると 200 が返り、参照は黙って破棄され、それでも課金されます。参照画像を使う呼び出しはすべて /v1/images/edits と multipart/form-data を使う必要があります — 上のエンドポイントを参照してください。

変更前と変更後

# Before: GPT-Image-2
resp = client.images.generate(
    model="gpt-image-2",
    prompt="Cyberpunk city on a rainy night",
    size="1536x1024",           # <- remove
    quality="high",             # <- remove
    output_format="jpeg"        # <- remove
)
img = base64.b64decode(resp.data[0].b64_json)

# After: Grok Imagine 2
resp = client.images.generate(
    model="grok-imagine-image",           # use grok-imagine-image-quality for higher fidelity
    prompt="Cyberpunk city on a rainy night",
    n=1,
    extra_body={
        "aspect_ratio": "16:9",           # <- replaces size
        "resolution": "1k",               # <- replaces the sizing role of quality
        "response_format": "b64_json"     # <- set explicitly to keep the parser unchanged
    }
)
img = base64.b64decode(resp.data[0].b64_json)

どちらを使うべきでしょうか？ マスクインペインティング、ピクセル単位で正確なカスタムサイズ、または最大 16 件の参照の融合が必要なら、GPT-Image-2 のままにしてください。予測しやすい料金（1 画像あたりの定額、2K の追加料金なし）、1回の呼び出しで複数画像（n、最大 10 枚）、または編集時の高いソース忠実度が必要なら、Grok Imagine 2 を選んでください。2つは共存できます — 同じ token で両方を呼び出せます。

主要パラメータ

`aspect_ratio` と `resolution`（出力サイズ）

これらを合わせて実際の出力ピクセル数が決まります。計測値はリクエストと完全に一致します：

`aspect_ratio`	`resolution: 1k`	`resolution: 2k`
`1:1`	1024x1024	2048x2048
`16:9`	1280x720	2816x1584
`9:16`	720x1280	1584x2816
`4:3`	1152x864	2368x1776
`3:4`	864x1152	1776x2368

両方のパラメータはテキストから画像生成にのみ適用されます。 /v1/images/edits ではエラーなく受け付けられますが、効果はありません。編集後の出力は常に入力参照画像の寸法に一致します（1280x720 in、1280x720 out）。出力サイズを変更するには、アップロード前に参照画像をトリミングまたはリサイズしてください。

バリデーションは緩く、タイプミスでもエラーは発生しません。 aspect_ratio の enum 外の値（例: 5:7、21:9）や resolution（例: 1K、1024x1024）は静かにデフォルトにフォールバックし、それでも画像が返されます。無効な response_format も同様に url にフォールバックします。したがって、出力が想定どおりでない場合は、まずパラメータ名のスペルを確認してください。ただし例外として resolution: "4k" は 503 model_service_unavailable を返します。つまりそのティアはサポートされていないという意味であり、チャネルが停止しているわけではありません — 1k / 2k に戻してください。

`n`（1回の呼び出しあたりの画像数）

1-10 を受け付けます。返される data 配列の長さは n に等しく、各画像に課金されます。0 は静かに 1 として扱われ、11 以上は 400 を返します。

ベストプラクティス

最初に決めてください：生成か編集か？

参照画像なし → /v1/images/generations。参照画像が1枚でもある場合、たとえ1ピクセルの微調整でも → /v1/images/edits。間違ったエンドポイントを選んでもエラーは出ず、予期しない画像が返るだけです。

クライアントのタイムアウトを360秒に設定してください

画像APIは同期処理です。2K は 15〜17 秒かかり、ピーク時やコールドスタート時にはさらに長くなることがあります。60秒のタイムアウトでは、課金対象のままのリクエストが不要に失敗してしまいます。

構図は prompt ではなく aspect_ratio で制御してください

このパラメータは実際に効くので、aspect_ratio: "16:9" のほうが prompt で「横長の構図」と指示するよりはるかに信頼できます。

解像度の段階は帯域幅で選んでください

2K は 1枚あたり 5〜6 MB のロスレスPNG、1K は 220〜300 KB のJPEGです — およそ20倍の差があります。モバイルや一括転送では 1K を推奨します。どちらの段階もコストは同じなので、選択基準は純粋に品質と帯域幅です。

編集時は「他はすべて変更しないでください」と伝えてください

「マフラーを赤に変えて、他はすべてまったく同じにしてください」のような指示は非常によく効きます — モデルはこの制約に強く従い、画像の残りの部分を保持します。

融合するときは画像を明示的に参照してください

image[] のアップロード順が「画像1 / 画像2 / 画像3」を意味します。「画像1の被写体を画像2のシーンに入れてください」と書くほうが、モデルに推測させるよりはるかに確実です。

再現性を seed に頼らないでください

このファミリーはseedをサポートしていないため、同じ prompt でも呼び出しごとに結果が変わります。再生成できると期待するのではなく、残したい画像は保存しておいてください。

バッチ処理はそのまま並行実行してください

同時実行数の制限はありません — 100 RPM でも余裕で動作します。チャネル容量にも十分余裕があるため、シリアルキューを作ったり追加のクォータを要求したりする必要はありません。

エラーコードと再試行

HTTP	コード	意味	推奨される対処
`400`	`invalid_image_request`	編集用エンドポイントが multipart ではなく JSON を受信しました	`multipart/form-data` アップロードに切り替えてください。再試行しないでください
`400`	`invalid_request`	パラメータが無効、または moderation によって prompt がブロックされました	どちらも同じコードです — まずパラメータを確認し、その後 prompt を修正してください
`415`	—	編集用エンドポイントでサポートされていないファイルフィールド名です	フィールド名を `image` または `image[]` に変更してください
`429`	—	レート制限を超過したか、残高が不足しています	指数バックオフを行い、アカウントの残高を確認してください
`503`	`model_service_unavailable`	サポートされていないパラメータ階層です（例: `resolution: 4k`）	障害ではありません — `1k` / `2k` に戻し、再試行しないでください
`503`	—	現在の Group に利用可能なチャネルがありません	Token の Group 設定を確認し、上の Group 設定を参照してください

クライアント向けガイダンス: 400 と 415 は決定的なので、再試行しても無意味です。代わりにアラートを上げてください。再試行する価値があるのは 429 とネットワーク層のタイムアウトのみで、その場合は指数バックオフを行い、試行回数は最大 3 回にしてください。400 invalid_request は「bad parameter」と「content blocked」の両方をカバーしており、レスポンスボディでは両者を区別できません。実用的な目安はレイテンシです: moderation のブロックは約 5〜6 秒で返ってきます。成功した生成（約 9 秒）より速いです。これは、ブロックが生成開始前に発生するためです。

よくある質問

なぜ、ベンダーのドキュメントでは JSON と示されているのに、/v1/images/edits に JSON を送ると 400 が返るのですか？

これは、APIYI ゲートウェイの編集エンドポイントが multipart/form-data のみを受け付けるのに対し、上流のベンダーのドキュメントは公開画像 URL を含む JSON 本文を説明しているためです。両者は異なります。このサイトのドキュメントに従ってください。正しい形式はファイルアップロードです:

curl -X POST "https://api.apiyi.com/v1/images/edits" \
  -H "Authorization: Bearer sk-your-api-key" \
  -F "model=grok-imagine-image" \
  -F "prompt=Change the scarf to red, keep everything else the same" \
  -F "[email protected]"

その利点は、画像ホスティングが不要なことです。公開 URL を用意するよりも、ローカルファイルを直接アップロードするほうが簡単です。完全な例は Image Editing API をご覧ください。

参照画像を text-to-image に送ったのに 200 が返り、結果が無関係なのはなぜですか？

これは想定どおりの挙動で、このモデルで最もよくある落とし穴です。/v1/images/generations は image / image_url / images を黙って無視し、prompt だけから生成し、通常どおり課金されます。エラーの兆候がないため、「編集が壊れている」と結論づけてしまいがちです。参照画像を使うワークフローでは必ず /v1/images/edits を使う必要があります。

なぜ resolution / aspect_ratio は編集エンドポイントに影響しないのですか？

編集後の出力サイズは入力した参照画像に従います。入力が 1280x720 なら出力も 1280x720、入力が 1024x1024 なら出力も 1024x1024 です。ここで resolution や aspect_ratio を渡してもエラーにはならず、何も起こりません。出力サイズを変えたい場合は、アップロード前に参照画像をトリミングまたはリサイズしてください。

なぜレスポンスに revised_prompt がないのですか？

このファミリーは revised_prompt を返さず、respect_moderation や model のようなフィールドも返しません。各 data[] エントリーは response_format に応じて url か b64_json のどちらか一方 を含みます。両方は入りません。レスポンスをパースする際に、これらのフィールドが存在すると仮定しないでください。

usage の token 数で billing を突き合わせることはできますか？

いいえ。 usage.prompt_tokens は実際の prompt 長に関係なく常に 1000 x n で、これはプレースホルダーです。このファミリーは画像ごとの定額でリクエスト単位課金です。実際の課金額は APIYI コンソールの課金記録をご利用ください。

なぜ 1K は JPEG なのに 2K は PNG なのですか？サイズがかなり違います

これは上流側の挙動です。resolution: 1k は JPEG（約 220-300 KB）を返し、resolution: 2k はロスレス PNG（約 5-6 MB）を返します。おおよそ 20 倍の差があります。URL の拡張子、HTTP Content-Type、実際のバイト列は互いに整合しているので、Content-Type を基準に安全に分岐できます。帯域に敏感なシナリオ（モバイル、バルク転送）では 1k を優先してください。どちらの階層も同じ料金なので、判断基準は純粋に品質です。

resolution: 4k で 503 が返ります。チャネルが落ちているのですか？

いいえ。 4k はこのファミリーでサポートされていない階層であり、ゲートウェイは 503 model_service_unavailable を返します。コード上は障害に見えますが、実際はパラメータの問題です。そのため、再試行しても解決しません。1k か 2k に戻してください。サポートされているのは 1k と 2k のみです。

なぜ無効なパラメータでエラーではなく、間違った画像が返るのですか？

このファミリーの検証は緩めです。無効な aspect_ratio（例: 5:7）、resolution（例: 1K、1024x1024）、および response_format（例: base64）はすべて黙ってデフォルトにフォールバックし、400 ではなく画像を返します。そのため、出力が期待と違うときは、まずパラメータ名の綴りを確認してください。特に、resolution の値は小文字の 1k / 2k です。

1 回の呼び出しで何枚の画像を生成できますか？

n は 1-10 を受け付け、返される data 配列の長さは n と同じです。各画像は課金対象です。0 は黙って 1 として扱われ、11 以上では 400 invalid_request が返ります。

seed ベースの再現性はサポートされていますか？

いいえ。 seed を渡してもエラーにはなりませんが、効果はありません。つまり、同じ prompt と同じ seed でも、呼び出しごとに異なる画像が返ります。再生成しようとするのではなく、再利用したい画像は保存してください。

公式の OpenAI SDK で呼び出せますか？

はい。どちらのエンドポイントも OpenAI の画像 API と互換です。base_url を https://api.apiyi.com/v1 に向けるだけです:

from openai import OpenAI
client = OpenAI(api_key="sk-your-api-key", base_url="https://api.apiyi.com/v1")

resp = client.images.generate(
    model="grok-imagine-image",
    prompt="a red wooden boat on an alpine lake at dawn",
    extra_body={"aspect_ratio": "16:9", "resolution": "1k"}
)

aspect_ratio と resolution は標準の OpenAI SDK フィールドではないため、extra_body で渡してください。

同時実行数の制限はありますか？バッチ生成はスロットリングされますか？

同時実行数の制限はありません。 100 RPM でも余裕で計測でき、429 もキュー拒否もなく、十分なチャネル容量に支えられています。直列キューを組んだり、追加のクォータを要求したりせず、並列に呼び出せます。実際に重要なのは timeout です。画像 API は同期処理なので、まだ正常に処理中で課金対象にもなっているリクエストを途中で切らないよう、クライアントの timeout を 360 秒 に設定してください。

コンテンツモデレーションはどのように動作し、ブロックをどう検知しますか？

このファミリーにはコンテンツモデレーションが適用されます。ブロックされたリクエストは、パラメータエラーとまったく同じエラーコードとメッセージで 400 invalid_request を返すため、レスポンスボディだけでは見分けられません。実用的な目安はレイテンシです。モデレーションによるブロックは約 5-6 秒で返り（ブロックが生成より先に起こります）、成功した画像は約 9 秒かかります。モデレーション結果にはある程度のランダム性もあるため、境界線上のコンテンツは再試行ごとに同じ挙動にならないことがあります。1 回の試行だけで結論を出さないでください。パラメータが正しいことを確認しても 400 が続く場合、prompt がモデレーションを引き起こした可能性が高いです。表現を見直してください。

/v1/chat/completions ിലൂടെ画像を生成できますか？

はい。ただし、推奨ルートではありません。このエンドポイントは標準的な chat 構造を返し、その content は markdown の画像リンクです:

![image](https://apac.ossforai.com/...)

これは Chatbox や LobeChat のような会話型クライアントに向いています。プログラムによる統合には、Images API を使用してください（/v1/images/generations と /v1/images/edits）— より豊富なパラメータ、より安定したレスポンス形状、そしてこのドキュメントとの整合性があります。

​概要

テキストから画像生成 API

画像編集 API

​APIYIでGrok Imagine 2を使う理由

OpenAI互換フォーマット

同時実行数の上限なし

一律料金、予測しやすいコスト

グローバルアクセス、障壁なし

充実したモデルエコシステム

専門サポート

​主な機能

2つの解像度帯

5種類のアスペクト比

1回あたり最大10枚

高速な生成

真の参照編集

マルチ画像融合

2つのレスポンス形式

OpenAI SDK対応

​価格

​グループ設定

​技術仕様

​エンドポイント

​GPT-Image-2 からの移行

​パラメータ対応表

​最も起こしやすい 3 つのミス

​変更前と変更後

​主要パラメータ

​aspect_ratio と resolution（出力サイズ）

​n（1回の呼び出しあたりの画像数）

​ベストプラクティス

​エラーコードと再試行

​よくある質問

​関連ドキュメント

概要

APIYIでGrok Imagine 2を使う理由

主な機能

価格

グループ設定

技術仕様

エンドポイント

GPT-Image-2 からの移行

パラメータ対応表

最も起こしやすい 3 つのミス

変更前と変更後

主要パラメータ

`aspect_ratio` と `resolution`（出力サイズ）

`n`（1回の呼び出しあたりの画像数）

ベストプラクティス

エラーコードと再試行

よくある質問

関連ドキュメント