maintaining-windows-health

Windows 11 の健全性を維持する

Windows 11 のディスクおよびメモリの危機に対する、復旧と予防のプレイブックです。maintaining-macos-health スキルの Windows 移植版で、同じ 3 つのレイヤー（トリアージ → 段階的な復旧 → 自動化／アラート）と、同じ安全性の不変条件を採用しています。つまり、スキャン → JSON → ユーザーが UI で選択 → 選択された項目のみを適用時に削除します。ただし、Windows ネイティブのツールと、Windows 固有の「絶対に触れない」ルールを使用します。このプレイブックは、日常的なクリーンアップにも、新しいマシンでの初回セットアップにも使えます。

目次

• 使用するタイミング
• スキルの構成
• 基本的な考え方
• 標準的なワークフロー
  • A.「今すぐ空き容量を確保する」（インシデント対応）
  • B.「アラートを設定する」（新しいマシンまたは初回）
  • C. アラートツールが動かない／通知が多すぎる
  • D.「アプリをきれいにアンインストールする」
• 安全ルール（絶対遵守）
• 把握しておくドメイン固有の事情
• 成果の尺度

使用するタイミング

次のいずれかに該当する場合に使用します。

• ディスクの空き容量が 20 % 未満、またはユーザーから空き容量不足の申告がある
• BSOD／予期しない再起動／Kernel-Power 41／WHEA エラーが発生した、または C:\Windows\Minidump に新しいクラッシュダンプがある
• 「PC の動作が遅い」、コミット使用率が高い（% Committed Bytes In Use > 85）、ページファイルが増大している
• ユーザーが監視／アラートを一から設定したい
• 新しい Windows PC への移行 → 同じアラートツールを復元する
• 一般的な「PC をクリーンアップして」「ストレージを監査して」「空き容量を確保して」という依頼

スキルの構成

ファイル	用途
references/triage.md	最初の 5 分間 — どのシグナルが発生したか（ディスク／コミットメモリ／BSOD クラッシュ／「動作が遅い」）を特定し、読み取り専用のスナップショットを取得します
references/cleanup-tiers.md	段階的なクリーンアップのプレイブック（10 段階、低リスクから、事前の相談が必要なものまで）。そのままコピーして安全に使える PowerShell ブロックを収録しています
references/never-touch.md	管理者権限でも削除してはならないカテゴリ（検証ツールと同期された厳密に保護されるプレフィックス、および Windows 固有の危険箇所）
references/native-tools.md	安全性の最低基準：Microsoft ネイティブツール、プロジェクト生成物の削除に使うマーカー→対象の対応表、適用スクリプトの検証ルール、サードパーティ製ツールに関する注意事項
references/alerting.md	アラートツールの詳細設計：重大度が CRITICAL の場合に限る 3 つのトリガー、ヒステリシス、調整、タスクスケジューラの対話型セッション、BurntToast と ntfy、S0ix／バッテリー
assets/win-health-check.ps1	本番環境向け PowerShell モニター（PS 5.1 対応）
assets/win-health-check.config.ps1	デフォルトのしきい値
assets/Install-WinHealthCheck.ps1	対話型ユーザーセッションにスケジュールされたタスクを登録します。-Test／-Uninstall に対応
assets/Audit-WinHealth.ps1	読み取り専用の事前インベントリ（ドライブ、コンポーネントストア、シャドウストレージ、プロファイル、ドライバー、CFA、KFM、BitLocker、再解析ポイント、ダンプ）
assets/render-cleanup-plan.py	対話型の HTML クリーンアップ計画 UI。スキャン結果の JSON からカテゴリ別のチェックボックスを生成し、127.0.0.1:18347 で配信してブラウザーを開き、ユーザーの選択を待って %TEMP%\cleanup-selection-<ts>.json に書き込みます。ワークフロー A で使用します。Python 3 が必要です。
assets/apply-cleanup-selection.py	クリーンアップの選択を適用することが認められた唯一の方法です。選択 JSON から selected_items を読み取り、各項目の command を PowerShell 経由で実行します。Windows 向けに書き換えられた検証機能（NTFS の正規化、拒否／許可の最長プレフィックス判定、プロバイダー／UNC／ADS／8.3／コマンド連結の拒否、2 段階のラッパー）と操作ログを備えています。--dry-run に対応しています。
assets/test_validate_command.py	検証機能に対する敵対的なユニットテスト — 安全性の中核となるゲートです。どの OS でも実行できます。

