Codex・Claude Codeの利用制限、残量%で節約していませんか｜12週の実測と、自分で壊してみた判断式

GPT-6 Astraが9月3日に出てから、Codexの枠の減りが変わったと感じている方は多いと思います。

数字にも出ています。OpenAIの目安表では、Plusプランで5時間あたりに送れるローカルのメッセージ数はGPT-5.6 Solが10〜100、Astraが5〜45。単純に比べると、1メッセージの消費はおおむね2倍です。

一方でこの夏のOpenAIは、週間制限を満量に戻す臨時リセットを何度も告知しています。減りは早く、回復は読めない。

残量メーターを見てなんとなく節約し、告知が流れると得をした気になり、来ない週は損をした気になる。心当たりのある方に向けて書いています。弊社もそうでした。

そこで、両社の臨時リセットの告知を12週分数え、その履歴に単純な使い方のルールを当てて再生しました。

先に結論だけ。残量の何%を切ったら節約する、という固定の閾値は成り立ちません。 正しい閾値は、次の定期回復までの日数で毎日変わるからです。

代わりに計算するのは1つ。自由に使える量＝残量から、次の定期回復までに必ず要る量を引いたぶん。臨時リセットは当てにしませんが、来たときの取りこぼしは減ります。

その判断式も、弊社の勤務時間を入れて回し直したら一度壊れました。どこが壊れて、どう直したかまで書きます。

※利用制限：Claudeには5時間ごとに戻る枠と、7日単位で戻る週間の枠があります。Codexも5時間あたりの目安に加えて、週間の制限が適用されることがあります。この記事は週間の枠が中心です。

枠が減るのが早くなった理由と、上限に当たったときの5つの選択肢

Codexの利用は、ローカルの操作もクラウドのチャットも同じ枠を消費します。5時間あたりの目安に加えて、週間の制限も適用されることがあります（原文は「may also apply」）。

Claudeは、ProもMaxも5時間枠と週間枠の二段構えです。週間枠はアカウントごとの固定の曜日・時刻に戻ります。claude.ai、Claude Code、デスクトップのどこで使っても同じ枠を消費します。

使用状況の画面では、上位モデルの週間枠と全モデル共通の週間枠が別に出ます。画面が2本立てになっているので、上位モデルの仕事は共通枠にも乗ると読めます（逐語で説明した公式文書は見つけられませんでした）。

ここに臨時リセットが重なります。担当者がXで「戻した」と告知することがあり、有志の追跡サイトまで存在します。残量メーターは、仕事の道具というより気分を上下させる装置になっています。

5時間の枠は待てば戻りますが、週間の枠はそうはいきません。制限がきついと感じる場面の多くは、こちらが原因です。

「枠が戻る」と言っても、中身は5種類あります。上限に当たったときに何が使えるかも、この分け方で決まります。この記事で数えたのは2つ目だけです。

呼び方	中身
定期回復	7日ごとに満量へ。次回の日時は画面に出る
臨時リセット	運営側が任意のタイミングで満量へ。Xで告知。この記事の集計対象
保有リセット（券）	あとで使える即時回復。リセット券・リセットチケットとも呼ばれる。付与から30日間有効。Codex側
購入リセット	有料の即時回復。次の定期回復は使用再開から7日後に組み直される
利用クレジット	Claude側。枠を超えたあと従量課金で続ける。枠は戻らない

臨時リセットを12週数えると、Codexは週2回、Claudeは月1〜2回だった

数えたのは、日本時間の月曜0時で区切った完了週。2026年6月15日から9月6日までの12週です。

対象は、公開告知で週間枠の即時回復が確認できるものだけ。定期の回復、5時間枠だけの回復、上限の増量、券の配布は数えていません。

28件はすべて、公式担当者のXの原文を開いて確かめました。ただし元の一覧が完全である保証はないので、ここでの0回は「告知が見つからなかった」という意味です。

結果は、Codex 23回、Claude Max 5回。週あたり1.92回と0.42回でした。

期間の取り方で変わらないかも見ています。直近8週はCodex 16回（週2.00）、Claude 2回（週0.25）。直近4週はCodex 7回、Claude 1回。

告知が1回もなかった週は、直近8週でCodexが1週、Claudeが6週。間隔がいちばん空いたのは、Codexが10.99日、Claudeが50.67日です。

