開発中に Claude Code のキャッシュミスで大量トークン消費を踏んだ — セッション共有と fork の備忘録

複数のアプリからClaudeに話しかける仕組みを作ろうとした。Blenderアドオンとデスクトップアプリのセッションを共有すれば、会話を引き継ぎながら効率的に使える、と考えたのだ。ところが、それは大きな落とし穴だった。アプリ間で切り替えるたびに、キャッシュが全損する。積み上がった会話全部が、キャッシュなしの単価で請求されるのだ。数十万トークンが毎回消費される。共有セッションへの外部割り込みはどう工夫してもキャッシュが効かない。公式ドキュメントにもこの罠は書かれていない。結局、妥協案に落ち着いた。--fork-sessionで初回だけ別セッションを切り、以降はそっちで継続する。デスクトップとBlenderは別々に動く。キャッシュはそれぞれで機能する。

AIの鬼が見るべきは、「見えない請求」の構造である。キャッシュとは単なる性能チューニングではない。これはコスト構造そのものだ。セッション設計の違いで、請求額が10倍変わる。技術者が気づかなければ、経営層が決算で驚く。複数アプリのAI連携が珍しくない時代に、セッション戦略はもはや必須の設計項目になった。「API仕様書」をレビューするのと同じ厳密さで、「キャッシュ互換性」を確認する習慣をつけなければ、後から大きな損失になる。

開発チームが今やることはシンプルだ。複数のシステムからAIを呼ぶなら、キャッシュを壊さないセッション設計を最初に決めてから実装に入れ。後で気づいたら手遅れ。「なぜキャッシュが効かないのか」という調査も、時間と金の無駄だ。最初から「キャッシュが効く設計とは何か」を技術チームで詰めておけ。