DISM.exe /Online /Cleanup-Image /RestoreHealthの使い方とエラー対処まとめ

Windows Update が何度やっても失敗する、起動や動作が急に重くなった、アプリが頻繁に落ちる――その原因が「システムの破損」だとしても、初期化や再インストールに踏み切るのは現実的ではありません。そんなときに有効なのが、Windows に標準搭載された修復コマンド DISM.exe /Online /Cleanup-Image /RestoreHealth です。

ただし、検索すると「実行すれば直る」とだけ書かれた説明が多く、実際には 0x800f081f や 0x800f0906、エラー87 などで止まり、かえって不安が増えるケースも少なくありません。重要なのは、コマンドを打つことではなく、失敗しない前提条件を整え、状況に応じてオンライン修復とオフライン修復を切り替えることです。

本記事では、DISM /Online /Cleanup-Image /RestoreHealth が直す対象と仕組みを押さえたうえで、正しい実行手順、成功判定の見方、代表的なエラーの原因と最短対処、さらに /Source 指定で確実に通す方法までを一気通貫で解説いたします。初めてコマンドを触る方でも迷わないよう、チェックリストと具体例を用意していますので、手順どおりに進めるだけで「次に何をすべきか」が明確になります。

※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。

dism.exe /online /cleanup-image /restorehealthでできること

Windowsイメージとコンポーネントストアの考え方

DISM.exe /Online /Cleanup-Image /RestoreHealth は、Windows に内蔵されている「展開イメージのサービスと管理（Deployment Image Servicing and Management）」機能を用いて、現在起動中の Windows（オンラインイメージ）を対象に、Windows の修復基盤にあたる領域を検査・修復するためのコマンドです。

Windows では、更新プログラムや機能追加、システムファイルの修復などに必要な「部品」が、OS内部の一定の場所に保管されています。この保管領域が一般に コンポーネントストア（WinSxS を含む仕組み） と呼ばれる部分で、Windows Update やシステム修復（SFC）に必要な材料がここから参照されます。
ところが、更新の途中失敗、ディスク障害、突然の電源断、セキュリティソフトの介入、ファイルシステム不整合などが重なると、この領域の整合性が崩れ、結果として以下のような症状が起きやすくなります。

• Windows Update が「インストールできませんでした」「ロールバックします」などで失敗する

• 更新適用後に起動が遅い、エクスプローラーが落ちる、設定アプリが開かない

• sfc /scannow を実行しても「修復できないファイルがあります」となる

• .NET などの機能追加（オプション機能）が追加できない

• 特定の累積更新が繰り返し失敗する

/Online は「起動中のOS（オンライン）を対象にする」指定です。
/Cleanup-Image は「Windows イメージ（コンポーネントストア）に対する検査・保守処理をする」カテゴリ指定です。
/RestoreHealth は「破損を検出し、必要に応じて修復を行う」処理を意味します。

なお、DISM の処理は「見えているエラーだけ」を直すというより、Windows の修復・更新の土台（修復材料）を正しい状態に戻すことが主目的です。そのため、体感としては「何かが直った」というよりも、以下のように結果が表れることが多いです。

• それまで失敗していた Windows Update が通るようになる

• SFC の修復が最後まで通るようになる

• オプション機能の追加・修復が通るようになる

• 更新後の不安定さ（エラー頻発）が落ち着く

また、DISM はオンラインだけでなくオフライン（別ドライブの Windows、WIM/ESD など）にも使えますが、本記事の対象はご指定キーワード通り オンライン修復 を中心にし、必要に応じてオフライン修復の実施方法まで取り扱います。

SFC /scannowとの違いと推奨順序

SFC /scannow は、主に システムファイル（Windows の保護対象ファイル） を検査し、破損があれば修復を試みるコマンドです。
一方で、SFC が修復する際には「正しいファイルの参照元」が必要になります。ここで参照元として重要になるのが、先ほどのコンポーネントストアです。つまり、修復材料が壊れていると SFC も直しきれないことが起こり得ます。

この関係を実務的に理解すると、次のように整理できます。

• SFC：表に出ているシステムファイルの破損を直したい（ただし材料が必要）