実行する前に、関連するリファレンスを読んでください。これらのファイルの内容を記憶に頼って操作してはいけません。詳細は Windows 固有の障害モードに合わせて調整されており、小さな変更でも安全性が損なわれる可能性があります。

基本的な考え方

1. OS 標準のツールが安全性の最低ラインです。 macOS（Mole）とは異なり、Windows には成熟したコミュニティ製の安全ツールがありません。そのため、ストレージ センサー／クリーンアップの推奨事項／cleanmgr／DISM が主な役割を担い、適用スクリプトのバリデーターがプロジェクト成果物の削除を守る唯一の手段です。OS 自身が管理するものには、必ずサポートされているコマンドを使ってください。
2. フォルダーを削除せず、コマンドでクリーンアップします。 WinSxS → DISM、Driver Store → pnputil、シャドウ コピー → vssadmin、イベント ログ → wevtutil、hiberfil → powercfg を使ってください。これらを手動で削除すると、OS が破損します。
3. メモリの指標は「利用可能 MB」ではなくコミット率です。 Available MBytes には回収可能なスタンバイ／キャッシュが含まれます。Windows で実際にメモリ不足（OOM）を引き起こすのは、コミット上限の枯渇です。
4. 選択 JSON で変更を防止します。 HTML UI はユーザーが選択した内容をそのまま書き込み、apply-cleanup-selection.py は selected_items だけを削除します。適用フェーズで Remove-Item を手作業で組み立てないでください。
5. 段階的に慎重に進めます。 まずはリスクゼロの項目（ストレージ センサー、キャッシュ、ごみ箱）から始め、必要な場合にのみプロジェクト成果物、Docker／WSL VHDX、コンポーネント ストア、管理者権限が必要な項目や事前相談が必要な項目へ進んでください。

標準的なワークフロー

A. 「今すぐ空き容量を増やす」（インシデント対応）

