Windows Server 2019 の Server Core でディスク容量が逼迫し、「cleanmgr.exe（ディスク クリーンアップ）を起動して手早く整理したい」と思っても、コマンドが見つからず詰まることがあります。原因は構成上の仕様です。この記事では、機能追加で解決できるのか、非公式寄りの回避策、そして運用で使える代替手段をまとめます。
Windows Server 2019（Server Core）で cleanmgr.exe が使えない現象
Server Core にログインして cleanmgr を実行すると、次のようなメッセージで止まります。
'cleanmgr' is not recognized as an internal or external command,
operable program or batch file.
これは「パスが通っていない」のではなく、そもそも Server Core の標準構成に cleanmgr.exe が含まれていないことが主因です。
Server Core は“GUI を前提とするツール”が削られた最小構成
Server Core は、GUI シェルや一部の管理ツールを削減して、攻撃面・更新コスト・リソース消費を抑えるためのインストール オプションです。結果として、GUI ベースのユーティリティ（ディスク クリーンアップなど）が入っていないことがあります。
cleanmgr.exe はクラシックな GUI ツールであり、Server Core の思想（最小構成）と相性が良くありません。このため、Desktop Experience（GUI あり）環境では見かけるのに、Server Core では「存在しない」状態になります。
機能追加（Feature 追加）で cleanmgr.exe を入れられる？結論
結論から言うと、Server Core に「Feature を追加して cleanmgr.exe を入れる」ことは基本的にできません。
- Windows Server 2012/2012 R2 では「Desktop Experience」機能を追加して Disk Cleanup を使う、といった運用がありました。
- 一方、Windows Server 2016/2019 以降は、インストール時に「Server Core」か「Server with Desktop Experience」かを選ぶ方式が中心で、後から GUI を載せ替える発想が取りづらくなっています。
つまり「cleanmgr を使いたいから Feature を追加する」というより、OS のインストール形態（Core / Desktop Experience）の選択が分岐点になります。すでに Server Core で稼働しているサーバーでは、次の選択肢のいずれかになります。
| 選択肢 | サポート性 | 期待できる効果 | 向いているケース |
|---|---|---|---|
| Server with Desktop Experience で再構築 | 高い（公式の範囲） | cleanmgr を含む GUI ツールが利用可能 | GUI が必要／更改タイミングが近い |
| cleanmgr.exe を手動で持ち込む | 低い（非公式寄り） | Disk Cleanup を “動かせる可能性” | 短期的にどうしても使いたい |
| DISM やスクリプトで代替クリーンアップ | 高い（運用で一般的） | WinSxS・キャッシュ・ログ等の整理 | Core のまま堅実に運用したい |
どうしても cleanmgr.exe を使いたい場合の手動導入（非公式寄り）
Server Core に cleanmgr.exe が無い以上、どうしても Disk Cleanup を使いたい場合は「別の Windows Server からファイルを持ってくる」という回避策が語られることがあります。ここから先は、検証環境での事前確認とバックアップを前提にしてください。
手動導入で必要になるファイル
最低限、次の 2 つが必要です。
- cleanmgr.exe
- cleanmgr.exe.mui（言語リソース）
ポイントは、コピー元が 同一バージョン／可能な限り同一更新レベル（Build が近い）であることです。ビルド差が大きいと、依存 DLL やリソースの不整合で起動しない・動作が不安定になるリスクが上がります。
配置先（System32 と言語フォルダ）
配置はシンプルですが、言語フォルダを間違えると UI が崩れたり、起動時にエラーになったりします。
cleanmgr.exe→%SystemRoot%\System32cleanmgr.exe.mui→%SystemRoot%\System32\ja-JP（日本語 OS の例）
英語環境の場合は en-US 配下です。自分の環境の言語名が分からない場合は、PowerShell で次のように確認できます。
# OS の UI 言語やロケールを確認（環境により値は異なります）
(Get-WinSystemLocale).Name
(Get-Culture).Name
導入後の実行（例）
ファイル配置後、管理者権限のコンソールから次を実行します。
cleanmgrDisk Cleanup は GUI 操作が前提のため、Server Core の環境や接続方法（リモート セッションの種類）によってはウィンドウが表示されない／操作しにくい場合があります。うまく動作しないときは、後述の「代替策（DISM / スクリプト）」を優先してください。
セキュリティ・運用上の注意点（必ず読む）
- Microsoft の正式サポート対象外になる可能性があります。障害時の切り分けやサポート対応を重視する環境では避けるべきです。
- 本番サーバーに手を入れる前に、スナップショット／フルバックアップ、最低でも対象フォルダの退避を行ってください。
- コピー元とコピー先でバージョン差がある場合、起動できても「予期しない削除」や「UI 表示の不整合」など、運用リスクが増えます。
どうしても実施するなら、せめてファイルの署名確認とバージョン確認はしておきます。
# バージョン確認
(Get-Item "$env:SystemRoot\System32\cleanmgr.exe").VersionInfo | Format-List
# 署名確認
Get-AuthenticodeSignature "$env:SystemRoot\System32\cleanmgr.exe" Server Core のディスク整理は「DISM のコンポーネント クリーンアップ」が本命
cleanmgr が使えない（または使わない）前提で、Server Core でまず検討すべきなのが DISM によるコンポーネント ストア（WinSxS）整理です。Windows Update を重ねると、置き換えられた古いコンポーネントが WinSxS に残り、システムドライブを圧迫します。
まずは現状分析：AnalyzeComponentStore
dism.exe /Online /Cleanup-Image /AnalyzeComponentStoreこの結果で「コンポーネント ストアのサイズ」「クリーンアップ推奨かどうか」の目安が取れます。いきなり削除に進むより、分析 → 実行 の順にすると安全です。
実行：StartComponentCleanup
dism.exe /Online /Cleanup-Image /StartComponentCleanup置き換え済みコンポーネントの整理を行い、WinSxS の肥大化を抑えます。更新直後に走らせるより、更新適用→再起動→安定確認→クリーンアップの順がトラブルを減らします。
強力だが慎重に：/ResetBase
dism.exe /Online /Cleanup-Image /StartComponentCleanup /ResetBase/ResetBase はさらに強力ですが、適用済み更新のアンインストールが困難（できなくなる）になる方向に寄ります。特に本番サーバーでは、パッチ運用のポリシー（ロールバック要件）に合うかを確認してから使ってください。
| コマンド | 目的 | 安全性の目安 | 補足 |
|---|---|---|---|
/AnalyzeComponentStore | WinSxS の分析 | 高い | まずは必ず実行 |
/StartComponentCleanup | 置き換え済みの整理 | 比較的高い | 定期実行の候補 |
/StartComponentCleanup /ResetBase | より徹底した整理 | 要注意 | 更新のロールバック要件と相性が悪い |
cleanmgr の代わりに使える「容量削減」アイデア集（Server Core 向け）
ディスク逼迫の原因は WinSxS だけとは限りません。Server Core では GUI の「ディスク クリーンアップ」ボタンが無いぶん、どこが増えているかを把握して、狙い撃ちで減らすのが基本です。
どこが増えているかを素早く把握する
まずは OS 標準のコマンドで空き容量を確認します。
Get-Volume | Sort-Object DriveLetter | Format-Table DriveLetter, FileSystemLabel, SizeRemaining, Size -Auto次に「巨大フォルダ」を探します。PowerShell だけで再帰集計すると時間がかかるため、まずは候補を絞るのがコツです。
C:\Windows配下（特にWinSxS,SoftwareDistribution,Logs）C:\inetpub（IIS ログ）- アプリケーション固有のログ／ダンプ
管理端末がある場合は、Windows Admin Center（WAC）やファイル分析ツールを “管理端末側” に入れて、Server Core をリモートで可視化するのが現実的です。
安全に削除できることが多い領域（例）
| 対象 | 代表パス | 削除・整理の考え方 | 注意点 |
|---|---|---|---|
| 一時ファイル | %TEMP%, C:\Windows\Temp | 一定日数より古いものを削除 | 稼働中プロセスが掴むファイルは失敗する |
| Windows Update ダウンロード キャッシュ | C:\Windows\SoftwareDistribution\Download | 更新トラブル時や逼迫時に整理 | サービス停止が必要／履歴表示への影響に注意 |
| ログ（役割・アプリ） | IIS/アプリ/バックアップログ等 | ローテーション・保管先分離 | 監査要件や保管ポリシーに従う |
| メモリダンプ | C:\Windows\MEMORY.DMP | 解析済みなら退避して削除 | 原因調査が終わるまで消さない |
実務で使える PowerShell 例：古い Temp を整理する
「何でも消す」のは事故の元です。ここでは、比較的安全に運用しやすい “古い一時ファイルだけ削除する” 例を示します。まずは -WhatIf を付けて影響範囲を確認し、その後に本実行する流れがおすすめです。
# 例：7日より古い一時ファイルを削除（まずは -WhatIf で確認）
$days = 7
$limit = (Get-Date).AddDays(-$days)
$targets = @(
$env:TEMP,
"$env:SystemRoot\Temp"
)
foreach ($t in $targets) {
if (-not (Test-Path $t)) { continue }
Get-ChildItem -Path $t -Force -Recurse -ErrorAction SilentlyContinue |
Where-Object { -not $_.PSIsContainer -and $_.LastWriteTime -lt $limit } |
Remove-Item -Force -ErrorAction SilentlyContinue -WhatIf
}
本番での定期実行にする場合は、エラー出力をログに残す、削除対象をフォルダ単位で限定する、といった“手綱”を付けると安心です。
Windows Update のダウンロード キャッシュを整理する（逼迫時の最終手段寄り）
SoftwareDistribution\Download は状況によって肥大化します。ただし無闇に消すと更新関連のトラブルシュートが難しくなることもあるため、空き容量が危険水域で、他の手が打てない時の手段として位置付けるのが安全です。
# サービス停止
Stop-Service wuauserv -Force
Stop-Service bits -Force
# ダウンロード キャッシュ削除
Remove-Item "C:\Windows\SoftwareDistribution\Download\*" -Recurse -Force -ErrorAction SilentlyContinue
# サービス起動
Start-Service bits
Start-Service wuauserv
- 実行後、Windows Update が次回から必要なファイルを再ダウンロードします。
- 更新が失敗している最中や再起動待ち（pending reboot）の状態で行うのは避けます。
cleanmgr を入れても“万能”ではない理由
Disk Cleanup は便利ですが、サーバー運用では次の理由で “頼り切り” になりにくいのが実情です。
- 何を消すかが項目ごとに異なり、削除の根拠が監査・運用資料に残りにくい
- GUI 操作が前提で、Server Core の自動化や無人実行と相性が良くない
- 根本原因（ログが出過ぎる、更新が溜まる、ダンプが残る等）を解決しないと再発する
そのため、Server Core では「DISM で WinSxS を整える」「ログの出方を制御する」「保存先を分離する」「監視とアラートを整える」といった運用設計が、結果的に一番効きます。
トラブルシューティング：手動導入した cleanmgr が動かないとき
コピーしても期待通り動かないケースがあります。ありがちな切り分けポイントを挙げます。
- MUI の配置先が違う：
ja-JP/en-USなど、OS 言語に合ったフォルダに入っているか確認 - コピー元のビルドが違う：月例更新の差でも挙動が変わることがあるため、同一更新レベルを推奨
- GUI を表示できないセッション：接続方式や制限でウィンドウが見えない場合、そもそも GUI ツール運用が向かない
- 権限：管理者として実行しているか、UAC 相当の制限が無いかを確認
ここで深追いするより、Server Core の思想に沿って DISM + スクリプト に寄せた方が、再現性と安全性が上がります。
再発防止：Server Core で容量不足を起こさない運用のコツ
- システム領域とデータ領域の分離：ログやバックアップを OS ドライブに置かない設計にする
- ログのローテーション：IIS/アプリ/バックアップの保管日数を決め、古いものを自動削除
- 更新の運用フローに DISM を組み込む：パッチ適用後の安定確認が取れたら
/StartComponentCleanupを実行する - 監視とアラート：空き容量が閾値を割ったら通知し、逼迫前に手を打つ
特に「空きが無くなってから慌てて cleanmgr」という運用だと、復旧優先の“力技”が増えがちです。月次の定期メンテナンスに組み込んでおくと、Server Core の安定運用に直結します。
まとめ：Windows Server 2019 Server Core のディスク整理は“公式寄りの手段”を軸に
Windows Server 2019 の Server Core では、cleanmgr.exe（ディスク クリーンアップ）は標準では使えず、Feature 追加で簡単に導入できるものでもありません。どうしても必要ならファイル持ち込みという手はありますが、サポート性と再現性の観点ではおすすめしづらいのが正直なところです。
まずは DISM によるコンポーネント クリーンアップで WinSxS を整理し、次に Temp・ログ・キャッシュなど増えやすい箇所を運用でコントロールする。この順番で取り組むと、Server Core のメリットを損なわずにディスク逼迫を減らせます。
コメント