Claude Codeの利用制限を徹底解説：仕組みと上限回避のコツ

Claude Codeの利用制限とは？

Claude Codeの利用は、次の2つの仕組みで管理されています。

• 5時間のローリングセッションウィンドウ
• 1つ以上の週次利用上限

いずれかに達すると、レート制限に引っかかります。

5時間のローリングウィンドウ

最も目に見える制限は「5時間のローリングウィンドウ」です。最初のプロンプトを送った時点でウィンドウが開始され、次の5時間に行う操作はすべて同じ利用プールから差し引かれます。このプールはClaude CodeとClaudeチャットで共有されており、一方の活動が他方に影響します。

例：

• 最初のプロンプト：午前9時
• ウィンドウ終了：午後2時

もし午前10時30分までに利用可能分を使い切った場合、午後2時にウィンドウがリセットされるまでアクセスは一時停止されます。

よくある誤解は、新しい会話を始めれば利用がリセットされるというものです。そうではありません。 /clearコマンドは会話コンテキストを新しくするだけで、利用許容量を回復したり5時間タイマーをリセットしたりはしません。

週次の上限

時間ベースのセッション制限に加えて、Claude Codeには週次の上限もあります。現在のセッションに余裕があっても、週次上限に達すると、週次リセットが行われるまで一時的に利用ができなくなる場合があります。

5時間の上限は「利用のタイミング」を制限し、週次上限は「利用の総量」を制限する、と考えると分かりやすいでしょう。

つまり、現在の5時間セッションに残りがあっても、週次の許容量を使い切っている場合はブロックされることがあります。多くのProユーザーにとっては、この区別は比較的単純ですが、Maxプランではもう一段複雑になります。

Maxユーザー向けのSonnet週次上限

Anthropicは現在、Maxプランに対し次の制限を適用しています。

• すべてのモデルを対象とした週次上限
• Sonnet利用に特化した別個の週次上限

この区別が重要なのは、全体のモデル枠を使い切ってもSonnetにはまだ余裕がある、あるいはその逆、といった状況が起こりうるためです。

たとえば、週の大半を実装作業でSonnetに費やした場合、全体の週次許容量には余りがあっても、Sonnet専用の週次許容量を使い切ってしまう可能性があります。その時点では、残りの制限に応じて、別のモデルに切り替える、Sonnetのリセットを待つ、またはプランをアップグレードするといった対応が必要になります。

逆の状況も起こりえます。週の間にOpusを多用した結果、Sonnet専用の枠が残っていても全体の週次上限に達してしまう場合があります。全体の上限は「傘」のような制限であり、これに達すると、Sonnetの残容量に関係なくそれ以上の利用はできません。

Sonnetでのリクエストが成功するには、次の両方を満たす必要があります。

• 全体の週次上限に余裕があること
• Sonnetの週次上限に余裕があること

一方、OpusのリクエストはOpus専用の許容量がないため、全体の週次プールのみを消費します。だからこそClaude.aiのUsageページが重要です。各週次上限とそのリセット時間が個別に表示されるため、長時間のコーディングセッションの前にどの上限に近づいているかを把握しやすくなります。

プラン別のClaude Code利用枠

プラン比較で難しいのは、Anthropicがもはや単純な「プロンプト回数」を公開していない点です。

代わりに、各プランは「相対的なキャパシティの倍率」で表現されます。これはProプランを基準とした利用可能キャパシティの倍率を示すもので、正確な数値を得るのは容易ではありません。一部のユーザーは、利用率をパーセンテージで追跡し、どの程度のトークンを消費したかをおおまかに把握しています。

2026年5月の利用制限の変更

Anthropicは2026年5月に、サブスクリプションの利用上限を倍増し、ProとMaxの加入者に影響していたピーク時間帯の縮小措置を撤廃して、Claude Codeのキャパシティを拡大しました。固定のプロンプト回数を公表するのではなく、実際の利用量がモデル選択、コンテキストサイズ、ツール利用に左右されるため、プラン差は相対キャパシティの倍率で示されるようになりました。

以降、Anthropicは一時的なプロモーションによって週次上限を調整することがあります。例えば、Claude Fable 5の展開中には、対象の加入者に対してClaude Codeの週次上限が50%引き上げられました。これらのプロモーションは一時的なものなので、長時間の作業を計画する前に、必ずClaudeのUsageダッシュボードで最新の上限を確認してください。

Agent SDKクレジット（2026年6月）

インタラクティブなコーディングセッションと自動エージェントのワークロードを分離する計画は、2026年6月に混乱を招きました。

6月15日以前は、すべてのClaude Codeのアクティビティが同じサブスクリプションプールから消費されていました。ターミナルでの対話、GitHub Actionの実行、CIパイプライン内でのclaude -pの呼び出しなど、すべてが同じ5時間および週次の上限を争っていました。