1. トリアージ — references/triage.mdを読み、どのシグナルが発生したか、緊急度はどの程度かを特定します。事前インベントリ（ドライブ、コンポーネントストア、シャドウストレージ、ドライバー、CFA / OneDrive KFM / BitLocker / 再解析ポイント）を確認するため、assets/Audit-WinHealth.ps1を実行します（読み取り専用）。
2. ベースラインのスナップショット — 対象ドライブの空き容量（GB）を記録します。
3. 削除はまだ行わず、すべてのスキャンを実行する — references/cleanup-tiers.mdの各ティアをインベントリモードで確認します（候補、サイズ、経過日数を一覧表示）。大容量ファイルの可視化パスも含めます。ブラウザーを開く前にすべての情報を収集してください。削除は、ユーザーがUIで選択した後にのみ行います。クリーンアップUIは、個別のUIを何度も表示するのではなく、安全なクリーンアップ候補、保護対象／相談してから決める項目、大容量の疑わしいユーザーファイル／ワークロードファイルをまとめた、最後の質問票を1つだけ表示してください。
4. Pythonの確認 — クリーンアップUIにはPython 3が必要です。実際のインタープリターがあるか確認します（py -3 --version、またはMicrosoft Storeのエイリアスではないpython.exe）。Pythonがない場合は、インストールの許可をユーザーに求めてください（winget install Python.Python.3.12）。その後、続行します。UIを黙って省略してはいけません。
5. JSONを作成する前に不明な項目を解決する — 500 MBを超える候補のうち、1文で説明できないもの（見慣れないアプリ／フォルダー、ベンダーのキャッシュ、VM/VHDX、モデルの重み）は、まず調査してください。references/never-touch.mdを確認してから、web-searcherサブエージェントに簡単な検索を依頼します（「Windows 11で<path>は何か、2026年時点で安全に削除できるか」）。項目に具体的なdescription（ユーザーの言語で1～3文）を記入してください。「不明」のような曖昧なプレースホルダーは絶対に表示しないでください。
6. 安全に削除できない大容量項目も表示する — 説明可能な項目のうち、500 MBを超え、ユーザー所有またはワークロード所有で、安全なキャッシュではないものも、通常はprotected: true、default_selected: false、具体的なwarningを付けて、同じ最後のUIに表示する必要があります。例：古い.7z/.zip/.isoアーカイブ、.gguf/.safetensorsモデルの重み、プロジェクト／ゲームのアセット、アプリの診断ダンプ、プロファイラーのスナップショット、同期フォルダー内のメディア、VHDXファイル。引き続き必要かどうかを判断できるのはユーザーだけなので、表示する必要があります。ハード保護対象のシステム内部ファイルを、そのまま削除候補として含めてはいけません。対応するツールを通じてのみ表示するか、対応する操作がない場合は削除対象から完全に除外してください。
7. データJSONを1つ作成する — 各候補を構造化されたitemにします（id、label、path、size_bytes、age_days、kind、PowerShellのcommand、必須のdescription、任意のprotected＋warning）。assets/render-cleanup-plan.pyのスキーマを使用してください。取り消し不能なツールのコマンド（DISM /ResetBase、vssadmin delete、wevtutil cl、pnputil /delete-driver、powercfg /h off）にはprotected: trueを付けます。安全でデフォルト選択される項目と、保護されて未選択の項目の両方を、この統合JSONに含めるまでUIを開かないでください。
8. クリーンアップUIをレンダリングして開く：

   python3 <skill>\assets\render-cleanup-plan.py %TEMP%\cleanup-data-<ts>.json
   

   127.0.0.1:18347でサービスを起動し、ブラウザーを開き、SubmitまたはCancelが押されるまで処理をブロックします。送信すると、%TEMP%\cleanup-selection-<ts>.jsonに書き込みます。ユーザーに口頭で「ブラウザーを開きました。チェックを入れてSubmitを押してから、私に連絡してください」と伝えてください。その後、停止して待ちます。
9. ユーザーから連絡があった後 — 選択JSONを読み込み、選択内容（カテゴリ、項目一覧、合計GB、保護対象の上書きがあればそのフラグ）をチャットでユーザーに提示し、削除前に明確な確認を1回だけ求めます。
10. ヘルパー経由で適用する — 手作業のRemove-Itemは絶対に使わない：

python3 <skill>\assets\apply-cleanup-selection.py %TEMP%\cleanup-selection-<ts>.json
#   add --scan-root D:\projects to allow bare deletes on an external dev drive

selected_itemsを読み込み、各commandを検証します（NTFSの正規化、最長プレフィックスの拒否／許可、プロバイダー／UNC／ADS／8.3／コマンド連結の拒否）。protected_overridesに含まれない保護対象の項目はスキップし、各コマンドをpowershell.exe経由で実行して、%LOCALAPPDATA%\win-health\operations.logに記録します。--dry-runで事前確認できます。選択JSONを唯一の信頼できる情報源とします。 11. 実行後の確認 — 空き容量の増加量を報告し、続けてDism /Online /Cleanup-Image /CheckHealthとsfc /scannowを実行して、問題が発生していないことを確認します。目標に達したら終了します。 references/never-touch.mdに従って厳重に保護されている項目は、必ずUIに"protected": trueと具体的なwarningを表示する必要があります。UIでは表示が薄くなり、チェックするには項目ごとの確認が求められます。ユーザーデータが依存している保護対象項目を非表示にしないでください。表示することで、関連するリスクを認識してもらえます。

