Codexの429エラーの原因と対処法｜GitHubの429との見分け方も

公開: 2026年8月3日 / 更新: 2026年9月9日・読了目安14分

Codexを使っていると、ある日突然「429 Too Many Requests」というエラーで作業が止まることがあります。結論から言うと、原因の大半は「プランの利用上限に達した」か「短時間にリクエストを送りすぎた」かのどちらかで、多くはリセット待ちかリトライ間隔の調整で解決します。ただし、残量が十分あるのに429が出るという報告も一定数あり、その場合は一時的な不具合を疑う必要があります。この記事では、実際にGitHub Issuesで報告されている症状をもとに、パターン別の見分け方と対処法を整理します。

この記事の要点

Codexの429エラーは「プランの利用上限到達」か「短時間のリクエスト過多」が主な原因です。

Codex CLIの/statusコマンドで、現在の残量とリセットまでの時間を確認できます。

APIキー(従量課金)利用時は、ChatGPTプランの利用枠ではなくOpenAI Platform側のレート制限が適用されます。

残量に十分余裕があるのに429が出る場合は、一時的な不具合の可能性があります。

2026年8月には「利用上限が急に減った」という声に対し、OpenAIがサブスクリプションをAPIとして転用・共有する「sub2api」等の利用が不正防止システムの検知対象になっていると公式に説明しました。

2026年8月25日にはPlusプラン向けに5時間ごとの利用上限が復活し、上限到達時の備えとして「Banked Reset」という使用量リセット権も配布されています。

復活への反発を受け、2026年8月末にはCodexリードが有料ユーザー全員の利用上限をリセットし、ハーネス側の修正で「同じ上限内でより多く作業できる」と説明しました(上限自体の恒久的な引き上げではありません)。

2026年9月時点でも「以前より早く上限に達する」という海外の報告は続いていますが、効率改善と上限値の引き上げは別の話として切り分けて読む必要があります。

予防策として、タスクの分割・並列実行数の抑制・リトライ時の指数バックオフが有効です。

429エラーとは何か

