Cドライブの空きを7.9%から22.4%に戻した話 — 開発者のWindowsクリーンアップ手順

Cドライブの空き容量が**7.9%まで減って、Windowsから赤い警告が出る寸前だった。WinDirStatで全体を見渡しつつ、開発ツールのキャッシュ・システムの一時ファイル・クラウドストレージのローカルキャッシュを段階的に削った結果、約135GBを解放して22.4%**まで戻した。同じ作業を以前もやった記憶があるので、次回再発したときに参照できるように手順を残しておく。

ビフォー / アフター

容量930 GBのSSDで、14.5pt 改善。1割未満の空きから2割超まで戻った。

まずは可視化: WinDirStatで犯人探し

雑にあちこち消すと巻き戻しにくいので、最初に全体像を把握する。WinDirStat を起動してCドライブをスキャンすると、ツリーマップでどのディレクトリが太っているかが視覚的に見える。

ざっと見ると、こうだった:

そして Users の中をさらに掘ると、犯人の正体が見えてくる:

Users\<user>\AppData\Local  → 230 GB

AppData\Local だけで230GBある。ここに開発ツールのキャッシュが大量に積み上がっていた。

AppData\Local の内訳（230GB の正体）

WinDirStatでさらに掘って判明した上位:

太字が今回のターゲット。コマンド一発で消せて、消しても次回の install で必要分だけ自動再生成されるものが多い。

触ってはいけないもの

開発マシンだと「なんか分からないけど大きい」を消したくなるが、以下は絶対に手を出さない。

hiberfil.sys は休止状態用ファイルなので、休止状態を使ってないなら powercfg /h off で削除してOK（管理者権限）。

実行した削減手順（軽い順）

1. ディスククリーンアップ（cleanmgr）

最初に試したが、今回はあまり成果なし（1.74 GB増のみ）。普段からそこそこ動いていたのと、WSLや開発ツールのキャッシュは標準ツールでは触れない領域だから。

ただし「システム ファイルのクリーンアップ」ボタンを押さないと出てこない項目（Windows Update のクリーンアップ、配信の最適化、Windows.old等）があるので、これは押しておくべき。

2. Tempフォルダを空にする

Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Temp\*" -ErrorAction SilentlyContinue

使用中のファイルはスキップされるだけで害はない。エラーメッセージが出ても無視。

# 削除前後のサイズ確認
Get-ChildItem "$env:LOCALAPPDATA\Temp" -Recurse -Force -ErrorAction SilentlyContinue |
  Measure-Object -Property Length -Sum |
  ForEach-Object { "{0:N2} GB" -f ($_.Sum / 1GB) }

結果: 12.2 GB → 0.53 GB（約 11.7 GB 解放）

3. パッケージマネージャのキャッシュ群

npm cache clean --force
pnpm store prune
yarn cache clean

それぞれ:

• npm-cache: 7.8 GB
• pnpm store: 8.0 GB（66,697ファイル / 1,868パッケージを削除）
• yarn: 7.3 GB

合計約 23 GB 解放。次回 install 時に必要分だけ自動で再生成されるので無害。

4. Google Drive content_cache

ここが分かりにくかった。WinDirStatで「No Extension」のファイルが拡張子別集計で 85GB あって、最初は「これ全部キャッシュじゃない？」と勘違いした。実際にはGoogle Driveの content_cache は 約 10.6 GB で、85GBは別の場所も合算した値だった。

Google Driveを ストリーミングモードで使っていると、開いたファイルがハッシュ名（拡張子なし）でローカルキャッシュされる。これが溜まる。

手順:

1. タスクトレイのDriveアイコン → 設定（歯車）→ 「同期アクティビティ」を確認し、アップロード待ちが0であることを確認
2. 設定 → 「Google ドライブを終了」で完全終了
3. プロセスが残ってないか確認:

Get-Process | Where-Object { $_.Name -like "*GoogleDrive*" -or $_.Name -like "*DriveFS*" }

4. content_cache を削除:

