Claude Code 制限にすぐ引っかかる原因、公式ドキュメントで全部読み解いた

Claude Code 制限にすぐ引っかかる原因、公式ドキュメントで全部読み解いた

Claude Codeの使用制限は5時間のローリングウィンドウと週次上限の二重構造。なぜすぐ制限に達するのか、フリーランスが実務で困る4パターンと対処法を公式ドキュメントベースで整理した。

エンジニアのゆとです。

Claude Codeで作業してる途中に「使用量の上限に達しました」と出て、手が止まった経験がある人は多いと思う。僕もある。納品前日の夜、あと少しでリファクタが終わるってタイミングで急に止まって、地味に焦った。

この制限、実は「5時間ごとにリセットされるセッション枠」と「週単位の上限」という2つの別物が重なって動いてる。しかもモデルを切り替えても解除されない。この仕組みを知らずに使ってると、なんで今止まったのか分からないまま「Claude Codeは制限が厳しい」という雑な印象だけが残る。

公式ドキュメント(サポートセンターとClaude Codeのdocs両方)を読み込んで、制限の正体と、フリーランスエンジニアが実務でどう向き合えばいいかを整理した。

「使用量制限」と「長さ制限」は別物

まずここを混同してる人が結構いる。Anthropicのヘルプセンターには、この2つがはっきり別概念として書いてある。

使用量制限は「会話予算」だ。特定の期間にどれくらいClaudeとやり取りできるかを制御するもので、メッセージ数やClaude Codeが動ける時間を決めてる。影響する要因は会話の長さ・複雑さ、使う機能、モデルの種類、努力レベル(/effortで設定するやつ)。

長さ制限はコンテキストウィンドウの話。1回のチャットで処理できる情報量の上限で、公式は「Claudeの作業メモリ」と表現してる。有料プランだと最新モデルは最大1Mトークン、それ以外は500Kか200K。

つまり「使用量制限」は時間軸、「長さ制限」は1セッションの深さ軸。前者に引っかかると「You’ve hit your session limit」や「You’ve hit your weekly limit」というメッセージが出て、後者に近づくとコンテキストの自動要約(auto-compact)が入る。挙動が全然違うのに、どっちも「制限」という同じ言葉でくくられるから混乱する。

Claude Code 1Mコンテキストの賢い使い方——トークン枯渇を防ぐ3層管理戦術
Claude Code 1Mコンテキストの賢い使い方——トークン枯渇を防ぐ3層管理戦術Sonnet 4.6/Opus 4.7で標準化した1Mコンテキストの落とし穴と管理戦術を実測データで解説。全部入れれば賢くなると思ったら逆だった話、3層管理の設計、/compactの最適タイミング、Python計測スクリプトまで。読む →

セッション上限と週次上限、2つの窓がある

Claude for Teams/Enterpriseの公式ドキュメントに、この構造がはっきり書いてある。各ユーザーの利用枠は「5時間のローリングウィンドウ」と「週単位のウィンドウ」の両方でリセットされる。Pro/Maxの個人プランも基本的に同じ考え方で動いてる。

ここでよく誤解されるのが「モデルを切り替えれば制限が解除される」という発想だ。実際は逆で、このウィンドウは全モデル共通で消費される。/modelでSonnetからHaikuに切り替えても、セッション上限自体はリセットされない。ただし例外があって、「Opus限定の上限(You’ve hit your Opus limit)」に達した場合は、Opus以外のモデルに切り替えれば作業は続けられる。つまり「全体の上限」と「Opus専用の上限」は別枠として存在してる。

週次上限に達した場合、メッセージにリセット時刻が表示される。ここで即座に確認したいときは/usageコマンドを叩くのが一番早い。Pro/Max/Team/Enterpriseなら、直近24時間・直近7日間をキー操作(d/w)で切り替えながら見れるし、使用量の内訳がskills・subagents・plugins・個別のMCPサーバー単位でパーセンテージ表示される。長いコンテキストやキャッシュミスが使用量の10%以上を占めている場合はその旨も警告してくれる。

