レート制限
Rate Limit
概要（サマリー）
レート制限とは、APIが一定時間に受け付ける回数や量へ設ける上限である。生成AIのAPIでは、1分あたりのリクエスト数（RPM）と、1分あたりのトークン数（TPM）のように、複数の基準が並ぶことが多い。
窓口の整理券に似ている。1枚の依頼が長くても短くても、枚数が上限ならそれ以上は並ばせない。枚数は空いていても、トークンの合計が先に上限へ達すれば、同じように止まる。
上限は提供者、モデル、契約で違う。超えると、多くのAPIはステータスコード429を返す。しばらく待ってから送り直す対象と、支払いの確認が必要な対象は、番号だけでは区別できない。
詳細解説
なぜ上限があるのか
OpenAIは、レート制限の理由を3つ説明している。乱用でサービスを詰まらせないこと、一部の利用者だけで容量を占有しないこと、設備全体の負荷を急増させないことである。
生成AIに限らない。地図、天気、決済のAPIでも、同じ考え方の上限がある。無料枠で試していると、少ない回数で先に当たる。
どの数字が先に当たるか
基準は一つではない。OpenAIの例では、RPM、1日あたりのリクエスト数、TPM、1日あたりのトークン数、画像なら1分あたりの枚数などが並ぶ。どれか一つに達した時点で、その期間の追加は拒否される。
20リクエストがRPMの上限なら、各リクエストが短いトークンでも20回で止まる。逆に、回数は残っていても、長い入力を連続で送るとTPMが先に尽きる。
モデルごとに上限が違い、複数モデルで枠を共有することもある。アカウント画面の数字を、別のモデルへ流用しない。
OpenAIでは、上限は組織とプロジェクトに付く。アプリのエンドユーザー一人ずつには、自動では付かない。自分のアプリが多くの人で同じAPIキーを使うなら、利用者ごとの上限はこちらで設ける。そうしないと、一人の連打で全員分の枠が消える。
429でも、待って直るとは限らない
一時的な回数超過は、429の rate_limit_error で返ることがある。応答に Retry-After があれば、そこに書かれた秒数は待つ下限である。その秒数より早く送り直さない。複数の処理が同じ秒に再送しないよう、少しだけランダムな待ちも足す。
待っても直らない429がある。月間の利用上限や、自分で設定した支出のハード上限に達した場合である。この場合は待つのではなく、契約、残高、上限設定を確認する。
モデル側の混雑は、429ではなく503のことがある。OpenAIは、急な増加を429、モデルの過負荷を503と分けている。番号と、本文のエラーコードの両方を見る。
失敗したリクエストも、その1分間の回数に数えられることがある。失敗のたびにすぐに再送すると、枠をさらに消費する。
再送の伸ばし方
公式の案内は、指数バックオフである。短い待ちから始め、失敗のたびに待ちを長くし、回数と合計時間に上限を付ける。
次は考え方を示す擬似コードである。call_api() や result の項目名は、使うSDKに合わせて読み替える。
delay_seconds = 1
for attempt in range(5):
result = call_api()
if result.ok:
break
if not result.retryable:
raise RuntimeError("支払い上限や認証の問題。再送せず設定を確認する")
wait = max(delay_seconds, result.retry_after_seconds or 0)
time.sleep(wait + random.uniform(0, 1))
delay_seconds = min(delay_seconds * 2, 60)
retryable は、一時的な429や503のように、待てば通る可能性があるエラーかどうかの判定である。Retry-After があればその秒数以上待ち、random.uniform で少しずらす。
SDKがすでに再送しているなら、アプリ側の再送と二重にしない。再送の段数が掛け算になると、1回の操作が何十回ものリクエストになる。
すぐ応答が要らない大量処理は、同期APIのRPMを消費しないバッチAPIが用意されていることがある。会話の返答のように待たせる処理とは分ける。
コンテキストウィンドウとの違い
コンテキストウィンドウは、1回の依頼に載せられる量である。レート制限は、時間あたりに何回、合計どれだけのトークンを送れるかである。
1回は窓に収まっていても、連続して送ればレート制限に当たる。逆に、1回の入力が長すぎて窓を超えるエラーは、回数を空けても同じ入力のままでは成功しない。
AIコーディングとの関係
エージェントがファイルを読むたびにAPIを呼ぶと、RPMをまとめて使う。短い修正のつもりが、探索の往復で429になる。
AIに再送処理を書かせるときは、429を一律で再送しないよう指定する。Retry-After を尊重すること、支出上限や認証エラーは止めること、再送回数の上限を書くことを依頼に含める。
自分用のスクリプトでも、ループの中で待たずに投げない。失敗ログを見ずに再実行すると、同じ分間の枠を自分で埋め続ける。
よくある勘違い
1回の文章が長すぎるエラーと同じ？
別である。長い入力が1回の窓に入らない問題と、時間あたりの回数や合計トークンの上限は、メッセージも対処も違う。
429なら待てば必ず通る？
一時的な上限なら、指定された秒数のあとで通ることがある。残高や月間上限が原因の429は、待っても解消しない。
APIキーを分ければ、エンドユーザーごとの制限になる？
提供者の上限は、組織やプロジェクトに付くことがある。利用者ごとの公平さは、アプリ側で回数を数えないと実現しない。
失敗したリクエストは回数に入らない？
入ることがある。すぐに連打すると、成功しないまま枠だけが減る。
まとめ
- レート制限は、一定時間あたりのリクエスト数やトークン数の上限である
- 複数の基準があり、どれか一つに達した時点で追加の依頼が拒否される
- 一時的な超過は429と Retry-After で待つのが基本である
- 支払い上限や認証エラーは、再送では解消しない
- 1回の依頼に載せられる量の上限とは別の制限である
情報ソース
より詳しくAIに聞いてみよう
- レート制限を、窓口の整理券のたとえで説明してください。
- RPMとTPMの違いを、短いリクエストを大量に送る例で教えてください。
- 429と503の違いを、待ってよい場合と確認が必要な場合に分けてください。
- 1回に載せられる量の上限と、時間あたりの回数の上限を、混同しない説明にしてください。
- AIに、Retry-Afterを尊重し、再送は最大3回で止める処理の条件を書かせてください。