Remove-Item -Path "C:\Users\<user>\AppData\Local\Google\DriveFS\<id>\content_cache\*" `
  -Recurse -Force -ErrorAction SilentlyContinue

5. スタートメニューからGoogle Driveを再起動

復元: 必要なファイルは次回開いたときに再キャッシュされる。最初のうちは初回アクセスが遅い。

5. 手動削除分（adobeTemp / ゴミ箱）

並行して手動でやったもの:

• adobeTempフォルダ（Cドライブ直下）: 24.6 GB
  • Adobe製品の作業中一時ファイル。アプリ全終了後にフォルダごと削除可能
• ゴミ箱を空に: 5 GB

6. uv キャッシュの剪定 — 最大のROI

このセッションで一番効いたコマンド:

uv cache clean

結果:

Clearing cache at: C:\Users\<user>\AppData\Local\uv\cache
Removed 891252 files (37.1GiB)

約 39.8 GB（37.1 GiB）/ 89万ファイルを削除。Pythonパッケージは1パッケージあたり数百〜数千ファイルになるので、ファイル数がここまで膨らむ。次回 uv sync 時に必要分だけ再生成されるので、運用への影響はゼロ。コマンド1発でこの規模が消える。

7. Google Drive ミラーリング時代の残骸

もうひとつの発見: 過去に Google Drive をミラーリングモード（ローカルにフルコピー）で使っていた残骸が C:\Users\<user>\Google ドライブ\ に残っていた。中身は約 19 GB の書籍 PDF・画像・コードファイル群。

確認:

• 設定の「マイ コンピュータ」タブ → バックアップ登録なし
• ブラウザ版Driveに同じフォルダが存在 → クラウド側にファイルが保全されていることを確認

→ ローカル側のフォルダは安全に削除できた（約 19 GB 解放）。ストリーミングに切り替えた後は、過去のミラーフォルダは不要になる。

検証は gws CLI で Drive 側のフォルダ内容を一覧化することで確認した。同名サブフォルダ・同名ファイルが揃っていることを目視で確認してから削除した。

8. OneDrive のファイルオンデマンド化

OneDrive で「all folder」配下に約 167 GB（論理サイズ）のデータがあり、まだローカルキャッシュされている分があった。

手順:

1. タスクトレイの OneDrive アイコン → ステータスが「ファイルが同期されています」になっているか確認（最重要: 同期未完了で実行すると未アップロードファイルを失うリスク）
2. エクスプローラーで C:\Users\<user>\OneDrive\ を開く
3. 「all folder」を右クリック → 「空き領域を増やす」
4. 配下のすべてが ☁️（オンラインのみ）状態に変換される

結果: 約 20 GB 解放

期待より少なかった理由は次セクションの「論理サイズと物理サイズ」を参照。

重要な発見: 論理サイズ vs 物理サイズの罠

PowerShell Get-ChildItem で OneDrive / Dropbox のフォルダサイズを測ると、論理サイズ（クラウド上の本来のサイズ）が出る。実際のローカルディスク使用量とは大きく異なる場合がある。

例: Dropbox の場合

「Dropbox が 211 GB 食ってる」と思って Smart Sync を急いだが、実際にはほとんどがすでにオンラインのみ状態で、ローカル使用は 22 GB 程度しかなかった。

なぜズレるのか

オンラインのみ（プレースホルダー）のファイルは:

• ファイル名・サイズ表示は本来のサイズで見える（例: 100 MBのPDF）
• 実体はディスクに無い（数KBのプレースホルダーだけ）
• ダブルクリックすると自動でダウンロードされる

PowerShell の Get-ChildItem -Recurse | Measure Length は、宣言されたサイズを素直に合計してしまうので、プレースホルダーも本来のサイズで計算する。

教訓

クラウドストレージの容量を測るときは:

• PowerShell で測る → 論理サイズが出る（実際の使用量とは乖離）
• WinDirStat で測る → 物理サイズが出る（信頼できる）
• クラウドアプリ自身の管理画面で見る → 一番正確

迷ったらWinDirStat の数字を信じるのが正解。

ストリーミングモードへの統一

OneDrive と Google Drive はどちらも、デフォルトでフルキャッシュ（ミラー）状態だと PC に大きな負担になる。両方とも「ファイルオンデマンド / ストリーミングモード」を使うのがベスト。

モード比較

開発マシンで容量が逼迫しているなら、ストリーミングモードが圧倒的に有利。

サービス別の設定場所

すでにストリーミングになっている場合でも、過去にダウンロードされたファイルが残っていることがあるので、「空き領域を増やす」/「ハードドライブの容量を管理」を1度実行するのがおすすめ。

まだ残っているターゲット

今回は手をつけなかったが、次回の候補:

特に Docker Desktop アンインストールで一気に約51GB が今後の最大候補。

学び: 開発マシンで溜まりやすい場所

今回明らかになった「太りやすい場所」を分類すると:

自動的に肥大化する場所

• パッケージマネージャのキャッシュ（uv / npm / pnpm / yarn）
• Docker のイメージ・ボリューム
• Google Drive のストリーミングキャッシュ
• Adobe のメディアキャッシュ
• WSL の vhdx（自動拡張するが自動縮小しない）
• OneDrive / Dropbox のオフラインキャッシュ（設定次第で巨大化）

一度きりの一時ファイルが残る場所

• %LOCALAPPDATA%\Temp
• adobeTemp（Cドライブ直下）
• 各種アプリのインストーラー残骸

過去の運用方針の変更で残骸になる場所

• Google Drive ミラーリング → ストリーミング切替後の旧フォルダ
• 旧バージョンアプリ（Cinema 4D 2025 と 2026 など）

開発マシンは4ヶ月くらいで再発する気がしている。次回はuvキャッシュから消せばいい、というメモを残しておく。

再発防止: ストレージセンサーの自動化

設定 → システム → ストレージ → ストレージセンサー → オン

• 一時ファイル自動削除
• ゴミ箱を30日で自動空に
• ダウンロード未使用60日で自動削除

これで Temp と ゴミ箱は放置でも勝手に整理される。パッケージマネージャのキャッシュは手動で定期的に prune が必要。

クラウドストレージは「ストリーミング/オンデマンド」モードを既定に。新規ファイルが自動でクラウドのみになる設定を入れておけば、ローカルキャッシュが肥大化しにくい。

まとめ

• WinDirStatで全体を見てから消す。雑に消さない
• コマンド一発で消せて、自動再生成されるものから優先的に
• 絶対に触ってはいけない場所を覚えておく（pagefile / Windows / Installer）
• 論理サイズと物理サイズを区別する。クラウドストレージの数字に騙されない
• ストリーミングモードに統一する。フルキャッシュはローカル容量の浪費
• 再発するので手順を残す。今回の記事がそれ

開発マシンはノードモジュールとPythonパッケージとDockerイメージ、それにクラウドストレージのフルキャッシュで太る。これを定期的に剪定するのが運用。