なぜAnthropicは統一された節約率を直接示すのではなく、「一般的なワークロード」「高度にエージェント的なワークロード」といった曖昧な分類を使うのか?
なぜなら、節約できる割合は本質的にモデルの固定的な属性ではなく、「あなたの利用パターン」と「値下げ幅」という2つを掛け合わせた結果だからだ。値下げ幅自体(75%)は全員に共通で固定されているが、請求額に占めるキャッシュ読み取りの割合は完全に個々の利用パターンに依存しており、アカウントやタスクの種類によって大きく異なりうる。もしAnthropicが単一の数字を示していたら、キャッシュの割合が特に高い、あるいは特に低いユーザーにとっては、不正確な情報になってしまっただろう。
「一般的なワークロード」と「高度にエージェント的なワークロード」という2つの分類を使うことは、本質的にはキャッシュ割合の2つの代表的な端点を説明しているのであって、厳密な技術的定義ではない——これは、この記事が「自分がどちらの分類に『近い』か」をまず判断するのではなく、直接自分の実際の割合を計算し直すことを推奨している理由でもある。この分類はコミュニケーションを簡便にするための表現であって、そのまま適用すべき厳密な公式ではない。
もし実際に計算した節約率が、公式の言う25%や45%と大きく違っていたら、それは自分の計算が間違っているのか?
必ずしもそうとは限らない。この公式(キャッシュ割合×75%)が算出するのは理論上の期待値であり、実際の請求額はいくつかの要因によってこの期待値からずれることがある。1つ目の要因はエフォートレベル(effort level)だ——Fable 5.1はClaude Codeではデフォルトで高強度(High effort)、Claude CoworkとClaude.aiではデフォルトで中強度(Medium effort)が使われる。エフォートレベルの違い自体が出力トークンの数量に影響し、それによって請求額における入力・出力・キャッシュ読み取りの相対的な比率が変わってくる。
2つ目の要因はタスク自体の挙動の変化だ——もしFable 5.1の推論能力向上によって、同じタスクがより少ない往復のやり取りで完了したり、生成される出力内容自体がより簡潔になったりすれば、請求額の構成はFable 5を使っていた頃の慣れたパターンとは異なるものになる。古い利用記録をそのまま公式に当てはめれば、算出される期待値は当然、新モデルの実際の請求額とずれが生じる。より慎重なやり方は、新モデルをしばらく実際に動かした後の利用データを手に入れてから改めて計算し直すことであり、アップグレード前の古いデータだけで一回限りの見積もりをすることではない。
自分の実際のキャッシュ割合を計算するには、どんなデータが必要で、具体的にどう計算すればよいのか?
最低限必要なのは、ある一定期間(ある1日だけの異常な変動を避けるため、少なくとも数日から1週間程度の通常利用をカバーすることが望ましい)の利用明細で、その中で3つの項目を区別できる必要がある。新規入力トークンの使用量、モデル出力トークンの使用量、キャッシュ読み取りトークンの使用量だ(キャッシュ書き込みを利用している場合は、それも記録しておいてよいが、書き込みの価格自体は変わっていないため、今回の計算には影響しない)。
計算方法自体はシンプルだ。キャッシュ読み取りのトークン数を、「新規入力トークン+出力トークン+キャッシュ読み取りトークン」の合計で割ると、得られる比率があなたの請求額に占めるキャッシュ読み取りの割合になる。この割合に75%を掛ければ、あなたのワークロードが理論上節約できる全体の費用の割合が得られる。例えば、ある期間のキャッシュ読み取りトークンが600万、新規入力が300万、出力が100万で、合計が1000万だった場合、キャッシュ読み取りの割合は60%となり、75%を掛けると約45%になる——これは、あなたの利用パターンが既に公式の言う「高度にエージェント的なワークロード」に近いことを意味する。
算出した節約率が低かった場合、キャッシュ読み取りの割合を能動的に高めて、公式が言う高い節約率の側に近づける方法はあるのか?
ある。ただし、その前提として、それが本来のタスクのニーズに合致していることが必要であり、節約のためだけに意図的にワークフローを歪めることではない。実際にキャッシュ割合を高める方法としては、通常、反復性の高い内容(システム指示、ツール定義、よく参照する文書、プロジェクトの背景説明)をできるだけ安定させて変えず、会話やリクエストの中の固定された位置に置くことで、その部分がキャッシュにヒットする機会を得られるようにすることだ。毎回少しずつ異なる言い回しで説明し直すのではなく——たとえ意味が同じであっても、言い回しの些細な違いがキャッシュミスを引き起こし、通常価格での計算に戻ってしまう可能性がある。
もう1つの方向性は、自分のタスクが、それぞれ独立していて文脈のつながりがない多数の短いリクエストに分割するのではなく、より長く連続したセッションにまとめられないかを検討することだ——キャッシュヒットの前提は「この内容が以前既に処理されたことがある」ことであり、毎回のリクエストが完全にゼロから始まるなら、当然ヒットするキャッシュは存在しない。ただし、この2つの調整はいずれも、タスク自体の合理性を優先すべきだ。もし利用パターンがもともと大量の独立した無関係な短い問い合わせで構成されているなら、無理に長い会話にまとめることは、かえって応答の質を犠牲にしてしまう可能性があり、割に合わない取引になりかねない。
Claude Fable 5.1はプロンプトキャッシュ読み取り(prompt cache reads)の価格を100万トークンあたり1ドルから0.25ドルへと、75%削減した。Anthropic公式の見積もりは「一般的なワークロードでは25%節約、高度にエージェント的なワークロードでは45%節約」というものだが、この2つの数字は無作為に決まったものではなく、自分で計算できる公式が背景にある。この公式を理解すれば、公式が示す2つの大まかな区間のどちらかに当てはめるのではなく、自分の実際の請求額がどれくらい節約できるかをおおよそ見積もれるようになる。
Fable 5.1の基本入力価格は100万トークンあたり10ドルのまま、出力価格は50ドルのまま、5分間キャッシュ書き込みは12.5ドルのまま、1時間キャッシュ書き込みは20ドルのままだ——これらはすべて変わっていない。唯一変わったのはキャッシュ読み取りで、1ドルから0.25ドルへと下がった。つまり、あなたの請求額の中で単価が安くなったのは「キャッシュ読み取り」というこの一項目だけであり、他の項目(新規入力トークン、モデルの出力トークン、キャッシュ書き込み)の単価はまったく変わっていない。
1つの単価だけが変わったため、実際に節約できるパーセンテージは、おおよそ「あなたの請求額の中でキャッシュ読み取りがもともと占めていた割合」に「75%」を掛けたものに等しくなる。もしあなたの請求額の中でキャッシュ読み取りがもともと3分の1を占めていたなら、実際の節約額は33%×75%で約25%となり、これはちょうど公式が言う「一般的なワークロード」に対応する。もしあなたの請求額の中でキャッシュ読み取りが6割を占めていたなら、節約額は60%×75%で約45%となり、公式が言う「高度にエージェント的なワークロード」に対応する。これが、公式が単一の数字ではなく範囲を示している理由でもある。人によって請求額に占めるキャッシュ読み取りの実際の割合が異なるため、同じ75%の割引を適用しても、算出される全体の節約幅は当然人によって異なってくる。
キャッシュ読み取りの割合が高い典型的なシナリオは、同じ大規模なコンテキストが何度も繰り返し読み込まれる場合だ——例えばエージェントが同じコードベース、同じシステム指示、同じツール定義群を繰り返し読み込んだり、蓄積され続けてどんどん長くなっていく会話履歴を読み込んだりするケースだ。この種のタスクは、実行の一歩ごとに、既に処理済みのコンテキストを改めて読み込む必要があることが多く、この繰り返される読み込みこそが、キャッシュの仕組みが最適化するよう設計されている対象だ。逆に、利用パターンが毎回新規の、互いにあまり関連のない内容を送信するもの(例えば毎回独立した短い質疑応答で、蓄積される文脈がない場合)であれば、キャッシュ読み取りはそもそも請求額の中でわずかな割合しか占めておらず、今回の値下げがあなたに与える実際の影響も相応に小さくなる。
公式が示す2つの大まかな数字のどちらかに当てはめるのではなく、自分が実際にどこに位置するのかを知りたい場合、最も直接的な方法は、ある期間の実際の利用記録を振り返り、キャッシュ読み取りのトークン使用量を、総トークン使用量(入力+出力+キャッシュ読み取り)で割り、請求額全体に占めるキャッシュ読み取りの実際の割合を算出することだ。それに75%を掛ければ、あなた自身のワークロードがおおよそ何パーセント節約できるかがわかる。もしまだこの利用データを手元に持っていないなら、時間をかけてそれを取得する価値がある——自分を「一般的」か「高度にエージェント的」かのどちらかに当てはめて仮定するよりも、はるかに正確な見積もりが得られる。