2026年半ばの時点で、本番環境のAIアーキテクチャにおいて最もよく見られる誤りは、推論に過剰な費用を払うことです。チームはLLM機能をリリースし、動作を確認しますが、その後、利用量とともに増え続ける月額5桁の請求に直面します。採算が取れなくなる機能もあれば、コストを適切に管理すれば成立したはずの機能を廃止する企業もあります。
ほとんどのLLM利用料は、必要額を大幅に上回っています。削減は1つの魔法のような手法から生まれるのではなく、個別には控えめな効果を持つ最適化を積み重ねることで実現します。
本記事では、手法、数値、本番環境で求められる規律を解説します。基本的なモデルルーティング（別の記事で説明済み）は実施していることを前提に、さらに深く掘り下げます。
コストの構成
LLMのコストは、次の要素から生じます。
- 入力トークン。 モデルへ送信する内容です。システムプロンプト、コンテキスト、ユーザーの質問が含まれます。
- 出力トークン。 モデルが返す内容です。通常は入力より4～6倍高価です（Anthropicは5倍、OpenAIは現在の定価で約6倍。モデルと価格のリファレンスを参照、2026-07-07検証済み）。
- 推論トークン。 推論モデルが内部で「思考」するためのトークンです。多くの場合、出力トークンと同程度の費用がかかります。
- ツール呼び出し。 ツール呼び出しを使用する場合、各ツールの定義も入力トークンになります。
- 再試行。 失敗した呼び出しにも費用がかかります。
各レイヤーで最適化できます。
手法1：プロンプトキャッシュ
最大の効果を得られる単一の施策です。現在の主要プロバイダーの多くは、繰り返される入力プレフィックスをキャッシュします。初回は通常料金を支払いますが、同じプレフィックスを使う後続の呼び出しは大幅に安くなります。
一般的な料金：
- Anthropic：キャッシュ済み入力は通常料金の約10%。
- OpenAI：プレフィックス一致時に自動適用され、通常料金の約50%（モデルにより異なる）。
- Google：明示的にキャッシュするコンテンツで、料金は場合により異なる。
仕組みは次のとおりです。特定の入力プレフィックスを使ったモデルへの初回呼び出しは通常料金です。キャッシュ有効期間内（通常は5～60分、プロバイダーにより異なる）の後続呼び出しでは、キャッシュされた表現が再利用されます。
実践的な実装：
静的なコンテンツを先、動的なコンテンツを後に配置するよう、プロンプトを構成します。
[キャッシュ対象：10Kトークン]
- システムプロンプト
- ツールの説明
- ユーザーの静的プロフィール
- 呼び出しごとに変わる可能性が低いナレッジベースの抜粋
[キャッシュ対象外：1Kトークン]
- 会話履歴（ターンごとに変わる）
- 現在のユーザーの質問
最初の10Kトークンは、初回呼び出し後にキャッシュされます。後続の呼び出しでは、その部分について約10%の料金を支払い、1Kトークンについて通常料金を支払います。
削減例：
キャッシュなし：
- 11K入力トークン × €3／100万トークン = 1回あたり€0.033。
- 1日100K回の呼び出し = 1日€3,300。
キャッシュあり（入力の90%をキャッシュ）：
- 1Kは通常料金 + 10Kは10%のキャッシュ料金：
- 1K × €3／100万トークン + 10K × €0.30／100万トークン = €0.003 + €0.003 = 1回あたり€0.006。
- 1日100K回の呼び出し = 1日€600。
82%の削減です。 実際の数値であり、実際のシステムで実現できます。
実装上の規律：
- プロンプトの静的な部分と動的な部分を特定する。
- 静的な部分を先に配置する。
- プロバイダーが対応している場合（Anthropic）は、明示的に制御するためキャッシュマーカーを使用する。
- キャッシュヒットをテストする。可観測性の仕組みでキャッシュヒット率を確認できるようにする。低い場合は、プロンプトの構造が適切ではない。
これは最もROIの高い最適化です。何より先に実装してください。
手法2：モデルルーティング
詳細は別の記事で解説しています。要点は、複雑さに応じてリクエストを異なるモデルへ振り分けることです。
- リクエストの60%を小規模モデルへ。
- 30%を中位モデルへ。
- 10%を最上位モデルへ。
すべてに最上位モデルを使う場合と比べた一般的な削減率は60～80%です。
キャッシュと組み合わせれば、単純なベースラインから90%以上削減できます。
手法3：出力長の制御
ほとんどのユースケースでは、出力トークンがコストの大部分を占めます。通常、入力コストの4～6倍であり、その量はモデルとプロンプトによって決まり、多くの場合は必要以上に長くなります。
戦略：
長さを明示的に指示する。
100語以内で回答してください。
モデルはこの指示に比較的よく従います。出力コストを大幅に削減できます。
構造化出力。
ユーザーに見せる回答が短い構造化データ（特定のフィールドを持つJSON）なら、出力量に上限ができます。不必要に冗長になる心配もありません。
max_tokensパラメーター。
必ず設定してください。デフォルトのままにしないでください。200トークンで十分なら、少し余裕を持たせて最大値を250に設定します。モデルはそれを超えられません。
形式の制約。
「箇条書きのみ」や「1段落のみ」と指定すると、自由形式より短い出力になります。
文章より箇条書き。
箇条書きは通常、同じ情報を伝える文章の半分程度のトークンで済みます。
前置きなし。
「導入の言葉を省き、すぐに回答してください」。モデルはしばしば「良い質問ですね」「説明しましょう」といった無駄なトークンを出力します。
削減例：
要約ワークフローを考えます。デフォルトの出力は500トークン、制約後は200トークンです。
- 500トークン × €10／100万トークン = 1回あたり€0.005。
- 200トークン × €10／100万トークン = 1回あたり€0.002。
出力コストを60%削減できます。キャッシュによる90%削減ほど目立ちませんが、最大のコスト項目に効きます。
手法4：出力サンプリングと早期停止
ユースケースによっては、LLMの完全な出力は必要なく、判断や分類だけで十分です。
分類にlogprobsを使う。
# ここでは小規模な非推論モデルを使う。推論系モデル
# （GPT-5.xのthinking tierなど）はlogprobs/logit_biasを受け付けない。
response = openai.chat.completions.create(
model=SMALL_NON_REASONING_MODEL,
messages=[{"role": "user", "content": prompt}],
logprobs=True,
top_logprobs=5,
max_tokens=1
)
# 最初のトークンのlogprobsを読み、可能性の高いカテゴリーを判断する
モデルに1トークン（カテゴリー）だけを出力させます。コストは入力1回分と出力1トークン分です。高速かつ安価で、多くの場合、長い回答と同等の結果が得られます。
ロジットバイアス。
既知の選択肢から出力させる場合は、有効な選択肢のロジットにバイアスをかけます。
import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o-mini")
# logit_biasのキーは（文字列化した）トークンIDであり、単語ではない。
bias = {str(enc.encode(w)[0]): 100 for w in (" yes", " no", " maybe")}
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[...],
logit_bias=bias,
max_tokens=1,
)
モデルが適切な種類の出力を生成するよう誘導します。分類において安価で信頼できる方法です。
手法5：バッチ処理
多数の項目を処理する場合は、バッチ化します。
APIレベルの非同期バッチ処理。
ほとんどのプロバイダーは、複数のリクエストを低コストで処理する非同期APIまたはバッチAPIを提供しています。
- OpenAI Batch API：50%割引、24時間のSLA。
- Anthropic Message Batches：50%割引、24時間のSLA。
リアルタイムの応答を必要としない未処理の作業は、バッチで実行してください。コストが半分になります。
プロンプト内でのバッチ処理。
可能な場合は、1回のLLM呼び出しで複数の項目を処理します。
次の代わりに、
[それぞれ1件のチケットを分類する、個別の呼び出し10回]
次のようにします。
[1つのプロンプトで10件のチケットを分類する、1回の呼び出し]
1回の呼び出しに含まれる入力（10項目）は増えますが、固定オーバーヘッド（システムプロンプト、ツールの説明）は1セットだけです。総トークン数は、個別に10回呼び出す場合より少なくなります。
ただし、1つのプロンプトに含める項目が多すぎると品質が低下する場合があります。自社のユースケースで最適な点をテストしてください。通常は、プロンプト1件あたり5～20項目であれば問題ありません。
手法6：範囲の狭いタスクに小規模モデルを使う
標準的なルーティングからさらに踏み込み、タスクに本当に大規模モデルが必要かを検討します。
分類： 単純な分類では、小規模モデルでも最上位モデルと同程度の結果を得られることがよくあります。現在の定価（2026-07-07検証済み）では、Claude Haiku 4.5が100万トークンあたり$1／$5、Claude Opus 4.8が$5／$25で、ちょうど5倍の差があります。OpenAIの小規模モデル群とGPT-5.5の間にも、同程度の倍率差があります。
抽出： 構造化抽出には中位モデルで対応できます。最上位モデルは、失敗するケースのために温存してください。
翻訳： 特化型翻訳モデルや小規模LLMで、ほとんどのケースに対応できます。
埋め込み： 埋め込みには汎用LLMではなく、埋め込み専用モデルを使用してください。
基本となるパターンは、「単純で範囲の狭い」ワークロードを特定し、十分な品質で処理できる最小のモデルへルーティングすることです。複雑で判断を多く要する作業のために最上位モデルを残します。
手法7：ファインチューニングした小規模モデル
処理量が非常に多く、範囲の狭いタスクでは、小規模モデルをファインチューニングします。
例：1日100K件の分類リクエスト。
- 未調整のGPT-5：APIコストは1日€30。
- 専用推論基盤上のファインチューニング済み8Bモデル：推論コストは1日€5～10。これに1回限りのファインチューニング費用が加わります。
十分な処理量があれば、ファインチューニングした小規模モデルは短期間で投資を回収できます。計算結果は処理量によって変わります。
ファインチューニングの記事で詳しく説明しました。原則は、規模が大きく範囲が狭い条件がそろったとき、ファインチューニングがコスト削減手段になるということです。
手法8：事前フィルタリング
多段階のLLMワークフローでは、安価なフィルタリングによって、高価な処理の前に明白なケースを捉えます。
例：カスタマーサポートの分類と回答。
安価な事前フィルター：
- 「これは実際のサポート質問か、それともスパム／ノイズか」（小規模モデルによる1トークンの分類）。
- 「これは既知のFAQか」（安価な埋め込み検索）。
フィルターを通過したリクエストだけが、高価な回答生成に進みます。
節約効果：受信リクエストの30%がノイズまたはFAQで処理できるなら、高価な呼び出しを30%削減できます。
事前フィルターは、回答生成（1回あたり€0.05）と比べて安価です（1回あたり€0.0001）。容易にROIを得られます。
手法9：プロンプトキャッシュ以外のキャッシュ
モデルプロバイダーのプロンプトキャッシュに加え、アプリケーションレベルでもキャッシュします。
レスポンスキャッシュ。 同じ質問、同じコンテキスト、同じ回答なら、キャッシュしてモデルを呼び出さずに返します。
def cached_call(prompt, model, ttl=3600):
cache_key = hash(prompt + model)
cached = redis.get(cache_key)
if cached:
return cached
response = call_llm(prompt, model)
redis.set(cache_key, response, ttl=ttl)
return response
冪等なクエリでは、重複する呼び出しを完全に排除できます。
埋め込みキャッシュ。 計算済みの埋め込みをキャッシュします。
検索結果キャッシュ。 クエリの検索結果を短時間キャッシュします。
ツール結果キャッシュ。 基となるデータが頻繁に変わらない場合は、ツール呼び出しの結果をキャッシュします。
キャッシュは各レイヤーで積み重ねられます。レイヤーごとに呼び出しを削減できます。
手法10：投機的実行
次のステップを予測でき、レイテンシーが重視されるフローでは、投機的に事前呼び出しを行います。
例：カスタマーサポートエージェント。顧客が問題を説明した後は、通常「問題を要約する」ステップに進むと分かっています。ユーザーに受領確認を表示する処理と並行して、要約を開始します。
予測が当たれば、必要な時点で回答の準備ができています。外れれば、1回の呼び出しが無駄になります。
これはコストよりレイテンシーの最適化ですが、一部のフローではUXを大きく改善します。
手法11：プロバイダー間の価格差の活用
同等のモデルでも、プロバイダーによって料金は異なります。その差を活用します。
安価な推論プロバイダー上のオープンソースモデル。
Together AI上のLlama 3.3 70B：入力、出力ともに$0.88／100万トークン（定価、2026-07-07検証済み）。 競合するクローズドモデル層であるClaude Sonnet 5：入力$3／100万トークン、出力$15／100万トークン（2026-08-31までの導入価格は$2／$10）。
オープンな70Bモデルで十分なタスクでは、入力で約3.4倍、出力で約17倍の差になります。入力と出力の比率に応じて、3～17倍と考えられます。
異なるプロバイダー上の同一モデル。
一部のオープンモデルは、料金の異なる複数のプロバイダーでホストされています。比較して選んでください。
大規模利用時の自社運用。
特定のモデルに十分な利用量（たとえば月€10K以上）があれば、自社運用の方がAPI呼び出しより安価になります。運用能力は必要です。
プロバイダー間の価格差を活用すると、複雑さが増します。フォールバックを備えたマルチプロバイダーのルーティングや、各プロバイダー版での品質テストが必要です。大規模環境では、その価値があります。
手法12：推論の高速化
自社運用の場合は、推論レイヤー自体を最適化します。
vLLM、TGI、SGLang。 最適化された推論サーバーです。単純な実装と比べてスループットが2～10倍になります。
量子化。 モデルを低い精度（4ビット、8ビット）で実行します。品質への影響は小さく、スループットは2～4倍になります。
Flash Attention、ページドアテンション。 現代的なサーバーで利用できるアーキテクチャ上の最適化です。
継続的バッチ処理。 実行中のリクエストをバッチ化し、GPU使用率を向上させるサーバーです。
大規模な自社運用を行うチームには重要です。APIを使用するチームでは、プロバイダーが対応します。
手法13：ストリーミング
ストリーミングはトークン数を減らしませんが、UXを改善します。費用対効果に対する体感という点で重要です。
長い出力では、コンテンツがすぐに表示され始めます。生成が完了するまでの間に、ユーザーは読み進められます。回答全体が完成するまで待つより、はるかに速く感じられます。
エージェントでは、中間ステップをストリーミングすることで、進捗をユーザーに示せます。
実装については、現在の主要APIはすべてストリーミングに対応しています。ユーザー向けのフローで使用してください。
手法14：予算ガード
最適化に加えて厳格な予算上限を強制し、コストの暴走を防ぎます。
リクエストごとの予算。 リクエストごとの最大トークン数です。超過したら停止します。
ユーザーごとの予算。 ユーザーごとの1日または1か月のコスト上限です。上限が近づいたらスロットリングします。
機能ごとの予算。 機能ごとに予算を設けます。1日の平均の10倍に達したら自動停止します。
全体予算。 1日または1か月の総額上限です。上限に近づいたら、必須ではない処理を一時停止します。
これらは費用を直接削減するわけではありませんが、大惨事を防ぎます。ガードがなければ、1つのバグや攻撃だけでコストが急速に膨れ上がります。
実例：実際のコスト削減
カスタマーサポートAIを運用していたあるチームには、月額€12,000の利用料がかかっていました。6か月後、各手法を適用した結果、月額€1,800になり、85%削減できました。
変更内容：
-
プロンプトキャッシュ。 静的なプレフィックスを最大化するようプロンプトを再構成しました。現在は入力の約70%がキャッシュされています。約30%削減しました。
-
モデルルーティング。 分類とチケットの振り分けをClaude SonnetからClaude Haikuへ移行しました。約15%削減しました。
-
出力長の制御。 以前は800～1500語だった回答を250語に制限しました。約25%削減しました。
-
事前フィルタリング。 安価な分類でFAQとして処理できるチケットを検出し、キャッシュから提供します。高価なフローに進むチケットを約20%減らしました。約10%削減しました。
-
FAQのレスポンスキャッシュ。 同一の質問にはキャッシュ済みの回答を返します。約5%削減しました。
記載した割合は、それぞれの手法が最終的な約85%の削減に占める比率です。合計すると全体の約85%になり、各値は前の変更後に残った利用料を基準として測定されています。自社の利用料へそのまま適用できる独立した乗数ではありません。
品質は、測定したすべての指標（顧客満足度、回答の正確性、解決率）で変わらないか、わずかに改善しました。
運用コストは3か月間で約80エンジニア時間でした。ROIは2週間で回収できました。
よくある誤り
よく見られるパターンをいくつか挙げます。
誤り1：コストを追跡していない。 機能、ユーザー、呼び出しごとのコストをチームが把握できていません。測定しなければ最適化できません。
誤り2：間違った項目を最適化する。 出力トークンが請求額の80%を占めているのに、入力トークンを5%減らすため数週間を費やします。まず測定し、最大の要因を最適化してください。
誤り3：品質の低下。 品質監視なしでコスト削減をリリースしました。費用は減りましたが、ユーザーを失いました。コスト改善には必ず評価スイートを組み合わせてください。
誤り4：過剰なルーティング。 小規模モデルでは実際には処理できないタスクまで積極的に振り分けます。見せかけの削減です。
誤り5：キャッシュの汚染。 まれなクエリでキャッシュが埋まります。ほとんどのキャッシュエントリは1回しか使われず、キャッシュミスが支配的になります。より適切なキャッシュ戦略が必要です。
誤り6：バッチAPIを使わない。 バッチで十分なのにリアルタイム処理を使います。半額にできる機会を逃しています。
誤り7：過剰な設計。 そもそも採算の合わない機能の上に、手の込んだコスト最適化を構築します。「その機能を廃止する」ことが正解の場合もあります。
誤り8：予算ガードがない。 1つのバグでコストが暴走します。小さな不都合ではなく、大惨事になります。
文化的な側面
コスト規律には文化的な側面もあります。成功するチームは次のように行動します。
- コストを後付けの検討事項ではなく、指標として扱う。
- 担当者を置く（多くの場合、エンジニアリング部門と財務部門の接点にいる人物）。
- 週次指標でコストをレビューする。
- 急増を即座に調査する。
- 機能ごとに予算を設定し、しきい値を超えたら通知する。
- トレードオフ（コスト対品質対レイテンシー）を明示的に判断する。
成功しないチームは次のように行動します。
- コストを他人の問題として扱う。
- 月末になって利用料を知る。
- 急増が起きた後に対応する。
- 予算という概念がない。
- トレードオフに関する議論をせず、一度に1つの側面だけを最適化する。
文化を変えることは、技術を変えることより困難です。しかし、技術的な変更を定着させるのは文化です。
価格の推移
より大きな傾向について補足します。
能力の単位あたりのコストは、年々急速に低下しています。主な理由は最上位モデルの定価が急落しているからではなく、小規模モデルが一世代前の最上位（フラッグシップ）モデルに追いつき続けているからです。「1年後の価格」という数値はモデル上の仮定として扱い、引用する前にモデルと価格のリファレンスを再確認してください。
これは次のことを意味します。
- 一部の最適化は、時間とともに重要性が下がる（絶対的なコストがいずれにしても低下する）。
- 現在は採算の取れない一部のワークロードが、将来は採算の取れるものになる。
- 長期を見据えて構築する。今すべての費用を切り詰めることより、クリーンなアーキテクチャを優先する。
とはいえ、価格が下がっても最適化は重要です。非効率なシステムは、どの価格帯でも費用を無駄にします。また、多くの場合、競争優位を得るのは、低コストで効率的に運用するチームです。
90日間のコスト最適化計画
「AI機能はあるが、コストが想定より高い」という段階から始めるチーム向けの計画です。
第1～2週：測定。
- 呼び出しごとのコストを計測する。
- 機能ごと、ユーザーごとのダッシュボードを構築する。
- 最大のコスト要因を特定する。
第3～4週：すぐ得られる成果。
- 対応している場合はプロンプトキャッシュを有効にする。
- 呼び出し回数の多い上位3つのプロンプトを再構成し、キャッシュヒット率を最大化する。
- すべての呼び出しにmax_tokensを設定する。
- 予算アラートを実装する。
第5～6週：ルーティング。
- 現在は最上位モデルで処理している単純なタスクを特定する。
- 呼び出し回数の多い3～5個のエンドポイントにルーターを構築する。
- 品質の低下をテストする。
第7～8週：出力とキャッシュ。
- ユーザーから見えない出力について、長さを制限する。
- 一般的なクエリにアプリケーションレベルのレスポンスキャッシュを追加する。
- 最も処理量の多いフローに事前フィルターを追加する。
第9～10週：高度な施策。
- リアルタイムでない作業にバッチAPIを使用する。
- 代替プロバイダーを評価する。
- 埋め込みキャッシュと検索キャッシュを実装する。
第11～12週：堅牢化。
- すべての機能に予算ガードを設定する。
- 定例のチームレビューにコストダッシュボードを組み込む。
- 今後の機能で使用するパターンを文書化する。
90日後には、50～80%のコスト削減が現実的です。品質を監視し、規律を定着させます。
まず測定し、その後で削減効果を積み重ねる
LLMのコストは削減できます。通常は品質を損なうことなく60～90%削減できます。キャッシュ、ルーティング、出力制御、バッチ処理、事前フィルタリング、レスポンスキャッシュ、モデル選択、予算ガードといった手法は広く知られています。
個別に実施した場合、それぞれの削減効果は控えめです。組み合わせれば、効果が積み重なり、劇的な削減になります。
適切に実践するチームは、採算の合わないAI機能を採算の合うものに変えます。実践しないチームは、本来なら成立したはずの機能をいずれ廃止せざるを得なくなります。
まず測定し、最大の要因を最適化してください。品質監視を維持し、チームの日常業務にコスト規律を組み込んでください。
その結果、技術面だけでなく、経済面でも拡張可能なAI機能になります。それこそがAIを、リリース時の話題にとどまらず、製品の持続可能な一部にするものです。
