トークンの使用量は単にコストの問題ではありません。フィードバックループの速度とコンテキストウィンドウの制限に関わる問題です。このガイドでは、プロジェクトの最適化、スマートなモデル選択、ワークフローパターンを通じて、より少ないトークンでより多くのことを実現する方法を紹介します。
トークン使用量の理解
トークンは主に3つの領域で消費されます:
┌──────────────────────────────────────────────────────────┐
│ Token Consumption │
├────────────────┬────────────────┬────────────────────────┤
│ Context │ Tool Calls │ Model Output │
│ (Input) │ (Overhead) │ (Response) │
├────────────────┼────────────────┼────────────────────────┤
│ • AGENTS.md │ • Read files │ • Explanations │
│ • Memories │ • Grep/search │ • Generated code │
│ • Conversation │ • Execute cmds │ • Analysis │
│ • File content │ • Each retry │ • Thinking tokens │
└────────────────┴────────────────┴────────────────────────┘
高いトークン使用量の典型的な原因:
- 過度な探索(不明確な指示)
- 複数回の試行(コンテキストの不足や失敗するテスト)
- 冗長な出力(フォーマット制約なし)
効率的なプロジェクトセットアップ
最大のトークン節約は、無駄なサイクルを防ぐプロジェクト設定から生まれます。
1. 高速で信頼性の高いテスト
Slow or flaky tests are the #1 cause of wasted tokens. Each retry costs a full response cycle.
| テストの特徴 | トークンへの影響 |
|---|
| 高速テスト(30秒未満) | Droidが変更を即座に検証 |
| 低速テスト(2分超) | Droidが検証をスキップするか、待機中にコンテキストを無駄にする可能性 |
| 不安定なテスト | 誤った失敗がデバッグサイクルを引き起こす |
| テストなし | Droidが変更を検証できず、やりとりが増加 |
アクション項目:
## In your AGENTS.md
## Testing
- Run single file: `npm test -- path/to/file.test.ts`
- Run fast smoke tests: `npm test -- --testPathPattern=smoke`
- Full suite takes ~3 minutes, use `--bail` for early exit on failure
2. リンティングと型チェック
Droidがエラーを即座にキャッチできれば、報告を待つ代わりに同じターンで修正できます。
## In your AGENTS.md
## Validation Commands
- Lint (auto-fix): `npm run lint:fix`
- Type check: `npm run typecheck`
- Full validation: `npm run validate` (lint + typecheck + test)
Always run `npm run lint:fix` after making changes.
3. 明確なプロジェクト構造
ファイル構成を文書化して、Droidが探索でトークンを無駄にしないようにします:
## In your AGENTS.md
## Project Structure
- `src/components/` - React components (one per file)
- `src/hooks/` - Custom React hooks
- `src/services/` - API and business logic
- `src/types/` - TypeScript type definitions
- `tests/` - Test files mirror src/ structure
When adding a new component:
1. Create component in `src/components/ComponentName/`
2. Add index.ts for exports
3. Add ComponentName.test.tsx in same directory
エージェント対応チェックリスト
Agent Readiness Reportは、トークン効率に直接影響する基準に対してプロジェクトを評価します。
高影響度の基準
| 基準 | トークン影響度 | 重要な理由 |
|---|
| Linter設定 | 🟢 高 | エラーを即座にキャッチ、デバッグサイクルなし |
| 型チェッカー | 🟢 高 | ランタイムエラーを防ぎ、コードをより明確に |
| 実行可能な単体テスト | 🟢 高 | 同じターンで検証 |
| AGENTS.md | 🟢 高 | 事前にコンテキスト提供、探索減少 |
| ビルドコマンド文書化 | 🟡 中 | 推測不要、失敗する試行の削減 |
| 依存関係の固定 | 🟡 中 | 再現可能なビルド |
| Pre-commitフック | 🟡 中 | 自動品質保証 |
準備状況レポートを実行してギャップを特定します:
droid
> /readiness-report
モデル選択戦略
異なるモデルには異なるコスト倍率と機能があります。タスクにモデルを合わせます:
コスト倍率
| モデル | 倍率 | 最適用途 |
|---|
| Droid Core (MiniMax M2.5) | 0.12× | 推論サポート付きの最安価オプション |
| Gemini 3 Flash | 0.2× | 大量タスク向けの高速・安価 |
| Droid Core (GLM-4.7) | 0.25× | バルク自動化、単純タスク |
| Droid Core (Kimi K2.5) | 0.25× | コスト重視の作業、画像サポート |
| Claude Haiku 4.5 | 0.4× | 素早い編集、ルーチンワーク |
| Droid Core (GLM-5) | 0.4× | Droid Coreでより高い品質が欲しい場合の新しいオープンソースGLMモデル |
| GPT-5.1 / GPT-5.1-Codex | 0.5× | 実装、デバッグ |
| GPT-5.2-Codex / GPT-5.3-Codex | 0.7× | Extra High推論による高度なコーディング |
| Gemini 3 Pro | 0.8× | 研究、分析 |
| Gemini 3.1 Pro | 0.8× | より新しいGemini世代による研究、分析 |
| Claude Sonnet 4.5 | 1.2× | 品質/コストのバランス |
| Claude Opus 4.5 | 2× | 複雑な推論、アーキテクチャ |
| Claude Opus 4.6 | 2× | 最新フラッグシップ、Max推論 |
| Claude Opus 4.6 Fast | 12× | より高速な応答に調整されたOpus 4.6 |
タスクベースのモデル選択
Simple edit, formatting → Haiku 4.5 (0.4×)
Implement feature from spec → GPT-5.1-Codex (0.5×)
Debug complex issue → Sonnet 4.5 (1.2×)
Architecture planning → Opus 4.6 (2×) or Opus 4.5 (2×)
Bulk file processing → Droid Core (GLM-4.7 at 0.25× or GLM-5 at 0.4×)
推論エフォートの影響
高い推論 = より多くの「思考」トークンですが、多くの場合再試行が少なくなります。
| 推論 | 使用時期 | トークンのトレードオフ |
|---|
| オフ/なし | 単純で明確なタスク | ターン当たり最低、より多くのターンが必要な可能性 |
| 低 | 標準実装 | 良いバランス |
| 中 | 複雑なロジック、デバッグ | ターン当たり高、再試行少 |
| 高 | アーキテクチャ、分析 | ターン当たり最高、初回試行の成功率最高 |
経験則: 最初の試行を間違えると修正が高くつくタスクには、高い推論を使用します。
Configure mixed models to automatically use different models for planning vs implementation. See Mixed Models for setup.
効率的なワークフローパターン
パターン1:複雑な作業でのSpecモード
実装前の計画にSpecification Mode(Shift+Tabまたは/spec)を使用します。
Specモードなし:
Turn 1: Start implementing → wrong approach → wasted tokens
Turn 2: Undo and try different approach → more tokens
Turn 3: Finally get it right
Total: 3 turns of implementation tokens
Specモードあり:
Turn 1: Plan with exploration → correct approach identified
Turn 2: Implement correctly
Total: 1 turn of planning + 1 turn of implementation
Use Spec Mode (Shift+Tab or /spec) for any task that:
- Touches more than 2 files
- Requires understanding existing patterns
- Has unclear requirements
- Is security-sensitive
パターン2:コンテキスト用IDEプラグイン
IDEプラグインなしでは、Droidはコンテキストを理解するためにファイルを読む必要があります:
Read file A → Read file B → Read file C → Understand context → Work
(4 tool calls before actual work)
IDEプラグインありでは、コンテキストが即座に利用可能:
Work (IDE provides open files, errors, selection)
(0 extra tool calls for context)
パターン3:一般的より具体的に
高コストなプロンプト:
"Fix the bug in the auth module"
→ Droidはバグを見つけるために複数のファイルを読み、異なる可能性を探索
効率的なプロンプト:
"Fix the timeout bug in src/auth/session.ts line 45 where the session expires after 5 minutes instead of 24 hours"
→ Droidは直接問題に向かう
パターン4:類似の作業をバッチ処理
高コスト:
Turn 1: "Add logging to userService"
Turn 2: "Add logging to orderService"
Turn 3: "Add logging to paymentService"
(3 turns, context rebuilt each time)
効率的:
Turn 1: "Add structured logging to all services in src/services/. Use the pattern from src/lib/logger.ts. Services: user, order, payment."
(1 turn, pattern established once)
トークンの無駄の削減
一般的な無駄パターン
| パターン | 原因 | 修正方法 |
|---|
| 複数の探索サイクル | 不明確な要件 | 事前に具体的に指定 |
| 重複するファイル読み取り | IDEコンテキストの不足 | IDEプラグインをインストール |
| 失敗する試行 | テスト/リンティングなし | 検証ツールを追加 |
| 冗長な説明 | フォーマット制約なし | 簡潔な出力を要求 |
| 間違ったアーキテクチャ | コンテキストの不足 | Specモードを使用 |
フォーマット制約
冗長性を減らすために特定の出力フォーマットを要求します:
"Add the feature. Return only the changed code, no explanations unless something is unclear."
"Review this code. Format: bullet list of issues only, no preamble."
"Debug this test failure. Show me the fix, then explain in 2-3 sentences."
使用量の監視
現在のセッションコストを確認
これは現在のセッションのトークン使用量を表示します。
時間経過での追跡
使用パターンを確認します:
- 各セッション後、
/cost出力をメモ
- 高コストなセッションを特定:何が高コストにしたか?
- アプローチを改善:より多くのコンテキスト?異なるモデル?より良いプロンプト?
使用量の警告サイン
これらのパターンに注意してください:
- 🚩 高い読み取り回数:Droidが過度に探索している(AGENTS.mdコンテキストを追加)
- 🚩 複数のgrep/search呼び出し:何を探すかが不明確(より具体的に)
- 🚩 類似の編集を繰り返し:失敗する試行(テスト/リンティングを確認)
- 🚩 非常に長い会話:スコープクリープ(より小さなタスクに分割)
簡単な改善チェックリスト
即座にトークンを節約するためにこれらを実装してください:
トークン予算ガイドライン
一般的なタスクの大まかなガイドライン:
| タスク種別 | 典型的なトークン範囲 | 注記 |
|---|
| 簡単な編集 | 5k-15k | 単純で具体的な変更 |
| 機能実装 | 30k-80k | Specモード計画あり |
| 複雑なデバッグ | 50k-150k | 複数回の試行が必要な場合あり |
| アーキテクチャ計画 | 20k-50k | 高推論モデル |
| コードレビュー | 30k-60k | PRサイズに依存 |
| バルクリファクタリング | 50k-200k | 多くのファイル、効率的なモデルを使用 |
これらの範囲を大幅に超えている場合は、上記の無駄パターンを確認してください。
まとめ:トークン効率的なワークフロー
1. Set up your project
└─ AGENTS.md with commands
└─ Fast tests
└─ Linting configured
└─ IDE plugin installed
2. Start each task right
└─ Use Spec Mode for complex work
└─ Be specific about the goal
└─ Reference existing patterns
3. Choose the right model
└─ Simple → Haiku/Droid Core
└─ Standard → Codex/Sonnet
└─ Complex → Opus (with reasoning)
4. Monitor and adjust
└─ Check /cost periodically
└─ Identify expensive patterns
└─ Refine your approach
次のステップ