AI エージェントのコストの最適化: トークンの使用とキャッシュ

AI エージェントの運用コストは、驚くほど急速に管理可能なコストから憂慮すべきレベルにまで拡大します。 1 日に 10 件のトランザクションを処理するエージェントは低コストです。同じエージェントが 1 日あたり 5,000 件のトランザクションを処理し、各トランザクションに大きなコンテキスト ウィンドウで 3 ～ 4 回の LLM 呼び出しが必要になると、毎月数千ドルの API コストが発生する可能性があります。これは元の ROI モデルには存在しなかったコストです。

実稼働規模の AI 導入では、コストの最適化はオプションではありません。それは、プラスの ROI をもたらすエージェントと、ROI を損なうエージェントの違いです。このガイドでは、出力品質を損なうことなく、一般的な OpenClaw 導入でコストを 40 ～ 70% 削減する実践的な戦略について説明します。

重要なポイント

• トークンの最適化 (即時圧縮、コンテキスト プルーニング) により、品質を損なうことなく API コストを 25 ～ 40% 削減します
• セマンティック キャッシュにより、繰り返しまたは同様のリクエストに対する LLM 呼び出しが排除され、多くのワークロードでコストが 30 ～ 60% 削減されます。
• モデル ルーティングでは、単純なタスクには安価なモデルを使用し、必要な場合にのみ高価なモデルを使用します
• プロンプト キャッシュ (プロバイダーから利用可能な場合) により、反復的なシステム プロンプトに対する入力トークンのコストが削減されます。
• バッチ処理により、大容量で時間に依存しないワークロードの呼び出しごとのオーバーヘッドが削減されます。
• ワークフローごとのアトリビューションによるコスト監視により、最もコストのかかるエージェントの動作を特定します
• ストリーミングにより、総コストを増加させることなく、ユーザー対応エージェントの最初のトークンまでの待ち時間が短縮されます。
• 包括的なコスト最適化戦略により、通常、最適化されていない展開と比較して、LLM の総支出が 45 ～ 65% 削減されます。

---

AI エージェントのコスト要因を理解する

コストを最適化する前に、何がコストを最適化するのかを理解してください。 LLM API のコストは主にトークンの消費量に基づいています。

入力トークン: モデルに送信されるすべてのトークン (システム プロンプト、ユーザー メッセージ、取得されたコンテキスト (RAG チャンク)、会話履歴、およびサンプル (少数のショット)) にはコストがかかります。現在のフロンティア モデルでは、入力トークンのコストは通常​​、出力トークンのコストより 2 ～ 5 倍低くなります。

出力トークン: 応答でモデルによって生成されたトークン。詳細な出力はコストが高くなります。推論のステップ (思考の連鎖) は、直接の回答よりもコストがかかります。 JSON に多くのフィールドがある場合、構造化された JSON 出力は散文よりもコストが高くなります。

通話量: すべての LLM 通話には最低コストが設定されています。タスクごとに 5 つの LLM 呼び出しを行うマルチステップ エージェントのコストは、単一呼び出しエージェントの 5 倍になりますが、より良い結果が得られる可能性があります。重要なのは、不要な通話をなくすことです。

モデルの選択: モデル間のコスト差は非常に大きくなります。 Claude 3 Haiku のトークンあたりのコストは、Claude 3 Opus の約 50 分の 1 です。 GPT-4o のコストは GPT-4o mini の約 15 倍です。あらゆるタスクにフロンティア モデルを使用することが、不必要なコストの最も一般的な原因です。

現実的なコスト シナリオ:

エージェントは 1 日あたり 1,000 件のカスタマー サービス チケットを処理します。 各チケットには次のものが必要です。

• システムプロンプト: 800 トークン
• 取得したコンテキスト: 1,200 トークン
• チケット内容: 400トークン
• 総投入量: 2,400 トークン
• 応答: 600 トークン

Claude 3.5 Sonnet の使用 (入力 $3/M、出力 $15/M):

• 1 日あたりのコスト: 1,000 × [(2,400 × 3 ドル/月) + (600 × 15 ドル/月)] = 16.20 ドル/日 = 486 ドル/月

