自走AIのループ間隔はキャッシュで決める

🔁「間隔を空けたほうが安い」と思っていた

呼び出しを減らせば安くなる、と単純に考えていました。ところが、間隔を空けた設計のほうが割高になっていた。

最初のループは、素朴に「あまり頻繁に呼ばないほうが節約になるだろう」という考えで、 周回のあいだにしっかり間を置いていました。呼び出し回数が少ないほど安い―― そう思い込んでいたからです。

ところが実際のコストを見ると、間を置いた設計のほうが、こまめに回した設計より割高になっていました。回数を減らしたのに高い。理屈が合わない。 その原因が、プロンプトキャッシュの仕組みでした。

🧊プロンプトキャッシュは「使わないと溶ける氷」

毎回ほぼ同じ前置き（システムプロンプトや道具の定義）を送るなら、その部分はキャッシュから安く読める。ただし放っておくと消えます。

エージェントを回すとき、リクエストの前半――システムプロンプトやツールの定義――は 毎回ほとんど同じです。この共通の前置き部分をキャッシュしておくと、次からは安く読み込める仕組みがあります（プロンプトキャッシュの公式ドキュメント）。読み込みは安く、書き込み（キャッシュを作り直す）はやや割高、という値付けです。

大事なのは、このキャッシュに寿命があることです。一定時間、誰も使わずに放っておくと消えます。氷と同じで、使わなければ溶ける。 溶けたあとにもう一度回すと、キャッシュを一から作り直すぶんの割高な書き込みを、 毎周ごとに払うことになります。

つまり――間隔を空けすぎると、周回のたびにキャッシュが溶けきっていて、 安く読める恩恵をまったく受けられない。回数は少ないのに、1 回あたりが高くつく。 これが「間を置いたほうが割高」の正体でした。

⏱️次の周回を、キャッシュが溶ける前に回す

ループの間隔を、キャッシュの寿命より短く保つ。この一点を設計の基準に据えました。

そこで運用を変えました。ループの周回間隔をキャッシュの寿命より短く保つ、というルールです。前の周回が作ったキャッシュがまだ溶けていないうちに次を回せば、 共通の前置きは安い読み込みで済みます。

逆に、どうしても間隔が長くなるループ――たとえば一日に何度も動かないもの――は、 キャッシュ前提のコスト計算をあきらめました。 溶ける前提で組んだほうが、見積もりが現実に合うからです。「速く回せば安い区間」と「間隔が長くて割り切る区間」を分けて考える。これだけで、コストの読みがぐっと安定しました。

長い寿命のキャッシュを選べる仕組みもあります。ただ、その場合は書き込みがさらに割高になるので、 「間隔がどのくらい空くか」と「何回読み直すか」を天秤にかける必要があります。 うちは、まずは短い寿命のまま間隔を詰める、という素朴な方針でうまくいっています。

🧮前置きに時刻を混ぜると、静かに溶ける

前置きの中に毎回変わるもの（現在時刻・ランダムなID）が一文字でも混ざると、キャッシュは効きません。しかもエラーは出ない。

間隔を詰めても効かないときは、たいてい別の落とし穴があります。 キャッシュは前半の並びが一文字でも変わると、それ以降が丸ごと無効になります。だから、共通の前置きの中に「現在時刻」や「毎回違う ID」を混ぜてしまうと、 毎回別物とみなされて、キャッシュがまったく効きません。

やっかいなのは、これをやってもエラーが出ないことです。動きはするけれど、静かに割高になる。私たちは、変わりやすいもの（時刻や個別の質問）を 前置きから追い出して、なるべく後ろに置く、という並べ方を徹底しました。 安く読めているかは、応答に返ってくる「キャッシュから読んだ量」を見れば確かめられます。 ゼロが続くなら、どこかに溶かし込みが潜んでいる合図です。

🧭エージェントを回している人へ

ループを組む前に、まず「共通の前置きはどれか」「その寿命の内側で回せているか」を一度だけ確かめてみてください。

AI を自走させるとき、賢さのチューニングに気を取られがちです。 でも、コストを左右していたのは賢さではなく、回す間隔とキャッシュの寿命の関係でした。ここを外すと、同じ仕事をしても静かに割高になります。

明日から使えるチェックは、たった 3 つです。 リクエストの前半で毎回同じ部分はどこか。その部分をキャッシュに乗せているか。 そして、周回の間隔はその寿命の内側に収まっているか。 この 3 つを一度そろえるだけで、無駄な書き込みは根元から減ります。

あなたも、自走するAIを回していますか。 もしそうなら――止めるタイミングだけでなく、回す間隔を、コストの目で一度見直してみてください。