WinMedic は何をしますか?
目標
ホスト Agent を推論層、ローカルの PowerShell と内蔵エンジンを実行層として使用します。まず証拠で原因を特定し、最小限の修復を提案、確認後に実行し検証します。
本 Skill は単独のモデルを起動せず、インターネットに接続せず、テレメトリを収集しません。常にホストの権限と承認メカニズムに従います。
実行前チェック
- プラットフォームが Windows、Shell が PowerShell、現在管理者権限かどうかを確認します。ユーザーの説明から推測しないでください。
- 作用範囲がローカルマシンであることを確認します。ユーザーが指定した保留項目(「WeChat を触らない」「D ドライブを消さない」など)は制約として書き留め、常に遵守します。
engine\winmedic.ps1 doctorを実行し、権限/PS バージョン/WizTree の可用性を取得します。- ホストにローカル実行能力がない場合(チャットのみ)、「手動手順 + 検証ポイント」モードで出力し、実行を偽装しません。
強制ワークフロー
1. 目標明確化
- 症状、期待状態、変更不可な制約に分解します。
- 複数の目標はそのまま保持し、削除で移行を代替したり、再インストールで修復を代替したりしないでください。
- 曖昧さが経路を大幅に変える場合のみ質問します。
2. Playbook のルーティング
- playbook-index.md を読み、症状に基づいて最も具体的なものを選択します。
- 必要なものだけ
playbooks/*.mdを読み込み、一度に全部読み込まないでください。 - 複数の独立した問題がある場合、「影響範囲 × 依存順序」で1つずつ処理します。
3. 読み取り専用診断
winmedic.ps1 probe --set <domain> # 出力: state\findings.json
- プローブは読み取り専用です。どのステップでも書き込み操作が発生したらバグです。即座に停止し報告してください。
- 取得できない項目は「取得不可」と正直に記載し、推測しないでください。
4. 計画の生成
winmedic.ps1 plan --from state\findings.json
出力: plan.json + plan.md + planHash。plan.md の原文をユーザーに提示し、自分で要約して曖昧な説明にしないでください。
plan.md には2つのセクションが含まれます:
- 推奨(優先順位順) — ドメイン横断的な処置の推奨。
highが優先(再起動待ち、復元ポイントなし、セキュリティリスク、ディスク緊急)処置列に実行可能: <action>とあるものは、直接winmedic.ps1 apply --action <action> --yesを実行可能手動: <playbook>とあるものは、その playbook に従って1つずつ処置し、自分で手順を考案しないでください
- 明細 — エンジンが実行可能なクリーンアップ項目(id で実行)
推奨セクションのソースは決定論的なルール(モデルの推測ではない)であり、証拠は playbook または catalog 証拠エントリにリンクしています。
5. 確認
- 項目ごとに: アクション、影響量、リスクレベル、ロールバック可否を列挙。
- ユーザーが承認した id のみ実行します。 ユーザーが「何でもいい」と言った場合、デフォルトで Tier 1 + Tier 2 のみ実行します。
- Tier 3 は項目ごとに確認が必要です。Tier 4 は一切実行しません。
6. 実行
winmedic.ps1 apply --plan state\plan.json --ids R1,R3 --yes
- デフォルトで隔離領域に入ります(ソフトデリート)。
--purgeを軽率に付けないでください。 - 部分失敗(終了コード 7)の場合、journal を確認してから続行するか判断します。
7. 検証
winmedic.ps1 verify --journal <id>
- 空き容量、サービス状態、ターゲットが消えたかどうかを確認します。
pendingReboot = trueの場合、ユーザーに「再起動後に完全に有効になります」と明確に伝え、成功したと偽らないでください。
8. 報告
固定の5セクション: 現状 → 何を見つけたか → 何をしたか → 検証結果 → 何をしなかったか(およびその理由)
アクション階層
| Tier | 意味 | 実行要件 |
|---|---|---|
| 1 | リスクゼロ、削除してもシステムは動作 | 確認のみ |
| 2 | キャッシュ、再構築される | 再構築のコストを説明 |
| 3 | 判断が必要、機能に影響する可能性あり | 項目ごとに確認 + 証拠提示 |
| 4 | レッドライン | 実行を拒否、理由を説明し手動の手順を提示 |
画面1つの健康診断と比較
winmedic.ps1 probe --set intake # ドメイン横断読み取り専用収集(約60〜90秒)
winmedic.ps1 summary # 9ドメイン画面1つのサマリー、OK/WARN/BAD
winmedic.ps1 diff --from a.json --to b.json # 2回の収集を比較
summary で未収集のドメインは [?] 未収集 と表示されます。これに基づいて結論を下さず、先に収集を補完してください。
サマリーの末尾には「推奨」(優先順位順)が直接リストされ、plan の推奨セクションと同じソースです。機械可読にするには --json を追加してリダイレクトします:
winmedic.ps1 summary --json > status.json
特定のソフトウェア(ワークロードドメイン)
ユーザーが特定のソフトウェアを指定した場合(LaTeX、PyCharm、Steam、Zotero、Word、プロキシツール…)、最初に以下を実行:
winmedic.ps1 probe --set workloads
これは catalog/workloads.json のシグネチャテーブルに従い、各ソフトウェアのキャッシュとデータのサイズを測定し、プロキシチェーンの一貫性をチェックします。
重要な区別:
kind=cache(シェーダーキャッシュ、IDE インデックス、texmf-var、OfficeFileCache)→ クリーンアップ可能、コストは再構築kind=data(ゲーム本体、Zotero 添付ファイル、WeChat チャット履歴、texmf-dist)→ 絶対に削除しない、移行のみkind=review(Tencent Video ダウンロード、混合ディレクトリ)→ 事前確認必須、ユーザーが自らダウンロードしたコンテンツが含まれる可能性ありprobe.proxy-chainは system/WinHTTP/git/npm/pip の5層のプロキシ値をリスト、consistent=falseは競合
新しいソフトウェアを追加するのにコード変更は不要: catalog/workloads.json にシグネチャ(detect + measure + playbook)を1行追加するだけです。
移行判断(ユーザーが「キャッシュ/ソフトウェアを別のドライブに移動」「C ドライブに新しいソフトウェアをインストールできない」と言った場合)
これは判断問題であり、参照問題ではありません。エンジンは事実のみを提供し、計画はあなたが決定しますが、チェックリストを完了する必要があります。
winmedic.ps1 relocate # ディスク概要 + 判断チェックリスト + 事実テーブル + デフォルト推奨
winmedic.ps1 relocate --json # 同上、構造化
出力は3つのセクションで構成され、意味が異なります。混同しないでください:
| セクション | 意味 | 使用方法 |
|---|---|---|
| 判断チェックリスト | 答えるべき3つの質問 | 回答で各質問に結論を出す必要があり、スキップ不可 |
| 事実 | パス/サイズ/メディア/存在/既知のフォルダ/ソフトウェア宣言パス | 判断の根拠 |
| デフォルト推奨 | エンジンのデフォルト視点(policySource=default-hint) | 参考のみ、あなたの判断で覆せる;結論としてそのまま伝えないこと |
3つのチェックリスト質問(回答時に明示的にカバーすること)
- 既知のフォルダ配下か? はい → そのフォルダを1回移動し、個々のソフトウェアにパスを設定しない;ただし、まず以下の第3条を判断
- ホットデータかコールドデータか? ホット(リアルタイムレンダリングキャッシュ、IDE インデックス、ストリーミングキャッシュ)→ 最速のドライブに残す;コールド(ゲーム/VM/ライブラリ/チャット履歴)→ 容量ドライブへの移動を検討
- ソフトウェアは既に絶対パスを記録しているか(インストール後に移動するケース)? はい → 移動後、ソフトウェア内の設定を同期して変更しないと、古いパスを参照する
あなた(DSH)がやるべきこと
- 事実テーブルの
メディアを最初に確認: ホットデータを HDD に移動するのは間違い。たとえ HDD のほうが大きくても ソフトウェア宣言パスを最初に確認: これは「インストール後に移動」の決定的な証拠- 計画は「何をする → なぜ → リスク → 検証方法」の形式で記述し、ユーザーが確認してから実行させること
- エンジンは代わりに移行しません;あなたの役割は理由付きの計画を提示すること
詳細は playbook apps-relocate-cache(PB-913)参照。
経過(誰が増えているか、だけでなく誰が最大か)
winmedic.ps1 trend --record # スナップショットを記録(1日1回推奨)
winmedic.ps1 trend --days 14 # 変化とレートを確認
判断ルール:
confidence=insufficient(<2 サンプル)→ 結論を下してはいけない、まず記録confidence=low(間隔 <0.5日)→ 変化量のみを見る。日次レートなしconfidence=ok→ 「1日 X GB 増加」と言える
用途: C ドライブが満杯のとき、まずトレンドを確認し、それからキャッシュをクリアするか、特定のソフトウェアがログを大量に書き込んでいるかを調査するかを判断。
鑑別診断(C ドライブ満杯 / ネットワーク異常など「原因追究が必要」なシナリオ)
winmedic.ps1 diagnose --list
winmedic.ps1 diagnose --case dx.cdisk-full
出力は事実テーブル(仮説 × 指標 × 現在値 × 判定シグナル × データソース)。結論は含まれません。
必須: 各項目を判断し、どの仮説が除外され、どの仮説が支持されたかを説明し、その後に計画を提示。
source に trend が含まれるものは変化量;low のものはレートを計算できない;insufficient のものは値なし。
外部ツールが必要な場合は、まずツールキャビネットを確認: winmedic.ps1 tools(検出のみ、Tier≥3 の自動実行はしない)。
症例ライブラリ(経験の蓄積)
cases/ には7セクション形式の症例: 症状 / 環境 / 収集 / 仮説と除外 / 処置 / 結果 / 教訓
- 同じ問題に遭遇したら症例を先に検索、丸ごと1ラウンドの調査を節約可能
- 新しい問題を解決したら
cases/_template.mdに従って1件記録。そうしないと次回また最初からやり直し pendingマークは現場証拠なしの調査待ち項目、結論として引用してはいけない
証拠照会
どのアクション実行前でも、ユーザーが「なぜ」「根拠は」と尋ねたら、直接検索:
winmedic.ps1 explain --action storage.winsxs-cleanup
出力: レベル、ロールバック可否、コマンド、注意事項、証拠原文と公式リンク、確認日、検証ルール
リスクゲート
apply は復元能力(復元ポイント/ボリュームシャドウコピー)をチェック:
- ターゲットに Tier 3(ロールバック不可)が含まれ、復元能力が ready でない → 実行を拒否、リターンコード 4
- この場合の正しい対処: 最初に
apply --action recovery.create-restore-point --yesで復元ポイントを作成、またはユーザーに明示的に--accept-riskを追加させる - タスクを進めるために勝手に
--accept-riskを追加しないこと
ユーザー保留項目(ハード制約)
ユーザーが「WeChat を触らない」「D ドライブに触らない」と言った場合、すぐに保留項目として固定化し、頭の中だけで覚えないこと:
winmedic.ps1 profile --exclude "C:\Users\<user>\Documents\WeChat Files"
winmedic.ps1 profile --exclude "D:\*"
winmedic.ps1 profile # 現在の保留項目を表示
winmedic.ps1 profile --exclude "..." --remove # 削除
保留項目は二重のインターセプト: plan フェーズで除外、apply フェーズで再度拒否して記録。
いつ手を止めるべきか
- ターゲットが
Windows\WinSxS内のファイル、Windows\Installer、System32、WindowsApps - ターゲットがチャット履歴ディレクトリ(
WeChat Files/xwechat_files)またはユーザー宣言の保留項目 - 残り1〜2個のシステム復元ポイントで、削除を要求された場合
- コミット量が上限に近い状態でページファイルの縮小を要求された場合
- ユーザーが「全部削除」「リスクを気にしない」と要求した場合 — まず説明し、その後 Tier 1/2 のみ実行
エンジン呼び出し規約
ホストが MCP 経由でのみツールにアクセスできる場合、
engine\mcp\winmedic-mcp.ps1を使用(docs/MCP.md 参照); ツールパラメータは以下のコマンドと1対1対応、ツールはyes=trueが必要。その他のルールは完全に同じ。
- すべてのサブコマンドは
--jsonをサポート。--jsonなしの場合は人間可読なサマリーを出力。 - 終了コード: 0 成功 / 2 使用方法 / 3 権限 / 4 前提条件未通過 / 5 plan 無効 / 6 レッドライン / 7 部分失敗
- エンジンをバイパスして直接削除コマンドを実行しないでください。 エンジンの価値はハッシュバインディング、隔離領域、監査ログです。
レポート生成
winmedic.ps1 report --journal <runId> # 5セクション形式の納品レポート
winmedic.ps1 report --set storage --out report.md
レポートは固定5セクション: 現状 → 何を見つけたか → 何をしたか → 検証結果 → 何をしなかったか(およびその理由) データがない場合は正直に「未収集」と書き、捏造しない。
レポートテンプレート
## 現状
C: 98.7 GB、空き 16.7 GB(83%)
## 何を見つけたか
| 項目 | サイズ | レベル | 根拠 |
| ごみ箱 | 7.03 GB | 1 | 影響なし |
| hiberfil.sys | 6.32 GB | 1 | マイクロソフト文書: powercfg /h off |
## 何をしたか
R1 ごみ箱を空にする: 7.03 GB -> 0
R2 休止状態を無効化: 6.32 GB 解放
## 検証結果
C: 空き 16.7 -> 30.1 GB;スリープ S0 正常;pendingReboot なし
## 何をしなかったか
SoftwareDistribution(ユーザーがスキップを要求)、Windows\Installer(高リスク、専用ツール推奨)