LLM APIコストを実際に下げる方法 — 「キャッシング90%割引」が請求書ではなぜ25%なのか

はじめに — 割引率は請求書の削減率ではない
この記事の数字について — 価格は頻繁に変わる
請求書はどこから来るのか — 出力トークンが支配する
プロンプトキャッシングは実際にいくら減らすのか
キャッシングは何回読めば元が取れるのか
キャッシングがまったく効かないケース
Batch APIの50%は本物か
バッチが使えないワークロードには — Flex
安いモデルに替えればその分安くなるのか — トークナイザーの罠
ロングコンテキスト割増 — 誰も予算に入れないもの
最大のレバーは出力トークンである
では何から始めるべきか
いつこれをやるべきでないのか
おわりに
参考資料

はじめに — 割引率は請求書の削減率ではない

「プロンプトキャッシングを有効にすれば90%安くなる」という文は、LLMコスト記事の定番です。半分だけ正しい。キャッシュ読み取りの単価が基本入力単価の10分の1であるのは事実ですが、それはキャッシュ読み取りという一つの明細項目の割引率です。請求書全体がそれだけ減るためには、あなたが使うお金の全部がキャッシュ可能な入力トークンでなければなりません。実際にはそうではありません。

まず答えから言いましょう。割引は、その項目が請求書に占める割合の分だけしか総額を減らしません。Anthropicが自社の価格ドキュメントに直接載せている計算例を見ると、Claude Opus 4.8で入力5万トークン・出力1万5千トークンを使う1時間のセッションのコストは0.705ドルです。ここで入力5万のうち4万トークンがキャッシュ読み取りに変わると、総額は0.525ドルになります。入力コストは0.25ドルから0.07ドルへ72%削られたのに、総額は25.5%しか減りませんでした。出力トークンがすでにコストの大部分を食っていたからです。

だからこの記事は割引率を並べません。代わりに請求書を計算します。キャッシングがなぜ機能するのか（トランスフォーマー内部のKVキャッシュの話）はLLMキャッシングの原理で、サービングエンジンがこれをどう回しているかはPrefill・Decode分離とgoodputですでに扱いました。ここでは徹底してAPIを買って使う側の経済学だけを見ます。

この記事の数字について — 価格は頻繁に変わる

LLMコストの記事がすぐに腐るのは、価格が頻繁に変わるからです。だから先にルールを釘打ちしておきます。

この記事のすべての価格は、2026年7月17日に各プロバイダーの公式価格表ページから直接取得したものです。二次資料、要約、記憶から持ってきた数字は一つもありません。
価格は予告なく変わります。この記事の中にもその証拠があります — Claude Sonnet 5の導入価格は2026年8月31日までしか有効でなく、9月1日から上がります。OpenAIのキャッシュ書き込み料金はGPT-5.6世代で新設されました（それ以前のモデルは無料でした）。どちらも「かつて正しかった文」が今は間違っている例です。
あなたがこの記事を読む時点でこれらの数字がまだ正しいかどうかは保証できません。支払いに影響する決定を下す前に、必ず各プロバイダーの価格表を自分で開いてください。リンクは一番下の参考資料にあります。

変わらないのは価格ではなく計算の構造です。この記事が本当に教えようとしているのは、その構造です。

請求書はどこから来るのか — 出力トークンが支配する

何を最適化するかを決める前に、お金がどこへ漏れているのかを見なければなりません。LLM APIの請求書は、ほぼ必ず3つの項目に分かれます — キャッシュされていない入力、キャッシュ読み取り、そして出力。

ここに、ほとんどの人が見落としている事実があります。出力トークンの単価は入力単価の数倍です。2026年7月17日時点のAnthropic価格表から取った数字です。

モデル                       入力（100万トークンあたり）  出力（100万トークンあたり）  出力/入力 倍率
Claude Opus 4.8                 5ドル                25ドル                5倍
Claude Sonnet 5（導入価格）      2ドル                10ドル                5倍
Claude Haiku 4.5                1ドル                 5ドル                5倍
Claude Fable 5                 10ドル                50ドル                5倍

