Windows Updateで「0x80070005」や「0x80080005」が出て更新できないと、ドライバー更新やトラブルシューティングを試しても行き詰まりがちです。多くは“アクセス拒否”に代表される権限・保護ファイル・更新コンポーネント不整合が原因。再現性の高い順に、具体的な直し方をまとめます。
0x80070005 / 0x80080005とは？まずは意味を押さえる
Windows Updateのエラーコードは、原因が1つに決まるというより「この方向が怪しい」という手掛かりとして捉えるのがコツです。特に0x80070005は、Microsoftのサポート情報でも「アクセス拒否（更新プログラムをインストールするためのアクセス許可が不十分）」の文脈で案内されており、管理者権限やセキュリティ設定の影響が疑われます。
| エラーコード | よくある意味合い | Windows Updateで疑うポイント | 現場で多い原因例 |
|---|---|---|---|
| 0x80070005 | アクセス拒否（権限不足） | 更新処理が必要なファイル/フォルダー/レジストリに書き込めない | 管理者権限不足、セキュリティ機能/常駐ソフトのブロック、更新キャッシュの破損、フォルダー権限の崩れ |
| 0x80080005 | 更新コンポーネント側の実行失敗（アクセス拒否系として扱われることも多い） | Windows Update関連サービスが正常に動けず、インストール段階で失敗する | Windows Updateコンポーネントの不整合、SoftwareDistribution/catroot2の問題、サービスの停止/無効化、システム破損 |
上の表のとおり、どちらも「更新処理が進むはずの場所で止まる」パターンが目立ちます。つまり、闇雲に再試行するより“更新の土台（コンポーネント）”と“壊れやすいポイント（権限/キャッシュ/システムファイル）”を順番に整える方が近道です。
最短で直すための全体像：やることは大きく3つ
対処の考え方を先に整理しておくと、作業の迷子になりません。0x80070005/0x80080005の解決は、だいたい次の3系統に収束します。
| 系統 | 狙い | 代表的な手段 | 向いている症状 |
|---|---|---|---|
| 干渉を取り除く | ブロック/競合している常駐を止める | セキュリティソフト一時停止、VPN/プロキシOFF、クリーンブート | ダウンロードは進むのにインストールで落ちる、更新が途中で止まる |
| 破損を修復する | システムファイル/コンポーネントストアを修復 | SFC、DISM | エラーが毎回同じ、別の機能も不安定、イベントログにエラーが多い |
| 更新基盤をリセットする | 更新キャッシュと署名関連を作り直す | SoftwareDistribution/catroot2のリネーム、サービス再起動、手動KB適用、修復インストール | トラブルシューティングでも直らない、複数KBが失敗、0x80080005が出続ける |
作業前の準備：ここを外すと成功率が下がる
更新トラブルの“あるある”は、手順そのものよりも前提条件の不足で失敗することです。次の準備をしてから作業すると、同じ時間でも成功率が上がります。
| 準備 | 理由 | 目安 |
|---|---|---|
| 管理者権限のアカウントで作業 | 0x80070005系は権限で詰まりやすい | ローカル管理者がベスト |
| 再起動を1回入れる | サービス/ロック中ファイルが解除される | 作業開始前に実施 |
| BitLockerが有効なら回復キーを控える | 修復インストール等の作業で求められる場合がある | Microsoftアカウント/社内管理を確認 |
| 空き容量の確保 | 十分でも“Cドライブ直下”が足りないと失敗するケースがある | 20GB以上を推奨（環境により増減） |
| 周辺機器を減らす | ドライバー/常駐の競合を減らす | 不要なUSB・ドックを外す |
| 時刻/タイムゾーンのズレを直す | 署名検証や安全な通信で不具合が出ることがある | 設定→時刻と言語→自動設定をON |
実際の対処手順：再現性が高い順に試す
干渉要因を除外する（セキュリティ・常駐・ネットワーク）
「サードパーティ製ウイルス対策なし」「ドライバー/BIOS更新済み」「容量も十分」「トラブルシューティングでも改善しない」という状況でも、常駐ソフトの競合やネットワーク制御（VPN/プロキシ/フィルタ）が残っていることがあります。まずは“更新だけ”に集中できる状態を作ります。
- VPNクライアント、広告ブロック系、通信監視系、社内セキュリティエージェントの一時停止（可能な範囲で）
- サードパーティ製のファイアウォール/最適化ツール/レジストリクリーナがあれば停止またはアンインストール
- 企業端末なら、WSUS（社内更新サーバー）やMDM（Intune等）のポリシーで更新が制限されていないか確認
- 一時的に周辺機器を外す（USBドック、外付けストレージ、特殊キーボード/マウス等）
「何が干渉しているかわからない」場合に強いのがクリーンブートです。ポイントは“常駐を減らす＝原因を消す”ではなく、“原因を特定するための診断モード”として使うことです（更新が通るかどうかの再現テストに向いています）。
| 切り分け対象 | よくある症状 | 確認/対処のヒント |
|---|---|---|
| VPN/プロキシ | ダウンロードが進まない、途中で止まる | 一時的にOFFにして更新を試す。企業ネットワークなら管理者に相談。 |
| セキュリティ/監視エージェント | インストール段階で失敗、アクセス拒否系 | 一時停止（できない場合はクリーンブートで影響を見る） |
| 最適化ツール/サービス無効化 | 0x80080005が出る、サービスが起動できない | Windows Update関連サービスが「無効」になっていないか確認 |
Windows Update トラブルシューティングを実行する（設定アプリから）
既に試している方も多いですが、手順がOSバージョンで微妙に異なります。未実施なら先に一度走らせておくと、後続の手順が通りやすくなることがあります。
- 設定を開く（Windowsキー + I）
- システム → トラブルシューティング → その他のトラブルシューティング ツール
- Windows Update の「実行」を選ぶ
結果が「解決できませんでした」でも落ち込む必要はありません。0x80070005/0x80080005は“根が深い”タイプがあるため、次のSFC/DISMやコンポーネントリセットが本命になります。
SFC / DISMでシステム破損を修復する（更新の土台を直す）
更新処理は、Windowsの保護ファイルやコンポーネントストアに強く依存します。ここが壊れていると、更新キャッシュを消しても再発しがちです。そこでSFC → DISMの順で修復するのが定石です。
| コマンド | 役割 | 実行場所 | ポイント |
|---|---|---|---|
sfc /scannow | 保護されたシステムファイルの検査・修復 | 管理者のコマンドプロンプト | 完了まで待つ。結果が「修復できない」と出たらDISMへ。 |
DISM /Online /Cleanup-Image /RestoreHealth | コンポーネントストアの修復 | 管理者のコマンドプロンプト | ネットワーク状況で時間が伸びることがある。終わったら再起動→SFC再実行が鉄板。 |
実行手順：
- スタートメニューで「cmd」または「コマンドプロンプト」を検索
- 右クリック → 管理者として実行
- 以下を順番に実行
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
完了したら一度再起動し、Windows Updateを再試行します。まだ失敗するなら、次の「Windows Updateコンポーネントのリセット」に進みます。
Windows Update コンポーネントをリセットする（SoftwareDistribution / catroot2）
0x80070005/0x80080005で最も“当たりやすい”のがこの手順です。Microsoft Q&Aでも、SoftwareDistributionとcatroot2をリネームして更新基盤を作り直す方法が繰り返し案内されています。特に、0x80070005/0x80080005が併発しているケースでは、Windows Update関連のキャッシュや署名データの不整合が混ざっていることが多く、効果が出やすい印象です。
注意点
- 作業は必ず管理者で行います。
- 更新の再ダウンロードが発生するため、回線が細い場合は時間がかかります。
- 「更新履歴」が一時的に空に見えることがありますが、インストール済み更新が消えるわけではありません。
手順（コマンドプロンプトを管理者として実行）：
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 Catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver 環境によっては、appidsvc（Application Identity）も止めてから再開すると安定することがあります。
net stop appidsvc
net start appidsvc
| 項目 | 何をしている？ | 壊れると起きやすいこと | 今回のリセットで期待できること |
|---|---|---|---|
| Windows Updateサービス（wuauserv） | 更新の検出・ダウンロード・インストール管理 | 更新が進まない、エラーが出続ける | 更新基盤の再初期化が進む |
| BITS | バックグラウンド転送 | ダウンロードが止まる/進まない | 転送状態をリセットしやすい |
| SoftwareDistribution | 更新キャッシュ（ダウンロード/データストア） | 失敗したKBが残り続ける、同じエラーを繰り返す | キャッシュが作り直され、古い破損データが切り離される |
| catroot2 | 署名・カタログ情報（暗号関連） | 署名検証で失敗、更新の適用で止まる | 署名関連の不整合が解消することがある |
実施後はPCを再起動し、Windows Updateを実行して改善するか確認します。Microsoft Q&Aの「0x80070005 / 0x80080005で更新できない」スレッドでも、Microsoft MVPの手順を試して解決したという報告があり、採用回答として紹介されています。
Windows Update関連サービスの状態を確認する（無効化されていないか）
最適化ツールや“高速化”の設定で、Windows Update関連サービスが無効化されていると、0x80080005が出やすくなります。GUIで確認するのが確実です。
Windowsキー + R→services.msc- 次のサービスを探し、状態が「実行中」または「手動/自動で起動できる」ことを確認
| サービス名 | 表示名の例 | 目安のスタートアップ | 役割 |
|---|---|---|---|
| wuauserv | Windows Update | 手動（トリガー開始）または自動 | 更新全般の中核 |
| bits | Background Intelligent Transfer Service | 手動（トリガー開始） | 更新のダウンロード |
| cryptsvc | Cryptographic Services | 自動 | 署名・証明書関連 |
| msiserver | Windows Installer | 手動 | MSIを使う更新の適用 |
ここで「無効」になっている項目があれば、まずは手動/自動に戻して再起動し、Windows Updateを再試行します。
失敗したKBを特定して「原因を絞る」
更新に失敗しているのが「特定のKBだけ」なのか、「更新全般」なのかで、打つ手が変わります。まずは設定から失敗した更新プログラム（KB番号）を確認しましょう。
- 設定 → Windows Update
- 更新の履歴を開く
- 「失敗」と表示されているKB番号をメモ
KBが特定できたら、次のように切り分けます。
- 累積更新（例：月例の品質更新）だけ失敗 → 更新基盤の破損/干渉が疑わしい
- .NET更新やドライバー更新だけ失敗 → 特定コンポーネント/ドライバー/依存関係を疑う
- 複数KBが連鎖して失敗 → Windows Updateコンポーネントやシステム破損の可能性が上がる
ログを取って、0x80070005/0x80080005の“具体的な場所”を掴む
原因が見えないときほど、ログは役に立ちます。Windows 10/11ではWindows UpdateのログはETL形式で保存されるため、Get-WindowsUpdateLogで読みやすいログに変換できます。
PowerShell（管理者）で実行：
Get-WindowsUpdateLog
デスクトップにWindowsUpdate.logが生成されます（静的なコピーなので、再度取得したい場合はコマンドをもう一度実行します）。
| ログ/場所 | 見るべきキーワード | 分かること | 補足 |
|---|---|---|---|
| WindowsUpdate.log（Get-WindowsUpdateLogで生成） | 0x80070005 / 0x80080005 / FATAL / ERROR | どの処理（検出/ダウンロード/インストール）で止まったか | 更新試行直後に採取すると追いやすい |
| C:\Windows\Logs\CBS\CBS.log | Access is denied / Cannot repair | システムファイル修復（SFC）関連の詳細 | 容量が大きいので、必要箇所だけ抽出して読む |
| イベントビューアー（Windowsログ） | WindowsUpdateClient / Setup | サービス起動失敗・インストール失敗の時系列 | 日時で絞ると見やすい |
ログで「アクセス拒否」がどのパスで起きているかが見えると、不要な作業を減らせます。例えば、SoftwareDistribution配下の書き込みで落ちているならコンポーネントリセットが刺さりやすい一方、別の場所（ドライバー領域や特定アプリのフォルダー）で落ちているなら競合/権限の見直しが近道です。
Microsoft Update Catalogから該当KBを手動インストールする（回避策）
「Windows Updateからの適用」が失敗する一方で、更新自体は正常に適用できるケースがあります。その場合はMicrosoft Update CatalogからKBを手動で落としてインストールするのが手堅い回避策です。
- Microsoft Update CatalogでKB番号（例：KB1234567）を検索
- OSとアーキテクチャ（x64/ARM64など）を間違えない
- インストール後は再起動し、Windows Updateを再確認
ただし、手動インストールでも同じエラーが出る場合は「更新の土台」自体が傷んでいる可能性が高いので、次の修復インストールを検討します。
クリーンブートで常駐競合を排除する（“犯人探し”に強い）
コンポーネントリセットやSFC/DISMまでやってもダメなら、残る大物は常駐の競合です。クリーンブートで更新が通るなら、常駐を段階的に戻して“どれが干渉したか”を特定できます。
- 一時的にMicrosoft以外のサービス・スタートアップを無効化
- 更新が通ったら、半分ずつ戻す（分割統治で特定）
- 犯人が特定できたら、アップデート/設定変更/アンインストールを検討
ISOを使った上書き修復（修復インストール）で更新基盤ごと立て直す
0x80080005が長期間続く場合や、複数の更新が連鎖して失敗する場合は、ISOを使った修復インストール（インプレースアップグレード）が現実的な最終手段になります。Microsoft Q&Aでも、コンポーネントリセットで直らない場合の追加案として「ISOで上書きして更新基盤を直す」方向が提案されています。
| 項目 | 修復インストール（上書き） | クリーンインストール（初期化） |
|---|---|---|
| 個人ファイル | 基本的に保持できる | 消える（バックアップ必須） |
| アプリ/設定 | 保持できることが多い | 再インストールが必要 |
| 狙い | 更新基盤・システムファイルの再構築 | 環境を完全に作り直す |
| おすすめ度 | まずはこちら（復旧のコスパが高い） | どうしても直らない/環境が汚れている場合 |
大まかな流れ：
- Microsoft公式からWindows 10/11のISO（またはインストールメディア作成ツール）を入手
- ISOをマウントして
setup.exeを起動 - 「個人用ファイルとアプリを引き継ぐ」を選択（表示される場合）
- 完了後にWindows Updateを実行して確認
作業中は電源を抜かない、周辺機器を最小限にする、必要ならセキュリティソフトを一時停止する、といった基本を守ると成功率が上がります。特にノートPCはAC接続、デスクトップは可能ならUPS（無停電電源装置）環境が理想です。
それでも直らないときのチェックポイント（再発防止にも）
ここまでやっても改善しない場合は、「OS側の破損」以外の要因が隠れていることがあります。特に0x80070005（アクセス拒否）は、権限・ポリシー・アカウントの影響を受けやすいのが厄介です。
- 仕事/学校アカウントを接続している場合、いったん解除して挙動が変わるか確認（企業ポリシーで更新が制御されることがあります）
- Windows Updateサービスが無効になっていないか（
services.mscで確認） - ディスクのエラー（ファイルシステム破損）を疑う場合は、ドライブのエラーチェックや
chkdskも検討 - イベントビューアーで、更新失敗の直前に別エラーが連鎖していないか確認
- 社内端末なら、管理者が配布している更新（WSUS/Intune）と競合していないか確認
逆に、安易に「フォルダーの所有権取得」や「レジストリの大量編集」を行うと、更新以外の不具合を増やしてしまうことがあります。0x80070005/0x80080005は“結果としてアクセスできない”だけで、原因はサービス停止やキャッシュ破損にあることも多いので、まずは本記事の順番で土台から整えるのがおすすめです。
よくある質問
更新コンポーネントのリセット後、更新履歴が消えたように見えます。大丈夫？
SoftwareDistribution配下のデータストアを作り直すため、設定画面の「更新の履歴」が一時的に空になったり、過去分が見えにくくなることがあります。これは“表示の履歴”が変わるだけで、インストール済み更新プログラム自体が削除されるわけではありません。不安な場合は「プログラムと機能」→「インストールされた更新プログラム」で確認できます。
フォルダーのリネームで「アクセスが拒否されました」になって進めません
多くはWindows Update関連サービスがまだ掴んでいる状態です。net stopが失敗していないか、コマンドプロンプトが管理者で起動できているかを確認し、再起動後すぐに同じ手順を試してください。ネットワークが有効なままだと更新が裏で動き続けることがあるため、必要なら一時的にWi‑Fiを切ってから作業するのも有効です。
SFCやDISMが長時間止まっているように見えます
進捗表示が止まって見えても内部では処理が続いていることがあります。特にDISMは環境によって時間がかかります。数十分以上まったく進まない場合は、いったん再起動→再実行、またはログ（CBS/DISM）を確認して原因を追うのが安全です。
何をやっても直らない場合、最終的にどう判断すべき？
目安として、(1)複数KBが継続的に失敗、(2)SFC/DISMでも修復できない、(3)クリーンブートでも改善しない、の3つが揃うなら、修復インストール（上書き）を強く推奨します。それでも改善しない場合は、ストレージ不良や企業ポリシー、端末管理の影響など、OS外の要因も疑って切り分けを進めてください。
コメント