メインコンテンツへスキップ
Token使用量はコストだけの問題ではありません。フィードバックループの速度とコンテキストウィンドウの制限にも関わります。このガイドでは、プロジェクトの最適化、賢いモデル選択、ワークフローパターンを通じて、より少ないTokenでより多くのことを実現する方法を示します。
**Factory Appを使用していますか?**これらの戦略はDroid CLIとFactory Appの両方に適用されます。Agent Readinessダッシュボードでプロジェクトの準備状況スコアを確認できます。

Token使用量の理解

Tokenは主に3つの領域で消費されます:
高いトークン使用量は通常以下を意味します:
  • 過度な探索(不明確な指示)
  • 複数回の試行(コンテキスト不足またはテストの失敗)
  • 冗長な出力(フォーマット制約なし)

効率性のためのプロジェクトセットアップ

最大のトークン節約は、無駄なサイクルを防ぐプロジェクト設定から生まれます。

1. 高速で信頼性の高いテスト

遅い、または不安定なテストは、トークンの無駄の最大の原因です。各リトライは完全なレスポンスサイクルのコストがかかります。
テストの特徴トークンへの影響
高速テスト(30秒未満)Droidは変更を即座に検証
低速テスト(2分超)Droidは検証をスキップするか、待機中にコンテキストを無駄にする可能性
不安定なテスト誤った失敗がデバッグサイクルを引き起こす
テストなしDroidは変更を検証できず、より多くのやり取りが発生
アクション項目:

2. リンティングと型チェック

Droidがエラーを即座に検出できる場合、あなたからの報告を待つのではなく、同じターンで修正します。

3. 明確なプロジェクト構造

Droidがトークンを無駄に消費して探索しないよう、ファイル構成を文書化してください:

エージェント準備チェックリスト

エージェント準備レポートは、トークン効率に直接影響する基準に対してプロジェクトを評価します。

高影響基準

基準トークンへの影響重要な理由
リンター設定🟢 高エラーを即座にキャッチし、デバッグサイクルを削減
型チェッカー🟢 高実行時エラーを防ぎ、コードをより明確に
実行可能なユニットテスト🟢 高同じターンでの検証
AGENTS.md🟢 高事前のコンテキスト、探索の削減
ビルドコマンドドキュメント🟡 中推測不要、失敗の試行を削減
依存関係の固定🟡 中再現可能なビルド
プリコミットフック🟡 中自動品質強制
準備レポートを実行してギャップを特定してください:

モデル選択戦略

異なるモデルには異なるコスト倍率と機能があります。タスクに応じてモデルを選択しましょう:

コスト倍率

現在のモデル倍率については利用可能なモデルを参照してください。

タスク別モデル選択

推論努力の影響

推論レベルが高い = より多くの「思考」トークンを使用するが、多くの場合再試行回数は減る。
推論使用タイミングトークンのトレードオフ
オフ/なしシンプルで明確なタスクターンあたり最少、より多くのターンが必要な場合あり
標準的な実装良いバランス
複雑なロジック、デバッグターンあたり高め、再試行回数は少なめ
アーキテクチャ、分析ターンあたり最高、初回試行の成功率が最も高い
経験則: 初回試行を間違えた場合の修正コストが高いタスクでは、より高い推論レベルを使用する。
混合モデルを設定して、計画と実装で異なるモデルを自動的に使用できます。設定については混合モデルを参照してください。

効率性のためのワークフローパターン

パターン1: 複雑な作業のための仕様モード

実装前の計画に仕様モードShift+Tabまたは/spec)を使用します。
以下のようなタスクには、Specモード(Shift+Tabまたは/spec)を使用してください:
  • 2つ以上のファイルに触れる
  • 既存のパターンの理解が必要
  • 要件が不明確
  • セキュリティに敏感

パターン2: コンテキストのためのIDEプラグイン

IDEプラグインがない場合、Droidはコンテキストを理解するためにファイルを読む必要があります:
IDE プラグインを使用すると、コンテキストが即座に利用できます:

パターン3: 一般的なものよりも具体的なもの

→ Droidは複数のファイルを読み取ってバグを見つけ、さまざまな可能性を探る
→ Droidが直接イシューに移動します

パターン4: 類似作業のバッチ処理


トークンの無駄遣いを減らす

よくある無駄遣いパターン

パターン原因修正方法
複数回の探索サイクル不明確な要件事前に具体的に指定する
ファイルの繰り返し読み込みIDEコンテキストの不足IDEプラグインをインストールする
失敗した試行テスト/リンティングなし検証ツールを追加する
冗長な説明フォーマット制約なし簡潔な出力を求める
間違ったアーキテクチャコンテキストの不足Spec Modeを使用する

フォーマット制約

冗長性を減らすため、特定の出力フォーマットを要求する:

使用量の監視

現在のセッション費用を確認

現在のセッションのトークン使用量を表示します。

時間経過の追跡

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

使用量の警告サイン

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

即効性チェックリスト

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

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

一般的なタスクの大まかなガイドライン:
タスクタイプ典型的なトークン範囲備考
簡単な編集5k-15kシンプルで具体的な変更
機能実装30k-80kSpec Modeプランニング込み
複雑なデバッグ50k-150k複数回の試行が必要な場合
アーキテクチャ計画20k-50k高推論モデル
コードレビュー30k-60kPRサイズに依存
一括リファクタリング50k-200k多数のファイル、効率的なモデルを使用
これらの範囲を大幅に超えている場合は、上記の無駄なパターンを確認してください。

次のステップ

セットアップチェックリスト

パワーユーザー設定を完了する

準備状況レポート

プロジェクトのAI対応状況を評価する