コスト最適化
モデル選択、キャッシュ、トークン管理の効率的な最適化方法。
学ぶこと
AIコーディングツールを大規模に使用すると、実際のコストが発生します。すべてのAPI呼び出しはトークンを消費し、トークンにはお金がかかります。しかし、コスト最適化とはすべてに最も安いモデルを使うことではありません。各タスクに適切なモデルを使うことです。
このセッションを終えると、以下を理解できるようになります：
- AIアシスト開発のコスト要因
- 各タスクに適したモデルの選択方法
- モデルカスケードパターン
- トークン管理とコンテキスト効率化
- 冗長な作業を削減するキャッシュ戦略
課題
すべてのタスクに最も高性能なモデルを使用する開発者は、単純なファイル検索、ディレクトリ一覧、設定ファイルの読み取りを含めて、大幅に過剰支出しています。
Typical session breakdown:
5 file searches (simple) ← Haiku could do this
3 code explorations (moderate) ← Sonnet is ideal
1 architecture decision (complex) ← Opus is worth it
10 small edits (simple) ← Sonnet handles fine
2 test investigations (moderate) ← Sonnet is ideal
All 21 ops with Opus → expensive
5 Haiku + 15 Sonnet + 1 Opus → same quality, fraction of costこの差は数日、数週間にわたり数百のセッションで複利的に積み重なります。
仕組み
コスト要因の理解
┌──────────────────────────────────────────────────┐
│ Cost Drivers │
│ │
│ 1. INPUT TOKENS │
│ System prompt, CLAUDE.md, conversation │
│ history, file contents, tool outputs │
│ │
│ 2. OUTPUT TOKENS │
│ Reasoning, responses, tool call arguments, │
│ generated code │
│ │
│ 3. MODEL CHOICE │
│ Haiku (lowest) → Sonnet (moderate) → Opus │
│ │
│ 4. NUMBER OF API CALLS │
│ Each tool use = another round trip │
│ Each call re-sends the full context │
│ │
└──────────────────────────────────────────────────┘重要な詳細：入力トークンはすべてのAPI呼び出しで送信されます。 コンテキストが50,000トークンで、エージェントが20回のツール呼び出しを行う場合、50,000トークンが20回送信されます。コンテキストを軽量に保つことは、すべての呼び出しで利益をもたらします。
モデル選択戦略
┌─────────────────────────────────────────────────┐
│ Model Selection Guide │
│ │
│ HAIKU (fast, lowest cost) │
│ ├── File search and exploration │
│ ├── Listing directory contents │
│ ├── Simple text transformations │
│ ├── Reading and summarizing files │
│ └── Pattern matching across codebase │
│ │
│ SONNET (balanced, moderate cost) │
│ ├── Writing and modifying code │
│ ├── Debugging and fixing errors │
│ ├── Refactoring, writing tests │
│ └── Most day-to-day coding tasks │
│ │
│ OPUS (powerful, highest cost) │
│ ├── Architecture decisions │
│ ├── Complex multi-file refactors │
│ ├── Resolving subtle bugs │
│ └── Critical code that must be correct │
│ │
└─────────────────────────────────────────────────┘モデルカスケードパターン
最も安いモデルから開始し、必要な場合のみエスカレーションします：
┌──────────────────────────────────────────────────┐
│ Model Cascade │
│ │
│ Task arrives │
│ │ │
│ ▼ │
│ Try with HAIKU │
│ ├── Quality OK? → Done (lowest cost) │
│ │ │
│ ▼ │
│ Escalate to SONNET │
│ ├── Quality OK? → Done (moderate cost) │
│ │ │
│ ▼ │
│ Escalate to OPUS → Done (highest quality) │
│ │
└──────────────────────────────────────────────────┘実際には、個々のタスクごとにカスケードするのではなく、タスクカテゴリに基づいてモデルを事前割り当てします。カスケードは、どのタスクにどのモデルを使うかを決める際のメンタルモデルです。
トークン管理
コンテキストを軽量に保つことで、後続のすべてのAPI呼び出しのコストが削減されます：
1. TARGETED FILE READS
Bad: "Read all files in src/" → 50 files, 40K tokens
Good: "Read src/auth/middleware.ts" → 1 file, 800 tokens
2. SPECIFIC SEARCHES
Bad: Search "config" (200 hits)
Good: Search "databaseConfig" in src/db/ (3 hits)
3. SUBAGENT ISOLATION
Bad: Explore in main context → 20 reads in history
Good: Spawn explore subagent → only summary returned
4. PROACTIVE COMPACTION
Bad: Let context fill to 95%
Good: Use /compact when switching tasksキャッシュ戦略
System Prompt Caching:
First call: 3000 tokens → CACHE MISS → full rate
Later calls: 3000 tokens → CACHE HIT → reduced rate
Avoid Re-Reading:
Read file once, keep info in conversation. Second read = wasted tokens.
Batch Related Reads:
Bad: Read A, B, C sequentially (3 round trips)
Good: Read A, B, C in parallel (1 round trip)
Lean CLAUDE.md:
Bloated: 5000 tokens × every API call
Lean: 800 tokens × every API call
Savings: 4200 tokens × every call in sessionサブエージェントのモデル選択
この1つの決定だけで、探索中心のワークフローのコストを50-70%削減できます：
Exploration → Haiku ("Find all test files", "List API routes")
Implementation → Sonnet ("Write unit test", "Refactor to async/await")
Architecture → Opus ("Design data model", "Evaluate trade-offs")重要なポイント
コスト最適化とは最も安いモデルを使うことではありません。各タスクに適切なモデルを使うことであり、多くの場合、異なる価格帯のモデルを組み合わせることを意味します。
検索に Haiku、コーディングに Sonnet、アーキテクチャに Opus を使用するワークフローは、すべてに Opus を使用するのと同じ品質の出力を、はるかに低いコストで生み出します。
2つ目のポイント：コンテキストサイズは乗数です。 フルコンテキストはすべてのAPI呼び出しで送信されるため、コンテキストを50Kから20Kトークンに削減すると、後続のすべての呼び出しで30Kトークンが節約されます。30回の呼び出しセッションでは、900Kトークンの節約になります。
これが、以前のセッションで学んだパターン --- サブエージェント分離（セッション4）、コンテキストコンパクション（セッション6）、ターゲットを絞ったツール使用 --- が品質だけでなく、コストに直接関係する理由です。
ハンズオン
コスト最適化されたワークフローの設定
ステップ1：タスクをカテゴリ分けする
Feature: Add search functionality
Exploration (Haiku):
- Find existing search-related code
- List database tables
- Check package.json for search libraries
Implementation (Sonnet):
- Write search API endpoint
- Create search index
- Build search UI component, write tests
Architecture (Opus):
- Decide: full-text vs fuzzy match vs external service
- Design search index schemaステップ2：CLAUDE.md を軽量に保つ
# Expensive (2000 tokens):
This project is a web application built with React 18,
TypeScript 5.3, Tailwind CSS 3.4, Prisma ORM 5.x...
[extensive descriptions, standards, deployment procedures]
# Lean (400 tokens):
Tech: React 18, TypeScript, Tailwind, Prisma, PostgreSQL
Style: Prettier defaults, no semicolons
Test: Vitest, run with "pnpm test"
Build: "pnpm build", deploys via GitHub Actions
Key dirs: src/api/, src/components/, src/db/ステップ3：コストと品質のトレードオフを理解する
SAVE money on: INVEST money on:
├── File search ├── Security-critical code
├── Directory listing ├── Data migration logic
├── Running commands ├── Architecture decisions
├── Boilerplate generation ├── Complex debugging
└── Repetitive edits └── API design経験則：間違えた場合のコストが正しく行った場合のコストより大きいなら、最良のモデルを使いましょう。タスクが機械的で簡単に検証できるなら、最も安いモデルを使いましょう。
変更点まとめ
| 最適化なし | コスト最適化済み |
|---|---|
| すべてに1つのモデル | タスクごとに適切なモデル |
| 大きな CLAUDE.md（2000+ トークン） | 軽量な CLAUDE.md（500 トークン未満） |
| ディレクトリ内の全ファイルを読む | ターゲットを絞った具体的な読み取り |
| メインコンテキストで探索 | Haiku サブエージェントで探索 |
| コンテキストが膨張して再送信 | コンテキストを軽量に保ち、呼び出しごとのコストを削減 |
| トークンコストの意識なし | モデルとコンテキストの意識的な選択 |
次のセッション
セッション22ではHuman-in-the-Loopを扱います。AIがルーチンタスクを自律的に実行しつつ、重要な判断では人間の承認を得るために一時停止する、スピードと安全性のバランスを取るワークフロー設計の方法を学びます。