WindowsのDriverStoreが肥大化する原因と安全に容量を減らす整理手順

本記事が扱う事象は、Windowsの「削除しにくい」システム領域のうち、DriverStore（ドライバーストア）配下の容量が増え、ストレージを圧迫するケースです。海外メディアでは、DriverStoreの整理で約20GBの空き容量を確保した事例が紹介されました。 (MakeUseOf)
ただし、DriverStoreはドライバーの保管と再インストールの基盤であり、単純にフォルダーを消す設計ではありません。以上を踏まえると、容量削減は「フォルダーの直接削除」ではなく、Windowsが想定する手段で「不要なドライバーパッケージを減らす」整理として捉える必要があります。 (Microsoft Learn)

• DriverStoreの役割と「触れないフォルダー」になりやすい理由
• 容量が増える仕組みと20GB規模まで拡大する条件
• 容量削減はPnPUtilでのドライバーパッケージ整理として扱う
• ほかのクリーンアップ機能との違いとDISMの守備範囲
• 整理後に起こり得る影響と運用上の確認点

DriverStoreの役割と「触れないフォルダー」になりやすい理由

DriverStoreは、Windowsが信頼できるドライバーパッケージだけを保管し、必要時に再利用するための保護領域です。
DriverStore（ドライバーストア）は、Windows標準のドライバーと、ベンダー提供のドライバーを含む「信頼されたコレクション」として管理されます。デバイスへドライバーを導入する前に、ドライバーパッケージはDriverStoreへ取り込まれます。この取り込みはstaging（ステージング）と呼ばれ、導入（インストール）とは別の処理として分離されています。 (Microsoft Learn)

そのため、DriverStoreに置かれるファイルは、INF（セットアップ情報）や関連ファイル一式として整合性を前提に扱われます。Microsoftの説明では、ステージング後のファイルは削除や改変を前提にしておらず、外部からの直接操作も含めて変更すべきではないと整理されています。 (Microsoft Learn)
なお、代表的な配置先として \Windows\System32\DriverStore\FileRepository（ファイルリポジトリ）が挙げられます。ここに複数世代の同種ドライバーが残ると、合計サイズが増える構造になります。 (Microsoft Learn)

ただし、この「変更しない前提」は、容量が増えた場合の整理を全面的に否定する意味ではありません。他方で、整理の手段はフォルダー操作ではなく、ドライバー管理機能を通じた削減に限定される点が実務上の確認点となります。 (Microsoft Learn)

容量が増える仕組みと20GB規模まで拡大する条件

容量増加の中心は、更新や差し替えで旧版ドライバーが残り、複数世代が積み上がる点にあります。
DriverStoreは「現在使うドライバー」だけを置く倉庫ではなく、導入済みドライバーの履歴や、互換性確保のための複数候補を保持しやすい構造です。言い換えると、最新ドライバーへ更新しても、旧版が直ちに消えるとは限りません。 (Microsoft Learn)

この点から、GPU（グラフィックス）やプリンター、ネットワークなど、サイズが大きいドライバーを何度も更新する端末ほど膨張しやすくなります。Windows側は問題が起きた際の切り戻しを成立させるため、複数パッケージを段階的に保持する場合があります。そうすることによって、更新失敗時の復旧余地を残せますが、ストレージ面では増加要因になります。 (Windows Forum)

海外メディアやコミュニティでは、DriverStore整理で10GB超から20GB規模の空き容量が出たとする報告が散見されます。ただし、同じ「20GB」でも増え方は環境依存であり、ドライバー更新頻度、利用デバイス数、メーカー配布の導入方式などで条件差が生じる可能性があります。 (MakeUseOf)
つまり、容量増加は異常というより、運用の積み上げで発生し得る事象として整理できます。その結果、削減方法も「何を残すか」を軸に組み立てる必要があります。

容量削減はPnPUtilでのドライバーパッケージ整理として扱う