最適化 (このガイドに示されている) を使用すると、これは月額 150 ～ 200 ドルに下がり、60% の削減になります。

---

即時圧縮とトークン削減

システムプロンプトの最適化

システム プロンプトはリクエストごとに送信されます。情報を失わずに 800 トークンに圧縮できる 2,000 トークンの肥大化したシステム プロンプトは、入力トークンに対して必要な 2.5 倍の料金を支払っています。

テクニック:

冗長性の削除: 複数の場所で再説明されている情報については、システム プロンプトを確認してください。統合します。

圧縮された言語を使用する: 会話的な前文は避けてください。比較してください:

Verbose (47 トークン): 「あなたは、契約書をレビューするのが得意な、役に立つアシスタントです。あなたの仕事は、契約書を注意深く読み、当社にとってリスクとなる可能性のある条項を特定することです。」

圧縮 (23 トークン): 「あなたは契約リスク アナリストです。顧客企業に対するリスクを表す条項を特定してください。」

圧縮バージョンでは同じ命令が伝えられます。 LLM は単語数ではなく、意味的な内容に応答します。

構造化された書式設定を使用する: 番号付きリストと箇条書きは、段落よりも情報を密に伝えます。

少数ショットを使用する場合は、システム プロンプトからサンプルを削除します。 システム プロンプトとユーザー メッセージの両方にサンプルがある場合は、二重に料金を支払うことになります。 1 つの場所に統合します。

システム プロンプトの長さを定期的に監査する: チームが古い指示を削除せずに時間の経過とともに指示を追加すると、システム プロンプトが長くなる傾向があります。四半期ごとのレビューでは、通常、システム プロンプト コンテンツの 20 ～ 30% が削除または圧縮される可能性があることがわかります。

コンテキストウィンドウの管理

RAG (Retrieval Augmented Generation) の検索は、知識集約型エージェントにとって最大のコスト要因の 1 つです。取得された各チャンクは入力トークンです。最適化されていない RAG は、必要以上のコンテキストを頻繁に取得します。

チャンク サイズの最適化: 大量に取得された小さいチャンク (256 ～ 512 トークン) は、多くの場合、事実に基づく質問応答において、大きいチャンク (1,000 以上のトークン) よりも優れたパフォーマンスを発揮します。大きなチャンク内の無関係なパッセージは取得されないため、小さなチャンクの方がコストも安くなります。

取得数の調整: エージェントがクエリごとに 10 チャンクを取得するが、常に上位 2 ～ 3 の情報のみを使用する場合は、取得数を減らします。取得されたどのチャンクがエージェント出力で実際に参照されるかを監視します。

関連性フィルタリング: 関連性スコアのしきい値を適用します。しきい値を超える取得されたチャンクのみをコンテキストに含めます。関連性の低いチャンクは、品質を向上させることなくコストを増加させます。

会話履歴のプルーニング: マルチターン エージェントの場合、会話履歴はターンごとに増加します。古いターンは関連性が低いことがよくあります。要約戦略を実装します。8 ～ 10 ターン後に、完全なターンバイターン履歴を保持するのではなく、初期の会話を圧縮された要約 (200 ～ 300 トークン) に要約します。

def manage_conversation_history(messages: list, max_tokens: int = 2000) -> list:
    """Prune conversation history to stay within token budget"""
    # Always keep system message and last N user/assistant turns
    if count_tokens(messages) <= max_tokens:
        return messages

    # Summarize early conversation if too long
    early_messages = messages[1:-6]  # Exclude system + recent 3 turns
    summary = summarize_conversation(early_messages)

    return [
        messages[0],  # System message
        {"role": "user", "content": f"[Earlier conversation summary: {summary}]"},
        *messages[-6:]  # Recent 3 turns
    ]

---

セマンティック キャッシュ

セマンティック キャッシュは、反復的なクエリを処理するエージェントにとって最も大きな影響を与えるコスト最適化です。 LLM 呼び出しの結果を保存し、同一ではない場合でも、意味的に類似した後続のリクエストに対してキャッシュされた結果を返します。

セマンティック キャッシュの仕組み

