メインコンテンツへスキップ
トークンの使用量は単にコストの問題ではありません。フィードバックループの速度とコンテキストウィンドウの制限に関わる問題です。このガイドでは、プロジェクトの最適化、スマートなモデル選択、ワークフローパターンを通じて、より少ないトークンでより多くのことを実現する方法を紹介します。
Using Factory App? These strategies apply to both CLI and Factory App. You can view your project’s readiness score in the Agent Readiness Dashboard.

トークン使用量の理解

トークンは主に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 Flash0.2×大量タスク向けの高速・安価
Droid Core (GLM-4.7)0.25×バルク自動化、単純タスク
Droid Core (Kimi K2.5)0.25×コスト重視の作業、画像サポート
Claude Haiku 4.50.4×素早い編集、ルーチンワーク
Droid Core (GLM-5)0.4×Droid Coreでより高い品質が欲しい場合の新しいオープンソースGLMモデル
GPT-5.1 / GPT-5.1-Codex0.5×実装、デバッグ
GPT-5.2-Codex / GPT-5.3-Codex0.7×Extra High推論による高度なコーディング
Gemini 3 Pro0.8×研究、分析
Gemini 3.1 Pro0.8×より新しいGemini世代による研究、分析
Claude Sonnet 4.51.2×品質/コストのバランス
Claude Opus 4.5複雑な推論、アーキテクチャ
Claude Opus 4.6最新フラッグシップ、Max推論
Claude Opus 4.6 Fast12×より高速な応答に調整された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 ModeShift+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."

使用量の監視

現在のセッションコストを確認

droid
> /cost
これは現在のセッションのトークン使用量を表示します。

時間経過での追跡

使用パターンを確認します:
  1. 各セッション後/cost出力をメモ
  2. 高コストなセッションを特定:何が高コストにしたか?
  3. アプローチを改善:より多くのコンテキスト?異なるモデル?より良いプロンプト?

使用量の警告サイン

これらのパターンに注意してください:
  • 🚩 高い読み取り回数:Droidが過度に探索している(AGENTS.mdコンテキストを追加)
  • 🚩 複数のgrep/search呼び出し:何を探すかが不明確(より具体的に)
  • 🚩 類似の編集を繰り返し:失敗する試行(テスト/リンティングを確認)
  • 🚩 非常に長い会話:スコープクリープ(より小さなタスクに分割)

簡単な改善チェックリスト

即座にトークンを節約するためにこれらを実装してください:
  • IDEプラグインをインストール - コンテキスト収集のツール呼び出しを除去
  • AGENTS.mdを作成 - Droidが事前にビルド/テストコマンドを把握
  • リンティングを設定 - エラーを即座にキャッチ
  • 高速テストコマンド - 同じターンで検証
  • Specモードを使用 - 高コストな誤ったスタートを防止
  • 具体的に指定 - 探索サイクルを削減
  • タスクにモデルを合わせる - 単純な編集にOpusを使わない

トークン予算ガイドライン

一般的なタスクの大まかなガイドライン:
タスク種別典型的なトークン範囲注記
簡単な編集5k-15k単純で具体的な変更
機能実装30k-80kSpecモード計画あり
複雑なデバッグ50k-150k複数回の試行が必要な場合あり
アーキテクチャ計画20k-50k高推論モデル
コードレビュー30k-60kPRサイズに依存
バルクリファクタリング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

次のステップ