生成AIのコストはモデルの選択だけでは決まりません。設計で決まります。
特に推論コストは、キャッシュ戦略を入れるかどうかで桁が変わることがあります。
本記事では、実務で使う代表的なキャッシュ戦略を整理します。雰囲気の最適化ではなく、再現性のある設計論としてまとめます。
完全一致キャッシュは最も単純で最も効く
主張：まずは完全一致キャッシュを入れるべきです。
根拠は明確です。業務系LLMでは同一入力が繰り返されます。FAQ回答、定型メール生成、要約テンプレートなどは特に顕著です。
具体例として、社内問い合わせボットで「パスワードリセット方法」を含む同一プロンプトが1日数百回発生していました。入力正規化（空白・改行除去）後にハッシュキーで保存するだけで、APIコールが40%削減できました。このパターンは本当によく見ます。
示唆はシンプルです。
- 入力を正規化してハッシュ化
- TTL（有効期限）を業務特性に合わせる
- モデルバージョンをキーに含める
まずここを入れずにコスト議論を始めると、私は少し構えます。
類似度キャッシュはスケール時に効く
主張：完全一致が効かなくなったら類似度キャッシュを検討すべきです。
根拠は、問い合わせが微妙に言い換えられるケースが増えるからです。「有給の申請方法」と「休暇申請のやり方」は意味的に近い。ここでEmbeddingを使った近傍検索キャッシュが効きます。
具体的には、
- 入力をEmbedding化
- ベクトルDBで類似検索
- 類似度閾値を超えたら既存回答を返す
ただし閾値設計は慎重に行う必要があります。高すぎればヒットしない、低すぎれば誤回答を返す。この瞬間に私は必ずオフライン評価を入れます。
示唆としては、
- 固定クエリセットで誤ヒット率を測定
- 類似度分布を可視化して閾値を決める
- 高リスク業務では人間確認フローを挟む
類似度キャッシュは便利ですが、品質責任を伴います。
中間生成物キャッシュはトークンを削る
主張：プロンプト分解できるなら中間生成物をキャッシュすべきです。
多段プロンプト設計では、毎回同じ前処理をLLMにさせているケースがあります。例えば「文書要約→論点抽出→表形式整形」という流れです。
ここで文書要約部分をキャッシュすれば、後段だけ再実行できます。ある案件では、1リクエストあたりの平均トークン数を30%以上削減できました。この設計を入れないままスケール議論を始める例もよく見ます。
示唆は以下です。
- プロンプトを機能単位で分割する
- 副作用のないステップをキャッシュ対象にする
- バージョン管理を徹底する
キャッシュは単なる保存ではなく、プロンプト設計の一部です。
キャッシュはコスト最適化ではなく基盤設計である
LLMキャッシュは「あとから足す最適化」ではありません。
最初から前提に入れるべき基盤設計です。
完全一致 → 類似度 → 中間生成物。
この順で検討すれば、多くのケースで現実的なコスト水準に落とせます。
次に考えるべきは、キャッシュヒット率をどう継続監視するかです。
コストは設計の副産物です。構造を整えれば、自然と下がります。