2026-11-09 · 6 分で読める

Claude Code の利用上限:5時間ウィンドウ、週次上限、429、そして壁の後のすべての道

サブスクの上限は同時に進む2つの時計:5時間ローリングウィンドウと週次上限。どう回り、なぜ Opus が週次プールを先に使い切るのか、429 が本当は何を言っているのか、壁の後の5つの出口をコスト順に並べる。

上限というものは、普段は存在せず、忙しい瞬間にだけ現れる。月次請求書と一緒に届くのではなく、リファクタの途中、金曜の夜というタイミングを選んで、エージェントを「後でもう一度」としか言わない入力ボックスに変える。この記事は上限の回避法ではない——それは正当な目標ではない。分解することだ:どの時計が回っているのか、壁に当たったとき機械は何を告げているのか、出口は実際にいくつあり、それぞれの値段はいくらか。

最初に明かします:私は Claude Code 向けの従量課金ゲートウェイ Teapot Router を運営しています。だから下の出口のひとつには明白な利害がある——だから出口は安い順に並べ、無料のものを最初に置いた。並び順が公正かどうかは自分で判断してほしい。

上限は同時に回る2つの時計

Claude Code のサブスク上限は数字ひとつではなく2つ:5時間のローリングウィンドウと、週次上限。ウィンドウは使い始めた時点から起算して5時間後にリセットされ、週次上限は週全体をまたいで、ウィンドウが許してくれなかった分を積み上げる。火曜午後の一気の作業は火曜のウィンドウだけではなく、今週のプールからも減っている。

だから「リセットされたばかりなのにまた上限」は大抵バグではない。5時間ウィンドウが一杯なのと週次上限が底をつくのとは別の感覚で、後者ならウィンドウが空になっても週が変わるのを待つしかない。/usage で自分がどちらの時計の前に立っているかを確かめられる。

  • 5時間ウィンドウ:ローリングでリセット。「今すぐ続けられるか」を決める。
  • 週次上限:累積。「今週あとどれだけあるか」を決める。
  • 2つは独立に計量され、先に満ちた方があなたを止める。

なぜ Opus がいつも週次上限を先に使い切るのか

週次上限は「使用量」で計り、フラッグシップモデルは1ターンあたり軽量モデルの数倍の使用量を食う——長いコンテキスト入り、長い完了出。同じ8時間のヘビーな日は、Opus だと Sonnet の数倍の速さで週次プールを減らす。ここから例の非対称が生まれる:週前半に数日 Opus を回すと、Sonnet 専用枠が残っていても週次上限が先に尽きる——プールは共有で、専用枠は全体タンクを満たし直さない。

これはヘビーユーザーへの罰ではなく、料金構造が書いた通りに動いているだけ。サブスクは定額保険で、保険料はどのモデルを使うかに頑丈、だがプールには底がある。それが見えれば、「モデルを変える」と「課金方式を変える」は民間信仰ではなく同じ算術の2つの変数になる。

壁に当たった瞬間、中で何が起きているのか

表面上の症状は 429 だ。これはエラーというより、プロトコルが正直に「クォータを使い切った、復帰時刻はレスポンスヘッダにある」と告げているだけ。大抵のクライアントは復帰時刻を表示してくれる——だから壁での最初の一手はツールの乗り換えではなく、時計を読んで次の1時間をどう過ごすか決めること。

はっきり言っておく価値がある:この壁はサブスク経路に存在する。従量課金の API 経路に 5 時間ウィンドウも週次プールもなく、その制限は別種(毎分のスループットと月次支出上限)で、一人でコードを書く量ではまず当たらない。従量が優れているという話ではなく——壁をメーターに交換するだけだ——しかし下のすべての出口はここで分かれる。

5つの出口、安い順に

壁の後の選択肢は昔からどこかに書いてある。ばらばらのドキュメントに散らばっているだけだ。集めて「安いのから試す」順に並べた:

  1. リセットを待つ。5時間ウィンドウはすぐターンし、費用ゼロ。「あと一息」の状況なら:タスクを保留にし、ウィンドウが回ったら片付ける。
  2. コンテキストを圧縮する。/compact か新しいセッション開始。各ターンはそれまでの会話を再送するので、無駄を落とせば残りの各ターンが安くなる。クォータは戻らないが、残りが長持ちする。
  3. モデルを一段下げる。定型編集や検索にフラッグシップは要らない。本当に難しい依存だけ Opus に残せば、週次の消費速度はすぐ下がる。過小評価されている出口:多くの人のデフォルトモデルは、そのタスクの大半に過剰性能だ。
  4. プランを上げる。1日数時間をフラッグシップに集中させる使い方なら、大きなプールは本当に単位あたり安い——それがティアの存在理由だ。使うべきところで使う。
  5. 従量課金へ切り替える。壁は消え、メーターが回り始める。使用が多様・不定期・複数ツール分散の人、そして月に1回以上壁に当たる人に合う——止められた時間もコストだから。

どの形の人がどこで止まるべきか

最初の4つの出口にこの記事は要らない。壁に一度当たった人は自ずと覚える。算術を止してやる価値があるのは4番と5番の間:プランを上げるか、従量に切り替えるか。

その判断の原料は自分の使用形状だ:1日の集中時間、タスクの強度、キャッシュの効き。それをコスト計算ツールに入れると損益分岐——従量の支出がプラン価格に追いつく1日あたりの時間——が出る。その線より下なら従量が安く、上ならプランが勝ち、壁は自分で選んだ保険料になる。万能の答えはなく、自分の掛け算だけがある。

知っておくべき非対称がひとつ:プランの価格は固定だが、従量の単価はレート表に従う。メーターを選ぶ人は、機械可読な価格表とリクエスト単位の明細を要求すべき——さもないと「メーターが回っている」が静かに「鍵のかかった箱の中でメーターが回っている」になる。

上限は敵ではなく、サブスクが結んだ契約条項:月額上限と引き換えの使用量上限。壁の痛みは契約が期限を思い出させる音だ。覚えるべきは5つの出口ではなく、自分の形状。形状がはっきりすれば、どこで止まるかは一桁の掛け算になる。

よくある質問

Claude Code の上限はどのくらいでリセットされる?

5時間のローリングウィンドウは開始から5時間後にリセット、週次上限は週単位で回復。2つは独立で、ウィンドウが新しくなっても週次プールは戻らない。制限されたら /usage でどちらの時計か確かめて。

従量課金の API にも上限はある?

あるが別種:毎分リクエスト数とトークンスループット(RPM/ITPM/OTPM)、ティア別の月次支出上限で、5時間ウィンドウや週次プールではない。一人の開発者の量では事実上目に見えず、バーストと月次合計を計る。

429 が出た。壊れた?

いいえ——429 はサーバーが「クォータ消費済み・復帰時刻はレスポンスヘッダの通り」と報告しているだけ。時計を読んでから決める:待つ、圧縮する、それとも上の5つの出口からひとつ。

すべての記事