Windows Server 2019の更新で0x80070005が出る原因と解決策まとめ（長期的に直す実践手順）

Windows Server 2019でWindows Updateや累積更新プログラムの適用時に「0x80070005（アクセスが拒否されました）」が出て、SFC・DISM・修復インストール・Windows Updateコンポーネントのリセットまで試しても改善しない──この症状は珍しくありません。
このエラーは「更新そのものが壊れている」というより、更新が通るために必要な権限・サービス・ストア（コンポーネント）・暗号化関連・ポリシーのどこかが噛み合っていない状態で起きやすいのが特徴です。この記事では、長期化しがちな0x80070005を“原因別に切り分けて”収束させる手順を、実務向けに整理します。

Windows Server 2019の更新で0x80070005が出る原因と解決策まとめ（長期的に直す実践手順）

0x80070005がWindows Server 2019で起きる典型パターン

0x80070005は広い意味での「アクセス拒否」です。更新処理は管理者権限だけでなく、複数のサービスアカウント・フォルダACL・証明書ストア・タスクスケジューラ・グループポリシーなどを横断して動くため、どこか一か所でも権限や整合性が崩れると失敗します。特に多いのは次の系統です。

Windows Update関連サービスが不整合（BITS/Windows Update/暗号化サービスなど）
SoftwareDistribution / Catroot2の破損やACL崩れ
コンポーネントストア（WinSxS）側の整合性問題（DISMが直し切れていない、保留更新が詰まっている）
ドメイン/ローカルポリシーで更新周りが制限（WSUS/署名/資格情報の扱い）
AV/EDRやハードニングでアクセスが遮断
SYSTEMやTrustedInstallerの権限不足（見落とされがち）

ここからは「順番にやれば、どこで詰まっているか分かり、戻せる」流れで解決策を提示します。

まずやるべき事前チェック（失敗を増やさない）

作業前に次を確認してください。これだけで原因が見つかることがあります。

再起動が保留になっていないか（更新の保留が残ると再現し続けます）
C:の空き容量（累積更新は一時領域を多く使います）
時刻同期（証明書/署名関連で地味に影響します）
プロキシ設定（WinHTTPプロキシが残っている環境は要注意）
WSUS利用有無（社内WSUSが原因のケースもあります）

次に、ログで方向性をつけます。

ログで「アクセス拒否の対象」を特定する

闇雲に修復を繰り返すと状況が悪化します。最低限、次を見ます。

WindowsUpdate.log（Server 2019はETWから生成）
イベントビューアー：Setup / System / Application
CBS.log（SFC/DISMの詳細）
更新の失敗コードが別に出ていないか（0x800f系など）

「どのフォルダ・どのサービスで拒否されたか」が見えると、以降の手当が刺さります。ログ確認が難しい場合でも、次の手順は“王道の復旧ルート”として有効です。

解決策1：Windows Updateの主要サービスを正しい状態に戻す

SFCやDISMを実行しても、サービスが停止できていない/スタートアップや依存関係が崩れていると更新が失敗し続けます。次を確認します。

wuauserv（Windows Update）
bits（バックグラウンド転送）
cryptsvc（暗号化サービス）
trustedinstaller（Windows Modules Installer）
msiserver（Windows Installer）（更新内容によって影響）

ポイントは、単に「動いている」ではなく、停止→クリア→起動が素直に通る状態に戻すことです。

解決策2：SoftwareDistribution と Catroot2 を“正しく”作り直す

「Windows Updateコンポーネントのリセット」をやったつもりでも、0x80070005が残る場合は、フォルダの中身だけ消してACLが壊れたまま、あるいはサービスが掴んだままのことがあります。

SoftwareDistribution：ダウンロード、データストア等
Catroot2：署名/カタログ情報

ここが破損していると、更新が「検出はできるが適用で落ちる」症状になりやすいです。理想は、関連サービスを確実に止めた上でフォルダを退避（リネーム）し、再起動後に自動生成させる運用です。
それでも戻らない場合は、次の“権限そのものの修復”へ進みます。

解決策3：SYSTEM/TrustedInstallerがアクセスできるACLに戻す