ここから言えることは3つです。

1. Codexの「だいたい週2回」という体感は正しい。 4週・8週・12週のどの区切りでも支持されます
2. Claudeの「週1回くらい」は、直近8週では確認できません。 12週を4週ずつに切ると3回、1回、1回。週1回に近かったのは6月中旬から7月中旬だけです
3. どちらにも7日を超える空白があります。 週2回という平均は、来ない週があることと両立します

頻度より大事なのは、リセットが「置換」だということ

リセットは残量を100%に戻す操作で、100%を足す操作ではありません。

OpenAIの公式ヘルプも、購入するリセットについて、通常の週間枠を前倒しで戻すものであり別の枠を追加するものではない、と説明しています。

残り80%のときに来たリセットで受け取れるのは20%分。残り10%なら90%分です。

つまり、節約して残量を高く保っている人ほど、臨時リセットから受け取る量は小さい。週2回を「毎週+200%」と読むのは誤りです。

だから、定期回復だけを前提に均等に節約するのは、使い残しを増やす方向に働きます。使うほうが合理的です。

ただし、使い切った直後に11日の空白が来る可能性も、同じ履歴の中にあります。

告知が来る時間帯にも、はっきりした偏りがあります

28件の告知時刻を数えると、すべてが日本時間の1時35分から14時54分の間に収まっていました。15時台から翌0時台までの告知はゼロです。46%は朝8時台から昼12時台に集まっています。

ただし、これを「日本の昼に回復している」と読むのは早すぎます。同じ28件を米西海岸の時刻に直すと、全件が午前9時35分から午後10時54分に入り、現地の9時から18時のあいだに68%が収まりました。

曜日でも同じことが起きています。日本時間では土曜が最多の7件ですが、米西海岸に直すと金曜の7件です。担当者が働いている時間に投稿しているのを、日本時間で見ているだけです。

それでも、日中に使う人には効いてくる向きがあります。9時から19時を稼働とすると、稼働中に届いたのは13件（46%）で、残りの15件（54%）は退勤後から翌日の始業前に届いていました。

つまり過半数は、その日の消費が終わったあと、翌日の消費が始まる前に来ています。置換の性質と重ねると、使い切ってから一日を終えた人がいちばん受け取れるという形です。

逆に、節約している人ほど、朝の告知の時点で残量が高くなっています。告知を待つ理由にはなりませんが、前倒しで使う理由はここでも増えます。

問いは「節約か、使い切るか」ではありません。「どこまで使ってよいかを、何で決めるか」です。

同じ残り30%で、答えが逆になる

その時間帯に処理できないと締切に間に合わない仕事が、1日8ポイントあるとします。ポイントは週間枠の1%です。以下は5日とも同じだけ働く前提の例で、休みが入る日の数え方は後の手順2に書きます。

残量30%・次の定期回復まで5日。 必要量は8×5で40。10足りません。節約では埋まらないので、別のAIへ移すか、順番を変えるか、券を使う判断が要ります。

残量30%・次の定期回復まで1日。 必要量は8。残り22は自由に使えます。ここで節約すると、翌日の定期回復で22ポイントがそのまま消えます。

同じ残り30%で、一方は不足、一方は余剰。固定の閾値は、この2つを区別できません。

見ていないのは、次の回復までの日数と、それまでに必要な量。正しい閾値はこの2つで日ごとに変わるので、固定の%には置けません。

枠の足し算にも注意してください。5時間枠と週間枠、上位モデル枠と共通枠、Codexの枠とClaudeの枠。全部が別々の制約です。

40%と30%だから70%、という計算に意味はありません。いちばんきつい1つが、その場の上限を決めます。

自由に使える量は、残量から必ず要る量を引いたぶん

弊社が代わりに使っているのは、枠ごとの3つの数字です。

• R：いま表示されている残量（%）
• T：画面に出ている、次の定期回復の日時
• B：Tまでに締切が来る重要な仕事に必要な量（%換算）

自由に使える量は S＝max(0, R−B)。Sの範囲で、価値の高い順に前倒しします。

Bは固定の60%のような数字に置かず、期限のある仕事から積み上げます。見積もりが荒いうちはBに余裕を上乗せする。上乗せした分だけ前倒しが減る、というトレードオフが数字で見えるのが、閾値との違いです。