B.「アラートを設定する」（新しいマシン、または初回）

アラートを受け取るユーザーとして、昇格していないPowerShellを実行してください（トースト通知には対話型セッションが必要です）。

cd <skill>\assets
.\Install-WinHealthCheck.ps1     # installs BurntToast, copies script+config, registers the task, runs once

調整方法については、references/alerting.mdを参照してください。タスクは対話型ユーザーセッションに登録されます（SYSTEMではありません。SYSTEMではトースト通知が通知なく無視されます）。5分ごとに実行され、-StartWhenAvailableが指定され、バッテリーに配慮した設定になっています。最初の7日間の調整期間中は通知を表示せず、ログのみ記録します。.\Install-WinHealthCheck.ps1 -Testで確認してください。

C. アラートが機能しなくなった／音が鳴る

references/alerting.mdの「トラブルシューティング」を参照してください。よくある原因は次のとおりです。

• タスクがSYSTEMとして実行されている／「ユーザーがログオンしているかどうかにかかわらず実行する」設定になっている → トースト通知が表示されません。インストーラーを再実行してください（対話型のプリンシパルを使用）。
• BurntToastがインストールされていない → トースト通知の送信元が「PowerShell」になるか、通知が表示されません。Install-Module BurntToast -Scope CurrentUserを実行してください。
• ノートPCでチェックが実行されない → AC電源接続時のみ動作する設定だったか、スリープ中に一時停止されていました。インストーラーを再実行してください（バッテリー関連のフラグと-StartWhenAvailableを指定）。
• 負荷の高い作業中にアラートが頻発する → %LOCALAPPDATA%\win-health\silentを作成するか、しきい値を上げるか、ヒステリシスを大きくしてください。

D.「アプリをきれいにアンインストールする」

winget uninstall --id <App.Id>を優先してください（クリーンで、サポートされています）。頑固な残留物があるアプリには、BCUninstallerが開発者向けの使いやすい選択肢です（残留物の一覧を確認してください）。アプリを「削除」するために、Program Filesのインストールディレクトリやレジストリキーを手動で削除しないでください。MSI／アンインストールの状態が不整合になります。ユーザーデータのフォルダーを削除する前には、必ず確認してください。

安全ルール（必須）

1. レベル5以上の項目、または昇格が必要な操作については、ドライランとユーザーの確認なしに削除しないでください。
2. references/never-touch.mdを決して回避しないでください — ユーザーが明示的に依頼した場合も同様です。断り、その結果を説明してください。
3. フォルダーではなくコマンドでクリーンアップしてください。 WinSxSにはDISM、Driver Storeにはpnputil、シャドウコピーにはvssadmin、ログにはwevtutil（消去前にエクスポート）、hiberfilにはpowercfgを使用してください。これらにRemove-Itemを使用しないでください。
4. レジストリをクリーンアップ対象にしないでください。 レジストリクリーナーは使用しないでください（Microsoftのサポート対象外です）。バリデーターはレジストリプロバイダーからの削除を拒否します。
5. 適用フェーズでは選択JSONのみを読み取ってください。 適用時にRemove-Itemを手作業で組み立てたり、前段階のスキャン結果からパスをハードコードしたりしないでください。これをすると、ユーザーがチェックを外した項目まで削除してしまいます。assets/apply-cleanup-selection.pyを使用してください。このスクリプトはselected_itemsのみを処理します。
6. Remove-Itemによる削除は元に戻せません（ごみ箱には入りません）。また、再帰的な削除はジャンクションを経由して想定外の場所に及ぶことがあります。常に-LiteralPathを使用し、再解析ポイントを再帰処理しないでください。ユーザーが判断に迷っている場合は、隔離先への移動を優先してください。
7. アラートに連動した自動クリーンアップは禁止です。 アラートは通知するだけにし、判断は人間に委ねてください。
8. クラッシュダンプは調査が終わるまで保持してください — これはクリーンアップ対象ではなく、フォレンジック上の証拠です。

