Windows ストレージセンサーのレジストリ設定徹底解説｜StorageSense と StorageSensor の違いと Intune 配布のベストプラクティス

企業 PC のストレージ不足やパフォーマンス低下を防ぐうえで、Windows 10/11 の「ストレージセンサー（Storage Sense）」はとても強力な機能です。しかしレジストリには StorageSense と StorageSensor の2系統が存在し、「Intune からスクリプトでどちらを触ればよいのか？」でつまずくケースが少なくありません。本記事では、この2つの違いと、実運用でどのキーをどう管理すべきかを、PowerShell や Intune 運用の観点から詳しく解説します。

Storage Sense と StorageSensor レジストリの違い

まずは前提として、「Storage Sense（ストレージセンサー）」という名前で呼ばれているものの中に、次の2つのレイヤーが存在していると考えると整理しやすくなります。

ユーザー向け UI レイヤー：設定アプリの画面やトグルスイッチ
バックグラウンドエンジンレイヤー：実際にファイルを削除するタスク

このレイヤーの違いが、そのままレジストリパスの違いとして表れています。

役割	レジストリパス	概要
UI（表示・設定アプリ用）	`HKCU\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy`	設定アプリの GUI で表示・操作した値を格納する。ビットマスクで複数のフラグを管理している。
エンジン（実際のクリーンアップ）	`HKCU\Software\Microsoft\Windows\CurrentVersion\StorageSensor\Parameters\StorageSensorV2`	バックグラウンドで動作するクリーンアップエンジンが参照する「実際の設定」。こちらがソース・オブ・トゥルース。

よくある混乱の原因は、StorageSense（UI）側の値だけを書き換えても、エンジン側がその値を必ずしも反映してくれるとは限らない点にあります。逆に、StorageSensorV2（エンジン）側を直接書き換えると、実際の削除動作は変わるが、GUI 上の表示は更新されないことがある、というズレが発生します。

なぜ UI 用とエンジン用でパスが分かれているのか

Windows の多くの設定は、次のような構造をとります。

ユーザーがさわる UI 用の設定（表示・入力のための器）
システム内部で参照するエンジン側の設定（処理ロジック）

Storage Sense も同様で、StoragePolicy は「UI の状態」、StorageSensorV2 は「エンジンが参照する最終的な値」という役割に分かれていると理解するとスッキリします。

特に StoragePolicy の値は、

2048 / 512 / 256 … といったビットマスク値
複数のチェックボックスやトグルの ON/OFF を 1 つの値に詰め込んだもの

になっているため、スクリプトから直接いじるには非常に扱いにくいのが実情です。「UI の見た目を揃える」という目的以外では、積極的に触るメリットはほとんどありません。

どちらを書き換えるべきか ― 結論

企業での運用、特に Intune や PowerShell を使った一括配布を考える場合の結論はシンプルです。

実際の動作を正しく制御したいなら、StorageSensor\...\StorageSensorV2（エンジン側）だけを設定する。

理由は次の通りです。

クリーンアップのバックグラウンドタスクが参照しているのは StorageSensorV2 側である
StorageSense（UI）側は表示が主目的で、設定が同期しないケースがある
UI のビットマスク値をスクリプトで安全に扱うのは難しく、メンテナンス性が低い
「見た目」と「実動作」がズレてトラブルになるくらいなら、実動作の整合性を優先した方が運用として健全

つまり、管理対象としては「エンジン側キーだけに絞る」が最もシンプルで再現性の高い方針です。

UI との表示ズレは気になるかもしれませんが、ストレージセンサーで本当に守りたいのは「ディスク容量とクリーンアップの動作」です。ユーザーが設定画面を開いたときに多少の違和感があっても、実際の削除ロジックが正しく動いていることの方が重要と割り切るのが現実的です。

StorageSensorV2 で制御できる主なパラメータ

Intune などから制御するうえで、最低限押さえておきたいキーは次の3つです。すべて REG_DWORD で設定します。

レジストリキー名	役割	主な設定値と意味
`RunPeriodDays`	ストレージセンサーの実行頻度（日単位）	`1`：毎日 `7`：毎週 `30`：毎月 `0`：空き容量が少ないときのみ
`RecycleBinRetentionDays`	ごみ箱に移動してから保持する日数	`30`：30日より前のごみ箱アイテムを削除 `0`：ストレージセンサーでは削除しない
`DownloadsRetentionDays`	ダウンロードフォルダーの保持日数	`60`：60日より前のファイルを削除対象にする `0`：ダウンロードフォルダーは削除しない

