Codexを動かしていて「429 Too Many Requests」や「rate_limit_exceeded」が出ると、作業が突然止まって焦ります。この記事は、AIで開発やブログ運用を自動化したい個人開発者に向けて、エラーの原因を「ChatGPTプラン枠」と「APIのレート制限」に切り分けて整理します。
待つだけで直るのか、設定変更が要るのかを最短で判断できるようにまとめました。原因さえ分かれば、対処は数分で終わります。
まず試すこと
- エラー文の「try again after ○○ seconds」に従って一度待ってから再実行する
- ChatGPTプランで使っているか、APIキーで使っているかを確認する（原因が別物）
- 複数のCodexを同時に走らせていないか、自動化ループの間隔が短すぎないかを見直す
Codexの429「Too Many Requests」とは何が起きているか
429は「リクエストを送りすぎた」ことを表すHTTPステータスです。Codexでこのエラーになるのはほぼレート制限に当たったときで、攻撃ではなく正常な利用の延長で起きます。まず落ち着いて、表示された待機秒数だけ間を空けてください。
先に確認
429はアカウントの停止やデータ破損ではありません。設定ファイルやAPIキーを焦って消すと、復旧後にかえって動かなくなります。まずは「待つ」「経路を確認する」だけにとどめてください。
表示されるエラー文の原文を確認する
原因を正しく切り分けるには、まず表示されたエラー文をそのまま読むことが近道です。CodexがChatGPTプラン枠のレートに当たると、次のようなエラー本文を返します。エラーコードはrate_limit_exceededで、ここを見れば「レート制限である」と確定できます。
error=http 429 Too Many Requests: “You’ve exceeded the rate limit, please slow down and try again after 60.616292 seconds.”（code: rate_limit_exceeded）
ERROR: exceeded retry limit, last status: 429 Too Many Requests, request id: …
上は実際にChatGPT Proユーザーが報告したログの要約です（出典は記事末尾）。「try again after ○○ seconds」の秒数が、再開タイミングのいちばん信頼できる目安になります。
「rate_limit_exceeded」と「exceeded retry limit」の違い
この2つは見た目が似ていますが、出どころが違います。前者はサーバーが返した本来のエラーコードで、レート制限そのものを指します。後者はCodex側が内部で再試行を何度か繰り返した末に「もう諦めた」と打ち切ったクライアント側のメッセージで、結果であって原因ではありません。
両方が画面に出ているときは、根っこにあるのはレート制限だと考えて対処を進めてください。コードがrate_limit_exceededになっているかどうかが、判断の決め手になります。
使用量が残っているのに429になることがある
「まだ枠が残っているのに429が出た」というのは、よくある困惑です。実は5時間ウィンドウの終端付近で、画面上の使用率に余裕があるのに429が出る事象がGitHubのIssueで報告されています。
報告例では約15分でウィンドウがリセットされ、自動的に復旧しています。数分の一時的な詰まりであれば、設定をいじらず待つのが正解です。
すぐに復旧するケースとしないケース
ここを見分けると、無駄な作業を減らせます。短時間で直るか直らないかが、原因を見分ける最初のヒントになります。
- すぐ直る: ChatGPTプラン枠の一時的な詰まり。5時間ウィンドウのリセットを待つだけで再開できることがほとんど。
- 待っても直らない: 週次の上限を使い切った、またはAPIのクォータ（請求上限）に達した場合。何時間待っても同じエラーが続く。
後者は「待つ」ではなく「設定や契約を変える」方向の対処に切り替える必要があります。経路ごとの整理は次の章で行います。
まず原因を切り分ける（プラン枠かAPIレートか）
Codexには「ChatGPTのサブスクリプションで使う経路」と「APIキー（独自プロバイダやAzure OpenAIを含む）で使う経路」の2系統があります。429の原因も対処もこの2つで別物なので、ここを最初に判別します。
自分がどちらの経路で使っているかを先に確定させると、「待てば直る」のか「設定を変える」のかが一発で分かります。
| 症状・経路 | 考えられる原因 | 対処の方向性 |
|---|---|---|
| ChatGPTプランで使用・短時間で復旧 | 5時間ウィンドウの一時的な上限 | 待機秒数だけ待って再実行 |
| ChatGPTプランで使用・何時間も直らない | 週次の上限を使い切った | 週次リセットを待つ／プランを上げる |
| APIキーで使用・特定の操作で頻発 | RPM（毎分リクエスト数）やTPM（毎分トークン数）の超過 | 同時実行や間隔を絞る／max_tokensを下げる |
| APIキーで使用・突然完全に止まる | クォータ（請求上限）に到達 | 請求設定・ティアを確認して引き上げ |
| 「exceeded retry limit」だけ表示 | プロバイダ側の429をCodexが握りつぶしている | プロバイダ設定とレートを確認し時間を空ける |
ChatGPTプラン枠の上限（5時間と週次）
ChatGPTのプランでCodexを使っている場合、ここがいちばん多い原因です。Codexの使用量には、5時間のローリングウィンドウと週次の2つの上限が同時に効きます。
5時間枠と週次枠が同時に効く仕組み
注意したいのは、2つの上限が同時に適用される点です。週次の枠を使い切ると、5時間枠に余裕があってもCodexは使えなくなります。逆に5時間枠を使い切れば、週次に余裕があっても一時的に止まります。
消費量はタスクの重さで変わり、大きなリポジトリを丸ごと読ませたり、長いセッションを続けたりするほど、1メッセージあたりの消費が増えます。渡すコンテキストの量で枠の減り方は大きく変わるため、思ったより早く上限に届くことがあります。
消費が早く減るときの見直し
枠の減りが早いと感じたら、毎回どれだけの情報をCodexに渡しているかを見直してください。巨大なファイルを毎回まるごと読ませると、入力トークンが膨らみ消費が跳ね上がります。
- 対象ファイルを必要な範囲に絞る
- 終わった作業のコンテキストを引きずらない
- 長くなったセッションは区切って新しく始める
こうした工夫で枠を長持ちさせられます。1回の依頼を小さく具体的にすることが、結果的に429を遠ざける近道になります。
APIレート（RPM・TPM・クォータ）の上限
APIキーでCodexを使う場合は、プラン枠とは別のレート制限が効きます。429はRPM（毎分リクエスト数）、TPM（毎分トークン数）、クォータ（請求上限）のいずれかを超えたときに出ます。
max_tokensが消費を押し上げる仕組み
見落としがちなのがmax_tokensの設定です。レート消費は「max_tokens」と「入力の推定トークン数」の大きい方で計算されます。つまりmax_tokensを必要以上に大きく設定していると、実際の応答が短くても、その大きな値でレートを消費したことになり、見た目より早く上限に届きます。
実際の応答サイズに合った値まで下げるだけで、同じ作業でも踏める回数が増えます。短い応答しか要らない処理にまで大きなmax_tokensを付けていないか、確認してください。
出典: How to handle rate limits（OpenAI Developers）（2026年6月時点）
現在の上限を確認する場所
対処の前に、今の自分の上限がいくつなのかを確認しましょう。APIの現在のティアと上限は、platform.openai.com の Settings → Limits で確認できます。ティアは累計の利用額が増えると自動で上がり、それに合わせて上限も広がる仕組みです。
上限はモデルごとに違うため、使っているモデルの行を見てください。今どのティアにいて、どのモデルにどれだけのRPM・TPMが割り当てられているかが分かれば、設定を絞るべきか、ティアを上げるべきかの判断がつきます。
「exceeded retry limit」だけ出て理由が分からないとき
エラーに「exceeded retry limit」しか表示されず、原因が読み取れないことがあります。これはCodexの挙動が関係しています。
Codexが429を握りつぶす挙動
Codexはプロバイダ側が返した429を画面に表示せず、内部で再試行を繰り返すことがあります。そして最後に「exceeded retry limit, last status: 429」だけを残します。この挙動はGitHubのIssueでも「Codexはモデルプロバイダの429をユーザーに見せない」と指摘されています。
表示は不親切ですが、裏で起きているのはレート制限です。原因が見えないからといって設定を壊さず、まずはレート制限を疑い、少し時間を空けてから再実行してください。
Azureや独自プロバイダ経由の場合
独自のプロバイダを設定している場合は、そのプロバイダ側の上限も疑ってください。たとえばAzure OpenAIのデプロイでは、料金ティア（S0など）のトークンレート上限に当たると、メッセージに「retry after ○○ seconds」を含む429が返ります。Codexはこれをそのまま再試行し続けるため、ユーザーには打ち切りログしか見えません。
この場合はOpenAIのプラン枠ではなく、プロバイダ側のクォータ画面で上限と残量を確認する必要があります。base_urlやAPIキーがどのプロバイダを向いているかも合わせて確認してください。
原因別の対処法と再発を防ぐ設定
切り分けができたら、原因に合った対処を上から順に試します。多くは「待つ」「同時実行を減らす」「設定を1か所変える」で解決します。
すぐ効く対処（手順）
まずは確実に効く順番で対処します。下のフローを上から実行してください。
- エラー文の「try again after ○○ seconds」に従って待ち、もう一度同じコマンドを実行する
- 同時に走っているCodexや自動化ループを止め、1本だけにして再実行する
- ChatGPTプラン枠なら使用状況、APIなら Settings → Limits で残量を確認する
- それでも直らなければ、APIはmax_tokensを下げる／プランやティアの引き上げを検討する
指数バックオフで自動リトライする
OpenAIが第一に推奨するのは、指数バックオフでのリトライです。429が出たらまず短く待ち、それでも失敗したら待ち時間を倍々に伸ばしながら再試行します。さらにランダムなゆらぎ（ジッター）を足すと、複数のプロセスが同じタイミングで一斉に再試行してまた429を踏む、という悪循環を防げます。
Codex自体も内部で同種のリトライを行いますが、Codexをスクリプトから呼び出して自動で回す場合は、呼び出し側にも同じ仕組みを入れておくと安定します。手動で連打して状況を悪化させないことが大切です。
自動化・並列実行で429を頻発させない設定
spec-kitやCI、複数エージェントでCodexを連続実行すると、短時間にリクエストが集中してRPM・TPMのバーストで429になりやすくなります。実際にspec-kitとの自動開発で頻発するという報告も上がっています。自動化勢ほど、ここの制御が効きます。
同時実行数と間隔を絞る
自動化で429を減らす鍵はリクエストの平準化です。並列でcodex execを大量に起動せず、同時実行は少数に抑えます。連続実行のループには数秒〜十数秒の間隔を入れ、一気にリクエストが集中しないようにします。
また、複数の小さな依頼をまとめて1リクエストにすれば、往復の回数が減りRPMの節約になり、TPMの無駄も抑えられます。CIで回す場合は、失敗時にすぐ再実行せず、バックオフを挟んでから次に進む設計にしておくと、連鎖的な429を避けられます。
解決しない場合の次の確認項目
ここまで試して直らないときは、環境側の要因を順に確認します。これらを一つずつ潰すと、原因が絞り込めます。
- Codexを最新版に更新し、
codex --versionでバージョンを確かめる（古い版だとレート関連の挙動が改善されていないことがある） - 軽量モデルへ一時的に切り替えて回避できないか試す
- 企業プロキシやVPN経由になっていないか確認する（WindowsのWSLや共有IP環境ではプロキシ側で詰まることがある）
- APIキーやbase_urlなどプロバイダ設定が、意図したものを向いているか確認する
関連エラーとの違い
429と取り違えやすいエラーがあります。混同すると、効かない対処を延々と試してしまいます。
認証切れ（token expired）との見分け方
とくに紛らわしいのが認証切れです。token expiredのような認証系エラーは、レート制限ではなくサインインのやり直しで直るため、対処がまったく異なります。429は「送りすぎ」、認証切れは「ログインの期限切れ」と原因が別物です。
見分けるポイントはエラーコードで、rate_limit_exceededでなければ429以外の原因を疑ってください。認証切れの直し方は別記事にまとめているので、コードが認証系であればそちらを参照してください。
環境別の確認点（Windows / Mac / Linux）
OSによって、確認すべき点が少し変わります。Windowsでは、WSLや企業プロキシ経由だとプロキシ側が429を返すことがあるため、プロキシ設定を確認します。MacとLinuxでは、複数のターミナルでCodexを同時に起動していないか、バックグラウンドのジョブが残っていないかを見てください。
どのOSでも共通するのは、最初に「ChatGPTプラン枠かAPIキーか」を切り分ける手順です。ここを飛ばすと、OS固有の枝葉をいくら確認しても解決にたどり着けません。
よくある質問（FAQ）
読者から多い3つの疑問を、原因の切り分けと結びつけて整理しました。
Q. CodexのToo Many Requests（429）は待てば直りますか？
ChatGPTプラン枠の一時的な上限なら、表示の待機秒数か5時間・週次のリセットを待てば直ります。APIのRPM/TPMやクォータに当たっている場合は、待つだけでなく同時実行を減らす・max_tokensを下げる・ティアを上げるといった設定変更が必要です。
Q. 使用量が残っているのに429が出るのはなぜですか？
5時間ウィンドウの終端付近で、使用率に余裕があるのに429になる事象がGitHubのIssueで報告されています。多くはウィンドウがリセットされると自動的に復旧します。数分待っても直らない場合は、APIレート側やプロバイダ側の上限を疑ってください。
Q. exceeded retry limit としか出ず原因が分かりません。
Codexはプロバイダ側の429を画面に出さず内部で再試行し続け、最後に「exceeded retry limit, last status: 429」だけを残すことがあります。実体はレート制限なので、ChatGPTプラン枠かAPIレートのどちらに当たっているかを確認し、少し時間を空けてから再実行してください。
解決チェックリストと公式情報の確認先
最後に、上から順に試せる解決チェックリストをまとめます。429が出たらこの順番で確認すれば、待つべきか設定を変えるべきかを迷わず判断できます。公式情報は更新が早いので、料金や上限の数値は必ず公式ページで最新を確認してください。
- エラー文の「try again after ○○ seconds」に従って一度待った
- ChatGPTプラン枠かAPIキーか、自分の利用経路を確認した
- 同時実行・自動化ループを止め、1本だけにして再実行した
- APIならmax_tokensを下げ、Settings → Limits で上限・ティアを確認した
ここまで試して直らない場合は、Codexを最新版に更新し、プラン/ティアの引き上げを検討してください。自動化での429に悩む方は、当サイトのAIコーディングツールのエラー・自動化DBで関連記事と、WordPress自動投稿・n8n連携の構築支援もまとめています。
公式情報の確認先と更新履歴
本記事は2026年6月9日時点の公式情報と、GitHub openai/codex の公開Issueをもとにしています。料金・上限・仕様は変更されることがあるため、判断の前に必ず一次情報を確認してください。
確認に使った一次情報源
本記事の判断は、公式ヘルプとGitHubの公開Issueを一次情報として裏取りしています。
- OpenAI Help Center: 429エラーの解決方法
- OpenAI Help Center: ChatGPTプランでのCodex利用と上限
- OpenAI Developers: レート制限の扱い方
- GitHub Issue #9135: 5時間枠終端での誤った429
- GitHub Issue #4840: プロバイダ側429の非表示
- GitHub Issue #20553: spec-kit併用時の429頻発
更新履歴: 2026年6月9日 初版公開。関連エラー記事「Codexのtoken expiredエラーの直し方」も合わせてご覧ください。
コメント