ai-agent-cost-optimizer

AI Agent Cost Optimizer

出荷する品質を落とさずに、AI エージェントの支出を削減します。生のトークン数ではなく、タスクを正しく完了するためのコストを最適化します。

有効にするタイミング

• AI コーディングの請求額、トークン使用量、API 推論コスト、またはモデルへの支出が高すぎる場合
• エージェントのワークフローにおけるコンテキストの無駄、リトライループ、キャッシュミスを確認するとき
• 計画、実装、レビュー、またはクリーンアップのタスクに使用するモデルの階層を選ぶとき
• プロンプトキャッシュ、低コストモデル、またはトークン削減に関する主張を評価するとき
• 繰り返し行うワークフローを記録し、今後のエージェントが同じコンテキストを再調査しなくて済むようにするとき

基本原則

モデルとコンテキストのコストは、失敗のコストに合わせます。

誤った回答が高額なやり直し、セキュリティリスク、データ損失、またはアーキテクチャ上の負担につながる可能性がある場合は、より高性能なモデルを使用します。タスクの範囲が限定され、やり直し可能で、テストでカバーされている、または機械的な作業である場合は、より低コストのモデルと小さいコンテキストを使用します。

リトライを増やしたり、重要な根拠を隠したり、コード品質を低下させたりする方法でトークンを節約してはいけません。

コスト監査のワークフロー

1. 支出の内訳を把握する

変更を提案する前に、実際にコストを押し上げている要因を特定します。

• API の支出とサブスクリプションの支出
• 使用中のプロバイダーとモデル
• 最も頻繁に実行されるワークフロー
• 利用可能な場合は、入力、出力、キャッシュされた入力、推論、ツール呼び出しの平均トークン数
• リトライ回数、失敗した実行、人による修正時間
• コストが一部の大規模なワークフローに由来するのか、多数の小規模な呼び出しに由来するのか

使用状況データがない場合は不明として記録し、アクセスできる場合に限り、ローカルの設定、ログ、スクリプト、またはプロバイダーのダッシュボードを確認します。

2. 検証済みの事実と主張を分ける

料金、モデルの提供状況、キャッシュの動作、ベンチマークの順位は、時期によって変わります。具体的な料金を提示したり、モデルをデフォルトとして推奨したりする前に、最新のプロバイダー公式ドキュメントを確認します。

SNS の投稿、ベンチマークのスクリーンショット、ベンダーの宣伝は仮説として扱います。デフォルトのルーティングを変更する前に、ローカルテストで検証します。

3. トークンの無駄を見つける

次のようなよくある無駄を探します。

• 対象を絞ったタスクの内容を把握する前に、大きなファイルやディレクトリを読み込む
• 「念のため」のファイル読み込み
• 有用な情報を抽出した後も、生ログ、ビルド出力、検索結果、テスト結果を保持する
• リトライのたびに同じコンテキストを再送信するツールループ
• キャッシュ可能な、重複したツール定義やプロバイダーの指示
• 短い要約で十分な状態を維持できるのに、長い会話を続ける
• フォーマット、名前変更、リンター修正、抽出、ボイラープレート作成に高価なモデルを使う
• 同じプレフィックスを使う質問を、多数の個別の呼び出しとして行う
• スキル、リファレンス、またはスクリプトに記録すべき環境調査を繰り返す

4. モデルを切り替える前にコンテキストを減らす

まずコンテキストの構成を改善します。

• ファイルを開く前に、シンボル、パス、エラーを検索する
• 質問に答えるのに必要な、最小限の関連箇所を読む
• 変更されにくいルール、スキーマ、ワークフローの指示は、永続的なスキルやリファレンスに保持する
• ツール出力は役目を終えたら要約する
• フェーズが変わったら古くなったコンテキストを破棄する
• 複数の質問で同じコンテキストを共有できる場合は、読み取り専用の調査をまとめる
• 重大なデバッグ、セキュリティ、請求、またはデータ損失の事例では、正確な根拠を保持する

5. キャッシュヒットが発生しやすい構成にする

安定したプレフィックスを設計します。

• 変化するタスクデータより前に、安定した指示、ツール定義、スキーマ、例を配置する
• タイムスタンプ、セッション ID、ユーザー固有の詳細、取得したスニペットは、再利用するプレフィックスに含めない
• 呼び出しごとに安定した指示を書き換えない
• プロバイダーの応答で確認できる場合は、キャッシュ読み取りとキャッシュ書き込みの使用状況を監視する
• キャッシュが機能すると決めつける前に、プロバイダー固有のしきい値、TTL、無効化ルールを確認する