レジストリパスは次の通りです。

HKCU\Software\Microsoft\Windows\CurrentVersion\StorageSensor\Parameters\StorageSensorV2

ダウンロードフォルダーについては、キー名のスペルミスがよくあるポイントです。DownloadsRetentionDays が正しく、「Downlads…」のようなタイプミスに注意してください。

「0」の意味に注意

RunPeriodDays と RecycleBinRetentionDays / DownloadsRetentionDays では、「0」の意味が異なる点に注意が必要です。

RunPeriodDays = 0：
自動スケジュールは行わず、「空き容量が少なくなったとき」にのみ実行する。
RecycleBinRetentionDays = 0：
ごみ箱内のファイルはストレージセンサーでは削除しない。
DownloadsRetentionDays = 0：
ダウンロードフォルダーはストレージセンサーでは削除しない。

特に「削除させたくない」フォルダー（ダウンロードなど）がある場合は、RunPeriodDays は設定しつつ、削除したくない対象の保持日数は 0 にする、という設計が安全です。

StoragePolicy（UI用）をあえて触らない方がよい理由

実務では、次のような相談を受けることが多くあります。

「StorageSensorV2 を書き換えたら動作したが、設定画面の表示が変わらない」
「GUI で表示されている日数と、実際に削除されるタイミングが合わない」

このギャップを埋めるために、StorageSense\...\StoragePolicy も同時に書き換えようとするケースがあります。しかし、以下の理由から原則として StoragePolicy は触らない方が無難です。

StoragePolicy の値はビットマスクで、どのビットがどの項目に対応するか完全には公開されていない
Windows のバージョンアップや機能追加で、ビット割り当てが変わる可能性がある
一見正しく見えても、エンジンとの整合性が崩れるリスクが高い
スクリプト側でビット演算をミスすると、想定外の UI 表示や動作になる

つまり、「UI の数字を揃えるために StoragePolicy をこねくり回す」より、「エンジン側だけを確実に管理する」方が安全でメンテナンスしやすいという判断になります。

どうしても UI の表示も合わせたい場合は、

少数のテスト端末で GUI 操作 → 値の変化をモニタリング
その値をテンプレートとして 固定値で書き戻す（ビット演算は極力避ける）

といった方針が考えられますが、本番運用では StorageSensorV2 のみを管理対象にすることを強くおすすめします。

Intune で配布する際の基本方針

ここからは、実際に Intune で配布するときの考え方と設計のポイントを解説します。

ユーザー単位での制御が前提（HKCU）

今回操作するレジストリは HKCU（ユーザーハイブ）配下です。そのため、Intune の PowerShell スクリプトは「ユーザーコンテキスト」で実行する必要があります。

実行コンテキスト：ユーザー
64 ビット PowerShell で実行：有効（推奨）

PC に複数ユーザーがサインインする環境（共有端末など）では、サインインしたユーザーごとにスクリプトが実行され、各ユーザーの HKCU に設定が入るイメージです。

設定値はすべて REG_DWORD（10進でOK）

StorageSensorV2 のキーはすべて REG_DWORD です。PowerShell からは 10 進数で指定して問題ありません。

30日 → -Value 30
60日 → -Value 60
毎週 → RunPeriodDays = 7

10 進で指定しても、レジストリエディター上は 16 進数表示で見える場合がありますが、内部的には同じ整数値なので気にする必要はありません。

「どの値を誰に適用するか」の設計例

ストレージセンサーの戦略は、ユーザーの利用形態によって変えるのが理想です。例えば、次のようなプロファイル分けが考えられます。

ユーザー種別	用途のイメージ	RunPeriodDays	RecycleBinRetentionDays	DownloadsRetentionDays
一般オフィスユーザー	Office 文書中心、ローカル容量はほどほど	7（毎週）	30	60
VDI・共有 PC	短時間利用が多い、ユーザー入れ替わり	1（毎日）	7〜14	7〜14
開発者・クリエイター	大容量ファイルを扱うが自己管理能力が高い	7（毎週）	30	0（ダウンロードは削除しない）

このように、ユーザープロファイルごとに Intune の割り当てグループを分けておき、それぞれ異なる PowerShell スクリプトを配布すると、現場の実態に沿ったきめ細かい運用が可能になります。

PowerShell スクリプト例（基本）

もっともシンプルな例として、「毎週実行 / ごみ箱30日 / ダウンロード60日」に統一するスクリプトを示します。

$path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\StorageSensor\Parameters\StorageSensorV2'

# キーが存在しない場合も考慮して作成
New-Item -Path $path -Force | Out-Null

