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)の並行運用・事故の検知と復旧・サブエージェントの沈黙の失敗対策など、主題別の手引きを公開しています。気になる人は著者の本の一覧から、価格と評価を見て選べます。