Claude Code の「キャッシュが壊れる」を一次資料まで遡る——Reddit の不具合報告→公式postmortem→arXiv論文2本
はじめに
AIコーディングアシスタントを長時間使っていると、「会話が長くなるほど品質が落ちる気がする」という体感が出てくることがある。この体感自体は珍しいものではなく、検索すると同じ訴えが大量に見つかる。「キャッシュが壊れる」「コンテキストが崩壊する」——見出しだけ見ると一つの現象のように読めるが、実際に一つずつ開いてみると、誰が言っているか・どこまで裏が取れているかがまるで揃っていないことに気づく。
この記事は、その揃っていなさを揃えずに扱う方法についての記録だ。結論を急がず、出典の性質を4段階に格付けし、格付けを保ったまま照合していく。主題は「バグがあったかどうか」という結論ではなく、その結論に至る前の、出典の扱い方にある。
出典を4段階で格付けする
裏取りを始める前に、まず出典の重みを固定した。
| 格付け | 内容 | 扱い方 |
|---|---|---|
| 公式一次 | Anthropic自身のドキュメント・エンジニアリングブログ | 最も重く扱う。ただし対象の世代（モデル・バージョン）を必ず確認する |
| 一次だが運営会社未関与 | GitHub Issue本文・実務者のコメント | 実際に起きた観測ではあるが、Anthropicが確認した事実ではない。係争中として保留する扱いを許す |
| 学術 | arXiv論文 | 数値の重みは大きいが、対象モデル・言語・タスクが現行と一致するかを先に確認してから数字を採る |
| 三次 | 個人の技術ブログ・孫引きの解説記事 | 機構（仕組みの整理）としては参考にするが、数字は採らない |
この表を先に固定したのには理由がある。同じ「キャッシュが壊れる」という一文でも、格付けが違えば扱いが変わる。特に危ういのは2段目——投稿者本人にとっては紛れもない一次の観測なのに、Anthropicが確認した話ではないという一点だけで、信頼度が公式一次とは全く別物になる。ここを混ぜると、うわさが事実の顔をして紛れ込む。
起点 ― 高評価のReddit投稿
調査の起点は、900件を超える支持を集めたRedditの投稿だった。投稿者は実行ファイルを逆アセンブルしたと主張し、2つのバグを指摘していた。中身の技術的な主張自体は今回は本題ではない。重要なのは、この投稿がその後どう扱われるべきかだ。
投稿には、本人による追記があった。
Issues linked in the description have been closed as resolved. Unfortunately I can’t verify those claims as I’m away from my PC.
コメント欄には、Anthropicの社員による否定も引用されていた。
Confirming this post isn’t the problem.
投稿者自身が「検証できない」と留保し、Anthropic側の人間が「これは原因ではない」と述べている。ここで、投稿が名指ししていたGitHub Issueの状態を実際に確認した。対応する2件は、いずれも修正済みとしてクローズされていた（2026-04-04・2026-04-01）。
投稿者の留保・Anthropicの否定・Issueの実際の状態、この3つが揃って初めて、この投稿を事実として採用しないという判断ができる。900件超の支持という数字は、判断材料としては使わなかった。支持の数は「多くの人が同じ症状を疑っている」ことは示すが、「その原因の説明が正しい」ことは示さない。
一次資料だが運営未関与のIssueを、直接読む
Reddit投稿とは別に、もう一つのGitHub Issueを直接開いた。本文とコメント全てを読むと、次のような機構が主張されていた。
Because many of CC’s own built-in reminders carry dynamic values … the smoosh produces different byte output turn-over-turn. The resulting byte drift in historical user messages breaks the prompt cache prefix …
このIssueはCLOSEDになっていた。だが、閉じた理由を確認すると、次のような自動コメントだった。
Closing for now — inactive for too long.
これは「修正されたのでCLOSED」ではない。しばらく動きが無かったので、ボットが自動的に閉じただけだ。同じ「CLOSED」という表示でも、直前の2件（修正済みとして閉じられた）とは意味が全く違う。この区別を付けずに「Issueは解決済み」とまとめると、放置されただけの主張を「片付いた」と誤読することになる。
このIssueについては、報告者自身が繰り返しこう書いていた。
Still zero @anthropic.com green-badge engagement.
主張の中身は具体的で、我々の運用にも直撃しうる形をしていた。だが格付けは「一次だが運営会社未関与」のままであり、Anthropic自身の確認は無い。結論は「棄却」でも「採用」でもなく、係争中のまま保留にした。
公式ポストモーテムに当たる ― ただし世代が違う
次に、Anthropic自身が公開しているポストモーテムを読んだ。品質劣化の報告について、公式は明確にこう書いている。
To state it plainly: We never reduce model quality due to demand, time of day, or server load. The problems our users reported were due to infrastructure bugs alone.
原因として、サーバの振り分けミス・出力の破損・コンパイラのバグという3件が具体的に説明されていた。これは正真正銘の公式一次資料であり、「品質劣化は実在し、原因はインフラ側にあった」という前例そのものだ。
ただし、対象のモデル世代を確認すると、現行世代よりも前のものだった。格付けが最も高い資料でも、対象世代が違えば、そのまま現行に当てはめることはできない。 ここで一度、「品質劣化の実例はある」という事実と、「その原因が今の環境にも当てはまる」という推測を、意図的に切り離した。
三次資料は、機構の整理だけを取る
裏取りの途中で、キャッシュの仕組みを図解した個人の技術記事にも当たった。この記事自体が、末尾に自己申告を書いていた（原文は中国語）。
数据来源说明：本文价格和机制数据来自多个 AI 的网络调研结果交叉验证，部分数据可能随时间变化，请以各家官方文档为准。
大意は「本文の価格・機構に関するデータは、複数のAIによるネット調査結果を突き合わせたものであり、各社の公式文書を正とすること」。書き手自身が「一次資料ではない」と明言している。
この記事からは、キャッシュの階層が「tools→system→messages」の順で上流の変更が下流を巻き込んで無効化するという機構の整理だけを参考にした。並んでいた価格試算や倍率の数字は、採らなかった。三次資料は、仕組みの見取り図としては役に立つが、数字の裏付けにはならない。
公式資料を「再読」したら、前提が複数覆った
裏取りが一通り終わった頃、以前読んだはずの公式のキャッシュ仕様を読み直した。今回の疑いに照らして読み直すと、以前は見落としていた一文があった。
Skills, commands, agents, hooks, LSP servers, monitors, and themes never invalidate the cache: anything they add to the request is appended after the existing conversation, so the next request pays for the new content but still reads everything before it from the cache.
「フックが多いほどキャッシュを壊しているのでは」という、この調査の出発点にあった疑いそのものが、公式一次資料によって否定された。フックや拡張機能は、追記されるだけでキャッシュを壊さない。壊すのは、モデルの切り替え・MCPサーバの接続変更・会話の圧縮など、公式が列挙する決まった操作だけだと明記されていた。
一度読んだ公式資料でも、別の疑いを持って読み直すと、拾えていなかった一文が出てくる。これが今回の調査でいちばん大きな軌道修正だった。「読んだ」と「照合できるまで読んだ」は別物だと、身をもって確認した形になる。
学術2本 ― 世代・言語・タスクが違う数字は持ち込まない
最後に、arXivの論文2本に当たった。片方は現行に近い世代のモデルを実際のセッションデータで測っており、こう報告していた。
Opus 4.6 … recall drops from 99.7% when such an attack is inserted in a 100K transcript to 69% when the same attack is inserted in an 800K transcript.
対象モデル・データセットともに現行に近く、この数字は参考値として持ち込める。もう1本は3年ほど前の、世代も言語もタスクも違うモデル群を対象にした論文だった。こちらは同じ「長い文脈の中央にある情報が拾われにくい」という形を示してはいたが、数字（正答率の絶対値）は現行世代には持ち込まなかった。示された形が2つの論文・複数世代にわたって再現しているという事実だけを受け取った。
出典を遡った道のり
起点: Reddit ↑955 投稿(一次だが運営未関与・本人が後日「検証できない」と追記)
│
├─▶ 対応するGitHub Issueの状態を実測
│ └─ 2件とも「修正済み」としてCLOSED(2026-04-04 / 2026-04-01)
│ └─ Anthropic社員の否定コメントも確認
│ └─ ⇒ 事実として採用しない(確定)
│
├─▶ 別のGitHub Issueを一次資料として直接読む
│ └─ CLOSEDの理由を確認 ── 修正ではなく「inactivity」の自動クローズ
│ └─ ⚠️ 棄却も採用もせず、係争中のまま保留
│
├─▶ 公式ポストモーテムに当たる(Anthropic自身・公式一次)
│ └─ 対象世代を確認 ── 現行より前の世代
│ └─ ⇒ 実例としては受け取るが、現行への適用は保留
│
├─▶ 三次資料(個人技術ブログ)で機構だけ整理
│ └─ 資料自身の自己申告(裏取りなしの二次調査)を確認
│ └─ ⇒ 機構の見取り図だけ参照・数字は採らない
│
└─▶ 公式一次資料を「再読」する ★ここで前提が覆る
└─ 「拡張機能はキャッシュを壊さない」という一文を発見
└──(戻りエッジ)──▶ 出発点の疑いそのものを撤回
│
└─▶ 学術論文2本で数値の裏取り
├─ 現行に近い世代 ── 数字を採る
└─ 3年前の世代 ── 形だけ採る(数字は採らない)
格付けを保ったまま出た結論
最終的に手元に残ったのは、「解決した謎」ではなく、確定した事実と、係争中のまま残った事実を分けた一覧だった。
| 主張 | 状態 |
|---|---|
| Redditが指摘した2つのバグ | 事実として採用しない（当人の留保・公式否定・Issue実測の3点で確定） |
| 別のGitHub Issueが主張する動的リマインダーの巻き込み | 係争中のまま保留（棄却も採用もしていない） |
| 拡張機能（フック等）がキャッシュを壊すという疑い | 公式一次資料により否定（今回の調査の出発点そのものが撤回された） |
| 長い文脈の中央にある情報が拾われにくいという「形」 | 学術2本・複数世代で再現を確認（数字は世代ごとに使い分け） |
一次資料に見えるものでも、発信者が誰か・どの時点の状態か・自分がそれを一度読んだだけで済ませていないかを、都度確かめる必要がある。今回いちばん効いたのは、新しい資料を足すことではなく、既に読んだはずの公式資料を、疑いを変えて読み直したことだった。
Claude Code のオーケストレーター用サブエージェントを廃止した理由——公式harness仕様に基づく構造的な3つの制約
調査の終わりに、疑いの出発点そのものが消えた。「調べたのに何も出なかった」ではなく、「調べる理由が無くなった」という形で片が付く——これは負けではなく、格付けを最後まで手放さなかったことの結果だった。