# レート制限 Source: https://aiand-docs-staging.pages.dev/ja/reference/rate-limits/ ai& は共有負荷下でプラットフォームを健全に保つため、組織単位でレート制限を適用します。上限はティアによって決まり、推論エンドポイントに適用されます — 管理 API には別途 (緩めの) 制限があります。 ## ティア | ティア | 説明 | |--------|------| | **Tier 0** | 評価用ティア。分あたり上限が低め。開発や小規模プロジェクト向け。新規組織はこのティアから始まります。 | | **Tier 1** | 本番用ティア。上限が高く、高スループットモデルへもアクセス可能。初回の決済成功時に自動昇格します。 | ## 計測対象 各リクエストは 6 つのバケットで判定されます — モデル単位の 4 つと、組織単位の 2 つ (global): - **Per-model RPM** — 特定モデルに対する 1 分間のリクエスト数。 - **Per-model Input TPM** — 特定モデルに対する 1 分間の入力トークン数 (リクエストボディから事前に見積もり)。 - **Per-model Output TPM** — 特定モデルに対する 1 分間の出力トークン数 (レスポンス完了後に計上)。 - **Per-model Concurrency** — 特定モデルに対する同時実行中リクエスト数の上限。 - **Global RPM** — **すべてのモデル**を合わせた 1 分間のリクエスト数。 - **Global Concurrency** — すべてのモデルを合わせた同時実行中リクエスト数の上限。 いずれかのバケットが先に埋まった時点でスロットルされます。 ## ヘッダ 認証を通過してモデルの受付判定に到達したすべての推論リクエスト — `200`、ストリーミング、およびこれら 6 つのバケットによる `429` を含む — に、適用される各バケットの状態が付与されます。最初の 2 行は OpenAI のヘッダ名と形式をそのまま使っているため、既にこれらを読み取るツールはそのまま動作します。残りは同じパターンを拡張したものです。 | バケット | ヘッダ | |----------|--------| | Per-model RPM | `x-ratelimit-limit-requests`, `x-ratelimit-remaining-requests`, `x-ratelimit-reset-requests` | | Per-model Input TPM | `x-ratelimit-limit-tokens`, `x-ratelimit-remaining-tokens`, `x-ratelimit-reset-tokens` | | Per-model Output TPM | `x-ratelimit-limit-output-tokens`, `x-ratelimit-remaining-output-tokens`, `x-ratelimit-reset-output-tokens` | | Per-model Concurrency | `x-ratelimit-limit-concurrency`, `x-ratelimit-remaining-concurrency` | | Global RPM | `x-ratelimit-limit-global-requests`, `x-ratelimit-remaining-global-requests`, `x-ratelimit-reset-global-requests` | | Global Concurrency | `x-ratelimit-limit-global-concurrency`, `x-ratelimit-remaining-global-concurrency` | - `limit-*` はバケットの上限、`remaining-*` は現時点の残量です。`remaining-tokens` は入力トークンのみを数えます — 出力トークンはレスポンス完了後に計上されます。 - `reset-*` はそのバケットが再び満杯になるまでの時間で、`45s` や `6m0s` のような duration 形式です。concurrency バケットには reset がありません: 実行中リクエストの完了とともに空きます。 - ティアに上限がないバケット (Input/Output TPM や global の上限が `0`) は省略されます。`limit-requests` または `limit-concurrency` が `0` の場合は逆で、そのモデルはあなたのティアには閉じており、待っても開きません。 これら 6 つのモデルバケットによる `429 Too Many Requests` では、さらに以下が追加されます: | ヘッダ | 意味 | |--------|------| | `X-RateLimit-Policy` | 拒否したバケット: `rpm` / `global_rpm` / `input_tpm` / `output_tpm` / `concurrency` / `global_concurrency`。 | | `Retry-After` | このリクエストが通るようになるまでの秒数 — バケット全体の回復を待つ `reset-*` より短くなります。`concurrency` と `global_concurrency` の拒否では付かない — 実行中リクエストの完了/キャンセルで解消する。 | 以前の `X-RateLimit-Limit` と `X-RateLimit-Remaining` は、非推奨の互換エイリアスとして引き続き返されます。新規の実装では上記の明示的なヘッダを使用してください。認証スロットルはモデルの受付判定より前に行われるため、`Retry-After` のみが付き、`X-RateLimit-Policy` とバケットヘッダは付きません。`GET /v1/models` のような公開カタログエンドポイントはこの方式では計測されず、これらのヘッダは付きません。 レート制限以外のヘッダは [レスポンスヘッダ](/ja/reference/response-headers/) を参照。 ## 429 レスポンス スロットルされると `429 Too Many Requests` が返されます。2 種類のバケットは解消の仕方が異なるため、`X-RateLimit-Policy` を確認して拒否の種類に応じて対処してください — 同じ「バックオフして再試行」は concurrency の拒否には当てはまりません。 **時間ベースの拒否** — `rpm` / `global_rpm` / `input_tpm` / `output_tpm`。ウィンドウの経過とともに回復します。`Retry-After` が最小の安全な待機時間を示すので、少なくともその時間だけ待ってから、ジッタ付きの指数バックオフで再試行してください。 **concurrency の拒否** — `concurrency` / `global_concurrency`。時間では解消せず、実行中のリクエストが完了またはキャンセルされたときにのみ空くため、`Retry-After` は付きません。新たに送信する前に、実行中のリクエストを消化させる (または同時実行数を下げる) 必要があります。