Claude Codeの消費が増える原因と見直し：コストを抑える作業の組み立て方

なぜ「長く使うほど重くなる」のか

公式ドキュメントによると、Claude Codeは1回のリクエストごとに会話全体を送り直します。ツールを使うたびに新しいリクエストが発生し、そこにも履歴が付きます。プロンプトキャッシュのおかげで再読み込みは安いレートで処理されますが、ゼロにはなりません。そのため、一日開きっぱなしのセッションでの一行の質問にも、会話全体ぶんの消費が乗ります。

キャッシュには有効期限があります。休憩が長くなると、戻って最初のメッセージで全文脈が再処理されます。キャッシュはモデルごとに別なので、/model で切り替えた直後も同じ現象が起きます。/effort の変更も、多くのモデルでキャッシュを失効させます（一部のモデルでは維持されると公式に書かれています）。MCPサーバーの接続変更も、ツール検索による遅延読み込みが働かない環境では失効の原因になります。

つまり、消費を決めるのは「何回聞いたか」より、文脈の大きさ、リクエストの数、キャッシュを壊した回数です。

自分の作業から原因を特定する

直す前に、どのパターンに当てはまるかを見ます。以下はすべて公式に載っている確認手段です。

1. `/usage` を見る

• セッション欄に、モデル別のトークン内訳が出ます。ドル表示は通常、定価をもとにした概算で、管理者が組織の契約レートを設定している場合はそのレートを使います。サブスクリプション利用者の請求額を示すものではありません。API利用の正確な請求はConsoleで確認します。
• Pro・Max・Team・Enterpriseでは、使用量がスキル、サブエージェント、プラグイン、MCPサーバー別の割合で出ます。10%以上を占める行動には、見直しの推奨が1行ずつ表示されます（例：CLAUDE.mdの縮小、作業前の /compact）。
• 表示は、このマシンのローカル履歴からの概算です。他の端末やclaude.aiの利用は含まれません。
• v2.1.251以降は Prompt cache (main) の行で、キャッシュの命中率とミス回数、現在キャッシュが温かいか冷えているかが分かります。ミスが多いなら、モデル切替や接続変更の頻度を疑います。

2. `/context` で常駐しているものを見る

何が文脈を占めているかを確認できます。使っていないMCPサーバーや、長いCLAUDE.mdが上位に出ることがあります。

3. `/insights` で作業の癖を見る

直近のセッション（1回で最大200件）を分析し、依頼の誤解や手戻りなどの摩擦をHTMLレポートにします。ただし、この分析自体もトークンを消費します。

見直しチェックリスト

下の表が本記事の成果物です。「該当する行動」に1つでも当てはまれば、右の対策を試してください。

