Claude Code 2.1.14 で修正された問題が 2.1.133 で 29 倍に膨れて使えなくなった話

Posted at 2026-05-10

起きたこと

2026 年 5 月 8 日の朝、Claude Pro の利用者が GitHub で起票した。Pro の認可の入口で /login を実行して、Claude.ai の購読の認証を通した。その直後に /context を確認すると、「System tools」の項目に約 2,900,000 トークンが読み込まれていた。文脈の窓の使用率は 1,460 パーセント。利用者の入力の前に、すでに窓は破裂している状態。

利用者が見たのは、自動の作業者が完全に使えない状態だった。何かを聞こうとしても、文脈はもう全部埋まっている。再起動しても同じ。プロジェクトのフォルダを変えても同じ。

~/.claude/.credentials.json を消して、API キーで login し直すと、/context は約 700 トークンに戻った。普通の状態。

つまり、Pro の購読の認証が、何かを大量に読み込んでいる。それが何かは、利用者の側からは見えない。

なぜ衝撃か

実は、これと似た問題は過去にも報告されていた。

2026 年 4 月 19 日に閉じられた起票 50062 では、Claude.ai の購読の認証で「System tools」に約 100,000 トークンが読み込まれる現象が報告されていた。原因は、Claude.ai のアカウントに登録された連結の道具 (Canva、Figma、Linear、Notion 等) が、自動で全部 CLI に流し込まれる仕組み。利用者は、CLI でそれらを使う意図がなくても、毎回の起動で 100,000 トークンの文脈の重さを払う。

公式の担当者の応答は、4 月の段で次のように整理されていた。2.1.14 で ENABLE_CLAUDEAI_MCP_SERVERS=false の環境の値が追加された。これを設定すれば、Claude.ai の購読の認証は維持したまま、連結の道具の自動の取り込みは無効化される。

そして、起票 50062 は閉じられた。

しかし、5 月 8 日の起票で報告された 2.9M トークンは、過去の 100K の 29 倍である。同じ仕組みで、規模が 29 倍に膨れている。2.1.14 の修正のあとに、何かが起きている。

数字を並べてみる

過去の事例の文脈の重さは 100,000 トークン。5 月 8 日の事例の文脈の重さは 2,900,000 トークン。差は 2,800,000 トークン。倍率は 29 倍。

100,000 トークンの段階で、利用者は「これは多すぎる、無効化したい」と訴えていた。29 倍の規模なら、もはや「使えない」が正しい表現になる。

利用者の側の対処は、回避策の試行と起票の継続のみ。問題の根本を直すのは、本家の担当の領域。

どうすれば回避できるか

ENABLE_CLAUDEAI_MCP_SERVERS=false を環境の値に設定して、 ~/.claude/.credentials.json を削除して、 /login で再認証する。これで Claude.ai の連結の道具の自動の取り込みが無効化されるはず、という回避の素案を 5 月 8 日の段で起票者の didiator に共有した。

返ってきた確認は次の内容だった。環境の値を ~/.claude/settings.json の env に設定すると、認証していない状態では文脈が 721 トークンまで下がる。しかし、 Claude.ai Pro で /login した直後の状態では、文脈の窓に 2.9M トークンの「System tools」が依然として表示される。つまり、 v2.1.14 の修正は OAuth で認証した時の経路には届いていない。

利用者の側の判断としては、環境の値の設定は試す価値があるが、 Pro の購読での認証を維持したまま使う場合は、 2.9M の状態が変わらない可能性が高い。認証していない状態で 721 トークンに戻る事は確認できているので、文脈の窓の枠を空けたい時の暫定の手段にはなる。ただし、連結の道具を起動するためには Claude.ai の認証が必要なので、「認証しない状態で 721 トークン」では本来の運用には戻れない。

修正のあとの再退行の意味

2.1.14 の修正は 4 月 19 日の段で配布された。約 3 週間後の 2.1.133 で、同じ仕組みの問題が 29 倍の規模で再発している。

これは、修正のあとの再退行と呼べる現象。2.1.14 で塞いだ経路は塞がっているかもしれないが、別の経路で同じ問題が拡大している可能性。連結の道具の登録の数の自然な増加 (4 月から 5 月までの 3 週間で、Claude.ai の連結の道具の選択肢は増え続けている) と、自動の取り込みの仕組みの未修正の経路が組み合わさって、29 倍の規模を生んだのかもしれない。

利用者の文脈の窓は、文書の取り込み、会話の履歴、自動の作業者の道具の説明、と複数の用途で使われる共通の資源。その共通の資源を、登録した覚えのない連結の道具の説明が大量に占有する状態は、利用者の側から見れば、本家が文脈の窓の管理の責任を放棄しているように見える。

起票の閉鎖の経過

5 月 8 日の起票 57235 は、自動の道具の判定で「重複の候補」として 3 件 (50062 / 20412 / 56773) が示された。起票者の didiator は最終的に「20412 の重複として閉じる」と書いて、自分で閉鎖した。

ここで観察できる構造の問題が 2 件ある。

ひとつ目、 v2.1.14 の修正のあとの 2.1.133 の再退行という、規模 29 倍の事実の証拠が、「重複」の判定で起票の場から消えた。検索で 50062 にたどり着いた利用者は、「修正済」のラベルを見るが、 5 月の v2.1.133 での再退行は知らされない。修正の状態の表示と実態の段の段の隔たりが、利用者の側の判断の入力を狭めている。

ふたつ目、起票 50062 は閉じられた状態で編集ができない。利用者が「あの修正は v2.1.133 では効いていない」と書こうとしても、公式の起票の場では書けない。結果として、同じ問題の別の起票が立ち上がり、「重複」として閉じられ、という循環が続く。

まとめ

5 月 8 日の起票は、 v2.1.133 を使う Pro の購読者で、 Claude.ai の連結の道具が 1 つ以上登録されている場合に、再現する可能性が高い。環境の値 ENABLE_CLAUDEAI_MCP_SERVERS=false は OAuth で認証した経路では機能しない事が、起票者の確認で分かっている。 5 月 11 日の段では、本家の修正の通知は無く、利用者の側の取れる手順は、認証しない状態での 721 トークンへの戻りの確認のみ。

修正の歴史は、 4 月 19 日の起票 50062 の close から 5 月 8 日の起票 57235 までの 19 日間で、文脈の窓の重さが 29 倍に膨れた。同じ仕組みの修正の効果が、別の経路で打ち消される構造の問題。修正の経過の透明性が、利用者の側の判断の入力として、もっと欲しい場面である。