Claude Codeの使用枠を節約する：モデル選択、コンテキスト、キャッシュ、/compact

最近、Claude Code や Claude Max を使っていて同じ問題に当たる人が増えています。Pro、Max 5x、Max 20x を契約しているのに、少し使っただけで使用量の警告が出る、あるいは次のリセットを待つ必要がある、というものです。特に大きなプロジェクトで Claude Code に大量のファイルを読ませたり、複雑な bug を修正させたり、長いタスクを走らせたりすると、この感覚はかなり強くなります。

先に結論を書くと、使用枠は「時間」で線形に減るわけではありません。モデル、コンテキスト長、添付ファイル、コードベースの大きさ、会話履歴、ツール呼び出し、現在の容量によって変わります。同じ5時間ウィンドウでも、長く使える人もいれば、十数分で上限に近づく人もいます。多くの場合、アカウントがおかしいのではなく、1回ごとのリクエストが重すぎます。

この記事では、使用枠を節約するための実用的な習慣を整理します。

01 まず Claude の使用ウィンドウを理解する

Claude Pro と Max には使用制限があります。Claude Code の使用量は、Claude のWeb、デスクトップ、モバイルアプリと同じサブスクリプション枠を共有します。公式ヘルプでは、送信できるメッセージ数はメッセージの長さ、添付ファイルの大きさ、現在の会話の長さ、使うモデルや機能に左右されると説明されています。Claude Code ではさらに、プロジェクトの複雑さ、コードベースの大きさ、自動承認設定なども影響します。

大まかにはこう考えるとよいです。

Pro：軽い利用と小さなプロジェクト向け。
Max 5x：より頻繁な利用と大きめのコードベース向け。
Max 20x：重めの日常利用や高頻度の共同作業向け。
使用ウィンドウは5時間セッション単位でリセットされる。
長いメッセージ、長い会話、大きなファイル、複雑なタスクは使用量を早く消費する。
Opus のような強いモデルは Sonnet より早く制限に近づきやすい。

そのため、「20分しか使っていない」という説明だけでは状況は分かりません。重要なのは、その20分で Claude がどれだけのコンテキストを読んだか、どのモデルを使ったか、大きなファイルを何度も処理したか、同じ長い会話にタスクを追加し続けたかです。

02 まずやること：最も高いモデルをデフォルトにしない

Claude 系列は、おおよそ次のように使い分けられます。

Opus：最も強力。複雑な推論、設計判断、難しい bug に向く。
Sonnet：能力とコストのバランスがよく、日常的なコーディング作業に向く。
Haiku：軽量。簡単な分類、要約、形式変換などに向く。

日常的なスクリプト作成、小さな bug 修正、ドキュメント整理、コード説明なら、多くの場合 Sonnet で十分です。Opus は次のような場面に残しておくほうがよいです。

複雑なアーキテクチャ設計。
複数ファイルにまたがる深いリファクタリング。
再現しにくい bug。
長い推論が必要なトラブルシュート。
通常モデルが明らかに詰まったタスク。

Claude Code では /model でモデルを切り替えられますし、/config でデフォルトも設定できます。安定した使い方は、普段は Sonnet、重要な局面だけ Opus に切り替えることです。最初から最後まで Opus で押し切る必要はありません。

03 次にやること：コンテキストを制御し、古いタスクを引きずらない

コンテキストが長くなるほど、Claude が毎回処理する内容が増え、使用量も増えます。Claude Code の公式ドキュメントでも、コンテキストを能動的に管理することが推奨されています。

無関係なタスクに切り替えるときは /clear で履歴を消す。
現在のタスクが一段落したが重要な文脈は残したいときは /compact で圧縮する。
何がコンテキストを使っているか知りたいときは /context を使う。
状態を常に見たい場合は status line を設定する。

使いやすいリズムは次の通りです。

1
2
3
4


小さな段階が終わった：/compact
大きなタスクが終わった：/clear
無関係な作業に切り替える：/clear
コンテキスト使用量が高くなってきた：早めに /compact

/compact は前の会話を要約し、重要なタスク状態、結論、ファイルパス、TODO を残しつつ、後続リクエストに持ち込む履歴を減らします。後ろに重点を書いてもよいです。

1

/compact 変更済みファイル、テスト結果、残りTODO、重要な設計判断を残す

自動圧縮を待つ必要はありません。公式ドキュメントでは、Claude Code はコンテキストが上限に近づくと自動圧縮すると説明されていますが、段階の区切りで手動圧縮するほうが制御しやすいです。

04 三つ目：長い会話と大きなファイルは毎回のリクエストを重くする

「もう一言聞いただけだから安いはず」と思いがちです。しかし長い会話では、その一言の背後に大量の履歴、ファイル要約、ツール定義、システムルールが付いてくることがあります。

特にコンテキストを増やしやすいものは次の通りです。

ずっと消していない長い会話。
Claude に大きなファイル全体を読ませること。
長いログ、ビルド出力、テスト出力を貼ること。
スクリーンショットや画像を一度に大量に入れること。
リポジトリ全体を何度もスキャンさせること。
長すぎる CLAUDE.md。
多すぎる MCP server。

節約するなら、ログは重要なエラーだけ、テスト出力は失敗部分だけにします。大きなファイルは、まず rg、head、tail、シンボル検索で位置を絞り、必要な部分だけ読ませます。コマンドラインで絞れる内容を、丸ごとコンテキストに入れないほうがよいです。

05 四つ目：キャッシュを理解する。ただし過信しない

