前回は、ツール定義を最初から渡さない遅延読み込みを紹介しました。あの記事の最後に「見つかったツールはコンテキストの末尾へ追加されるので、キャッシュが効きやすい」と書きました。
今回はその一般化です。「減らす」のではなく「一度渡したものは、1バイトも動かさない」。コストと速度の両方に効く、KVキャッシュの話をします。
エージェントは「入力」にお金を払っている
エージェントはツールを使うたびに、過去のやり取りすべてを含んだコンテキストを送り直します。対して出力は、短い関数呼び出し1個。
Manusの公式ブログ（2025年7月）によれば、同社のエージェントでは平均の入出力トークン比が約100:1。つまり支払いのほぼすべてが入力処理です。
そして入力には、公式に「値引き」が用意されています。
- Anthropic: キャッシュ済み入力はベース価格の0.1倍。Claude Sonnet 5なら $2/MTok → $0.20/MTok（10分の1）
- OpenAI: キャッシュ済み入力トークンは「最大90%割引」
仕組み：完全一致しか許されないキャッシュ
LLMは入力を処理するとき、トークン間の関係をまとめた中間計算結果（KV状態）を作ります。プロンプトキャッシュはこのKVテンソルを保存しておき、同じプレフィックスを持つ次のリクエストで再利用する——これがOpenAI公式ドキュメントの説明です。
重要なのは「同じ」が完全一致だという点。1トークンでも違えば、そこから先は全部再計算になります。
Anthropicのキャッシュ対象は tools → system → messages の順で連結した全体。この順序を覚えておくと、「何がキャッシュを壊すか」が見えてきます。
車載開発にたとえると、配線を1本引き直すと、下流のECUは全部再認証になるのと同じです。キャッシュは「先頭からの一致」でしか成立しません。
キャッシュを殺す3つの罠
罠1: プロンプト先頭のタイムスタンプ
「現在時刻を伝えるために、システムプロンプトの先頭に日時を入れる」のは典型悪手です。秒単位の時刻は毎回変わるので、キャッシュが毎回全滅する。Manusの公式ブログも真っ先にこれを挙げています。時刻が欲しいなら、コンテキストの末尾（ユーザーメッセージ側）に置きましょう。
罠2: 過去メッセージの書き換え
「前のターンの観測結果を要約して置き換える」処理を毎ターン実行すると、置換位置から先がキャッシュ不能になります。基本は追加専用（append-only）。要約・圧縮するなら、まとめて実行して置換の頻度を下げるのがポイントです。
罠3: ツール配列の入れ替え
OpenAI公式ドキュメントは、tools の「名前・説明・スキーマ・順序」の変更がキャッシュに影響すると明記しています。自前でツールを抜き差しするのはキャッシュ面でも動作面でもリスク大。やるなら前回紹介したTool Searchのような公式の遅延読み込み機構を使うのが安全です。
実践チェックリスト
- 可変情報（現在時刻、検索結果など）はコンテキストの末尾に置く
- JSONのシリアライズはキー順を固定する（言語・ライブラリによってはキー順が非決定的で、黙ってキャッシュを壊す）
- Anthropicのキャッシュ寿命はデフォルト5分。ただしキャッシュを使うたびに無料で更新されるので、頻繁に呼ぶエージェントなら実質無期限。1時間TTLは書き込みが2倍コスト
- APIレスポンスのusageを確認し、キャッシュ読み（cache read）トークンがちゃんと出ているか定期チェックする
考察：「削る」と「固定する」は矛盾しない
ここ数回の「減らす」話と、今回の「動かさない」話は一見逆方向に見えます。でも原点は同じ、「コンテキストは有限リソース」という認識です。Anthropicはこれを「モデルにはattention budgetがある」と表現しています。
- 削る → 1回の推論の質を守る（context rot対策）
- 固定する → 推論間の再利用を最大化する（コスト・レイテンシ対策）
設計の本体は結局、「安定なものを前、可変なものを後ろ」という順序設計に集約されます。静的なシステムプロンプトとツール定義を前に固め、履歴は追加専用で積み、そのターンだけ必要な一時情報を末尾に置く。この1行に全部入っています。
まとめ
- エージェントのコストは入力が支配する（100:1）。入力には10分の1の値札が最初から付いている
- 値引きは「完全一致」しか効かない。1トークンの差が10倍の差になる
- 今日からできる3つ: 時刻は末尾・履歴は追加専用・ツールは固定
「減らす」設計と「動かさない」設計、両方揃って初めてコンテキストエンジニアリングです。
PL視点では「トークン数」より「キャッシュヒット率」を見る
コスト見積もりで入力トークンの総数だけ数えても、実費は変わりません。見るべきはキャッシュ済み入力の割合です。APIのusageレスポンスでキャッシュ読みトークンが記録されているので、運用ダッシュボードに入れておくと、「ある改修を入れた瞬間に命中率が落ちた」という発見ができます。速度の劣化も、まずこの指標で説明がつくことが多いです。
参考ソース
- Anthropic公式ドキュメント: Prompt caching（料金倍率・TTL・キャッシュ順序）
- OpenAI公式ドキュメント: Prompt caching（90%割引・KVテンソル・toolsの影響）
- Manus公式ブログ: Context Engineering for AI Agents（2025年7月）（100:1・タイムスタンプ罠・append-only）
- Anthropic Engineering: Effective context engineering for AI agents（2025年9月）