LLM を組み込んだアプリは、PoC では月数千円だった API 費用が、本番でユーザーが増えた途端に月数十万円・数百万円へ跳ね上がることがあります。しかも厄介なのは、コストを下げようとすると品質が落ち、品質を守ろうとすると費用が膨らむ、というトレードオフに見えてしまう点です。

実際には、両者を天秤にかける前に削れる無駄がかなりあります。本記事では、AI 駆動開発のクリエイティブスタジオとして LLM アプリを運用してきた経験から、品質を落とさずにコストを半分前後まで下げるための打ち手を、効果と実装コストの観点で優先順位を付けて整理します。発注前にランニングコストを見積もりたい方にも、すでに運用していて費用に悩んでいる方にも使える内容です。

LLM アプリのコストはどこで膨らむか - 構造を分解する

最適化の前に、まず費用がどこで発生しているかを分解します。LLM の従量課金は基本的に「入力トークン × 単価 + 出力トークン × 単価」で決まり、ここに使うモデルのグレードが効いてきます。アプリ全体のコストは、おおまかに次の 4 つの掛け算で表せます。

  • リクエスト回数(ユーザー数 × 1 ユーザーあたりの呼び出し頻度)
  • 1 リクエストあたりの入力トークン(プロンプト + 参照文書 + 履歴)
  • 1 リクエストあたりの出力トークン(生成する文章の長さ)
  • 使用モデルの単価(グレードによって 10 倍以上の差がある)

重要なのは、多くのチームが「リクエスト回数」だけを見て、残り 3 つの掛け算要素に無頓着なことです。実際に費用を分解してみると、ごく一部の機能が全体の大半のトークンを消費していたり、毎回まったく同じシステムプロンプトを何千トークンも送り続けていたりと、改善余地が掛け算で効く形で眠っているのが普通です。

まず取り組むべきは、機能単位・モデル単位でトークン消費を計測することです。これをせずに「とりあえず安いモデルに変える」と動くと、効果の小さい場所をいじって品質だけ落とす、という最悪の結果になりかねません。コスト構造を数字で押さえてから、効果の大きい順に手を付けていきます。

モデルの使い分け - タスク別の Opus / Sonnet / Haiku 戦略

最も効果が大きいのがモデルの使い分けです。Claude を例に取ると、Opus・Sonnet・Haiku のように推論能力と単価の異なるモデルが用意されており、その単価差は用途によって数倍から十数倍に及びます。全リクエストを最上位モデルで処理しているなら、そこに大きな削減余地があります。

判断の軸は「そのタスクにどれだけの推論能力が必要か」です。経験則として、次のように振り分けると品質とコストのバランスが取りやすくなります。

  • 分類・ルーティング・短い抽出・形式変換などの定型タスク → 下位モデル(Haiku 相当)
  • 一般的な要約・問い合わせ応答・コード補完などの中位タスク → 中位モデル(Sonnet 相当)
  • 複雑な推論・長文の統合・難易度の高い設計判断 → 上位モデル(Opus 相当)

特に効くのが、1 つの処理を複数ステップに分けて、ステップごとにモデルを変える設計です。たとえば「ユーザーの意図を分類する → 必要な情報を抽出する → 最終回答を生成する」というパイプラインなら、前段の分類・抽出は下位モデルに任せ、最終回答だけ上位モデルを使う、といった割り当てができます。前段で安いモデルが入力を整理しておくことで、高いモデルに渡すトークン量も減り、二重に効いてきます。

注意点は、安いモデルへの切り替えは必ず自社のデータで評価してから決めることです。「Haiku でも十分だろう」という思い込みで切り替えて品質が落ちると、本来 LLM に任せたかった価値そのものが損なわれます。代表的な入力セットでモデルを比較し、許容ラインを満たす最も安いモデルを選ぶプロセスは、後述の評価の仕組みに組み込んでおくと継続的に運用できます。評価基盤そのものの作り方は LLMOps と評価ハーネスの実装 で詳しく扱っています。

プロンプトキャッシュとコンテキスト設計でトークンを減らす

次に効くのが入力トークンの削減です。ここは「プロンプトキャッシュ」と「コンテキスト設計」の 2 つに分けて考えます。

プロンプトキャッシュは、システムプロンプトや参照文書のようにリクエスト間で共通する長い固定部分をキャッシュし、その部分の入力単価を大きく下げる仕組みです。チャットボットやドキュメント検索のように、毎回同じ前提・同じ指示文を送る用途では効果が顕著です。固定ブロックを先頭に置き、可変部分を後ろに置くようにプロンプトを構造化すると、キャッシュが効く範囲を最大化できます。同じ前提を何千トークンも毎回フルで送っている箇所があれば、ここは優先的に着手すべきポイントです。

コンテキスト設計は、そもそも送るトークン量そのものを減らす取り組みです。実務でよく見かける無駄は次のようなものです。

  • 使われない情報まで参照文書を丸ごと詰め込んでいる
  • 会話履歴を無制限に積み上げて毎回全部送っている
  • 検索で取ってきた候補を絞り込まずに全件渡している

