LLMコスト最適化とは？API費用を下げる手法とFinOps運用
- Inform用途・部門・モデル別にトークン使用量と費用を見える化
- Optimizeモデルの使い分け、キャッシュ、バッチ化で単価と量を下げる
- Operate予算アラートと定例レビューを設け、部門ごとに費用責任を持たせる
LLMのコストはどんな構造で膨らむのか？
LLMのAPI費用は「トークン数×単価×呼び出し回数」で決まります。費用が膨らむ原因の多くは、入力の肥大化と呼び出し回数の増加です。
生成AIの導入当初はPoC（概念実証）規模の利用にとどまり、費用はほとんど問題になりません。本番展開で利用者が増え、RAGやAIエージェントを組み込み始めると、請求額は予想を超えて伸びやすくなります。最初にコストの構造を分解して把握しておくと、後の打ち手を選びやすくなります。AX（AI Transformation）の全体像と進め方は、AXとは？DXとの違いと5層の構成要素で整理しています。
トークン課金の基本式はどうなっているのか？
OpenAI、Anthropic、GoogleのAPIは、いずれも入力と出力のトークン数に応じた従量課金が基本です。入力と出力では単価が別に設定されています。
基本式は次のとおりです。
月額コスト ≒（入力トークン数×入力単価＋出力トークン数×出力単価）×月間リクエスト数
各社の公式料金ページを見ると、多くのモデルで出力単価は入力単価より高く設定されています。そのため、出力が長くなりやすい用途（文書生成、詳しい説明文など）では出力側の費用が効いてきます。一方、RAGやAIエージェントは毎回大量の文脈を渡すため、入力側の費用が大きくなります。実務では「どちら側のトークンで費用がかかっているか」を最初に切り分けるのが近道です。
コストを押し上げる主な要因は何か？
主な要因は「長いコンテキスト」「AIエージェントの多段呼び出し」「過剰なモデル選定」の3つです。どれも本番化の段階で顕在化します。
| 要因 | 典型的な発生場面 | 膨らむ側 |
|---|---|---|
| 長いコンテキスト | RAGで検索結果を大量に投入、会話履歴の全件送信 | 入力 |
| 多段呼び出し | AIエージェントのツール実行ループ、再試行 | 入力・出力・回数 |
| 過剰なモデル選定 | 分類や抽出などの単純作業に最上位モデルを使用 | 単価 |
| 冗長な出力 | 前置きや繰り返しの多い回答、不要な推論過程の出力 | 出力 |
| 失敗リクエスト | タイムアウトや形式エラーによる再実行 | 回数 |
特にAIエージェントは、1回のユーザー操作の裏で何度もLLMを呼び出します。しかも呼び出すたびに、それまでの履歴を入力し直す構造です。画面上は1回の質問に見えても、内部では数倍から十数倍のトークンを消費していることがあります。本番に出す前に、1タスクあたりの呼び出し回数を計測しておくことをおすすめします。
LLMコストを削減する主な手法は？
削減手法は「入力を減らす」「単価を下げる」「出力を絞る」の3系統に整理できます。効果が大きく、品質への影響が小さいものから着手します。
代表的な手法と、その特徴を表にまとめます。
| 手法 | 主な効果 | 品質リスク | 導入難度 |
|---|---|---|---|
| プロンプトの圧縮・整理 | 入力トークン削減 | 低〜中 | 低 |
| RAGの検索件数・チャンク最適化 | 入力トークン削減 | 中 | 中 |
| プロンプトキャッシュ | 入力単価の割引 | 低 | 低〜中 |
| Batch API（非同期一括処理） | 単価の割引 | 低（ただし即時応答は不可） | 低 |
| 出力長の上限設定・形式指定 | 出力トークン削減 | 中 | 低 |
| モデルの使い分け（ルーティング） | 単価の引き下げ | 中 | 中〜高 |
| 応答キャッシュ（同一質問の再利用） | 呼び出し回数削減 | 中（情報の鮮度） | 中 |
入力トークンはどう削ればよいのか？
最も確実な打ち手は、システムプロンプトの冗長な部分を削ることと、RAGで投入する文書量を絞ることです。
実務で効果が出やすいのは次の4点です。
- システムプロンプトの棚卸し：改修を重ねるうちに指示が重複したり、互いに矛盾したりしていないかを確認します。
- RAGの検索件数を見直す：上位何件を渡すかを評価データで比較し、精度が落ちない最小の件数に絞ります。
- 会話履歴を要約する：古いやり取りは要約に置き換え、全文を毎回送らないようにします。
- 不要なメタデータを除く：HTMLタグや定型的なヘッダーなど、回答に関係しない情報を前処理で取り除きます。
現場の感覚としては、RAGの検索件数を「念のため多めに」設定しているケースが少なくありません。評価セットを用意して件数を段階的に減らしてみると、精度を保ったまま入力を減らせる余地が見つかることがあります。
キャッシュとバッチ処理はどう使い分けるのか？
共通の長い前置きを繰り返し送る処理にはプロンプトキャッシュが向いています。即時応答が不要な大量処理にはBatch APIが向いています。
プロンプトキャッシュは、同じ前置き部分（システムプロンプトや参照文書など）を再利用したとき、その部分の入力単価を割り引く仕組みです。OpenAIとAnthropicはどちらも提供していますが、適用条件（最小トークン数、明示的な指定が必要かどうか）や割引率、キャッシュの保持時間は各社・各モデルで異なります。導入前に公式ドキュメントで確認してください。キャッシュを効かせるには、変わらない部分をプロンプトの先頭に、変わる部分を末尾に置く構成が基本です。
Batch APIは、結果を受け取るまでに一定の待ち時間を許容する代わりに、通常より安い単価で処理できる仕組みです。OpenAIとAnthropicは通常料金から50%割引と案内しています（2026年10月時点。条件は変わる可能性があるため、各社の料金ページで最新情報を確認してください）。夜間の文書分類、過去データへのタグ付け、評価用データの一括生成などは、Batch APIへ切り替えやすい代表例です。
モデルの使い分けとルーティングで何が変わるのか？
タスクの難易度に応じて使うモデルを振り分けると、品質を保ったまま平均単価を大きく下げられます。
「すべての処理に最上位モデルを使う」設計は、PoCの段階では合理的です。精度を確かめることが目的だからです。しかし本番環境では、処理の大半が分類・抽出・定型要約といった比較的単純なタスクであることも珍しくありません。その場合、モデルの使い分けがコスト最適化の中心的な施策になります。
どのタスクにどのモデルを割り当てるべきか？
単純で構造化されたタスクは軽量モデルに、複雑な推論や重要な判断を伴うタスクは上位モデルに割り当てるのが基本です。
| 階層 | 想定タスク | モデルの位置づけ（例） |
|---|---|---|
| 軽量 | 意図分類、定型抽出、短文要約、フォーマット変換 | 各社の小型・高速モデル（OpenAIのminiクラス、AnthropicのHaikuクラス、GoogleのFlashクラスなど） |
| 中位 | 一般的なQ&A、RAGを使った回答生成、文書ドラフト | 各社の標準クラスのモデル |
| 上位 | 複雑な推論、コード生成、AIエージェントの計画立案 | 各社のフラッグシップモデル |
モデル名やラインナップは頻繁に更新されます。社内の設計書には特定のモデル名を固定で書かず、「階層」で定義しておくと、モデル更新時の差し替えが容易になります。
ルーティングはどんな手順で設計するのか？
評価データを先に用意し、タスクごとに「品質基準を満たす最も安いモデル」を選ぶ手順で進めます。
- タスクを棚卸しする：アプリケーション内のLLM呼び出し箇所を洗い出し、用途ごとに分類します。
- 評価セットを作る：用途ごとに代表的な入力と、期待する出力または採点基準を用意します。
- 複数モデルで比較する：同じ評価セットで、品質・レイテンシ・コストを並べて測定します。
- 振り分けルールを決める：まずは用途ごとの固定割り当てから始め、必要に応じて入力内容で動的に振り分けます。
- フォールバックを用意する：軽量モデルの出力が形式チェックに失敗した場合は、上位モデルで再実行します。
- 定期的に再評価する：新しいモデルが出たら、同じ評価セットで比較し直します。
入力に応じて動的に振り分ける仕組みは魅力的ですが、判定ロジックそのものが複雑になりがちです。経験上、まずは用途単位の固定割り当てで効果を確認し、その後に段階的に高度化するほうが運用は安定しやすいと感じます。
LLMコストを継続管理するFinOps体制は？
LLMのFinOpsでは、費用を「機能別・チーム別・ユーザー単位」で可視化し、事業価値と結びつけて継続的に判断します。
FinOpsはクラウド費用を管理する実践として、FinOps Foundationが体系化してきた考え方です。同団体は生成AIの費用管理にもこの枠組みを適用する指針を公開しています。LLMの費用は利用量に連動して日々変わるため、一度最適化して終わりではなく、継続的な運用の仕組みが必要になります。
何を指標として可視化すべきか？
総額だけを見ず、「1タスクあたりのコスト」と「成果あたりのコスト」を追うことが、FinOps運用の核になります。
| 指標 | 定義の例 | 使いどころ |
|---|---|---|
| 機能別コスト | 機能・プロダクト単位の月額API費用 | 予算配分、優先順位づけ |
| 1リクエストあたりコスト | 総費用÷リクエスト数 | プロンプト改修の効果測定 |
| 1タスクあたりコスト | AIエージェントの1タスク完了までの総費用 | エージェント設計の評価 |
| 成果あたりコスト | 1件の問い合わせ解決、1本の文書作成あたりの費用 | 投資対効果の説明 |
| キャッシュヒット率 | キャッシュ適用トークン÷全入力トークン | キャッシュ設計の改善 |
これらを計測するには、LLMを呼び出すたびに機能名・チーム・モデル・トークン数を記録しておく必要があります。各社のAPIキーを直接配布するのではなく、社内のLLMゲートウェイ（プロキシ）を経由させる構成にすると、ログの収集と上限の制御を一か所で行えます。
誰がどんなサイクルで運用するのか？
開発チーム・財務・AX推進部門が役割を分担し、月次で費用と成果を振り返る運用サイクルを回すのが現実的です。
| 役割 | 主な責任 |
|---|---|
| AX推進部門（CoE） | 指標の定義、ゲートウェイの運用、全社横断の最適化施策 |
| 開発チーム | 機能ごとの費用の把握、プロンプトやモデル選定の改善 |
| 財務・経営企画 | 予算策定、予実管理、投資判断 |
| 事業部門 | 成果指標の提供、費用に見合う価値があるかの判断 |
運用サイクルは「可視化 → 最適化 → 運用ルール化」の順で回します。予算の上限やアラートのしきい値は、ゲートウェイ側で機能単位に設定しておくと、AIエージェントの暴走（無限ループなど）による想定外の請求を防ぎやすくなります。
LLMコスト最適化で失敗しないための注意点は？
失敗の多くは、品質評価をせずに削減を進めることと、単価だけでモデルを比べることから生じます。
コスト最適化は「削れるところを削る」作業に見えますが、生成AIでは削った結果が品質にどう影響するかが見えにくいことに注意が必要です。
品質劣化はどうすれば見落とさずに済むのか？
最適化の前後で同じ評価セットを使って比較し、品質の基準を下回る変更は採用しないルールを設けます。
プロンプトの短縮、RAGの検索件数の削減、軽量モデルへの切り替えは、いずれも回答品質を下げる可能性があります。避けたいのは「費用は下がったが、利用者が回答を信用しなくなり、使われなくなった」という結果です。費用の指標と並べて、正答率やユーザー評価、人手による修正率などの品質指標を必ずモニタリングしてください。
単価以外に何を比較すべきか？
トークン単価だけでなく、必要なトークン数、再試行率、レイテンシ、運用の手間まで含めた総コストで比較します。
単価の安いモデルでも、指示に従わず再試行が増えれば、総コストはかえって高くなることがあります。また、同じ文章でもモデルによってトークン数の数え方（トークナイザー）が異なるため、単価表だけを並べた比較では実態を正しく反映できません。実際の業務データで1タスクあたりの総コストを測るのが確実です。
あわせて、特定ベンダーの独自機能に深く依存すると、価格改定やモデルの提供終了（廃止予定の告知）に対応しにくくなります。ゲートウェイでAPI呼び出しを抽象化し、複数のモデルを切り替えられる構成にしておくことは、コスト面だけでなく事業継続の観点からも有効な備えです。
LLMのコスト最適化は、技術的な小手先の節約ではなく、AXの投資対効果を説明できる状態をつくる取り組みです。構造の把握、削減手法の適用、モデルの使い分け、FinOps運用を段階的に積み上げることが、生成AIの全社展開を持続させる土台になります。
