LLMコスト最適化：キャッシング、ルーティング、そしてファインチューニングのタイミング

エージェント型AI機能をリリースするすべてのチームは、やがて同じ壁に直面します。デモは魔法のようですが、本番環境の請求額は残酷です。1つのエージェントループが数十のLLM呼び出しに広がり、コストはユーザー数に比例して増えていきます。朗報は、その支出のほとんどは回避可能だということです。利用制限やモデルのダウングレードを検討する前に、以下の3つのレバーを順番に試してください。

1. プロンプトキャッシング：最も簡単な勝利

最新のLLM APIはプロンプトキャッシングをサポートしています。プロンプトの静的な前半部分（システム命令、ツール定義、検索されたドキュメント）がプロバイダー側にキャッシュされ、通常の入力単価のごく一部——典型的にはキャッシュヒット時に通常入力コストの10%——で課金されます。

エージェント型ワークロードにとって、これは変革的です。毎ターン同じ2万トークンのシステムプロンプトを送信するコーディングエージェントは、1行のコード変更で70〜90%の入力コスト削減を実現できます。ルールはシンプルです。

• 安定したコンテンツを先頭に、可変コンテンツを末尾に配置する。
• リクエスト間でキャッシュプレフィックスをバイト単位で同一に保つ。
• TTLに注意する——プロンプトキャッシュは通常、数分間の非アクティブ後に期限切れになります。

プロンプトキャッシングをまだ使っていないなら、他の何かに手を付ける前にここから始めてください。

2. モデルルーティング：すべての呼び出しを適正サイズに

すべてのLLM呼び出しに最大モデルが必要なわけではありません。よく設計されたエージェントはカスケードを使います。安価で高速なモデルが分類、抽出、定型ステップを処理し、フロンティアモデルは推論、計画、コード生成のために温存されます。

実践的には次のようになります。

• Haiku／小型モデル：インテント分類、ツール選択、要約。
• Sonnet／中位モデル：ほとんどのツール利用と検索拡張ステップ。
• Opus／フロンティアモデル：計画、複雑な推論、長期的なタスク。

シンプルなルーター——プロンプトタイプや推定難易度に基づくルールベースのものでも——が、品質の低下をほとんど伴わずにコストを40〜60%削減することがよくあります。リリース前に評価で各ティアの品質を測定してください。推測ではダメです。

3. ファインチューニングのタイミング（とタイミングでないとき）

ファインチューニングは、チームが最初に手を伸ばしがちで、実は最後に検討すべきレバーです。トレーニングコスト、推論コスト（ファインチューニングされたエンドポイントはベースモデルより高価なことが多い）、運用の複雑さ、そしてベースモデルが更新されるたびに動くターゲットが加わります。

ファインチューニングすべきとき：

• 狭く、大量のタスクで、プロンプトエンジニアリングが頭打ちになっている。
• プロンプト長を劇的に削減する必要がある（例：5Kトークンの命令ブロックを組み込み動作に置き換える）。
• 数千の高品質な例と、「良い」と「素晴らしい」を区別する明確な評価を持っている。

RAG、より良いプロンプト、またはより小さなルーティングされたモデルが問題を解決できる場合は、ファインチューニングをスキップしてください。2026年において、キャッシングを伴う少数ショットプロンプティングは驚くほど強力です。「ファインチューニングが必要」という直感のほとんどは、実際には「より良い検索が必要」か「評価が必要」なのです。

すべてを組み合わせる

現実的なコスト最適化アーキテクチャはこのようになります。ルーターが受信リクエストを分類し、キャッシュされたシステムプロンプトが重いコンテキストを運び、小型モデルが呼び出しの70%を処理し、フロンティアモデルが難しい30%を処理し、ファインチューニングは1〜2の狭く実証済みのボトルネックのために温存されます。このパターンを適用したチームは、最初の本番デプロイと比較して5〜10倍のコスト削減を日常的に目にしています。

Sdevratechでは、LLMワークロードの計測、ルーティングとキャッシングレイヤーの構築、そしてこれらのトレードオフを可視化する評価の実施をチームと一緒に行っています。エージェント型AIは高価である必要はありません——エンジニアリングされるべきなのです。