Claude Codeの上限とリセットまでの時間の確認方法。5時間の枠と週の枠を手元の記録から数える

Claude Codeの上限は2つある。5時間のローリング枠と、週の枠だ。リセットされる時刻は、上限に当たったときのメッセージに出る。事前に残りを見たいなら/usageを開く。

ただ、この2つを知っただけでは、なぜ今日はこんなに早く当たったのかは分からない。減り方を決めているのは打った回数ではなかった。手元の記録から数えたら、1回のやり取りで平均42万トークンの履歴を読み直していた。

以下の仕様は、2026年9月20日にAnthropicの公式ドキュメントの費用管理のページで確かめた。使用量の集計は自分の端末に残っているセッション履歴を数え、Microsoft 365のExcel（バージョン16）で計算した。

上限は2種類あり、モデルを変えても逃げられない

公式ドキュメントには、座席ごとの利用枠がローリングの5時間枠と週の枠でリセットされると書かれている。枠はClaude Codeだけのものではない。ヘルプセンターの記載では、claude.ai、Claude Code、Claude Desktopという別々の入り口での利用が、すべて同じ枠に数えられる。

上限に当たったときのメッセージには2種類ある。ここを読み分けると、待つべきか動けるかが決まる。

セッション上限に達しましたと出た場合と、週の上限に達しましたと出た場合は、全モデル共通の枠だ。/modelでモデルを切り替えても復帰しない。メッセージにリセットの時刻が出るので、その時刻まで待つ。

Opusの上限に達しましたと出た場合は違う。これはモデルごとの枠なので、別の系統のモデルに/modelで切り替えれば作業を続けられる。同じ画面に出る似たメッセージだが、意味が逆になる。

待つ場合、v2.1.234以降のClaude Codeなら、リセット後に中断した作業を自動で続ける選択ができる。自分で選ぶときは/rate-limit-optionsから指定する。

/usageの数字は、この端末の記録から計算されている

/usageにはプランの使用量バーと内訳が出る。dとwのキーで、直近24時間と直近7日を切り替えられる。

ここで見落としやすい注記がある。この数字は、その端末のローカルのセッション履歴から計算した概算だと明記されている。他の端末やclaude.aiでの利用は入らない。枠そのものは全部の入り口で共通なのに、表示はこの端末の分だけになる。複数の端末を使っていると、バーが短いのに上限に当たることが起きる。

内訳では、スキル、サブエージェント、プラグイン、MCPサーバーごとの割合が出る。直近の使用量の10%以上を占める振る舞いには、長い文脈やキャッシュミスといった印がつく。

手元の記録から、自分で数える

/usageが読んでいるのと同じ元データは、自分の端末にある。~/.claude/projects/の下に、プロジェクトごとのフォルダとセッションごとの.jsonlが並んでいる。1行が1件の記録で、応答の行にはusageが入っている。

入力トークン、キャッシュ作成、キャッシュ読み、出力の4つを時刻と一緒に取り出して、CSVに落とした。私の直近およそ30時間分で、重複を除いた応答が1,825回あった。

Excelに読み込んでから、5時間の枠に切る。日時をA列に入れて、G列に枠の開始、H列に枠の通し番号を出す。

G2: =A2
G3: =IF(A3-G2>5/24,A3,G2)
H3: =IF(G3<>G2,H2+1,H2)

5/24が5時間だ。前の枠の開始から5時間を超えた最初の行が、新しい枠を開く。あとは枠番号でSUMIFとCOUNTIFをかければ、枠ごとの合計が出る。

=COUNTIF($H$2:$H$1826,$J2)
=SUMIF($H$2:$H$1826,$J2,$E$2:$E$1826)

回数ではなく、送り直す量で減っていた

30時間分は6つの枠に分かれた。枠ごとに数えた結果がこれだ。

3番目の枠は応答が76回しかない。4番目は499回で、6.6倍やりとりしている。それなのに1回あたりの読み直しは、76回のほうが2倍近く重い。

合計を見ると差がはっきりする。新しく打ち込んだ入力トークンの合計は29,352。キャッシュから読み直した分の合計は782,090,436だった。26,645倍になる。

仕組みは公式ドキュメントに書かれている。Claude Codeは毎回の要求で会話の全体を送る。ツールを使うたびに、その結果を積んだ要求をもう1回送る。キャッシュが効いているので安く読めるが、読んでいる量そのものは減らない。だから、一言の質問でも、その日ずっと開いていた会話の全部を運ぶことになる。上限が減るのは打鍵の回数ではなく、この運搬量のほうだ。

会話が伸びると、1回が5.7倍重くなる

同じ記録で、最初の100回と最後の100回のキャッシュ読みの平均を出した。最初は93,183トークン、最後は527,192トークンだった。5.7倍だ。

会話が長くなるほど1回が重くなる。同じ作業を同じ回数やっても、朝に始めた会話の続きでやるか、/clearしてからやるかで、枠の減り方が変わる。

公式ドキュメントは、長いセッションで使用量が伸びる理由をいくつか挙げている。長い文脈のほかに、キャッシュミスがある。キャッシュの有効期間を超えて間を空けると、次の1回が全文脈の再処理になる。有効期間はサブスクリプションで1時間、使用量クレジットを使っている間は5分に下がり、APIキーやクラウド経由では既定で5分だ。

スケジュールされたタスクも、セッションが止まっている間に勝手に発火して、そのたびに全文脈を送る。別のセッションからのメッセージの受け取りも同じだ。動かしていないのに減っていたときは、この辺りを疑う。応答が遅く感じるときの切り分けはClaude Codeが遅いときの記事に書いた。

踏んだ失敗

上限に当たったとき、モデルを軽いものに切り替えれば続けられると思って/modelを触った。変わらなかった。セッション上限は全モデル共通なので、切り替えは効かない。効くのはモデル別の上限に当たったときだけで、メッセージの文面が違う。読まずに操作したのが失敗だった。

長いセッションを開いたまま、一言の質問を続けていたこともある。数えてみたら、その時間帯の1回あたりが52万トークンを超えていた。作業が変わったところで/clearしていれば、9万トークン台から積み直せた。関係のない話に移るときは会話を切る、というだけのことを守っていなかった。

昼休みを1時間半とってから再開した日もある。キャッシュの有効期間を超えていたので、再開の1回目が全文脈の再処理になった。休憩が長くなると分かっているときは、そこで一度区切る。

読み込ませる指示を短くする話はCLAUDE.mdで効いた項目の記事に書いた。公式ドキュメントも、CLAUDE.mdは200行以下に抑え、細かい手順はスキル側に移すよう勧めている。

確認していないこと

5時間の枠がどの時点から始まるかは、今回読んだページには書かれていなかった。上の集計では、前の枠の開始から5時間を超えた最初の応答が新しい枠を開く、という決め方で切っている。実際の枠の区切りとずれている可能性がある。プランごとの具体的な上限値も公表されていないので、ここでは扱っていない。

週の枠が何曜日の何時にリセットされるかも確認していない。メッセージに出る時刻を見るのが確実だ。

トークンの数え方と、プランの枠の減り方が一対一で対応しているかも分からない。ここで数えたのはローカルの記録にあるトークン数であって、枠の消費量そのものではない。傾向を見る道具として使っている。

出典（2026年9月20日確認）: Anthropic「Manage costs effectively」の/usageコマンド、Claude for Teams and Enterprise、When a developer asks about a limit、Why usage climbs in a long sessionの各項、およびClaudeヘルプセンター「How do usage and length limits work?」。