LLM を本番に載せると、1 回あたりは数円でも「ユーザー数 × 利用頻度 × 365 日」で月のコストはあっという間に膨らみます。コスト最適化とは、品質を落とさずにこの掛け算を小さくする技術の総称です。本ガイドは、すぐ効く順に キャッシュ・モデルの使い分け・バッチ・コンテキスト圧縮、そしてセルフホスト時の 量子化・蒸留 までを、2026 年時点の事実に沿って整理します。
FIG.1 最適化のレバーは「単価を下げる」「トークンを減らす」「測って回す」の3系統
原則は単純で、まず効果が大きく実装が軽い順に手を付けます。多くのケースで効くのはキャッシュ・モデルの使い分け・コンテキスト圧縮の3点で、本番に乗せたあと月次コストを見ながら段階的に追加していくのが現実的です。
01プロンプトキャッシュ：同じ前置きを使い回す
システムプロンプトやツール定義のように毎回ほぼ同じ長い前置きを送る場合、その部分をプロバイダ側に覚えさせ、2 回目以降は入力トークン費用を大きく割り引く仕組みがプロンプトキャッシュです。エージェントや RAG のように前置きが長い構成ほど効きます。
注意したいのは、割引率や挙動がプロバイダごとに異なることです（料金は変動するので必ず公式で最新を確認してください）。2026 年時点の代表的な傾向は次の通り。
| 仕組み | 2026年時点の傾向 |
|---|---|
| Anthropic（Claude） | キャッシュ読み出しは通常入力の約1割（最大約90%引き）。書き込み時は約1.25倍。cache_control で明示 |
| OpenAI | 安定したプレフィックス（目安1,024トークン以上）を自動キャッシュ。読み出しは約50%引き |
| Google（Gemini） | Context Caching。キャッシュ分は約75%引きが目安 |
FIG.2 キャッシュは「静的プレフィックス → 動的テール」の順に設計する
最大の落とし穴はキャッシュ無効化です。日時・ユーザー名・セッション ID などの動的な値をプロンプトの先頭に混ぜると、それ以降が毎回別物と判定され、割引が効かず通常料金に戻ってしまいます。対策はシンプルで、固定の前置きを先に、変わる値を末尾に置くこと。あるセキュリティ企業（ProjectDiscovery）は、作業メモをメッセージ末尾へ移すだけで LLM コストを約 59% 削減しています。
02モデルカスケード：軽い質問は軽いモデルへ
1 つのアプリで全リクエストを最上位モデルに投げるのは、軽自動車で済む用事に毎回トラックを出すようなものです。質問の難しさに応じてモデルを段階的に使い分けるのがカスケード（多段ルーティング）です。2026 年時点では、同じモデルファミリ内でも効率モデルとフロンティアモデルで5〜25 倍の単価差があります。
Light
分類・ルーティング・簡単な抽出。例：Claude Haiku 系、GPT の Mini/Nano 系、Gemini Flash-Lite。
Mid
日常業務・要約・翻訳。例：Claude Sonnet 系、Gemini Flash／Pro 系。
Frontier
複雑な推論・コード生成・エージェントの司令塔。例：Claude Opus 4.6/4.7、GPT-5.4。
FIG.3 Light で大半を捌き、難しいものだけ Mid → Frontier へ上げる
カスケードの実装手順
- 軽量モデル（または分類器）で「これは難しい質問か」を判定する
- 簡単 → 軽量モデルでそのまま回答
- 難しい → Mid にエスカレーション、それでも不十分なら Frontier
- 判定の根拠・結果・費用をログし、判定ロジックを継続的に改善する
うまく設計すると、フロンティア単体運用に比べコストを 45〜85% 削減しつつ品質の約 95% を維持できる、という報告が複数あります。鍵は「いつ上位に上げるか」の判定精度なので、誤って簡単な質問を上位に流していないかを必ず計測しましょう。
03バッチ API：急がない処理は半額で
リアルタイム性が不要なタスクは、OpenAI・Anthropic・Google いずれもバッチ API で約 50% 安く処理できます（24 時間以内に結果が返る非同期方式）。
- 大量翻訳、データ分類・ラベリング、まとめ要約、定期レポート生成
- JSONL でまとめて投入し、結果をまとめて受け取る
- 夜間バッチや定時処理に最適
さらに、バッチ内のプレフィックスがキャッシュに当たればバッチ割引とキャッシュ割引が重なり、理論上は元コストの約 25% まで下げられる、とされています。リアルタイムが要らない処理を洗い出して片っ端からバッチに寄せるのは、効果が大きく安全な定番手です。
04コンテキスト圧縮：渡すトークンを減らす
入力トークンは「短く・必要な分だけ」が基本です。やりがちな無駄を削るだけで効きます。
- 会話履歴を要約して渡す（一定ターンを超えたら要約モードに切替）
- RAG で関連部分だけ渡す（全文を毎回渡さない）
- 構造化が要らない場面では JSON より軽い Markdown / 箇条書きで渡す
- 不要な改行・空白・テンプレ定型文を除去する
05再ランキング：少なく渡して精度も上げる
RAG で広めに 100 件取得し、再ランキング（Cohere Rerank、Voyage Rerank、Zerank など）で上位 5 件に絞ってから LLM に渡すと、投入トークンが減りつつ精度も上がるという一石二鳥が狙えます。再ランカーは検索入力トークンあたりで課金される（例：Cohere は概ね $2/100万トークン規模）ため、再ランカー自体のコストと LLM への投入削減を合わせて見るのがコツ。スコアをセマンティックキャッシュすると、再ランキング費用をさらに 30〜60% 抑えられるという報告もあります。
「広く拾って、厳しく絞る」。再ランキングはコストと精度を同時に動かせる数少ないレバーです。
06量子化：セルフホスト時のメモリと費用を削る
オープンウェイトモデルを自前の GPU で動かす場合、量子化でモデルの重みを低ビットに圧縮し、メモリと計算を減らせます。2026 年時点の実務的な選び方は次の通り。
| 方式 | 特徴（2026年時点） |
|---|---|
| INT8 | 精度ほぼ維持、メモリ約半分。手堅い第一候補 |
| INT4（AWQ / GPTQ） | BF16比でVRAM約75%削減。AWQ は精度低下<1%が目安で vLLM での INT4 定番。要約・分類・コード補完に好適、複雑な推論や数学は劣化が出やすい |
| FP8 | H100 / Blackwell でネイティブ高速。ほぼ無劣化（精度コストはごく僅か）で約2倍近いスループット |
FIG.4 低ビット化でメモリは減るが、INT4 は複雑タスクで劣化が出やすい（要検証）
vLLM や Together AI、Fireworks などが量子化配信に対応しています。注意点として、量子化はモデル重みを縮めますが、KV キャッシュ（推論中の文脈保持）は別枠でバッチサイズや系列長に応じて増えるため、本番のバッチ規模では重みに上乗せで数十 GB 必要になることがあります。導入時は必ず自分のタスクで精度を実測してから採用してください。
07蒸留：小モデルに大モデルの仕事を覚えさせる
蒸留（Distillation）は、大きな「教師」モデルに大量の入出力を作らせ、それを使って小さな「生徒」モデルを Fine-tune する手法です。狭く specialized なタスクでは、よく仕上げた小モデルが汎用の大モデルを上回り、しかも桁違いに安く・速く動くことがあります。OpenPipe や Together、Fireworks がワークフローを提供しています。汎用性は落ちるので「対象タスクを絞れるか」が採否の分かれ目です。
08プロンプトとストリーミングの小ワザ
- 過剰な敬語・前置きを削る（「お手数ですが…」は不要）
- few-shot の例は効く範囲で 1〜2 個に絞る
- 推論モデルでは Chain-of-Thought を明示しなくても内部で実施されることが多い
- JSON Schema で出力を指定すると、安定しつつ後処理も短くできる
- ストリーミング応答は総時間は変わらないが体感が良くなり、継続率＝ROI を底上げする
Measure, Then Optimize
測らない最適化は「劣化」と見分けがつかない
削減策を入れたら必ず効果を測ります。コストだけ見て品質を見落とすと、安くなったのかただ劣化しただけなのか判別できません。最低限、次の指標を継続して見ましょう。
FIG.5 コスト指標と品質指標は必ずペアで監視する
とくにキャッシュヒット率は、設計どおり割引が効いているかの健康診断になります。低ければプロンプト先頭に動的要素が混ざっている可能性が高いので、FIG.2 の設計を疑いましょう。
09施策ごとの削減効果の目安
数字はあくまで目安で、トラフィックの性質やキャッシュヒット率で大きく変動します。自分のワークロードで実測するのが前提です。
| 施策 | 削減効果の目安 |
|---|---|
| プロンプトキャッシュ | キャッシュ読み出し分で50〜90%（プロバイダ依存） |
| モデルカスケード | 全体で45〜85%（品質95%前後を維持） |
| バッチ API | 対象処理で約50%（キャッシュ併用で最大75%減） |
| RAG＋再ランキング | 投入トークン削減で30〜60% |
| 量子化（セルフホスト） | VRAM約75%減（INT4）／精度は要検証 |
| 蒸留（小モデル化） | 対象タスク特化で大幅減（汎用性は低下） |
10導入ロードマップ
まず計測の土台を作る
1リクエスト平均トークン・モデル別比率・キャッシュヒット率・P95・エラー率をログ。ここが無いと効果も劣化も見えない。
軽い順に効く施策を入れる
プロンプトを「静的→動的」に直してキャッシュを効かせ、急がない処理をバッチへ寄せる。
モデルを使い分ける
Light で大半を捌くカスケードを導入。誤エスカレーションを計測しながら判定を磨く。
RAGなら検索と投入を絞る
コンテキスト圧縮＋再ランキングで投入トークンを減らし、精度も同時に底上げ。
必要ならセルフホスト最適化
量があり要件が固まったら量子化・蒸留を検討。必ず自タスクで精度を実測してから採用。
11まとめ
推論コスト最適化は、効果と手軽さの順で 「キャッシュ ＋ カスケード ＋ コンテキスト圧縮」 の3点がまず大きく効きます。重要なのは、すべてを一度に入れようとせず、計測の土台を先に作り、安い順に段階導入して、コストと品質を必ずペアで見ること。料金体系もモデルのラインナップも頻繁に変わるので、割引率や型番は公式の最新情報で確認しながら、自分のワークロードで実測して仕組み化していきましょう。
