【Windows】Cドライブの空き容量を増やす方法｜見えない75GBの正体を管理者権限で調べてWinSxS・配信の最適化キャッシュを掃除した実測

うちのPCのCドライブ(NVMe SSD 512GB)の空きが、いつの間にか96GBまで減っていた。原因を調べようと、エクスプローラーやPowerShellでフォルダごとのサイズを足してみたところ、合計が実際の使用量より約75GBも少ない。どこにも見当たらない容量が75GBあることになる。

結論から書くと、見えない容量の正体は、普段の権限では中身を数えられない場所(別ユーザーのフォルダ、ストアアプリ、WinSxS、復元ポイントなど)だった。管理者権限で中身を調べてから、Windowsの不要ファイル(クラッシュダンプ・配信の最適化キャッシュ・WinSxSの古い更新)を掃除して、Cの空きは170.2GBから184.2GBになった(約14GB増)。この記事では、調べ方と、実際に消したもの・消さなかったものを実測の数字つきでまとめる。

なお、このときの作業はClaude Code(AIのコーディングツール)に調べてもらい、削除するものは私が1つずつ決めて実行した。

まず結果:何をして何GB空いたか

一番効いたのは使っていないゲームだったが、これは人によって違う。Windowsの掃除だけで約14GB空いたことになる。WinSxSのクリーンアップの実行中にストアアプリ2つをアンインストールしたので、最後の行の約10GBには両方の分が混ざっている。

手順①:管理者権限でフォルダごとのサイズを調べる

普段の権限(管理者として実行していないPowerShellやエクスプローラー)では、アクセス権のないフォルダの中身は数えられない。そのため、フォルダのサイズを足しても使用量に届かず、「どこにも見当たらない容量」が出てくる。中身をきちんと数えるには、管理者権限で調べる必要がある。

フォルダ直下のサブフォルダごとの合計サイズは、次のスクリプトで出した。読み取るだけで、何も変更しない。dirsize.ps1という名前で保存する。

param([string[]]$Roots)
# 指定フォルダ直下の各サブフォルダの合計サイズを集計する(読み取りのみ)
function Get-DirSize([string]$path) {
    $total = [long]0
    $stack = New-Object System.Collections.Generic.Stack[string]
    $stack.Push($path)
    while ($stack.Count -gt 0) {
        $d = $stack.Pop()
        try {
            $di = New-Object System.IO.DirectoryInfo $d
            foreach ($f in $di.EnumerateFiles()) { $total += $f.Length }
            foreach ($s in $di.EnumerateDirectories()) {
                if (-not ($s.Attributes -band [System.IO.FileAttributes]::ReparsePoint)) { $stack.Push($s.FullName) }
            }
        } catch {}
    }
    return $total
}
foreach ($root in $Roots) {
    "=== $root ==="
    $rows = @()
    try {
        $rdi = New-Object System.IO.DirectoryInfo $root
        $loose = [long]0
        foreach ($f in $rdi.EnumerateFiles()) { $loose += $f.Length }
        $rows += [pscustomobject]@{ Path = "(直下のファイル)"; GB = [math]::Round($loose/1GB,2) }
        foreach ($s in $rdi.EnumerateDirectories()) {
            if ($s.Attributes -band [System.IO.FileAttributes]::ReparsePoint) { continue }
            $rows += [pscustomobject]@{ Path = $s.Name; GB = [math]::Round((Get-DirSize $s.FullName)/1GB,2) }
        }
    } catch { "error: $_" }
    $rows | Sort-Object GB -Descending | Format-Table -AutoSize | Out-String -Width 200
}

スタートボタンを右クリックして「ターミナル(管理者)」を開き、保存したフォルダに移動してから次を実行する。ジャンクション(別の場所を指すフォルダ)は二重に数えないように飛ばしている。

powershell -NoProfile -ExecutionPolicy Bypass -File .\dirsize.ps1 -Roots 'C:\','C:\Windows','C:\Users','C:\Program Files','C:\Program Files\WindowsApps','C:\ProgramData'

うちのPCのC:\直下の結果はこうなった(使用量305.5GBの時点)。

「直下のファイル」の44.7GBは、仮想メモリのpagefile.sys(32GB)と休止状態のhiberfil.sys(13GB)だ。System Volume Informationだけは管理者でも「アクセスが拒否されました」になって数えられなかったが、ここには復元ポイントが入っているので、次の手順②で別に確かめる。

