そもそも何にお金がかかるのか
LLM利用のコストは大きく分けて3層あります。
- モデル利用料（API）：入力／出力トークン × 単価。ほとんどのコストはここ。
- 埋め込み・ベクトル検索：ドキュメント数 × ベクトル次元数。RAGならここも無視できない。
- インフラ：サーバー・ストレージ・ログ。LLMコストに比べると相対的に小さい。
コストが膨らむ典型パターン
① 履歴を全部詰め込む
チャット履歴をぜんぶプロンプトに乗せると、ターンを重ねるごとに入力トークンが線形に増えます。10ターン目には初回の10倍。
② RAGコンテキストが太い
「Top-5を全部入れる」を素直に実装すると、1回の質問で数千〜万トークンの入力が発生します。Rerankerで絞らないと崩壊します。
③ エージェントの再帰呼び出し
Function CallingベースのAIエージェントは、判断→ツール呼び出し→再判断、と内部で複数回LLMを叩きます。1ユーザーリクエストが平均5〜10回のLLM呼び出しになることも。
④ 全部 Opus / GPT-5 で叩く
「高精度モデルを使えば安心」と全リクエストを最上位モデルに飛ばすと、コストは桁で違います。タスクによってはHaiku／Geminiで十分。
設計段階で組み込むべき5つの対策
1. プロンプトキャッシュ
Claude／GPTの prompt caching を使うと、システムプロンプト・固定ドキュメントを再利用時に大幅割引できます。長文ドキュメントを毎回送るRAGでは効果絶大。
// Claude prompt caching の例
{
"system": [
{ "type": "text", "text": "あなたは社内ナレッジアシスタントです。" },
{ "type": "text", "text": longDocument, "cache_control": { "type": "ephemeral" } }
]
}2. モデル切替（ルーター）
クエリの難易度を簡易判定し、簡単な質問はHaiku／Flash、複雑な質問だけOpus／GPT-5へ。「タスク分類器→モデル選択」を入れるだけで体感の品質は変えず30〜60%コスト減のケースが多いです。
3. RAGコンテキストの動的圧縮
Top-Kは固定にせず、回答に必要な箇所だけを抽出する「Context Compression」を入れる。LlamaIndexのContext Compressorなどが定番。
4. 履歴の要約
長くなったチャット履歴は、定期的に要約してプロンプト先頭に置き、生履歴は破棄。トークンを線形に増やさない設計を最初から組み込む。
5. スコープ制御（ガード）
「全社員が無制限に叩ける」状態は、コスト面でもリスク。ユーザー単位・チーム単位の利用上限／月次予算アラートを最初から実装する。
実例 — 月額コストが1/4になった案件
ある社内ナレッジRAGで、運用開始3ヶ月後の月額コストが想定の3倍に達していました。プロンプトキャッシュ・モデル切替・履歴要約の3つを入れ替えて、翌月から1/4まで圧縮。精度はむしろ向上しました。
「目に見える」コストモニタが必要
LLMコストは設計時の見積よりも、運用後の計測と可視化のほうが重要です。下記4軸でダッシュボードを置きましょう。
- 機能別コスト（チャット／RAG／エージェント／要約 …）
- ユーザー別コスト（誰が・どれだけ叩いているか）
- モデル別コスト（Opus 何%、Sonnet 何%…）
- キャッシュヒット率（節約できているか）
コストが見えないと、節約のしようがない。LLMOpsを謳うのに「コストダッシュボードがない」案件は、運用に乗ったあと必ず破綻します。
SLAと予算のバランス
最後に。コスト最適化はSLA（応答時間・精度）とのトレードオフです。「とにかく安く」ではなく、業務要件に合った最適点を探す設計が必要です。
例えば、CS自動応答なら「3秒以内に出ること」が体感品質に直結するので、レイテンシ重視でモデル選定。法務レビューなら「精度第一」でコストは度外視。利用シーン×SLAでモデルを使い分けるのが、本当に効くコスト設計です。
MU AI事業部のLLMOps運用代行プランでは、上記のコスト設計を実装段階から組み込み、運用後も月次レポートで効果を可視化します。