Cドライブを圧迫していたのはソースコードじゃなかった。AI・開発ツールの“副産物”を大掃除した話

Web制作や開発まわりの仕事をしていると、気づけばローカル環境にいろいろなものが増えていきます。

案件ごとのソースコード、画像、デザインデータ、検証用環境、Docker、Node.js、ブラウザ、AIツール……etc
なので、Cドライブの空き容量が少なくなってきたとき、最初に疑ったのは当然、普段保存している制作データでした。

ところが、実際に調べてみると違ったのです。
今回ほとんど駆除対象にならなかったのが、まさかのソースコードを保存しているディレクトリ。

容量を食っていたのは、制作物そのものではなく、制作を支えているツールたちがローカルに残していた“副産物”でした。

前日譚：Adobe Acrobat、お前25GBも使ってたの？

そもそもの発端は、Adobe Acrobatでした。

ストレージを確認していたところ、Acrobat関連で25GB近く使用していることが判明。PDF閲覧・編集ツールに25GB……？？？

さすがに「何をそんなに持っているんだ」となりました。
現在の利用頻度も低かったため、まずはAdobe Acrobat自体をアンインストール。

これでかなり空くはず、と思っていたのですが、Cドライブ全体を見ると、まだまだ巨大なデータが残っている……。

そこで、WizTreeを使ってディスク全体を可視化することにしました。ここから本当の大掃除が始まります。

Dockerは「消したつもり」でも残る

まず目立ったのがDockerです。

Docker Desktop配下だけでかなりの容量を使っており、確認してみると、使っていないImageやVolume、Build Cacheが大量に残っていました。

特にVolumeは、docker compose downを実行しても、明示的に削除しない限り残るものがあります。
開発案件ごとにDocker環境を作っていると、

• もう触っていない案件のDB
• 検証時に作った匿名Volume
• 過去のImage

が少しずつ積み上がっていきます。

不要なImageやBuild Cacheを整理しただけで、数GB単位で容量を回収できました。
さらに厄介だったのが、Docker DesktopがWSL上で使用しているVHDXです。中身を削除しても、仮想ディスクファイル自体のサイズが自動的に縮むとは限りません。

今回、Dockerのデータ用VHDXは約27.5GBまで膨らんでいましたが、不要データを削除したあとに圧縮することで、約18.1GBまで縮小……！

これだけで約9GB（！）回収できました。

npmもちゃんと貯め込んでいた

次に見つかったのがnpm cache。

普段は完全に意識していませんでしたが、npmもパッケージ取得時のキャッシュをローカルに保持しています。長期間使っている環境では、当然これも積み上がります。

今回あらためて確認して、「npm、お前もか……！」という気持ちになりました。

Dockerほど巨大ではありませんでしたが、こういう“1つ1つは大したことなさそうなキャッシュ”が複数ツールに存在すると、合計では馬鹿になりません。

ChromeとWaveboxは、ブラウザというより小さなOSだった

さらに調べていくと、ChromeとWaveboxもかなりの容量を使っていました。

Chromeには複数のProfileが残っており、過去に使っていたProfileを削除。加えて、Code Cache や通常の Cache、GPU関連キャッシュなども蓄積していました。さらにChrome配下には、オンデバイス処理用と思われるモデルデータが約4GB。

もはやブラウザというより、いろいろな実行環境を抱えた小さなOSのようです。

Waveboxも同様でした。
Chromiumベースのアプリなので、内部にはService Worker、Code Cache、Cache、Storage、IndexedDBなどが存在します。一部の拡張機能用Storageだけで1GBを超えているものもありました……。

ただし、このあたりは雑に削除するとログイン状態やアプリ内部データまで消える可能性があります。

そのため、今回は「名前にCacheが含まれる領域を確認する」「Storage全体は削除しない」という方針で慎重に整理しました。

ClaudeはVMを9GB以上抱えていた

次の大物はClaudeでした。

すでに普段使っていない状態だったので調べてみると、Roaming配下のClaudeディレクトリが約10GB。そのうち大半を占めていたのが vm_bundlesで、約9.6GB（！）ありました。
単なるログではなく、実行環境やVM関連のデータです。

現在使っていないツールだったため、通常のアンインストール後に残存ディレクトリを削除し、ここでも約10GB回収。

AIツールはクラウド上で動いている印象が強いですが、実際にはローカル側にもかなりの実行環境やキャッシュを持つケースがあるということですね……。

最後の巨大生物、Cursor

そして一番面白かったのがCursorでした。

Roaming配下のCursorは約16GB。
そのうち大半を占めていたのがUserディレクトリで、さらにその中のglobalStorageが巨大化していました。

調べてみると、state.vscdbというSQLite DBが約4.5GB。
最初は、「MCP設定とか拡張機能情報がそんなに大きいのか？」と思いましたが、読み取り専用で中身を調査すると、実態はかなり違いました。

容量の大半を占めていたのは、

• agentKv
• bubbleId
• checkpointId
• composerData
• messageRequestContext
• codeBlockDiff

など。

つまり、主にAgentやComposerの会話、チェックポイント、差分、内部状態です。
CursorでAgentスレッドを大量に開き、長期間使っていると、その履歴がローカルDBに積み上がっていく。これは今回初めて明確に意識しました。

「スレッドを消す」ではなく「統合してから消す」

ここで問題になるのが、ストレージのために過去スレッドを全部消してしまっていいのか、という点です。

なにせ過去のAgent会話には、

• 「なぜこの設計にしたのか」
• 「途中で何を試したのか」
• 「どの方針を採用したのか」

といった、後から参照したい情報が残っています。

そこで、単純にスレッドを削除するのではなく、必要な情報だけを要約・統合してから整理する仕組みをSkillとして作ることにしました。

Agentの会話履歴をJSONLから読み取り、複数スレッドの決定事項や試行錯誤を1つのMarkdownにまとめ、そのうえで元スレッドを削除候補として一覧化する形です。

削除自体は自動化せず、統合後の内容を人間が確認してから実行するようにしました。これなら、過去の会話を丸ごと抱え続けなくても、必要な知識だけを圧縮して残せます……！

効率化ツールにも「運用コスト」はある

今回一番意外だったのは、ソースコード保存ディレクトリが主犯ではなかったことです。

容量を使っていたのは、制作物そのものではなく、制作・開発・AI活用を効率化するためのツールが残していたデータでした。

AIや開発効率化の記事では、

• 「何時間短縮できた」
• 「このツールを使えば自動化できる」

という表側のメリットに注目しがちです。

もちろん、それも重要ですが、日常的に使い続けるなら、

• 「ローカルに何を保存するのか」
• 「キャッシュはどのくらい増えるのか」
• 「履歴はどこに残るのか」
• 「不要になったときにどう掃除するのか」

まで含めて、運用として考えた方がいい。今回のCドライブ大掃除で、そこをかなり実感しました……！

導入時には見えないコストは、時間だけではありません。ストレージもまた、AI・開発環境の運用コストのひとつです。あなたのPCにも、思いもよらない巨大生物が住み着いているかもしれません……。