残量と次のリセット時刻の確認方法は、どちらも決まっています。

• Codex：CLIの /status、またはChatGPTの設定にある使用状況（Usage）
• Claude：claude.aiの設定にあるUsage、またはClaude Codeの /usage

運用の手順です。全部を一度に整えなくても、まず1と2だけで判断の質は変わります。

1. 見るタイミングを決める。 業務の開始時、大きな仕事の前、回復や締切が変わったとき。それ以外で残量メーターを見ない
2. Bは締切のある仕事だけで積む。 やりたい仕事を入れ始めると、Sがいつまでも0のままになります。積むのはカレンダーの日数ではなく、Tまでに実際に働くぶんです。回復の時刻が勤務時間の途中や終業後に来る日は、日数のまま数えると足りません。逆に休みをまたぐ日は、日数で積んだBが実際より大きく出ます
3. Sの範囲で前倒しする。 臨時リセットが来たらRが100に戻るので、その場で再計算。後回しにできる仕事の一覧を先に用意しておくと迷いません
4. B>Rなら不足。 別のAIへ作業単位で移す、券を使う、順番を変える、購入リセットや利用クレジットを費用と比べる、のどれかが要ります。CodexとClaudeの枠は別勘定なので、片方が尽きたらもう片方へ、という併用は成立します
5. 券はRに足さない。 Tまで有効な券だけをBの裏付けに数えます。だから使える量はRを超えません。将来配られるかもしれない分は資産に数えない
6. モデルの格下げは残量だけで決めない。 比べるのは合格品1件あたりの枠消費、再試行の回数、確認にかかる人の時間です

Bを見積もる元データが手元にない、という方がほとんどだと思います。弊社もまだ揃っていません。

大げさな計測は要りません。仕事の開始時と終了時に、使ったAIとモデル、作業の種類、前後の残量%、修正が何回入ったかを1行ずつ書くだけです。

同じ種類の仕事が10件ほどたまるまでは、数件の最大値を保守的な見積もりに使います。

過去12週の履歴に、3つの使い方を当てて再生した

机上の理屈で終わらないかを確かめるため、実際の告知履歴にルールを当てて再生しました。ここから先は実績ではなく、仮想の仕事量を使った試算です。

条件はこうです。週間枠を100ポイント、28日間を1時間刻み。仕事は1日あたり重要10ポイントと通常20ポイント。重要な仕事はその時間帯に処理できなければ失われ、通常の仕事は後回しにできます。

12週の告知から28日の窓を9通り取り、定期回復の初期位置を7通りずらして、方式ごとに63回。どの方式も、次の臨時リセットがいつ来るかは知りません。

比べたのは3つです。

• 均等配分：残量を次の定期回復までの残り日数で毎日割り直す
• 重要枠確保：上の判断式。Bを残してSを前倒し
• 即利用：重要な仕事のあと、残りを全部すぐ使う

もうひとつ、結果に大きく効く分岐があります。臨時リセットで定期回復の予定日が動くかどうかです。

公式ヘルプは、購入したリセットについては使用再開から7日後に組み直されると明記しています。無料の臨時リセットや券でも同じかは確認できなかったので、両方の仮定で試算しました。

自分がどちらの世界にいるかは判別できます。臨時リセットの直後に、画面のTが7日先へ動いたかを見るだけです。

予定日が動く仮定の結果です。

Codexでは、均等配分が28日で138.0ポイント処理したのに対し、重要枠確保は319.6ポイント。2.3倍です。重要な仕事の未処理は、どちらも0でした。

即利用は546.3ポイントと最も多く処理します。ただし重要な仕事280ポイントのうち72.1ポイント、およそ4分の1を落としました。

券が2枚ある条件では、Tまで有効な券をBの裏付けに数える方式が426.2ポイントまで伸び、未処理は0のまま。ただしこれは、券が裏付けの間は残量を使い切り、重要な仕事が止まった時点で券を切る規則です。実務では0%の手前で切ってよく、その分は下がります。

Claudeは臨時リセットが少ないぶん差が小さく、均等配分144.9に対して重要枠確保181.4。即利用は456.0を処理する代わりに、重要な仕事の7割にあたる199.2を落としました。

