推論コストはワークロードの特性です：モデルとリージョン、キャッシュされていない入力とキャッシュ済み入力、生成トークンと推論トークン、ツール、再試行、同時実行数、ストレージ、人による確認がすべて関係します。業界の削減率の主張ではなく、請求された使用量とトレースから始めてください。
現行の価格とキャッシュのルールは頻繁に変わります。コストモデルを使う前に、公式のOpenAIの料金、Anthropicの料金、Geminiの料金を再確認してください。
この記事では、手法、数値、本番運用の規律を扱います。基本的なモデルルーティングはすでに済ませている前提です（マルチモデルオーケストレーション）。ここではさらに深く掘り下げます。
コストスタック
LLMのコストは、次の項目から生じます。
- 入力トークン。 モデルへ送る内容です。システムプロンプト、コンテキスト、ユーザークエリを含みます。
- 出力トークン。 モデルが返す内容です。入力と出力の価格比は、プロバイダー、モデル、バッチモード、キャッシュ状態によって異なります。
- 推論トークンまたは非表示の計算に対する課金。 プロバイダーの報告方法と課金上の扱いは異なります。目に見える出力と同等だと仮定せず、請求対象の使用量フィールドと現行の料金表を使ってください。
- ツール定義とツールの使用。 スキーマが入力トークンを増やすことがあり、ホスト型ツールや外部サービスには別途課金が発生する場合があります。
- 再試行と失敗した処理。 失敗または中断した呼び出しにも使用量が計上されることがあります。プロバイダーの請求データとトレースから、障害箇所を分類してください。
最適化は各レイヤーで行います。
手法1：プロンプトキャッシング
複数のリクエストがキャッシュ対象となる共通のプレフィックスを持ち、実際のヒット率が高いワークロードでは、キャッシュは大きな手段になり得ます。
キャッシュ対象プレフィックスの最小サイズ、書き込み／読み取り料金、有効期限、ルーティング上の制約、可観測性は、各プロバイダーの現行キャッシュドキュメントで確認してください。
概要としては、条件を満たす反復プレフィックスを、プロバイダーが定めた時間枠内で再利用できる場合があります。正確な仕様はプロバイダーごとに異なり、そのまま持ち込めません。
実務上の実装：
静的な内容を先に、動的な内容を後に来るよう、プロンプトを構成してください。
[CACHED: 10K tokens]
- システムプロンプト
- ツールの説明
- ユーザーの静的プロフィール
- 呼び出しごとにほとんど変わらないナレッジベースの抜粋
[NOT CACHED: 1K tokens]
- 会話履歴（ターンごとに変わる）
- 現在のユーザークエリ
このプレフィックスが対象になるか、どのように課金されるかは、選んだモデルとプロバイダーに依存します。
削減額の計算式：
daily cost = calls × (uncached input × input rate + cache writes × write rate + cache reads × read rate + output × output rate + tool charges)
請求対象となったトークン数と現行の料金表を当てはめてください。同等の期間を比較し、キャッシュミスも含めてください。
実装上の規律：
- プロンプトの静的な部分と動的な部分を切り分けます。
- 静的な部分を先頭に置きます。
- プロバイダーが対応している場合は、明示的に制御できるキャッシュマーカー（Anthropic）を使います。
- キャッシュヒットを検証します。可観測性でヒット率を確認できるようにしてください。低ければ、プロンプト構造が適切ではありません。
再利用されるキャッシュ対象入力が主要な費用項目だとトレースで示されてから、キャッシングを優先してください。
手法2：モデルルーティング
詳細は別記事で扱っています。要点は、複雑さに応じて異なるリクエストを異なるモデルへ振り分けることです。
ラベル付きのルーティング評価セットを作り、候補モデルを品質とコストで比較し、確信が持てないケースや失敗時のフォールバックを維持してください。結果として得られるルーティング構成は、ワークロード固有です。
手法3：出力長の制御
出力トークンが主要な費用項目になることがあります。応答長を最適化する前に、使用量データで確認してください。
戦略：
長さを明示する指示。
100語以内で回答してください。
モデルは、文章による長さの指示を守らないことがあります。制限を適用して評価し、大幅な削減を約束するのではなく、実測したトークン数と品質の変化を報告してください。
構造化出力。
必要な応答が短い構造化データである場合、厳格なスキーマによって無関係な文章を減らせます。不正な出力、過大なフィールド値、再試行、途中切れのリスクまではなくなりません。すべての結果を検証してください。
プロバイダーの出力トークン上限。
実測したタスクの必要量に基づいて、現行APIの出力上限を設定し、正常な完了のための余裕を残してください。パラメーター名と意味はAPIとモデルで異なります。上限が小さすぎると構造化出力が切り捨てられ、呼び出しが増えることがあります。
形式の制約。
「箇条書きのみ」や「一段落で」と指定すると、自由形式より短い出力になります。
箇条書きを文章より優先する。
箇条書きにすると、つなぎの文章を減らせる応答もあります。トークン数を測定してください。冗長な箇条書きは、簡潔な段落より長くなることがあります。
前置きを省く。
「導入の言い回しは省き、答えから始めてください。」モデルは「素晴らしい質問ですね……」や「ご説明します……」から始めることがよくあります。無駄なトークンです。
測定例：
要約ワークフローでは、同じドキュメントに対してデフォルト出力と制約付き出力を比較してください。請求された出力トークン、事実のカバレッジ、読みやすさ、ユーザーの追加質問率、途中切れの有無を報告します。トークン数が減っても、ユーザーが別の呼び出しを必要とするなら節約にはなりません。
手法4：出力サンプリングと早期停止
用途によっては、LLMの完全な出力は不要で、必要なのは判断や分類です。
分類のためのlogprobs。
# Use only a model and API operation whose current documentation supports
# log probabilities; support varies by model and endpoint.
response = openai.chat.completions.create(
model=SMALL_NON_REASONING_MODEL,
messages=[{"role": "user", "content": prompt}],
logprobs=True,
top_logprobs=5,
max_tokens=1
)
# Read logprobs of first token to determine likely category
これは、対応するモデルに短いラベルを出力させる方法です。選択したAPIが対数確率に対応していること、ラベルがトークンへ明確に対応すること、分類品質が目標を満たすことを確認してください。
制約付きラベルまたはロジットバイアス。
既知集合の出力では、利用できるならドキュメントに記載されたenum／スキーマ制約を優先してください。ロジットバイアスはトークン選択に影響しますが、トークナイザーとモデルに依存します。
response = openai.chat.completions.create(
model=COMPATIBLE_MODEL,
messages=[...],
# If used, build logit_bias from every tokenization variant you intend
# to accept; do not assume a class label is exactly one token.
logit_bias=VALIDATED_TOKEN_BIAS,
max_tokens=1,
)
ロジットバイアスはトークン選択に影響しますが、有効なクラスを強制するものでも、分類の信頼性を証明するものでもありません。検証し、想定外の出力は拒否してください。
手法5：バッチ処理
多数の項目を処理する場合は、バッチ処理してください。
APIレベルでの非同期バッチ。
一部のプロバイダーは、非同期またはバッチの製品を提供しており、料金、完了までの時間枠、制限、データの取り扱い条件が異なる場合があります。
- OpenAIとAnthropicは、いずれも非同期バッチ製品を文書化しています。現行の割引、完了までの時間枠、制限、データの取り扱い条件は、公式の料金ページとバッチページで確認してください。
バックログ作業に対話的な応答が不要なら、現行のバッチ料金と完了時の挙動を、同期経路と比較してください。
プロンプト内バッチ。
可能であれば、一回のLLM呼び出しで複数の項目を処理します。
次のようにするのではなく、
[10 separate calls, each classifying one ticket]
次のようにします。
[1 call, classifying 10 tickets in one prompt]
一回の呼び出しでは項目分の入力は増えますが、固定のプロンプトオーバーヘッドは一セットで済む可能性があります。ワークロードによっては総トークン数を減らせますが、区切り、長い出力、再試行、バッチ単位の失敗によって、その削減は消えることがあります。
注意：バッチ処理は、品質、順序、途中切れ、障害の分離を変えることがあります。万能な範囲を採用せず、代表的な入力でバッチサイズを変えて検証してください。
手法6：狭いタスクにはより小さいモデルを使う
通常のルーティングを超えて、そのタスクに本当に大きなモデルが必要かを検討してください。
分類： まれなクラスと回答保留を含むラベル付き例で、より小さいティアを現行の本番モデルと評価してください。コスト比較には現行のプロバイダー価格を使います。
抽出： より小さいモデル、中位、決定論的、ハイブリッドの抽出器を、フィールド単位の精度、例外処理、レイテンシー、コストで比較してください。検証済みのルールでエスカレーションします。
翻訳： 実際の言語ペア、用語、書式、安全性、人による確認の要件に照らして、専門の翻訳システムとLLMティアを評価してください。集計ベンチマークから対応範囲を推測してはいけません。
埋め込み： 埋め込みには専用モデルを使い、汎用LLMで埋め込みを作らないでください。
基本方針は、「単純で狭い」ワークロードを特定し、十分な品質で仕事を果たす最小のモデルへ振り分けることです。フラッグシップは、複雑で判断の重い作業のために残します。
手法7：ファインチューニングした小規模モデル
処理量が非常に多く、範囲の狭いタスクでは、小規模モデルをファインチューニングします。
処理量の多い分類ワークロードでは、プロンプトだけの小規模モデル、ファインチューニング済みモデル、決定論的ルール、ハイブリッドを比較してください。学習と評価のデータ、サービング、遊休キャパシティ、監視、再学習、エンジニアリングコストを含めてください。ファインチューニングが経済的なのは、実測した品質／コスト曲線がそれを正当化する場合だけです。
これは2026年のファインチューニングで扱いました。原則は、規模と狭さが揃ったとき、ファインチューニングはコストを動かす手段になる、ということです。
手法8：事前フィルタリング
複数ステップのLLMワークフローでは、安いフィルタリングで、高コストな処理の前に明らかなケースを拾います。
例：カスタマーサポートの分類と応答。
安い事前フィルター：
- 「これは実際のサポート質問か、スパム／ノイズか？」（小規模モデルでの1トークン分類。）
- 「これは既知のFAQか？」（埋め込み検索。低コスト。）
フィルターを通過したリクエストだけが、高コストな応答生成に進みます。
事前フィルターが必要な適合率でトラフィックのどの割合を解決できるか、測定してください。偽陽性は正当なリクエストを抑え込むことがあるため、コスト削減は品質とエスカレーションへの影響と併せて評価する必要があります。
手法9：プロンプトキャッシング以外のキャッシュ
モデルプロバイダーのプロンプトキャッシュに加えて、アプリケーションレベルのキャッシュがあります。
応答キャッシング。 承認された範囲と、応答に影響する入力の完全な集合について、鮮度と意味が有効なままなら、以前の応答を再利用します。非決定性があるため、これは製品上の判断であり、同一性の法則ではありません。
import hashlib
import json
def stable_sha256(value):
payload = json.dumps(value, sort_keys=True, separators=(",", ":"))
return "llm:" + hashlib.sha256(payload.encode("utf-8")).hexdigest()
def cached_call(scope, prompt_version, prompt, model, params, ttl=3600):
# Canonicalize all response-affecting inputs and include tenant/user scope
# where a shared answer is not explicitly safe. Use a stable cryptographic
# digest rather than the process-randomized built-in hash().
cache_key = stable_sha256({
"scope": scope,
"prompt_version": prompt_version,
"prompt": prompt,
"model": model,
"params": params,
})
cached = redis.get(cache_key)
if cached:
return json.loads(cached.decode("utf-8"))
response = call_llm(prompt, model, params)
redis.set(cache_key, json.dumps(response), ex=ttl)
return response
十分な決定性があり対象となる問い合わせでは、ヒットが蓄積されたあと、繰り返しの呼び出しを避けられます。鮮度と無効化を定義し、スコープを分離し、キャッシュスタンピードを防ぎ、機密または個別化された出力を承認なしにキャッシュしてはいけません。
埋め込みキャッシング。 計算済みの埋め込みをキャッシュします。
検索結果のキャッシング。 クエリに対する検索結果を短期間キャッシュします。
ツール結果のキャッシング。 基盤データが頻繁に変わらない場合、ツール呼び出し結果をキャッシュします。
キャッシュの階層は積み重なります。各レイヤーで呼び出しを減らせます。
手法10：投機的実行（レイテンシーとのトレードオフであり、コスト削減ではない）
次のステップを予測できる、レイテンシーが重要なフローでは、投機的に先行呼び出しします。
例：カスタマーサポートエージェント。顧客が問題を説明したあとの次のステップは、通常「問題を要約する」です。ユーザーへ受付を見せるのと並行して、その要約を開始します。
予測が当たれば、必要なときに応答が用意されています。外れれば、一回の呼び出しを無駄にしたことになります。
この方法は、破棄される可能性のある処理を意図的に使うため、コストが増えることがあります。実測したレイテンシー改善が無駄を正当化でき、キャンセルと副作用が制御され、投機的リクエストが権限のないデータを露出または変更できない場合に限って使ってください。
手法11：プロバイダー比較
プロバイダーは、価格、能力、リージョン、クォータ、データ条件、信頼性、モデル実装が異なります。同じワークロードと契約上の前提で、品質が同等な候補を比較してください。
マネージド推論プロバイダー上のオープンウェイトモデル。
候補モデルが同じワークロード評価に合格してから、現行のプロバイダー価格を比較してください。パラメーター数が近いことや、マーケティング上のティアが同じことは、品質が同等である根拠になりません。
異なるプロバイダー上の同一モデル。
一部のオープンウェイトモデルは、複数のプロバイダーから提供されています。正確なリビジョン、量子化、サービング構成、APIの挙動をベンチマークしてください。同じモデル名でも、出力や性能が同一とは限りません。
規模の大きい自社運用。
自社運用は、ワークロード固有の稼働率の地点で、より安くなる場合があります。GPU時間、レプリカ、遊休とピークのキャパシティ、ネットワーク、可観測性、アップグレード、セキュリティ、インシデント対応、エンジニアリング上のオーナーシップを試算してください。
マルチプロバイダーのルーティングは、統合、評価、セキュリティ、調達、可観測性、障害モードの複雑さを増やします。実測した耐障害性または経済的な利点が、そのオーナーシップコストを上回る場合に限って採用してください。
手法12：推論の高速化
自社運用の場合：推論レイヤーそのものの最適化です。
vLLM、TGI、SGLang。 モデル対応範囲と最適化経路が異なる推論サーバーです。対象ハードウェア上で、サポート対象のバージョンをベンチマークしてください。
量子化。 低精度化はメモリを減らしたりスループットを向上させたりできますが、品質への影響はタスクと手法に依存します。実際の成果物とサービング構成をベンチマークしてください。
Flash Attention、paged attention。 現行のサーバーで有効化されるアーキテクチャ上の最適化です。
継続的バッチ処理。 実行中のリクエストをまとめて、GPU利用率を高めるサーバーです。
大規模に自社運用するチームでは、これが重要です。APIを使うチームでは、プロバイダーが担います。
手法13：ストリーミング
ストリーミングはトークン数を減らしませんが、ユーザー体験は改善します。費用対効果の感じ方には影響します。
長い出力では、内容がすぐに表示され始めます。生成が終わるまで、並行して読めます。完全な応答を待つより、ずっと速く感じられます。
エージェントでは、承認済みの進捗イベントやステータス要約をストリーミングしてください。非公開の推論内容、シークレット、人による確認前のツール引数、他テナントのデータを「中間ステップ」として出してはいけません。
実装：選択したAPIとモデルがストリーミングに対応しているなら、ユーザー向けフローでテストしてください。ストリーミングが変えるのは体感レイテンシーであり、総コストやタスク完了時間が必ず変わるわけではありません。
手法14：予算ガード
最適化に加えて、コストの暴走を防ぐ厳格な予算を適用します。
リクエストごとの予算。 リクエストあたりの最大トークン数です。超過したら停止します。
ユーザーごとの予算。 ユーザーあたりの日次または月次の費用上限です。近づいたらスロットルします。
機能ごとの予算。 各機能には担当付きの予算があり、ワークロード固有のしきい値を超えたときの応答が検証されています。
全体予算。 日次／月次の総上限です。上限近くでは必須でない処理を一時停止します。
これらの制御は、削減を証明するものではありません。支出を上限付けまたは振り替えし、可用性も下げ得るため、必須・非必須の各ワークロードについて、アラート、スロットリング、ダウングレード、キューイング、サーキットブレーカーの動作をテストしてください。
コスト削減実験のテンプレート
複数施策を合成した値を、顧客の実績として提示してはいけません。本番ワークフローを一つ選び、基準となる請求期間を取り、変更を一度に一つずつ適用します。
変更内容：
-
プロンプトキャッシング。 対象プレフィックスのトークン、ヒット率、キャッシュの書き込み／読み取り、レイテンシー、請求コストを記録します。
-
モデルルーティング。 ルート分布、ルートごとの品質、フォールバック、レイテンシー、コストを記録します。
-
出力長の制御。 出力長、完了品質、ユーザーの再プロンプト、コストを記録します。
-
事前フィルタリング。 適合率、再現率、エスカレーション、抑制された有効リクエスト、回避できた呼び出しを記録します。
-
FAQ向けの応答キャッシング。 意味的同等性のルール、鮮度、無効化、ヒット率、回答品質を記録します。
総削減と純削減、評価結果、エンジニアリング時間、新たな運用コストに加え、データと手法が支える場合は不確実性区間も報告してください。意味のある品質低下を検出できる評価設計がない限り、品質は変わらないと主張してはいけません。
よくあるミス
自社のトレースで確認すべき失敗パターン：
ミス1：コスト追跡がない。 機能、ユーザー、呼び出しごとのコストが見えていません。測定なしに最適化はできません。
ミス2：最適化対象を間違える。 出力トークンが請求の80%なのに、入力トークンを5%減らすために数週間を使います。まず測定し、最大の寄与要因を最適化してください。
ミス3：品質のリグレッション。 品質監視なしにコスト削減を出荷します。支出は減ってもユーザーを失います。コスト施策は必ず評価スイートと対にしてください。
ミス4：過剰ルーティング。 実際には扱えないタスクまで、小規模モデルへ積極的に振り分けます。見せかけの削減です。
ミス5：キャッシュの汚染。 まれなクエリでキャッシュが埋まります。大半のエントリーは一度しか使われません。キャッシュミスが支配的です。より良いキャッシング戦略が必要です。
ミス6：バッチ評価を省略する。 プロバイダーの現行バッチ時間枠と制約で待てる作業にも、リアルタイム処理を使っています。
ミス7：過剰な作り込み。 そもそも採算の取れない機能の上に、精巧なコスト最適化を積みます。正しい答えが「機能を廃止する」である場合もあります。
ミス8：予算ガードがない。 一つのバグが暴走を生みます。軽微な不便ではなく、惨事になります。
運用規律
推奨する運用慣行：
- コストを後回しではなく、指標として扱います。
- エンジニアリングと財務にまたがる責任者を置きます。
- 支出の変動と事業リスクに見合う頻度でコストを確認します。
- 急増は、定めたしきい値とランブックでトリアージします。
- 機能ごとに予算を設定し、しきい値超過をアラートします。
- トレードオフを明示します（コスト対品質対レイテンシー）。
探す統制の抜け：
- 指名されたコスト責任者がいない。
- 意思決定の期間が過ぎてから請求に気づく。
- 対応責任者もランブックもないアラート。
- 承認された予算や予測の枠がない。
- トレードオフの議論を省き、一度に一つの軸だけを最適化する。
これらは、担当記録、レビューへの出席、アラート対応、完了したコスト施策で検証すべきガバナンス上の選択であり、チーム文化についての主張ではありません。
価格と能力のドリフト
より広い動向についての注記です。
プロバイダーの価格、モデル能力、バッチ製品、キャッシュルール、ホスト型ツールの課金は、ベンダーのスケジュールで変わります。この記事は、普遍的な歴史的傾向や予測を示すものではありません。
料金、モデル、契約、ワークロードに重要な変更があれば、コストと品質のモデルを再実行してください。現在採算が取れないワークフローが将来採算に乗ると仮定してはいけません。将来の表示価格の引き下げが、非効率な設計を救うと仮定してもいけません。
例示的な12週間のコスト最適化の流れ
「AI機能はあるが、コストが想定より高い」という状態から始めるチーム向けに、以下は計画例です。期間と停止条件は、ワークロード、根拠、運用余力に合わせて変えてください。
第1～2週：測定。
- 呼び出しごとのコストを計装します。
- 機能別、ユーザー別のダッシュボードを作ります。
- 最大の費用要因を特定します。
第3～4週：即効の改善。
- トレースに反復する対象プレフィックスがあり、現行のプロバイダールールに合う場合に限って、プロンプトキャッシングを試します。
- コストが最も高い対象プロンプトを再構成し、キャッシュヒット率、レイテンシー、品質、請求コストを測定します。
- 実測したタスク要件が支える場合に限り、各APIの現行出力上限を設定し、途中切れと再試行をテストします。
- 予算アラートを実装します。
第5～6週：ルーティング。
- 現在フラッグシップで動かしている単純タスクを特定します。
- 呼び出しが最も多い3～5個のエンドポイント用にルーターを作ります。
- 品質のリグレッションをテストします。
第7～8週：出力とキャッシング。
- ユーザーに見えない箇所で出力長を制約します。
- よくあるクエリ向けに、アプリケーションレベルの応答キャッシュを追加します。
- 処理量が最も多いフローに事前フィルターを追加します。
第9～10週：高度な施策。
- リアルタイムでない作業にバッチAPIを使います。
- 代替プロバイダーを評価します。
- 埋め込みキャッシュ、検索キャッシュを追加します。
第11～12週：堅牢化。
- すべての機能に予算ガードを置きます。
- 定例のチームレビューでコストダッシュボードを扱います。
- 将来の機能向けパターンを文書化します。
改善サイクルの終わりに、実測したコスト変化と品質の根拠を公開してください。スケジュールは、削減率を保証しません。
まず測定し、削減を積み上げる
LLMのコストは多くの場合削減できますが、削減率と品質への影響はワークロード固有です。候補となる手法には、キャッシング、ルーティング、出力制御、バッチ処理、事前フィルタリング、応答キャッシング、モデル選択、予算ガードがあります。
効果を帰属できるよう、変更は順に適用してください。相互作用によって、効果は積み重なることも、重なることも、打ち消し合うこともあります。
推論、ツール、人による確認、インフラストラクチャ、保守、サポートを差し引いた正味貢献で、その機能が経済的に持続可能かを判断してください。
まず測定します。最大の寄与要因を最適化します。品質モニタリングを維持します。コストの規律をチームの日常業務に組み込みます。
その結果、技術面だけでなく経済面でもスケールするAI機能になります。それこそが、AIを発表時の見出しではなく、製品の持続可能な一部にします。
