内容更新日: 2026-09-18
非同期画像生成
画像生成モデルでは、1回の生成に通常20~120秒かかります。同期インターフェースの場合、クライアントはHTTP接続を結果が出るまで維持する必要があり、ゲートウェイ/プロキシの読み取りタイムアウトに遭遇しやすく、返されるbase64データも大きくなります。非同期モードでは、この処理を2回の呼び出しに分けます:- 送信:リクエストするとすぐに
202とタスクIDが返ります(1秒以内)。 - ポーリング:タスクIDを使って
GET /v1/tasks/{id}へ問い合わせ、完了したらresultに画像のhttps URLが入っています(永久にmedia.crazyrouter.comに保存)。base64は返しません。
モデル名、リクエストボディ、課金方式は同期とまったく同じです。 非同期は「いつ結果を取得するか」だけが異なり、同じAPIキーで一部のリクエストを同期、一部を非同期で使うことができます。タスクが失敗した場合は課金されません。
対応モデル
方法1:Geminiパス別名(Geminiクライアント推奨)
リクエストボディ、ヘッダー、クエリパラメータのどのバイトも変更せずに、動作のサフィックスを:generateContentから:asyncGenerateContentに変更するだけです。
cURL
202:
返された
modelは解析済みの内部モデル名(例えばgemini-3.1-flash-image-preview)で、課金ログと一致しますが、nano-banana-2で送信することに影響ありません。参考画像編集や同期と同じ方法で、partsにinlineData(base64)またはfileData(URL)を入れるだけです。:asyncGenerateContentは画像出力モデルのみ受付けます。テキストモデルを使うと400 async mode is only available for image modelsが返ります。ストリーミング動作:streamGenerateContentは非同期に対応していません。
方法2:OpenAI画像エンドポイント+Preferヘッダー
既存の/v1/images/generationsまたは/v1/images/editsリクエストにHTTPヘッダーPrefer: respond-asyncを追加するだけです。他は変更不要。リクエストボディフィールド"async": true(JSON)、またはフォームフィールドasync=true(multipart)でも同様に動作します。
Preference-Applied: respond-asyncが含まれ、本文は方法1と同様(202+タスクID)。
タスクの照会
404になります。2~3秒ごとにポーリングし、10分経っても完了しない場合は失敗とみなします。
ステータス
完了時のレスポンス(Gemini系)
resultは元のGemini GenerateContentResponseで、inlineDataを画像URL指向のfileDataに変更しただけです:
完了時のレスポンス(OpenAI系)
resultは同期/v1/images/*のレスポンスと同じ形式で、画像はdata[].urlにあります:
?inline=trueを追加すると、サーバー側で保存画像を再読込してinlineData / b64_json(推奨しません、画像が大きいと遅い)を返します。
失敗時のレスポンス
retryable: trueは新しいタスクを再送信できることを示します。システムは自動再試行しません。
冪等な送信
ネットワーク再試行で同じタスクが重複送信される場合もあります。送信リクエストにIdempotency-Key: <任意の文字列>ヘッダーを付けると、同じアカウントと同じキーで同じタスクIDが返ります(二回目は200が返り、202は返りません)、生成も課金も重複しません。