OpenAI API が "You exceeded your current quota" や insufficient_quota を返したら、最初に再試行回数を増やすべきではありません。多くの場合、それは通常の rate limit ではなく、現在の組織、プロジェクト、月次予算、前払い残高、支払い状態、またはモデル経路に利用可能な API 枠がないという意味です。
安全な最初の答えは、OpenAI Platform の Billing と Limits を開き、API key が属する組織とプロジェクトを確認し、前払い残高、月次予算、approved usage limit、支払い状態、モデル権限を見てから、同じプロジェクトで小さなリクエストを一回送ることです。利用枠が使えると確認してから、RPM、TPM、並列数、レスポンスヘッダー、backoff を見ます。
2026 年 4 月 29 日時点で、OpenAI の rate-limit guide は正確な現在値を Platform Limits ページに置き、production best practices は billing limits と approved usage limits をアカウント管理の項目として扱っています。安全な運用順序は、変わりやすい数値表ではなく、事故中に実行できる確認手順として持つべきです。
まず読む短い答え
| 質問 | 答え |
|---|---|
| このエラーは何を意味しますか？ | 現在の API 経路に、利用可能な枠、残高、予算、支払い、プロジェクト、モデル権限がない可能性があります。 |
| rate limit と同じですか？ | 違います。insufficient_quota は請求/枠の分岐で、RPM/TPM は別分岐です。 |
| 最初に確認するものは？ | Platform Billing、Limits、月次予算、組織、プロジェクト、key、モデル権限です。 |
| ChatGPT Plus や Pro で直りますか？ | 自動では直りません。ChatGPT 契約は Platform API 残高ではありません。 |
| key を変えるべきですか？ | 同じプロジェクト内で key を変えても枠は増えません。 |
| いつ rate-limit headers を見ますか？ | 利用枠が使えることを確認した後、または request/token 圧力が証拠として見えるときです。 |
コード変更の前に所有者を決める
重要なのは、利用可能性と処理量を分けることです。処理量の問題は、その経路自体は許可されているが、リクエスト数、トークン、並列数、burst が多すぎる状態です。利用可能性の問題は、その経路が今、残高、予算、支払い承認、プロジェクト範囲、モデルアクセスを持っていない状態です。
エラー本文に insufficient_quota がある、または "You exceeded your current quota, please check your plan and billing details" と出るなら、backoff はアプリを静かにするだけで、枠を作ることはできません。強い再試行はログを汚し、アカウント状態という本当の所有者を見えにくくします。
証拠が RPM、TPM、remaining headers、reset window、burst traffic、concurrency を指すなら、OpenAI API rate limits を使います。証拠が billing details、trial、prepaid credits、月次予算、組織、プロジェクト、モデル権限を指すなら、quota 分岐に残ります。
OpenAI の公式文書もこの分け方に合っています。rate-limits guide は現在の上限を Limits page で確認し、request/token windows を response headers で読むように示します。production best practices は billing limits と approved usage limits をアカウントの制御として扱います。記事側は古い数値表ではなく、確認場所を明確にするべきです。
五つの確認を順番に行う
| 確認 | 見るもの | 理由 |
|---|---|---|
| 請求経路 | Platform billing が有効で、支払い状態が健全か。 | API 利用は Platform 側の請求であり、ChatGPT 契約だけではありません。 |
| 前払い残高 | credits があり、有効期限内で、利用中のアカウントにあるか。 | コードが正しくても、利用可能な残高がなければ失敗します。 |
| 月次予算 | project/account が self-imposed cap や approved spend ceiling に当たっていないか。 | 残高を追加しても低い budget cap が残ることがあります。 |
| 組織とプロジェクト | key が、確認した Billing/Limits と同じ組織・プロジェクトに属するか。 | 間違った組織を見ると、正常なアカウントが壊れて見えます。 |
| モデル経路 | そのプロジェクトと tier で要求モデルを使えるか。 | 残高があっても、すべてのモデル経路が使えるとは限りません。 |
これらを一つの「請求は問題ない」にまとめないでください。カードは有効でも前払い残高がないことがあります。残高があっても月次予算が低すぎることがあります。組織は支払い済みでも、アプリは別プロジェクトの key を使っているかもしれません。安いモデルは動いても、別のモデル経路は使えないことがあります。
ダッシュボード確認後の最もきれいなテストは、同じ key、同じ組織、同じプロジェクト、同じ endpoint family、同じモデル経路で小さなリクエストを送ることです。成功したら、環境変数、wrapper 設定、deployment secrets のずれを見ます。まだ insufficient_quota なら、所有者はアカウント枠または経路アクセスです。
復旧の順序
診断した順に修正します。
- 正しい Platform 組織とプロジェクトにいることを確認する。
- Billing で残高、支払い方法、credit 状態、invoice health を見る。
- Limits で approved usage limit、月次予算、モデル可用性、project scope を見る。
- prepaid credits を追加した直後なら、反映を待ってから判断する。
- 同じプロジェクトの最小 API リクエストを実行してから、queue や worker を再起動する。
- 最後に RPM、TPM、並列数、token budget、response-header backoff を調整する。
この順序は保守的ですが、二つの高いミスを防ぎます。間違ったアカウントへ入金することと、アカウント状態の問題に retry logic を実装することです。最低購入額、credit の期限、usage tier のような変わりやすい事実は、その場で OpenAI Billing と Help Center を確認してください。
key 作成直後や trial の期待が曖昧なら、OpenAI API key free trial を確認します。組織や project scope が不明なら、コードの前に組織とプロジェクト設定を分けて確認します。
wrapper と連携ツール
Zapier、Make、n8n、社内 gateway、OpenAI-compatible provider は OpenAI 風の quota message を表示することがありますが、請求の所有者が分かりにくい場合があります。実際に OpenAI へ送られる credential が誰のものかを確認します。
連携が自分の OpenAI API key を使うなら、自分の Platform account を診断します。連携が managed provider account を使うなら、wrapper の plan、connector quota、workspace budget を先に診断します。両方選べるなら、自分の key で OpenAI Platform へ直接最小リクエストを送り、wrapper path と比較します。
local script、production worker、CI、user-facing app が同じ予算を使うとは限りません。本番だけ別プロジェクト、古い key、別組織、独自 cap 付き gateway を使っていることがあります。直接 API テストは、wrapper を外して Platform quota 自体の可用性を確認できます。
停止ルール
エラー本文が quota や billing を指すなら、次を止めます。
- 同じ無資金プロジェクト内で key を回す。
- quota error を突破するために retry count を増やす。
- ChatGPT subscription を買えば Platform API credit が増えると考える。
- 公開の quota table を自分のアカウント状態の証拠にする。
- usable spend を確認する前に higher rate limits を求める。
代わりに、exact error body、timestamp、organization、project、key source、endpoint、model、dashboard state を保存します。最小の直接リクエスト結果、wrapper path との違い、最近の billing action、反映待ち時間も記録します。support や limit increase にはスクリーンショットだけではなく、この証拠パケットを渡します。
証拠パケット
support や limit increase には、exact error text、error type、HTTP status、model、endpoint family、project、organization、timezone 付き timestamp、Billing page state、Limits page state、最近の payment/credit changes、minimal same-project retest の結果を入れます。
アカウントが使える状態になった後に必要なのが throughput 増加なら、証拠は request per minute、tokens per minute、concurrency、queue size、reset headers、burst や token output をどう抑えたかになります。これは quota ではなく rate-limit 分岐です。
よくある質問
API key 作成直後に quota exceeded になるのはなぜですか？
API key は credential です。billing、credits、budget、モデルアクセスを保証しません。key を作った同じ組織とプロジェクトを確認してください。
credits を追加すればすぐ直りますか？
短い反映待ちが必要な場合があります。同じプロジェクトで再確認し、まだ失敗するなら credits が実際に使うアカウントとプロジェクトにあるかを見ます。
insufficient_quota と too many requests は同じですか？
違います。too many requests は処理量分岐です。insufficient_quota は利用可能性分岐です。HTTP status が似ていても修正は違います。
dashboard には余裕があるのにアプリが失敗します
アプリが別の organization、project、key、wrapper account、model route、environment variable を使っている可能性があります。直接最小リクエストとアプリ経路を比較してください。
higher limit を申請すべきですか？
usable quota があり、証拠が throughput または approved usage ceiling を指すときだけです。payment、balance、monthly budget、project scope が所有者なら、先にそれを直します。