Claude Code 肥大化の原因を実測で切り分ける

Claude Code 肥大化の原因は一つではない。~/.claudeが重いと感じたら、掃除の前に何が太っているかを実測するとよい。この記事は、ディスク上の会話記録とコンテキストのトークンという、原因の異なる二つの肥大を分けて測る手順を、自分の環境で実際に測った数値とともに書く。フックの出力が犯人だった話、junctionを消しても容量が減らなかった話、削れるのに削らないと判断した理由まで、実測の過程をそのまま渡す。

1. 会話記録とトークンは別問題

Claude Codeの~/.claudeが重い、という相談は一つの症状に見えて、実は原因の異なる二つの問題を指していることが多い。一つは、ディスク上に溜まる会話記録（セッションごとの.jsonlファイル）そのものの容量である。もう一つは、毎回のやり取りで送信されるコンテキスト窓に、CLAUDE.mdや規則ファイルが常駐して払い続けるトークンの量である。

自環境の実測では、最大の会話記録ファイル（1.86GB）のうち66%はファイル読み込みフックの出力で、実際の作業結果は7.4%しか占めていなかった。

一方でコンテキスト窓の側には、システムプロンプトや環境情報のように、Claude Codeが毎セッション自動で読み込む要素がもとから存在する。

出典：Explore the context window - Claude Code Docs

出典：Explore the .claude directory - Claude Code Docs

この二つを分けずに「肥大化を直す」と検索すると、ディスクの掃除だけをして、コンテキストの浪費に気づかないまま終わることになる。ここから先は、両方をそれぞれの実測手順で扱う。

2. 実測に要る準備

実測に使うのは、次の3つの公式な手段である。サードパーティのツールは使わない。

出典：File system | Node.js Documentation

出典：Token counting - Claude Platform Docs

日本語の文章を対象にするときは、文字数を4で割る概算をそのまま使ってはいけない。自環境の実測では、日本語は1文字がほぼ1トークンに対応し、文字数÷4の見積りは実際の4倍過小になっていた。

正確な値が要る場面では、count_tokens APIで実際に数える。文字数からの概算はAnthropicの公式ドキュメントでも案内されておらず、正確な計測にはAPIの利用が案内されている。

3. 実測で肥大を突き止める手順

Step 1　会話記録の内訳を集計する

**セッションのトランスクリプトはprojectsディレクトリ配下のセッションファイルに保存される。**次の手順で内訳を集計する。

1. 容量が大きいトランスクリプトファイルを探す
2. ファイル内の記録を、出所（フックの出力／会話本文とツールの実行結果）ごとに分類する
3. 出所ごとの合計容量を、ファイル全体の容量に対する割合として出す

Step 2　犯人のフックを特定する

内訳で最大の割合を占めていたのは、プロジェクトのsettings.jsonのどこにも書かれていないフックだった。

1. /hooksメニューを開き、有効なフックの一覧を出所別に確認する
2. プロジェクトのsettings.jsonに書かれているフックと、一覧に表示されるフックを突き合わせる
3. 差分があれば、その分はプラグインが持ち込んだフックである

プラグインのフックはプラグイン自身のhooks/hooks.jsonに定義され、有効化されると実行時にユーザーとプロジェクトのフックへ統合される。/hooksメニューでは出所が「Plugin Hooks」と表示されて区別できるが、プロジェクトのsettings.jsonには現れない。

出典：Hooks reference - Claude Code Docs

自環境でも、肥大の犯人はプラグイン側のフックで、設定ファイルだけをいくら見ても見つからなかった。

Step 3　未回収の一時領域を洗い出す

セッションのトランスクリプトには自動削除の仕組みがあり、既定値は30日である。

しかし、この自動掃除の対象表に載っていない領域も存在する。

1. ジョブ単位の一時領域を直接列挙する
2. ファイル数と合計容量を集計する
3. 自動クリーンアップの対象表と照らし、含まれているかどうかを確認する