予定日が動かない仮定では、均等配分の成績が上がります。Codexで405.5対526.6、Claudeで207.8対244.4。改善の幅は仕様しだいなので、単一の改善率は結論にしません。

固定閾値そのものも走らせた

公開前のレビューで「閾値が成り立たないと書きながら、閾値方式を再生していない」と指摘されたので、追加で回しました。残量がその%を割ったら通常の仕事を止める方式です。

方式	通常の処理／重要の未処理（予定日が動く → 動かない）
判断式 S＝R−B	319.6／0 → 526.6／0
固定閾値60%	388.6／8.4 → 465.1／3.0
固定閾値70%	298.9／0 → 365.3／0
固定閾値80%	202.3／0 → 247.9／0

予定日が動く仮定では、判断式と70%閾値の差は7%しかありません。

リセットのたびにTが7日先へ動くので、B＝10×7＝70、S＝30。判断式は事実上「リセットのたびに30だけ前倒し」＝70%の固定閾値と同じ動きになるからです。

判断式が閾値に差をつけるのは、予定日が動かない仮定のほうでした。そこでは60%閾値が63回中29回で重要な仕事を落とし、70%閾値は通常の処理が3割少ない。

正確に言えばこうです。固定の閾値が外れるのは、Tまでの日数が変わる世界。判断式は、その日数に合わせて閾値を毎回引き直しているだけです。

「未処理0」は検証結果ではなく、方式の定義

条件を振っても崩れないかも見ました。いずれも仕事が24時間均一に発生する前提です。重要5・10、総需要20・30・50、予定日の2仮定、券0・2枚で合計9,072回。うち重要枠確保は2,268回で、すべて未処理0でした。

ただし、これは方式の定義から従う結果です。判断式はTまでの重要分より下に残量を落とさないので、その前提のもとでは、週間枠の7分の1（1日14.3ポイント）を超える重要な仕事がない限り、未処理0は自動的に成り立ちます。

9,072回で確かめたのは、実装が定義どおり動くこと。方式が現実に安全だという証拠ではありません。重複条件も含む、重なる窓と条件の掛け合わせの数です。

本当に効くのは、見積もりの誤差のほうでした。

重要な仕事を実際の10ポイントより1割低い9ポイントと見積もると、63回中57回（動かない仮定は59回）で重要な仕事が止まります。2割低ければ、止まる量は倍です。

逆に2割高く見積もっても、未処理は0のまま。失う通常の処理は、動かない仮定で4%、動く仮定で25%でした。

だからBは多めに置く。 その代償は、少なくとも片方の仮定では小さい、という数字です。

自分たちの勤務時間を入れたら、この判断式は一度壊れました

見積もりがずれる原因は、うっかりだけに限りません。仕事の発生が時間帯に偏るだけで、同じずれが起きます。

ここまでの再生は、仕事が24時間均一に発生する前提でした。ここへ弊社の実際の稼働時間である9時から19時を入れて回し直すと、判断式でも重要な仕事の未処理が出ます。Codexの動く仮定で1.2ポイント（63回中57回）、Claudeの固定仮定では12.6ポイント（63回とも）でした。

原因はBの積み方です。残り日数で積むと、残りが0.5日でもその中に勤務時間が丸ごと入ることがあり、Bが実際に発生する量より小さく出ます。

Tまでに実際に発生する量でBを積み直すと、未処理は0へ戻りました。 4条件すべてでです。代わりに通常の処理が1.5%から7.7%減ります。24時間均一の場合は両方の積み方が一致するので、先ほどの未処理0は、その特殊な場合の話だったことになります。

28日間に臨時リセットが一度も来ない条件でも、Bを実際に働くぶんで積んでいれば未処理は0でした。勤務時間を入れても数字は変わりません。券2枚を使う方式は、券なしの約2倍を処理します。将来の配布を当てにしなくても、手持ちの券を前倒しの原資にできます。

重要な仕事の価値しだいで、結論は変わる

即利用が通常の仕事をいちばん多く処理するのは事実です。重要枠確保が上だと言えるのは、重要な仕事を落とす損失が十分に大きいときだけ。

通常の仕事1ポイントの価値を1、重要な仕事1ポイントの価値をwとすると、重要10・通常20の条件で、損益分岐はこうなりました。