Anthropic の Prompt Caching は、繰り返される prompt の前方部分をキャッシュします。デフォルトのキャッシュ寿命は5分で、1時間キャッシュもサポートされています。キャッシュがヒットすると、繰り返し使う大きなコンテキストを毎回完全に再処理せずに済むため、コスト削減や使用枠の効率改善につながります。

ただしキャッシュには制限があります。

テキストや画像を含め、内容が完全一致する必要がある。
デフォルトのキャッシュは短命。
モデル、ツール、システムプロンプト、コンテキスト構造を変えるとヒット率が下がることがある。
出力 token はキャッシュで消えるわけではなく、回答生成分は必要。
Claude Code が具体的にどうキャッシュを使うかは製品実装の詳細なので、永続的な「無料メモリ」と考えないほうがよい。

実際の利用で大事なのは、キャッシュの細部を研究することではなく、セッションを安定させることです。

同じ段階ではモデルを頻繁に切り替えない。
作業中に大量のルールを何度も書き換えない。
同じタスクの途中で新しい画像を次々追加しない。
長いタスクを長時間放置したあと、いきなり大きなリクエストを投げない。
段階が終わったら /compact する。

こうすると、繰り返しのコンテキストを再利用しやすくなり、後続リクエストも軽くなります。

06 ピーク時間について：避けられるなら避ける。ただし固定公式にしない

ネット上では、特定の時間帯は使用枠が厳しいという話をよく見かけます。公式ヘルプの表現はもっと慎重で、送信可能数は Claude の現在の容量、会話の長さ、添付ファイル、モデル、機能に影響されるとされています。つまり、ピーク時の容量は体験に影響する可能性がありますが、特定地域の特定時間を永続的な固定ルールとして扱うべきではありません。

実用的には次のように考えます。

大きなリファクタリングや重い分析は、自分のネットワークとサービスが安定している時間に行う。
すぐ離席する直前に超長タスクを始めない。
長時間離れる予定があるなら、先に /compact または /clear する。
小さな修正なら、長いコンテキストのまま Opus で強引に走らせない。

固定の「何時から何時は使わない」というルールを覚えるより、このほうが安定します。

07 CLAUDE.md、rules、MCP、skills を軽くする

Claude Code はセッション内でプロジェクトルール、ツール情報、一部の環境コンテキストを読み込みます。公式ドキュメントでも、汎用ルールと専用ルールを分け、毎回大量の無関係な内容を読み込まないようにすることが推奨されています。

おすすめの分け方は次の通りです。

CLAUDE.md：全体に常に適用される最小限のルールだけ。
rules：特定パスや特定ファイルタイプに必要なルール。
skills：投稿、デプロイ、画像生成、コードコミットなどの特定ワークフロー。
MCP：現在のタスクで本当に使う server だけ有効にする。

CLAUDE.md が何百行、何千行もあると、毎回その分を持ち込みます。たまにしか使わない手順は skill に移し、必要なときだけ呼び出すほうが軽くなります。

MCP も同じです。ツールが多いほど効率が上がるとは限りません。Claude Code のドキュメントでは、/mcp で不要な server を確認して無効化し、/context で何がコンテキストを使っているか確認できると説明されています。

08 実用コマンド一覧

日常的によく使うのは次のコマンドです。

1

/model

モデルを切り替える。通常は Sonnet、複雑な推論では Opus。

1

/clear

現在のコンテキストをクリアする。無関係なタスクに切り替えるときに使う。

1

/compact

会話履歴を圧縮する。段階が終わったが同じタスクを続けるときに使う。

1

/context

コンテキスト使用量を確認し、何が場所を取っているか調べる。

1

/status

現在のサブスクリプションや使用量関連の状態を見る。公式ヘルプでも残り割り当ての確認に推奨されています。

1

/mcp

MCP server を確認、管理し、現在使わないツールを無効化する。

API 課金で使っている場合は /cost も参考になります。ただし Pro/Max サブスクリプションでは、公式ドキュメントが /cost のドル見積もりは請求の基準ではないと説明しています。サブスクリプション利用者は /stats や /status の利用情報を見るほうが適しています。

09 使用枠を節約する作業フロー

使いやすい流れは次のようになります。

新しいタスクの前に /clear する。
デフォルトは Sonnet にする。
Claude にはまずプロジェクト構造と重要ファイルだけを読ませ、リポジトリ全体を一気に読ませない。
小さな段階が終わるたびに /compact する。
難しい詰まりどころだけ Opus に切り替える。
ログ、エラー、テスト出力は絞ってから渡す。
タスク完了後は /clear し、古いコンテキストを引きずって新しい作業を始めない。
定期的に CLAUDE.md、MCP、skills を見直し、常駐コンテキストを小さくする。

この流れの核心は、Claude に毎回「今本当に必要なもの」だけを見せることです。

10 まとめ

Claude Code の使用枠がすぐ尽きる原因は、たいてい1つではありません。高コストなモデル、消していない長い会話、多すぎるファイルやログ、重い MCP とルール、キャッシュ命中率の低下、ピーク時の容量変動が重なって起こります。

節約の要点はシンプルです。

日常作業は Sonnet を優先する。
Opus は本当に複雑な問題に残す。
段階が終わったら /compact。
タスクを切り替えるときは /clear。
/context でコンテキスト肥大化の原因を探す。
CLAUDE.md、rules、MCP、skills を軽くする。
リポジトリ全体、ログ全体、大量の画像をそのまま入れない。

同じ Pro や Max でも、どれだけ作業できるかはコンテキスト管理に大きく左右されます。コンテキストを小さくし、タスクの境界をはっきりさせると、Claude Code はかなり安定して使いやすくなります。

参考リンク

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching