LLMコスト最適化の順序
更新日 September 27, 2026 · 初回公開 September 27, 2026
2026年9月、r/LLMDevsのスレッドで、本番環境のLLMコストを実際にどう抑えているか、開発時間に制約がなければ何をするかが問われました。最も支持された回答の要点は、取り組む順序は一般に考えられているよりずっと重要だというものです。このチームはプロンプトのキャッシュとシステムプロンプトの大幅な短縮から始めました。一方、反復作業を小型モデルに任せるためのファインチューニングは失敗しました。保守の負担が大きく、品質も低下し続けたからです。
効果的な順序
- プロンプトをキャッシュする。 開発時間に対する効果が非常に大きい対策です。Opus 5.5では、キャッシュから読み込む100万トークンは0.20ドル、新規入力の100万トークンは4.00ドルで、この費目では95%の割引になります。システムプロンプト、ツール定義、検索したコンテキストを繰り返し使うなら、まずここから始めます。
- システムプロンプトを短くする。 同じ回答でも強調された点です。冗長な指示は毎回課金対象になります。主に必要なのは開発作業ではなく、明確で簡潔な文章への書き直しです。
- 使っていないツールを削除する。 ツールが呼び出されなくても、定義は毎回のリクエストのコンテキストに含まれます。MCPツール定義のオーバーヘッドと同じ仕組みです。設定から1行削除するだけで継続的に効く場合があります。
- タスクに応じてモデルを振り分ける。 この段階で初めてモデルルーティングの効果を十分に得られます。キャッシュ導入後のルーターは、モデルを切り替える前から処理コストが下がっています。
- バッチ処理するか、後回しにする。 ユーザーへの即時応答が不要な処理には、Batch APIの割引を利用できます。適した非本番トラフィックは最初からバッチに回します。
- ファインチューニングは最後に検討する。 多くのチームが最初に選びますが、この事例では失敗しました。保守負担と品質の変動は、キャッシュやルーティングで既に得られる節約のために、恒常的な運用費を生みます。
なぜ順序が重要なのか
各段階で、次の施策が対象とするトークン数と費用が変わります。ルーティングより先にシステムプロンプトを短くすれば、同じ振り分けロジックでも低価格モデルが扱える処理が増えます。ファインチューニングより先にキャッシュを有効にすれば、調整費用を正当化する対象はキャッシュが効かない処理に絞られます。順序を誤ると、書き直しで不要になったはずのモデル調整や、6万トークンの指示を扱いきれない低価格モデルに送るルーターに二重の費用を払うことになります。
よくある失敗
スレッドでは、反復作業用の小型モデルを調整したことが失敗でした。節約の狙いは理解できます。しかし、作業内容が変わるたびに再学習が必要になり、基盤モデルの更新後には品質差が広がりました。運用負担も大きく、維持が難しくなりました。その作業は処理量の約15%、支出の約2%にすぎなかった可能性があります。小さな節約に大きな継続費用が付いた形です。
一つのリクエストで順番に試す
代表的なリクエストを一つ選び、請求対象トークンと費用を記録しながら各施策を順に適用します。
| 手順 | 変わる点 | 示された一般的な削減幅 |
|---|---|---|
| キャッシュを有効化 | 繰り返す先頭部分をキャッシュから読む | 40–70% |
| システムプロンプトを短縮 | 毎回の未キャッシュトークンを減らす | 10–25% |
| 未使用ツールを削除 | ツール定義の量を減らす | 5–15% |
| ルーティング | 大半の処理に低価格モデルを使う | 30–60% |
| 非本番処理をバッチ化 | 割引料金を利用する | 対象処理の25–50% |
効果は積み重なります。この例では、同じリクエストの費用が80–90%下がることもあります。逆に最初にモデルを調整すると、処理量の15%にしか使えず、ルーティングも元が取れない可能性があります。キャッシュとルーティングの数値は費用面の節約です。ルーティングだけでトークン数が減るわけではありません。
まとめ
キャッシュ、プロンプトの短縮、未使用ツールの削除は、費用とリスクが比較的小さく、効果を重ねられます。次にルーティングとバッチ処理を行い、ファインチューニングは必要なら最後に検討します。重要なのは施策の一覧より実施する順序です。
関連記事
この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 →