PowerShellでDISM /Online /Cleanup-Image /RestoreHealthを実行しても％が表示されず、止まったように見えることがあります。CheckHealthはrepairableなのにSFCも進まない――そんな時は「本当に止まっているかの見極め」と「修復ソース指定」が鍵です。現場で再現性の高い手順をまとめます。
よくある症状：DISMの進捗が出ない／SFCが終わらない
Windowsの不調（更新失敗、アプリが落ちる、設定が開かない、ブルースクリーンが増えた等）をきっかけに、PowerShellでDISM /Online /Cleanup-Image /RestoreHealthを実行したものの、ロード画面や％表示が出ず「固まった？」と不安になるケースがあります。さらにDISM /Online /Cleanup-Image /CheckHealthでは「修復可能（repairable）」と出るのに、sfc /scannowも進まない・途中で止まるという組み合わせは現場でも頻出です。
この状態で大切なのは、闇雲に再起動や初期化に走る前に、DISMが“止まって見えるだけ”なのか、本当に失敗しているのかを切り分け、必要ならWindows Updateに依存しない修復ソース（インストールメディア等）を明示して実行することです。
DISMとSFCの役割を整理すると解決が早い
DISMとSFCは似た「修復コマンド」に見えますが、直す対象が違います。両者の関係を理解すると、やる順番や“詰まる理由”が見えてきます。
| コマンド | 主に触る場所 | 目的 | 進捗が出にくい場面 |
|---|---|---|---|
DISM /Online /Cleanup-Image /CheckHealth | コンポーネントストア（WinSxS） | 破損の有無と「修復可能か」をざっくり判定 | 短時間で終わることが多い |
DISM /Online /Cleanup-Image /ScanHealth | コンポーネントストア（WinSxS） | 破損を詳細にスキャン（時間がかかる） | ディスクI/Oが多い、％が止まって見える |
DISM /Online /Cleanup-Image /RestoreHealth | コンポーネントストア（WinSxS） | 破損の修復（Windows Updateまたは修復ソースを使用） | ネットワーク/WSUS/ソース不一致で停滞・失敗 |
sfc /scannow | システムファイル（OS本体） | 壊れたシステムファイルを置き換え | 修復元のコンポーネントストアが壊れていると修復できない |
ポイントは、SFCは「部品箱（コンポーネントストア）」を参照して修復するため、その部品箱が壊れているとSFCがうまく動かないことがある点です。だからこそ、典型的な順番は「DISMでコンポーネントストア修復 → SFCでシステムファイル修復」になります。
まず“待つべき”ケース：止まって見えるだけの可能性
DISMは環境によっては数時間かかります。特に以下の条件が重なると、％表示が長時間変わらず「フリーズしたように見える」ことがあります。
- HDD（SSDより遅い）／空き容量が少ない
- CPUが低速、またはバックグラウンドで別の重い処理が動いている
- Windows Updateの保留や、更新履歴が大量にある
- 破損箇所が多く、修復に必要なファイルの取得や検証が長い
- ウイルス対策ソフトがリアルタイムで検査してI/Oが詰まっている
体感としては「20%付近」「40%付近」「62.3%付近」など、特定のところで止まったように見える相談が多いです（実際は内部処理が長いだけのことがあります）。
作業前に確認したいチェックリスト（詰まりを減らす）
「コマンドは合っているのに永遠に進まない」ケースは、環境要因が原因になっていることがあります。実行前に以下を軽く整えるだけで完走率が上がります。
| 項目 | 確認/推奨 | 理由 |
|---|---|---|
| 管理者権限 | PowerShell/コマンドプロンプトを「管理者として実行」 | 権限不足だと途中で失敗、または修復が動かない |
| 電源 | ノートはAC接続、スリープを一時的にOFF | 長時間処理の中断を防ぐ |
| 空き容量 | 可能ならシステムドライブに十分な空き（余裕があるほど良い） | 展開・検証・ログで一時領域を使う |
| 重い常駐 | 負荷の高い作業を止める（大規模コピー/ゲーム/VMなど） | I/Oが詰まると「止まって見える」時間が増える |
| ネットワーク | 標準のRestoreHealthで詰まる環境は最初からソース指定 | Windows Update経由の取得待ちを避ける |
進捗が出ないときに“本当に止まっているか”を見極める方法
むやみに中断すると状態が悪化することがあります。次のチェックで、動いているかを判断します。
| 確認ポイント | 見る場所 | 動いているサイン | 止まっている疑い |
|---|---|---|---|
| CPU/ディスクの動き | タスクマネージャー / リソースモニター | dism.exeがCPUやディスクを断続的に使用 | 長時間まったく使用しない |
| ログが増えているか | C:\Windows\Logs\DISM\dism.log | ファイルサイズや更新時刻が動く | 更新が止まり、同じエラーがループ |
| Windows Update関連の待ち | サービス（wuauserv, BITS） | 通信やサービスが稼働している | 停止/無効化、WSUSで遮断 |
| 画面表示だけの問題 | PowerShell / Windows Terminal | 見た目は静かでも内部は進む | 別コンソールで実行すると％が出ることも |
見極めのコツとして、PowerShellで表示が静かな場合は、同じコマンドを「管理者として実行したコマンドプロンプト（cmd.exe）」で実行し直すと、％表示が出て安心できるケースがあります。PowerShellでも問題ないのですが、表示の相性で「進捗が見えない」だけのことがあります。
まずやる基本フロー（現場で事故が少ない順番）
「repairable」と出ているなら、次の順番が失敗しにくいです。
- PCを再起動（保留中の更新やロックを解消）
- 管理者権限でコマンド実行（PowerShell/コマンドプロンプトどちらでも可）
DISM /Online /Cleanup-Image /ScanHealthで状態確認（時間がかかっても中断しない）DISM /Online /Cleanup-Image /RestoreHealthを実行- DISMが完走したら
sfc /scannowで仕上げ
ただし、企業ネットワークやオフライン環境、Windows Updateが壊れている環境では、/RestoreHealthがWindows Update経由の取得で詰まりやすいです。その場合は次の「修復ソース指定」が最短ルートになります。
最重要：Windows Updateに頼らず修復する（/Source と /LimitAccess）
DISM /Online /Cleanup-Image /RestoreHealthは、標準だと不足する修復ファイルをWindows Updateから取りに行くことがあります。ここが詰まると、進捗が出ない・長時間待ち・エラーで失敗になりがちです。
そこで、インストールメディア（ISO）や社内配布メディアなどの修復ソースを明示し、さらにWindows Updateへアクセスしないように指定します。
/Source指定の基本例（質問に近い形）
ISOをマウントして取り出したイメージをC:\test\mountにマウントしている前提なら、次のように実行します。
Dism /Online /Cleanup-Image /RestoreHealth /Source:C:\test\mount\Windows /LimitAccess/LimitAccessを付けることで、Windows UpdateやWSUSに依存せず、指定ソースからの修復に集中できます。
修復ソースの用意：ISOから install.wim / install.esd を確認する
一般的なWindows 10/11のISOには、sourcesフォルダ配下にinstall.wimまたはinstall.esdが入っています。どちらが入っているかで指定方法が少し変わります。
- ISOをダブルクリックでマウント（例：ドライブレターが
D:になる） D:\sources\install.wimまたはD:\sources\install.esdを確認
エディション/ビルド不一致を防ぐ（ここで詰まる人が多い）
修復ソースは「同じWindowsの系統」であることが重要です。大雑把に言うと、次が一致しているほど成功率が上がります。
- Windows 10 / Windows 11 の別（できれば同一）
- Home/Pro/Enterprise などエディション（WIM内のインデックス選択で合わせる）
- 32bit/64bit（ほぼ64bitですが一致必須）
- 可能なら同じ言語
「CheckHealthはrepairableなのにRestoreHealthが進まない」ケースの一部は、ソース側が違う（別バージョン、別エディション、別アーキテクチャ）ことが原因です。
実務で使う /Source の書き方パターン（表で整理）
/Sourceは指定方法がいくつかあります。環境に合わせて選ぶと迷いません。
| パターン | /Sourceの例 | メリット | 注意点 |
|---|---|---|---|
| マウントしたイメージのWindowsフォルダを指定 | /Source:C:\test\mount\Windows | 分かりやすい。質問の状況に近い | WIMのマウント作業が必要 |
| WIMを直接指定（インデックスあり） | /Source:wim:D:\sources\install.wim:1 | マウント不要で手軽 | インデックス番号を間違えると失敗 |
| ESDを直接指定（インデックスあり） | /Source:esd:D:\sources\install.esd:1 | 最近のISOで多いESDに対応 | 環境によってはWIMより遅いことがある |
| 複数ソース（フォルダ）を指定 | /Source:C:\src1;C:\src2 | 複数候補がある時に便利 | 実務ではまず単一ソースで十分 |
インデックス番号の調べ方（install.wim / install.esd）
WIM/ESDには複数のWindowsエディションが入っていることがあります。インデックスが合わないと、修復が進まない／失敗しやすくなります。まずはインデックスを確認します。
Dism /Get-WimInfo /WimFile:D:\sources\install.wimESDの場合は次のようにします。
Dism /Get-WimInfo /WimFile:D:\sources\install.esd表示された一覧から、自分の環境（Home/Pro/Enterpriseなど）に一致するもののインデックスを選び、:1の部分に指定します。
推奨の実行例：ソース指定でRestoreHealthを完走させる
ここからは、失敗しにくい「実行例」をまとめます。すべて管理者権限で実行してください。
WIMを直接指定する（マウント不要）
Dism /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:1 /LimitAccessESDを直接指定する（ISOがinstall.esdの場合）
Dism /Online /Cleanup-Image /RestoreHealth /Source:esd:D:\sources\install.esd:1 /LimitAccessWIMをマウントしてWindowsフォルダを指定する（質問の例に近い）
まずマウント用フォルダを作り、WIMをマウントします。
mkdir C:\test\mount
Dism /Mount-Image /ImageFile:D:\sources\install.wim /Index:1 /MountDir:C:\test\mount /ReadOnly次に修復を実行します。
Dism /Online /Cleanup-Image /RestoreHealth /Source:C:\test\mount\Windows /LimitAccess終わったらマウント解除します（読み取り専用でも解除は必要です）。
Dism /Unmount-Image /MountDir:C:\test\mount /DiscardDISMが進まない・失敗する代表パターンと対処（エラー別）
「進捗が出ない」だけでなく、しばらく待ってエラーで終了する場合もあります。代表例を表にまとめます。
| 症状 / エラー例 | よくある原因 | 現実的な対処 |
|---|---|---|
| 0x800f081f（ソースが見つからない） | ソース不一致、インデックス違い、パス間違い | ISOを同一バージョンで用意し直す／/Get-WimInfoでインデックス確認／/Source:wim:...:indexで再実行 |
| 0x800f0906（必要ファイルをダウンロードできない） | ネットワーク制限、WSUS、プロキシ、Windows Update不調 | /Sourceと/LimitAccessを付けてローカル修復に切り替える |
| 進捗が極端に遅い（数時間動かないように見える） | HDD/空き容量不足/ウイルス対策でI/O詰まり | 空き容量確保（目安：数十GB）／一時的に重い常駐を停止／AC接続で放置 |
| エラーは出ないがSFCが直らない | DISMが完走していない、または修復が不完全 | まずDISM完走→再起動→sfc /scannowを再実行 |
DISM完走後にやること：SFCでシステムファイル修復を仕上げる
DISMが通ったら、次はSFCです。SFCの結果は、トラブルが解消したかの判断材料にもなります。
sfc /scannow| SFCの代表メッセージ | 意味 | 次にやること |
|---|---|---|
| 整合性違反は見つかりませんでした | システムファイルは正常 | 不調が残るならアプリ/ドライバ/更新履歴を疑う |
| 破損ファイルを検出し修復しました | 修復完了 | 再起動して症状確認（必要ならもう一度SFC） |
| 破損ファイルがありましたが修復できませんでした | 修復元が不足、または別要因 | DISMをソース指定で再実行→再度SFC／ログ確認 |
SFCが「うまく動作しない」時のチェック（途中で止まる/開始できない）
質問のようにSFC自体が進まない場合、次の原因が多いです。
管理者権限で実行しているか
SFCは管理者権限が必須です。Windows TerminalやPowerShellを「管理者として実行」してから再試行してください。
Windows Modules Installer（TrustedInstaller）が止まっていないか
SFCの修復処理は内部でサービスを使います。サービスが無効化されていると修復が始まらないことがあります。次のコマンドで状態確認と起動を試します。
sc query trustedinstaller
sc config trustedinstaller start= demand
net start trustedinstaller社内PCでサービスが制限されている場合は、管理部門のポリシーを優先してください。
オフラインでSFCをかける（Windowsが不安定なとき）
Windowsの起動自体が怪しい、ログオン後すぐ落ちる、SFCが毎回止まる場合は、Windows回復環境（WinRE）からオフラインスキャンすると通ることがあります。
回復環境のコマンドプロンプトで、Windowsのドライブ文字を確認したうえで実行します（例ではWindowsがC:にある想定）。
sfc /scannow /offbootdir=C:\ /offwindir=C:\Windowsログを見れば「どこで詰まっているか」が分かる
長時間待っても改善しないときは、ログを見ると原因が見えます。最低限、次の2つのログは押さえておくと役に立ちます。
| ログ | 場所 | 見るポイント |
|---|---|---|
| DISMログ | C:\Windows\Logs\DISM\dism.log | “Source files could not be found”やエラーコードの有無 |
| CBSログ（SFC関連） | C:\Windows\Logs\CBS\CBS.log | SFCが修復できない対象、アクセス拒否、破損箇所 |
ログはサイズが大きいことがあるので、トラブル発生時刻付近を中心に確認すると効率的です。
それでも直らない場合に選ぶ現実的な手段
DISMをソース指定で通してもSFCが改善しない、あるいはOSの挙動がおかしいままなら、修復の選択肢を段階的に上げます。
| 手段 | データ保持 | 狙い | 向いている状況 |
|---|---|---|---|
| システムの復元 | 概ね保持（アプリは戻る場合あり） | 直近の更新/設定変更を巻き戻す | 特定の日から急に不調になった |
| 修復インストール（上書きインストール） | 保持しやすい | OSコンポーネントを再展開して整合性を回復 | DISM/SFCでも直らないが初期化は避けたい |
| このPCを初期状態に戻す | 選択可（ただしリスクあり） | OSを再構築 | 深刻な破損、動作不安定が続く |
どの選択肢でも、重要データのバックアップは先に取ってください。DISM/SFCは比較的安全ですが、「直らない状態で追加作業を重ねる」ほど復旧難度が上がることがあります。
よくある質問（DISM/SFCの“つまずきポイント”）
PowerShellだと進捗が出ないのは異常ですか？
必ずしも異常ではありません。表示の相性で静かに見えるだけのことがあります。タスクマネージャーでdism.exeが動いているか、dism.logが更新されているかを確認し、心配なら管理者のコマンドプロンプトで再実行してください。
CheckHealthがrepairableなら、必ずRestoreHealthで直りますか？
「修復可能」という意味であって、標準設定（Windows Update依存）で必ず直るとは限りません。ネットワーク制限やWSUS、Windows Update自体の不調があると詰まります。その場合は本記事のとおり/Sourceと/LimitAccessで成功率が上がります。
/Sourceのパスは何を指定すれば正解ですか？
最も確実なのは「ISO内のinstall.wim/esdの正しいインデックス」を指定する方法です。/Get-WimInfoでインデックスを確認し、/Source:wim:...:indexまたは/Source:esd:...:indexで指定すると迷いが減ります。マウントして...\Windowsフォルダを指定する方法も有効ですが、マウント手順を間違えると遠回りになりがちです。
DISMは通ったのにSFCが止まります。どうすれば？
まず再起動してからSFCを再実行します。それでも止まる場合、TrustedInstallerサービスの状態を確認し、Windowsが不安定ならオフラインSFC（回復環境からの/offbootdir指定）を試してください。SFCが修復できない場合はCBSログにヒントが残ることが多いです。
まとめ：再現性の高い解決ルート
- DISMは数時間かかることがあり、進捗が出なくても“止まって見えるだけ”のケースがある
- 動いているかは「タスクマネージャー」「dism.log更新」で確認する
- 進まない／失敗するなら、Windows Update依存をやめて
/Sourceと/LimitAccessで修復ソースを明示する - DISM完走後に
sfc /scannowを実行して仕上げる（順番が重要） - それでも直らない場合は、ログ確認→修復インストール等へ段階的に切り替える
「repairableなのに進まない」状況は、原因さえ潰せば改善することが多いです。焦って中断せず、ソース指定でDISMを通し、最後にSFCで整合性を取り直す流れで復旧を狙ってください。
コメント