Claude APIの「90%削減」は本当か、料金計算機に数式を実装して検算した
自作のLLM料金計算機にキャッシュとバッチの計算を実装したら、削減テクニックの効き幅が数式で見えた。「90%削減」がどの構成でだけ成立するのか、モデル選択・出力制御・キャッシュ・バッチの優先順位を計算根拠つきで整理する。
2026年7月に、自作のLLM API料金計算機へプロンプトキャッシュとバッチAPIの計算を実装した。チェックボックスとスライダーを置くだけの作業に見えて、実際には「請求額を1本の数式に落とす」作業だった。そして式にしてみると、世の中に出回っている「Claude API料金を90%削減」系のテクニック集が、それぞれ式のどの変数をどれだけ動かしているのか、機械的に判定できるようになった。
先に立場をはっきりさせておくと、自分はClaude APIを個人サービスのAI日記生成で実運用している程度で、大規模トラフィックで90%削減を達成した経験談を持っているわけではない。この記事は、計算機を正しく作るために削減テクニックを数式レベルで分解した人間による「効く順番」の整理だ。数字を盛る動機がない分、正直に書ける。
請求額は1本の式で決まる
Claude APIの月額は、結局これで決まる。
月額 = リクエスト数 × (入力トークン × 実効入力単価 + 出力トークン × 出力単価) × バッチ係数
実効入力単価 = 通常入力単価 × (1 - キャッシュヒット率) + キャッシュ読み取り単価 × ヒット率
バッチ係数 = バッチAPIなら 0.5、標準APIなら 1計算機の中身もほぼこのままの実装になっている。世にある削減テクニックは、どれもこの式のどれかの変数を動かしているだけだ。だから「どれから手をつけるか」は精神論ではなく、変数ごとの効き幅を見れば決まる。順に見ていく。
モデル選択: 唯一、入力と出力の両方の単価に効く
2026年7月時点のAnthropic系の単価はこうなっている（100万トークンあたり。計算機のデフォルト値と同じ）。
| モデル | 入力 | 出力 | キャッシュ読み取り |
|---|---|---|---|
| Claude Fable 5 | $10 | $50 | $1 |
| Claude Opus 4.8 | $5 | $25 | $0.5 |
| Claude Sonnet 5 | $2 | $10 | $0.2 |
| Claude Haiku 4.5 | $1 | $5 | $0.1 |
Fable 5からHaiku 4.5に落とせば単純に1/10。モデル選択は式の中で入力単価と出力単価の両方に掛かる唯一のレバーで、効き幅としては別格だ。他のテクニックを検討する前に「このタスク、1段下のモデルで許容できるか」を試す方が先だと思う。
もちろん品質とのトレードオフなので「全部Haikuにしろ」という話ではない。ただ、逆の「とりあえず全部最上位モデル」も同じくらい雑な判断で、後で見るように「90%削減できた」系の数字の種は、だいたいここに埋まっている。
出力の制御: 単価が入力の5倍という非対称
上の表を見ると、Claude系は4モデルとも出力単価が入力のちょうど5倍だ。この非対称のせいで、トークン数の直感と請求額はかなりズレる。
計算機のデフォルト値（入力2,000トークン・出力800トークン・月1万リクエスト）をSonnet 5で計算すると、入力は20Mトークンで$40、出力は8Mトークンで$80。トークン数では入力の方が2.5倍多いのに、請求の2/3は出力が占める。
つまり出力を絞る工夫（max_tokensの指定、「結果だけ返して」の明示、JSONなら必要なキーだけ返させる）は、トークンあたりの削減効果が入力側の5倍ある。地味だが、生成系ワークロードでは最初に疑うべき変数だ。思考トークンや会話履歴の再送も含めた「請求がズレる原因」は別記事に書いたので、見積もり自体が怪しい人はそちらから読んでほしい。
プロンプトキャッシュ: 「90%オフ」は入力の、ヒットした部分だけ
プロンプトキャッシュの読み取り単価は通常入力の1/10（Sonnet 5なら$2に対して$0.2）。「90%削減」という言葉が一番よく使われるのがここだが、式に当てはめると効き方はかなり限定的だと分かる。
キャッシュが動かすのは実効入力単価だけで、しかもヒット率を掛けた分だけだ。さっきのデフォルト例で入力が全部キャッシュにヒットしたとしても、$120が$84になるだけ。入力側は確かに90%減っているのに、全体では30%しか下がらない。出力が支配的な構成では、キャッシュは主役になれない。
逆に、RAGのように毎回同じ長大なコンテキストを送って短い回答をもらうワークロードなら、入力が請求の大半を占めるのでキャッシュが主役になる。自分のワークロードが入力支配か出力支配かで優先順位が入れ替わる、というのが式から出てくる結論で、これは計算機のヒット率スライダーを0%と100%で動かして月額の変わり幅を見るのが一番早い。
ひとつ注意点。キャッシュはヒットしなかった分の書き込みが通常よりやや割高になるので、ヒット率が低い設計だと逆効果もあり得る。計算機ではそこは単純化してヒット率だけを扱っているが、「共通プロンプトが実際にどれくらいヒットするか」は楽観しない方がいい。
バッチAPI: 式の一番外側に掛かる一律50%
バッチAPIは入力も出力もキャッシュ読み取りも、全部まとめて半額にする。式で言えば一番外側の係数で、他の工夫と干渉せずそのまま掛け算できるのが強い。コードの工夫が要らない代わりに、リアルタイム応答を捨てられる処理でしか使えない。
どのワークロードなら非同期に倒せるのか、キャッシュとの重ねがけがどう効くのかはバッチAPIの記事に分けて書いたので、ここでは「一律50%の係数」という位置づけだけ押さえておけばいい。
で、「90%削減」はどこから出てくるのか
ここまでの変数を全部掛け合わせて検算してみる。条件はさっきと同じ、入力2,000・出力800トークン×月1万リクエスト。
- Fable 5・標準API・キャッシュなし: $200 + $400 = $600
- Sonnet 5・バッチ・入力全部キャッシュヒット: ($4 + $80) × 0.5 = $42
93%減。つまり「90%削減」は数式上、確かに成立する。ただしこれは一番高い構成と一番安い構成の比較だ。最上位モデルを標準APIで素のまま回していた、という出発点があって初めて出てくる数字で、既にSonnet 5を普通に使っている人の$120からだと、同じ最安構成に乗り換えても65%減。キャッシュヒット率を現実的な70%に置けば60%減まで下がる。
しかも最安構成には「非同期を許容できる」「入力の大半が毎回共通」という条件が付く。自分の日記生成はユーザーがボタンを押して待つ同期処理なのでバッチに乗れないし、キャッシュが効くのもシステムプロンプト程度。全条件に乗れるワークロードは、実はそんなに多くないと思う。
優先順位はこうなった
式に落とした結果、自分の中での手をつける順番はこうだ。
- 出力を疑う。単価5倍の側なので、量を絞る工夫の費用対効果が一番高い
- モデルを1段落とせるか試す。両方の単価に効く唯一のレバー
- 非同期に倒せる処理をバッチへ。実装コストほぼゼロで一律50%
- 残った入力にキャッシュ。入力支配のワークロードならここが2位以内に繰り上がる
削減率の看板は構成の前提次第でいくらでも変わるので、他人の「何%削減」を自分の見積もりに使うのはやめた方がいい。自分のトークン数とリクエスト数をLLM API料金計算機に入れて、キャッシュヒット率とバッチの入り切りで月額がどう動くかを見る方が、この記事を読み返すより確実だ。単価は改定されたら計算機側を更新していくので、記事中の具体値が古くなっていたらそちらを正としてほしい。