• DISM：修復材料（コンポーネントストア）の破損を直したい（結果としてSFCが通りやすくなる）

そのため、トラブル対応の基本は以下の順序が推奨されます。

1. DISM（材料側の整備）

2. SFC（システムファイル側の修復）

3. 再起動、Windows Update の再試行

なお、DISM をいきなり /RestoreHealth で走らせてもよいのですが、状況把握や時間の見積もりをしやすくするため、/CheckHealth や /ScanHealth を挟む運用が安定します。これは「軽い確認→詳細スキャン→修復」という段階分けになり、問題が軽微な場合に無駄な時間を減らせます。

dism.exe /online /cleanup-image /restorehealthの実行手順

実行前のチェックリスト

DISM は OS の根幹に関わる整合性を扱います。基本的に安全性が高い手順ですが、失敗要因を潰し、作業中に中断しないために、事前に以下を確認してください。

事前チェックリスト（推奨）

• 管理者権限でコマンドを実行できる（管理者として実行）

• ノートPCはAC電源に接続し、作業中にスリープしないようにする

• Cドライブに十分な空き容量がある（目安として数GB以上の余裕）

• ディスクが異常に遅い・異音がするなどの兆候がない（疑わしい場合はバックアップ優先）

• インターネット接続が安定している（オンライン修復の場合）

• 会社端末の場合、WSUS・プロキシ・通信制限の有無を把握している

• 念のため重要データのバックアップを取っている（障害対応として推奨）

特に多い落とし穴は「管理者として起動していない」「途中でスリープして中断」「空き容量不足」「ネットワーク制限」です。まずここを固めるだけで、成功率が大きく上がります。

基本コマンドの実行手順

ここでは、最も迷いにくい「基本の実行順」を、コピペ前提で整理いたします。

1）管理者でコマンドプロンプトまたは PowerShell を起動

• スタートメニューで「cmd」または「PowerShell」と検索

• 右クリックして「管理者として実行」

2）軽い確認（CheckHealth）

これは短時間で終わることが多く、状態が「修復不要」か「修復が必要（破損がある）」かの目安になります。ここで問題が出ないからといって完全に安心とは限りませんが、初手として有用です。

3）詳細スキャン（ScanHealth）

破損が疑われる場合は、より丁寧にスキャンします。環境によっては時間がかかります。スキャン結果が「破損が修復可能」となれば、次の RestoreHealth に進みます。

4）修復（RestoreHealth）

これが本命です。オンラインで必要な修復コンポーネントを取得できる環境であれば、ここで修復が完走します。途中で進捗が止まったように見える場合がありますが、後述のFAQで判断の目安を説明します。

5）仕上げ（SFC）

DISM が完走したら、最後に SFC を実行します。

SFC は DISM で整備された材料を用いて、システムファイル側を修復します。ここまで通ると、Windows Update の失敗や不安定さが改善するケースが多いです。

補足：実行中の注意

• 作業中はできる限り他作業を控え、負荷を避ける

• セキュリティソフトが強い監視をしている場合、一時的に影響することがあります（無効化の是非は環境方針に従ってください）

• 途中で強制終了（タスクキルや電源断）は避ける

完了メッセージの見方と成功判定

DISM は実行すると、進捗（％）が表示されます。ただし、環境によって進捗が一定時間動かない、同じ数値で止まるように見えることがあります。これは必ずしも異常ではありません。

成功判定の目安

• コマンドが最後まで完了し、致命的なエラーコードが出ない

• 「操作は正常に完了しました」等の完了メッセージで終わる

• その後の sfc /scannow が完走し、修復結果が改善する

失敗判定の目安

• エラーコード（例：0x800f081f、0x800f0906、87）が表示される

• 「ソースファイルが見つからない」「ファイルをダウンロードできない」などの文言が出る

• 何度実行しても同じ箇所で停止し、長時間進まない（ただし“長時間”は環境差が大きい点に留意）

失敗した場合でも、多くは原因が「ネットワーク」「ソース」「入力ミス」に集約されます。次章で失敗原因を整理し、その次でエラー別に最短の対処に落とし込みます。

dism.exe /online /cleanup-image /restorehealthが失敗する主な原因

ネットワークや更新コンポーネントの問題

