TL;DR
- LLM API 料金は input/output/cache/batch の4軸で構造化できる
- 単価比は output > input > batch > cache の順に安くなる（モデル依存だが概ね10倍以上の幅）
- 最適化の優先順位：cache 有効化 → batch 振り分け → output 短縮 → モデル切替え
- 「賢いモデルへの切替えで安くなる」は罠が多い、まず構造分解する方が確実
- 年間試算は使用量を均一に見積もると外す。ピーク考慮した month-based シミュレーションが現実解
この記事の目的と成功基準
- 目的: LLM API 料金の構造を理解し、優先順位を付けて最適化できる状態にする
- 想定読者: LLM プロダクトの財務管理を担うエンジニア / EM、コスト責任を持つテックリード
- 成功基準: 「LLM API 料金」関連クエリでの流入、LLM本番運用・Vibe Codingトークン経済学 への回遊
料金構造を4軸で分解する
Zenn の LLM API 料金記事 でも整理されている通り、2026年の主要 LLM プロバイダ（OpenAI / Anthropic / Google）の料金は概ね以下の4軸に分解できる。
| 軸 | 単価傾向 | 削減の主な手段 |
|---|---|---|
| Input | 中 | プロンプト圧縮、関連性スクリーニング |
| Output | 高（input の3〜5倍） | 出力長制限、構造化指示 |
| Cache（input 再利用） | 極低（input の10%程度） | システムプロンプト・規約・few-shot を cache 対象に |
| Batch | 中（即時 API の50%） | 非リアルタイム処理を batch に振り分け |
単価の幅は output > input > batch > cache の順で大きい。
最適化の優先順位
優先度1: Cache 有効化
最も投資対効果が高い。Anthropic の prompt caching、OpenAI の prompt caching、Google の context caching を有効化する。
cache 対象にすべきもの：
- システムプロンプト（変更頻度が低い）
- AGENTS.md / CLAUDE.md / 規約文書
- few-shot example
- 長文の API リファレンス・知識ベース
実装上の注意：
- cache hit を狙うため、システムプロンプトを変更頻度別に並べる（不変→可変の順）
- hit rate を Gateway / Langfuse で監視。30%未満なら設計を見直す
優先度2: Batch 振り分け
即時性を求められないジョブは batch API に振る。
- ナイトリーレポート
- 大量 embedding 生成
- バックフィル
- 評価データ生成
batch は完了に最大24時間かかるため、ユーザー体験に直結する処理（チャット応答・コード補完）には使えない。
優先度3: Output 短縮
output 単価は input の3〜5倍。短くするだけでコスト効果が大きい。
- 構造化出力（JSON）で冗長な自然言語を削る
- 「箇条書きで5項目以内」「200字以内」と制約
- 出力を「次のステップ指示」に絞り、説明部分を別段階に分離
「説明させる」だけのために生成している output が無いか棚卸しする。
優先度4: モデル切替え
最後の手段。賢いモデル → 安いモデルへの切替えは品質低下リスクがあるため、A/B 評価で検証する。
切替え判断軸：
- 簡単なタスク（分類・抽出・短文生成）は小型モデルで十分
- 複雑な推論（多段プラン・コード生成）は大型モデルを維持
- 量が多くて単純なジョブほど小型モデル化の費用効果が大きい
年間試算の現実解
「月間 X トークン × 単価 = 年間 Y 円」では外す。
外す理由：
- 使用量はリリース・キャンペーン・季節で2〜10倍揺れる
- 新機能追加のたびに input トークンが増える
- ユーザー成長は線形でない
現実的な試算手順：
- 過去3か月の月次実績を取得
- 翌3か月の機能ロードマップから増加要因を見積もる
- ピーク月（成長率2倍）と平準月で月別シミュレーション
- 安全係数 1.3 倍を載せて budget 設定
単価比較の落とし穴
「Claude Haiku は GPT-4o より安い」のような単純比較は、output ÷ input 比率が違うと逆転する。
- モデル A: input $1/M tokens, output $5/M tokens
- モデル B: input $0.5/M tokens, output $10/M tokens
input が多く output が少ないタスク（要約）は B が安い。output が多いタスク（コード生成）は A が安い。タスク特性に合わせて単価モデルを選ぶ必要がある。
Growth Lab での適用例
このサイトの記事生成バッチで、以下の順に最適化を適用した（実数は例）：
| 施策 | 月次コスト変化 |
|---|---|
| 何もしない | 100% |
| システムプロンプト cache 化 | 60% |
| 評価ジョブを batch 移行 | 50% |
| 出力構造化（JSON 化） | 42% |
| 分類タスクを小型モデル化 | 38% |
cache だけで40%減、4軸全部やって62%減という結果になった。
詳細は LLM本番運用チェックリスト のコスト制御軸も参照。
アンチパターン
- モデル切替えから始める: 品質低下リスクがあるので最後にする
- cache を意識してプロンプトを固定しすぎる: 改善サイクルが止まる
- batch でユーザー応答を返す: 体感を破壊する
- 試算の安全係数を入れない: 想定の2倍出る
FAQ
Q. cache の TTL はどう決めますか？ A. プロバイダ標準（Anthropic は5分・1時間オプション）を使い、システムプロンプトを長 TTL、可変部分を短 TTL にします。
Q. batch API でレイテンシが許容範囲なら全部 batch にして良いですか？ A. リクエストごとの完了タイミングが予測しにくいため、SLO が必要なジョブは即時 API を使うのが安全です。
Q. 小型モデルの品質はどう検証しますか？ A. ゴールデンセット（100〜500件）で大型モデルと小型モデルの出力を LLM-as-judge で比較し、許容差を判定します。
まとめ
LLM API 料金は input/output/cache/batch の4軸で構造化できる。最適化は cache → batch → output 短縮 → モデル切替えの順に進めるのが投資対効果が高い。年間試算は月別シミュレーション+安全係数で外さない数字を作る。Platform 側の Gateway と組み合わせて組織全体で運用に乗せる。
