MENU

Windows Updateの過去履歴をPowerShellで確認・保存する方法｜Get-HotFixとの違い

Windows

Windows Updateの過去の実行履歴と、Get-HotFixで取得する現在の更新情報は別の記録なので、一方だけで全期間の適用を証明できません。 設定画面、Windows Update Agentの履歴、CBS由来の更新一覧、イベント/診断ログを目的別に比較します。古い情報が見えない場合も、「3か月で一律に消える仕様」や「表示されない＝未適用」とは断定しません。残っている記録を取得し、これからの保存運用を整えることが基本です。

目次

目的別に確認手段を選ぶ

知りたいこと確認する記録限界
画面で最近の更新を確認設定のWindows Update→更新の履歴過去の全記録が揃うことを保証しない
成功・失敗・削除を含む更新の実行履歴Windows Update AgentのQueryHistoryPCに残る履歴。現在のインストール状態とは別
現在確認できるCBS由来の更新Get-HotFix全製品・ドライバー・全過去履歴ではない
失敗した時刻と詳細WindowsUpdateClient等のイベント、WindowsUpdate.log/CBS.log保存容量や残存ログの範囲に依存
1年前の適用日を証明当時保存した出力・ログ・管理レポートとの照合現在の結果から失われた履歴を復元する保証はない

1．設定画面と、現在の版を記録する

Windows 11では［設定］→［Windows Update］→［更新の履歴］を開き、必要な更新名・KB・日付・結果を確認します。Windows 10では［更新とセキュリティ］→［Windows Update］の履歴を確認します。公式FAQに沿って、画面の情報と取得時点を保存してください。

［更新プログラムをアンインストールする］の一覧は、現在削除できる更新を確認するための画面です。成功・失敗を含む過去の全履歴を保存した一覧とは違います。コントロールパネルで別の画面へ移る版もあるため、そこに表示されないことだけで未適用と判断しません。履歴を調べる目的なら削除操作は不要です。

古い情報がない場合は、OSの再インストール、機能更新、更新データの初期化等を行った記録があるか調べます。ただし、特定のクリーンアップ操作が原因だったと、証拠なしに確定しないでください。履歴のためにSoftwareDistributionを削除すると、調査したい記録を失う可能性があります。

2．Get-HotFixで、現在確認できる更新を取得

Get-HotFixの公式資料は、Win32_QuickFixEngineeringを利用し、CBS（Component Based Servicing）由来の更新を返すと説明しています。WindowsのローカルPCで次のように確認します。

Get-HotFix | Select-Object Source, Description, HotFixID, InstalledBy, InstalledOn

HotFixIDは更新識別子、InstalledOnは出力で確認できるインストール日です。これは過去に実行したすべての更新の時系列表ではありません。失敗した試行、アンインストールした更新、MSI等の別方式の更新や各製品の履歴を、このコマンドだけで網羅できません。空欄の値や表示されないKBは、そのまま未確認として扱います。

上書きを避けて、取得時点のCSVを保存

次の例は、新しい保存フォルダーを作り、出力と取得日時を保存します。Windows PowerShell 5.1を想定した例です。保存先は利用環境に合う場所へ変更し、ローカルに書き込む権限を確認します。個々のコマンドに権限不足が出た場合はエラーを記録し、必要な権限を管理者へ確認してください。

$auditDir = Join-Path $env:TEMP ('WU-Audit-' + (Get-Date -Format 'yyyyMMdd-HHmmss') + '-' + [guid]::NewGuid().ToString('N'))
New-Item -ItemType Directory -Path $auditDir -ErrorAction Stop | Out-Null
$collectedAt = (Get-Date).ToString('o')
Get-HotFix -ErrorAction Stop |
    Select-Object Source, Description, HotFixID, InstalledBy, InstalledOn |
    Export-Csv -LiteralPath (Join-Path $auditDir 'hotfix-current.csv') -NoTypeInformation -Encoding UTF8
[pscustomobject]@{
    Computer = $env:COMPUTERNAME
    CollectedAt = $collectedAt
    Method = 'Get-HotFix / Win32_QuickFixEngineering'
    PowerShell = $PSVersionTable.PSVersion.ToString()
} | ConvertTo-Json | Set-Content -LiteralPath (Join-Path $auditDir 'collection-info.json') -Encoding UTF8
$auditDir

一時フォルダーへの保存だけでは長期保管になりません。出力を確認してから、組織が定める保管先へ移します。CSVをExcelで開いて日付の見え方を変えても、取得直後の原本は別に残してください。InstalledOnの空欄、機種ごとの形式や取得エラーを、既知の日付で埋めません。

3．PowerShellで成功・失敗を含むWindows Update履歴を読む

Windows Update AgentのQueryHistoryは、PCに残る更新イベントを新しい順に取得します。上の保存例の後に、同じPowerShellセッションで以下を実行する想定です。更新の検索・導入・アンインストールを実行するコードではありません。

$wuSession = New-Object -ComObject Microsoft.Update.Session
$wuSearcher = $wuSession.CreateUpdateSearcher()
$historyCount = $wuSearcher.GetTotalHistoryCount()
$historyRows = @(for ($offset = 0; $offset -lt $historyCount; $offset += 200) {
    $take = [Math]::Min(200, $historyCount - $offset)
    foreach ($entry in $wuSearcher.QueryHistory($offset, $take)) {
        [pscustomobject]@{
            Date = $entry.Date.ToString('o')
            Title = $entry.Title
            Operation = [int]$entry.Operation
            ResultCode = [int]$entry.ResultCode
            HResult = ('0x{0:X8}' -f [int]$entry.HResult)
        }
    }
})
[pscustomobject]@{AvailableHistoryCount = $historyCount; ExportedRows = $historyRows.Count}
if ($historyRows.Count -gt 0) {
    $historyRows | Export-Csv -LiteralPath (Join-Path $auditDir 'wu-history.csv') -NoTypeInformation -Encoding UTF8
} else {
    Write-Warning '取得できる更新履歴が0件です。未適用の証明ではありません。'
}

