FDX株式会社
Tech Note

LLMトークン節約5パターン｜本番運用で​コストを​70%削る​ハーネス設計

LLMコストを本番運用で50〜80%削減する5つの節約パターン（キャッシュ・圧縮・モデル使い分け・バッチ・自前抽出）と、予算管理ハーネスの設計を実測指標とあわせて解説します。

··FDX株式会社 編集部·監修: 佐藤 拓哉（生成AI協会 理事）
LLM トークンコスト 3 層構造図。入力 / 出力 / キャッシュ書込・読出の単価差を可視化し、本番運用での割合の典型例を示す。

要点（100字）：LLM本番コストは​5パターン​（キャッシュ / 圧縮 / モデル使い分け / バッチ / 自前抽出）の​組み合わせで​50〜80%削減できる。​設計の​中核は​「予算上限を​Hard ceilingと​して​扱う」​「実測 → 改善ループを​月次で​回す」。

この​​記事の​​対象読者

トークンコストの​​基本：入力 / 出力 / キャッシュの​​3層

コスト3層構造

2026年時点の​主要LLMの​料金体系は​3層構造に​なっている。

層内容相対単価​（目安）
入力トークンプロンプトと​して​モデルに​送る​トークン1.0x​（基準）
出力トークンモデルが​生成する​トークン3〜5x​（入力より​割高）
キャッシュ書込プロンプトキャッシュへの​書き込み1.25x​（入力 +25%）
キャッシュ読出キャッシュからの​読み出し0.1x​（入力の​10%）

ポイント：

節約パターン5つ

5パターン マトリクス

パターン1：プロンプトキャッシュ​（最大インパクト / 適用難度​​：低）

Anthropic / OpenAI / Googleともキャッシュ機能を提供。​キャッシュヒット時は​入力の​10〜25%で​読める。

実装：

典型効果：エージェント運用 / チャットボットで​ 30〜60%コスト削減。​プロンプトが​長いほど​効く。

注意：

パターン2：コンテキスト圧縮​（中インパクト / 適用難度​​：中）

会話履歴 / RAG結果​ / システムプロンプトを​圧縮する。

実装：

典型効果：チャット運用で​ 20〜40%削減。​会話が​長くなる​ほど​効く。

注意：

パターン3：モデル使い分け​（小→大エスカレーション）​​（高インパクト / 適用難度​​：中）

タスクの​難易度に​応じて​モデルを​切り​替える。

実装：

典型効果：カスタマーサポート / 文書分類で​ 50〜80%削減。

注意：

パターン4：バッチ処理 / バッチAPI​（中インパクト / 適用難度​​：低）

リアルタ​イム性を​犠牲に​して​大幅な​単価割引を​得る。

実装：

典型効果：日次バッチで​動かす業務​（レポート生成 / 文書要約 / データ抽出）で​ 40〜50%削減。

注意：

パターン5：LLM抽出から​​自前抽出への​​撤退​（高インパクト / 適用難度​​：高）

LLMで​抽出している​処理を、​ルールベース / 既存ライブラリで​置き換える。

実装：

典型効果：抽出系業務で​ 70〜95%削減。​ただしカバレッジは​限定的。

注意：

予算管理ハーネスの​​設計

予算上限を​​Hard Ceilingと​​して​​扱う

予算は​「目標値」ではなく​ Hard Ceiling（絶対上限） と​して​実装する。

const budget = { total: 50_000, spent: 0 }
async function callLLM(prompt: string) {
  if (budget.spent >= budget.total) throw new Error("Budget exceeded")
  const result = await llm.call(prompt)
  budget.spent += result.usage.input_tokens + result.usage.output_tokens
  return result
}

緩い​上限​（​「目標X円、​実績Y円で​報告」）に​すると、​エッジケースで​指数的コスト爆発を​起こす。​Hard Ceilingは​運用安全の​最低ライン。

超過時の​​挙動​（fail fast / 縮退 / 通知）

予算超過時の​挙動は​3パターン：

  1. fail fast：即座に​エラーで​停止。​エンタープライズでの​推奨
  2. 縮退：高位モデルから​小型モデルに​切り替えて​続行。​コスト感応度が​中程度の​業務向け
  3. 通知のみ：超過後も​継続、​Slack通知で​人間が​判断。​プロトタイプフェーズのみ

本番運用では​fail fast + 即時通知が​原則。​縮退は​精度低下の​リスクが​ある。

月次の​​予算と​​日次の​​バースト制御

予算管理は​2階層：

日次バースト制御が​ないと、​月初1週間で​月次予算の​80%を​消費して、​月末は​機能停止状態に​なる。

実測と​​改善ループ

計測指標

指標計算目標
Cache hit rateキャッシュ読出トークン / 全入力トークン50%以上​（運用3ヶ月以降）
Avg tokens per task全トークン / タスク数タスク特性次第​（基準値を​月次で​見直し）
Cost per outcome月次コスト / 業務KPI改善量業務KPI連動で​目標設定
Escalation rate高位モデル呼び出し / 全呼び出し20〜30%​（モデル使い分け運用時）