• :-、消費が増える理由：:-、対策：:-、確認方法：:-
• 無関係な作業を同じセッションで続ける、消費が増える理由：古い文脈が毎回送られる、対策：別件に移る前に /rename して /clear。後で /resume で戻れる、確認方法：/usage のセッション値が /clear で0に戻る（v2.1.211以降）
• 巨大な履歴を放置し、休憩後にいきなり /compact する、消費が増える理由：キャッシュ切れ後の要約では、要約対象の会話履歴が未キャッシュ入力として再処理される、対策：作業の区切りの、キャッシュが温かいうちに実行。不要なら /clear、確認方法：Prompt cache (main) の warm/cold
• 作業の途中でモデルや /effort を何度も変える、消費が増える理由：キャッシュが失効し、全履歴が再処理される、対策：セッション冒頭で決め、切替はタスクの切れ目で行う、確認方法：ミス回数の増加
• 常にOpusなど重いモデルを使う、消費が増える理由：同じ作業でも1リクエストあたりが重い、対策：日常の実装はSonnet、難しい設計判断だけ上位モデル。単純なサブエージェントは model: haiku、確認方法：/usage のモデル別内訳
• 使わないMCPサーバーを入れたままにする、消費が増える理由：ツール検索による遅延読み込みが使えない環境では、ツール定義が文脈に入り、セッション中の着脱でキャッシュが失効する場合がある、対策：/mcp で無効化。gh などCLIがあればそちらを使う、確認方法：/context
• CLAUDE.mdが長い、消費が増える理由：毎セッション冒頭から常駐する、対策：公式は200行以内が目安。手順書は必要時だけ読み込まれるスキルへ移す、確認方法：/usage の推奨行
• 「全体を見て改善して」と頼む、消費が増える理由：広い探索で多数のファイルを読む、対策：対象ファイル・関数・完了条件を指定する（次章）、確認方法：読まれたファイル数
• 長いテストやログの出力をそのまま読ませる、消費が増える理由：出力全体が文脈に残る、対策：失敗行だけに絞る。hookで前処理、または調査をサブエージェントに委任、確認方法：出力量
• サブエージェントやエージェントチームを多用する、消費が増える理由：それぞれが別の文脈で別にリクエストする、対策：小さく保ち、用が済んだら終了。チームメイトにはSonnetを使う、確認方法：/usage の帰属割合
• /loop などの定期タスクを残したまま離席する、消費が増える理由：アイドル中も間隔ごとに全文脈を送る、対策：不要なら停止する、確認方法：/usage の Loops 行（v2.1.242以降）
• 方向がずれたまま進め、あとで大きく直す、消費が増える理由：やり直しの往復が積み上がる、対策：複雑な作業は計画モード（Shift+Tab）で方針を先に確認。ずれたら Esc、/rewind、確認方法：手戻り回数
• 思考が不要な単純作業でも高い設定のまま、消費が増える理由：思考トークンは出力として課金・消費される、対策：/effort を下げる。ただしモデルによっては思考を切れない、確認方法：/usage

プロンプトの提案表示を使っている場合、応答後に短いリクエストが追加で送られます。気になる場合は設定でオフにできます。

依頼文を直す

広い依頼は、読むファイルの範囲を決めないので探索が膨らみます。公式も「コードベースを改善して」のような依頼は広い走査を招くと説明しています。以下は説明用の例で、実際に実行した結果ではありません。

膨らみやすい依頼

このプロジェクトのバグを探して直して。

絞った依頼（説明用の例）

src/auth/login.ts の validateEmail が、"a@b" のような
ドメインにドットがない入力を通してしまいます。
- 対象：validateEmail とその単体テストのみ
- 期待：ドットのないドメインは false を返す
- 完了条件：tests/auth/login.test.ts の該当ケースが通ること
- 他のファイルは、必要になった場合だけ理由を述べてから読んでください

この形には、対象・期待する挙動・完了条件の3点が入っています。Claude側が検証できる終点があると、修正の往復も減ります。公式は検証対象（テストや期待出力）を渡すことを勧めています。

人が行う確認は次のとおりです。

• 指定していないファイルまで変更されていないか、差分を見る。
• テストが通ったという報告は、自分の環境でも実行して確かめる。
• 本番の認証情報や実データは貼らず、説明用のダミーに置き換える。

1セッションの組み立て方

チェックリストを、実際の流れに並べ直すと次のようになります。

1. 開始前：/mcp で不要なサーバーを切り、使うモデルと /effort を決める。
2. 着手：複雑なら計画モードで方針を確認してから実装に入る。
3. 実装中：1ファイル書いてテストする、を繰り返す。大量の出力が出る調査はサブエージェントに任せる。
4. 区切り：タスクが終わったら /rename → /clear。続きがあるなら、離席前に /compact Focus on ... で残したい内容を指定する。
5. 週に1回：/usage の推奨行と /insights を見て、チェックリストの該当行を直す。

直したあとの効果は、同じ種類の作業を数回ぶん /usage で記録して自分で比べてください。効果の大きさは環境次第で、この記事では数値を示せません。

組織やAPI利用の場合

Console（API）やクラウド経由の場合は、請求が従量課金です。公式は、予想外に高い請求の原因として、クリアされない長いセッションと、Opusが既定のままになっていることを挙げています。チームではワークスペースの支出上限や、OpenTelemetryによるユーザー別集計も使えます。なお、サブスクリプションの場合は、上限に達したときのメッセージの種類（セッション上限、週次上限、利用クレジットの上限）で意味が違います。詳細は公式のコスト管理ページで確認してください。

請求や契約個別の質問は、アカウントを確認できるAnthropicのサポートに問い合わせるのが確実です。