429 と再試行によるリクエスト集中を防ぐ
リクエスト頻度と同時実行数を分け、無制限の再送を避け、確認と新規生成を別々に制御します。
技術確認日:
RPM と同時実行数は別
RPM は 1 分あたりの新規リクエスト数で、同時実行数は処理中の仕事の数です。生成が長いと低い RPM でも実行中タスクが増えます。送信頻度と稼働中ジョブ数を両方制限してください。画像や別アカウントの値を流用せず、プラットフォーム、キー、モデル、上流で制限が異なり変更され得ると考えます。高速なクライアントでも上流容量は増えません。
429 の発生元を確認
HTTP 429 はリクエスト過多を表します。Retry-After が返る場合がありますが、必須とは限りません。MaxAPI ではエラーコードと履歴を確認し、受付拒否、上流制限、タスク失敗を区別します。新規送信を抑え、既存 ID は保持してください。1 件のユーザーリクエストに複数チャネル試行が含まれることがあり、チャネル件数を固有ジョブ数として使わないでください。
GET と POST の再試行方針を分ける
一時的な確認 GET の失敗は、上限付きバックオフと揺らぎを使い同じタスクに再試行できます。一方 POST の再送は新しい仕事と費用につながります。配布例は HTTP・通信エラー時に自動再送せず停止します。再試行を追加するなら既存タスクの有無を確認し、有効なサーバー待機指示と試行上限を守り、運用者が失敗を確認できるようにしてください。不正入力の無変更再送や安全制限の回避は行いません。
受付と結果を別々に観測
固有の送信、受付済みタスク、実行中、最終失敗、確認通信を別々に記録します。制限された診断ログにはリクエスト ID とタスク ID を残し、キー、非公開プロンプト、参照 URL 全体は除外します。待機列が増えたら再送で負荷を増幅せず同時実行数を下げます。キュー容量と表示上の待機方針は自分のアプリで決め、一定時間内の完了保証と混同しないでください。
モデル別パラメーター
公開設定のスナップショットであり、現在の稼働状況ではありません。パラメーター、ルート、参照画像の上限は各モデルページを確認してください。
- Gemini 3.1 Flash Image Preview
google/gemini-3.1-flash-image-preview - Nanobanana Pro
google/gemini-3-pro-image-preview - GPT Image 2
openai/gpt-image-2