/RestoreHealth は、状況により修復に必要なファイルをオンラインで取得しようとします。ここで問題になるのがネットワーク経路と更新関連の仕組みです。

代表的な阻害要因は次のとおりです。

• プロキシ環境で外部接続が制限されている

• 会社端末で WSUS 配下にあり、Windows Update の参照先が統制されている

• VPN 経由で通信が不安定

• セキュリティ製品やUTMで特定通信が遮断

• 更新関連サービスが停止・不整合（更新コンポーネント破損）

この場合、オンライン修復で粘るよりも、/Source 指定によるオフライン修復へ切り替えた方が早いことが多いです。特に企業環境は「インターネットへ取りに行く」動作が制限される前提で設計されている場合があり、オフライン前提に切り替える判断が重要です。

入力ミスと権限不足

エラー87の多くは入力ミスや権限不足です。以下が典型です。

• 「/」が「／」になっている（全角）

• スペースの位置がズレている、または余計な空白が混じっている

• cleanup-image のハイフンが別の記号になっている

• 末尾に余計な文字が入っている

• 管理者として起動していない

特に日本語環境では、Webページやメモ帳からコピーした際に全角記号が紛れ、見た目では気づきにくいことがあります。可能であれば、本記事のコマンドをそのままコピペし、うまくいかない場合は一度「手入力」ではなく「貼り付け直し」を推奨いたします。

修復ソース不一致とメディアの落とし穴

0x800f081f などでよくある根本原因が「修復ソースが見つからない／一致しない」です。ここでいうソースは、/Source で指定する WIM/ESD やフォルダ、またはオンライン取得元です。

失敗しやすい落とし穴は以下です。

• ISO が Windows のバージョン・ビルドと一致していない
  例：OSが 22H2 なのに、別世代のISOを使う

• エディションが一致していない
  例：OSが Pro なのに、Home のイメージを指している

• install.wim / install.esd の インデックス番号 が適切でない
  例：:1 が別エディションを指している

• ネットワーク共有のアクセス権やパス指定が誤っている

• ドライブ文字（D: など）が環境により変わっている

この原因は「/Source 指定をしたら必ず直る」というよりも、正しい修復材料を、正しく指定できているかが勝負になります。次章でエラー別に整理し、さらに次の章でオフライン修復を体系化いたします。

dism.exe /online /cleanup-image /restorehealthのエラー別対処法

ここでは代表的なエラーを、最短の解決動線になるように整理いたします。ポイントは「何を確認し、何に切り替えるか」を迷わないことです。

0x800f081f ソースファイルが見つからない

このエラーは、端的に言えば「修復に必要なソースが手に入らない」状態です。オンライン取得に失敗しているか、/Source で指定したものが不適切です。対処は次の順で進めると効率的です。

対処手順（推奨順）

1. まずはオンライン修復を再試行する（通信が一時不調の可能性がある場合）

2. 改善しない場合は /Source 指定 へ切り替える

3. /Source 指定でもだめなら、ISO（修復材料）のバージョン・エディション一致を疑う

4. それでも解決しない場合は、修復インストール等の上位手段を検討

/Source 指定の基本方針

• 会社PCや通信制限環境：/LimitAccess を付ける方向で設計すると安定します

• 個人PCで通信が安定：/LimitAccess は必須ではありませんが、環境により有効です

• インデックス番号は「合っていれば一発で直る」「ズレていると必ず失敗する」重要要素です

具体コマンド例は後述の「オフラインで通す方法」でまとめます。

0x800f0906 ファイルをダウンロードできない

このエラーは「取得経路が塞がれている」または「取得処理が成立していない」ことが中心です。やるべきことは明確で、オンラインに固執せず、早めにオフラインへ寄せる方が時間効率が良いことが多いです。

対処の考え方

• 会社端末：WSUS/プロキシ/セキュリティ統制の可能性が高い

• 自宅端末：回線不安定、VPN、セキュリティソフトの影響が疑わしい

• いずれの場合も、ISO を用意して /Source 指定に切り替えると前に進みやすい

追加の現実的な確認ポイント

• 大容量ダウンロードが制限されていないか（社内ルール、時間帯制限）

