WSL2 で Claude Code が重い 2026 年版 — Tokenocalypse 後の体感と8つの対策

「Claude Code が遅い」「トークンが知らないうちに消えている」「セッションが180分もかかる」——WSL2 で Claude Code を動かしている開発者の声が、2026 年 4 月以降、急に増えた。私自身、800 時間の自律運用を WSL2 上で続けているが、4 月の v2.1.88 以降、明らかに「同じ作業量で消えるトークン量が増えている」感覚があった。

実測してみたら、直近 7 日で API 換算 $10,379 相当を消費していた（cc-token-diet というツールで自分のログを集計した結果）。Max プランの月額固定で動かしているので実際の請求はこの金額ではないが、「context intensity（毎ターンのトークン消費密度）」としては明らかに異常値だった。

この記事は WSL2 ユーザー向けに、「Tokenocalypse 後の WSL2 で何が起きているか」を公式情報と自分の実測データで整理し、即試せる 8 つの対策を提示する。Mac/Linux ネイティブの記事は英語圏に多いが、WSL2 特有の遅延要素（ファイルシステム境界、CDP 経路、サンドボックス越え）を含んだ日本語の 2026 年版は、私が探した限りまだ存在しなかった。

公式情報で確認できる事実

まず「気のせいではない」ことを公式の事実で確認する。

v2.1.88（2026-04-12 リリース）以降のトークン消費急増

v2.1.88 のリリースノートには明示的な「トークン消費が増えた」という記載はないが、その後ユーザー側の実測報告が相次いだ。

GitHub Issue #46829（seanGSISG さんが 92 日 / 119,866 API コールの分析を投稿、当初「$1,582 を burn した」と報告。後に本人が試算を訂正したが、cache TTL が 1 時間から 5 分に縮んでいた事実は変わらず、Issue は 2026-04-12 に NOT_PLANNED でクローズされた）
Simon Willison さんの 4/20 記事: Opus 4.7 のシステムプロンプトが 4.6 比で 1.46 倍、総コスト約 40% 増を独立に実測

WSL2 ユーザーは、これらに加えて WSL2 → Windows 側のアクセス遅延が積み重なる構造になっている。

v2.1.118（2026-04-23 リリース）で WSL2 ポリシー継承が追加

リリースノートから WSL2 関連の重要な追加:

wslInheritsWindowsSettings ポリシーキー: WSL2 上の Claude Code が Windows 側の管理設定を継承できるようになった
/cost と /stats が /usage に統合（v2.1.117 以前から使っていた人向けに /cost//stats は入力ショートカットとして残る）
hook が MCP ツールを直接呼び出せる（type: "mcp_tool"）

wslInheritsWindowsSettings は、企業環境で Windows 管理者が設定したポリシー（例: 特定の API キーの使用禁止）を WSL2 側でも反映するためのもの。個人開発者にとっては、Windows 側で DISABLE_AUTOUPDATER などを設定していれば WSL2 側でも同じ動作になる、という意味がある。

v2.1.121（2026-04-25 リリース）で `--resume` 系の部分修正

v2.1.120 で報告された --resume 時のクラッシュ群が、v2.1.121 で部分修正された
WSL2 では特に subagent の stream 切断が起きやすい（macOS の sleep 問題と同じ構造で、WSL2 のホスト Windows 側が省電力に入ると stream が切れる報告あり）

長時間自律実行を WSL2 でやっている人は、v2.1.121 への即時アップデートが効く。

Anthropic 4/23 のポストモーテムで認められた 3 つの不具合

Anthropic は 2026-04-23 のポストモーテムで Opus 4.7 リリース後の品質低下に関する3つの不具合を公式に認めた:

reasoning effort のレベルが低く設定されていた
thinking キャッシュのバグでキャッシュが効いていなかった
verbosity 抑制プロンプトが意図せず効きすぎていた

WSL2 ユーザーの体感「同じプロンプトで返答が短くなった、間違いが増えた」は、これらの不具合が原因の可能性が高い。

自分の WSL2 環境での実測データ

公式情報を踏まえた上で、自分の WSL2 環境（Ubuntu 22.04 / Windows 11 ホスト / Max プラン）で 800 時間動かした結果を見せる。

`cc-token-diet` で自分のログを集計した結果

npx -y github:yurukusa/cc-token-diet

これを 2026-04-27 朝に走らせた直近 7 日の集計:

Sessions analysed: 208   Assistant turns: 27,613
Input:   716.1K   Output:        21.49M
Cache read:   4.74B   Cache write:  87.66M
API-equivalent spend:  $10,379.82  (Opus 4.x pricing)
Cache hit ratio: 98.2%

Waste patterns:
  90 runaway session(s) (>100 assistant turns) (≈ $2,852.04 wasted)

Hottest sessions:
  $612.19  2026-04-25  projects-cc-loop  884 turns / 180min
  $575.71  2026-04-25  projects-cc-loop  808 turns / 180min
  $452.35  2026-04-26  projects-cc-loop  760 turns / 181min