0件のときはQueryHistoryに0を渡さない構成です。記録の数と取得した行数を確認します。実行中に更新履歴が変化したりCOMエラーが出たりした場合、途中の結果を完全な一覧として提出せず、エラーと取得時点を残します。本稿では構文を確認していますが、対象PCの履歴件数やCOM取得は実機検証していません。

値意味
Operation：1／2インストール／アンインストール
ResultCode：0／1未開始／処理中
ResultCode：2成功
ResultCode：3完了したがエラーあり。単純な成功とまとめない
ResultCode：4／5失敗／中止

番号の意味はOperationResultCodeとUpdateOperationの公式定義を確認します。成功したインストールの記録があっても、その後に削除、別の更新への置き換え、ロールバック等が起きていないかを現在の状態と照合します。失敗の行を先に除いて保存すると、試行履歴の証拠が欠けます。

4．イベントログと診断ログを補完する

イベントビューアーでは、［アプリケーションとサービスログ］→［Microsoft］→［Windows］→［WindowsUpdateClient］→［Operational］等を確認します。環境でそのログが存在・有効か、容量と保存モードはどうなっているかを先に調べます。次の例は設定の読み取りと、直近100件の表示です。全期間の取得と呼ばないでください。

$logName = 'Microsoft-Windows-WindowsUpdateClient/Operational'
Get-WinEvent -ListLog $logName -ErrorAction Stop |
    Select-Object LogName, IsEnabled, RecordCount, LogMode, MaximumSizeInBytes
Get-WinEvent -LogName $logName -MaxEvents 100 -ErrorAction Stop |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

Get-WinEventの公式資料には、ログ情報を列挙する方法と、権限不足で読めない場合の注意があります。ログが空、無効、対象がない、アクセス拒否という状態を区別します。エラーを無視して「更新失敗がない」と結論づけません。

残るイベントをEVTXで保管する場合、同じ保存フォルダーへ次のように出力できます。wevtutilのeplはログのエクスポートです。clによる消去ではありません。

wevtutil.exe epl 'Microsoft-Windows-WindowsUpdateClient/Operational' (Join-Path $auditDir 'WindowsUpdateClient.evtx')
if ($LASTEXITCODE -ne 0) { throw 'EVTX出力に失敗しました。終了コードと権限を確認してください。' }

更新の通信や導入エラーの詳細が必要な場合、Windows Updateログの公式説明と照合し、残っているETLやCBS.logを確認します。次の例は残存するETLを読みやすいログへ変換し、ファイルを書き出します。

Get-WindowsUpdateLog -LogPath (Join-Path $auditDir 'WindowsUpdate.log')

変換結果は取得時点の静的なログで、あとから自動で更新されません。元のETLが残っていない過去の期間を復元する機能でもありません。コマンドの資料にある-ForceFlushは更新サービスを止める処理を含むため、単に履歴を保存する本例では指定していません。ログは障害調査の補完資料で、全更新の適用台帳とは分けます。

古いKBが出ないときの判断

  • KBがどのWindowsの版・エディション・製品に向けたものかを公式資料で確認します。
  • 今のOSの版・ビルド、現在の更新情報、当時保存した履歴や管理レポートを比較します。
  • Get-HotFixにないものは、そのコマンドの取得対象外か、現在の状態と異なるのかを調べます。
  • 履歴の成功行だけで現在の適用を断定せず、逆に古いKBが見えないだけで未適用と断定しません。
  • 残っていない当時の日時は、確認不能と報告します。現在取得したCSVを当時の証拠として日付を変えません。

Securityを含む行だけで、全セキュリティ更新を証明できる？

Get-HotFix | Where-Object { $_.Description -like "*Security*" }

この例はGet-HotFixのDescriptionにSecurityを含む行を絞るだけです。全セキュリティ更新や脆弱性対策の網羅性を証明しません。まず絞る前の原本を保管し、対象OSと更新の公式KB、管理側の適用状態を照合します。

長期保存を、取得時点と方法が分かる形で運用

保存項目記録する内容
取得対象端末識別子、OSの版/エディション/ビルド、対象範囲
取得時点日時とタイムゾーン、担当者、再起動の前後
取得方法コマンド/画面、PowerShell版、件数、エラー
記録の種類現在の更新一覧／試行履歴／イベント／診断ログを区別
保存運用原本、アクセス権、必要な保存期間、更新や初期化前の取得

定期的な取得と、更新適用後・大きな変更前の保存を組み合わせます。ログには端末名・ユーザー名・内部のパス等が含まれる可能性があるため、社内ルールに従って保管します。公の質問や記事コメントへ、そのままCSVやログを貼らないでください。

多数の端末では、既に運用しているIntuneやConfiguration Manager等のレポートと端末側の出力を照合します。Windows Update for Business reportsの公式案内では、データ更新が24時間ごと、最近28日間に確認された端末の情報を反映すると説明されています。管理サービスにも更新の遅延や保存範囲があります。導入すれば、過去に保存していなかった1年前の証拠を自動で復元できるという意味ではありません。

公式資料

Windows
PowerShell セキュリティ Windows Update

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次