モデルのAPI利用料を抑えるには？

エージェントのワークフローを最適化してコスト（トークン消費）を削減することは、本質的に**「トークン・エコノミクス」のガバナンスを行うことに他なりません。 核心となる原則はただ一つ、「リソースを最も重要な部分に集中させること」**です。つまり、高度な推論能力が不可欠な場面でのみ、高価なモデルを呼び出すべきです。

アーキテクチャ設計、モデルの階層化、コンテキスト管理、プロンプトエンジニアリングの4つの側面から、徹底的なコスト圧縮（削減）を行う方法を解説します。

1. アーキテクチャ設計：LLMを使わずに済むなら使わない (Bypass & Offload)

最も安上がりな呼び出しとは、「呼び出さないこと」です。私たちは往々にして、従来のコードで処理できるタスクにまでLLMを乱用しがちです。

• 純粋なコード/正規表現フィルタ (Heuristic/Regex First)
  • シーン： ユーザー入力にメールアドレスが含まれているか、空欄ではないか、フォーマットは正しいかのチェック。
  • 最適化： LLMに渡す前に、まずPythonのバリデーション関数を通す。
  • 効果： 無効またはフォーマットエラーのリクエストを30%ブロックでき、そのコストはゼロです。
• セマンティック・キャッシュ (Semantic Caching)
  • 原理： ユーザーの質問は重複することが多いです（例：「休暇の申請方法は？」）。従来のKey-Valueキャッシュは完全一致が必要ですが、セマンティック・キャッシュはベクトルの類似度を利用します。
  • 手法：
    1. ユーザーのクエリ（Query）のベクトルを計算する。
    2. ベクトルデータベース（Redis/Pineconeなど）で、類似度が0.95以上の過去の問答を検索する。
    3. ヒットすれば、キャッシュされた回答を直接返す。
  • 推奨ツール： GPTCache
  • 効果： 高頻度で質問が重複するシーンでは、API呼び出しを40%〜60%削減可能です。
• 決定論的ルーティング (Deterministic Routing)
  • 原理： 意図が極めて明確な指示（例：「顧客の張さんを検索して」）の場合、LLMの計画層（Planning Layer）をスキップし、SQLクエリツールへ直接マッピングします。
  • 実装： キーワードマッピングテーブルや分類ツリーを作成して振り分けます。

2. モデルの階層化：モデル・カスケード (Model Cascading/Waterfall)

GPT-4oに全ての仕事をさせないでください。小規模モデルから大規模モデルへと段階的に処理を委譲するメカニズムを構築します。

• ルーター/分類器 (Router/Classifier)
  • 小モデル戦略： Llama-3-8B（ローカル）やGPT-4o-mini（安価なAPI）を、意図分類やツール選択の専門担当にします。タスクが「複雑な推論が必要」と判定された場合のみ、大規模モデルに渡します。
  • コスト比較： GPT-4o-miniの価格は通常、GPT-4oの約1/30です。
• 段階的リトライ機構 (Fallback Pattern)
  • フロー： まず安価なモデルを呼び出して解決を試みます。
  • 高速な検証関数（Checker）で結果をチェックします（JSON形式に従っているか等）。
  • 安価なモデルが失敗したり、検証に通らなかった場合のみ、高価なモデルに「アップグレード」してリカバリー（救済）させます。

3. コンテキスト管理：必要なものだけを渡す (Context Pruning)

プロンプトに含まれるコンテキスト（会話履歴、参考ドキュメント）は、通常トークン消費の大部分を占めます。

• コンテキスト圧縮 (Summarization over Memory)
  • 戦略： 過去10往復の会話をそのままLLMに送ってはいけません。
  • 最適化： LangChainの SummaryMemory などを利用し、3ターンごとに小規模モデルで過去の会話を100文字程度の要約にまとめ、元のログと置き換えます。
• RAG検索の最適化 (Reranking)
  • シーン： ナレッジベースから20個のドキュメント断片が検索されたとして、それを全部プロンプトに詰め込むとトークンが爆発し、推論のノイズにもなります。
  • 最適化： Rerankモデル（BGE-Rerankerなど。非生成式で非常に高速）を導入します。まず50個検索し、Rerankで関連性が最も高いトップ3だけを厳選してLLMに渡します。

4. プロンプトエンジニアリング：バッチ処理と構造化

• バッチ処理 (Batching)
  • シーン： リストにある5件のデータに対して同じ分析を行う場合。
  • Bad: forループを書いて、LLMを5回呼び出す。
  • Good: 5件のデータを1つのプロンプトに結合する。「以下の5件のデータを順に分析し、JSONリスト形式で結果を返してください」→ 呼び出しは1回で済みます。
• 出力の強制短縮 (Output Constraints)
  • LLMの課金体系は通常、Input（入力）が安く、Output（出力）が高いです。
  • テクニック： System Promptに「Do not imply. Do not explain. Output JSON only.（示唆するな。説明するな。JSONだけを出せ）」と記述します。
  • OpenAIの json_object モードを使用し、モデルが生成しがちな「承知いたしました、こちらが結果です…」といった無駄な社交辞令（これらも課金対象です）を排除します。

コスト削減対照表

まとめと推奨ステップ

もし今すぐ最適化に着手するなら、以下の順序で進めることをお勧めします。

1. 第一歩（即効性あり）： 全てのプロンプトを見直し、冗長なコンテキストを削除し、簡潔なJSON出力を強制する。
2. 第二歩（アーキテクチャ調整）： 全ての非推論タスク（フォーマット整形、キーワード抽出など）を、GPT-4o-miniやDeepSeek-V3などの高コスパモデルに置き換える。
3. 第三歩（上級）： セマンティック・キャッシュを導入し、重複リクエストをブロックする。