# 実行頻度：毎週
New-ItemProperty -Path $path -Name 'RunPeriodDays' -PropertyType DWord -Value 7 -Force | Out-Null

# ごみ箱：30日より前を削除
New-ItemProperty -Path $path -Name 'RecycleBinRetentionDays' -PropertyType DWord -Value 30 -Force | Out-Null

# ダウンロード フォルダー：60日より前を削除
New-ItemProperty -Path $path -Name 'DownloadsRetentionDays' -PropertyType DWord -Value 60 -Force | Out-Null

ポイントは次の通りです。

New-Item -Force で、キーがなくても安全に作成できる
New-ItemProperty -Force で、値が既にあっても上書き可能
冪等性が高く、同じスクリプトを何度実行しても結果が安定している

Intune では、「複数回実行」を有効にしておくと、端末のライフサイクル中に設定がズレた場合でも自然に修正されるため、より安心です。

PowerShell スクリプト例（環境別に値を変えたい場合）

同じスクリプトを使い回しつつ、環境ごとに値だけ変えたい場合は、変数化しておくとメンテナンスが楽になります。

# ===== 環境別パラメータ（ここだけ書き換える） =====
$runPeriodDays            = 7   # 実行頻度
$recycleBinRetentionDays  = 30  # ごみ箱の保持日数
$downloadsRetentionDays   = 60  # ダウンロード フォルダーの保持日数
# ================================================

$path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\StorageSensor\Parameters\StorageSensorV2'

New-Item -Path $path -Force | Out-Null

New-ItemProperty -Path $path -Name 'RunPeriodDays' -PropertyType DWord -Value $runPeriodDays -Force | Out-Null
New-ItemProperty -Path $path -Name 'RecycleBinRetentionDays' -PropertyType DWord -Value $recycleBinRetentionDays -Force | Out-Null
New-ItemProperty -Path $path -Name 'DownloadsRetentionDays' -PropertyType DWord -Value $downloadsRetentionDays -Force | Out-Null

このスクリプトをベースとして、

「一般ユーザー用」「VDI 用」「開発者用」など、値だけをコピーして変えたバージョンを複数用意する
Intune の「スクリプト名」や「割り当てグループ名」にプロファイル名を分かりやすく付ける

といった運用にすると、構成管理がシンプルになります。

Intune への登録手順（要点）

具体的なポータルの画面操作は割愛し、要点だけを整理します。

Intune 管理センターで
「デバイス」→「スクリプト」→「Windows PowerShell」 を開く
前述の PowerShell スクリプト（.ps1）をアップロード
スクリプト設定で次を指定
- 実行コンテキスト：ユーザー
- 64 ビット PowerShell で実行：はい（推奨）
- 複数回実行：可能であれば「はい」（環境による）
対象の Azure AD グループ（ユーザーグループ）に割り当て

特に共有端末や VDI 環境では、ユーザーサインインのタイミングで確実に HKCU に設定が入ることが重要です。テスト用のグループを用意し、小規模での検証 → 段階的展開という流れを守ると安心です。

動作確認のコツ（SilentCleanup の活用）

「レジストリは設定できたはずだが、本当にストレージセンサーが期待通りに動くのか？」という不安を解消するために、タスクスケジューラからの手動実行が役立ちます。

管理者権限のコマンドプロンプトまたは PowerShell を開く
タスクスケジューラを起動して次のパスを開く：
タスクスケジューラライブラリ → Microsoft → Windows → DiskCleanup
「SilentCleanup」タスクを右クリックして「実行」

この操作により、クリーンアップ関連の処理がバックグラウンドで走るため、

ごみ箱やダウンロードフォルダーで、古いファイルが削除されるか
イベントログやディスク容量の変化から、期待した動作が行われたか

といった観点で確認できます。実際の削除タイミングや対象を厳密に確認したい場合は、

テスト用に専用フォルダーやテストファイルを用意しておく
「作成日時」「更新日時」を過去日に変更して挙動を見る

といったやり方が有効です。

よくあるトラブルとその考え方

GUI の表示と実際の動作が一致しない

前述の通り、StorageSense（UI）側と StorageSensor（エンジン）側の値が同期していないことが主な原因です。Intune から StorageSensorV2 のみを管理している場合、

設定アプリ上の「保持日数」が初期値やユーザー操作のまま
実際の削除ロジックは Intune で配布した値通りに動作している

という状態になり得ます。この場合、「動作が正しいか」を優先して評価し、GUI 表示のズレは仕様として割り切るのが現実的です。