• Codex・券なし：w＝約3.1
• Codex・券2枚：w＝約3.5
• Claude：w＝約1.4

重要な仕事が通常の3倍より価値があるなら重要枠確保、そうでなければ即利用が高得点、という意味です。

ただし分岐は条件で動きます。Codexは通常の需要が少ない条件で0.3前後、多い条件で2.7〜2.9。いちばん振れるのは中間の条件で、1.1から3.1まで開きます。予定日が動かない仮定では全体が0.2〜2.4。Claudeはどの条件でも1.0〜1.4で安定していました。

締切違反の損失は、実際には回数に比例しません。1回落とすだけで信用ごと失うことがあるので、弊社は重要な仕事を先に守るほうを制約として置いています。

この価値判断を抜きに「最適」とは言えません。

この試算が言っていないこと

• 告知の一覧が完全でなければ、頻度は過少に出ます。告知時刻と実際の回復時刻にもずれがあります
• 週間枠を単一の100ポイントで表していますが、実際の容量はモデルや処理内容で変わります
• 勤務時間の9時から19時は弊社の実際の稼働時間ですが、その中で仕事が均一に発生するという置き方はしています。1時間あたりの消費量はまだ測っていません
• 判断式でも、リセット直前に残っていた分は消えます。 動く仮定のCodexで28日平均411ポイント、供給された枠の38%。予測に頼らない代償です
• 5時間枠を入れていないので、前倒しの速度は現実より速く出ています
• AI間の移管は含めていません。CodexとClaudeの100ポイントは別の量なので、図3を群をまたいで比べないでください
• 弊社の実運用で生産性が上がったという実績ではありません。感度分析です
• 必ず週2回来る、全員の全枠が毎回回復する、停止確率0%。いずれも立証していません

それでも公開する理由は、この判断式が臨時リセットの予測に依存していないからです。

頼っているのは、画面に出ている次の定期回復の日時だけ。来なくてもBの範囲は守られ、来ればSの分は取りこぼさない。この非対称性は、頻度の数字が多少ずれても残ります。

弊社が2つのAIでしていること

弊社はClaudeが記事の構成と本文、Codexが管理と開発と根拠の検証を担当しています。この分担は品質と権限で決めていて、残量では動かしません。何を基準にどう分けたかはCodex・Claude Codeの使い分けに書きました。

残量に応じて配分を見直すのは、調査や資料整理のように、どちらに任せても品質条件を満たせる仕事だけです。

今回の分析も同じ分担で作りました。告知28件の分類と再生の実装はCodex、記事の構成と本文はClaude、公開前の検査は別のセッションで独立に行っています。

足りていないのは、弊社自身の仕事ごとの消費量です。だから「残量の何%が自由に使えます」という具体的な数字は、まだ書けません。

測れたら、この記事の数字を差し替えます。予定より悪かった場合も、そのまま書きます。

1行ずつ記録して、測れないものは測れないと書く。この型はAI検索の効果測定でも同じにしています。弊社の体制は会社概要に置きました。

Codex・Claude Codeの利用制限についてよくある質問

Q 残量と、次の定期回復の日時はどこで見られますか

A

Codexは、CLIの/statusかChatGPTの設定にある使用状況（Usage）です。Claudeは、claude.aiの設定にあるUsageかClaude Codeの/usage。5時間枠と週間枠は別の制約なので、その場できついほうが上限になります。判断式は枠ごとに同じ形で使えます。5時間枠なら、Tは窓が切り替わる時刻、Bはそれまでに必要な量です。

Q 臨時リセットは、これからも週2回来ますか

A

分かりません。12週でCodexは週1.92回でしたが、10.99日の空白もありました。運営側の判断で行われるものなので、頻度は変わり得ます。この記事の判断式は頻度を前提に置いていないので、下がっても構造は崩れません。

Q Claude Codeの週間制限は、いつリセットされますか

A

ProもMaxも、アカウントごとに割り当てられた固定の曜日・時刻です。使い始めた日や契約日に関係なく、毎週同じ時刻。claude.ai、Claude Code、デスクトップの利用は同じ枠を消費し、次回の時刻は設定のUsageに出ます。上位モデルの週間枠は別に表示されます。

Q GPT-6 Astraは枠の減りが2倍と聞きました。Solに戻したほうがいいですか