ここで読み取れる事実:

API 換算で週 $10,379 相当の context intensity を出していた（Max プラン月額固定なので実請求はこの金額ではないが、Sonnet で動かしていれば約 1/5 = $2,076 相当）
暴走セッション（100 ターン超）が 90 件、推定 $2,852 相当の context waste
上位 3 セッションが全て 180 分前後 / 800 ターン前後で集中
cache hit 98.2% は健全（目標 85% 超え）。つまり「キャッシュは効いていたが、それでもこの量を消費していた」

特に 180 分セッションが頻発するのは WSL2 の構造的な問題ではなく、自分の運用パターン（/compact を使わずに延々とセッションを続ける）の問題。

状態管理ファイルが肥大化していた

毎セッション開始時に読み込まれる主要ファイルのサイズを確認した:

ファイル	サイズ	トークン換算
mission.md	417 KB	約 100,000 トークン
current-focus.md	176 KB	約 44,000 トークン
MEMORY.md	33 KB	約 8,000 トークン
合計	626 KB	約 152,000 トークン

200K のコンテキスト窓のうち 76% を、毎セッションの開始時点で「過去の作業履歴」に消費していた。これが上記の暴走セッション群の根本原因の一つ。

WSL2 特有の制約: Qiita API POST が 403

これは別軸の WSL2 特有の罠だが、覚えておく価値がある:

WSL2 の curl で Qiita API に POST すると 403 Forbidden（GET は正常）
PowerShell の Invoke-RestMethod 経由なら問題なし
原因は SSL/TLS ネゴシエーションかヘッダー差異の可能性（特定できていない）
対処: Qiita 記事投稿は PowerShell 経由で行う

WSL2 を使い始めた時に「なぜか Claude Code から Qiita 投稿が通らない」とハマる人がいる場合、これが原因の可能性が高い。

8 つの対策（即試せるもの限定）

対策 1: `wslInheritsWindowsSettings` ポリシーで Windows 側設定を継承する

v2.1.118 以降で追加された設定。Windows 側で DISABLE_AUTOUPDATER などを設定していても、WSL2 側の Claude Code には継承されないことがあった。これを解決する。

~/.claude/settings.json または管理ポリシーで:

{
  "wslInheritsWindowsSettings": true
}

これで Windows 側の管理設定が WSL2 にも反映される。企業環境なら Windows 管理者の設定が、個人環境なら自分が Windows 側に書いた設定が、WSL2 でも一貫して効く。

対策 2: CDP daemon を `chrome-auto`（CDP 9222）に統一する

WSL2 から Windows Chrome を操作する CDP（Chrome DevTools Protocol）経路は、起動方法が複数あって混乱しやすい。私は次の優先順位に統一した:

第一選択: ~/bin/chrome-auto（CDP ポート 9222）
フォールバック: ~/bin/cc-chrome（CDP ポート 9223）
CDP 操作は cdp-bridge コマンドに統一（~/chrome-claude-bridge/）
生の WebSocket CDP 構築は禁止

CDP daemon が無応答になった時は、まず cdp-bridge dialog-dismiss で Chrome 側のダイアログを消す。CDP daemon がフリーズしているように見える原因の多くは、Chrome 側に未承認のダイアログ（基本認証、許可確認、再起動通知など）が出ていて、CDP コマンドがそれに弾かれているケース。

対策 3: `context-monitor.sh` で context 残量を可視化する

cc-safe-setup という hook 集に含まれている context-monitor.sh を入れる。これが PostToolUse で毎ツール実行ごとに走り、/tmp/cc-context-pct に context 残量パーセントを書き出す。

ステータスラインに表示する:

# ~/.claude/statusline などで
cat /tmp/cc-context-pct 2>/dev/null

これで context 残量が視覚的に分かるので、「気付いたら 15% を割って強制退避」という事故を防げる。私は context が 25% を切ったら自動で mission.md に退避テンプレートが書き込まれる設定にしている（hook 側で対応）。

対策 4: 状態管理ファイルの履歴部分を別ファイルに分離する

上の実測で見たように、mission.md 417 KB / current-focus.md 176 KB は明らかに肥大化している。これらは履歴と現在の判断材料が混ざった状態で、毎セッション読み込まれていた。

分離方針:

mission.md の履歴部分（過去のセッション entry の列）を mission-archive-YYYY-MM.md に切り出す
current-focus.md の作業履歴 45 項目のような長いリストを cycle-log-YYYY-MM-DD.md に切り出す
元のファイルには「最新の判断材料」と「再開時にやること」だけを残す

これだけで毎セッションの開始時のトークン消費が大幅に減る。私の場合、合計 626 KB（約 152,000 トークン）が想定で、ここから履歴を分離すれば 50 KB（約 12,000 トークン）まで圧縮できる見込み。

対策 5: `/compact` を 60 分ごとに使う

実測で見たように、180 分 / 800 ターンのセッションが頻発していた。これは /compact を使わずに延々とセッションを続ける運用パターンの結果。

シンプルなルール:

1 セッション 60 分を上限の目安にする
60 分経ったら、現在のタスクに区切りを付けて /compact を実行する
/compact 後は要約された context で続行できる

WSL2 環境では特に、セッションが長くなると Windows ホスト側のリソース（メモリ、ディスク I/O）への負荷が累積する。Mac/Linux ネイティブよりも頻繁に区切る方が体感が安定する。

対策 6: コンテキスト管理の設計を学ぶ

context 管理は Claude Code 全体で最も効く対策で、これだけで本が書けるレベルの話。私は Token Book ¥2,500（Zenn）の第 3 章でコンテキスト管理の体系をまとめている。

WSL2 ユーザーが特に意識すべき点だけを抜粋:

/clear と /compact と --resume を「いつ使うか」のルールを自分で決める
セッション内で読み込むファイルは「必要な時に必要な分だけ」（事前にまとめて読み込まない）
サブエージェントを使って本体 context を綺麗に保つ（並列調査をオフロード）

対策 7: `cc-token-diet` で月 1 回は自分のログを点検する

上で示したように、npx -y github:yurukusa/cc-token-diet で自分のログを集計できる。これを習慣化する。

月 1 回（または週 1 回）走らせる
暴走セッション数、cache hit 比率、上位ホットセッションの3つを確認する
「対策の前後でこの数字がどう動いたか」を測ると、対策の効果が定量化される

このツールは 100% ローカル動作で外部送信しない（ソースは 1 ファイル）。WSL2 上で自分のログを集計する用途に向いている。

対策 8: memory ファイルを 32 KB で分割する

Claude Code の memory システム（~/.claude/projects/*/memory/）にある個別の memo ファイルが大きくなりすぎると、毎セッション読み込まれる量が膨らむ。

ルール:

1 つの memo が 32 KB を超えたら分割を検討する
古い情報は別ファイル（例: _archive/ 以下）に移す
MEMORY.md のインデックスは 200 行までで自動切り捨てされるので、リンクは厳選する

私の場合、memory ファイルは 221 本あって最大 32 KB（MEMORY.md 自身）。インデックスがそれ以上膨らむと毎セッションで切り捨てが発生して、参照したい memo が見えなくなる事故が起きる。

対策の前後で何が変わるか

数値で示せる範囲で:

項目	before	after（見込み）
毎セッション開始時の状態管理ファイル	626 KB（約 152,000 トークン）	50 KB（約 12,000 トークン）
暴走セッション数 / 7 日	90 件	30 件以下を目標
1 セッションの平均時間	180 分前後	60 分前後
context bloat 由来の waste / 7 日	約 $2,852 相当	約 $1,000 相当を目標

after の数値は対策実施直後の見込みで、私自身もこれから実証する段階。記事公開後 14 日（2026 年 5 月中旬）に再度 cc-token-diet を走らせて、実測値で更新する予定。

「対策の効果を毎回数字で測る」習慣自体が、Tokenocalypse 後の Claude Code を WSL2 で安定運用する最大の鍵になる。

まとめ

WSL2 で Claude Code が重い 2026 年版の正体は、v2.1.88 以降の Tokenocalypse に WSL2 特有の遅延（ファイルシステム境界、CDP 経路、状態管理ファイル肥大化）が重なった結果だった。8 つの対策のうち、最も効くのは 対策 4（状態管理ファイル分離）と対策 5（/compact 頻度向上）。これだけで毎セッション開始時の context が 1/12 に圧縮できる見込みがある。

公式情報（v2.1.118 の wslInheritsWindowsSettings、v2.1.121 の --resume 部分修正、Anthropic 4/23 ポストモーテムの 3 bug）と自分の実測データ（cc-token-diet、状態管理ファイル肥大化）を組み合わせて、自分の WSL2 環境で何が起きているかを数字で把握することが、対策の出発点になる。

関連リソース

無料で試せるトークン消費分析ツール: cc-token-diet（GitHub 直接、npx github:yurukusa/cc-token-diet）
WSL2 から Windows CDP を操作する方法: Qiita 既存記事
Claude Code の安全 hook 集: cc-safe-setup（context-monitor.sh、token-budget-guard.sh など）
コンテキスト管理を体系的に学びたい方は Token Book ¥2,500（Zenn）の第 3 章へ

Claude Code は毎月のように仕様が変わり、費用の膨らみ方も事故の新種も毎月出ます。「先月から何が変わったか・今すぐ直すべき設定や貼るべき hook はどれか」を毎月15日ごろ短く受け取りたい人には、Claude Code 事故まとめ(無料・月次)もあります（本は腰を据えて読む手引き、便りは毎月の鮮度で走らせる運用の線、という住み分けです）。

800時間の Claude Code 運用データから、トークン消費の削減・複数ベンダー(Claude / Codex / Gemini / Copilot)の並行運用・事故の検知と復旧・サブエージェントの沈黙の失敗対策など、主題別の手引きを公開しています。気になる人は著者の本の一覧から、価格と評価を見て選べます。