トークンバジェット最適化（トークンバジェットサイテキカ）
LLMアプリケーションのトークン消費を体系的に管理・最小化する技術群。プロンプト圧縮・セマンティックキャッシュ・ストリーミング中断・段階的生成・モデルルーティングなどを組み合わせ、品質を維持しながらAPI利用コストを最大70%削減する手法。
トークンバジェット最適化とは、LLMアプリケーションが消費するトークン数を予算（バジェット）として管理し、品質を維持しながら消費量を最小化する技術体系である。2026年現在、企業のLLM運用コストは月間$1,000〜$100,000に達しており、トークンバジェット最適化は収益性に直結する技術課題となっている。
概要
トークンバジェット最適化は、従来の「精度最優先」から「精度とコストのパレート最適」へのパラダイムシフトを体現する。具体的には、入力トークンの圧縮（プロンプトエンジニアリング）、出力トークンの制御（max_tokens設定・構造化出力）、重複呼び出しの排除（キャッシュ）、適材適所のモデル選択（ルーティング）の4軸で最適化する。
実証事例として、Stripe社はモデルルーティング導入でLLM月間コストを$280,000から$95,000に削減（66%減）。Notion AIはプロンプトキャッシュとセマンティックキャッシュの併用で月間$420,000から$180,000に削減（57%減）したと報告されている。
最適化手法の体系
| 手法 | 削減効果 | 実装難度 | 品質影響 | 適用場面 |
|---|---|---|---|---|
| プロンプト圧縮 | 30〜60% | 中 | 2〜5%低下 | 長いシステムプロンプト |
| セマンティックキャッシュ | 40〜70% | 高 | 0%（同一回答） | FAQ・定型質問 |
| モデルルーティング | 40〜60% | 中 | 2〜3%低下 | 混合難度のクエリ |
| 構造化出力 | 20〜40% | 低 | 0% | JSON/XML出力 |
| ストリーミング中断 | 10〜30% | 低 | 可変 | チャットUI |
| バッチ処理統合 | 50%（単価） | 低 | 0% | 非リアルタイム処理 |
プロンプト圧縮の実践
プロンプト圧縮は入力トークン数を削減する最も直接的な手法。3つのアプローチがある：
- 手動リファクタリング: 冗長な指示を簡潔に書き換え。「以下の文章を読んで、内容を要約してください。要約は3つのポイントに絞り、各ポイントは50字以内で記述してください」→「要約: 3点×50字以内」。平均20〜30%削減
- LLMLingua-2: Microsoft Researchが開発した自動圧縮ツール。BERTベースの分類器がトークンの重要度を判定し、低重要度トークンを除去。圧縮率2〜5倍で品質低下5%以内
- AutoCompressor: Chevalier et al.が提案した学習ベースの圧縮。LLM自体に過去の会話を圧縮させ、summary vectorとして保持。メモリ効率と品質のバランスが良い
セマンティックキャッシュの実装
セマンティックキャッシュは、意味的に類似するクエリに対して過去の回答を再利用する仕組み。
主要実装：
- GPTCache: オープンソース。Redis/Milvus/Qdrant等のベクトルDBと連携。コサイン類似度0.95以上でキャッシュヒット
- LangChain SemanticCache: LangChainフレームワーク内蔵。OpenAI Embeddingsで類似度計算
- Redis Semantic Cache: Redis Stack 7.4+のベクトル検索機能を活用。レイテンシ1ms以下
キャッシュ戦略の設計指針：
- ヒット率目標: 40〜60%（FAQ系アプリは70%以上可能）
- TTL設定: 情報鮮度に応じて1時間〜7日。ニュース系は短く、技術ドキュメント系は長く
- 類似度閾値: 0.92〜0.96。低すぎると誤ヒット、高すぎるとヒット率低下
- キャッシュサイズ: Pareto分布に従い、上位20%のクエリが80%のトラフィックを占める
モデルルーティングの実装
クエリの複雑さに応じて最適なモデルを自動選択するアーキテクチャ。
| ルーター | 方式 | 対応モデル | 判定精度 | レイテンシ追加 |
|---|---|---|---|---|
| OpenRouter | クラウドAPI | 200+ | 85% | 50ms |
| LiteLLM | OSS Gateway | 100+ | - (ルール) | 10ms |
| Martian | ML分類器 | 50+ | 90% | 30ms |
| RouteLLM (Berkeley) | 学習ベース | カスタム | 92% | 20ms |
| 自前ルール | if-else | 任意 | 用途次第 | 0ms |
段階的ルーティングの実例：
- Tier 1（$0.15/1M）: GPT-4o mini — 挨拶・FAQ・定型応答（全クエリの40%）
- Tier 2（$2.50/1M）: GPT-4o — 一般的な質問・要約・翻訳（全クエリの45%）
- Tier 3（$10.00/1M）: o3 — 複雑な推論・コード生成・数学（全クエリの15%）
この3段ルーティングで、全クエリをTier 2で処理する場合と比較して55%のコスト削減。
トークンバジェット管理のベストプラクティス
- 日次・週次のトークン消費レポート: Helicone・LangSmith・Langfuse等のobservabilityツールでモニタリング
- アラート設定: 日次バジェットの80%到達で通知、100%でフォールバックモデルに切替
- A/Bテスト: 圧縮・ルーティング施策の品質影響を定量的に検証。NPS・CSAT・タスク完了率で計測
- 月次最適化レビュー: トークン単価の値下げ・新モデルリリースに応じてルーティングルールを更新
よくある質問（FAQ）
Q1: トークンバジェット最適化で品質はどれくらい下がるか？ A: 適切に実装すれば品質低下は3〜5%以内に抑えられる。モデルルーティングでは簡単なクエリに小型モデルを使うため体感品質は変わらない。プロンプト圧縮のみ2〜5%の低下があるが、ユーザー満足度調査では差が検出されないケースが多い。
Q2: 最初に導入すべき最適化手法は何か？ A: 実装コスト対効果で順位付けすると、(1) max_tokensの適正設定（即日・20%削減）、(2) プロンプトキャッシュ有効化（1日・35%削減）、(3) モデルルーティング（1週間・50%削減）の順。セマンティックキャッシュは効果大だが実装に2〜4週間かかる。
Q3: 小規模アプリでもトークンバジェット管理は必要か？ A: 月間API利用額$50以下なら不要。$50〜$500ならmax_tokens設定とプロンプトキャッシュの2つだけで十分。$500以上ならモデルルーティングまで導入すべき。Helicone（無料枠10万リクエスト/月）でまずモニタリングを始めるのが第一歩。
まとめ
- トークンバジェット最適化は品質維持×コスト最小化のパレート最適を実現する技術体系
- プロンプト圧縮（30〜60%削減）・セマンティックキャッシュ（40〜70%）・モデルルーティング（40〜60%）の3本柱
- 3段階ルーティング（mini→標準→推論特化）で全クエリ同一モデル比55%削減
- 月間$500以上のAPI利用なら投資回収1〜2ヶ月で最適化施策が回収可能
- Helicone・LangSmith等のobservabilityツールでトークン消費の可視化が第一歩