Claude Fable 5.1のキャッシュコスト値下げ後、Agentコストが下がらない理由は？2026年調査

2026年9月の今週は、モデルをすぐ戻さず、動的な前置き、ツール定義、TTL、usage集計を順番に確認してください。キャッシュが正常に読まれているのに総費用が高い場合は、出力、再試行、ツール処理、Mac占有時間を分離して負荷を振り分けます。

1対象読者と今週の判断

この記事は、Claude APIのワークロードをClaude Fable 5.1へ移行したものの、cache writeが頻発するAgent開発者向けです。モデル料金とツール実行、クラウド上のMac占有を分けて管理したいプラットフォームエンジニアにも適しています。

また、移行前後の実タスク記録で効果を判断したいFinOps担当者や技術責任者にも役立ちます。機能比較やeffort設定の解説ではなく、キャッシュによるコスト削減が成立しない原因を問題軸で切り分けます。

注意：キャッシュ読み取りの単価が下がったことと、Agentタスク全体の費用が下がることは同じではありません。Anthropicが示す削減見込みも特定のワークロードを前提にした推定であり、すべてのAgentにそのまま適用できる確定値ではありません。最新のモデル情報はAnthropicのモデルページとClaude Platformのリリースノートで確認してください。

2最初に見る症状と請求項目

「Claude Fable 5.1はなぜcache writeを繰り返すのか」を調べるとき、総入力Tokenだけを見るのは危険です。Prompt cachingでは、通常の入力、キャッシュ作成、キャッシュ読み取り、出力Tokenが別のusage項目として返されるため、まずリクエスト単位の記録を保存します。公式のusage項目と入力Tokenの計算を基準にしてください。

動的なタイムスタンプ、タスク状態、利用者ごとの変数、キュー情報を固定のシステム指示より前に置くと、後ろに同じ文面が続いていても共通のキャッシュ接頭辞が変わります。その結果、各リクエストが新規書き込みになり、読み取り単価の変更を活かせません。

修正の基本は、安定したツール定義、システム指示、組織共通のコンテキストを先頭へ集め、タスク状態や利用者固有の値を後ろへ移すことです。キャッシュの失効条件は公式のキャッシュ無効化一覧と照合し、見た目が同じかではなく、リクエストの構造が同じかを確認します。

3ツール定義と推論設定の差分

Claude APIのキャッシュ命中率が低い場合、プロンプト本文だけを比較してはいけません。tool_choice、並列ツール設定、画像の有無、effort、利用モデル、ツール配列の順序まで、隣接リクエストで変化していないかを確認します。

ツールのSchemaを自動生成している構成では、説明文の順序、任意項目の並び、既定値の出力形式が変わるだけでも、内容のハッシュが異なる可能性があります。動的なツール発見を毎回共有キャッシュへ含める設計も、安定した前置きを壊しやすい構成です。

ツール利用にはモデル入力以外の料金要素があるため、ツール利用の料金説明も確認します。キャッシュされた入力が増えても、同時にツール呼び出し回数や外部APIの応答待ちが増えていれば、タスク全体では安くなりません。

4TTLとタスク周期の組み合わせ

「長いAgentタスクは短いキャッシュと長いキャッシュのどちらがよいか」は、タスクの待ち時間で判断します。短い対話を連続して処理するAgentと、キュー待ちや人手承認を挟んで再開するAgentでは、同じTTLを設定する理由がありません。

TTLのライフサイクルと利用条件はキャッシュの動作説明を参照してください。短いTTLと長いTTLのどちらが常に得になる、という固定の節約率は置けません。書き込み回数、読み取り回数、実際の呼び出し間隔を同じ集計窓で比較する必要があります。

5モデル費用と実行環境費用

Agentでprompt cachingを使っているのに請求額が下がらない場合、キャッシュの問題と決めつける前に、費用を少なくとも次の層へ分けます。

長いコード生成の出力や、失敗したツール呼び出しの再試行は、キャッシュ読み取りが正常でも発生します。Xcodeのビルド、画面操作、Shell実行、外部サービスの待機は、モデルTokenとは別にMacの占有時間を消費します。したがって「モデル入力が安くなったか」と「完成したタスクがいくらかかったか」を同じグラフに重ねるだけでは原因を誤ります。

