上限を気にせずClaude Codeを使い倒すために、私がやっている2つの工夫
コスト削減=コンテキスト削減。サブエージェントによるコンテキスト分離とMANAGEMENT.mdによるセッション使い捨て戦略で、Claude Codeの上限問題に向き合う実践的な方法を紹介します。
Claude Codeを使いはじめた頃は、コードのことを質問する程度でした。でも最近は違います。プランの立案、コーディング、レビュー、テストまで、開発のほぼ全工程をClaude Codeに任せるようになりました。
そうなると避けられないのが「使用上限」との戦いです。
Claude Codeのサブスクリプションは決して安くありません。それでも上限に当たる頻度が増えてきました。何か対策をしなければ、と思いながらも「どこから手をつければいいのか」がわからない方も多いのではないでしょうか。
結論から言うと、コスト削減 = コンテキスト削減です。コンテキストとは何か、どう削減するかを理解すれば、上限への恐怖はかなり和らぎます。
この記事では、Anthropicの公式ドキュメントで推奨されている方法と、私が実際に使っている2つの工夫を紹介します。
そもそもClaudeはどうやって会話を処理しているのか
コンテキストを削減する方法を語る前に、Claudeが会話をどう処理しているかを押さえておきましょう。
Claudeには「記憶」がありません。厳密に言うと、前回の会話を内部に保存しているわけではなく、毎回「これまでのやり取り全部+今の質問」をまとめてモデルに渡しています。これがコンテキストウィンドウです。
たとえば、1時間かけてClaude Codeと開発を進めた場合、その間のメッセージのやり取り、ファイルの読み込み内容、コマンドの実行結果、エラーログ……これらが全部「履歴」としてコンテキストに積み上がっていきます。
そしてこの履歴の量が、そのままトークン数になります。トークン数 = コストです。
Claude Codeのコンテキストウィンドウの上限は約20万トークン。一見多く感じますが、大きなファイルを読み込んだり、長いコマンド出力が返ってきたりすると、想像以上に早く埋まります。上限に近づくと自動的に圧縮が走りますが、それでも追いつかなければセッションを切るしかありません。
つまり「コンテキストを減らす」とは、「この履歴の積み上がり方をコントロールする」ということです。
公式が推奨するコンテキスト削減のコツ
Anthropicの公式ドキュメントには、コンテキストを削減するためのヒントがいくつか紹介されています。まずはここから押さえておきましょう。
/compact と /clear を使いこなす
最も手軽な方法が、スラッシュコマンドの活用です。
/compact は会話の履歴を圧縮するコマンドです。古いツール出力を削除しながら、重要な内容(ユーザーのリクエスト、コードの断片)を要約して保持してくれます。
使い方はチャット欄に /compact と入力するだけです。「なんとなく重くなってきた」と感じたタイミングで実行するのがおすすめです。保持してほしい情報がある場合は以下のように指定できます。
/compact focus on the API changes
/clear は会話の履歴を完全にリセットするコマンドです。全く別のタスクに切り替えるときに使います。古い文脈を引きずったまま続けるより、まっさらな状態で始めた方がトークンの無駄がありません。
/clear
現在のコンテキスト使用量を確認したい場合は /context コマンドを使うと、何がどれだけトークンを使っているかを可視化できます。まずはここで現状を把握してみてください。
CLAUDE.md は200行以内に絞る
CLAUDE.mdはセッションのたびに毎回読み込まれ、コンテキストに入り込みます。つまり長くなればなるほど、何もしていなくてもトークンを消費してしまいます。
公式では200行以内を目安にすることを推奨しています。
肥大化しがちなCLAUDE.mdをスリム化するコツは、「毎回必要な情報だけを残す」ことです。具体的には以下を参考にしてください。
- 残すもの: ビルドコマンド、命名規則、アーキテクチャの概要、コーディング規約
- 移動させるもの: 特定のワークフロー手順、複数ステップの作業フロー → スキルファイル(
.claude/skills/)に切り出してオンデマンドで読み込む
スキルに切り出した内容は呼び出されたときだけコンテキストに読み込まれるため、使わない日はトークンを一切消費しません。
使っていないMCPサーバーを無効化する
MCPサーバーを複数登録している場合、ツールの定義情報がセッション開始時にコンテキストに読み込まれます。使っていないサーバーが残っていると、静かにトークンを食い続けます。
まず /mcp コマンドでどのサーバーがどれだけトークンを使っているかを確認しましょう。使っていないサーバーが見つかったら、Claude Codeにそのまま頼めば設定を変更してくれます。
使っていないMCPサーバーを設定から無効化してください
Hooksでツール出力を事前にフィルタリングする
少し上級者向けですが、Hooksを使えばClaude Codeがツールを実行した結果を「受け取る前」に加工できます。
たとえば、テスト実行やログ解析で大量の出力が返ってくる場面では、ERRORやWARNの行だけを抽出してからClaudeに渡すよう設定できます。設定ファイルを直接編集する必要はなく、以下のようにClaude Codeに依頼するだけで対応してくれます。
Bashツールの出力が大きくなりすぎないよう、
PostToolUseフックでERRORとWARNの行だけに絞り込むHooksを設定してください
大量の出力が発生しやすい作業(テスト実行、ログ解析など)では、劇的にトークンを削減できます。
実践① サブエージェントでコンテキストを分離する
公式の設定を整えたら、次は使い方の工夫です。私が最も効果を実感しているのが、サブエージェントの活用です。
サブエージェントはコンテキストが独立している
Claude Codeのサブエージェント(Agentツール)の重要な特徴は、メインのセッションとは完全に独立したコンテキストで動くことです。
サブエージェントがどれだけ大量のファイルを読み込もうと、長いコマンドを実行しようと、その内容はメインセッションには流れてきません。返ってくるのはサマリーだけです。
たとえば「このディレクトリ全体のコードをレビューして」という指示をメインセッションで実行すると、全ファイルの読み込み結果がそのままコンテキストに積み上がります。でもサブエージェントに委譲すれば、重要な指摘だけが要約されて返ってきます。
実際の使い方
サブエージェントへの委譲は、プロンプトに「サブエージェントを使って」と書くだけで機能します。より細かく制御したい場合は、用途に特化したカスタムエージェントを定義することも可能です。
たとえば、コーディング専任のサブエージェントを作りたい場合は、そのままClaude Codeに頼めば作成してくれます。
コーディング専任のカスタムサブエージェントを作成してください。
実装・修正・リファクタリングを担当し、完了報告と変更ファイルの一覧を返すエージェントです。
私はこんな作業を委譲している
具体的には以下のような作業をサブエージェントに任せています。
- プランの作成: 大量のファイルを読み込んで設計を考える作業は、メインセッションでやると一気にコンテキストが埋まります
- コーディング: 実装作業そのものを委譲し、完了報告とコードの差分だけ受け取ります
- レビューとテスト: コードベース全体を走査するような作業もサブエージェント向きです
メインセッションの役割は「指示を出し、結果を受け取り、次のアクションを判断すること」に徹します。いわばプロデューサーのような立ち位置です。
こうすることで、どれだけ大きなプロジェクトを扱っていても、メインセッションのコンテキストは常にクリーンな状態を保てます。
実践② MANAGEMENT.mdをプロマネにして、セッションを使い捨てにする
もう一つの工夫は、セッションを長期化させないことです。
「長いセッションを続けるほどコンテキストが積み上がる」という構造上、セッションを短命にすることは根本的な解決策になります。ただ、セッションを切るたびに「どこまで進んでいたっけ」と迷うのでは本末転倒です。
そこで私が使っているのが、MANAGEMENT.mdにプロジェクトの状態を全部書き出すという方法です。
セッションをまたいでも迷わない仕組み
プロジェクトを始めるとき、まず docs/MANAGEMENT.md を作成します。このファイルには全体方針・注意事項・タスクリスト(進行中・未着手・完了)・変更履歴を記載します。
ただし、このファイルを自分で直接書くことはありません。私は manager というカスタムスキルを使って、作成から更新まで全てClaude Codeに任せています。
プロジェクト開始時に以下を実行すると、コードベースと要件を読み込んだうえでMANAGEMENT.mdを作成してくれます。
/manager plan
タスクが完了したら以下で進捗を更新します。
/manager update
次のセッションで現状を把握したいときは以下を実行するだけです。
/manager
コードベースとgit履歴を読み込み、進行中のタスクと次のアクション候補を整理して報告してくれます。
このスキルは自分で定義したものですが、同じ発想は手動でも再現できます。新しいセッションのたびに「MANAGEMENT.mdを読んで現状を把握して、次にやるべきことを教えて」とClaude Codeに伝えるだけでも十分機能します。
セッションは「一工程ずつ」使い捨てる
私のイメージは、プロジェクト全体を管理するプロマネ(MANAGEMENT.md)と、各工程を担当する作業者(各セッション)が分かれている構造です。
- MANAGEMENT.mdを読ませて次のタスクを把握する
- そのタスク専用のセッションを立ち上げてサブエージェントに作業を委託する
- タスクが完了したらMANAGEMENT.mdを更新してセッションを閉じる
- 次のタスクは新しいセッションで始める
こうすることで、どのセッションも「その作業だけ」のコンテキストしか持ちません。一つのセッションで開発のはじめから終わりまで抱えようとするから、コンテキストが膨らんでしまうのです。
セッションは記憶するものではなく、使い捨てるもの。 記憶はファイルに任せればいいのです。
まとめ:セッションを長持ちさせようとしない
コンテキスト削減のポイントをまとめると、こうなります。
| 施策 | 難易度 | 効果 |
|---|---|---|
/compact /clear を使う | ★☆☆ | すぐ実践できる |
| CLAUDE.mdを200行以内に絞る | ★☆☆ | 地味に効く |
| 使っていないMCPサーバーを無効化する | ★☆☆ | 設定を見直すだけ |
| Hooksでツール出力をフィルタリングする | ★★★ | 効果は大きい |
| サブエージェントに重い作業を委譲する | ★★☆ | 最も効果的 |
| MANAGEMENT.mdでセッションを使い捨てにする | ★★☆ | 根本的な解決策 |
共通しているのは「セッションに多くを持たせすぎない」という発想です。
Claude Codeを使いはじめると、ついセッションを大切に長持ちさせようとしてしまいます。でも実は逆で、セッションをどれだけ短く、軽く保てるかがコスト管理の核心だと気づきました。
まず今日から試せるのは /context でコンテキストの現状を確認することです。何が積み上がっているかを把握するところから始めてみてください。