1. LLM 呼び出しが行われると、入力 (プロンプト + コンテキスト) の埋め込みベクトルを計算します。
2. 現在の入力とのベクトル類似性が高い保存された結果をキャッシュで検索します。
3. 類似性がしきい値を超えた場合、キャッシュされた結果を返します (LLM 呼び出しなし)。
4. そうでない場合は、LLM 呼び出しを実行し、結果をその埋め込みとともに保存します

重要な洞察: 現実世界のリクエストの多くは、テキスト的には同一ではない場合でも、意味的には似ています。 「過去 30 日以内に注文した商品の返品ポリシーは何ですか?」 「3週間前に注文したものを返品できますか?」言葉は違いますが、同じ質問です。セマンティック キャッシュは、最初のキャッシュから 2 番目のキャッシュを提供できます。

エージェント タイプ別のキャッシュ ヒット率

キャッシュ ヒット率が 65% のカスタマー サポート エージェントの場合、セマンティック キャッシュにより LLM コール量、つまり LLM コストが 65% 削減されます。

キャッシュ構成

類似性のしきい値: キャッシュを再利用するために 2 つのリクエストが「十分に類似している」と宣言するためのしきい値。しきい値が高い = キャッシュ ヒットは少なくなりますが、精度は高くなります。しきい値が低い = キャッシュ ヒットが増加しますが、異なるリクエストに対して微妙に間違った応答が返されるリスクがあります。

事実に基づくクエリの場合、通常、類似性のしきい値は 0.92 ～ 0.95 が安全です。分析タスクまたは推論タスクの場合は、微妙に異なる質問に対して不正確な分析が返されることを避けるために、より高いしきい値 (0.97+) を使用します。

キャッシュ TTL: キャッシュ エントリ タイプが異なれば、有効期限も異なる必要があります。

• 製品価格: 1 ～ 4 時間 (価格は変動します)
• ポリシー情報: 24 ～ 48 時間 (ポリシーはほとんど変更されません)
• 一般知識: 7 日間 (非常に安定した情報)
• 生成されたレポート: 基礎となるデータが変更されるまでキャッシュします (イベントトリガーによる無効化)

キャッシュの範囲: キャッシュがユーザーごと、組織ごと、またはグローバルのいずれであるかを構成します。カスタマー サポート エージェントには、組織を対象としたキャッシュが必要です (組織に適した回答が別の組織には適切ではない可能性があります)。一般知識エージェントはグローバル キャッシュを共有できます。

---

モデルのルーティングと階層型 LLM の選択

すべてのタスクにフロンティア モデルが必要なわけではありません。 GPT-4o mini が正しく処理する単純な分類タスクに GPT-4o または Claude 3.5 Sonnet を使用すると、必要な料金の 15 ～ 50 倍の費用がかかります。

ルーティング戦略

タスクの複雑さの分類: 受信した各リクエストを複雑さによって分類する軽量の分類子を実装します。

• シンプル: 検索、少数のカテゴリによる分類、明確なテンプレートによる短い生成
• 中程度: 複数ステップの推論、複雑な文書からの抽出、条件付きロジック
• 複雑さ: 自由形式の分析、創造的な統合、微妙な判断

モデルの割り当て:

• シンプル → GPT-4o mini、Claude 3 Haiku (コスト: ~$0.15-0.30/M トークン)
• 中程度 → クロード 3.5 ソネット、GPT-4o (コスト: ~$3-5/M トークン)
• 複雑 → Claude 3.5 Sonnet、GPT-4o (または深い推論タスクの場合は o1) (コスト: $5-15/M トークン)

フォールバック ルーティング: 安価なモデルで品質しきい値を下回る出力が生成された場合 (自動評価で検出)、より高価なモデルで再試行します。この「カスケード」アプローチでは、安価なモデルを楽観的に使用し、必要な場合にのみエスカレーションします。

def route_to_model(task: AgentTask) -> str:
    complexity = classify_task_complexity(task)

    model_map = {
        "simple": "claude-haiku-3",
        "moderate": "claude-3-5-sonnet",
        "complex": "claude-3-5-sonnet"
    }
    return model_map[complexity]