429はHTTPのステータスコードで、「Too Many Requests(リクエストが多すぎます)」を意味します。コード自体に問題があるわけではなく、一時的にリクエストを受け付けられない状態を示すエラーです。Codexでは次のようなメッセージで表示されることが多く、GitHub Issues上でも同様の報告が繰り返し上がっています(openai/codex#12775、#9148、#10560など)。

stream error: exceeded retry limit, last status: 429 Too Many Requests

このメッセージは、Codexが内部で自動リトライを繰り返した末に失敗したことを示しています。実際、openai/codex#4840では「429を受け取っても静かにリトライを続けるだけで、ユーザーに分かりやすく通知されない」という設計上の課題も報告されており、ユーザー側からは「何が起きているか分かりにくい」状態になりがちです。まずは焦って何度も再実行するのではなく、以下のどのパターンに当てはまるかを切り分けることが大切です。

429エラーの4つの原因(プラン利用上限への到達、短時間の連続リクエスト、APIキー従量課金のレート制限、一時的な不具合)を整理した図解

発生パターン①: プランの利用上限に到達している

ChatGPT Plus・Pro・Business・Enterpriseなどのサブスクリプションでは、直近数時間単位のローリングウィンドウと、週単位でリセットされる上限の組み合わせで使用量が管理されています。どちらかの上限に達した状態でリクエストを送り続けると、429やレート制限に関するメッセージが表示されます。

Codex CLIの/statusコマンドで、現在の残量とリセットまでの時間を確認できます。
上限に達している場合は、次のリセットまで待つのが基本の対処法です。大きなタスクは分割し、リセット後に再開するとスムーズです。
上限の具体的な数値やリセット周期はプランの変更に伴って見直されることがあるため、正確な数値は公式サイトの料金ページで確認してください。2026年8月時点でも、5時間の上限表示が一時的に外れるなど仕様が変わる場面が見られました。
2026年6月からは、保存しておいたリセットを好きなタイミングで使える「Saved Rate Limit Resets」も一部プランに導入されました。SNS上では「使用量リセットを課金で購入できる」という誤情報が出回っていますが、実際は無料付与や友人招待で獲得するもので購入はできません。詳しい仕組みは「Codexが動かない時の対処法」にまとめています。
2026年8月には「利用上限が急に減った気がする」という声が海外で相次ぎ、OpenAIのCodex担当リードが公式に説明を出しました。それによると、上限がコミュニティへの周知なしに変更されることはなく、調査の結果、影響を受けたユーザーの多くはChatGPTサブスクリプションをAPIとして転用・共有する「sub2api」と呼ばれる非公式の仕組みを使っていたとのことです。サブスクの利用枠をAPI化して複数人で共有・転売する使い方は、不正防止システムの検知対象になると明言されています。
一方、公式クライアントや「Sign in with ChatGPT」に対応したオープンソースツールから自分の利用枠を使う分には問題ないと説明されています。心当たりがないのに上限が急減したと感じる場合は、GitHub Issuesで同様の報告を確認するか、サポート窓口に問い合わせてみてください。
2026年8月25日には、一時的に緩和されていたPlusプラン向けの5時間ごとの利用上限が復活しました。Codexリードのティボ・ソティオー(Tibo Sottiaux)氏が8月24日にX(旧Twitter)で明らかにしたもので、計算リソースの平準化が理由とされています。5時間の上限は週次の上限を置き換えるものではなく両方が併存するため、実質的に二重の上限がかかる点に注意してください。なお、Pro($100/$200)プランについては「今後数ヶ月」は5時間上限の対象外とされています。
上限到達に備える仕組みとして、2026年8月21日には有料ユーザー全員に「Banked Reset」と呼ばれる使用量リセット権が1回分配布されました。上限を使い切った後に手動で発動して利用枠をリセットできるもので、週次の上限に対する保険として機能します。前述の「Saved Rate Limit Resets」と近い性質の仕組みとみられますが、正式名称や適用範囲は変更される可能性があるため、最新情報はCodex内のプロフィールメニュー等で確認してください。
5時間制限の復活には利用者から反発が広がり、これを受けてCodexリードのティボ・ソティオー(Tibo Sottiaux)氏は2026年8月末、有料ユーザー全員の利用上限をリセットしたと明らかにしました。あわせて、compaction(会話の圧縮)・メモリ管理・サブエージェントまわりのハーネス修正により、「同じ上限内で以前より10〜50%多くの作業をこなせるようになった」と説明しています。これは同じ上限をより効率的に使えるようにする改善であり、上限の数値自体を恒久的に引き上げたわけではない点には注意してください。

codex
# セッション内で実行
/status

一方でopenai/codex#9148のように、「5時間・週次のどちらの上限も大きく下回っているのに429が出た」という報告もあります。/statusで残量に余裕があると分かった場合は、このパターンではなく後述するパターン③・④を疑ってください。Claude Codeの使用制限対策は「Claude Codeの使用制限対策」にまとめています。

2026年9月時点の状況: 「効率改善」と「上限アップ」は別の話

2026年9月時点でも、8月末のハーネス修正のあとに「以前より早く上限に達する」という声が海外の掲示板(Redditのr/codexなど)で続いています。なかにはBusinessプランで同じ作業を続けた自分のログをもとに、週あたりに使えたトークン量が約3億2,300万から約1億7,300万へおよそ半減した、という報告もあります(2026年9月時点・数百件の賛同を集めた投稿)。ただしこれはいずれも個人の利用ログに基づく海外ユーザーの書き込みであり、OpenAIがプランごとの上限トークン数を公表しているわけではありません。数値そのものを鵜呑みにせず、「そういう体感の報告がある」という程度に受け止めてください。

混同しやすいのが、この報告と8月末のアナウンスの関係です。PC Watchの報道(2026年8月31日)によると、Codexリードのティボ・ソティオー氏が説明したのは、圧縮時に古い画像を保持してコンテキストが膨らむ不具合や、重複した要約が週次使用量の最大5分の1を圧迫していた問題などを修正した結果、「使い方によっては以前より10〜50%ほど多く利用できるようになる」というものでした。つまり同じ枠をより効率的に使えるようにする改善であって、上限の数値を引き上げたという発表ではありません。効率が上がっても、扱うコンテキストや並列数を増やせば体感の持ちは元に戻ります。

実務上の対処は変わりません。まず/statusで自分の残量とリセット時刻を実測し、体感と数値がずれる場合はGitHub Issuesで同時期の報告を検索する、という順番が確実です。上限の仕様そのものは公式の料金ページやCodex内の表示で確認してください。

2026年9月時点(Astra切替後): 上限到達が増えたと感じたら

GPT-6 Astraへ切り替えた直後に429や上限到達が増えたと感じる場合、原因の多くはクレジット消費速度の違いです。公式のプラン別上限(learn.chatgpt.com/docs/pricing)では、Plusの5時間枠の目安メッセージ数はGPT-5.6 Solが10〜100件、GPT-5.6 Terraが25〜200件なのに対し、GPT-6 Astraは5〜45件です。

同じ作業量でもAstraのほうが早く上限に達するのは想定内の挙動で、不具合ではありません。対処は、/modelでGPT-5.6 Sol・Terraへ一時的に戻すか、設計判断や難しいバグ調査などここぞという場面だけAstraを使う運用に切り替えることです。消費量の詳しい違いは「Codex GPT-6 Astra対応ガイド」にまとめています。

発生パターン②: 短時間に連続してリクエストを送っている

複数のCodexセッションやサブエージェントを並行して動かしていると、短時間にリクエストが集中してレート制限に触れることがあります。openai/codex#11083では、25個ものサブエージェントを同時に走らせていたユーザーが、以前は問題なかった構成で急に429が出るようになったと報告しています。

並列実行数を減らし、一度に走らせるセッションやサブエージェントの数を絞ります。
リトライする場合は、間隔を空けずに連打するのではなく、待機時間を徐々に伸ばす「指数バックオフ」の考え方が有効です。OpenAI公式のガイドでも、429や503のようなリトライ可能なエラーに対しては、待機時間を毎回2倍にしていく方式が推奨されています。
複数プロセスが同時に同じタイミングで再試行すると再び集中してしまうため、待機時間に多少のランダムな幅(ジッター)を持たせるとさらに安定します。

1回目の失敗 → 1秒待機
2回目の失敗 → 2秒待機
3回目の失敗 → 4秒待機(以降、上限まで倍々に)

発生パターン③: APIキー(従量課金)利用時のレート制限

OPENAI_API_KEYを使ってcodex login --with-api-keyでサインインしている場合、ChatGPTプランの利用枠ではなく、OpenAI Platform側のレート制限が適用されます。組織のUsage tierによってリクエスト数・トークン数あたりの上限が異なり、Usage limits(支出上限)を設定していると、その金額に達した時点でリクエストが止まる仕様です。

OpenAI Platformの使用量ダッシュボードで、モデル別の消費量とUsage tierを確認します。
頻繁に上限へ到達する場合は、支出上限の見直しやUsage tierの引き上げを検討します。
APIキー経由の認証設定や、ChatGPTサインインとの違いは「CodexをAPIキーで使う方法」で詳しく解説しています。従量課金への切り替え手順を確認したい場合はあわせてご覧ください。

発生パターン④: 一時的な障害・不具合が原因の場合

残量に十分な余裕があり、リクエスト頻度も特に高くないのに429が出るケースも報告されています。openai/codex#12775では「利用枠の99%以上が残っているのにexceeded retry limitが出た」という報告があり、openai/codex#7839ではバージョンアップ後に特定の構成でだけ429が発生するようになったという事例もあります。これらはCodex側やモデルプロバイダ側の一時的な不具合、あるいはインシデント対応に伴う仕様変更が影響している可能性があります。

少し時間を置いてから再実行してみます。数分から数十分程度で解消することがあります。
直前にCodexをアップデートした場合は、そのバージョンで既知の不具合が報告されていないか確認します。ロールバックや修正版へのアップデートで解決する場合もあります。
自分の環境固有の問題か、他のユーザーも同様の症状を報告しているかは、GitHub Issuesで「429」や「rate limit」といったキーワードで検索すると切り分けやすくなります。エラー全般の切り分け方は「Codexが動かない時の対処法」でも整理しているので、あわせて確認してみてください。

CodexではなくGitHub本体の429だった場合

「429」はCodex固有のエラーではなく、GitHubのサイトやAPIでも同じ番号のエラーが返ります。どのサービスが429を返しているのかを最初に切り分けると、対処先を間違えずに済みます。

GitHub REST/GraphQL APIの429: GitHub APIには1時間あたりのプライマリレート制限(未認証は60リクエスト、個人アクセストークン認証で5,000リクエストが基本)と、短時間の連続リクエストに対するセカンダリレート制限があり、超過すると403または429が返ります(2026年8月時点の公式ドキュメントより)。レスポンスヘッダーのx-ratelimit-remainingが0ならプライマリ制限、retry-afterヘッダーがあればその秒数だけ待ってから再試行します。
GitHubのWebページの429: ブラウザで「429: Too Many Requests」ページが表示された場合は、同一ネットワークからの過剰アクセスが原因のことが多く、時間を置けば解消するのが一般的です。
Codex経由でGitHub操作をしていた場合: CodexにGitHub連携(PR作成やIssue取得など)をさせているときの429は、Codexの利用枠ではなくGitHub API側の制限に触れている可能性があります。エラーメッセージにgithub.comやAPIエンドポイントが含まれていないかを確認してください。

Codex側の枠が原因ならこの記事の①〜④、GitHub側ならリクエスト頻度の調整と待機が対処の中心になります。

予防策

429エラーそのものを完全になくすことは難しいものの、発生頻度を下げる工夫はいくつかあります。

大きなタスクは事前に小さく分割し、非対話実行(codex exec)を使ってムダなやり取りを減らします。
並列で走らせるセッション・サブエージェントの数を、体感で問題なかった範囲から急に増やさないようにします。
APIキー経由でスクリプトから呼び出す場合は、リトライ処理に指数バックオフとジッターをあらかじめ組み込んでおきます。
日頃から/statusで残量を確認する習慣をつけ、上限が近づいているタイミングでは大きめのタスクを避けます。
Codex自体を最新版に保つことも予防策の一つで、レート制限まわりの表示や挙動は今後のアップデートで改善される可能性があります。基本的な使い方から見直したい場合は「Codexの使い方完全ガイド」も参考にしてください。

よくある質問

429エラーは何度もリトライすれば直りますか?

短時間の連続アクセスが原因であれば、間隔を空けてから再実行すると解消することがあります。ただし、間隔を空けずに連打すると悪化することがあるため、待機時間を徐々に伸ばしながら試すのが安全です。プランの利用上限に達している場合はリトライしても状況は変わらず、リセットを待つ必要があります。

APIキー利用とChatGPTサブスクで429の原因は違いますか?

はい、適用される上限の仕組みが異なります。ChatGPTサインインではプランごとの利用枠(5時間・週次の組み合わせ)が対象になるのに対し、APIキー認証ではOpenAI Platform側のレート制限やUsage limitsが対象になります。どちらの認証方式を使っているかによって確認すべき場所が変わる点に注意してください。

残量が十分あるのに429が出るのはなぜですか?

GitHub Issuesでは、利用枠にまだ余裕があるにもかかわらず429が発生したという報告が複数あります。この場合はCodex側やモデルプロバイダ側の一時的な不具合が疑われます。時間を置いて再実行し、それでも解消しない場合はGitHub Issuesで同様の報告を検索するか、新規に報告することをおすすめします。

まとめ

Codexの429エラーは、多くの場合「プランの利用上限への到達」か「短時間のリクエスト過多」が原因で、残量確認とリトライ間隔の調整で対応できます。APIキー利用時はOpenAI Platform側のレート制限が対象になる点も押さえておくと切り分けがスムーズです。それでも残量に余裕があるのに発生する場合は、一時的な不具合を疑いGitHub Issuesを確認してみてください。基本的な使い方やエラー全般の対処法は「Codexの使い方完全ガイド」と「Codexが動かない時の対処法」もあわせてご覧ください。