Claude系は一貫して5倍です。OpenAI側は倍率がさらに大きい — 2026年7月17日時点の価格表で、gpt-5.6-solはショートコンテキスト基準で入力5ドル / 出力30ドルの6倍、gpt-5.6-lunaは1ドル / 6ドルでやはり6倍です。

これがなぜ重要なのか。Anthropicドキュメントの計算例をそのまま持ってくるとこうなります（Opus 4.8、入力5万・出力1万5千トークン）。

項目        トークン数     割合        コスト        コスト割合
入力        50,000       76.9%     0.25ドル      40%
出力        15,000       23.1%     0.375ドル     60%
合計        65,000                 0.625ドル

出力はトークン数では23.1%にすぎないのに、コストでは60%を占めます。トークン数を見て「入力が問題だ」と判断すると、正確に逆を突くことになります。

だから最初の実践ルールは、最適化ではなく計測です。Anthropic APIはレスポンスのusageにinput_tokens、output_tokens、cache_creation_input_tokens、cache_read_input_tokensを返し、OpenAIはcached_tokens（キャッシュ読み取り）と、GPT-5.6以降の世代ではcache_write_tokens（キャッシュ書き込み）を返します。この4つの数字にそれぞれ単価を掛けて項目別の金額を出すまでは、どんな最適化も推測にすぎません。

プロンプトキャッシングは実際にいくら減らすのか

では、冒頭の計算を最後までやりましょう。Anthropic価格ドキュメントのManaged Agentsの項には、キャッシング前後を並べた表があります。以下はそのドキュメントの数字をそのまま書き写し、検算したものです。

[キャッシングなし] Opus 4.8、入力5万 / 出力1万5千、1時間セッション
  入力                 50,000 x 5ドル  / 100万 = 0.25ドル
  出力                 15,000 x 25ドル / 100万 = 0.375ドル
  セッションランタイム   1.0時間 x 0.08ドル      = 0.08ドル
  合計                                         = 0.705ドル

[キャッシング適用] 入力5万のうち4万がキャッシュ読み取り
  未キャッシュ入力      10,000 x 5ドル / 100万       = 0.05ドル
  キャッシュ読み取り    40,000 x 5ドル x 0.1 / 100万 = 0.02ドル
  出力                 15,000 x 25ドル / 100万      = 0.375ドル
  セッションランタイム   1.0時間 x 0.08ドル           = 0.08ドル
  合計                                              = 0.525ドル

節約額 = 0.705 - 0.525 = 0.18ドル
節約率 = 0.18 / 0.705 = 25.5%

キャッシュ読み取りの単価は、明らかに基本入力の10%（つまり「90%割引」）です。それなのに総額は25.5%しか減りませんでした。

3つのことを指摘しなければなりません。

第一に、セッションランタイムの0.08ドルはManaged Agents専用の項目です。通常のMessages APIにはこの行がありません。だからトークンコストだけを切り出して見ると0.625ドルから0.445ドルで、削減率は28.8%です。どちらで計算しても、90%には程遠い値です。

第二に、この例はキャッシュがすでに温まった状態を仮定しています。キャッシュ書き込みコストが計算に入っていません。最初のリクエストでは書き込み料金を余分に払うので、実際の初回呼び出しはむしろ高くつきます。この損益分岐は、すぐ次の節で計算します。

第三に、そしてこれが本当の結論ですが — キャッシング後、出力がトークンコストに占める割合は0.375 / 0.445 = 84.3%に上がります。キャッシングは入力項目を消すことで、出力の支配力をむしろ強めます。キャッシングをきちんと有効にした瞬間、次のレバーは必ず出力です。

キャッシングは何回読めば元が取れるのか

キャッシングがタダではないのは、書き込み料金のせいです。2026年7月17日時点でAnthropicドキュメントが明らかにしている倍率は、基本入力単価に対してこうです。

キャッシュ操作               倍率                 有効期間
5分キャッシュ書き込み       基本入力の1.25倍       5分
1時間キャッシュ書き込み     基本入力の2倍          1時間
キャッシュ読み取り(ヒット)   基本入力の0.1倍        直前の書き込みと同じ