ストリーミングがキャッシュを妨げると一般化してはいけません。キャッシュミスの原因は通常、プレフィックスが不安定であること、プロバイダーやモデルが非対応であること、しきい値、TTL の期限切れ、またはツールやメッセージの構造が変わったことです。

6. タスクのリスクに応じて振り分ける

この基準を出発点として使用します。

タスク	デフォルトのティア	引き上げる条件
アーキテクチャ、セキュリティ上重要なレビュー、不可逆な操作、影響範囲の大きいリファクタリング	プレミアム	すでにプレミアムです。レビューまたはテストを追加します
機能の実装、デバッグ、テストの作成、通常のリファクタリング	ワークホース	繰り返し失敗する、テストが不十分、またはアーキテクチャ上の隠れたリスクがある場合
リント、フォーマット、名前変更、単純な抽出、ボイラープレート、分類	ユーティリティまたはローカル	出力に繊細な判断が必要、または本番環境の挙動に影響する場合
長時間のエージェント型ループ	コンテキスト予算を厳格に設定したワークホース	ループで不明確な設計判断に直面する、または失敗が続く場合
未知のコードベースの調査	初期マップ作成にはワークホースまたはプレミアム、その後の範囲を限定したフォローアップには低価格のティア	アーキテクチャが不明確、またはリスクが高い場合

広範なリーダーボードの主張よりも、ローカルでの評価を優先します。安価なモデルでも再試行回数が倍になれば、プレミアムモデルより高くつく可能性があります。

7. 意図的にバッチ処理と分割を行う

関連する小さな質問が同じコンテキストを共有している場合は、まとめて1回の呼び出しで処理します。広範なタスクは、各サブタスクを独立したコンテキストで実行し、簡潔な結果を返せる場合に、独立したサブタスクへ分割します。

単純な作業を並列化するためだけに余分なエージェントを起動するのは避けます。コンテキストの分離や所要時間の短縮によってオーバーヘッドを正当化できない限り、マルチエージェントシステムではトークン消費が増える可能性があります。

8. 繰り返し行うワークフローを記録する

ワークフローが繰り返し実行され、安定している場合は、エージェントが何度も再発見しなくて済むように記録します。

• 複数手順にわたる手続き的な知識について、焦点を絞ったスキルを作成する
• 長い背景資料は、必要な場合にのみ読み込むリファレンスへ移動する
• 壊れやすい、または繰り返し行う変換には、決定論的なスクリプトを作成する
• 環境に関する情報は、検証日とともにリポジトリのメモリまたはプロジェクトドキュメントに記録する

発見に至るまでの探索経路ではなく、最終的に機能するワークフローを記録します。

9. 結果を測定する

タスク単位の指標を使って、変更前後を比較します。

• 完了したタスクあたりのコスト
• 入力、出力、キャッシュされた入力、およびツール呼び出しのトークン数
• キャッシュヒット率
• 再試行回数
• 所要時間
• テスト合格率またはレビューでの不具合率
• 人による修正時間

削減効果は、測定した範囲として報告します。変更前と変更後の両方が把握できていない限り、「80%削減」のような裏付けのない主張は避けます。

出力形式

ワークフローを監査する際は、次の形式で回答します。

1. 主な漏れ - 支出への影響が大きいと考えられる順
2. 低リスクの修正 - 品質を損なうリスクなしにコストを削減する変更
3. 振り分けの変更 - モデルティアの変更と引き上げ条件
4. キャッシュ計画 - 安定したプレフィックス、変動するサフィックス、注視する指標
5. 記録候補 - スキル、リファレンス、またはスクリプトにする価値のあるワークフロー
6. 未検証の主張 - 最新の情報源で確認が必要な価格やモデル品質に関する主張

ガードレール

• 最新の価格情報とローカルでの品質を示す根拠がない限り、特定のプロバイダーやモデルをデフォルトとして推奨しません
• 正確性、安全性、コンプライアンス、監査可能性に必要なコンテキストを削除しません
• 再試行やレビューの負担が増える場合は、機械的なトークン数の削減を優先しません
• プロンプトキャッシュを万能なものと見なさず、利用状況のデータでキャッシュヒットを検証します
• 変動する価格表を、長期的に有効なスキルの内容として記録しません
• リポジトリで確立されたワークフローに反する編集の近道を使いません

統合

関連するスキル：

• context-optimization（references/fundamentals.md） - コンテキストを消費する要素を理解する
• context-optimization - 圧縮、マスキング、キャッシュ、分割を適用する
• multi-agent-patterns - サブエージェントによるコンテキスト分離がオーバーヘッドに見合うかを評価する
• tool-design - ツールの曖昧さと応答の冗長さを減らす
• skill-capture - 繰り返し行うワークフローを再利用可能なスキルとして保存する