Windows 11 の累積更新プログラムが「ダウンロード中」や「インストール中」のまま進まない、再起動しても毎回同じ更新に失敗する――そんなとき、意外な犯人が「Windows イベント ログ」サービスの起動状態です。この記事では、サービスを手動や無効にしたことがきっかけで Windows Update が失敗するケースを例に、原因の仕組みから具体的な復旧手順、再発防止策までを実務目線で整理します。
Windows Updateが進まないときによくある症状
まずは、今回のように「Windows イベント ログ（Windows Event Log）」が原因になっているときに見られやすい症状を整理します。必ずしもすべてが当てはまるとは限りませんが、複数当てはまる場合はイベント ログ サービスの状態を疑う価値があります。
| 症状 | 具体的な状況 |
|---|---|
| 進行バーが止まる | 「インストール中 20%」などの表示から数十分～数時間動かない |
| 再起動後にロールバック | 「更新を元に戻しています」「以前のバージョンの Windows を復元しています」と表示され、更新がなかったことになる |
| 同じ更新が何度も出る | 累積更新プログラムが毎回失敗し、Windows Update に同じ KB 番号が繰り返し表示される |
| エラーコードが一定しない | 0x80070005 や 0x800f0922 など、原因がバラバラのように見えるエラーコードが表示される |
| イベント ビューアーにログがほとんどない | トラブルシュートのためにイベント ビューアーを開いても、該当時間帯にログが記録されていない |
こうした症状があり、なおかつ「Windows イベント ログ」サービスの起動種類を「手動」や「無効」に変更した記憶があるなら、その設定を見直すだけであっさり解決する場合があります。
原因：Windows イベント ログ サービスの起動状態
今回のポイントはシンプルです。
- 「Windows イベント ログ」サービス（サービス名：
eventlog）が「手動」または「無効」に変更されている - その状態で Windows 11 の累積更新プログラムを適用しようとすると、更新の途中で処理がうまく進まない、あるいはロールバックしてしまう
- サービスを「自動」に戻して開始したところ、同じ更新プログラムが正常に適用された
つまり「イベント ログを無効・手動にしたことが、Windows Update の失敗を誘発していた」という再現事例です。
Windows イベント ログとは何をしているサービスか
「Windows イベント ログ」は、Windows およびアプリケーションが発生させる各種イベント（情報、警告、エラーなど）を記録する基盤サービスです。イベント ビューアーで閲覧できる各種ログ（システム、アプリケーション、セットアップ、セキュリティなど）は、このサービスが動いていることで初めて記録されます。
| 項目 | 内容 |
|---|---|
| 表示名 | Windows イベント ログ |
| サービス名 | eventlog |
| 役割 | OS やアプリのイベントをログファイルに記録し、イベント ビューアーなどから参照できるようにする |
| 既定の起動の種類 | 自動 |
| 関連機能 | Windows Update、トラブルシューティング、各種監査・監視、セキュリティ対応など |
Windows Update は更新処理の各フェーズでイベントを記録し、その情報をもとにロールバックや再試行、トラブルシュートを行います。このとき記録基盤である「Windows イベント ログ」が無効化されていると、内部処理の一部が正常に完了できず、結果として更新が失敗したり、元に戻されたりすることがあります。
「手動」でもダメなのか？という疑問
「手動（トリガー開始）」にしておけば、必要なときに勝手に起動されるはずなのでは？と考えたくなります。しかし実際には、
- サービスの依存関係や起動順序の問題で、必要なタイミングまでに eventlog が起動していない
- なんらかの理由で eventlog の起動がブロックされている、または失敗している
- サードパーティ製ツールやカスタマイズが影響している
といった要因も絡み、理論上は「手動で必要時に起動される」サービスでも、現実には更新に間に合わないケースがあります。確実に Windows Update を通したいなら、eventlog を「自動」かつ実行中にしておくのが安全です。
最優先ですべき対処：イベント ログサービスを自動＆実行中に戻す
まずは、Windows イベント ログサービスの状態を既定どおりに戻すことから始めます。手順は GUI と PowerShell のどちらでも構いません。
GUIでの設定手順
- Windowsキーを押し、「services.msc」と入力してEnterキーを押す。
- サービスの一覧から「Windows イベント ログ」を探してダブルクリックする。
- 「スタートアップの種類」を「自動」に変更する。
- サービスの状態が「停止」になっている場合は、「開始」ボタンをクリックして起動する。
- OKをクリックしてダイアログを閉じる。
これで eventlog が自動起動＆実行中の状態に戻ります。
PowerShell（管理者）でまとめて設定する
複数台のパソコンで同じ設定を行いたい場合や、サーバー管理者の方は PowerShell で一括設定すると効率的です。
- スタートボタンを右クリックし、「Windows ターミナル（管理者）」または「PowerShell（管理者）」を開く。
- 以下のコマンドを実行する。
Set-Service -Name eventlog -StartupType Automatic
Start-Service -Name eventlog
エラーが出なければ、eventlog の起動種類が自動に変更され、サービスが起動した状態になります。
その後に Windows Update を再実行する
eventlog を自動＆実行中に戻したら、改めて Windows Update を試します。
- 設定 → Windows Update を開く。
- 「更新プログラムのチェック」をクリックする。
- 保留中だった累積更新プログラムのダウンロード・インストール・再起動を完了させる。
多くのケースでは、この時点で以前失敗していた更新が正常に完了するはずです。もし改善が見られない場合は、関連サービスやシステムファイルの状態もあわせて確認していきます。
Windows Updateに影響しやすい関連サービスの確認
Windows イベント ログだけでなく、更新処理に深く関わる他のサービスが無効化されていると、やはり更新は不安定になります。カスタマイズや軽量化ツールを使ったことがある場合は、以下の主要サービスもチェックしておきましょう。
| サービス名（表示名） | サービス名 | 役割の概要 | 推奨する起動種類の目安 |
|---|---|---|---|
| Windows Modules Installer | TrustedInstaller | Windows コンポーネントのインストール・変更・削除を行う中核サービス | 手動（トリガー開始）または自動 ※無効はNG |
| Windows Update | wuauserv | 更新プログラムの検出・ダウンロード・インストールを管理 | 手動（トリガー開始）または自動 ※無効はNG |
| Windows Update Medic Service | WaaSMedicSvc | Windows Update の自己修復を行う補助サービス | 手動（トリガー開始）※基本的に変更しない |
| バックグラウンド インテリジェント転送サービス | BITS | バックグラウンドでの効率的なデータ転送（更新のダウンロード等） | 手動または自動 ※無効はダウンロード失敗の原因に |
| 暗号化サービス | CryptSvc | 更新プログラムの署名検証や暗号化処理に関与 | 手動（トリガー開始）または自動 ※無効はエラーの元 |
これらのサービスが「無効」になっている場合は、少なくとも「手動」以上に戻しておきましょう。不安であれば、既定値に近いであろう「手動（トリガー開始）」または「自動」に統一しておくとよいです。
それでも更新に失敗するときの安全な復旧手順
イベント ログや関連サービスを正しく戻しても更新が失敗する場合、システムファイルの破損や更新コンポーネントの不整合など、より根本的な問題が潜んでいる可能性があります。その場合は、以下のような「定番だが効果が高い」復旧手順を実施します。
システムファイルを修復する（SFC & DISM）
Windows Update に限らず、システムの挙動がおかしいときは、まず SFC（システムファイルチェッカー）と DISM による修復を走らせるのがおすすめです。
- 管理者権限のコマンドプロンプトまたは Windows ターミナルを開く。
- 次のコマンドを順番に実行する。
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow：保護されたシステムファイルをスキャンし、破損している場合は自動修復を試みる。DISM /Online /Cleanup-Image /RestoreHealth：コンポーネントストア（WinSxS）を修復し、更新コンポーネントの不整合を正す。
これらの処理には時間がかかる場合があります。完了したら Windows を再起動し、再度 Windows Update を試します。
更新コンポーネントのリセット（状況に応じて）
より症状が重い場合、SoftwareDistribution フォルダーや Catroot2 フォルダーをリセットすることで改善するケースもあります。これは少し踏み込んだ操作になるため、以下のような点に注意してください。
- 実行前に重要なデータのバックアップを取る。
- 企業環境では、ローカルポリシーやWSUS設定との兼ね合いを考慮する。
- まずは SFC・DISM・サービス設定見直しを行い、それでもダメな場合の「次の一手」として検討する。
一般的な個人利用の範囲では、ここまで手を入れなくても、eventlog を含むサービス設定の見直しと SFC/DISM だけで回復するケースが多い印象です。
ログを活かして原因を深掘りする
Windows イベント ログサービスを有効に戻したあとで更新を再度試すと、その結果がイベント ログにも記録されるようになります。今後同じようなトラブルに備えるためにも、一度ログの場所と読み方を押さえておくと便利です。
代表的なログの場所
| ログ/ファイル | 場所 | 用途 |
|---|---|---|
| CBSログ | C:\Windows\Logs\CBS\CBS.log | コンポーネントベースの更新処理の詳細が記録される。SFC や DISM の実行結果も含まれる。 |
| イベント ビューアー – システム | イベント ビューアー → Windows ログ → システム | Windows Update やサービスの起動・停止、ドライバー関連のエラーなどが記録される。 |
| イベント ビューアー – 設定 | イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → SettingSync など | 設定同期やストアアプリ関連など、より詳細なアプリ・機能ごとのログ。 |
以前に eventlog を無効にしていた期間中の詳細なログは残っていない可能性が高いですが、サービスを有効に戻した状態で改めて再現させることで、次からは原因究明がぐっと楽になります。
なぜ「無効にしない」のがベストプラクティスなのか
「サービスを減らせば軽くなる」「ログは容量を食うから最小限にしたい」という考えから、イベント ログを含む基盤サービスを無効にしてしまうカスタマイズ例は少なくありません。しかし Windows イベント ログは、もはや OS の根幹機能のひとつと言ってよい存在です。
- 更新やドライバーインストールなど、システムレベルの操作の成否を記録する
- セキュリティインシデントや不正アクセスの痕跡を追うための重要な情報源になる
- 障害対応やベンダーへの問い合わせの際、必ずと言っていいほど参照される
これらが記録されない状態は、例えるなら「ブラックボックスの機械を目隠しして動かしている」ようなものです。表面的には動いているように見えても、トラブルが起きた瞬間に手がかりが無くなります。更新の成否だけでなく、セキュリティや運用面から見ても、イベント ログサービスは既定どおり「自動・実行中」を維持することを強くおすすめします。
実際の利用者目線での疑問と要望
今回のような事例では、次のような素朴な疑問・要望が出てきます。
- 「手動にしていても、Windows Update が必要なら自動で起動してくれないの？」
- 「イベント ログを無効にしようとしたときに、『更新が失敗する可能性があります』と警告してほしい」
後者については、まさに製品側への改善要望と言えます。イベント ログに限らず、更新や起動に必須となるコアサービスを無効にするときは、より強い警告があってもよいでしょう。こうした声は、Windows の「フィードバック Hub」アプリから送信することで、実際に開発チームに届きます。
フィードバック Hubで要望を出す手順の一例
- Windowsキーを押し、「フィードバック Hub」と入力して起動する。
- 「フィードバックを送る」を選択し、カテゴリとして「Windows の設定」や「更新とセキュリティ」など適切なものを選ぶ。
- タイトルに「Windows イベント ログを無効にすると更新が失敗しやすい」などと記入し、本文で再現手順や要望内容を具体的に記載する。
- 必要に応じて「再現手順の記録」も行い、送信する。
すぐに仕様が変わるとは限りませんが、実際の利用者からのフィードバックが積み重なることで、将来のバージョンでの改善につながる可能性があります。
予防策：二度と同じトラブルに悩まされないために
最後に、今後同じような「Windows Update が進まない・失敗する」トラブルを避けるための運用上のコツをまとめます。
コアサービスは「いじらない」のが鉄則
- イベント ログ、Windows Update、BITS、暗号化サービスなど、更新に直結するサービスは基本的に既定の起動種類のままにしておく。
- 軽量化やカスタマイズを行う場合でも、「無効」にする前にそのサービスの役割を必ず確認する。
- どうしても一時的に停止・無効化する必要がある場合は、「変更前の状態をメモしておく」ことを習慣にする。
検証用の変更は必ず「元に戻す」
不具合調査などでサービスの状態を変えてみることはありますが、検証環境ならともかく、実機や本番環境では「検証が終わったら元に戻す」ことを徹底します。
- 検証作業の前後で、サービスの状態をスクリーンショットやメモで記録する。
- 作業の最後に「サービス設定を元に戻すチェックリスト」を用意しておく。
- 複数人で運用している場合は、変更内容をチケットや共有ノートに残す。
管理者向け：一括チェック用の PowerShell スクリプト例
企業や組織で複数台の Windows 11 を管理している場合、重要サービスの状態を一括で確認する簡易スクリプトを用意しておくと便利です。例えば、次のようなイメージです。
$services = @(
'eventlog',
'TrustedInstaller',
'wuauserv',
'WaaSMedicSvc',
'BITS',
'CryptSvc'
)
Get-Service -Name $services | Select-Object Name, Status, StartType
このスクリプトを管理者権限の PowerShell で実行すると、主要なサービスの現在の状態と起動種類を一覧で確認できます。異常な設定（無効化されているなど）がないかを定期的にチェックする運用も、トラブル予防に有効です。
まとめ：Windows Updateが進まないときはイベント ログの状態も要チェック
Windows 11 の累積更新プログラムが進まない・失敗する原因は多岐に渡りますが、今回取り上げた「Windows イベント ログサービスの起動状態」は、見落とされがちでありながら、非常に影響が大きいポイントです。
- eventlog を「手動」や「無効」にしていると、更新処理の途中で不具合が起きやすくなる
- サービスを「自動」に戻して起動するだけで、更新が正常に完了するケースがある
- 関連する Windows Update 系サービスの無効化も、同様にトラブルの原因となる
- システムファイルの修復（SFC・DISM）やログの確認で、より根本的な問題の切り分けが可能になる
- 今後のために、コアサービスは原則として「既定設定からいじらない」運用を心がける
もし今まさに Windows Update が進まず困っているのであれば、まずは「Windows イベント ログ」サービスを自動＆実行中に戻すところから始めてみてください。それだけで長時間悩んでいた問題があっさり解消するかもしれません。
コメント