Update — 2026年夏：この方法は私の環境では通用しなくなった
2026年夏までに、このやり方は私の環境では安定して機能しなくなった。アカウント上で5時間枠の使用量表示が消え、週次の使用上限だけが見える状態になった。結果として、以前このワークフローの基準にしていた短いリセット周期を前提にできなくなった。
さらに大きかったのは、長時間タスクの挙動だ。重いCodexタスクの実行中に週次上限を使い切ると、以前のようにそのまま完了まで進むのではなく、作業が止まるケースを経験した。そのため、「残り3〜5％で最も重いタスクを開始する」という以前のルールは、私にとってほとんど意味を失った。実行中のタスクなら週次上限を越えて続く、と期待できなくなったからだ。
ただし、ここは製品全体の仕様と私の観測を分けて書く必要がある。私が確認できるのは、自分のアカウントとワークフローで起きたことだけであり、OpenAIがすべてのユーザーから5時間枠を恒久的に廃止したとまでは断言できない。実際、OpenAIの現在のCodexドキュメントには5時間枠と週次枠の両方への言及があり、上限到達時でもfair-use制限の範囲内で進行中のturnが継続できる場合があると説明されている。したがって、2026年夏の変化は私が実際に経験した挙動として記録するが、全アカウント共通の仕様変更としては扱わない。
以下の本文は、この変更以前に私の環境で実際に機能していたワークフローの記録として残している。現在の判断では、このUpdateを旧本文の現在形の推奨より優先して読んでほしい。
ChatGPT Plusで使っているCodexの使用量表示が残り3〜5％ほどになると、私はその残りを小さなプロンプトには使わない。逆に、事前に準備してある中で最も重い開発タスクを開始する。
私の場合は、TypeScriptへの全面移行、リポジトリ全体のESLint整理、コードベース全体を対象にした深いバグレビュー、大規模な構造リファクタリングなどだ。複数のプロジェクトをあらかじめ準備しておき、最後の使用枠を、その時点で本当に実行可能な重いタスクへ回すことが多い。
この運用に変わった理由は、繰り返し見た挙動にある。可視上の上限が尽きる直前に大きな作業を始めたあと、上限がなくなったように見えてもCodexが作業を続ける場面を、私は一度ではなく何度か経験した。場合によっては、そのままタスクが完了した。自分の使い方を変えるには十分な回数だったが、だからといって製品仕様として保証されているとは言えない。
ワークフローを変えた観測
使用上限が近づくと、普通は慎重になる。大きなタスクは途中で止まるかもしれないので、最後の枠は小さな依頼に使いたくなる。私は今、残り3〜5％を逆に「開始するための窓」として扱っている。
考えるのは「あと何個、小さなプロンプトを送れるか」ではない。「プランに含まれる使用量が残っているうちに、準備済みのどのタスクを始めるのが最も価値が高いか」だ。
この方法が成立するのは、プロジェクト側の準備が済み、タスクの範囲も明確だからだ。最後の数％を、何をすべきか考える時間には使わない。実行を開始するために使う。
名称と上限についての重要な補足
私は以前これを「Codex Plus」と呼んでいたが、これは便宜的な呼び方で、正式な製品名ではない。OpenAIの表現では、CodexはChatGPT Plusに含まれる。この点は直しておいたほうがいい。「Codex Plus」という別プランや別製品があるように読めてしまうからだ。
OpenAIの現在のCodex利用ドキュメントでは、使用量は作業の規模や複雑さ、モデル、タスクの実行場所によって変わると説明されている。また、5時間枠と週間枠を含む使用ウィンドウがある。したがって、この記事の「3〜5％」は使用画面に表示される残量の割合を指す。実時間の3〜5％でも、tokenの3〜5％でも、保証された作業量でもない。
対象となるPlusユーザーは、プラン内の上限到達後にクレジットでCodexの利用を延長することもできる。だからこの運用が無意味になるわけではない。私が最適化しているのは、あくまでプランに含まれる使用量の配分であって、上限を回避する方法ではない。
残り3〜5％で始めるタスク
このタイミングに回すのは、だいたい次のような広い範囲の開発作業だ。
- TypeScriptへの全面移行
- リポジトリ全体のESLint整理
- 大規模コードベースの深いバグレビュー
- 大規模な構造リファクタリング
残り枠を価値の低い小さな依頼に分散させるより、こうした作業をまとまった一つの仕事として開始したい。こういうタスクでは、プロンプトを気の利いた文章にすることより、リポジトリが準備済みで、ゴールが明確であることのほうが重要だ。
複数プロジェクトを準備しておくのも同じ理由による。あるリポジトリでまだ判断やセットアップが必要なら、最後の枠をその準備に消費せず、すでに実行可能な別プロジェクトを始められる。
本当の制約は準備にある
コツは「3％まで待って巨大なプロンプトを貼る」ことではない。タスクが曖昧なら、限られた使用量は探索、確認質問、あるいは間違った方向の作業で簡単に消える。このパターンが有効なのは、プロジェクトが実行可能な状態で、タスクが十分に切られているときだけだ。
同じような運用を試すなら、開始前にスコープを明示しておくとよい。何を変えるのか、何を変えないのか、制約は何か、どう検証するのか、エージェントにどんな成果物を求めるのか。これは一般的なエンジニアリング上の安全策であり、特定のプロンプト形式が使用量を増やすという話ではない。
また、実際に上限で止まった場合も再開しやすくなる。スコープと検証条件が最初から明確なら、途中まで進んだ移行やレビューを引き継ぐのはかなり楽だ。
確認できることと、確認できないこと
私自身の利用から確認できるのは限定的だ。すでに開始していたタスクが、可視上の使用上限を使い切ったように見えたあとも進み続けたことが複数回あり、場合によっては完了した。
一方で、その仕組みは確認できない。OpenAIがすべての実行中タスクに隠れた猶予時間を与えている、最後の3〜5％だけで任意の大規模タスクが完了する、同じ挙動が今後も安定して続く、あるいは上限を回避できる、といったことは主張できない。OpenAIのドキュメントにも、その保証はない。
ここを分けることが重要だ。私は繰り返し観測した挙動を前提に計画はするが、保証として依存はしない。上限でタスクが止まっても、それ自体は異常ではない。残ったプラン内使用量を数個の小さなプロンプトより重要な仕事に使えたなら、この戦略の目的は達成できている。
完了と検証済みは別物
タスクが大きくなるほど、もう一つの区別が重要になる。完了は正しさの証明ではない。TypeScript移行がbuildできても、runtimeの挙動が正しいとは限らない。ESLintが通っても、ビジネスロジックの正しさは証明されない。バグレビューで怪しいパターンが見つかっても、それだけで実バグとは確定しない。テストが通るrefactorも、その信頼性はテストとチェックの範囲に依存する。
このワークフローが変えるのは、作業をいつ開始するかだけだ。検証基準は下げない。大きなagentic changeには、リスクに応じてdiff review、typecheck、tests、build、runtime check、その他プロジェクト固有の検証が必要になる。
このやり方が向かないケース
大きいタスクなら何でも最後の枠に向いているわけではない。作業内容がまだ曖昧、頻繁なプロダクト判断が必要、破壊的あるいは本番に敏感な操作を含む、途中停止でリポジトリが危険な中間状態になる、といったケースでは相性が悪い。
そういう場合は、小さく明確に区切ったタスクか、新しい使用ウィンドウで始めるほうが工学的には安全だ。目的は最後のプロンプトを派手にすることではない。限られたプラン内使用量を、安全に有用な進捗を生める仕事へ使うことだ。
今の自分のルール
ChatGPT Plusに含まれるCodex使用量が残り3〜5％ほどになったら、残りプロンプト数を最大化しようとは考えない。事前に準備したプロジェクトを見て、スコープが明確で、やる価値のある最も重い開発タスクを開始する。
可視カウンターがゼロになったあともCodexが動き続けたら、それは自分が観測してきた有用な挙動として扱う。権利や保証とは考えない。止まっても驚かない。私は上限を回避する方法を見つけたわけではない。上限に達する前に「何を始めるべきか」を決める、より良い使い方を見つけただけだ。