同じプレフィックスをN回送るとすると、キャッシュなしで払うお金はN（基本入力単価を1とした相対値）で、キャッシュを使うと書き込み1回 + 読み取り(N-1)回です。計算するとこうなります。

5分キャッシュ (書き込み1.25倍)
  N=1: キャッシュなし 1.00  vs  キャッシュ 1.25        -> キャッシュが損
  N=2: キャッシュなし 2.00  vs  1.25 + 0.10 = 1.35   -> キャッシュが得
1時間キャッシュ (書き込み2倍)
  N=2: キャッシュなし 2.00  vs  2.00 + 0.10 = 2.10   -> まだ損
  N=3: キャッシュなし 3.00  vs  2.00 + 0.20 = 2.20   -> キャッシュが得

つまり5分キャッシュは読み取り1回目から、1時間キャッシュは読み取り2回目から元を取ります。Anthropicドキュメントが言う損益分岐と正確に一致し、上の式で直接検算できます。

実務で重要なのはこの点です。5分以内に同じプレフィックスが2回以上来ないトラフィックなら、キャッシングはコストを増やします。1日に数回しか来ない低頻度エンドポイントでキャッシングを有効にしておいて「なぜ安くならないんだ?」と聞くケースが、これに当たります。ただしAnthropicは、5分キャッシュの場合はキャッシュが使われるたびに追加費用なしで有効期間が更新されると明らかにしているので、トラフィックが絶えず流れている間は5分が延長され続けます。

OpenAI側は世代によってルールが違います。OpenAIドキュメントによれば、GPT-5.6より前のモデルはキャッシュ書き込みに追加料金がなく、GPT-5.6世代からはキャッシュ書き込みが未キャッシュ入力単価の1.25倍です。「OpenAIはキャッシュ書き込みがタダ」という古い常識が、最新世代で崩れたわけです。キャッシュ読み取りはgpt-5.6-sol基準で入力5ドルに対して0.5ドルと、正確に10%です。結果として最新世代では、両社のキャッシュ価格構造（書き込み1.25倍 / 読み取り0.1倍）は事実上同じになりました。

キャッシングがまったく効かないケース

いちばん虚しい失敗は、キャッシングを有効にしたのに何も起こらないケースです。プロンプトが最小長に満たなければ、キャッシュは単に効きません。

Anthropicドキュメント基準（2026年7月17日）で、Claude APIの最小キャッシュ可能プロンプト長はモデルごとに違います。

Claude Fable 5, Mythos 5                       512トークン
Claude Mythos Preview, Opus 4.7              2,048トークン
Claude Opus 4.6, Opus 4.5                    4,096トークン
Claude Haiku 4.5                             4,096トークン
Claude Opus 4.8, Sonnet 5, Sonnet 4.6,
  Sonnet 4.5                                 1,024トークン

ドキュメントはここに決定的な但し書きを付けています — 最小長に満たないプロンプトはcache_controlを付けてもキャッシングなしで処理され、エラーにはなりません。静かに失敗するという意味です。キャッシュが効いたかを確認するには、レスポンスのcache_creation_input_tokensとcache_read_input_tokensを見てください。両方とも0なら、効いていません。

もう一つ注意点があります。この最小値はプラットフォームごとに違うことがあります。Anthropicドキュメントは、Amazon BedrockではFable 5とMythos 5の最小長が1,024トークンだと別途明記しています。Bedrockのモデル別の最小値・失敗時の動作・フィールド名は、AWSドキュメントを見る必要があります。

OpenAIは構造がより単純です — ドキュメント上、1,024トークン以上のプロンプトに自動でキャッシングが適用され、キャッシュヒットは正確なプレフィックス一致でのみ発生します。1,024トークン未満のリクエストはcached_tokensが0になります。