ユーザーが自分で GUI から設定を変えてしまう

ユーザーが設定アプリからストレージセンサーの設定を変更すると、StorageSense 側の値はもちろん、StorageSensorV2 側の一部も書き換えられる可能性があります。

これを防ぐ硬めの運用としては、

グループポリシーや Intune の設定カタログで「ストレージセンサーのユーザー設定変更」を制限する
Intune の PowerShell を定期的に再実行し、値の乖離を自動修正する

といったアプローチが考えられます。ただし、あまりに制限をかけすぎるとユーザー体験が悪化するため、現場の運用ポリシーに合わせたバランスが重要です。

ごみ箱やダウンロードからの削除でユーザーが困る

ストレージセンサーでありがちなトラブルとして、

「勝手にダウンロードフォルダーのファイルが消えた」
「ごみ箱に残しておいたファイルがいつの間にか消えていた」

といった声が挙がることがあります。これを避けるためには、技術的な設定だけでなく、運用ルールとユーザーへの案内が非常に重要です。

ダウンロードフォルダーは「一時ファイル置き場」として扱うよう周知する
重要なファイルは必ずドキュメントや OneDrive / SharePoint に保存してもらう
ごみ箱からの自動削除のポリシー（例：30日）は社内ルールとして明文化

技術と運用の両方からケアしてはじめて、ストレージセンサーを安心して有効化できます。

運用設計のベストプラクティス

ここまでの内容を踏まえ、実務での運用設計のポイントを整理します。

1. まずは「テスト用リング」で小さく導入する

いきなり全社展開するのではなく、次のような段階的な導入がおすすめです。

IT 部門用のテストグループに適用して挙動を確認
次に、協力的なパイロットユーザー（現場のキーユーザーなど）に拡大
問題がなければ一般ユーザーへ段階的に展開

この際、ストレージセンサーの設定だけでなく、ユーザーの反応・問い合わせ内容も記録しておくと、本格運用時の FAQ 整備に役立ちます。

2. レジストリ編集範囲は可能な限り最小にする

Intune からレジストリを触るときは、「必要最低限のキーだけを確実に管理する」ことが鉄則です。

今回でいえば
- RunPeriodDays
- RecycleBinRetentionDays
- DownloadsRetentionDays
に絞る
StoragePolicy など UI 用キーは、特別な理由がない限り触らない
不明なキーを「ついでに」いじらない

「よく分からないけど値を合わせておこう」という発想は、将来のトラブルの元になりがちです。

3. 設定値・意図・適用範囲を必ずドキュメント化する

レジストリによる制御は、GUI のポリシー設定に比べると「見える化」が弱いのが弱点です。将来の運用担当者が困らないように、

どの OU / Azure AD グループに、どのスクリプトを適用しているか
スクリプト内の各値の意味（例：RunPeriodDays = 7 の意図）
いつ・誰が・どのような理由で値を変更したか

といった情報を、社内 Wiki や変更管理システムに残しておくことを強くおすすめします。

まとめ

本記事のポイントを最後に整理します。

レジストリには StorageSense（UI 用）と StorageSensor（エンジン用）の 2 系統がある
実際のクリーンアップ動作を制御したいなら、
HKCU\Software\Microsoft\Windows\CurrentVersion\StorageSensor\Parameters\StorageSensorV2
を書き換えるのが正解
StorageSense\...\StoragePolicy は主に表示用で、ビットマスク値が複雑なため、基本的には触らない方が安全
制御すべき主なキーは
- RunPeriodDays：実行頻度（1 / 7 / 30 / 0）
- RecycleBinRetentionDays：ごみ箱の保持日数（0 は削除しない）
- DownloadsRetentionDays：ダウンロードフォルダーの保持日数（0 は削除しない）
Intune で配布する場合は
- スクリプトの実行コンテキストを「ユーザー」にする
- 64 ビット PowerShell を有効にする
- 必要なら環境別にスクリプトを分けて配布する
動作確認にはタスクスケジューラの SilentCleanup を活用すると分かりやすい

ストレージセンサーは、「一度きちんと設計・配布してしまえば、その後は静かにストレージ容量を守ってくれる」心強い機能です。
StorageSense と StorageSensor（StorageSensorV2）の役割の違いを理解し、エンジン側レジストリを軸にしたシンプルな運用を組み立てることで、ストレージ管理の手間とトラブルを大きく減らすことができます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Windows ストレージセンサーのレジストリ設定徹底解説｜StorageSense と StorageSensor の違いと Intune 配布のベストプラクティス