Claude Codeの利用上限 — 6つのメッセージの見分け方とプラン別の対処

Claude Codeの利用上限とは、契約プランに応じて一定期間内に使える処理量に設けられた天井です。ただしClaude Codeが表示する「上限」系のメッセージは1種類ではありません。セッション枠・週次枠・Opus専用枠というプラン消費の3種に加え、コンテキストの圧縮警告やサーバー側の一時的なスロットルまで、似た見た目で原因が違うメッセージが並びます。原因を取り違えると、効かない対処に時間を溶かします。モデルを切り替えても復帰しないケースと、それだけで復帰するケースが混在しているのが厄介な点です。

429やoverloadedといったエラーコード側の切り分けはClaude rate limitエラーの対処で扱っています。ここではClaude Codeが実際に出す上限メッセージを起点に原因を切り分け、利用形態(個人のPro/Max・Team/Enterprise・Console経由のAPI・クラウド経由)ごとに効く対処を示します。上限に当たったあとの見分け方と動き方をここで扱い、上限に当たりにくくするための日々の運用習慣はClaude Codeのトークン節約にまとめています。

Claude Codeの上限メッセージは6種類に分かれる

「上限」を名乗るメッセージのうち、実際にプランの消費枠が尽きているのは一部だけです。残りはコンテキストの警告や、プランと無関係な一時的スロットルです。見分けを誤ると、たとえば「サーバー側の一時的な制限」を自分の上限だと思い込んでプラン増強を検討する、といった無駄が生まれます。

上位3つ(セッション・週次・Opus)がいわゆる「プランの利用上限」で、/usageの画面や設定画面に反映されます。残り3つは名前は似ていても別の仕組みで、プランのクォータを消費していません。実際、サーバー側スロットルのメッセージには(not your usage limit)という注記がそのまま含まれています。

見落としやすいのが、セッション枠と週次枠が独立ではなく同時に減っていく点です。ワークフローの一斉ファンアウトのような重い処理をまとめて走らせると、セッション枠がリセットされる前に週次枠のほうを先に使い切ることがあります。この場合、5時間待ってもメッセージは消えません。待つべきは次の週次リセットの日時です。

利用形態によって上限の入れ物が変わる

同じ「上限」でも、契約の形によって誰が何を管理しているかが変わります。個人でPro/Maxに課金している場合と、会社のTeam/Enterpriseシートを使っている場合、Claude Console経由のAPIを使っている場合とでは、確認する画面も対処の主導権も違います。

Team/Enterpriseのシート割当は、Claudeチャット・Cowork・Claude Codeの3面が同じ枠を共有する点がポイントです。日中Claude Codeで重い処理を回すと、夕方にチャットで使うつもりだった枠が残っていない、という事態が起こり得ます。コントロールは管理者側にあり、開発者個人が設定を変える手段はありません。組織の支出上限を引き上げるか使用量クレジットを有効にするかは、管理者への相談が前提になります。

Console経由のAPI利用では「セッション枠」「週次枠」という概念自体がなく、トークン従量課金です。ただし無制限ではありません。組織単位でTPM(1分あたりトークン数)とRPM(1分あたりリクエスト数)のレート制限が設定され、Claude Codeのトラフィックもこの枠を消費します。この制限はユーザーごとではなく組織全体にかかるため、他のメンバーが使っていない時間帯は1人が計算上の持ち分より多く消費できる、という挙動になります。前払いクレジットを使い切るとCredit balance is too lowのエラーになり、これはサブスクリプションの利用上限とは完全に別会計です。

/usageと/usage-creditsで今すぐできること

上限に当たったら、まず/usageでどちらの枠が原因かを確認します。/costと/statsは同じコマンドの別名です。

/usage

Pro・Max・Team・Enterpriseのプランでは、/usageにプラン消費の内訳が表示されます。直近の使用量がスキル・サブエージェント・プラグイン・個別のMCPサーバーのどれに何%割り当てられているかを示す「Attribution」と、長いコンテキストやキャッシュミスのような挙動が直近使用量の10%以上を占めるときに表示される「Behavior flags」の2種類です。dキーで直近24時間、wキーで直近7日間の表示を切り替えられます。VS Code拡張でも同じ内訳が「Account & usage」ダイアログに表示されます(v2.1.174以降)。

使用量エンドポイント自体がレート制限されていて取得に失敗した場合は、直近60分以内にこのマシンで読み込んだ最後の使用量バーを「Showing last-known usage」の注記付きで表示します。rキーで再試行できます。

上限に達したその場で追加利用したいときは/usage-creditsを実行します。以前は/extra-usageという名前でした。

/usage-credits

挙動は役割によって変わります。

請求権限のないメンバーがリクエスト済みの状態で再度実行すると、重複送信はされず「既にリクエスト済み」と表示されます。管理者がリクエストを却下したあとに再実行すると、新しいリクエストが送られます。非対話モード(-pフラグ)やRemote Control経由では、このコマンドはリクエストを送らずインタラクティブセッションでの実行を促す表示に変わります。

Pro・Maxのプランでは、使用量クレジットを有効にした状態で支出上限(spend limit)に達すると、CLIを離れずにその場で上限を引き上げるか外すかを選べます。サーバーが変更を拒否した場合はCould not update your spend limitというエラーになり、サーバー側の理由が付く場合とダイアログを再試行すれば直る場合の2パターンがあります。

上限に当たる前に気づく — ステータスラインとDesktop

上限メッセージが出てから動くより、残量を見ながら重い作業のタイミングを選ぶほうが手戻りが少なくて済みます。Claude Codeのカスタムステータスラインには、Pro/Maxのサブスクリプションでセッション中に最初のAPI応答が返ったあと、rate_limitsというフィールドが渡されます。