これらは、参照文書を必要な範囲に絞る、履歴を要約して圧縮する、検索結果を関連度で上位数件に絞る、といった設計で削減できます。RAG を使っている場合は、検索の精度を上げて渡す文書数を減らすこと自体がコスト削減に直結します。出力側も同様で、不要に長い生成を避けるよう最大トークン数や出力形式を指定するだけで、出力単価の無駄を抑えられます。

リトライ・評価・ログのコストを見落とさない

見落とされがちなのが、ユーザーに見えない「裏側」のコストです。最適化の議論はメインの推論呼び出しに集中しがちですが、運用していると次のような費用がじわじわ効いてきます。

ひとつはリトライです。エラー時や出力フォーマットが崩れたときの再実行を無制限に許すと、失敗するリクエストほど何度も呼び出されてコストを押し上げます。リトライ回数に上限を設け、構造化出力やバリデーションでそもそも崩れにくくする設計が効きます。

もうひとつが評価とテストの費用です。品質を守るために LLM の出力を別の LLM で採点する手法(LLM-as-a-judge)は有効ですが、本番の全リクエストを毎回採点すると評価コストが本番コストに匹敵してしまいます。評価はサンプリングして一部だけ採点する、デプロイ前のオフライン評価に寄せる、といった割り切りでコストを管理します。

ログとモニタリングも、入出力を丸ごと保存し続けるとストレージとデータ転送の費用が積み上がります。費用最適化の観点では、コスト分解に必要なメタデータ(用途・モデル・トークン数)は確実に残しつつ、本文の保持期間は割り切る、という設計が現実的です。これらの裏側コストを最初から運用設計に織り込んでおくことが、後から効いてきます。

回答キャッシュとバッチ処理で従量課金を抑える

呼び出しパターンが見えてきたら、リクエスト回数そのものを減らす打ち手に進みます。

回答キャッシュは、同じ入力に対して同じ出力を返してよい場面で、LLM を呼ばずにキャッシュから返す仕組みです。FAQ 応答や定型的な分類のように入力のばらつきが小さい用途では、ヒット率が高くなり費用を直接削れます。完全一致だけでなく、入力をベクトル化して意味的に近い質問のキャッシュを返す「セマンティックキャッシュ」を使えば、表現が違っても同義の質問をまとめられます。ただし誤ったキャッシュを返すと品質に響くので、対象は出力が安定している用途に絞るのが安全です。

バッチ処理は、リアルタイム性が不要な処理を非同期でまとめて投げる手法です。多くの LLM では、即時応答を求めないバッチ用のエンドポイントが通常より低い単価で提供されています。夜間の一括分類、大量データの要約、定期的なレポート生成のように、即応が要らない処理をバッチに寄せるだけで、その分の単価を下げられます。ユーザーの操作に直結するリアルタイム処理と、裏で回せるバッチ処理を切り分ける設計が、コストと体験の両立につながります。

コストを継続監視する仕組みと予算アラート

コスト最適化は一度やって終わりではありません。ユーザーが増えれば費用は伸び、機能を追加すれば新たなトークン消費が生まれます。月末の請求書を見て驚く運用から脱するには、コストを継続的に見える化する仕組みを最初から組み込むことが欠かせません。

実務では次のような仕組みを整えます。

  • リクエストごとに用途・モデル・入出力トークン数を記録し、機能単位でコストを分解できるようにする
  • 日次でコストを集計し、機能別・モデル別の推移をダッシュボードで追えるようにする
  • 予算しきい値を設定し、超過しそうなときにアラートを飛ばす
  • ユーザー単位・テナント単位のレート制限を設け、想定外の大量呼び出しによる費用の急増を防ぐ

こうした仕組みがあれば、「先月より急にコストが伸びた」ときにどの機能が原因かを即座に特定でき、対処も早くなります。コストの可視化は、最適化の前提であると同時に、暴走を防ぐ保険でもあります。

運用コストまで設計する AI 駆動開発の費用設計

ここまで見てきた打ち手は、どれも「作ってから後付けする」より「設計段階で織り込む」方が圧倒的に効果が出ます。モデルの使い分けを前提にパイプラインを組む、キャッシュが効くようにプロンプトを構造化する、コスト計測のログを最初から仕込む、といった判断は、アーキテクチャの初期設計に深く関わるからです。

裏を返すと、ランニングコストを考えずに作られた LLM アプリは、後から最適化しようとしても構造的な手戻りが大きく、削れる費用も限られます。だからこそ、見積もりの段階で「本番でいくらかかるのか」「どこに削減余地を残しておくか」まで含めて設計することが、AI 駆動開発では重要になります。

私たちは AI エージェント開発 や AI 駆動開発 の支援において、機能要件だけでなく運用コストの見積もりと最適化方針までセットで設計しています。品質を守りながら費用をコントロールできる構造を、最初の設計に組み込むことを大切にしています。

LLM アプリの運用コストを含めた開発の進め方や見積もりにお悩みでしたら、お問い合わせ からお気軽にご相談ください。コスト構造の見える化と、品質を落とさない最適化の優先順位づけをご一緒します。