なぜ「思ったより早く」制限に達するのか

公式ドキュメントが「長いセッションで使用量が跳ね上がる理由」として挙げてるのは主に5つ。フリーランスエンジニアの実務でよく起きる順に並べ直すとこうなる。

長時間セッションでの文脈の肥大化

Claude Codeは会話全体を毎回のリクエストに乗せて送る。ツールを使うたびにその結果もまとめて送信されるから、1日開きっぱなしのセッションだと、1行だけの質問でも会話全体分の使用量が消費される。

キャッシュミス

プロンプトキャッシュの有効期限は、サブスクなら1時間、追加使用量(usage credits)を使い始めた後は5分に短縮される。APIキーやクラウドプロバイダー経由だと既定5分。この時間を超えて久しぶりにメッセージを送ると、キャッシュが切れて全文脈を再処理することになり、消費が跳ねる。休憩から戻って最初の1通が妙に重いのはこれが原因。

サブエージェント・エージェントチームの過剰消費

各サブエージェントは独立したコンテキストウィンドウを持つ。エージェントチームに至っては、チームメイトがplanモードで動く場合、通常セッションの約7倍のトークンを使うと公式に明記されてる。「複数のサブエージェントに並列で投げれば速い」は事実だけど、その分だけ使用量も食う。

Claude Codeのサブエージェント、禁止→解禁を1週間で繰り返した理由
Claude Codeのサブエージェント、禁止→解禁を1週間で繰り返した理由Claude Codeはサブエージェントの同時実行を20体に制限した4日後、ネストの入れ子生成を既定で禁止し、さらに3日後には深さ3まで既定で解禁した。7月17日〜24日の3リリースを時系列で追い、暴走コストの正体とCLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS等の実務での調整方法を解説する。読む →

スケジュールタスクの放置

/schedule的な定期実行タスクを仕込んでおくと、セッションがアイドル状態でも設定した間隔で発火し、そのたびに全文脈を送信する。使ってないと思ってたタスクが裏で使用量を削ってるケースは意外とある。

コンパクトそのものが重い処理

/compactは要約対象の会話全体を読み込むので、大きなコンテキストを圧縮する行為自体が大きめのリクエストになる。「制限が近いから節約のためにcompactしよう」で余計に消費するという、地味に本末転倒な事態が起こりうる。

フリーランスが実務でハマる場面

会社員と違って、フリーランスは複数クライアントの案件を並行で抱えることが多い。この働き方が制限との相性を余計に悪くする。

1つ目は「案件を掛け持ちしてセッションを切り替えずに使い回す」パターン。A社の実装作業のままB社のコードレビューを頼むと、A社の分の文脈が残ったままB社の作業をすることになり、無関係な文脈込みで使用量が削られる。案件が変わったら/clearを挟む、これだけでかなり違う。

2つ目は「納期直前にサブエージェント並列投入」パターン。時間がないから複数のサブエージェントに一気に振って並列処理させると、消費速度も比例して上がる。急いでる時ほど制限に近づくのは、ある意味で当然の帰結だ。

3つ目は「休憩を挟むたびにキャッシュミスが起きてることに気づいてない」パターン。カフェで作業して、移動して、また作業を再開する、みたいな細切れの働き方をしてると、再開のたびに1時間(またはusage credits適用後は5分)を超えてキャッシュが切れて、地味に消費が積み上がる。

4つ目は「Opusをデフォルトにしたまま忘れてる」パターン。複雑な設計判断の時だけOpusを使うつもりが、/modelで戻し忘れて単純なタスクもOpusで処理し続けると、コストも使用量も余計にかかる。

