情報確認日：2026年10月15日
OpenAI APIの429は、一時的なレート制限なら待機・減速で再試行できますが、クレジット残高や強制予算上限は、短い待機・再送では解消しません。残高の対応、管理者による上限対応、月次上限のリセット時期を確認します。HTTP番号に加え、エラー本文のerror.codeと利用組織・プロジェクトを確認します。ChatGPTの契約画面ではなく、APIの利用状況と上限を見ることが必要です。
最初に、エラー本文を読む
公式のエラーコード表は、同じ429でも原因を分けています。アプリが「利用制限」とだけ表示する場合は、開発者や管理者に元のエラーを確認します。
| エラーの例 | 主な意味 | 次の確認 |
|---|---|---|
| レート制限、slow_down | リクエスト過多、急な増加 | 待機時間と送信ペース |
| credit_balance_exhausted | 前払いクレジット残高なし | 残高・契約側の対応 |
| project_spend_limit_exceeded | プロジェクトの強制支出上限 | 対象プロジェクトの設定 |
| organization_spend_limit_exceeded | 組織の強制支出上限 | 組織の設定・管理者 |
| organization_usage_limit_exceeded | OpenAIが定めた利用上限 | 承認済み利用枠・サポート |
請求関連では、広いerror.typeがinsufficient_quotaでも、error.codeで具体的な原因を区別できると説明されています。typeだけを見て、すべてを同じ待機処理へ送らないようにします。
料金や上限を変更する判断は管理者の範囲です。動作を直すために、承認なく上限を解除したり追加購入したりする手順にはしません。
リクエスト数とトークン数は、別の制限
レート制限の公式説明には、1分当たりのリクエスト数RPMやトークン数TPM、日単位の制限などが示されています。少ない回数でも大きな資料を毎回送れば、トークンの側へ先に達することがあります。
上限はユーザー一人の会話回数ではなく、組織・プロジェクト、モデルなどの条件で決まります。同じプロジェクトの別アプリが同時に利用していれば、自分の送信が少なくても枠を使います。モデル群で共有する制限もあります。
さらにslow_downは、RPM・TPMの範囲内でも、通信量が急に増えた場合に起き得ると説明されています。枠の最大値だけを確認して「上限未満だから原因は別」と決めないことも必要です。
一時的な制限では、指定された時間以上待つ
応答に有効なRetry-Afterがあれば、それは再試行までに待つ最小の時間です。短く切り詰めず、少なくとも指定時間を待ちます。多数の処理が同時に再開しないよう、小さなランダムな遅延を加える方法も公式に案内されています。
ヘッダーがない場合や値が無効な場合は、失敗するたびに間隔を広げる指数バックオフを使います。ただし、試行回数と全体の待機時間に上限を設けます。終了条件なしのループにすると、仕事が終わらないまま呼出しを続けてしまいます。
SDKも再試行を行う場合があります。アプリ側のループと重なれば、想定より多い回数を送ります。インストールしているSDKのバージョンと設定を確認し、SDKの再試行を含む総数・総時間で管理してください。
指定された待機がSDKやアプリの最大待機を超えるなら、より早く送り直すのでなく、処理を延期する設計にします。1回の通信のタイムアウトと、仕事全体の締切も別に扱います。
通信量を減らす場所を選ぶ
多数の作業を同時に開始しているなら、同時実行数を絞り、一定のペースで送ります。トークンが原因なら、不要な過去履歴、毎回付ける同じ長文資料、必要以上に大きな出力条件を見直します。
入力の切り詰めは、答えに必要な条件まで落とさない範囲で行います。速く送れるようになっても、資料の要点を失えば結果は使えません。仕事を止めた理由と、減らした範囲を記録して比較します。
即時の応答が不要な大量処理は、Batch等の別の処理方式を検討できます。ただし、別の制限や納期があるため、切り替えれば上限問題が必ず消えると考えないでください。
予算の通知と、強制停止は異なる
現行の公式表では、Spend alertは通知を出してAPI通信を続け、Hard spend limitは対象のリクエストを429で止めます。通知額を設定したことだけで、自動停止するとは限りません。
組織・プロジェクトの強制月次支出上限に達した場合は、管理者による上限の変更等の対応、または月次上限のリセット後にアクセスが再開する条件を確認します。一時的なレート制限のバックオフと、月次の予算期間を分けて扱います。
管理者はAPIダッシュボードで、利用組織、プロジェクト、残高、支出上限、OpenAIが承認した利用枠を確認します。上限を変更できない利用者は、エラーコードと対象を管理者へ伝えます。
問い合わせには、発生日時、モデル・エンドポイント、組織とプロジェクト、エラーコード、応答のrequest ID、送信ペースをまとめます。APIキーや個人情報を含む入力全文は、不要なら添えません。
なお、現行説明で一時的なモデル過負荷は503とserver_is_overloadedです。429以外にも同じように待機が必要な場合があります。番号と本文をセットで読むと、再試行を続ける問題と、管理側で対応する問題を切り分けられます。
参照資料
あわせて読みたい記事
執筆・検証：カネさん（政経プラスチャンネル運営）＋ ChatGPT
