レート制限とクォータ

ゲートウェイは各リクエストに多層の制限を適用します。外側から順に：レート（RPM/同時実行数）→ キーの利用上限 → アカウント残高 → リクエストサイズ。各層がどのエラーを返すかを理解することが、正しいリトライロジックの前提になります。

RPM と同時実行数

アカウントごとに毎分リクエスト数（RPM）と同時セッション数の上限が設定されます。超過すると 429 が返ります：

• rpm_exceeded：毎分リクエスト数の超過。エラーメッセージに上限値が含まれます。バックオフして再試行してください。
• concurrent_exceeded：同時に処理中のリクエスト数の超過。実行中のリクエストの完了を待つか、クライアントの並列数を下げてください。

注意：モデル一覧などのメタデータリクエストも RPM にカウントされます。ループで高頻度にポーリングしないでください。

キーの利用上限

各キーには USD 建ての利用上限を設定でき、日/週/月ごとの自動リセットも選べます。上限に達すると 402（key_quota_exhausted）が返り、リセットまたは上限変更まで拒否されます。ワークロードや環境ごとに独立した予算を割り当てるのに便利です。

アカウント残高

残高が不足すると 402（balance_exhausted）が返ります。チャージすると再開されます。

リクエストサイズ

• 413（body_too_large）：リクエストボディがこのエンドポイントの上限を超えています。対話系エンドポイントはインラインメディアを許容し、テキスト専用エンドポイント（embeddings など）は上限が小さめです。インラインメディアを圧縮するか、大きなペイロードに適したエンドポイントを使ってください。
• 503（server_busy）：ゲートウェイの処理中リクエストボディの合計サイズが上限に達しました。あなたのリクエストが大きすぎるのではなく、いま全体が混雑しています。しばらくして再試行してください。

実践的なアドバイス

• 429/502/503 は指数バックオフでリトライし、402 はリトライではなくアラートにしてください。エラー処理とリトライ参照。
• 429 と 402 の発生頻度を監視してください。前者は並列数を下げるか上限引き上げの相談を、後者はチャージまたは予算調整を意味します。
• 長時間タスクとストリーミングにはタイムアウトの余裕を持たせ、クライアントが早期に切断しないようにしてください（ストリーミング参照）。
• ワークロードごとにキーを分けてそれぞれ上限を設定すれば、1 つの超過が他に波及しません。