Windows 11アップデート「エラーコード0x80070005」を乗り越える完全ガイド

Windows Updateの0x80070005は「アクセスが拒否された」ことを表すエラーです。ただし、エラーコードだけでは拒否された対象や原因を特定できません。管理者権限、システムファイル、セキュリティ製品、組織ポリシーなどを、失敗時刻とログに基づいて切り分けます。

目次

まず更新対象と発生時刻を記録する

「設定」→「Windows Update」→「更新の履歴」で、失敗したKB番号・日時・エラー全文を控えます。「システム」→「バージョン情報」でエディションとOSビルドも確認します。以前のKB5050009での事例と、現在提供されている更新は同一ではありません。古いKBを番号だけで手動インストールせず、自分のOSに適用される更新と公式の既知問題を確認してください。

更新がダウンロード段階で止まるのか、インストール中か、再起動後に取り消されるのかも記録します。同じ0x80070005でも、Microsoft StoreやOfficeのエラーとは調べる対象が異なります。

STATUS_ACCESS_DENIEDという文字だけで「WDACが原因」とは判断できません。拒否の対象と同じ時刻の記録が必要です。

低影響の対処から始める

作業を保存して再起動し、接続・空き容量・再起動待ちの有無を確認します。Windows 11の「ヘルプを表示」アプリからWindows Updateの診断を実行します。失敗を繰り返す場合は、同じ操作を無制限に続けず結果を記録します。組織管理PCでは更新の配布方針も担当者に確認してください。

更新の一時停止は障害の原因を修復する操作ではありません。停止したまま放置せず、再開の予定を管理します。セキュリティソフトをとりあえず停止する、Windowsフォルダー全体の所有者を変える、といった操作は初手にしません。

CBSログを確認する

更新・コンポーネント処理の記録は通常 C:\Windows\Logs\CBS\CBS.log にあります。失敗した更新の時刻付近で、0x80070005やアクセス拒否の対象を確認します。一行だけ切り出すと、原因ではなく後続の結果を見ている場合もあるため、前後の処理とKB番号を合わせて読みます。

ログにCodeIntegrityや.cipが出た場合でも、直ちにそのファイルを削除してはいけません。管理者がCodeIntegrityのイベント、ポリシーの配布元、署名や適用状態などを照合します。ログを相談先へ渡す前には、ユーザー名・端末名・パスなどの不要な個人情報を確認してください。

ログの確認は原因を調べる作業です。該当パスが見えたことは、そのファイルの所有権やアクセス許可を変更してよい根拠にはなりません。

App Control/WDACが疑われる場合

App Control for Business(旧WDAC)は、実行可能なコードを制御する仕組みです。ポリシーによる影響が疑われるときは、組織の担当者がログと配布設定を確認します。0x80070005だけで原因を断定し、一般ユーザーが保護設定を解除する手順ではありません。

.cipファイルにtakeown・icaclsを使って権限を変更したり、ファイル名を変えて回避したりしないでください。署名済みポリシーなどは撤回方法が異なり、不適切な削除で起動障害が生じる可能性があります。必要な変更は配布方式と公式の撤回要件を把握した管理者が行います。

個人所有PCでも同様です。Windowsセキュリティの画面だけで、すべてのコード整合性ポリシーの原因や撤回方法を判断することはできません。身に覚えのない管理状態はサポートへ相談します。

システムファイルの破損を調べる

破損が疑われ、管理権限と作業許可がある場合は、Microsoftの標準修復手順を利用します。重要なデータをバックアップし、管理者のコマンドプロンプトで次のDISMを実行します。成功を確認してからSFCへ進みます。

DISM.exe /Online /Cleanup-image /Restorehealth
sfc /scannow

DISMが失敗したら、表示されたエラーとログを記録してください。修復ソースが必要な場合もあり、権限変更で押し切る操作ではありません。SFCの終了まで待ち、結果を確認してから更新を再試行します。どちらもApp Controlの設定やあらゆるアクセス拒否を必ず直すものではありません。

「成功率が高い」「何分で必ず直る」という一律の目安はありません。修復結果と次の更新結果を別々に確認しましょう。

セキュリティ製品が関係している場合

製品名・バージョン・検知履歴と更新失敗時刻を照合し、メーカーの対応情報を確認します。影響が確認された場合も、保護を無断で止めるのではなく、管理者やメーカーが示す更新・修復手順を使います。組織端末では担当部署へ引き継ぎます。

問い合わせ時にまとめる情報

KB番号、OSビルド、失敗日時と段階、エラー全文、CBSやDISMの関連記録、セキュリティ製品名、実施済みの操作と結果をまとめます。Q&Aの似た事例は参考情報であり、自分の端末にも同じ原因がある証拠ではありません。

管理者へは「ポリシーを無効化してほしい」ではなく、まず発生時刻と拒否対象を伝え、配布設定との関連を調べてもらうと適切な切り分けにつながります。

まとめ

0x80070005は原因名ではありません。更新対象とログを確かめ、診断・標準修復・管理者への引き継ぎを順に行います。保護ポリシーの改名・削除や一括権限変更は、一般的な更新エラー対策として実施しないでください。

公式資料

Windows Updateのトラブルシューティング、DISMとSFC、App Controlポリシーの撤回に関する管理者向け注意事項。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次