DriverStoreの整理は、PnPUtil（プラグアンドプレイ・ユーティリティ）で不要パッケージを列挙し、削除対象を絞る流れで成立します。
PnPUtil（PnPUtil.exe）はWindowsに同梱され、ドライバーストアの列挙や削除などの操作体系が定義されています。多くの操作に管理者権限が必要であり、削除は /delete-driver、列挙は /enum-drivers が基本になります。 (Microsoft Learn)

そのため、一般に用いられる確認・削除の呼び出し例は次の形になります。なお、ここでは「直接フォルダーを消す」のではなく、公開名（例: oem##.inf）を単位として扱う点が重要です。 (Microsoft Learn)

ただし、削除フラグには強制削除（/force）などもあり、動作影響が大きくなり得ます。要点を整理すると、削除対象の判断は「現用か」「置換済みか」「代替があるか」の三点で構造化されます。 (Microsoft Learn)

なお、pnputilの構文と例はMicrosoftが更新を継続しており、2025年11月時点でも操作例が整理されています。ここを基準に、端末の状態に合わせて整理手順を整することが実務上の確認点となります。 (Microsoft Learn)

ほかのクリーンアップ機能との違いとDISMの守備範囲

DISM（展開イメージのサービスと管理）はDriverStoreではなく、主にコンポーネントストアの整理に使われる枠組みです。
ストレージ不足の文脈では、Disk Cleanup（ディスク クリーンアップ）や、Windows Update（更新）関連の掃除、WinSxS（コンポーネントストア）縮小が並列に語られがちです。ただし、対象が同じとは限りません。 (Microsoft Learn)

Microsoftの説明では、WinSxSの縮小はタスク（StartComponentCleanup）や、Dism.exe /online /Cleanup-Image /StartComponentCleanup といった手段で行われます。この結果、更新済みコンポーネントの旧版が削除され、コンポーネントストア側の容量が減る形になります。 (Microsoft Learn)
一方で、DriverStoreの肥大化はドライバーパッケージの積み上げが中心であり、DISMのコンポーネント整理と同一視すると論点がずれます。言い換えると、DriverStoreはPnPUtilなどのドライバー管理の枠内で扱い、WinSxSはコンポーネント管理の枠内で扱う、という分離が必要です。 (Microsoft Learn)

なお、コミュニティ記事ではDISMでドライバー退避を行い、PnPUtilで削除する構成も示されています。ただし、これは運用設計の一例であり、どの範囲まで実施するかは端末の役割や復旧要件に依存します。 (Windows Forum)
つまり、容量削減は単一コマンドの問題ではなく、対象領域の切り分けが先に必要となります。

整理後に起こり得る影響と運用上の確認点

DriverStoreからの削除は、将来の自動再導入や切り戻しの余地を狭めるため、影響範囲の見積りが前提になります。
DriverStoreは、デバイスの再接続や再検出の際に、Windowsが自動で適用可能なドライバーパッケージを提供する土台です。そのため、置換済みの旧版を減らす行為は容量面で有効でも、故障対応や再構成の段取りには影響します。 (Microsoft Learn)

また、PnPUtilの /uninstall や /force は、適用中のデバイスへ干渉する可能性を高めます。他方で、管理者権限が必要という制約もあり、操作主体や変更管理の扱いが実務上の確認点となります。 (Microsoft Learn)
なお、DriverStore Explorer（RAPR）などのGUI（グラフィカルユーザーインターフェース）ツールも存在しますが、公式リポジトリ側で誤操作による起動不能や機能喪失の警告が明記されています。この点から、ツール選定は「見やすさ」ではなく、復旧手段と監査性を含む運用条件で整理されます。 (GitHub)

海外メディアが示した「削除しにくい領域の整理で大きく空きが出る」という筋立ては、容量が積み上がる構造を前提にすると説明がつきます。ただし、DriverStoreは安全策としての保持も含むため、削減は「不要の定義」を先に置いた上で実施される作業として位置づけられます。 (MakeUseOf)