• VPNを切ったら改善するか（許可される範囲で）

• 一時的に別回線に切り替えられるか

• Windows Update サービスや関連サービスが停止していないか

ただし、環境ポリシーに抵触する対処（勝手なプロキシ設定変更など）は避け、可能な範囲で「オフライン修復に切り替える」方針を強く推奨いたします。

エラー87 パラメーターが正しくない

エラー87は、原因が「入力・書式」であることがほとんどです。以下のチェックを上から実施してください。

チェックリスト

• コマンドは正確に DISM /Online /Cleanup-Image /RestoreHealth になっている

• - はハイフン、/ は半角スラッシュになっている

• 余計な文字（全角スペース、引用符など）が入っていない

• 管理者で起動している

• DISM.exe の有無は本質ではないが、まずは DISM で統一して試す

実務上のコツ

• 手入力はミスが混じりやすいため、まずコピペで成立させる

• うまくいかない場合、コピー元が装飾されている可能性があるため、いったんメモ帳に貼って整形し、そこからコピーする

• 日本語IMEの影響を避けるため、入力モードを半角英数に固定する

それでも直らないときの次の手段

DISM のエラーが解消しない場合でも、次に取るべき手段は段階化できます。闇雲に初期化へ進むのではなく、以下の順番で「損失が少ない手段」から検討してください。

1. DISMが完走した前提で、SFCを実行

   • DISM完走 → sfc /scannow で仕上げ

2. /Source 指定のオフライン修復へ切り替える

   • オンラインがだめなら材料を用意して修復する

3. 更新コンポーネントの問題を疑い、更新関連の整合性を整える

   • 同じ累積更新が繰り返し失敗するなど、Update基盤に偏った不具合がある場合

4. 修復インストール（上書き修復）を検討

   • 個人データやアプリを保持しつつ、OSを再構成できる手段として現実的です

5. 最終手段としてクリーンインストール

   • 時間も手間もかかるため、バックアップと移行計画が必須です

特に「0x800f081f で詰まる」ケースは、修復ソースさえ正しく準備できれば改善することが少なくありません。次章でその準備・指定の要点をまとめます。

dism.exe /online /cleanup-image /restorehealthをオフラインで通す方法

/Source と /LimitAccess の使い分け

オフライン修復（修復ソース指定）の中心は、/Source と /LimitAccess の理解です。

• /Source:
  修復に使う材料（ファイル群）を指定します。フォルダ指定、WIM/ESD指定、ネットワーク共有指定などが可能です。

• /LimitAccess
  Windows Update など外部から取得しようとする動きを抑え、指定したソースの利用を優先させます。
  特に企業環境・通信制限環境では、付けておいた方が「余計な取りに行って失敗する」挙動を減らせるため、安定しやすいです。

典型例（フォルダ指定）

ただし、フォルダの中身が「修復に必要な構成」を満たしていないと、当然失敗します。個人用途では ISO をマウントし、WIM/ESD から指定する方法が分かりやすいことが多いです。

install.wim と install.esd の使い分け

Windows のインストールメディア（ISO）を右クリックで「マウント」すると、DVDドライブのように表示され、通常 sources フォルダ配下に以下のいずれかが存在します。

• install.wim

• install.esd

どちらも Windows のインストールイメージであり、修復材料として利用できる可能性があります。大きな違いは圧縮形式などにありますが、現場で重要なのは「存在する方を正しく指定する」「インデックス番号が合っている」ことです。

WIM の指定例

ESD の指定例

ここで D: はマウントしたISOのドライブ文字です。環境により E: や F: になる場合がありますので、エクスプローラーで確認してください。

インデックス番号（:1）が重要な理由

install.wim / install.esd は、1つのファイルの中に複数エディション（Home/Pro/Enterprise 等）を含む場合があります。そこで :1 のような指定で「どのエディション部分を参照するか」を決めます。
もしインデックスが合っていないと、修復材料が一致しないため、0x800f081f 等の原因になり得ます。

そのため、オフライン修復で失敗する場合は「インデックスが違う」「ISOが違う」を疑うのが鉄則です。手間はかかりますが、ここを合わせ込めると解決が一気に近づきます。