ここから、両社が共通して強調する設計ルールが出てきます。固定された内容（システムプロンプト、例、ツール定義）を前に、変わる内容（ユーザー入力）を後ろに置いてください。キャッシュはプレフィックス一致でしか効かないので、先頭にタイムスタンプを1行入れた瞬間、その後ろ全部がキャッシュから外れます。画像とツール定義も、リクエスト間で同一でなければなりません。

Batch APIの50%は本物か

本物です。しかも3プロバイダーとも同じ数字です。2026年7月17日時点で各社のドキュメントから確認した内容です。

Anthropic: Message Batches APIは「すべての使用量が標準API価格の50%で課金」されます。入力と出力の両方です。
OpenAI: Batch APIは同期APIに対して「50%のコスト割引」です。価格表でgpt-5.6-solのショートコンテキスト基準、入力5ドル → 2.5ドル、出力30ドル → 15ドルと検算できます。
Google: Vertex AIの価格ページは「Geminiモデルはバッチモードで50%割引」と明記しており、Gemini 3.1 Pro Preview基準で入力2ドル → 1ドル、出力12ドル → 6ドルと検算できます。

キャッシングと違い、バッチ割引は入力と出力の両方にかかります。だから出力が支配する請求書では、バッチのほうがキャッシングより総額を大きく減らします。先ほどのOpus 4.8の例（トークンコスト0.625ドル）をバッチで回すと0.3125ドルと、正確に半分になります。キャッシングの28.8%と比べてみてください。

もちろんタダではありません。代償は時間と確実性です。

Anthropic: ドキュメントは「ほとんどのバッチは1時間以内に完了する」としながらも、結果には「すべてのメッセージが完了したとき、または24時間後のどちらか早い時点」でアクセスでき、24時間以内に処理が終わらなければバッチは期限切れになると明記しています。重要な但し書きが付いています — 需要とリクエスト量によって処理が遅くなることがあり、その場合は24時間後に期限切れになるリクエストが増える可能性があります。ただし期限切れになったリクエストは課金されません。

OpenAI: 完了ウィンドウ（completion_window）は現在24hのみ設定でき、バッチのステータスにはexpired（「24時間のウィンドウ内に完了しなかった」）が存在します。

整理すると、バッチは「50%割引」ではなく、50%割引と24時間期限切れリスクのパッケージです。ユーザーが待っているリクエストには使えません。夜間のレポート生成、ドキュメントの一括分類、埋め込みの再インデックス、評価セットの実行 — こうした作業では、ほぼ常に得です。

バッチが使えないワークロードには — Flex

ここに、あまり知られていない選択肢が一つあります。OpenAIのFlex処理は、同期呼び出しなのにバッチ価格が適用されます。OpenAIドキュメントの表現そのままに、Flexのトークンは「Batch APIのレートで課金」され、プロンプトキャッシング割引が追加で乗ります。価格表でも、gpt-5.6-solのFlexレート（入力2.5ドル / 出力15ドル）はBatchレートと完全に同一です。

24時間のバッチファイルワークフローを組まずにservice_tierをflexにするだけでよいので、バッチに移すには微妙な非対話型の作業によく合います。

代償は明確にドキュメント化されています。Flexは「より遅い応答時間と断続的なリソース不足」を受け入れる代わりに安いのであり、現在はベータであり対応モデルも限定的です。リソースが足りないと429 Resource Unavailableが返ってきますが、ドキュメントはこの場合課金されないと明記しています。SDKのデフォルトタイムアウトが10分なので長い作業ではタイムアウトを延ばす必要があり、OpenAIは失敗時の戦略として、指数バックオフでリトライするか、service_tierをautoに変えて標準処理でリトライするかの2つを提示しています。

一行でまとめると、非対話型だが24時間は待てない作業なら、Flexがちょうどその隙間を埋めます。

安いモデルに替えればその分安くなるのか — トークナイザーの罠

モデルルーティングの論理は単純です。簡単なリクエストは安いモデルへ、難しいリクエストだけ高いモデルへ。価格の階段は、2026年7月17日時点でこうです。

