Codexのリミットはいつリセットされる？使用制限・残量確認・banked resetを整理

この記事の結論

• Codexのリミットは「完全に見えない」わけではなく、公式にはCodex usage dashboardとCLIの/statusで確認できる導線があります。
• ただし、あと何回使えるかはモデル、コードベース、タスクの複雑さ、コンテキスト量、ローカル/クラウド実行で変わるため、体感として分かりにくい部分があります。
• local messagesとcloud tasksは同じ5時間ウィンドウを共有し、さらに週制限が適用される場合があります。
• banked rate-limit resetは便利ですが、対象プラン、招待条件、対象期間、有効期限があるため、誰でも常に使える機能とは断定できません。
• 制限に近づいたら、リセットだけを待つより、タスクを小さく分け、不要なコンテキストを減らし、小さいモデルやcreditsの条件を確認するのが現実的です。

なぜ「codex reset limit」で検索したくなるのか

Codexを使っていると、実装の途中でusage limitに近づいたり、突然エラーに見える表示が出たりします。英語ではCodex reset limit、Codex usage limit、Codex rate limit reset、日本語ではCodex リミット、Codex 制限、Codex 残量確認のような検索になりがちです。

混乱しやすい理由は、CodexがCLI、デスクトップアプリ、Web、ChatGPT上の体験、BusinessやEnterpriseの管理画面など複数の入口を持つからです。さらに、残量は単純な回数だけでなく、モデルやタスク規模によって消費のされ方が変わります。

Codexの使用制限はどこで確認できる？

OpenAI DevelopersのCodex pricingでは、現在の使用制限はCodex usage dashboardで確認でき、アクティブなCodex CLIセッション中は/statusでremaining limitsを見られると説明されています。まずはこの2つを一次情報として扱うのが安全です。

Codexの5時間ウィンドウとは？

Codex pricingでは、local messagesとcloud tasksの使用制限が5時間ウィンドウを共有すると説明されています。これは「5時間ずっと使い放題」という意味ではありません。一定の時間枠の中で、モデルやタスク内容に応じて含まれる使用量を消費する、という見方が近いです。

さらに、追加の週制限が適用される場合があります。つまり、5時間ウィンドウだけを見て「時間が来れば必ず全部回復する」と決めつけるのは危険です。実際の残量や回復見込みは、dashboard、CLI表示、エラー表示に出る情報を優先してください。

Codexのリセット時間は固定で分かる？

リセット時間を自分で正確に計算するのは難しいです。OpenAIのchangelogでは、usage-limit errorsにreset timingが表示される改善が紹介されていますが、これは表示される場合の情報を確認するという話であり、誰でも手元で完全な残り回数を逆算できるという意味ではありません。

体感メモを取ることは役に立ちます。どのモデルで、どの程度の作業を、どのくらいの頻度で頼むと重くなるかを記録すれば、作業計画は立てやすくなります。ただし、それは個人の運用メモであって、OpenAIが明言する残量計算式ではありません。

banked rate-limit resetとは？

OpenAIのCodex changelogでは、2026-06-11のCodex app 26.609でrate-limit reset bankingが追加されたと説明されています。Plus / Proユーザー向けにローンチ時のone free resetや、referral invitationsによって追加される場合があるresetが案内されています。

ここで大事なのは、banked resetを制限突破の裏技として扱わないことです。対象プラン、対象期間、招待条件、有効期限がある救済手段であり、誰でも常に使えるもの、招待すれば必ずもらえるもの、無限に制限を増やせるものではありません。

creditsとは？

OpenAI Developersの説明では、creditsは含まれる使用制限に達した後もCodexを続けるための仕組みです。Plus / Proでは追加credits、Business / Edu / Enterpriseではworkspace credits、APIキー利用では標準API料金の扱いが関係します。

個人開発では、追加課金の前に、まず依頼を小さくする、モデルを下げる、不要なログや巨大ファイルを渡さない、作業指示を整理する、という順番がおすすめです。creditsは便利ですが、使うほど費用も発生します。

制限に近づいたときの現実的な対処法

• 小さいモデルに切り替える。routine taskなら軽量モデルで十分なことがあります。
• 依頼を小さく分ける。調査、設計、実装、確認を一つの巨大ターンに詰め込まない。
• 大きなログや不要ファイルを渡しすぎない。エラーの核心、対象ファイル、再現手順を先に絞る。
• READMEやAGENTS.mdを整えて、毎回同じ説明をしなくて済むようにする。
• 長時間タスクは、ゴール、変更禁止範囲、実行するチェック、完了条件を先に書く。
• APIキー利用や別ツール利用は、費用、安全性、秘密情報の扱いを確認してから使う。

目的:
対象ファイル:
変更してよい範囲:
変更してはいけない範囲:
先に確認すること:
完了条件:
実行するチェック:
報告してほしいこと:

個人開発者向け：リミットを浪費しやすい依頼

リミットを浪費しやすいのは、AIが読む範囲と判断範囲が広すぎる依頼です。「全部いい感じにして」「サイト全体を改善して」「エラー全文と巨大ログを全部見て」のような依頼は、調査量も往復も増えやすくなります。

逆に、目的、対象ファイル、禁止事項、確認コマンドがある依頼は強いです。Codexは作業者として賢くても、ゴールがぼやけていると探索に使用量を使います。リミット節約は、プロンプト節約というより、作業設計の問題です。

まとめ

Codexの使用制限には、usage dashboardや/statusという確認導線があります。ただし、実際の残り作業量はモデル、タスク規模、コードベース、コンテキスト量、ローカル/クラウド実行で変わるため、単純な残り回数としては分かりにくい部分があります。

だからこそ、この記事の結論は制限突破ではなく、確認・節約・安全運用です。リセットを待つだけでなく、タスクを小さく分け、不要なコンテキストを減らし、必要に応じてbanked resetやcreditsの条件を公式情報で確認する。この使い方が、個人開発ではいちばん事故りにくいです。