修復ソースを固定する運用の考え方

個人PCでも、複数台の端末を扱う場合でも、「毎回ネット検索して適当なISOを拾う」運用は成功率を下げます。成功率と再現性を上げるために、修復ソースは計画的に扱うことを推奨いたします。

安定運用の要点

• OSのバージョン・エディションに合う ISO を用意する

• ISO の入手元は信頼できる経路に限定する（社内標準、公式配布など）

• 端末のOSバージョンが更新されるたび、修復ソースも更新する

• 企業環境では共有フォルダや管理された配布で、/Source を標準化する

• ログ、エラーコード、実施したコマンドを記録し、同様事象に流用できる形にする

このように運用を整えると、単発の解決だけでなく「次に同じ障害が起きたときの対応時間」を大きく短縮できます。特にヘルプデスクや情シスの文脈では、/Source の固定化と /LimitAccess の使い分けが効きます。

dism.exe /online /cleanup-image /restorehealthのFAQ

どれくらい時間がかかる？止まったように見える

所要時間は環境差が大きく、一概に「何分」と断定しにくいのが実情です。影響する要因は以下です。

• SSD/HDD（HDDは遅くなりやすい）

• ディスク使用率が高い（他作業をしている）

• 破損の程度が大きい

• オンラインでの取得が必要で回線が遅い

• セキュリティ製品が強く監視している

また、進捗％が長時間変わらないことがあります。これは「同じ処理を繰り返している」「特定の検証に時間がかかっている」などの可能性があり、必ずしもフリーズではありません。以下の観点で判断してください。

判断の目安

• ディスク使用率やCPU使用率が動いているなら、継続している可能性が高い

• 数十分単位で変化がない場合でも、環境によっては正常範囲になり得る

• ただし半日以上など明らかに異常に長い場合は、ログ確認や再起動後の再試行を検討

結論としては、短時間で止まったように見えても、まずは完走を優先し、どうしても不安な場合は「エラー表示が出たか」「システム負荷が動いているか」で判断してください。

データやアプリは消える？安全性は？

DISM /Online /Cleanup-Image /RestoreHealth は、基本的に Windows の修復基盤を整える処理であり、ユーザーデータやインストール済みアプリを削除することを目的としていません。従って、多くの場合はデータに影響はありません。

ただし、注意点は2つあります。

1. 障害対応である以上、元々のシステム状態が不安定である可能性がある

2. 作業中に電源断やディスク障害が起きると、問題が悪化する可能性がある

そのため、重要データは事前にバックアップする、ノートPCは電源を接続する、ストレージに異常があるなら先にバックアップを優先する、というのが安全設計です。

ログはどこ？貼り付けるならどれ？

トラブルを切り分ける際は、最低限以下を残してください。

• 実行したコマンド全文（/Sourceの指定内容まで）

• 出力されたエラーコード（0x800f081f等）

• 表示された最終メッセージ（どこで止まったか）

詳細なログとしては、DISM関連ログ（一般に DISM.log 等）が参照されることが多いです。ログを読む目的は、以下のいずれかを特定することです。

• ソースが見つからないのか（パス、アクセス権、インデックス）

• ダウンロードができないのか（ネットワーク、更新基盤）

• そもそもパラメータ解釈で失敗しているのか（エラー87）

ログの全文を貼り付ける必要はありません。特に個人情報や環境情報が含まれる場合がありますので、共有する場合は必要箇所に絞り、機密情報は伏せる運用を推奨いたします。

管理者で実行できない場合は？

管理者権限がないと、DISM は正常に実行できないことが多いです。ここでの対応は、端末の所有形態により変わります。

• 会社PC（管理者権限が付与されない）
  情報システム部門の手順に従うのが原則です。勝手に設定変更やツール導入を行うと監査・セキュリティポリシー違反になる可能性があります。/Source の共有、WSUS設定、修復ポリシーなど、組織として整備されている場合があります。

• 個人PCなのに管理者で実行できない
  管理者アカウントへの切り替え、UACの許可、アカウント権限の見直しが必要です。
  ただし、権限を変更できないほど状況が悪い場合は、回復環境や修復インストールなどの上位手段を検討する方が早い場合があります。