Claude Codeのレート制限（5時間の壁）に当たったら｜個人開発の実体験と対処法

Q: 制限に当たらないようにする一番簡単な方法は？

fallbackModelの設定・タスクの重さに応じたモデルの使い分け・/compactによるトークン節約を併用すると、同じ作業量でも枠の消費ペースを緩められます。

Claude Codeで大きめのリファクタを回していると、ある瞬間から返事が返ってこなくなる。レート制限だ。

Max 5x（月100ドル）で日常的にClaude Codeを酷使している身として、この「5時間の壁」には実際に何度も当たっている。追加料金を取られるわけではないが、作業が止まる感覚は最初は戸惑う。この記事では、レート制限とは何か、当たったときに何が起きるか、そして待つ以外にどう対処しているかを、実体験ベースでまとめる。

比較記事ではない。制限に当たった側の実際の挙動と対処法を書く。

結論：レート制限は追加課金ではない。5時間で自然にリセットされる「一時的な待ち」
いつ当たるか — 重いセッションを連発したとき
当たったときの対処 — 待つ以外にできること
そもそも枠に余裕を持たせる設定
Pro・Max 5x・Max 20xで枠はどう違うか
まとめ — 制限は「課金」ではなく「待ち」。運用でペースを整える
よくある質問

結論：レート制限は追加課金ではない。5時間で自然にリセットされる「一時的な待ち」

先に結論を書く。Claude CodeのMaxプラン（Pro/Maxいずれも共通の考え方）は、利用枠＋レート制限という方式で動いている。従量課金のように「使った分だけ追加で請求される」仕組みではなく、契約プランに応じた利用枠があり、その枠を一定時間内に使い切るとレート制限がかかる。

制限に当たると起きるのは次のことだけだ。

新規のリクエストがしばらく通りにくくなる（エラーや待機表示が出る）
追加の請求は発生しない
一定時間（5時間のローリングウィンドウ）が経過すると、枠が自然にリセットされて再び使えるようになる

つまり「制限＝ペナルティで課金される」のではなく「枠を使い切ったので、時間経過で回復するのを待つ」という挙動だ。この区別を誤解している人が多いので、まずここをはっきりさせておきたい。

いつ当たるか — 重いセッションを連発したとき

レート制限に当たりやすいのは、体感として次のような場面だ。

大規模なリファクタや、複数ファイルにまたがる調査を続けて走らせているとき
複数のサブエージェントを並列で動かし、それぞれが独立にトークンを消費しているとき
1つのセッションを/compactせずに長時間引っ張り、文脈が肥大化した状態で重いタスクを投げ続けているとき

自分の場合、当たりやすい場面ははっきりしている。朝一の大規模リファクタや、複数のサブエージェントを並列で多用しているとき——とくに自律実行でClaudeに任せきりにしているときによく当たる。手を動かして対話的に使っているときより、放っておいて自動で走らせているときのほうが、枠の消費が速い体感だ。

そして体感としてはっきりしているのは、当たるかどうかがモデルとeffort（思考の深さ）で大きく変わるという点だ。Opus 4.8だけをeffort最大で回し続けると、5時間ウィンドウを待たずに手前で枠に当たる。逆に下位モデルに落としたり思考のeffortを下げたりすると、5時間の制限にはそもそも当たらずに済むことが多い。「時間で回復を待つ」以前に、「何を・どのくらいの重さで回しているか」で、当たる頻度そのものが決まる。

当たったときの対処 — 待つ以外にできること

制限にかかったら、何もしなければ時間経過を待つしかない。ただし、待つ以外にも実際に行っている対処がいくつかある。

fallbackModelで安いモデルに逃がす — 主モデルが混雑・過負荷のときに自動で別モデルへ降格する設定。過負荷起因の中断や無駄なリトライを減らせる。設定方法はClaude Codeの料金を下げる実践3設定を参照。

タスクの重さで使うモデルを手前から絞る — 探索や下書きのような軽い作業はHaiku、標準的な実装はSonnet、設計判断や難しいデバッグだけOpus、という配分にしている。最上位モデルに固定して枠を早く消費するより、軽い作業を安いモデルに逃がすほうが枠の持ちが良い。

/compactでトークンを節約する — 会話が長くなるほど1回のリクエストが重くなる。定期的に/compactで要約し、不要なMCPツールの定義を毎ターンの文脈に載せないようにするだけでも、同じ作業量でも枠の消費ペースが変わる。

モデルの格を下げ、effort（思考の深さ）を落とす — 自分の場合これが一番効いた — Opus 4.8だけをeffort最大で回し続けると、枠を一気に消費して5時間を待たずに制限へ当たる。重い設計判断以外は一段下のモデルに任せ、思考のeffortを下げておくだけで、制限に当たる頻度がはっきり減った。当たってから待つより、日常の「重さ」を一段下げておくほうが効く。

（正直に）時間配分はあまり効かなかった — 「重い作業を5時間ウィンドウの頭に寄せる」という時間配分も試したが、当たる頻度そのものは体感ほとんど変わらなかった。自分に効いたのは時間帯の工夫ではなく、モデルとeffortを一段落とすことだった。

そもそも枠に余裕を持たせる設定

制限に当たってから対処するより、日頃から枠を圧迫しない使い方をしておくほうが効く。上記のfallbackModel・モデル使い分け・トークン節約は、実はコスト削減3設定の記事で先にまとめた設定と同じものだ。コストを下げる設定と、枠を圧迫しない設定は、根っこが同じということになる。

Pro・Max 5x・Max 20xで枠はどう違うか

契約プランによって利用枠の大きさは異なり、上位プランほど5時間ウィンドウ内で使える量が大きくなる設計になっている。ただし具体的な枠の量やモデル別の配分は改定が速く、ここで数字を断定すると公開時点でずれる可能性が高い。具体的な枠の量は公式でも明示されていない部分が多いため、ここでは数値を断定しない。

最新の枠や各プランの違いは、公式ドキュメントと合わせて料金プランのまとめ記事で確認してほしい。参考までに、Max 5x（月100ドル）でどれだけの作業量をこなせているかの実測は、Claude Codeの実際の料金で公開している。

【関連】5時間枠のレート制限は定額制ならではの律速だが、2026年6月にCopilot（従量課金化）・Cursor（2プール制）と他方式の料金構造も大きく動いた。方式ごとの違いは料金地殻変動の整理記事にまとめている。

まとめ — 制限は「課金」ではなく「待ち」。運用でペースを整える

Claude Codeのレート制限は、追加で請求される仕組みではなく、契約プランの利用枠を使い切ったときに新規リクエストが一時的に通りにくくなり、5時間のローリングウィンドウで自然にリセットされるという挙動だ。当たったら待つのが基本だが、当たる頻度自体は運用で下げられる。自分に一番効いたのはモデルとeffort（思考の深さ）を一段落とすことで、加えてfallbackModelの設定・タスクに応じたモデルの使い分け・/compactでのトークン節約が効く（一方、重い作業を時間帯で寄せる工夫は自分には効果が薄かった）。

制限そのものをゼロにする方法ではなく、当たる頻度と体感の待ち時間を減らすための工夫として書いた。