0x80070005の本丸はここです。手動でフォルダを触った、最適化ツールを使った、セキュリティ製品が隔離した、監査やハードニングで権限が変わった──このいずれかで、更新に必要な書き込みが拒否されます。

狙いどころは主に次です。

C:\Windows\SoftwareDistribution
C:\Windows\System32\catroot2
C:\Windows\WinSxS
C:\Windows\Logs\CBS
C:\Windows\Temp と C:\Users\...\AppData\Local\Temp（サービス側の一時利用）

重要なのは、AdministratorsがフルだからOKではない点です。更新はSYSTEMやTrustedInstaller主体で動きます。これらが必要箇所にアクセスできないと失敗します。
ACLを初期状態に近づけるには、対象フォルダ単体の修正より、ポリシー/テンプレートでの逸脱を見直すほうが安全な場合もあります（とくにドメイン配下）。

解決策4：保留更新（Pending）を解消して詰まりを抜く

長期的に更新が失敗しているサーバーでは、保留状態が積み上がってDISMでも直り切れないことがあります。典型的には「ある更新が中途半端に適用済み扱いになり、次が進まない」状態です。

この場合、次の方向で立て直します。

まずコンポーネントストアの整合性確認（DISMのチェック系）
破損が直せない場合、ソースを指定して修復（インストールメディアや同版のISO）
それでもダメなら、更新適用の起点を変える（後述の“スタンドアロン適用”）

すでに修復インストールを試している場合でも、エディション/ビルド/言語がズレたメディアだと修復が中途半端になることがあります。同一条件のソースが重要です。

解決策5：WSUS・GPO・セキュリティ製品の影響を切り分ける

企業環境で多い落とし穴です。

WSUS：承認/配布の不整合、古い分類、署名問題
GPO：更新の場所固定、デュアルスキャン制御、資格情報の扱い
AV/EDR：更新関連フォルダのロック、自己防衛での拒否
CIS等のハードニング：サービス権限/レジストリ/タスクが制限

切り分けの考え方はシンプルで、一時的に外せる制約を外し、同じ手順で再現するかです。
特にEDRは「管理者が見ても分からない拒否」を起こすことがあるため、更新作業の時間帯だけでも例外設定を検討する価値があります。

解決策6：スタンドアロン（手動）で累積更新を当てて前に進める

Windows Update経由がどうしても失敗する場合でも、スタンドアロンで最新の累積更新（LCU）を適用すると前進するケースがあります。更新基盤の問題を迂回できるためです。

ただし、SSU（サービススタック更新）が絡む世代では順序が重要になることがあります
適用後にWindows Updateが復帰することもあります

「更新基盤を完全に直す」より「更新を進めて環境を新しくする」ほうが総合的に安全な場合もあります。

それでも直らないときの現実的な着地点

ここまでの手当で改善しない場合は、環境固有の問題（強いハードニング、ACLの広範破損、過去の更新失敗の蓄積）が濃厚です。現実的には次のどちらかが“損失が少ない”です。

同等スペックの新規サーバーへ移行（役割を移して更新問題を断つ）
インプレースアップグレード/再展開を含めた更改計画（運用コスト最小化）

長期的な更新不全は、セキュリティリスクと運用工数を同時に増やします。0x80070005が続くサーバーは「たまたま更新できない」ではなく、更新できない構造が残っている可能性が高いので、短期復旧と並行して更改シナリオも持っておくのが得策です。

まとめ：0x80070005は“権限と更新基盤”を分解して潰す

Windows Server 2019の0x80070005は、SFCやDISMだけで直り切らないことがあります。だからこそ、更新に関わるサービス・フォルダ・ACL・ポリシー・セキュリティ製品の影響を分解し、順番に戻すのが最短ルートです。

フォルダの作り直しは「中身」ではなく「権限と生成」を意識する
管理者権限だけでは不十分で、SYSTEM/TrustedInstallerの視点で見る
企業環境ではWSUS/GPO/EDRが“拒否の本体”になりうる
手動適用で突破してから基盤が戻るケースもある

この流れで進めれば、「何を試してもダメ」から「どこがダメか分かる」に変わり、復旧の再現性が上がります。