結論：設定を見直すだけで月額コストは66%削減できる
Claude Codeを本格導入して3ヶ月、月額コストが$280を超えた時点で「これはちゃんと最適化しないとまずい」と気づきました。
結論から言うと、Effortレベルの使い分け・モデル選択・CLAUDE.mdの最適化の3点を見直すだけで、出力品質をほぼ維持したまま月額$280→$95まで削減できました。
この記事では、同一タスク100個を複数条件で実行した検証結果をもとに、コスト最適化の具体的な方法をお伝えします。
環境・前提条件
| 項目 | 内容 |
|---|---|
| プラン | Claude Max ($100/月) + API従量課金の併用 |
| 検証期間 | 2025年4月〜6月（3ヶ月） |
| 主な用途 | Webアプリ開発（TypeScript/React/Node.js） |
| 測定方法 | Claude Codeの /cost 表示 + API使用量ダッシュボード |
| 品質評価 | 各タスクの出力を5段階で手動スコアリング（後述） |
1. 問題提起：月額コストが想定の3倍になった経緯
Claude Codeの導入当初、私の想定月額は約$80〜$100でした。しかし3ヶ月目に$280を記録。原因を分析すると、以下の3つが浮かび上がりました。
- 全タスクをデフォルト設定（high effort + Opus相当）で実行していた
- CLAUDE.mdに大量のルールを書き込み、毎回のコンテキスト消費が膨大だった
- コンテキストウィンドウの肥大化に気づかず、
/compactを使っていなかった
つまり「とりあえず最高品質で」という運用が、コストを3倍に押し上げていたのです。
2. 検証設計：100タスク × 6条件で比較
コスト最適化の根拠を得るため、以下の条件で検証を行いました。
タスクの分類（合計100タスク）
| カテゴリ | タスク数 | 例 |
|---|---|---|
| 単純コード生成 | 30 | ユーティリティ関数、型定義の作成 |
| バグ修正 | 25 | エラーログからの原因特定と修正 |
| リファクタリング | 20 | 既存コードの構造改善 |
| 設計・アーキテクチャ | 15 | モジュール分割、API設計の提案 |
| テスト生成 | 10 | ユニットテスト・E2Eテストの作成 |
実行条件（6パターン）
各タスクを以下の6条件で実行し、トークン消費量と**出力品質スコア（1〜5点）**を記録しました。
品質スコアの基準は以下の通りです。
- 5点: そのまま本番投入可能
- 4点: 軽微な修正で投入可能
- 3点: 方向性は正しいが追加修正が必要
- 2点: 部分的にしか使えない
- 1点: やり直しが必要
3. 結果①：Effort別のトークン消費量と品質スコア
数値データ
| Effort | 平均トークン消費 | 平均品質スコア | コスト効率（スコア/1Kトークン） |
|---|---|---|---|
| low | 2,800 tokens | 3.2 | 1.14 |
| medium | 8,500 tokens | 4.1 | 0.48 |
| high | 22,000 tokens | 4.4 | 0.20 |
解釈
最も重要な発見は、highとmediumの品質差はわずか0.3点なのに、トークン消費は2.6倍という点です。
Sonnet + medium が最もコスト効率の高いゾーンに位置しています。一方、Opus + high は品質こそ最高ですが、コスト効率は最低クラスです。
4. 結果②：モデル別のコスト対品質比
Sonnetで十分なタスクの特徴
検証の結果、タスクの約70%はSonnetで品質スコア4点以上を達成できることがわかりました。
| タスクカテゴリ | Sonnet平均スコア | Opus平均スコア | Opusが必要か |
|---|---|---|---|
| 単純コード生成 | 4.3 | 4.5 | ❌ 不要 |
| バグ修正 | 3.8 | 4.3 | △ 複雑な場合のみ |
| リファクタリング | 3.9 | 4.4 | △ 大規模な場合のみ |
| 設計・アーキテクチャ | 3.2 | 4.5 | ✅ 推奨 |
| テスト生成 | 4.1 | 4.3 | ❌ 不要 |
Opusが真価を発揮するのは「設計・アーキテクチャ系」のタスクです。複数ファイルにまたがる設計判断や、トレードオフの分析が求められるタスクでは、Sonnetとの品質差が1.3点と顕著でした。
逆に、単純コード生成やテスト生成のような「パターンが明確なタスク」では、Opusを使ってもスコアは0.2点しか上がりません。コスト差を考えると完全にオーバースペックです。
5. 結果③：CLAUDE.mdの記述量とトークン消費の関係
ここが意外な発見でした。
CLAUDE.mdの行数を変えて同一タスクを実行した結果です。
| CLAUDE.md行数 | 毎回の追加トークン消費 | 品質スコア変化 |
|---|---|---|
| 20行（最小限） | +800 tokens | 基準 |
| 80行（中程度） | +3,200 tokens | +0.4 |
| 200行（詳細） | +8,500 tokens | +0.5 |
| 350行（過剰） | +14,000 tokens | +0.3 |
80行を超えると、トークン消費の増加に対して品質改善が頭打ちになります。さらに350行では、情報過多により品質がむしろ低下する傾向が見られました。
効果的なCLAUDE.mdの書き方
# 良い例（約60〜80行）
- プロジェクト固有の技術スタック（簡潔に）
- コーディング規約のうち非自明なもの（例外的なルール）
- ディレクトリ構造の概要
# 悪い例（200行超）
- 一般的なベストプラクティスの羅列（LLMは既に知っている）
- すべてのESLintルールの転記
- READMEの丸コピー
ポイントは、「LLMが事前知識として持っていない、このプロジェクト固有の情報」だけを書くことです。
6. コスト最適化チェックリスト：タスク種別ごとの推奨設定表
検証結果をもとに、タスク種別ごとの推奨設定をまとめました。
推奨設定一覧
| タスク種別 | Effort | モデル | 想定トークン | 備考 |
|---|---|---|---|---|
| ユーティリティ関数の生成 | low | Sonnet | ~2,000 | パターンが明確 |
| 型定義・interface作成 | low | Sonnet | ~1,500 | 機械的な作業 |
| 単体テスト生成 | low〜medium | Sonnet | ~4,000 | テストケースの網羅性次第 |
| 単一ファイルのバグ修正 | medium | Sonnet | ~6,000 | |
| 複数ファイルのリファクタリング | medium | Opus | ~12,000 | 依存関係の把握が必要 |
| API設計・アーキテクチャ提案 | medium〜high | Opus | ~18,000 | 判断力が必要 |
| 大規模な機能実装 | high | Opus | ~25,000 | ここだけhighを許容 |
重要な原則：high effortを使うのは全タスクの10〜15%に絞る。
7. 月額$280→$95に削減した具体的な設定変更
Before（月額$280の運用）
# すべてデフォルト（実質high effort）
# モデル選択も意識せず常にOpus
# CLAUDE.mdは320行の巨大ファイル
# /compact 未使用
After（月額$95の運用）
変更点1：Effortのデフォルトをmediumに変更
Claude Codeの設定で、デフォルトのeffortレベルを medium に変更しました。必要な場合のみ明示的に high を指定します。
# タスク実行時にeffortを明示指定
claude --effort low "この関数にJSDocコメントを追加して"
claude --effort high "認証モジュール全体をOAuth2.0対応にリファクタして"
変更点2：モデル使い分けルールの策定
チーム内で以下のルールを共有しました。
- Sonnet使用（全体の75%）: 単一ファイル作業、テスト生成、定型的な修正
- Opus使用（全体の25%）: マルチファイル設計、アーキテクチャ判断、複雑なデバッグ
# モデルの切り替え
claude --model sonnet "単体テストを書いて"
claude --model opus "このモジュールの責務分割を提案して"
変更点3：CLAUDE.mdのダイエット（320行→75行）
削除した内容：
- 一般的なTypeScriptのベストプラクティス（LLMは知っている）
- ESLint/Prettierの設定詳細（設定ファイルを直接読めばよい）
- チーム紹介やプロジェクト背景（コード生成に不要）
残した内容：
- プロジェクト固有のディレクトリ規約
- 独自のAPI命名ルール
- デプロイ先の制約事項（ランタイムバージョンなど）
変更点4：/compact の定期実行
詳細は次セクションで解説します。
コスト削減の内訳
| 施策 | 削減効果（月額） |
|---|---|
| Effortのデフォルトをmediumに | -$85 |
| Sonnet活用率を75%に | -$60 |
| CLAUDE.mdの最適化 | -$25 |
| /compact の活用 | -$15 |
| 合計 | -$185 |
8. 補足：/compact の活用とコンテキストウィンドウ管理
/compact とは
/compact は、Claude Codeのコンテキストウィンドウに蓄積された会話履歴を要約・圧縮するサブコマンドです。
長い対話セッションでは、コンテキストウィンドウが肥大化し、毎回のリクエストで過去の会話すべてがトークンとして送信されます。これが「何もしていないのにトークンが増えていく」原因です。
使いどころ
# 目安：10往復以上の会話後、または体感でレスポンスが遅くなったら
> /compact
# 特定のトピックに焦点を絞って圧縮することも可能
> /compact 現在のバグ修正に関連する情報だけ残して
効果の実測値
| 状況 | /compact前のコンテキスト | /compact後のコンテキスト | 削減率 |
|---|---|---|---|
| 15往復の対話後 | ~45,000 tokens | ~8,000 tokens | 82% |
| 30往復の対話後 | ~95,000 tokens | ~12,000 tokens | 87% |
特に長時間セッションでは、/compact 一発で次のリクエストのトークン消費が大幅に減少します。
運用ルール
私のチームでは以下を運用ルールにしています。
-
10往復ごとに
/compactを実行する -
タスクの切り替え時には必ず
/compactを実行する - 新規セッションで始められるなら、継続より新規セッションを優先する
まとめ
- Effortのデフォルトはmediumで十分。highを使うのは全タスクの10〜15%（設計・大規模実装）に絞ることで、品質を0.3点しか落とさずにトークン消費を60%削減できる
- タスクの約75%はSonnetで品質スコア4点以上を達成可能。Opusは「複数ファイルにまたがる設計判断」にのみ投入するのがコスト効率最大
- CLAUDE.mdは60〜80行が最適解。「LLMが知らない、このプロジェクト固有の情報」だけに絞り、/compact を定期実行することで、隠れたトークン消費を大幅に抑えられる