# Claude Code トークン使用量監査：コンテキスト、キャッシュ、MCP、セッションコスト

> 総トークン数だけでは原因は分かりません。課金経路を確定し、コンテキストとキャッシュ、MCP、対照セッションを同じ条件で比較します。

- URL: https://blog.laozhang.ai/ja/posts/claude-code-usage-limit-issues
- Published: 2026-08-04
- Updated: 2026-08-04
- Author: AI Free API Team (https://blog.laozhang.ai/ja/about)
- Category: Claude Code
- Tags: Claude Code, トークン使用量, コンテキスト, プロンプトキャッシュ, MCP

---
Claude Code の使用量監査で最初に見るべきものは、節約テクニックではなく数字の所有者です。サブスクリプションの使用量バー、ローカルのセッション見積もり、Claude Console、クラウド事業者の請求は同じメーターではありません。

問題のセッションを閉じずに `claude --version` を記録し、`/usage`、`/context`、`/mcp` を実行します。モデル、effort、認証経路、session ID、コンテキスト率、input/output、cache creation/read、正確な制限表示やエラーを控えてください。秘密鍵、顧客コード、私的な会話は証拠資料に含めません。

この記事は 2026 年 8 月 4 日に公式の[コスト管理](https://code.claude.com/docs/ja/costs)、[コンテキストウィンドウ](https://code.claude.com/docs/ja/context-window)、[プロンプトキャッシュ](https://code.claude.com/docs/ja/prompt-caching)、[MCP](https://code.claude.com/docs/ja/mcp)を確認しています。表示が違う場合はインストール済みバージョンを基準にしてください。

## 監査前にメーターを分類する

`/usage` の Session ブロックは現在のセッションのトークン構成と、標準価格からローカル計算した金額を示します。比較には便利ですが、割引や契約単価を反映した請求書ではありません。Pro や Max は使用量がサブスクリプションに含まれるため、ドル表示だけで追加請求を判断できません。

| 表示 | 判断できること | 判断できないこと |
| --- | --- | --- |
| `/usage` | ローカルなセッション内訳、プラン窓、最近の帰属 | 全端末の完全な活動 |
| `/context` | 現在のウィンドウを占める項目 | 課金した事業者 |
| statusline | 継続的なコンテキストと推定コスト | 確定請求額 |
| Claude Console | API workspace の利用額 | Pro/Max の残量 |
| クラウド請求 | Bedrock、Google Cloud、Foundry の費用 | Claude サブスクリプション使用量 |

経路が不明なら計算を止め、ログイン、環境変数、base URL、プロバイダーを確認します。詳しい分岐は [API key とサブスクリプション課金](https://blog.laozhang.ai/ja/posts/claude-code-api-key-vs-subscription-billing)にまとめています。

## 一枚の監査台帳を作る

![Claude Code のメーターと証拠強度を整理した監査台帳](https://blog.laozhang.ai/posts/ja/claude-code-usage-limit-issues/img/audit-ledger.webp)

時刻とタイムゾーン、バージョン、モデル、effort、経路、作業ディレクトリ、session ID、`/context` の主要カテゴリ、トークン分類、MCP 帰属を一緒に記録します。モデル変更、MCP 接続、`/compact`、アップデート、古いセッションの再開、長い中断も重要です。

現在の `/usage` は、最近の使用量を skills、subagents、plugins、個別 MCP server に帰属させ、長いコンテキストや cache miss が目立つ場合に示します。ただし本機の履歴に基づく近似です。他端末や Claude.ai を含む会計帳簿として扱わないでください。

## コンテキスト増加とキャッシュ再作成を分ける

長いセッションでは、指示、ファイル、会話、tool result が次のリクエストへ持ち越されます。キャッシュが正常でも、無関係な複数タスクを同じ会話で続ければ一回あたりの処理対象は増えます。

まず `/context` で大きいカテゴリを見ます。開始時から CLAUDE.md、memory、MCP tool 名、skill 説明が入り、その後にファイルと会話が増えます。古いタスクが大部分なら、新しい目的専用のセッションが最も明確な対策です。

次に `cache_read_input_tokens` と `cache_creation_input_tokens` を分けます。read は既存 prefix の再利用、creation は書き込みまたは再構築です。モデルや effort の変更、prefix に入る tool の変更、`/compact`、アップデート、経路変更、TTL 切れの直後に一度再構築されるのは正常な場合があります。同条件の似たターンで creation が繰り返し高いときに初めて疑います。詳細は [cache miss コストガイド](https://blog.laozhang.ai/ja/posts/claude-code-cache-miss-token-costs)を参照してください。

## MCP は定義と結果を別々に測る

設定された server 数だけでコストを推定しないでください。対応経路では Tool Search が schema を遅延読み込みし、必要な tool だけを発見します。一方で gateway、クラウド、モデル、設定、`alwaysLoad` によって upfront load へ戻る場合があります。

`/mcp` と `/context` で有効な tool と読み込み方を確認した後、返却データ量を確認します。小さな定義でも、大量ログや全テーブルを返せば会話履歴が膨らみます。Claude Code は単一 MCP 結果が 10,000 token を超えると警告し、既定上限は 25,000 token です。上限を上げる前に filter、pagination、summary、file handle を使います。整理方法は [MCP context overload ガイド](https://blog.laozhang.ai/ja/posts/claude-code-mcp-context-overload)で扱っています。

## 同じ条件で対照セッションを作る

![重い Claude Code セッションとクリーンな対照セッションの比較](https://blog.laozhang.ai/posts/ja/claude-code-usage-limit-issues/img/control-session.webp)

1. 同じプロジェクト、バージョン、経路、モデル、effort を維持します。
2. 新規セッションを開き、必要な MCP だけを残します。
3. 作業前の `/usage` と `/context` を保存します。
4. 完了条件が明確な小さい作業を一つ実行します。
5. 同じ項目を再取得し、context、creation/read、output、MCP 帰属を比較します。

対照が軽ければ、元の原因は履歴、巨大な tool result、混在タスク、並列 agent である可能性が高いです。無関係な仕事の境界で `/clear`、自然な区切りで `/compact` を使い、tool の返却範囲を狭めます。

対照でも再現するなら、何度も試さず一回分を保存します。同一条件、時刻、トークン分類、MCP 状態、正確なエラーをそろえれば、サポート側が比較できます。

## 証拠に対応する最小の修正を選ぶ

| 証拠 | 最初の対応 | 先にしないこと |
| --- | --- | --- |
| 無関係な履歴が大きい | 目的別の新規セッション | すぐ上位プランへ変更 |
| creation が連続して高い | model、effort、tools、route を固定 | 毎ターン compact |
| 一つの MCP が大きい | query と返却量を狭める | 全 MCP を永久停止 |
| output が主因 | 成果物を限定する | cache を疑う |
| agent が主因 | 数と spawn prompt を小さくする | 子 context を無料とみなす |
| 正確な `529` | status 確認と限定再試行 | 個人 quota と解釈 |
| API `429` | provider の retry と limit に従う | Pro/Max 枯渇と解釈 |
| 対照でも異常 | 台帳でエスカレーション | 追加 usage で隠す |

監査のゴールは普遍的な式ではありません。大きな増分を、持ち越しコンテキスト、キャッシュ read/write、MCP、output、agent、プラン窓、課金経路のどれかに割り当てられれば、次の一手を安全に選べます。