改善ループ​（月次）

  1. 計測：上記4指標を​月次ダッシュボードで​可視化
  2. 分析：高コストTop 10ユースケースを​特定
  3. 仮説：5パターンの​どれが​適用可能か​検討
  4. 実装：1つだけ試して​効果測定​（A/Bで​1〜2週間）
  5. 本番展開 / 棚卸し：効果が​出たら本番、​出なかったら​撤退

複数施策を​同時に​投入すると​効果が​判別不能に​なる。1ヶ月1施策が原則。

アンチパターン3つ

アンチパターン1：context windowを​​全部​​詰める

「Claudeの​コンテキスト1M​使えるから​全部​入れちゃえ」は​最も​損な​パターン。​入力トークンは​出力より​安いが、​それでも​100K入力すると​キャッシュなしで​ $0.3〜1 / 呼び出しに​なる。

回避策：必要最小限の​コンテキストに​絞る。​RAG / 検索で​必要な​部分だけ取得する。

アンチパターン2：全リクエストを​​高位モデルで​​処理

「Opusで​全部​やれば​品質が​出る」は​単価が​50xの​モデル選択。​月次コストが​10〜30倍に​なる。

回避策：分類 / 抽出 / 単純応答は​小型モデルに​任せ、​高位モデルは​判断が​必要な​ケースだけ呼ぶ。

アンチパターン3：キャッシュ未活用での​​反復

同じ​システムプロンプトを​毎回​送って、​キャッシュ機能を​使わない​実装は、​本来0.1xで​済むものを​1xで​払っている​状態。

回避策：プロンプトキャッシュを​明示的に​有効化。​Anthropicは​ cache_control を指定。

FAQ

Q1. プロンプトキャッシュは​​Anthropic以外でも​​使えるか？

使える。

実装の​自由度は​Anthropicが​最も​高いが、​自動キャッシュは​OpenAI / Googleが​便利。​本番運用では​プロバイダごとの​実装差異を​抽象化する​レイヤーを​作る。

Q2. どの​​指標から​​計測すべきか？

最初に​見るべきは​ Cost per outcome（業務KPI改善あたりの​コスト）。​次に​ Avg tokens per task で​外れ値を​特定。Cache hit rate は​中期的な​改善余地の​指標。

Total costだけ​見ても​改善余地が​見えない。​必ず "per X" で​割って​評価する。

Q3. モデル使い分けの​​判定は​​どう​​自動化する？

3パターン：

  1. ルールベース：入力長 / メタデータで​分岐​（簡単 / ​柔軟性低）
  2. 小型分類モデル：DistilBERT等で​判定​（中速 / 中精度）
  3. 小型LLM判定：Haiku等で​判定 → 必要なら​Opus​（コスト中、​精度高）

最初は​ルールベースで​開始、​運用データが​溜まったら​小型LLM判定に​進化させる​流れが​標準。

Q4. バッチAPIは​​どの​​程度​安くなる？

OpenAI / Anthropicは​ 50%オフ、​Googleは​ 時期とSKU次第。​日次バッチ業務​（レポート / データ抽出 / 文書要約）に​適用すると、​即座に​半額に​なる。

最大24時間の​遅延を​許容できる​業務にだけ適用する。​リアルタイム業務には​使えない。

Q5. コスト管理は​​誰の​​責任に​​すべきか？

3階層責任：

3階層の​どこかが​空白だと​コスト管理が​破綻する。​特に​「CFOが​承認したが​SREが​実装しない」のが​最頻パターン。

Q6. 月次予算を​​超過した​​場合の​​対応は？

3ステップ：

  1. 即時：fail fastで​サービス停止 / 縮退
  2. 24時間以内：原因特定​（特定ユースケースの​バースト / プロンプト変更に​よる​爆発 / バグ）
  3. 月内：恒久対策​（プロンプト見直し / モデル使い分け追加 / 予算枠調整）

予算超過は​障害扱いに​する。​インシデント報告 / ポストモーテムを​実施し、​再発防止を​仕組み化する。

FDXの​​LLMコスト最適化支援

FDX株式会社は、Forward Deployed Engineer（FDE）+ プラットフォームエンジニアリング に​よって、​LLM本番運用の​コスト最適化を​支援する。

「PoCは​通ったが、​本番​運用したら​コストが​想定の​5倍」と​いう​典型課題に​対して、​構造的に​再設計する​（参考：AI PoCが​失敗する​5つの​構造的理由）。

FDXに​LLMコスト最適化の​相談を​する​ →

関連記事

まとめ

出典・参考文献

関連記事

Tech Note

ローカルLLM比較2026｜オープンウェイトモデルの選び方

Strategy

AI PoCが失敗する5つの構造的理由と回避策｜本番化に進めるPoCの設計

Tech Note

ループエンジニアリング入門｜自律エージェントを動かし続けるハーネス設計の体系

Next Steps

次に読むべき

ノウハウ記事

他のノウハウ記事を読む

FDE / AX 実装に関する他のインサイト記事。

読む

事例

実装事例集

記事で議論したパターンが動いている実例。

読む

ホワイトペーパー

業務別AIツール25本 徹底比較

議事録・画像生成・資料作成・検索・開発の選定地図。

読む

FDX流の​FDEモデルを​相談する

戦略立案・実装・現場定着・運用移管まで一気通貫で支援します。

無料相談を申し込む実装事例を見る