Anthropic (100万トークンあたり、入力 / 出力)
  Claude Fable 5              10ドル / 50ドル
  Claude Opus 4.8              5ドル / 25ドル
  Claude Sonnet 5 (導入価格)    2ドル / 10ドル   <- 2026-08-31まで
  Claude Sonnet 5 (9/1から)     3ドル / 15ドル
  Claude Haiku 4.5             1ドル /  5ドル

OpenAI (100万トークンあたり、ショートコンテキスト基準、入力 / 出力)
  gpt-5.6-sol                  5ドル / 30ドル
  gpt-5.6-terra              2.5ドル / 15ドル
  gpt-5.6-luna                 1ドル /  6ドル

Haiku 4.5（1ドル/5ドル）とOpus 4.8（5ドル/25ドル）は、正確に5倍の差です。簡単なリクエストの80%をHaikuに下ろせば、それだけ大きな節約になります — ルーティングが実際に割に合う理由です。

ところが、ここに罠があります。per-token価格はトークナイザーが同じときにだけ比較可能です。Anthropicの価格ドキュメントにはこんな脚注が付いています — Claude Opus 4.7以降のOpusモデル、Fable 5、Mythos 5、Mythos Preview、Sonnet 5は新しいトークナイザーを使い、このトークナイザーは同じテキストに対して約30%多くのトークンを生成します。（ドキュメントは「正確な増加幅はコンテンツとワークロードの形によって異なる」と付け加えています。Sonnet 4.6とそれ以前のモデルは、旧トークナイザーを使います。）

これが価格比較をどうひっくり返すか、計算してみましょう。ドキュメントの「約30%」をそのまま1.3倍と置き、同じテキストTを処理するとします。

Sonnet 4.6 (3ドル、旧トークナイザー) vs Sonnet 5 導入価格 (2ドル、新トークナイザー)
  単純な単価比較:   (3-2)/3          = 33.3% 安い
  同じテキスト基準: 3T vs 2 x 1.3T = 2.6T
                   (3-2.6)/3        = 13.3% 安い   <- 実際

Sonnet 5が9月1日に3ドルへ上がると
  同じテキスト基準: 3T vs 3 x 1.3T = 3.9T
                   -> Sonnet 4.6より30%高い

Opus 4.1 (15ドル、旧) vs Opus 4.8 (5ドル、新)
  単純な単価比較:   (15-5)/15        = 66.7% 安い
  同じテキスト基準: 15T vs 5 x 1.3T = 6.5T
                   (15-6.5)/15      = 56.7% 安い  <- 実際

正直に付け加えるべきことがあります。この計算は入力テキストが同一だという仮定の上の算数であって、ベンチマークではありません。Anthropicドキュメントは、新トークナイザーが「幅広いタスクでの性能向上に寄与する」と説明しているので、トークンが増えた分をそのまま損だと読んではいけません。より良いモデルは同じ仕事をより短い出力で終わらせるかもしれず、リトライが減るかもしれません。そして「約30%」は英語基準の近似値である可能性が高い — 韓国語のようにトークン化の特性が違う言語で実際に何%になるかは、公開された数値がありません。あなたの実際のプロンプトを各モデルのトークンカウントAPIに入れて自分で数える以外に、方法はありません。

ここから出てくるルールはこれです。モデルを替えるときは、単価表ではなく「自分の実際のプロンプトのトークン数 x 単価」を比較してください。世代の違うモデルの間で単価だけを比べるのは、単位の違う2つの数を引き算するようなものです。

ロングコンテキスト割増 — 誰も予算に入れないもの

コンテキストを長く使えばトークンが増えて高くなることは、誰でも知っています。ところが、プロバイダーによっては単価そのものが上がるということは、はるかに知られていません。ここで3社が分かれます。各数字は、その会社自身の価格表から取ったものです（2026年7月17日時点）。

OpenAIの価格表は、gpt-5.6系のレートを「Short context」と「Long context」の2セットに分けて載せています。

gpt-5.6-sol    ショートコンテキスト   5ドル / 30ドル
               ロングコンテキスト   10ドル / 45ドル    -> 入力2倍、出力1.5倍
