Codex 429 Too Many Requests 対処
Codex で長めの作業を依頼していたら突然「429 Too Many Requests」が返ってきた、という相談はよくあります。これは Codex 側の不具合ではなく、API のレート制限を一時的に超えたときに OpenAI が返すエラーで、原因は明確、対処も決まっています。
本記事では、429 Too Many Requests エラーが Codex で発生する仕組み、OpenAI 公式が示す 3 段階の対処、Codex 製品(CLI / IDE / Cloud / ChatGPT 内 Codex)を使う上での実務的な判断軸を整理します。
目次 (8)
429 Too Many Requests は Codex のレート制限超過エラー
OpenAI 公式 Help Center は、429 を「組織のレート制限(maximum number of requests and tokens that can be submitted per minute)を超えたときに返るエラー」と定義しています。Codex API もこの仕組みを共有しており、Codex CLI / IDE 拡張 / Codex Cloud のいずれを使っていても同じ条件で発生します。
代表的なエラーメッセージは「RateLimitError: Rate limit reached for default-codex in organization org-{id} on requests per min. Limit: 20.000000 / min. Current: 24.000000 / min.」のように、上限値と現在値の両方が示されるパターンです。Codex でこの形式が出れば、「自分のプランで決まっている上限を超えた」という意味になります。
つまり 429 は、Codex の故障や OpenAI 全体の障害ではなく、自分の利用条件と作業量の関係で起きる正常系のエラーです。Codex 側の機能を疑う前に、まず利用状況を確認するのが正解です。
1 分あたりのリクエスト数 / トークン数を超えると発生する
レート制限は「1 分あたりのリクエスト数(RPM)」と「1 分あたりのトークン数(TPM)」の両方で管理されています。たとえば 20 RPM のプランで Codex を使っていれば、同じ 1 分の中で 21 回目のリクエストを送った時点で 429 が返ります。リクエスト 1 回あたりのトークン数が多ければ TPM 側で先に上限に当たります。
Codex CLI で長尺タスクを実行している場合、内部的には「リポジトリ読解 → ファイル編集 → テスト実行 → 修正提案」と複数の API 呼び出しを連続で行うため、1 分の中に多数のリクエストが集中しがちです。Codex Cloud で複数候補を並列に走らせる場合や、IDE 拡張で複数ファイルを同時に編集させる場合も同じ理由で 429 が出やすくなります。
ChatGPT Plus / Pro / Business / Enterprise / Edu のサブスク枠から Codex を使うケースでは、API のような細かい RPM/TPM ではなく、一定期間ごとに上限がリセットされる「利用上限」モデルが適用されます。OpenAI Developer Community でも 2026 年 4 月 28 日に「Codex Rate limits reset for all paid plans」が告知されており、サブスク側の枠は時間経過で復帰する設計です。
対処 1 — exponential backoff で自動リトライする
OpenAI 公式 Cookbook が最初に勧める対処は、自動リトライ + exponential backoff(指数バックオフ)です。429 が返ったら短い待ち時間でリトライし、まだ 429 なら待ち時間を倍々に増やしながらリトライを続けます。短時間のスパイクで 429 になったケースは、これだけで多くが解消します。
具体的には、初回 1 秒待ち、429 が続けば 2 秒、4 秒、8 秒、と倍にしていく実装が一般的です。ランダム要素(jitter)を加えると、複数クライアントが同時にリトライしてさらに 429 を悪化させる「サンダリング・ハード」を避けられます。Codex CLI などのクライアント側でも、既定で軽いリトライは入っていますが、長時間タスクでは自前の wrapping を入れたほうが安定します。
リトライの上限(回数 or 累計待ち時間)を決めておくのも重要です。30 秒〜数分粘っても 429 が続くなら、原因はスパイクではなく恒常的な上限超過です。次の対処に切り替える判断材料になります。
対処 2 — 並列実行をスロットルする
Codex Cloud で複数の修正案を並列に走らせる、社内ツールから Codex API を多数呼ぶ、といった「同時実行が多い」場面では、リトライよりも 並列度のスロットル(throttle)が効きます。OpenAI 公式は parallel processor のサンプル api_request_parallel_processor.py を提供しており、リクエスト並列度と RPM/TPM の上限を引数で受けて、自動でレートを守りながら投げ続ける設計になっています。
業務で Codex API を組み込む場合は、自前の queue + worker 実装より、こうした参考スクリプトをベースに調整するほうが事故が少ない構成です。「ピーク時に並列を絞る」「夜間バッチでは並列を上げる」といった可変運用も、スロットル機構が前提にあれば自然に実装できます。
Codex CLI を 1 ユーザーが対話的に使う範囲では、並列度の調整より対処 1(リトライ)で足ります。並列を上げているのは多くの場合 Codex Cloud 利用時か API を直接叩いている統合システム側です。
対処 3 — Codex 利用枠を上位プランに引き上げる
リトライ・スロットルでも 429 が頻発するなら、上限自体を引き上げる必要があります。Codex の利用枠は、Codex 製品経由なら ChatGPT サブスクのプランに紐づきます。Plus → Pro / Business → Enterprise / Edu の順に Codex 利用上限が上がる構成で、API 直接利用の場合は Tier(支払い実績による段階)で RPM/TPM が上がります。
「短期スパイクではない、定常的に 429」という体感がある場合は、プラン引き上げ or Tier 引き上げが恒久対策です。逆に「特定の時間帯だけ 429」「週末だけ 429」といった偏りがあるなら、対処 1・2 の運用改善で吸収できる余地があります。
なお OpenAI Developer Community では「2 倍レート制限のプロモが終了して、上限に当たるのが早くなった」という報告も出ています。プラン上の上限変動は時期によって起きるため、429 が増えたタイミングで OpenAI 公式アナウンスを確認するのも実務上の習慣にしておきたいところです。
残量の確認方法とリセットタイミング
Codex の利用枠を使い切る前に「あとどれくらい残っているか」を見ておくと、429 自体を避けやすくなります。Codex 製品から ChatGPT サブスク枠を消費する経路では、ChatGPT 上の利用状況や Codex 側の表示で残量を確認できます。OpenAI Developer Community でも「rate limit reset が分かりにくい」という意見が継続的に出ており、可視化は完璧ではないものの、確認手段はあります。
API 直接利用の場合は、レスポンスヘッダの x-ratelimit-remaining-requests / x-ratelimit-remaining-tokens / x-ratelimit-reset-* などを参照する仕組みになっています。クライアント側で残量を見ながら投げる速度を自動で落とすのが、ベストプラクティスとされています。
リセットタイミングは、API 側は分単位、Codex サブスク側は時間〜週単位が中心です。「いま 429 でも、X 時間後にはリセットされる」と分かれば、再開待ちで進めるか、別経路(ChatGPT 内 Codex / 別アカウント)に切り替えるかの判断が早くなります。
まとめ — 429 は「上限超過」と理解できれば 3 段で対処できる
Codex で 429 Too Many Requests が出るのは、自分の組織のレート制限(RPM / TPM / サブスク枠)を超えたときです。OpenAI 公式が示す対処は、(1) exponential backoff の自動リトライ、(2) parallel processor で並列実行をスロットル、(3) プラン or Tier の引き上げ、の 3 段階に整理されます。
短期スパイクならリトライ、並列が高いならスロットル、定常的な不足ならプラン引き上げ、と原因と対処を 1 対 1 で対応させると、Codex を 429 で止められても落ち着いて回せます。残量の可視化とリセット時刻の把握を運用に組み込んでおけば、429 自体の発生も大きく減らせます。
