LLMコスト削減の実践ガイド｜FDEが現場で使う手法と優先順位

LLMのコストは何で決まるのか？

LLMのコストは「トークン単価×トークン量×呼び出し回数」でほぼ決まります。最初に見るべきなのは、長い入力と出力の量です。

LLMのAPI利用料は、多くの商用モデルで「入力トークン」と「出力トークン」それぞれの単価に、使った量を掛けて計算されます。月額固定のSaaSとは違い、利用が増えればそのまま請求額も増えます。PoCでは気にならなかった金額が、本番運用で数十倍に膨らむのはこのためです。

トークン単価はモデル選択でどう変わるのか？

トークン単価はモデルの性能帯で大きく変わります。同じプロバイダでも、上位モデルと軽量モデルでは桁が違うこともあります。

Anthropic、OpenAI、Googleなどの主要プロバイダは、性能と価格の異なるモデルを複数そろえています。上位モデルは複雑な推論に強い一方、単価は高めです。分類や抽出のような定型処理なら、軽量モデルで足りることもよくあります。単価は頻繁に改定されるため、試算の前には必ず各社の公式料金ページで最新の値を確認してください。

入力・出力・呼び出し回数はどれが効きやすいのか？

効きやすいのは、毎回付く長い入力と、多くのモデルで単価が入力より高く設定されている出力です。

入力側では、システムプロンプトや会話履歴、RAGで取ってきた文書が、呼び出しのたびに積み上がっていきます。出力側は1回あたりの量は少なくても、単価が入力の数倍に設定されていることが多いモデルでは、冗長な出力がそのままコストに響きます。さらにAIエージェント型の構成では、1つのタスクで何度もモデルを呼び出すため、呼び出し回数が掛け算で効いてきます。

LLMコスト削減の主な手法は？

主な手法は、モデルの使い分け、プロンプトの圧縮、キャッシュ、バッチ処理、コンテキスト設計の5つです。

どの手法も「単価を下げる」「量を減らす」「回数を減らす」のどれかに当てはまります。下の表は手法ごとの特徴を整理したものです。効果の大きさはユースケースによって変わるため、相対的な目安として見てください。

モデルの使い分けはどう設計するのか？

処理の難易度ごとにモデルを割り当てるのが基本です。軽い処理を軽量モデルに移すだけでも、単価は下がります。

よく使うのは、「分類・抽出・整形」は軽量モデル、「複雑な推論・最終回答の生成」は上位モデル、という役割分担です。入力の難易度を軽量モデルやルールで判定してから振り分ける「ルーティング」もあります。ただ、判定を間違えると品質が落ちるので、後で述べる評価セットで振り分けの精度を確かめることが前提です。

プロンプトキャッシュとバッチ処理はどれくらい効くのか？

プロンプトキャッシュとバッチ処理は品質を変えずに単価を下げられるため、費用対効果の高い施策です。

プロンプトキャッシュは、毎回同じ先頭部分（システムプロンプトや参照文書など）を再利用し、その部分の入力単価を下げる仕組みです。たとえばAnthropicの公式料金では、キャッシュから読み出した入力は通常の入力単価の1割と案内されています（キャッシュへの書き込みには割増があります）。バッチ処理は、即時応答を求めない代わりに割引価格で処理する仕組みです。AnthropicのMessage Batches APIもOpenAIのBatch APIも、通常料金から50%引きと公式に案内されています。条件や割引率は変わることがあるので、採用前に最新のドキュメントを確認してください。

プロンプトとコンテキストはどう削ればよいのか？

まず、毎回渡している情報が本当に必要かを見直します。そのうえで、出力の形式と長さを指示で絞ります。

現場でよく見かけるのが、「念のため」と全文を渡しているマニュアルや、無制限に溜まっていく会話履歴です。RAGで取ってくる件数とチャンクの大きさを見直す、履歴は要約してから渡す、出力はJSONスキーマや文字数の上限で絞る。地味な施策ですが、品質への影響を抑えながら量を減らせます。

どの順番でLLMコスト削減に取り組むべきか？

計測、低リスクな施策、モデル変更の順に進めるのが安全です。いきなりモデルを替えるのは避けてください。

現場で起こりがちなのが、「高いから安いモデルに替えよう」と最初に決めてしまい、品質が落ちて現場から苦情が出るパターンです。品質を変えずに削れる部分から手を付けるほうが、関係者の合意も得やすくなります。