手順②:復元ポイントとWinSxSの実際のサイズを確かめる

復元ポイント(シャドウコピー)

復元ポイントが使っている容量は、管理者権限で次を実行すると分かる。

vssadmin list shadowstorage

うちのCドライブは「使用領域: 8.28 GB」「最大領域: 9.52 GB」だった。最大領域を超えると古いものから自動で消えるので、際限なく増えるものではない。

WinSxS(コンポーネントストア)

C:\Windows\WinSxSは、エクスプローラーで見るとかなり大きく見える。ただ、中のファイルの多くはWindowsの他の場所とハードリンクで共有されているので、見た目のサイズほど容量を使っているわけではない。実際の中身は、管理者権限で次を実行すると分かる。

Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

うちのPCの結果(英語表示にしたもの)はこうだった。

Windows Explorer Reported Size of Component Store : 21.20 GB
Actual Size of Component Store : 19.66 GB
    Shared with Windows : 8.89 GB
    Backups and Disabled Features : 10.76 GB
    Cache and Temporary Data :  0 bytes
Date of Last Cleanup : 2026-10-22 01:55:39
Number of Reclaimable Packages : 21
Component Store Cleanup Recommended : Yes

見るのは「Backups and Disabled Features」(古い更新のバックアップなど)と、最後の「Component Store Cleanup Recommended」だ。Yesなら、クリーンアップで減らせるものがあるとWindows自身が判定している。うちは10.76GBがバックアップで、クリーンアップ推奨になっていた。

見えていなかった容量の内訳

手順①・②の結果をまとめると、普段の権限では見えていなかった約75GBの中身は、ほぼ次のとおりだった。

家族などと共用のPCだと、別ユーザーのフォルダが思ったより大きいことがある。ここは自分では消さず、本人に整理してもらうのがよい。

手順③:クラッシュダンプを消す

C:\Windows\LiveKernelReportsには、Windowsがハングしたときなどに書き出したダンプファイルが残る。うちには2025年6月のResourceTimeout-20250601-0003.dmp(1752.6MB)が1つだけあった。1年以上前の、もう調べる予定のない記録なので消した。中身を確認してから、管理者権限のPowerShellで次を実行する。

Get-ChildItem C:\Windows\LiveKernelReports -Recurse -File -Force | Select-Object FullName, Length, LastWriteTime
Get-ChildItem C:\Windows\LiveKernelReports -Force | Remove-Item -Recurse -Force

Cの空きは170.18GBから171.89GBになった。最近のブルースクリーンやフリーズの原因をまだ調べている途中なら、ダンプは原因調査の材料になるので、消さずに残しておく。

手順④:配信の最適化キャッシュを消す

「配信の最適化」は、Windows UpdateやMicrosoft Storeのダウンロードに使われる仕組みで、ダウンロードしたファイルをキャッシュとして持っている。Microsoftのドキュメントでは、キャッシュは自動で消えるが、ディスクの空きが必要なら手動で消してよいとされている。今のキャッシュの量は次で分かる。

Get-DeliveryOptimizationStatus | Measure-Object FileSizeInCache -Sum

うちは2.30GBだった。消すのは管理者権限のPowerShellで次の1行。

Delete-DeliveryOptimizationCache -Force

「Successfully deleted Delivery Optimization cache」と出て、Cの空きは171.89GBから174.24GBになった。コマンドを使わない場合は、Microsoftのドキュメントにあるとおり「ディスク クリーンアップ」で「配信の最適化ファイル」にチェックを入れて削除しても同じことができる。

手順⑤:WinSxSをクリーンアップする

WinSxSフォルダの中のファイルを手で消すのは絶対にやめる。Microsoftのドキュメントにも、WinSxSからファイルを削除するとPCが起動しなくなったり更新できなくなったりすると書かれている。減らすときは、Windowsに用意されているDISMのコマンドを使う。管理者権限のコマンドプロンプトかPowerShellで次を実行する。

Dism.exe /Online /Cleanup-Image /StartComponentCleanup

うちのPCでは6分ほどで終わり、「The operation completed successfully.」と出た。Windowsは同じ処理を、タスクスケジューラのStartComponentCleanupタスクで普段から自動で行っている。ただし自動のほうは、更新から30日たつまで古いバージョンを消さず、1時間で打ち切られる。DISMで手動実行すると、30日を待たずにすぐ消え、時間の制限もない。