ドメイン固有の注意点

• SYSTEM セッションではトーストを表示できません。 SYSTEM としてスケジュールされたタスクは実行されますが、トーストは何も表示されずに無視されます（Session 0 にはデスクトップがありません）。タスクは対話型ユーザーセッションに登録してください。これは macOS の「osascript → Script Editor」の落とし穴に相当する Windows の問題です。
• Remove-Item -Recurse はジャンクションをたどり、リンク先の内容を削除する可能性があります。これはよくあるデータ損失の原因です。開発ツリーにはジャンクションが数多くあります（npm/pnpm ストア、Docker、WSL）。-LiteralPath を使用し、FILE_ATTRIBUTE_REPARSE_POINT を持つ項目を再帰処理しないでください。
• Remove-Item はごみ箱を経由しません。 ごみ箱にドラッグする場合とは異なり、削除は即時かつ恒久的です。
• OneDrive KFM は Desktop/Documents/Pictures を OneDrive にリダイレクトします。そこで削除すると、すべてのデバイスに反映されます。Files On-Demand のプレースホルダー（RECALL_ON_DATA_ACCESS/OFFLINE）はクラウド上のオリジナルです。スタブを削除すると、クラウド上のファイルも削除されます。
• Controlled Folder Access は Documents/Pictures/Desktop 内の削除をブロックし、Defender による Access Denied を返します。これを実際のエラーと区別してください。
• Available MBytes にはスタンバイ／キャッシュも含まれます。 「available」の値が高くても、健全な状態とは限りません。実際の OOM の兆候はコミット制限の枯渇です。
• pagefile.sys と swapfile.sys は別々のファイルです。 C:\Windows\Installer と Package Cache を削除すると MSI の修復に支障が生じます。Prefetch はクリーンアップしないでください（これは誤解です）。
• Modern Standby（S0ix） ではウェイクタイマーが不安定になり、S3 が表示されなくなります。これは正常であり、障害ではありません。タスクはスリープ中に一時停止し、-StartWhenAvailable により復帰後に処理を再開します。
• 一般則：フォルダーの内容を一文で説明できない場合（特に 500 MB を超える場合）は、推測で説明を書かず、項目の description を記述する前に web-searcher による検索を依頼してください。説明できてもユーザーデータの可能性がある場合は、最終的なクリーンアップ UI に保護対象として表示し、デフォルトではチェックを外しておいてください。

効果の目安

AI／Docker／WSL の負荷が高く、空き容量が約 8％まで減少した開発マシンでの代表的な復旧例です。

• 最大の単独要因：Tier 7 のパージによるプロジェクトのビルド成果物（node_modules、bin/obj、target、.next）。
• WSL2／Docker の *.vhdx の圧縮（削除ではありません）：10～40 GB を回復できることがよくあります。
• 累積更新プログラムを多数適用した後の DISM によるコンポーネントストアのクリーンアップ：数 GB。
• パッケージマネージャーのキャッシュ（npm/pnpm/NuGet/pip/cargo/gradle）：数 GB。
• Downloads の確認（古いインストーラー、ISO）：状況によりますが、多くの場合 10～20 GB。
• 昇格されたティア（ロールバック確認後の Windows.old、Delivery Optimization、エクスポート後に消去したログ）：状況によります。

7 日間の調整期間を設けてアクティブなアラート機能をインストールし、稼働開始前に合成ディスクトリガーテストで動作を確認しました。数値はワークロードとディスク容量によって異なります。軽い使い方では回復量が少なく、AI／Docker／WSL／IDE を多用するユーザーでは多くなります。