gpt-5.6-terra  ショートコンテキスト  2.5ドル / 15ドル
               ロングコンテキスト    5ドル / 22.5ドル  -> 入力2倍、出力1.5倍
gpt-5.6-luna   ショートコンテキスト   1ドル / 6ドル
               ロングコンテキスト    2ドル / 9ドル     -> 入力2倍、出力1.5倍

3モデルとも、正確に入力2倍、出力1.5倍です。ただしgpt-5.6系で「ロングコンテキスト」が何トークンから始まるのかは、価格表ページに載っていません。同じページが旧世代モデルの行にはgpt-5.5 (<272K context length)のように境界を表記しているのに、gpt-5.6系にはその表記がありません。だから、ここで閾値をでっち上げることはしません — 必ず自分で確認してください。

GoogleのVertex AI価格ページは、閾値を明示しています。Gemini 3.1 Pro Previewは入力2ドル / 出力12ドルですが、200K入力トークンを超えると4ドル / 18ドルになります（やはり入力2倍、出力1.5倍）。そしてこのページの脚注には、痛い一文があります — クエリの入力コンテキストが200Kトークンを超えると、入力と出力を含むすべてのトークンがロングコンテキストレートで課金されます。閾値を1トークン超えただけで、そのリクエスト全体の単価が変わるという意味です。

Anthropicは逆へ行きます。価格ドキュメントは、Fable 5、Mythos 5、Mythos Preview、Opus 4.8、Opus 4.7、Opus 4.6、Sonnet 5、Sonnet 4.6が100万トークンのコンテキスト全体を標準価格に含むと明記し、括弧で釘を刺します — 「90万トークンのリクエストは9千トークンのリクエストと同じトークンあたりレートで課金されます」。プロンプトキャッシングとバッチ割引も、コンテキスト全域に標準レートで適用されます。

これはベンチマーク比較ではなく、価格構造の比較です。3社の性能を突き合わせる共通ベンチマークはここにはなく、それぞれが自社の価格表に載せている課金ルールを並べただけです。実務的な含意は明白です。RAGのようにコンテキスト長がでこぼこなワークロードなら、閾値をまたぐリクエストが予算を静かに崩しかねません。閾値のあるプロバイダーでは、コンテキスト長の分布をモニタリングし、閾値のすぐ下で切り詰めるだけで大きな節約になることもあります。

最大のレバーは出力トークンである

ここまでの計算は、ずっと同じ場所を指してきました。出力は単価が5〜6倍で、キャッシングを有効にするとトークンコストの84%まで上がります。それなのに出力は、ほとんどのコスト記事で最後に1段落だけ扱われます。順序が逆です。

出力トークンを減らす方法は、つまらないほど単純です。

max_tokensを実際に必要な値に設定してください。上限であって目標値ではありませんが、暴走を止める最後の防衛線です。
出力形式を強制してください。分類タスクでラベル一つだけが必要なのに、モデルが3段落の説明を付けているなら、その説明の全部が5倍の単価で請求されます。構造化出力（JSONスキーマ）は、精度のツールである前にコストのツールです。
「ステップごとに説明して」の価格を意識してください。推論過程を長く引き出すプロンプトは、その分だけ出力トークンを使います。最終的な答えだけが必要な自動化パイプラインでは、それは単なる無駄です。（参考までに、GoogleのVertex価格表は出力の項目をそのまま「Text output (response and reasoning)」と記しています — 推論トークンも出力として課金されるという意味です。）
リトライを数えてください。失敗した呼び出しも、生成された出力トークンの分だけお金が出ていきます。パース失敗で3回リトライするパイプラインは、出力コストが4倍です。

入力側にも、タダで得られる節約が一つあります。Anthropicの価格ドキュメントは、ツール使用時に自動で付くシステムプロンプトのトークン数をモデル別に公開しています — Opus 4.8はauto/none基準で290トークン、Opus 4.7は675トークンです。ここにツール定義自体のトークンが加わります（例: bashツールはOpus 4.7・4.8で325トークン）。使わないツールを毎リクエストに載せて送っているなら、それは毎回払う税金です。ツール定義はプレフィックスの前方にあるので、キャッシングでカバーできるという点も一緒に覚えておいてください。