def execute_with_fallback(task: AgentTask):
    primary_model = route_to_model(task)
    result = execute_with_model(task, primary_model)

    if not meets_quality_threshold(result):
        # Escalate to more capable model
        result = execute_with_model(task, "claude-3-5-sonnet")

    return result

モデル ルーティングによる現実的な節約: ワークロードが混在するエージェント フリートでは、通常、タスクの 60 ～ 70% が「単純」と見なされます。これらを安価なモデルにルーティングすると、そのセグメントで 50 ～ 70% のコスト削減が達成され、全体のコスト削減に換算すると 30 ～ 50% になります。

---

プロンプト キャッシュ (プロバイダー レベル)

Anthropic と OpenAI は、システム プロンプトを繰り返すコストを削減するプロンプト キャッシュ機能を提供します。システム プロンプト (またはプロンプトの任意のプレフィックス) が複数のリクエスト間で同一である場合、キャッシュされたトークンのコストは新しいトークンよりも大幅に低くなります。

人為的キャッシュの価格: キャッシュされた入力トークンのコストは、標準入力トークンの価格の ~10% ($0.30/M 対 Sonnet の場合は $3/M)。キャッシュ書き込みコストは 3.75 ドル/M です (1 回書き込まれ、その後は 0.30 ドル/M で読み取られます)。

効果的な戦略: 安定した部分 (システム プロンプト、例、手順) が最初に来て、変数部分 (ユーザー入力、取得されたコンテキスト) が最後になるようにプロンプ​​トを構造化します。プロバイダーは安定したプレフィックスを自動的にキャッシュします。

損益分岐点の計算: キャッシュ書き込みには標準入力トークン価格の 1.25 倍のコストがかかります。キャッシュ読み取りコストは 0.1 倍です。損益分岐点は、プレフィックスを共有する 2 つのリクエストです。 2 番目以降のすべてのリクエストは、キャッシュされた部分に関して 90% 安くなります。

1,000 トークンのシステム プロンプトを備え、1 日あたり 1,000 リクエストを実行するエージェントの場合:

• キャッシュなし: 1,000 × 1,000 トークン × 3 ドル/月 = システム プロンプトのみで 3 ドル/日の入力コスト
• キャッシュあり: 3.75 ドル (1 回の書き込み) + 999 × 1,000 × 0.30 ドル/M = 0.30 ドル/日
• 毎日の節約: $2.70 (このコンポーネントでは 90% 割引)

---

バッチ処理

時間に依存しないワークロード (夜間のレポート生成、バッチ文書処理、スケジュールされたデータ分析) の場合、バッチ API 呼び出しにより大幅なコスト削減が実現します。

OpenAI バッチ API: 24 時間の完了ウィンドウを持つバッチとして送信されたリクエストのコストが 50% 削減されます。夜間のレポート生成の場合、これだけで LLM API コストが半分になります。

人為的なメッセージ バッチ: 時間に依存しないワークロードにも同様のバッチ料金が適用されます。

バッチ スケジュール パターン:

• レポート生成リクエストを 1 日を通して収集し、業務終了時にバッチとして送信します
• RAG のドキュメント取り込みをオフピーク時間にバッチ ジョブとして処理します
• コンプライアンス監視スキャンをバッチとして毎晩実行します

---

コストの監視と帰属

最適化にはコストがどこから発生しているのかを知る必要があります。生産初日からコスト監視を実装します。

ワークフローごとのコスト追跡: すべての LLM 呼び出しに、それが属するワークフローをタグ付けします。 1 日あたりのワークフローごとの合計コストを計算します。これにより、どのエージェントの動作が最もコストがかかるかが明らかになり、最適化の取り組みに優先順位が付けられます。

トークンごとの属性: 入力トークンと出力トークン、プロンプト コンポーネント (システム プロンプト、コンテキスト、ユーザー入力)、およびモデルごとにコストを分類します。この粒度でのコスト帰属により、ターゲットを絞った最適化が可能になります。

