Codexの残り使用量が1%になったら、巨大で曖昧な依頼を投げるより、入力と完成条件が決まった「最後まで流れる仕事」を任せるのがよさそうです。
これは公式の攻略法ではありません。私の推測です。
リセットが近いなら、できるだけ贅沢に使って、記事やコードを仕上げたい。けれど、そこで投げた仕事が確認待ちや認証待ちで止まると、残りの使用量だけを消費して成果物が残らないことがあります。
この記事では、1%を切ったときに何を任せるか、どんな依頼なら途中で止まりにくいかを分解します。
この話のきっかけは、残り1%に大きな仕事を入れる使い方
2026年8月4日、ついはじめさん（@hajimetwi3）のXで、Codexの残り使用量が1%になったあと、自動承認の設定を切り替え、Solの高速モードで重い処理を走らせる使い方が話題になっていました。
Codeswitcherさん（@codeswitcher41）は、残り1%のときに大きなタスクをいくつも入れ、合計で8000行以上のコードを生成したと返信していました。0%になったあとも、進行中の仕事がしばらく続いたという話です。
一方で、その使い方をすると次の利用枠にカウントされるのではないか、という指摘もありました。
この部分は、私の環境でまだ比較できていません。だから「1%になったら必ず使い切るべき」とは言いません。
公式に確認できることと、まだ分からないことを分ける
OpenAIの公式ヘルプでは、Codexの消費量は単純なメッセージ数だけで決まりません。モデル、入力・キャッシュ入力・出力のトークン、タスクの大きさ、実行場所などで変わります。
また、Codexのレートカードでは、Fast Modeは対応モデルでクレジットを高いレートで消費すると説明されています。速く進む可能性はありますが、残り使用量が長持ちする設定ではありません。
上限に到達したときも、進行中のターンは公正利用の範囲で続く場合があります。ただし、すべての環境で同じように続く保証ではありません。
つまり、公式情報から言えるのは次の範囲です。
- 大きな仕事ほど、使用量が増えやすい
- モデルやFast Modeによって消費の仕方が変わる
- 上限到達後も、現在のターンが続く場合がある
- 1%で始めた仕事が、次の利用枠にどう反映されるかは環境ごとに確認が必要
最後の項目は、画面の表示と実際の利用履歴を見ないと判断できません。
私の仮説。1%は「使い切り」ではなく「ラストワンマイル」に使う
私が考えているのは、1%を無理に燃やすことではありません。
すでに調査や設計が終わっていて、残りの作業を一気に仕上げられるものを投げることです。
たとえば、記事なら次のような仕事です。
- すでに集めた材料を読む
- 結論先行の構成にする
- 本文を書く
- 事実・本人発言・推測を分ける
- FAQとメタディスクリプションを追加する
- ローカルに保存し、リンクと表記を確認する
この流れなら、途中で「次は何をしますか」と聞かれる回数を減らせます。
ここでいう「止まらない」は、確認を全部なくすという意味ではありません。人の判断が必要な操作を避け、Codexが自分で次の安全な工程へ進める状態です。
途中で止まりにくいタスクの条件
1%付近で任せる仕事は、次の5つを満たすものが向いています。
入力がそろっている
対象ファイル、記事本文、画像、テストコマンドなどが、すでに手元にある仕事です。
新しい認証、追加の資料探し、外部サービスのログインが必要な仕事は止まりやすくなります。
工程が順番になっている
「いい感じに仕上げる」ではなく、調査、作成、検証、報告の順番を書きます。
工程が決まっていれば、1つの作業が終わったあとに次へ移りやすくなります。
変更範囲が狭い
「リポジトリ全体を改善する」より、「このファイルのこの機能を直し、テストを通す」の方が安全です。
大きな仕事を任せる場合も、対象を増やすのではなく、工程を増やします。
失敗しても戻せる
ローカル下書き、作業ブランチ、差分確認、テスト実行のように、結果を確認してから次へ進める仕事にします。
完了条件が機械的に確認できる
「読みやすくなった」だけで終わらせず、ファイルが保存された、構文チェックが通った、リンクが存在する、といった証拠を指定します。
1%のときに任せやすい仕事
私なら、次のような順番で選びます。
1. 仕上げ前の記事
記事の材料がそろっているなら、構成、本文、FAQ、メタ情報、内部リンク候補、表記チェックまでを一つの流れにします。
公開ではなく、ローカルの下書き完成までに限定します。
2. 既存コードの限定修正とテスト
対象ファイルと直したい挙動を先に固定します。
実装だけでなく、静的チェック、テスト、差分確認、残課題の報告までを同じタスクに含めます。
3. テストと棚卸し
新しい機能を大量に作るのではなく、既存機能を調べ、失敗箇所を分類し、安全な小修正まで行う仕事です。
修正できないものも、再現手順と原因候補が残れば成果になります。
1%のときに任せない仕事
残りを使い切りたいからといって、次の仕事を混ぜるのは避けます。
- 公開、deploy、cache purge
- 削除、大量移動、既存データの一括上書き
- 認証情報が必要な操作
- 外部への投稿、メール送信、課金を伴う操作
- 「サイト全体をよくして」のように対象が決まっていない依頼
- 既存の本文画像、アイキャッチ、URLを守る条件がない大規模改稿
自動承認の切り替えやモデル変更は、残り使用量を増やす魔法ではありません。設定を変える場合も、公開や削除を許可する理由にはしない方が安全です。
そのまま使える「残り1%用」の依頼文
次のように、目的、対象、禁止事項、工程、完了条件を一つにまとめます。
残り使用量が少ないため、今回のターンで1つの成果物を最後まで仕上げてください。
目的:
[完成させたい記事・コード・検証結果]
対象:
[ファイル、本文、URL、使ってよい資料]
許可:
- 対象範囲内のローカル編集
- 下書き保存
- テスト、静的チェック、差分確認
禁止:
- 公開、deploy、cache purge
- 削除、大量移動、外部送信、課金
- 認証設定の変更
- 指定していないファイルや既存画像・URLの変更
工程:
1. 対象と完了条件を確認する
2. 必要な調査を対象範囲内で行う
3. 成果物を作る
4. 検証を実行する
5. 問題があれば安全な範囲で修正して再検証する
6. 最後に、変更ファイル・確認結果・未確認事項を報告する
進行ルール:
- 安全に仮定できることは仮定して進める
- 追加の承認や認証が必要な場合は実行せず、読み取り・検証・作業メモへ切り替える
- 途中で止まる代わりに、残りの安全な工程を続ける
- 公開状態にはしない
完了条件:
[保存先、テスト結果、確認した項目、最終報告に必要な証拠]「とにかく重い処理をして」ではなく、「最後に何が残れば完成か」を書くのがポイントです。
仮説を本当に使える知識にする記録方法
1%の使い方は、感覚だけだとすぐに噂になります。試すなら、毎回次の項目をメモします。
| 記録する項目 | 例 |
|---|---|
| 開始時の残量 | 1%、0%など |
| 表示されたリセット時刻 | 画面に出た内容をそのまま記録 |
| モデルと速度設定 | Sol、Fast Modeなど |
| タスクの種類 | 記事、実装、テスト |
| 終了状態 | 完成、途中、停止、次のターンへ継続 |
| 次の利用枠への影響 | 残量表示の変化を確認 |
| 成果物 | ファイル、差分、テスト結果 |
比較するなら、同じくらいの規模のタスクを、通常時と1%付近で分けて試します。
「0%になっても続いた」という体験だけでは、次の枠に影響したかまでは分かりません。開始時と終了時の表示を残して、初めて検証できます。
よくある疑問
0%になっても作業は続きますか？
進行中のターンが、公正利用の範囲で続く場合はあります。ただし、必ず続くとは限りません。止まっても成果が残るように、途中保存と段階的な完了条件を入れておきます。
SolのFast Modeにすれば、たくさん作れますか？
速さと成果量は同じではありません。Fast Modeは高いレートで消費するため、重要な仕上げに絞って使います。
自動承認を切り替えると、使用量を使い切れますか？
自動承認は操作の許可範囲に関わる設定です。使用量を増やす設定として扱わず、外部操作や破壊的操作を避ける条件を先に決めます。
大きなコードを大量に生成するのが一番よいですか？
行数は成果ではありません。あとで読み直し、テストし、直せる成果物を優先します。1%の最後に必要なのは、コードの量より完成に近づくことです。
まとめ
Codexの残り使用量が1%になったら、私は「何でもいいから重い仕事」ではなく、「準備が終わっていて、途中で確認待ちになりにくく、ローカルで最後まで検証できる仕事」を任せます。
自動承認やSol高速モードの切り替えは、話題になった使い方の一部です。ただ、それだけで次の利用枠への影響や成果量が決まるわけではありません。
1%を使い切る方法として残したいのは、設定名ではなく、仕事の設計です。
目的を一つにする。対象を固定する。工程を順番にする。禁止事項を書く。最後に証拠を残す。
リセット前に仕上げたいものがあるなら、まずその仕事を「止まらない最後の工程」に分解してから投げる。今のところ、これが私の一番再現しやすい仮説です。