組織単位の集計を使う場合は、Messages Usage Reportの項目が自社のリクエストログと対応しているか確認します。モデル、ワークスペース、タスクID、リクエスト時刻、usage、再試行番号を保存し、異なるモデルや請求先を混ぜないことが重要です。

6cache writeが続く場合の修復手順

次の順番で進めると、キャッシュ設定だけを何度も変える無限ループを避けられます。

1. 代表タスクを固定します。 安定した共通前置きを持ち、成功と失敗の両方が含まれるAI Agentの処理を選びます。モデル、ツール、effort、実行環境を記録します。
2. リクエストを連番化します。 同じタスクIDに対して、通常入力、cache creation、cache read、出力Token、停止理由をリクエストごとに保存します。
3. 前置きを分割します。 システム指示、固定ツール、公共コンテキストを前半へ置き、時刻、ユーザー値、タスク状態、キュー情報を後半へ移します。
4. ツール構造を固定します。 Schema、ツール配列の順序、tool_choice、並列実行の設定をバージョン管理し、動的なツール発見は共通キャッシュから切り離します。
5. 呼び出し間隔を測ります。 人手承認、キュー、バックオフ、外部API待ちを含め、次のリクエストまでの実時間を測定します。その分布に合うTTLだけを比較します。
6. 再試行を別集計にします。 同一の入力を最初から再送しているのか、失敗したツールだけを再実行しているのかを分け、停止条件と最大反復条件を設けます。
7. Mac実行を計測します。 Xcodeビルド、Shell、ブラウザー操作、待機、手動介入の時間をタスクIDに関連付けます。モデル処理が終わってもMacを保持している時間を見落とさないでください。
8. 同条件で回帰します。 修正前後で同じモデル、ツール、TTL、入力、実行環境を使い、cache read比率だけでなく、重複書き込み、成功率、再試行回数、Mac占有時間を比較します。

7回帰結果による分岐

判定はキャッシュ命中率だけで終えません。次のように、キャッシュの状態と完成タスクの費用を交差させます。

ここで、キャッシュの読み取り単価や書き込み条件だけを追い続けるのは得策ではありません。長い出力が必要な処理、ツールを何度も呼ぶ処理、ビルドや画面操作が中心の処理は、キャッシュを共有する定型Agentから分離し、専用の停止条件や実行時間上限を設けた方が再現性を保ちやすくなります。

今週の里程標は、まずリクエスト単位のusageを取得し、次に前置きとツール定義の差分を固定し、その後にTTLを実測の呼び出し間隔へ合わせることです。移行前後を同じ条件で比較できるまで、モデルを戻す判断も、全チームへ展開する判断も保留してください。

8現行構成とMac構成の切り分け

現在の構成が共有キャッシュを使えていても、外部API、ブラウザー、Shell、Xcodeビルド、待機中の実行環境が一つのAgentに集中していれば、モデル費用の改善が完全なタスク費用に反映されません。特に再試行時に環境を保持し続ける構成では、Token請求とは別に占有時間、並列枠、ビルド待ちが積み上がります。

そのような処理を一時的な検証やチーム横断のAgent実験で運用するなら、物理機を先に購入するより、必要な期間だけMac環境をレンタルして実行時間と同時利用数を記録する方が判断しやすい場合があります。反対に、長期間の安定した高負荷処理や専用の物理インターフェースが必要な業務では、自社保有のMacや固定環境の方が適しています。Mac環境の接続条件はvpstixのMac利用案内で確認でき、導入前のサービス範囲はvpstixのサービス案内から確認できます。

まずはClaude Fable 5.1のキャッシュコスト値下げを理由に構成を戻すのではなく、usageとタスク実行記録を一組で出力してください。問題がキャッシュではなくツール実行やビルド占有にあるなら、モデル設定の微調整より、不要なループを止め、長時間処理を分流し、必要な時間だけMac環境を確保する方が、完成タスク単位の費用を下げる近道になります。