コストの異常検出: 1 日あたりのコストが 7 日間のローリング平均より 20% 以上急増した場合にアラートを送信します。スパイクは、正当なボリューム増加 (予想される) またはバグ (無限ループ、暴走コンテキスト ウィンドウ、異常に長い完了を引き起こすプロンプト インジェクション) を示します。

成功したタスクあたりのコスト: 合計コストを成功したタスクの完了数で割って、価値単位あたりのコストを取得します。これは ROI にとって重要な指標です。タスクの量と品質が維持されたままタスクあたりのコストが減少すれば、最適化は機能しています。

---

よくある質問

コストの最適化により、現実的にどの程度 LLM API コストを削減できるでしょうか?

一般的な OpenClaw 導入では、プロンプト圧縮、セマンティック キャッシュ、モデル ルーティングに対処する体系的な最適化作業により、最適化されていない導入と比較して 45 ～ 65% のコスト削減が達成されます。具体的な節約額はワークロードの特性に大きく依存します。クエリの繰り返しが多いエージェントはキャッシュから最も恩恵を受けます。多様でユニークなクエリを持つエージェントは、モデル ルーティングからより多くの恩恵を受けます。

セマンティック キャッシュにより応答の精度が損なわれますか?

しきい値を適切に設定すると、精度への影響は無視できます。通常、実際のタスクでの低下は 0.5% 未満です。重要なのは、タスクの種類に応じて類似性のしきい値を適切に設定することです。質問の微妙な違いが異なる正解につながるタスクの場合は、より高い類似性しきい値 (0.96 以上) を使用して、真に同等のクエリのみがキャッシュから提供されるようにします。

セマンティック キャッシュのレイテンシへの影響は何ですか?

キャッシュ ルックアップ (ベクトル類似性検索) では、5 ～ 15 ミリ秒の遅延が追加されます。キャッシュ ヒットにより、LLM 呼び出しの遅延 (通常は 500 ミリ秒から 3 秒) が排除されます。最終的な結果: キャッシュされた応答は、キャッシュされていない応答より 20 ～ 200 倍高速になります。これは遅延の改善であり、低下ではありません。

多大なエンジニアリング作業を行わずにコスト監視を実装するにはどうすればよいでしょうか?

OpenClaw の可観測性レイヤーは、実行ごとにトークン数とモデルの選択を自動的にキャプチャします。 ECOSIRE は、実装中にワークフロー、モデル、期間ごとのコストを表示するコスト ダッシュボードを構成します。カスタム エンジニアリングは必要ありません。監視インフラストラクチャは標準実装の一部です。

コスト最適化対策はどの程度の規模で価値がありますか?

ほとんどの最適化手段は、LLM API コストが月額 500 ドルを超えると価値があります。このしきい値を下回ると、通常、エンジニアリングの労力が節約額を超えます。月額 2,000 ドルを超える場合は、体系的な最適化を強くお勧めします。この規模では、最適化に投資したエンジニアリング時間に対する ROI が非常に高くなります。

安価なモデルに切り替えると、エージェントの出力の品質が低下しますか?

より安価なモデルが同等の品質を提供するタスクの場合、それらに切り替えることは純粋な節約になります。深い推論、微妙な判断、または複雑な合成を必要とするタスクの場合、安価なモデルでは著しく悪い出力が生成されます。モデル ルーティング パターンは、適切な場合にのみ安価なモデルを使用し、それらを必要とするタスクについてはプレミアム モデルにルーティングすることで、この問題に対処します。重要なのは経験的な検証です。運用トラフィックを特定のタスクにルーティングする前に、そのタスクで安価なモデルをテストします。

---

次のステップ

AI エージェントのコストの最適化は、1 回限りのプロジェクトではなく、継続的な分野です。 ECOSIRE の OpenClaw 実装には、初日からコスト最適化レイヤーが含まれています。セマンティック キャッシュ、モデル ルーティング、プロンプト最適化は、後付けで追加されるのではなく、展開アーキテクチャに組み込まれています。

ECOSIRE OpenClaw サービスを調べる して、コストの最適化要件について話し合うか、メンテナンスと最適化の維持オプションを確認して、ECOSIRE が本番 OpenClaw 導入の継続的なコスト効率をどのように管理するかを理解してください。