Claude Opus 5でClaude Codeの何が変わる?価格と機能を検証
Claude Opus 5でClaude Codeの何が変わる?価格と機能を検証2026年7月24日リリースのClaude Opus 5をClaude Code視点で検証した。1Mコンテキスト、fast modeの価格、会話途中のツール入れ替えベータ機能、セーフティ自動フォールバック、週間利用上限50%増キャンペーンの延長、Sonnet 5との実務での使い分けまで一気に整理する記事。読む →

制限に達した時、実際どうするか

制限に達すると、選べる選択肢は大きく3つある。それぞれフリーランスの財布目線で整理する。

待つ

セッション上限なら5時間、週次上限なら週単位でリセットされる。急ぎでなければこれが一番コストがかからない。ただしクライアント対応中に「5時間待ってください」は現実的じゃない場面もある。

usage credits(追加使用量)を使う

Pro/Max/Team/Enterpriseなら/usage-creditsコマンドで有効化できる。ただしこのコマンドはclaude.aiのサブスクでログインしてる場合のみ動く。API keyで認証してると使えない。有効化すると支出上限を設定した上で、上限超過後も従量課金で作業を続けられる。「今どうしても終わらせたい1タスクのためだけに使う」くらいの温度感で使うのが財布に優しい。

プランをアップグレードする

恒常的に制限に引っかかるなら、Pro→Maxのように上位プランに乗り換えるのが根本解決になる。ただし月額が数倍に跳ねるので、実際にどれくらいの頻度で制限にぶつかってるかを/usageで数字を見てから判断した方がいい。感覚じゃなくて実測で決める。

制限を体感で減らす、僕が実際にやってること

ここからは公式の推奨と、自分の運用で効いてる実感を混ぜて書く。

一番効くのはタスクの切れ目で/clearすることだった。「なんとなく同じセッションで続ける」をやめて、無関係な作業に移る瞬間に必ず切る。/renameで分かりやすい名前をつけてから/clearすれば、あとで/resumeで戻れるので実質デメリットがない。

モデルの使い分けも地味に効く。実装の大半はSonnetで十分で、Opusは設計方針で迷った時の壁打ちだけに絞る。サブエージェントに単純作業を投げるときはmodel: haikuを明示的に指定すると、そこだけ軽いモデルで処理されて全体の消費が抑えられる。

CLAUDE.mdを太らせすぎないのも重要だ。CLAUDE.mdはセッション開始時に毎回読み込まれるから、特定ワークフロー専用の細かい指示をここに書き続けると、無関係な作業をしてる時もそのトークンを払い続けることになる。用途別の指示はSkillsに切り出して、CLAUDE.mdは200行以内に収めるのが公式の目安。

あとはPreToolUseフックでBashの出力を絞る運用も入れてる。テストの出力を全部読ませるんじゃなくて、失敗行だけgrepして渡すフックを噛ませると、1万行のログが数百行に減って、その分そのままトークン消費も減る。

FAQ

週次制限とセッション制限、どっちが先に来る?

使い方次第だけど、1日中作業してる日はセッション制限(5時間ごと)に先にぶつかることが多い。逆に毎日コンスタントに使い続けてると週次の方が先に効いてくる。/usageで両方の残量を見比べるのが確実。

Team/Enterpriseなら制限は緩くなる?

シート単位の利用枠になり、Standard/Premiumのシート階層によって枠の大きさが変わる。個人のPro/Maxより融通は利くけど、無制限ではない。組織のadminがusage creditsをオンにして支出上限を設定する運用になる。

Claude Code on the Webも同じ制限を消費する?

Claude for Teams/Enterpriseでは、シートの利用枠はClaude chat・Cowork・Claude Codeで共有される。個人のPro/Maxプランでも基本的に同じ考え方で、Claude Code以外の使用も同じ枠を削る。

制限の仕組みそのものは変えられないけど、「なぜ今止まったか」が分かるだけで対応の速度は全然違う。次に制限に引っかかったら、まず/usageを叩いて、セッションなのか週次なのか、何が使用量の大半を占めてるのかを確認するところから始めるといい。

code.claude.com
← 記事一覧に戻る