10月28日、EZEKIAS BOKOVEが「What caching does for an LLM agent ?」と題した記事を公開した。この記事では、LLMエージェントにおけるキャッシング（メモリ検索・埋め込み・ツール結果・プロンプトの4層）が実際のコスト削減にどう寄与するか、1500ターンの実測データをもとに検証した結果が詳しく紹介されている。
エージェントは「繰り返し」にお金を払い続けている
LLMエージェントは1ターンごとに推論コストが発生する。短いチャットでは気にならないが、数百・数千ターンになると話は変わる。しかも、その多くは「1分前に同じことをやった」ような重複処理だ。
EZEKIAS BOKOVEはこの問題を実際に測定するため、ハーネス（エージェントの周辺コード）に4つのキャッシュ層を実装した。
- メモリ検索結果のキャッシュ
- 埋め込み（embedding）のキャッシュ
- ツール実行結果のキャッシュ
- プロンプト先頭部分のキャッシュ（プロバイダーのプロンプトキャッシュ活用）
そして1500ターンの会話を流し、各キャッシュがどれだけ効くか、どこで破綻するかを測定した。
プロンプトキャッシュは「天気」と同じ：当てにするな
プロバイダーのプロンプトキャッシュとは、プロンプトの先頭から同じトークンが続く場合、プロバイダーが前回の計算結果を再利用してトークン単価を大幅に下げる仕組みだ。Nebius上のDeepSeek V4 Flash（元記事記載のモデル名）では、キャッシュヒット時のコストが通常の1/14（0.14→0.01 USD/100万トークン）になる。
ただし「先頭から一致」が条件なので、プロンプトの冒頭に日時を入れたり、メモリノートの順序が変わったりするだけで全滅する。
さらに厄介なのが、キャッシュヒット率がモデル・プロバイダーによって大きくばらつく点だ。同じ1500ターンテストを同一プロバイダー（Nebius）で複数モデルに流した結果：
- DeepSeek V4 Flash：入力トークンの約95%をキャッシュから取得
- Nemotron：ほぼキャッシュなし
- Gemini：前日はゼロ、翌日は50%超（ただしプロンプト末尾が伸びた場合のみ）
GeminiについてはVertex AI・Gemini API両方で計54〜95回のテストを実施したが、ある日は全くキャッシュされず、別の日は半分以上がキャッシュされた。著者の結論は明快だ：「プロバイダーのキャッシュは天気と同じ。自分のアカウント・ハーネス・プロンプト形状で実測してから設計しろ」。
ツールキャッシュは「自由テキスト検索」には効かない
ツール実行結果のキャッシュ（同じ検索を2回しないで済む）は直感的に有効そうに見えるが、実測では15〜18回の検索のうちヒットは1回だけだった。モデルは同じことを聞くとき、ほぼ毎回言い回しを変えるからだ。
類似クエリのファジーマッチを試みると1回あたり2件ほど追加でヒットしたが、4件に1件は「2024年の質問に2025年のキャッシュで答える」といった誤答を生んだ。
著者はツールをpure（同一入力なら常に同一出力）、ttl（有効期間付き）、never（副作用あり・絶対にキャッシュしない）の3クラスに分類している。「決済を再実行してしまうキャッシュはバグ」という指摘は実装上の重要な注意点だ。
本題：1500ターンで「記憶」の4方式を比較した
記事の核心はここだ。BOKOVEは日常会話1500ターンに個人情報24件（ロッカーコード、便名、医師名、予算など）を埋め込み、一部は後から訂正される設定にした。各情報は最後に言及されてから100〜1300ターン後に質問される。正答率とコストで4方式を比較した。
| 方式 | 内容 |
|---|---|
| Naive（素朴） | 全履歴をそのまま送り続ける |
| Compact（要約） | 定期的に古い会話を要約・圧縮する |
| Compact + 逐語検索 | 要約 + ユーザーの過去発言を検索して末尾に追加 |
| Extract（事実抽出） | 事実をノートとして抽出・管理し、必要時に検索 |
結果：要約（Compact）方式がすべての事実を正確に再現しつつ、最低コストを達成した。
コスト面での差は顕著だ。Naive方式では1500ターンでプロンプトが12〜14万トークンに膨らみ、コストが要約方式の7〜9倍になった。一方、要約方式は古い会話を定期的に数行の箇条書きに畳み込む（1500ターンで11〜12回）。圧縮はバックグラウンドで非同期に行われ、ユーザーの待ち時間には影響しない。
事実抽出方式は「小さくて安定したメモリ」を保つのでプロンプトはキャッシュされやすいが、ノート更新のモデル呼び出しコストが積み重なり、要約方式より約3割高くなった。
「Compact + 逐語検索」方式については、要約に加えてユーザーの過去発言をキーワード検索で末尾に付加する構成だ。正答率は要約単体と同等を維持しつつ、追加検索コストが生じる分、純粋な要約方式よりわずかにコストが増す結果となった。追加の検索ステップが精度向上に寄与しにくいケースでは、シンプルな要約方式で十分といえる。
他モデルでの検証では、Gemini 3.5 Flash-Lite（元記事記載のモデル名）でも要約方式が24件全問正解・最安値（0.96〜0.98 USD）だった。一方、GLM-5.3（中国のZhipu AIが開発するモデル）では事実抽出が最安（3.13 USD対要約の3.42 USD）と逆転する場面もあり、モデルの特性によって最適解は変わりうる。要約方式が「本命」と言えるのはあくまで多くのモデルで成立する傾向としてであり、特定モデルでは別の方式が優位になる点には注意が必要だ。
なお、モデル選択がコストに与える影響は記憶設計より大きく、同じ要約方式でDeepSeek V4 Flash（0.13 USD）→ Gemini Flash-Lite（約0.97 USD）→ GLM-5.3（3.42 USD）と大きく変動する。
メモリシステムが失敗する本当の理由：「保存」ではなく「検索」
初期実装では1回あたり3〜4件の事実を取りこぼしていた。原因はメモリの欠落ではなく検索の打ち切りだった。
対策として、埋め込みによる意味検索（セマンティック）とBM25によるキーワード検索を組み合わせたハイブリッド検索を実装した。日付やコードのような固有値は埋め込みで意味を捉えにくいため、キーワード検索の役割が大きい。この変更で24件全問正解を達成した。
「事実の保存は簡単。再び見つけ出す部分でメモリシステムは失敗する」という指摘は、RAG（検索拡張生成）設計全般に通じる教訓だ。
まとめ
BOKOVEが数週間の実測から導いた結論は、キャッシングへの楽観論に対する修正だ。プロバイダーのプロンプトキャッシュはモデルによって効果が激変し、ツールキャッシュは自由テキスト検索にはほぼ効かない。そして長期エージェントで最もコストを下げたのは、派手な設計ではなくシンプルな要約圧縮だった——ただしモデルによっては逆転もある。コードは記事末尾で公開されており、同じ条件で再実行できる。
詳細はWhat caching does for an LLM agent ?を参照していただきたい。
