Windows Updateで「0x80072EFF」が出て更新に失敗する場合、多くは更新サーバーとの通信（TLS/SSL、プロキシ、VPN、時刻ずれ、キャッシュ破損）が原因です。この記事では原因の切り分けから、SFC/DISM、Windows Updateコンポーネントのリセット、TLS1.2有効化まで、現場で再現性の高い手順を順番にまとめます。
Windows Update エラー 0x80072EFF とは
エラー 0x80072EFF は、Windows Update / Microsoft Update が更新サーバーへ接続する途中で通信が成立せず、処理が中断されたときに出やすいコードです。体感的には「更新が途中で止まる」「ダウンロードが始まらない」「確認中のまま失敗する」といった症状になりがちで、原因の多くは ネットワーク経路 と SSL/TLS（暗号化通信） にあります。
特に企業ネットワークやセキュリティ製品の導入環境では、プロキシ・VPN・SSLインスペクション（HTTPS検査）・フィルタリングが絡み、Windows Update が必要とする通信がブロック／改変されて失敗するケースが珍しくありません。
最初に把握しておきたい「よくある原因」
| よくある原因 | 起きやすい状況 | 最初に見るポイント |
|---|---|---|
| TLS 1.2 が無効／暗号設定が古い | 古いPC、調整済みのセキュリティ設定、レジストリ変更後 | インターネット オプションの「TLS 1.2」 |
| プロキシ / VPN / 会社のネットワーク制御 | 社内LAN、在宅VPN、ゼロトラスト／CASB利用 | WinHTTPプロキシ設定、VPNの一時停止 |
| Windows Update のキャッシュ破損 | 更新失敗を繰り返した、途中で電源断、ストレージ逼迫 | SoftwareDistribution / catroot2 のリセット |
| システムファイル破損 | 強制終了、ストレージエラー、長期間更新していない | SFC / DISM |
| 日時ずれ（証明書検証に失敗） | CMOS電池劣化、手動設定、VPN接続直後 | 時刻同期（w32tm） |
| セキュリティソフトの通信遮断 | 新規導入直後、アップデート直後、ネットワーク保護機能有効 | 一時停止して再試行（検証目的） |
作業前の注意
- 以下の手順は 管理者権限 が必要なものがあります。管理者としてサインインして作業してください。
- 業務PCや管理下の端末（会社のポリシー適用、WSUS/Intune等）では、プロキシや更新設定を勝手に変えると業務影響が出る場合があります。判断に迷う場合は管理者に確認してください。
- 不安な場合は、事前に復元ポイント作成や重要データのバックアップを行ってください。
最短で直すための実施順
0x80072EFF は「通信・暗号・キャッシュ」が中心なので、手当たり次第ではなく、切り分けしながら上から潰すのが効率的です。
| 推奨順 | やること | 狙い | 失敗しやすいポイント |
|---|---|---|---|
| 1 | 日時・ネットワークの基本確認 | 証明書検証／接続不可の初歩ミスを排除 | VPN・プロキシが暗黙で有効になっている |
| 2 | SFC / DISM | 更新基盤が壊れているケースを先に潰す | DISMはWindows 8以降が主対象 |
| 3 | Windows Update トラブルシューティング | サービスや設定の不整合を自動修復 | 管理ポリシー環境では直らないことも |
| 4 | Windows Update コンポーネントのリセット | キャッシュ破損・カタログ破損を解消 | サービス停止に失敗する場合は再起動後に実施 |
| 5 | TLS 1.2 / SSL 設定の見直し | 暗号化通信（ハンドシェイク）失敗を解消 | SSL 2.0/3.0は有効化しない |
| 6 | プロキシ / VPN / セキュリティソフトの切り分け | 経路遮断・検査による失敗を特定 | 会社PCは勝手に解除しない |
| 7 | ネットワークスタックのリセット | Winsock/DNS/IPの不整合を解消 | 再起動が必須 |
| 8 | ログ確認／手動更新（最終手段） | 原因特定・回避インストール | KBやビルドの取り違え |
日時とネットワークの基本を確認する
Windows Update は証明書（HTTPS）で相手が本物か検証します。日時がずれるだけで失敗することがあるため、まず最短でチェックします。
| チェック項目 | 確認方法 | 目安 |
|---|---|---|
| 日付・時刻・タイムゾーン | 設定 → 時刻と言語 → 日付と時刻 | 自動設定をON、明らかなずれがない |
| 時刻同期 | 管理者のコマンドで再同期 | 同期後に更新が通ることがある |
| インターネット接続 | ブラウザでHTTPSサイトを複数表示 | 社内ポータルだけでなく外部HTTPSに接続できる |
| キャプティブポータル | 公衆Wi-Fi/ホテル/ゲストWi-Fi | ログイン画面が必要な回線は更新に不向き |
時刻再同期は、管理者としてコマンドプロンプトを開き、次を実行します。
w32tm /resyncシステムファイルを修復する（SFC / DISM）
更新そのものに入る前に、Windows の土台（システムファイル）が壊れているケースを排除します。SFC は「まずやる基本」として優先度が高く、ここで直る場合もあります。
| コマンド | 対象 | 期待できる効果 |
|---|---|---|
sfc /scannow | 全Windows | 破損した保護システムファイルの修復 |
DISM /Online /Cleanup-Image /RestoreHealth | 主にWindows 8/10/11 | コンポーネントストア破損の修復（SFCが直りきらない時に有効） |
管理者のコマンドプロンプトで、まず SFC を実行します。
sfc /scannowSFCで「修復できませんでした」と出る、または更新基盤が不安定な場合は、続けて DISM を実行します（Windows 10/11 なら特に有効です）。
DISM /Online /Cleanup-Image /RestoreHealth実行後は再起動し、Windows Update を再試行してください。ここで改善する場合、0x80072EFF の根っこは「通信」ではなく「更新基盤の破損」だった可能性が高いです。
Windows Update のトラブルシューティングを実行する
Windows の診断ツールは、更新サービスの状態、レジストリ設定、キャッシュの軽微な不整合などを自動修正できることがあります。短時間で試せるため、SFC/DISM の次に挟むのが現実的です。
| OS | 手順 |
|---|---|
| Windows 11 | 設定 → システム → トラブルシューティング → その他のトラブルシューティング → 「Windows Update」 |
| Windows 10 | 設定 → 更新とセキュリティ → トラブルシューティング → 追加のトラブルシューティング ツール → 「Windows Update」 |
| 古い表示（コントロールパネル） | コントロールパネル → トラブルシューティング → システムとセキュリティ → 「Windows Update」 |
実行後は、表示された「修復済み」「適用済み」の内容を確認し、PCを再起動してから更新を再試行します。
Windows Update コンポーネントをリセットする（効くことが多い）
0x80072EFF は通信が原因になりやすい一方で、実際の現場では 更新キャッシュやカタログの破損 が引き金になっているケースも多いです。更新が失敗し続けると SoftwareDistribution や catroot2 内のデータが不整合を起こし、以後の更新が連鎖的に失敗します。
次の手順は、更新関連サービスを停止し、キャッシュを退避してから再作成させる定番の対処です。
実行前のポイント
- 管理者のコマンドプロンプトで実行します。
- 途中で「サービスが停止できない」場合は、再起動直後にもう一度実行すると成功しやすいです。
- フォルダ名の変更（.old 退避）にしているため、万一必要なら元に戻せます。
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実行後は再起動し、Windows Update を再試行します。更新の「確認」に時間がかかったり、最初のダウンロードが遅く感じる場合がありますが、キャッシュ再構築中の挙動としては正常です。
さらに詰めたい場合（任意）として、BITSキューが壊れているときは次も効くことがあります。
Del "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr*.dat"SSL/TLS 設定を見直す（0x80072EFF の本命になりやすい）
Windows Update は HTTPS で Microsoft の更新サーバーに接続します。ここで TLS が無効になっている、または暗号化方式が古すぎると、サーバーとのハンドシェイクが成立せず 0x80072EFF になりやすくなります。
確認手順は次のとおりです。
- コントロールパネル → 「インターネット オプション」
- 「詳細設定」タブを開く
- 「セキュリティ」欄で 「TLS 1.2 を使用」 にチェック
- 適用 → OK → 再起動
- Windows Update を再試行
| 項目 | 推奨 | 理由 |
|---|---|---|
| TLS 1.2 | 有効 | 現行のMicrosoftサービスで前提になることが多い |
| TLS 1.1 / TLS 1.0 | 環境により | 古い環境との互換性用途。基本は1.2を軸にする |
| SSL 3.0 / SSL 2.0 | 無効のまま | 古く危険なため。トラブル回避のために有効化する運用は推奨しない |
「全部有効化したら直った」という情報を見かけることがありますが、SSL 2.0/3.0 の有効化はセキュリティ上のリスクが大きいです。まずは TLS（特に 1.2）を優先して見直してください。
補足：古いOSでTLS 1.2が選べない／効かない場合
もし Windows 7 など古いOSで TLS 1.2 の項目が見当たらない、または有効化しても改善しない場合、OS自体がサポート終了していたり、暗号基盤の更新が足りない可能性があります。サポートが切れているOSは更新サーバー側の要件変更に追従できず、同様のエラーで詰まることがあります。可能なら、サポート中のWindowsへ移行するのが根本解決です。
プロキシ / VPN / セキュリティソフトを切り分ける
0x80072EFF を「通信エラー」として扱うなら、次に疑うのは プロキシ／VPN／フィルタリングです。特に社内ネットワークでは、ブラウザは通るのに Windows Update だけ通らないことがあります（WinHTTPのプロキシ設定が別扱いになるため）。
まずは一時的に遮断要因を外して試す
- VPN を切断して再試行（在宅VPN利用時は特に）
- プロキシを一時的に無効化して再試行
- セキュリティソフトの「Web保護」「SSL検査」「通信保護」を一時停止して再試行（検証目的）
WinHTTP プロキシ設定を確認する
管理者のコマンドプロンプトで、まず現在の設定を確認します。
netsh winhttp show proxyもし意図しないプロキシが入っている、または一時的にプロキシを外して検証したい場合は次を実行します（企業環境では管理者へ確認のうえ実施してください）。
netsh winhttp reset proxyなお、IE/Edge の「インターネット オプション」に設定されたプロキシと、WinHTTP のプロキシは別物です。ブラウザの通信は通るのに Windows Update が失敗する場合、WinHTTP側だけが詰まっていることがあります。
Windows Update 関連サービスの状態を確認する
更新で必須となるサービスが停止している、またはスタートアップの設定が崩れていると、通信以前に失敗します。次のサービスが想定どおりになっているか確認します。
| サービス名 | 表示名（services.msc） | 役割 | 目安 |
|---|---|---|---|
| wuauserv | Windows Update | 更新の検索・ダウンロード・インストール | 手動（トリガー開始）/ 実行中になる |
| BITS | Background Intelligent Transfer Service | バックグラウンド転送 | 手動 / 実行中になる |
| cryptSvc | Cryptographic Services | 署名・証明書・カタログ処理 | 自動 / 実行中になる |
| msiserver | Windows Installer | MSIインストール関連 | 手動 / 必要時に起動 |
確認は次のどちらでも構いません。
- GUI：
services.msc（サービス）から状態を確認 - CUI：管理者コマンドで確認
sc query wuauserv
sc query bits
sc query cryptsvc
sc query msiserverネットワークスタックをリセットする（DNS/Winsock/IP）
プロキシやTLSの設定が正しいのに更新が通らない場合、DNSキャッシュやWinsockの破損、IP設定の不整合が原因になっていることがあります。次のコマンドは「通信経路の土台」を初期化するイメージで、更新トラブルにも有効です。
| 目的 | コマンド | 補足 |
|---|---|---|
| DNSキャッシュのクリア | ipconfig /flushdns | 名前解決の不整合を解消 |
| Winsockのリセット | netsh winsock reset | 通信ソケットの設定破損に効く |
| IPスタックのリセット | netsh int ip reset | TCP/IP設定を初期化 |
管理者のコマンドプロンプトで、上から順に実行します。
ipconfig /flushdns
netsh winsock reset
netsh int ip reset実行後は必ず再起動し、Windows Update を再試行します。
Microsoft Store が絡む場合の追加対処
「Windows Update だけでなく Microsoft Store の更新も怪しい」「ストアアプリの更新が詰まっている」など、ストア側の不調が同時に起きている場合は、次を追加で試す価値があります（必須ではありません）。
| 対処 | やること | 狙い |
|---|---|---|
| Storeキャッシュのリセット | wsreset.exe を実行 | ストア更新のキャッシュ不整合を解消 |
| Storeの再登録（上級者向け） | PowerShell（管理者）で再登録コマンドを実行 | ストア関連コンポーネントの再構成 |
再登録（任意）は、PowerShell を管理者で開き、次を実行します。
Get-AppxPackage -allusers Microsoft.WindowsStore | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml"}ログで原因を絞る（再発や長期化を防ぐ）
「いろいろ試したが再発する」「社内環境でなぜか特定端末だけ失敗する」場合、闇雲な対処よりもログから原因を絞るほうが早いことがあります。Windows Update はイベントログに手がかりが残ります。
- イベント ビューアー → Windows ログ → システム
- アプリケーションとサービス ログ → Microsoft → Windows → WindowsUpdateClient → Operational
さらに Windows 10/11 では、Windows Update ログを生成して確認できます。
Get-WindowsUpdateLogログに出てくるエラーが 0x80072EFF 以外（例：0x80072F8F など）に派生している場合、切り分けの方向が変わることがあります。代表的な関連エラーの目安を表にまとめます。
| エラー例 | 意味の傾向 | 優先して見るポイント |
|---|---|---|
| 0x80072EFF | 接続が確立できない／途中で中断 | TLS、プロキシ、VPN、フィルタリング、キャッシュ |
| 0x80072F8F | 証明書検証（時刻・TLS・証明書）系 | 日時、TLS、ルート証明書、SSL検査 |
| 0x8024402C | プロキシ/WSUS設定不整合のことが多い | WinHTTPプロキシ、WSUS/GPO |
| 0x8024a105 | 更新コンポーネントの停止・不整合 | サービス状態、リセット、SFC/DISM |
どうしても直らない場合の現実的な回避策
環境要因（社内プロキシ、SSL検査、ポリシー）の壁が厚い場合、Windows Update の経路にこだわるより「必要な更新プログラムを手動で当てる」ほうが早いことがあります。
Microsoft Update Catalog から手動で更新する
累積更新プログラム（例：KBから始まる番号）を手動で入れる手順の流れは次のとおりです。
- Windows のバージョン（例：Windows 11 23H2）とビルドを確認する（設定 → システム → バージョン情報）
- Windows Update の画面に出ているKB番号を控える
- Microsoft Update Catalog で該当KBを検索し、OSとアーキテクチャ（x64/ARM64）に合うものを入手
- 適用後に再起動
この方法で更新が入るなら、端末自体は更新できる状態であり、0x80072EFF は「通常の更新経路（通信・設定）」側に問題があると判断できます。
企業PC（WSUS/管理ポリシー）での注意点
会社支給PCで次に当てはまる場合、端末側でどれだけ頑張っても直らないことがあります。
- 更新サーバーが社内WSUS固定になっている（外部Microsoftに出ない）
- 証明書の差し替え（SSLインスペクション）をしている
- プロキシが必須だがWinHTTP側に正しく入っていない
- ゼロトラスト製品やEDRが更新通信だけをブロックしている
この場合は、イベントログと netsh winhttp show proxy の結果、発生時刻、ネットワーク種別（社内/自宅/テザリング）を添えて管理者へ相談すると、解決までが早くなります。
再発防止のポイント
- TLS設定を「動作確認のために全部ON」にせず、TLS 1.2 を中心に安全な構成を維持する
- 時刻同期を自動に戻す（ノートPCで時計がずれやすい場合は特に）
- 更新失敗を繰り返している端末は、早めに Windows Update コンポーネントのリセットを実施する
- VPN/プロキシ環境では、更新時だけでも正しい経路になるよう運用（分割トンネルの可否など）を見直す
0x80072EFF は「更新できない＝OSが壊れた」と決めつけるより、通信の前提（TLS・プロキシ・時刻）と更新の前提（キャッシュ・サービス・システムファイル）を順に整えることで解消しやすいエラーです。上から順番に潰していけば、原因を切り分けながら最短で復旧できるはずです。
コメント