/ResetBaseは付けなかった

ネットでは/ResetBaseを付ける方法もよく紹介されている。付けるとさらに減るが、Microsoftのドキュメントによると、実行後は今入っている更新プログラムをアンインストールできなくなる。更新プログラムで不具合が出たときに戻せなくなるので、私は付けなかった。

手順⑥:使っていないストアアプリを消す

C:\Program Files\WindowsAppsのサイズ上位を見ると、Power BI Desktop(2.7GB)とPower Automate(1.17GB)が入っていた。どちらも使っていなかったので消した。普通は「設定」→「アプリ」→「インストールされているアプリ」から、アプリ名の右の「…」→「アンインストール」で消せる。

私はPowerShellで消した。Power Automateは常駐していたので、先にプロセスを止めている(普段の権限のPowerShellで実行した)。

Get-AppxPackage | Where-Object Name -match 'PowerBI|PowerAutomate' | Format-List Name, Version, PackageFullName
Get-Process | Where-Object { $_.Path -match 'PowerAutomate|PowerBI' } | Stop-Process -Force
Get-AppxPackage -Name Microsoft.MicrosoftPowerBIDesktop | Remove-AppxPackage
Get-AppxPackage -Name Microsoft.PowerAutomateDesktop | Remove-AppxPackage

どちらもアプリの一覧からは消えた。Power BIはフォルダも消えたが、Power Automateのフォルダ(約1.2GB)はその時点ではWindowsAppsに残っていた。PCに別のユーザーがいて、そのユーザーにもインストールされていると、そちらでもアンインストールしないとフォルダは消えない。うちの場合どちらが理由だったかは確認していない。

消さなかったもの・試していないこと

• 復元ポイント(8.3GB): 何かあったときの保険になり、上限(うちは9.52GB)を超えると古いものから消えるので残した
• 仮想メモリのpagefile.sys(32GB): 小さくすると、画像生成AIなどメモリを大量に使う処理が落ちるおそれがあるので触っていない
• 休止状態のhiberfil.sys(13GB): 休止状態を使っていなければ管理者権限でpowercfg /h offを実行すると消えるが、私はまだ試していない
• 別ユーザーのフォルダ(21.5GB): 本人のデータなので中身も見ていない
• WinSxSの/ResetBase: 更新プログラムをアンインストールできなくなるので使っていない

ほかに、自分のユーザーフォルダの中で大きかったのは、Chromeのキャッシュ(12.6GB)と、AIのコーディングツールCodexの作業フォルダ.codex(29GB)だった。Claude CodeやCodexを使っていると、会話ログがユーザーフォルダにどんどん溜まっていく(ファイル履歴のバックアップ先がいっぱいになった話はファイル履歴がClaude Code・Codexの会話ログで満杯になった原因と対策に書いた)。

まとめ

• フォルダのサイズを足しても使用量に届かないときは、管理者権限で調べる。別ユーザーのフォルダ、WindowsApps、WinSxS、復元ポイントなどは、普段の権限では数えられない
• 復元ポイントはvssadmin list shadowstorage、WinSxSの実際の中身はDism.exe /Online /Cleanup-Image /AnalyzeComponentStoreで確認できる
• 安全に消せたのは、古いクラッシュダンプ(1.7GB)、配信の最適化キャッシュ(2.3GB)、WinSxSのクリーンアップと使っていないストアアプリ(合わせて約10GB)
• WinSxSは手で消さずに/StartComponentCleanupを使う。/ResetBaseは更新プログラムを戻せなくなるので、私は使っていない

参考

• Windows でドライブの空き領域を増やす - Microsoft サポート
• WinSxS フォルダーの実際のサイズの特定 - Microsoft Learn
• WinSxS フォルダーのクリーンアップ - Microsoft Learn
• 配信の最適化に関してよく寄せられる質問 - Microsoft Learn
• Delete-DeliveryOptimizationCache - Microsoft Learn
• vssadmin list shadowstorage - Microsoft Learn
• Remove-AppxPackage - Microsoft Learn
• ファイル履歴がClaude Code・Codexの会話ログで満杯になった原因と対策(当ブログ)