では何から始めるべきか

順序があります。上から順にやってください。

ステップ1 — まず計算。直近1日分のusageフィールドをかき集めて、項目別（未キャッシュ入力 / キャッシュ読み取り / キャッシュ書き込み / 出力）の金額を出してください。出力が60%以上なら、キャッシングのチューニングは優先事項ではありません。

ステップ2 — BatchかFlexに移せるトラフィックを探す。ユーザーがリアルタイムで待っていないリクエストがあるなら、入力・出力の両方に50%がかかります。単一のレバーとしては最大です。24時間待てるならBatch、待てないなら（OpenAIで）Flex。

ステップ3 — 出力を締める。形式の強制、max_tokens、不要な推論の削除、リトライの削減。単価5〜6倍の項目なので、効果がそのまま掛け算で効きます。

ステップ4 — その次にキャッシング。5分以内に同じプレフィックスが2回以上再利用されるトラフィックだけで有効にしてください。固定資産を前に、変動データを後ろに。最小トークン数を超えたかをusageフィールドで確認してください（静かに失敗します）。

ステップ5 — ルーティング。簡単なリクエストを安いモデルに下ろすものの、必ず「自分のプロンプトの実際のトークン数 x 単価」で比較してください。世代が違えば、単価表の比較は無意味です。

ステップ6 — コンテキスト長の分布を見る。閾値のあるプロバイダーを使っているなら、ロングコンテキスト割増が予算を蝕んでいるかもしれません。

いつこれをやるべきでないのか

正直になるべき部分です。この記事の大部分は、あなたには必要ないかもしれません。

請求書が月に数十ドルなら、何もしないでください。キャッシュブレークポイントを設計してバッチパイプラインを組むエンジニアの時間のほうが、節約額よりはるかに高くつきます。LLMコスト最適化は、請求書がエンジニアの人件費と同じ桁になったときに始める仕事です。
トラフィックが低頻度なら、キャッシングは損です。前の損益分岐の計算が、そのまま答えです。
品質がまだ固まっていないなら、ルーティングしないでください。安いモデルに下ろして精度が落ち、リトライと人の介入が増えれば、総コストはむしろ上がります。評価セットなしのルーティングは、コスト最適化ではなく品質のギャンブルです。
ユーザーが待っている経路にバッチを使わないでください。当たり前に見えますが、「50%」という数字に釣られて対話型エンドポイントをバッチに移そうとする試みを、実際に見かけます。
キャッシングとバッチを重ねると、掛け算になります。Anthropicドキュメントは、キャッシングの倍率がバッチ割引を含む他の価格修飾子と「掛け合わせて適用される（stack）」と明記しています。良い知らせですが、そのせいで見積もりの計算が紛らわしくなります — 単純に90%と50%を足して140%割引にはなりません。逆にFast modeはバッチと併用できず、Managed Agentsのセッションにはバッチ割引・Fast mode・データレジデンシー倍率が適用されません。

おわりに

一文に縮めるとこうです。割引率は、その項目が請求書に占める割合の分だけしか総額を減らしません。

キャッシュ読み取りが入力単価の10%なのは事実です。そしてそれが総額を25.5%しか減らせないことも — Anthropic自身の計算例で — 事実です。2つは矛盾しません。出力トークンがすでにコストの60%を食っていただけです。この構造を理解すれば、「90%削減」のような見出しにもう揺さぶられなくなります。そういう見出しは、項目の割引率を請求書の削減率であるかのように使っているのです。

だから順序はいつも同じです — 請求書を項目別に分解し、いちばん大きな項目から手を付け、各レバーの代償（24時間の期限切れ、リソース不足、キャッシュ書き込み料金、品質低下）を明示的に計算してください。そして、この記事の数字も含めて、すべての価格は今日（2026年7月17日）時点のものであり、頻繁に変わります。下のリンクを開いて自分で確認するところから始めてください。変わらないのは価格ではなく、算数です。