Anthropicは2026年6月15日にこれらのワークロードの分離を開始する予定でしたが、当日に変更を一時停止しました。つまり、インタラクティブ利用とプログラムからの利用（Agent SDK、claude -p、GitHub Actions）は、引き続き同じサブスクリプションプールから消費されます。

2026年7月時点で、別個のAgent SDKクレジットは存在せず、申請して付与されるオプトインのクレジットもありません。

実際にクォータを消費しているのは何か？

多くの開発者はプロンプト数やトークン調整に注目しますが、真の犯人はしばしばコンテキストです。各やり取りには、入力した質問以上に多くの情報が含まれています。

CLAUDE.mdとルールファイル

Claude Codeは次の場所から自動的に指示を読み込みます。

• CLAUDE.md

• 親ディレクトリのCLAUDE.mdファイル

• インポートされた@参照

• .claude/rules/*.mdファイル

これらのコンテキストと追加の指示はリクエストのたびに繰り返し含まれます。つまり、肥大化したルールファイルは、セッション全体を通して密かにトークン消費を増やします。Anthropicは、個々のCLAUDE.mdファイルを概ね200行以内に保つことを推奨しています。

大規模プロジェクトでは、パスのフロントマターを使ったスコープ付きルールに分割し、必要なときだけ読み込まれるように検討してください。詳しくは、最適なCLAUDE.mdの書き方ガイドで効果的な整理戦略を解説しています。

MCPツール定義

Model Context Protocol（MCP）サーバーも、隠れたオーバーヘッドの原因です。接続されている各MCPサーバーは、たとえツールを一度も使わなくても、ツールのスキーマをClaudeのコンテキストに挿入します。

例えば：

• MCPサーバーが5つ
• 各サーバーにツールが10個

この場合、リクエストごとに50のツール定義が含まれます。未使用のMCPサーバーを切断するのは、Claude Codeのトークン消費を減らす最も簡単な方法の1つです。

重要な注意：アクティブなセッション中にMCPサーバーを追加・削除するのは避けてください。プロンプトキャッシュのプレフィックスが無効になり、利用コストが増える可能性があります。

自動メモリ

Claude Code v2.1.59以降、自動メモリはデフォルトで有効です。メモリは、複数のセッションでClaudeが保存したグローバルな知識で、より多くのコンテキストを提供します。これは、データベースからのデータ取得方法から、実装した技術的詳細まで幅広く含まれ得ます。

起動時に、ClaudeはMEMORY.mdから次の上限まで読み込みます。

• 先頭から200行まで
• 先頭から25 KBまで

ワークフローによっては有用ですが、単なる余計なコンテキストになる場合もあります。

自動メモリは、いくつかの方法で無効化できます。すべての設定より優先される恒久的なキルスイッチ（CIパイプラインや自動化環境に有用）として、シェルで環境変数を設定してください。

export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

または、次をsettings.jsonに追加します。すべてのプロジェクトで無効にするには~/.claude/settings.json、特定プロジェクトのみでは.claude/settings.jsonに記述します。

{ "autoMemoryEnabled": false }

メモリファイルを積極的に使っていない場合は、この機能を無効にするとベースラインのコンテキストサイズを削減できます。

会話履歴と検索

会話履歴は継続的に増加します。ツールの結果、ファイルの読み取り、grepの出力、ターミナルコマンド、コード検索など、すべてがセッションコンテキストの一部になります。

私の経験では、リポジトリ探索が最大の要因であることが多いです。Claudeは1つの関数を見つけるために数十のファイルを読むことがあり、これらのファイルはコンテキストに留まり、以後のターンでもトークンのオーバーヘッドを生み続けます。

自動化ワークフローでは、claude -p --bareを使うと、不要なセッションコンテキストを取り除いて固定オーバーヘッドの多くを削減できます。これにより、Claudeがファイル検索に費やしてしまうはずだった月次のAgent SDKクレジットを大幅に節約できます。

Claude Codeの利用状況を確認する方法

長時間のコーディングセッションを始める前に確認するのが最適です。事前にどの程度上限に近いか把握しておくことで、実際の作業に入る前から計画が立てやすくなります。

/usageの利用

Claude Code内で/usageと入力すると、次が表示されます。

• セッション消費量
• 週次の消費量
• 残りの割当

インタラクティブセッションで残っているクォータの概要を把握でき、先を見据えた計画に役立ちます。上限に達する直前に複雑な大仕事を始めるのは賢明ではありませんが、ファイル整理のような軽作業は残りのクォータの良い使い道になるかもしれません。

/statusの利用

また、/statusを実行すると、次の情報が得られます。

• 現在のプラン
• アカウント情報
• アクティブな利用状態

プランとアクティブ状態を把握することで、潜在的な制限を理解できます。利用がベースラインの5倍なのか20倍なのかは重要です。

Claudeダッシュボードの確認

最も包括的なビューは、Settings → Usage（内のClaude.ai）です。

このダッシュボードには次が統合されています。

• Claudeチャットの利用状況
• Claude Codeの利用状況
• 週次リセットのスケジュール
• モデル別の上限

複数の上限が同時に存在するため、このダッシュボードを唯一の正確な情報源とみなすべきです。大規模なリファクタリング、長時間のデバッグ、または自律的なコーディングタスクを始める前に、利用状況を確認する習慣をつけると実用的です。

Claude Codeの制限内で最大限に活用する方法

プランをアップグレードせずに利用上限を延ばす方法を考えましょう。オーバーヘッドを減らすだけで、はるかに効率的にキャパシティを使える場合があります。

CLAUDE.mdを削ぎ落とす

1ファイルあたり200行未満を目安に、送信するコンテキスト量とエージェントの混乱を最小化しましょう。次のような項目を見直してください。

• 古くなったプロジェクトの指示
• 履歴的なメモ
• 個別のプロンプトに含めるべきルール

指示が特定のディレクトリにのみ関係する場合は、pathsフロントマターを用いたスコープ付きルールを使い、常時ではなく必要なパスでのみルールが効くようにしましょう。グローバルではなくプロジェクト単位のCLAUDE.mdを用意するのも有効です。

MCPサーバーの棚卸し

実際に使っているMCPサーバーだけを残しましょう。接続されているサーバーは、やり取りのたびにスキーマのオーバーヘッドを追加します。ブラウザのタブのように管理し、今使っていないものは閉じてください。

良い方法として、特定のプロジェクトでのみ必要なMCPがある場合は、ユーザーレベルではなくプロジェクトレベルでインストールする運用があります。こうすることで、あらゆるプロジェクトやセッションで読み込まれず、特定の用途があるときだけ読み込まれます。

早めに/compactを使う

/compactコマンドは会話履歴を要約し、以降のトークンコストを削減します。ターンごとに処理されるコンテキストの増加量を抑えることで、クォータ消費を減らせます。

既に消費したクォータは戻りませんが、セッションが過度に大きくなる前に/compactを使うと有効です。

タスクにモデルを合わせる

すべてのタスクにOpusやFableが必要なわけではありません。小さなモデルや工夫した使い分けで、クォータ管理を改善できることがあります。高付加価値の作業にプレミアムモデルを温存するだけで、利用可能なキャパシティを大きく増やせる場合があります。

モデル最適化の一例：

• アーキテクチャの決定、複雑な推論、曖昧な要件にはOpus
• 編集、検索、実装作業にはSonnet
• 軽量タスクや手早い読み取りにはHaiku

ただし、セッション中にモデルを何度も切り替えるのは避けてください。プロンプトキャッシュはモデルごとに異なるため、切り替えるたびに新しいモデルは会話履歴全体をキャッシュなしのフルコストで再処理する必要があり、「安い」モデルへ切り替えたつもりでも、据え置いた方がクォータを節約できる場合があります。

上限に達したとき：APIへの切り替え

サブスクリプションのクォータがボトルネックになる場合は、Claude APIが代替手段になります。API利用では5時間のセッションウィンドウや週次のサブスクリプション上限に縛られず、トークン消費に応じて支払います。

このモデルが適しているケース：

• CIパイプライン
• 長時間稼働の自律エージェント
• 大規模な自動化
• 予算が予測可能な本番ワークフロー

注意点として、Claude CodeのシェルにANTHROPIC_API_KEYの環境変数を設定したままにしないようにしてください。このキーが環境に存在すると、サブスクリプションアカウントではなくAPI経由で認証されることがあります。

その場合、サブスクリプションの制限ではなくトークン課金となるため、想定外のAPI料金が発生する恐れがあります。費用が不自然に見える場合は、まず認証設定を確認することをおすすめします。

最新のモデル料金については、必ずAnthropicの公式料金ドキュメントを参照してください。料金は頻繁に変更され、モデルによって異なります。

まとめ

Claude Codeの利用制限は、単にプロンプトの数を数えているわけではないと理解すれば、ずっと管理しやすくなります。

この仕組みは次の要素を組み合わせています。

• 5時間のローリングウィンドウ
• 週次上限
• モデル別の許容量
• コンテキストのオーバーヘッド

多くの開発者にとって意外なのは、総トークン使用量の中でプロンプトが占める割合は少ないことが多い、という点です。大きなCLAUDE.md、MCPツール定義、自動メモリ、リポジトリ検索、増え続ける会話履歴などが、質問そのもの以上にキャパシティを消費しがちです。

実際、異常に早く上限に達してしまう人の多くは、キャパシティの問題ではなく構成の問題を抱えています。プランを上げる前に、より大きなクォータを購入するのではなく、コンテキストの整理でオーバーヘッドを減らすことを検討してください。

ワークフローの改善を続けるには、Claude Codeベストプラクティスのガイドと、Claude Code Hooksのチュートリアルもおすすめです。長時間の開発でも、より効率的で堅牢にする手法を解説しています。