改善・モダナイゼーション

既存AI機能のLLMコストを抑える改善ポイント

July 13, 2026
AI活用 AIコスト コスト削減 LLM 既存改善

「AI機能をリリースしたら想定の3倍のAPIコストがかかっている」「ユーザーが増えるほど利益率が下がっていく」——AI機能をプロダクトに組み込んだ企業から、こういった相談が増えています。開発時はPoCの少量データで動作確認しただけで、本番トラフィックでのコストを見積もっていなかった、というケースが典型です。

LLMのAPIコストは、使い方次第で数倍〜数十倍の差が出ます。多くの場合、精度を落とさずにコストを半分以下にする余地が残っています。この記事では、既存のAI機能のコストが膨らむ典型的な原因と、発注者側でも判断できる改善ポイントを整理します。

コストが膨らむ典型的な原因

まず、なぜコストが想定より膨らむのかを分解します。原因はだいたい次の5つに集約されます。

  • 毎回巨大なプロンプトを送っている: システムプロンプトに大量の指示・過去の会話履歴・参考データを毎回丸ごと詰め込み、リクエストごとに数千〜数万トークンを送っている
  • 全処理に高価な最上位モデルを使っている: 分類や要約のような単純なタスクにも、最も高性能で高価なモデルを一律で使っている
  • キャッシュがない: 同じ質問・似た入力が来るたびに毎回APIを叩き直している
  • リトライやエラー処理が雑: タイムアウトや形式エラーのたびに何度もリトライし、そのたびに課金が発生している
  • 不要な情報を渡しすぎている: RAG(検索拡張生成)を使わず、関連しそうな文書を全部プロンプトに詰め込んでいる、あるいは出力トークン数の上限を設定していない

これらは個別の技術問題というより、「PoCの延長のまま本番運用している」ことが根本原因です。PoCの段階でコストは意識されにくく、本番化のタイミングで初めて設計し直す必要が出てきます。この論点はAI PoCが本番化しない理由と、失敗させない進め方でも詳しく扱っています。

削減策1: モデルの使い分け

最も効果が大きいのが、タスクごとに適切なコストのモデルを選ぶことです。

  • 分類・タグ付け・簡単な抽出など「答えがほぼ一意に決まる」タスクは、安価な小型モデルで十分な精度が出ることが多い
  • 複雑な文章生成・多段階の推論が必要なタスクにだけ、高価な上位モデルを使う
  • 「まず安いモデルで処理し、自信度が低い場合だけ上位モデルにエスカレーションする」という二段構成にすると、全体のコストを大きく下げられる

実際に処理内容を棚卸しすると、全リクエストの7〜8割が単純なタスクで、残り2〜3割だけが高度な推論を必要としている、というプロダクトは珍しくありません。ここを最上位モデル一律で回していると、コストの大半を無駄にしていることになります。

削減策2: プロンプトの圧縮とRAGでの文脈の絞り込み

プロンプトに詰め込む情報量そのものを見直します。

  • システムプロンプトの指示文が冗長になっていないか(同じ指示を何度も言い換えていないか)
  • 会話履歴を無制限に送っていないか。直近N件・要約した履歴に置き換えるだけでトークン数は大きく減る
  • 参考データを全文渡すのではなく、RAG(検索拡張生成)で本当に関連する部分だけを検索して渡す構成にする。これはコスト削減だけでなく、無関係な情報によるハルシネーション(誤った出力)を減らす効果もある
  • 出力トークンの上限(max_tokens)を用途に応じて適切に設定する。要約タスクで数千トークンの出力上限を設定したままにしていると、無駄に長い出力に課金され続ける

削減策3: キャッシュとバッチ化

  • プロンプトキャッシュ: 主要なLLM APIには、変化しない部分(システムプロンプトや共通の参考資料)をキャッシュして再利用時のコストを下げる仕組みがある。プロンプト構成を「固定部分」と「可変部分」に分けて設計するだけで対象になる
  • 結果キャッシュ: 同じ入力・類似した入力に対する結果をアプリケーション側でキャッシュし、APIを叩かずに返す。FAQ的な質問応答やタグ付けのような処理では特に効果が大きい
  • バッチ化: リアルタイム性が不要な処理(夜間バッチでのデータ分類など)は、バッチAPIを使うと同じ処理でも大幅に安くなることが多い

精度を落とさず削る勘所

コスト削減で最も怖いのは「安くした結果、出力の質が落ちてユーザー体験が悪化する」ことです。ここは順番が重要です。

  1. まず現状のコスト内訳を可視化する。どのエンドポイント・どのタスクがコストの何割を占めているかを把握しないまま闇雲に削ると、影響の大きい箇所を見誤る
  2. 精度への影響が小さい箇所(分類・抽出などのタスク)から着手し、モデルを軽量なものに切り替えて精度を計測しながら段階的に進める
  3. 削減後は必ず精度の回帰テストを行う。PoC時に使った評価データセットが残っていればそれを使い、なければ主要なユースケースだけでも簡易的な評価セットを作っておく

外注する場合は、この「可視化→段階的な削減→精度の回帰確認」のプロセスを踏んでいるか、削減提案の根拠として実測データを示せるかを確認すると、雑な一律ダウングレードによる品質劣化を避けられます。AI機能の設計・改善はAI・LLM活用の技術支援AI機能の組み込み支援でも対応しています。

まとめ

  • AI機能のAPIコストが膨らむ主因は、巨大プロンプト・モデルの一律使用・キャッシュ不在・雑なリトライにある。まずコスト内訳の可視化から始める
  • モデルの使い分け・プロンプト圧縮とRAG・キャッシュとバッチ化の3方向で、精度を落とさずコストを半分以下にできる余地が多くのプロダクトに残っている
  • 削減は影響の小さい箇所から段階的に進め、必ず精度の回帰確認とセットで行う

torcheeesでは、既存プロダクトのAI機能を対象にした開発診断、継続的な改善が必要な場合は継続的な改善支援を提供しています。まずは現状のAPIコスト内訳と処理内容を一緒に確認するところから始められます。既存プロダクトの改善全般については既存プロダクトの改善、外部チームが最初に見る観点もあわせてご覧ください。お問い合わせフォームからお気軽にご相談ください。

Discuss Your AI × Rails Development

Contact Us
Quick Estimate