Claude Code、便利すぎて使いまくっていたら月額が想定の3倍になっていた。トークン消費を可視化・分析し、品質を落とさずコストを52%削減した全プロセスを数字付きで公開します。
この記事でわかること：
- Claude Codeのトークン消費がどこで膨らむのか
- 品質を維持しながらコストを半減させる4つの具体策
- コスト監視を仕組み化する方法
環境・前提条件
| 項目 | 内容 |
|---|---|
| プラン | Claude Max（月額$200） / Anthropic API 併用 |
| 利用期間 | 2025年4〜6月（3ヶ月間の計測） |
| プロジェクト規模 | TypeScript + Next.js（約120ファイル、2万行） |
| 利用頻度 | 平日5〜8時間/日 |
| 計測方法 | Claude Codeの /cost コマンド + API Usage Dashboard |
1. 衝撃の請求：Claude Codeを1ヶ月本気で使った実際のコスト
4月の請求を見て目を疑いました。
API利用分だけで 約$620（約9.3万円）。月額$200のMaxプランの上限に何度も到達し、API直接利用に切り替えた分を合わせるとこの金額です。当初の想定は月$200〜250程度だったので、約3倍のオーバーです。
内訳を調べると、1日あたり平均 約150万トークン を消費していました。特に多い日は300万トークンを超える日もありました。
「体感では普通に使っているだけ」なのに、なぜここまで膨らんだのか。ここから分析が始まりました。
2. どこでトークンが消費されているか — セッション別・タスク別の消費分析
まず、1週間のセッションをすべて記録し、タスクの種類ごとにトークン消費を分類しました。
衝撃的な事実：本来やりたい作業（新規コード生成＋レビュー）は全体のわずか20%でした。
残りの80%は、コンテキストの再送信・巨大ファイルの読み込み・エラー修正の堂々巡りという「非生産的な消費」に費やされていたのです。
セッション別に見ると、さらに明確なパターンが見えました。
| セッションの長さ | 平均トークン消費 | 1トークンあたりの成果 |
|---|---|---|
| 短い（〜30ターン） | 約8万トークン | 高い |
| 中程度（30〜80ターン） | 約35万トークン | 中程度 |
| 長い（80ターン〜） | 約120万トークン | 非常に低い |
長いセッションではトークン消費が指数関数的に増加する一方、生産性は頭打ちになっていました。
3. コスト爆発の3大原因
分析の結果、コスト爆発の原因は大きく3つに集約されました。
原因①：無駄なコンテキスト送信
Claude Codeは会話が長くなるほど、過去のやり取りすべてをコンテキストとして送信します。80ターンを超えるセッションでは、1回のリクエストで10万トークン以上がコンテキストだけで消費されていました。
さらに、CLAUDE.md に不要な情報を大量に書いていたため、毎回のリクエストで数千トークンが無条件に消費されていました。
原因②：再試行ループ
指示が曖昧だったり、型定義が不足していたりすると、Claudeが生成→エラー→修正→エラーのループに入ります。ひどいケースでは 1つのバグ修正に15回以上の往復 が発生し、30万トークンを消費していました。
原因③：巨大ファイル読み込み
「このファイルを見て」と指示するたびに、Claude Codeはファイル全体を読み込みます。3,000行を超えるファイルを何度も参照させていたため、1ファイルの読み込みだけで数万トークンが飛んでいました。
4. 対策①：CLAUDE.mdの最適化でベースコンテキストを圧縮する
CLAUDE.md はClaude Codeが 毎回のリクエストで自動的に読み込む ファイルです。ここが肥大化すると、すべてのやり取りのベースコストが上がります。
Before（最適化前）
# CLAUDE.md（最適化前：約2,800トークン）
## プロジェクト概要
このプロジェクトは〜（長い説明）...
## アーキテクチャの詳細
フロントエンドはNext.js 15を使用し〜（詳細な説明）...
## 全コーディング規約
- 変数名は〜
- 関数は〜
- （50項目以上のルール）
## デプロイ手順
1. まず〜
- （詳細な手順）
After（最適化後）
# CLAUDE.md（最適化後：約600トークン）
## Stack
Next.js 15 / TypeScript 5.7 / Prisma / Tailwind CSS 4
## Commands
- dev: pnpm dev
- test: pnpm vitest run
- lint: pnpm eslint . --fix
## Rules
- 日本語でコミュニケーション
- 関数: アロー関数 + 明示的な戻り値型
- コンポーネント: FC不使用、Props型をexport
- エラー: Result型パターン（throw禁止）
- テスト: 変更したファイルに対応するテストを必ず更新
## Architecture
src/app/ → ルーティング
src/features/ → 機能別モジュール（詳細は docs/architecture.md を参照）
ポイント：
- 詳細な説明は外部ドキュメント（
docs/配下）に分離し、必要時だけ参照させる - ルールは「判断に迷うもの」だけに絞る
- 当たり前のこと（「バグのないコードを書け」など）は書かない
これだけで、毎リクエストあたり約2,200トークンの削減になりました。1日200リクエストとすると、1日で約44万トークンの節約です。
5. 対策②：/compactとセッション分割の戦略的活用
/compact の使い方
/compact コマンドは、現在の会話履歴を要約して圧縮してくれます。20〜30ターンごとに実行することで、コンテキストの膨張を防ぎます。
# 20ターンほど作業した後に実行
> /compact
# カスタムプロンプトで要約内容を指定することも可能
> /compact 現在の実装状況とTODOリストに焦点を当てて要約して
セッション分割のルール
私が実践しているルールはシンプルです。
| ルール | 基準 |
|---|---|
| 1セッション1タスク | 「〇〇機能の実装」のように単一目的にする |
| 30ターンで判断 | 30ターン超えたら /compact or 新セッション |
| 引き継ぎメモ | セッション終了時に成果をファイルに書き出す |
引き継ぎメモの例：
<!-- docs/session-notes/2025-06-15-auth.md -->
## 認証機能の実装（セッション1）
### 完了
- JWTトークンの発行・検証ロジック（src/features/auth/jwt.ts）
- ミドルウェアの作成（src/middleware.ts）
### 未完了
- リフレッシュトークンのローテーション
- ログアウト時のトークン無効化
### 注意点
- jose ライブラリを使用（jsonwebtoken は Edge Runtime 非対応のため）
次のセッションでは「docs/session-notes/2025-06-15-auth.md を読んで、未完了のタスクから続けて」と指示するだけです。会話履歴を丸ごと引き継ぐよりはるかに効率的です。
6. 対策③：MCPを使って外部にコンテキストを逃がすテクニック
MCP（Model Context Protocol）サーバーを活用すると、Claude Codeが必要な情報を「必要な時だけ」取得する仕組みが作れます。
実践例：プロジェクトのドキュメントをMCPで提供
ファイルシステムMCPサーバーを設定して、ドキュメントを必要時にだけ参照させます。
// .claude/settings.json
{
"mcpServers": {
"project-docs": {
"command": "npx",
"args": [
"-y",
"@anthropic-ai/mcp-server-filesystem",
"./docs"
]
}
}
}
Context逃がしの考え方
| 情報の種類 | 配置場所 | 参照方法 |
|---|---|---|
| 毎回必要なルール | CLAUDE.md（圧縮版） | 自動読み込み |
| アーキテクチャ詳細 | docs/architecture.md | MCPまたは明示的に参照指示 |
| API仕様 | docs/api/ | 必要な時だけ該当ファイルを参照 |
| 過去のセッション記録 | docs/session-notes/ | 引き継ぎ時のみ参照 |
| 外部API仕様 | MCP経由で取得 | ツール呼び出し時のみ |
原則：CLAUDE.mdには「常に必要な最小限」だけを書き、それ以外は外部に置いて必要時に取得する。
7. 対策④：サブタスクの粒度設計でトークン効率を最大化する
Claude Codeには --subtask フラグによるサブタスク機能（サブエージェント）があります。メインのコンテキストを汚さずに、独立した調査や実装を実行できます。
粒度設計の原則
❌ 悪い例：「認証機能を実装して」（曖昧・巨大）
✅ 良い例：
1. 「JWTトークンの発行関数を実装して。入力はuserId: string、出力はPromise<string>」
2. 「上で作ったjwt.tsに対するテストを書いて」
3. 「認証ミドルウェアを実装して。jwt.tsのverify関数を使うこと」
効果的なサブタスク活用パターン
| パターン | 使い方 | トークン効率 |
|---|---|---|
| 調査タスク | 「〇〇ライブラリの使い方を調べて要約して」 | 高い（メインを汚さない） |
| 生成タスク | 「型定義ファイルを生成して」 | 高い |
| レビュータスク | 「このdiffをレビューして」 | 中程度 |
また、プロンプトの書き方自体も重要です。
## 効率的なプロンプトのテンプレート
### やりたいこと
{1〜2文で簡潔に}
### 制約
- {具体的な技術的制約}
- {命名規約など}
### 入出力
- Input: {型や具体例}
- Output: {期待する型や具体例}
### 参考ファイル
- src/features/auth/types.ts（型定義のみ参照）
「参考ファイル」で ファイル全体ではなく必要な部分を指定する のもポイントです。「types.tsの User 型を参照して」のように限定すると、Claude Codeが読み込む範囲を最小限に抑えられます。
8. 削減結果：Before/Afterの3軸比較
4月（最適化前）と6月（最適化後）の比較です。
| 指標 | 4月（Before） | 6月（After） | 変化 |
|---|---|---|---|
| 月額コスト | $620 | $295 | -52.4% |
| 1日平均トークン消費 | 約150万 | 約68万 | -54.7% |
| タスク完了数/月 | 85件 | 92件 | +8.2% |
| 手戻り率 | 28% | 12% | -57.1% |
| 平均セッション長 | 62ターン | 24ターン | -61.3% |
コストが半減したのに、タスク完了数は増え、手戻りは減りました。
これは当然の結果です。セッションを短く区切り、プロンプトを明確にしたことで、Claude Codeの出力精度が上がったためです。長いセッションでコンテキストが混濁すると、AIの回答品質は著しく低下します。
9. コスト監視の仕組み化：簡易ダッシュボードの作り方
最適化を一度やって終わりにしないために、日常的な監視の仕組みを作りました。
方法1：/cost コマンドの定期実行
Claude Codeの /cost コマンドで現在のセッションのコストを確認できます。私はセッションの区切りごとに必ず実行しています。
方法2：APIログの収集と可視化
API利用の場合、Anthropicの Usage Dashboard でトークン消費を確認できます。
方法3：簡易スクリプトでの記録
セッション終了時にコストを記録するシンプルな仕組みを運用しています。
#!/bin/bash
# log-session-cost.sh
# セッション終了時に手動で実行する簡易ログ
DATE=$(date +%Y-%m-%d)
TIME=$(date +%H:%M)
TASK="$1" # タスク名を引数で受け取る
TOKENS="$2" # /cost で確認したトークン数
COST="$3" # /cost で確認したコスト
echo "${DATE},${TIME},${TASK},${TOKENS},${COST}" >> ~/claude-cost-log.csv
echo "✅ 記録しました: ${TASK} - ${TOKENS} tokens - \$${COST}"
# 使い方
./log-session-cost.sh "認証機能実装" "85000" "0.42"
このCSVを週次で集計し、タスク種別ごとのコスト傾向を確認しています。異常に高コストなタスクパターンが見つかれば、プロンプトの改善に取り組みます。
まとめ
- トークン消費の80%は「非生産的な消費」（コンテキスト再送信・巨大ファイル読み込み・再試行ループ）であり、ここを削減するだけで品質を落とさずコストが半減する
- CLAUDE.mdの圧縮・セッション分割・MCPによるコンテキスト外部化・サブタスクの粒度設計の4つの施策を組み合わせることが重要
- 可視化と記録を仕組み化し、コストを継続的にモニタリングすることで、最適化の効果を持続させられる