A

残量だけで決めないほうがよいと思います。目安表でメッセージ数が半分なのは事実ですが、比べるべきは合格品1件を出すまでの枠消費と再試行、人が確認する時間です。Astraで1回で通るなら、Solで2回やり直すより安く済むことがあります。トークンの節約それ自体は目的ではありません。切り替えるなら作業単位で。

Q Codexの保有リセットは、いつ使うのが得ですか

A

使いどきは2つ。重要な仕事が残量不足で止まる時点と、価値のある仕事が待ちになって納期や品質に損が出始める時点です。0%まで待って実行中の仕事を止める必要はありません。期限が近いものから使い、失効の損失と、残量が多いうちに使って受け取りが小さくなる損失を比べてください。公式の料金ページでは付与から30日間有効ですが、配布分も同じかは自分の画面で確認を。

Q 制限解除はできますか。上限に達したら、待つ以外に何ができますか

A

枠そのものを解除する設定はありません。できるのは4つで、別のAIへ作業単位で移す、Codexなら券（リセット券）を使う、購入リセットを使う、Claudeなら利用クレジットで従量課金に切り替える。どれを選ぶかは、止まっている仕事の価値と次の定期回復までの日数で決まります。購入リセットは、使い残しがあっても即時に満量へ戻り、あとに取っておくことはできません。なお、プロンプトで制限を解除するという類の話は、ここでいう利用枠とは別のもので、規約に触れる可能性があります。この記事では扱いません。

まとめ：明日は、必ず要る量を1回だけ引き算する

残量の%で節約する決め方は、次の回復までの日数と、それまでに必要な量を見ていません。

だから同じ30%で逆の判断が必要な場面を区別できず、節約した週は臨時リセットの恩恵が小さく、使い切った週は空白に当たる。一喜一憂の正体は、判断の材料が足りないことです。

明日やることは1つ。画面で次の定期回復の日時を見て、それまでに締切が来る仕事に要る量を、粗くてよいので%で書き出す。

元データがなければ、直近の似た仕事で減った%を当てて、台帳を1行目から始めれば足ります。

残量からそれを引いた分は、気兼ねなく使ってください。使う仕事がなければ、使わなくて構いません。0%にすることが目的ではないので。

臨時リセットが来たら、その場でもう一度引き算をするだけです。告知を待つ必要はありません。

再現用のデータとスクリプト

同じフォルダに置いて python3 simulate.py のあとに python3 verify_simulation.py を実行します。Python 3.9以上、標準ライブラリだけで動きます。

告知の一覧は、有志の追跡サイト（codex-resets.com と claude-resets.com）を起点に、28件すべてを公式担当者のXの原文で確認して分類し直したものです。

• events_public.json：38件の告知日時、分類、対象、原文URL。うち主集計の28件はcount_main=true
• simulate.py：3方式の定義と2つの予定日の仮定はこの中にあります
• verify_workday.py：固定閾値・見積もり誤差・勤務時間の3つの追試。この記事のために書き足したもので、均一の条件では上のsimulate.pyと同じ値を返します
• verify_simulation.py：残量の計算、需要の収支、券の失効、置換であることを検査
• simulation_results.json：144条件群、9,072再生の要約（約280KB）
• 一式のzip：上記に研究メモ2本とREADMEを同梱

参考にした公式情報

• OpenAI「GPT-6 Astra: A new generation of intelligence」（2026年9月3日公開・9月8日確認）
• OpenAI Help Center「Paid weekly Work and Codex rate limit resets」（9月8日確認）
• OpenAI Help Center「Using Codex with your ChatGPT plan」（9月8日確認）
• OpenAI「Pricing」（ChatGPT Work and Codex）（9月8日確認）
• Claude Help Center「What is the Max plan?」（9月8日確認）
• Claude Help Center「What is the Pro plan?」（9月8日確認）
• Claude Help Center「How do usage and length limits work?」（9月8日確認）
• Claude Help Center「Usage limit best practices」（9月8日確認）
• Claude Help Center「Manage usage credits for paid Claude plans」（9月8日確認）
• GitHub openai/codex Issue #43201（利用者による報告・9月8日確認）

臨時リセットの頻度も上限の仕様も、来週には変わっているかもしれません。数字は上の一覧を更新して引き直してください。