自環境では、この一時領域は誰にも回収されないまま8.3GB・236,608ファイルまで溜まっていた。

Step 4　常駐トークンを数える

最後に、コンテキスト側を数える。

1. 毎セッション読み込まれるファイル（CLAUDE.md・rules・MEMORY.md）を洗い出す
2. それぞれをcount_tokens APIに渡し、実トークン数を得る
3. 文字数÷4の概算と比べる

自環境の実測では、毎セッション常駐する規則ファイルの実トークンは約17,500だった。

4. つまずきやすい3つの罠

実測の途中で自分自身が引っかかった罠を、回避策とセットで書く。

プラグインのフックは、プロジェクトのsettings.jsonだけをいくら見ても見つからない。/hooksメニューで出所を確認する必要がある。

Windowsのjunction（mklink /Jで作るNTFSのreparse point）は、対象ディレクトリへの透過的な別名として働く。

出典：mklink | Microsoft Learn

ディレクトリを再帰的に集計するとき、fs.statSyncはこのリンクを辿ってしまう。判定にはfs.lstatSyncを使う必要がある。

**自環境でも、プラグインcacheの旧バージョンがjunctionだったため、素朴に容量を数えると923MBの幻の削減見込みが出た。**実際の削減は0だった。

セッション開始時に出る「skill descriptions dropped」という警告は、無視してよいものではない。一覧には全skillの名前が必ず載るため、名前を指定して呼ぶ経路は影響を受けない。落ちるのは説明文のほうで、公式文書はその短縮が「Claudeが依頼と照合するために必要なキーワードを削り落としうる」と書く。

削る順は呼ぶ回数が少ないものからである。つまり、めったに呼ばないものほど、Claudeが自分で選ぶ精度が先に落ちる。この一覧に割く予算は、既定でコンテキスト窓の1%と決まっている。

出典：Extend Claude with skills - Claude Code Docs

自環境の実測では、この予算を上げると毎セッション28,000トークンの恒久的な支払いが発生する。

5. 実測して分かったこと

ここまでの手順を実際の環境に適用した結果をまとめる。

設定ディレクトリ全体では、25.9GBから16.7GBへ、9.0GBを回収できた。

一方で、Step3で見つけた一時領域のように、8.3GB・236,608ファイルが未回収のまま残っていた領域もある。

すべてを削ればよいわけではない。**毎セッション常駐する規則ファイルを統合すれば節約できるトークンは、実測すると0.15%にとどまった。**この記事の環境では、規律の実効性を優先して統合しない判断をした。

規則の分量そのものを見直す目安として、別のプロジェクトで実測した数値も参考になる。起動時に読ませる規則が合計1229行あり、典型例とされる100行以下を10倍超えていた。

Claude Code公式ドキュメントも、CLAUDE.mdは200行を目安にするよう案内している。

出典：How Claude remembers your project - Claude Code Docs

6. Claude Code 公式の実測ツール

この記事で使った手段は、すべてClaude CodeとAnthropicが公式に提供する機能である。サードパーティのツールは使っていない。

/doctorを実行すると、skill一覧がコンテキストにどれだけのコストをかけているか、内訳の上位とともに見積もりが出る。

count_tokens APIは、稼働中の全モデルに対応しており、トークン数を実際に数えられる。

/contextは、セッション中に何がコンテキスト窓を占めているかを一覧で示す。

7.【まとめ】会話記録とトークンをそれぞれ実測してから削る

「肥大化した」という一つの症状の裏には、ディスク上の会話記録と、毎ターン払うコンテキストのトークンという、原因の異なる二つの問題が隠れている。

どちらも、症状から直接「消す」に飛ぶ前に、まず内訳を実測すると迷わない。実測すれば、削ってよい場所と、削らなくてよい場所の両方が判断できる。

次にやることは一つである。自分の環境の~/.claudeで、Step1から順に実測してみてほしい。