"rate_limits": {
  "five_hour": {
    "used_percentage": 23.5,
    "resets_at": 1738425600
  },
  "seven_day": {
    "used_percentage": 41.2,
    "resets_at": 1738857600
  }
}

jq -r '.rate_limits.five_hour.used_percentage // empty'

このフィールドは初回のAPI応答が返るまでは存在しません。ステータスラインを自作していない場合は、Desktopアプリのモデルピッカー横にある使用量リング(usage ring)でも同じ情報を確認できます。CLIのステータスライン・VS Code拡張の「Account & usage」・Desktopの使用量リングは、それぞれ別の画面でありながら同じ消費データを違う見せ方で提供している、という位置づけです。

モデルを切り替えても消えない上限、消える上限

復帰するのはOpus枠のときだけです。/modelでモデルを切り替えても、セッション枠と週次枠は全モデル共通の消費のため直りません。Sonnetに切り替えてもHaikuに切り替えても同じで、当たっている枠がOpus専用のときだけ、他モデルへの切り替えで作業を続けられます。

もう1つ紛らわしいのが/clearの「リセット」です。/usageのSessionブロックに出るコスト集計は/clearで新しいセッションを始めるたびに$0へ戻ります。これはローカルで計算している表示上の集計で、ローリング5時間・週次のプラン消費とは別物です。プラン側の消費はサーバー側の記録に基づき、メッセージに表示されるリセット時刻(resets 3:45pmのような固定時刻)まで動きません。/clearを実行しても、既に消費した分のプラン利用枠が戻るわけではありません。以降のメッセージで無駄なコンテキストを送らずに済む、という将来の消費抑制効果はありますが、過去の消費を取り戻す機能ではありません。

コンテキストの圧縮警告も同じカテゴリーの誤解を招きます。これは会話がコンテキストウィンドウの圧縮しきい値に近づいたことを知らせるだけで、プランの利用上限とは無関係です。Claude Codeが自動で要約するため、放置しても実害はありません。発火条件と要約後に何が残るかの詳細はClaude Code compactの発火条件で扱っています。

上限に当たりにくくするうえで外しやすい2点

日々の運用で消費を抑える具体策(/clearを使うタイミング、モデルとeffortの決め方、サブエージェントへの委任、/compactの使い方、それぞれの相殺関係)はClaude Codeのトークン節約に手順としてまとめてあります。ここで付け加えたい注意点は次の2つです。

• ワークフローの一斉ファンアウトは週次枠を先に溶かす。セッション枠と週次枠は同時に減るため、大量の並列タスクを一度に走らせると、5時間の回復を待たずに週次リセットまで動けなくなることがあります。大きなファンアウトを組む前に/usageで週次側の残量を確認しておくと安全です。
• 上限に当たった直後の/compactは効果が薄い。/compactはそれ自体が会話全体を読み直す大きなリクエストです。プラン側の上限は時間経過でしか解消しないため、上限を回避する目的で/compactを挟んでも消費が増えるだけで復帰にはつながりません。話題を変えるときの/clearは無料ですが、上限そのものへの対処にはなりません。

よくある質問

Team / Enterpriseで上限に当たったとき、開発者自身にできることはありますか

シート割当や支出上限を変更する権限は開発者本人にはなく、管理コンソールはclaude.aiの管理者側にあります。請求権限を持たないメンバーは/usage-creditsを実行すると、確認ダイアログのあとに管理者へリクエストが送られる仕組みです。同じリクエストが処理待ちの間に再実行しても、重複しては送られません。

1Mコンテキストのモデルを使うと、また別の上限に当たりますか

[1m]付きのモデルを明示的に選んでいて、プランが1Mコンテキストを使用量クレジット経由でしか含んでいない場合、Usage credits required for 1M contextというエラーになります。これはセッション枠・週次枠のような消費枠の枯渇ではなく、その機能を使う権利があるかどうかのチェックです。/modelで[1m]なしの通常コンテキスト版に切り替えるか、/usage-creditsで有効化すれば解消します。

Request rejected (429)が出たとき、具体的に何を確認すればいいですか

/statusで現在使われている認証情報を確認します。環境変数に紛れ込んだANTHROPIC_API_KEYが、意図せず低ティアのキー経由でリクエストを飛ばしていることがあります。プロバイダのコンソールで有効なレート制限を確認し、スクリプトによる高頻度実行が原因ならCLAUDE_CODE_MAX_TOOL_USE_CONCURRENCYで同時実行数を下げるか、軽いモデルに切り替えます。429と、混同しやすいoverloaded(529)の切り分けはClaude rate limitエラーの対処で詳しく扱っています。

Server is temporarily limiting requestsは自分の使いすぎが原因ですか

いいえ。このメッセージにはプランの利用上限とは無関係であることを示す(not your usage limit)という注記がそのまま含まれています。APIの短時間スロットルなので、少し待って再試行すれば解消することがほとんどです。

セッションを終了すれば上限は早く回復しますか

回復しません。セッション枠・週次枠はメッセージに表示される固定のリセット時刻(resets 3:45pmのような時刻)で戻る仕組みで、Claude Codeの終了や/clearといったローカルの操作とは連動していません。

まとめ

Claude Codeの「上限」は一枚岩ではありません。セッション枠・週次枠・Opus専用枠というプラン消費の3種と、コンテキスト警告・サーバー側スロットル・認証経路のレート制限という上限とは別物の3種が、似た見た目のメッセージで混在します。まず/usageでどの枠に当たっているかを確認し、Opus限定なら/modelで切り替え、セッション・週次なら待つか/usage-credits、Team/Enterpriseなら管理者への相談、という順に動くのが遠回りを避ける道筋です。日々の消費を抑える具体策はClaude Codeのトークン節約、プラン全体のコスト試算はClaude Codeの料金を参照してください。