1. 計測する：機能別・プロンプト別・ユーザー別に、トークン量と呼び出し回数を記録する
2. 上位の支出源を特定する：支出の大半を占める少数の処理に絞り込む
3. 品質に影響しない施策を入れる：プロンプトキャッシュ、バッチ化、リトライの抑制、重複呼び出しの排除
4. 量を減らす：プロンプトの圧縮、出力形式の制約、コンテキストの絞り込み
5. 評価基盤を用意する：代表的な入力と期待する出力のセットを作る
6. モデルの使い分けを試す：評価セットで比較しながら、軽量モデルへ段階的に移す

なぜ最初に計測が必要なのか？

何にどれだけ使っているかが分からないと、効果の大きい施策を選べないからです。計測がすべての起点になります。

請求書の合計額だけでは、どの機能がコストを押し上げているのか分かりません。リクエストごとに入力トークン数、出力トークン数、モデル名、機能名をログに残し、日次で集計するところから始めます。LLM向けの監視ツールやゲートウェイを使うと、この可視化は比較的早く整えられます。

低リスクな施策から着手すると何がよいのか？

低リスクな施策から始めると、品質の議論をしなくても削減効果が出ます。社内の信頼を得るうえでも有効です。

キャッシュやバッチ化は出力の中身を変えないので、品質保証の手続きを軽くできます。最初の成果を「品質はそのままでコストだけ下がった」という形で示せれば、次に来るモデル変更のようなリスクのある施策にも、合意を取りやすくなります。

FDEはLLMコスト削減で何を担うのか？

FDEは顧客の現場に入り、業務要件とコストの釣り合いを技術面から設計し、運用できる形で定着させる役割です。

FDE（Forward Deployed Engineer）は、Palantirで広まった職種で、顧客の現場に深く入って課題解決まで実装する点に特徴があります。LLMのコスト削減は、技術の工夫だけでは終わりません。「どの業務でどの品質が必要か」を顧客と詰めていく作業そのものです。だからこそ、FDEの価値が出やすい領域だと考えています。

顧客の現場でまず何を可視化するのか？

業務の単位で「1件あたりいくらかかっているか」を可視化します。そうすると、技術の指標を経営の言葉に置き換えられます。

「月に何百万トークン」と伝えても、顧客の意思決定者には響きにくいものです。「問い合わせ1件の対応に何円」「帳票1枚の処理に何円」と業務の単位に直すと、人手で処理した場合との比較や、投資判断の材料として使えるようになります。この翻訳は、現場の業務を理解しているFDEだからこそできる仕事です。

業務要件とコストのバランスをどう合意するのか？

処理ごとに求められる品質を顧客と取り決め、上位モデルを使う範囲を明確にします。そのうえで合意を取ります。

すべての処理に最高品質が必要なわけではありません。社内向けの下書き生成と、顧客に送る最終回答とでは、許容できる誤りの水準が違います。FDEは現場担当者へのヒアリングを通じてこの線引きをはっきりさせ、「この業務は軽量モデルで十分」「この判断だけは上位モデルを使う」といった方針を、顧客の意思決定者と一緒に決めていきます。

LLMコスト削減で品質を落とさないためには？

品質を守る鍵は、削減施策の前に評価セットを用意し、段階的に切り替え、継続的に監視することです。

コスト削減の失敗の多くは、「なんとなく大丈夫そう」で切り替えた結果、品質の低下に気づくのが遅れることで起きます。削減と評価を常にセットで回す体制が必要です。

評価セットはどう作ればよいのか？

本番の代表的な入力と期待する出力を数十〜数百件そろえ、変更のたびに自動で採点できる状態にします。

評価セットには、よくある入力だけでなく、過去に誤答が問題になった事例や境界的なケースも入れておくと効果的です。採点は、完全一致やルールで判定できる項目と、LLMを評価者として使う項目とを組み合わせます。評価の基準は、顧客の現場担当者と一緒に決めておくのが理想です。

削ってはいけない領域はどこか？

誤りの影響が大きい判断や、顧客に直接届く出力は、コストより品質を優先すべき領域です。

金額や契約にかかわる判断、医療や安全に関する情報、外部に送られる最終回答では、多少コストが高くても上位モデルと人によるチェックを残すことをおすすめします。コスト削減の目的は、浮いた予算を価値の高い処理に回すことです。品質を犠牲にして削減率を追うと、長い目で見るとLLM活用そのものへの信頼を失いかねません。

本記事で触れた料金体系や割引率は、執筆時点で各社の公式ドキュメントに記載されている内容に基づいています。LLMの料金は頻繁に改定されるため、導入前に最新の公式情報を確認してください。現場実務に関する記述は監修者の確認を経て公開しています。

姉妹メディアの関連記事