LLM APIを業務システムに組み込む際、最初は想定以下のコストで動いているのに、運用が進むにつれてコストが膨らんでいく——という話はよく聞く。
本業でAzure OpenAI ServiceやClaude APIを使った業務システムの設計に関わっている立場から、コストが膨らむ典型パターンと、現場で効いている対策をまとめておく。
典型パターン1：プロンプトが肥大化している
「精度を上げるために指示を追加する」を繰り返すと、システムプロンプトが数千トークンに膨れ上がることがある。トークン単価は安くても、1日数百回〜数千回のAPI呼び出しがあると、固定コストとして効いてくる。
対策
・システムプロンプトを定期的に棚卸しし、重複・不要な指示を削除する
・ユーザー入力を前処理してノイズを除く（不要な空白・改行など）
・few-shotを入れる場合は最小限の例示に絞る
典型パターン2：キャッシュが効いていない
OpenAI / Anthropicいずれもプロンプトキャッシングの仕組みを持っているが、プロンプトの構造を変えるたびにキャッシュが無効になる。毎回フルの入力コストがかかり続ける。
Anthropicの場合（cache_control）
{
"role": "user",
"content": [
{
"type": "text",
"text": "長い共通コンテキスト...",
"cache_control": { "type": "ephemeral" }
}
]
}
変わらない部分（システムプロンプト、参照ドキュメント）をキャッシュ対象として先頭に置くだけで、ヒット時のコストを大幅に削減できる。
典型パターン3：不要なAPI呼び出しが発生している
「毎回LLMを呼ぶ」設計になっているが、実はキャッシュできるケースや、ルールベースで処理できるケースが混在していることがある。
検討する観点
・同じ入力に対して同じ出力になるなら、結果をキャッシュして再利用できないか
・分類タスクなど、LLMを使わずに対応できる処理が混じっていないか
・バッチ処理に切り替えられる処理はないか（Anthropic Batchは通常の50%）
典型パターン4：モデルの選択が適切でない
処理の性質に関わらず、最上位モデルを全タスクに使っている場合。分類・抽出・要約など単純タスクはHaikuやmini系モデルで十分なことが多い。
目安
複雑な推論・長文生成 → Opus / GPT-4o
標準的な生成・対話 → Sonnet / GPT-4o mini
分類・抽出・短文生成 → Haiku / GPT-3.5相当
コスト管理はアーキテクチャ設計時に決まることが多く、後から直すほど手間がかかる。「今のコストが適正か」を定期的に確認する習慣と、監視の仕組みを最初から入れておくことが、長期的には一番効く。
詳細はnoteにも書いている：LLM API利用でコストが膨らむ典型パターンとその対策