「更新プログラムを適用したら、社内のPCが次々にフリーズした」「タスクバーが消えてログオンすらできない」──そんな悪夢のような報告が、2026年に入ってから企業のIT管理者の間で後を絶ちません。Windows11の月例更新(Patch Tuesday)は、セキュリティを守るために不可欠な存在です。しかし、その更新がかえって業務を止めてしまうリスクがあるとしたら、あなたはどう備えますか?
この記事では、2026年1月から3月にかけて実際に発生した不具合の全体像を整理し、企業PCへの影響範囲を明確にしたうえで、情シス担当者や個人ユーザーが「今日からできる具体的な対策」を徹底解説します。さらに、2026年6月に迫るSecure Boot証明書の期限切れという”時限爆弾”への備え方まで、他の記事では触れられていない深い情報をお届けします。
- 2026年1月〜3月の月例更新で発生した主な不具合と企業PCへの影響範囲の全体像
- 段階展開やロールバックなど、業務を止めないための実践的な7つの対策手順
- 2026年6月のSecure Boot証明書期限切れに向けた事前準備チェックリスト
- そもそもWindows11の月例更新とは何か?なぜ企業PCで問題が起きやすいのか
- 2026年1月の月例更新で何が起きたのか?KB5074109の衝撃
- 2025年末から続いていたMSMQとXAML関連の不具合も忘れてはいけない
- 2026年3月の最新月例更新KB5079473の状況と注意点
- 業務を止めないための7つの実践的対策
- 2026年6月に迫るSecure Boot証明書期限切れへの備え
- 過去の月例更新トラブルから学ぶ傾向と教訓
- 企業のIT管理者が今月すべきアクションまとめ
- 現場で即使える!月例更新トラブル時のPowerShellコマンド集
- 更新失敗時の「鉄板リカバリ手順」を完全解説
- Secure Boot証明書の更新状況をPowerShellで確認する具体的な手順
- Windows Updateがいつまでも終わらないときの「本当の原因」と対処法
- グループポリシーで月例更新を制御する実践テクニック
- 情シスが見落としがちな「月例更新後のチェック項目」
- PSWindowsUpdateモジュールで更新管理を自動化する方法
- 「更新のたびに毎回プリンタが壊れる問題」への根本対策
- Windows11の月例更新と企業PCの対策に関する疑問をさらに深掘り
- ぶっちゃけこうした方がいい!
- Windows11の月例更新と企業PCの対策に関するよくある質問
- 今すぐパソコンやスマホの悩みを解決したい!どうしたらいい?
- まとめ
そもそもWindows11の月例更新とは何か?なぜ企業PCで問題が起きやすいのか
毎月第2火曜日(日本時間では水曜日)にMicrosoftが配信するPatch Tuesday(月例セキュリティ更新)は、Windowsの脆弱性を修正し、PCを安全な状態に保つための更新プログラムです。累積更新(Cumulative Update)という仕組みで配信されるため、前月までの修正がすべて含まれています。つまり、1回の更新を適用するだけで最新のセキュリティ状態になれるわけです。
ところが、企業環境では「更新を当てたら動かなくなった」というトラブルが個人PCよりも格段に起きやすい傾向があります。その最大の理由は、企業PCの複雑さにあります。プロビジョニング(大量展開のための設定テンプレート)、VDI(仮想デスクトップ)、グループポリシー、サードパーティ製セキュリティソフト、業務アプリケーション──これらが複雑に絡み合っているため、更新プログラムがどこかの依存関係を崩すと、連鎖的にトラブルが広がってしまうのです。
個人のPCであれば「再起動したら直った」で済む話も、数百台・数千台を管理する企業では「朝出勤したら全フロアのPCが使えない」という業務停止レベルの事態になりかねません。だからこそ、月例更新の影響範囲を事前に把握し、段階的に展開する戦略が不可欠なのです。
2026年1月の月例更新で何が起きたのか?KB5074109の衝撃
2026年最初のPatch Tuesdayとなった1月13日配信のKB5074109は、114件規模の脆弱性修正を含む大型アップデートでした。しかし適用後、複数の深刻な不具合が次々と報告されました。
リモートデスクトップ接続の認証失敗
Azure Virtual Desktop(AVD)やWindows 365といったクラウドPC環境で、サインイン時に認証が失敗するという問題が発生しました。Windows AppなどのRemote Desktop系アプリで認証フローが崩れ、業務でリモート接続を多用している企業にとっては致命的なトラブルとなりました。Windows11の25H2・24H2だけでなく、Windows10のESU環境やWindows Server 2025でも報告が広がり、影響範囲はかなり広かったといえます。
Microsoftは1月17日に緊急のOut-of-band(OOB)更新を配信して修正対応を行いました。該当する環境ではWindows Updateに自動表示される場合がありますが、環境によってはMicrosoft Update Catalogから手動でダウンロードする必要があったため、対応が遅れた現場も少なくなかったようです。
シャットダウンできない・電源が落ちない問題
「シャットダウン」や「休止状態」を選んでも電源が落ちず、再起動してしまう、あるいはノートPCが夜間に勝手に起動状態のまま放置されてバッテリーが消耗する──そんな報告も相次ぎました。Microsoftの説明では、Secure Launchが有効な端末で発生する電源周りの不具合とされています。こちらもKB5077797などのOOB更新で修正が提示されましたが、一般ユーザーへの周知が遅れた点は課題として残りました。
Outlook(クラシック)のフリーズ
POPアカウントやPSTファイルを使っている環境、特にPSTファイルをOneDrive上に配置している場合に、Outlook(クラシック版)が「応答なし」状態になるという問題も発生しました。リモートデスクトップや電源の問題と違い、こちらは緊急パッチではなく回避策の徹底が求められる状況が続きました。具体的には、PSTファイルをOneDriveの配下からローカルドライブに移動させることが推奨されています。
2025年末から続いていたMSMQとXAML関連の不具合も忘れてはいけない
MSMQサービスの障害とその修正経緯
2025年12月の更新プログラム(KB5071546など)の適用後、企業の業務システムで使われることが多いMSMQ(Microsoft Message Queuing)サービスが正常に動作しなくなる重大な不具合が発生していました。Microsoftは12月18日にOOBパッチ(KB5074976)をリリースして対応しましたが、累積更新の性質上、この修正は2026年1月以降の月例更新にも取り込まれています。MSMQを利用している環境では、更新後に
C:\Windows\System32\msmq\storage
フォルダのアクセス権限を必ず確認し、イベントビューアで「Insufficient resources」エラーが出ていないかチェックすることが重要です。
XAMLコンポーネントの初期化失敗による企業PC大規模障害
2025年7月以降のWindows11 24H2/25H2向け累積更新を適用後にプロビジョニングされたEnterprise版PCで、タスクバーが表示されない、スタートメニューが開かない、エクスプローラーが起動直後にクラッシュするという極めて深刻な問題が報告されています。最悪の場合、ログオンしても真っ黒な画面のままシェルが立ち上がりません。
原因は、WindowsのXAML(Extensible Application Markup Language)パッケージが正しく登録される前に、それに依存するアプリケーションが起動してしまうことにあります。特にVDI(仮想デスクトップ)のような非永続環境では、ログオンのたびにこの状態に陥るリスクがあり、企業にとっては「キッティング済みPCを一斉配布した直後に発覚する」という最悪のシナリオも現実になり得ます。Microsoftは公式ドキュメント(KB5072911)で問題を認識し、XAMLパッケージの再登録スクリプトを暫定策として公開しています。
2026年3月の最新月例更新KB5079473の状況と注意点
2026年3月10日に配信されたKB5079473は、Windows11の24H2と25H2を対象とした累積更新で、79〜84件の脆弱性修正を含む重要なアップデートです。2件のゼロデイ脆弱性(CVE-2026-21262SQL Serverの特権昇格、CVE-2026-26127.NETのサービス拒否)の修正に加え、Officeのプレビューペインを開くだけでリモートコード実行が可能になるCVE-2026-26113とCVE-2026-26110も含まれており、セキュリティ的には「絶対にスキップできない月」です。
報告されている不具合の実態
配信直後から、フォーラムやコミュニティで「フリーズ」「BSOD(ブルースクリーン)」「アプリケーションクラッシュ」の報告が上がりました。ただし、ここは冷静に見る必要があります。Windows Latestの調査によると、これらの報告は10件未満のユーザーからの声に基づいており、10億台以上が稼働するWindows全体から見れば極めて少数です。Microsoftに確認したところ、KB5079473に起因するBSODや再起動ループは認識していないとの回答がありました。
一方で、Samsung製PCでCドライブにアクセスできなくなる問題が同時期に発生し、当初はKB5079473が原因と疑われましたが、Microsoftの調査の結果、これはSamsung Galaxy Connectアプリの不具合が原因であることが判明しています。月例更新と同時期にベンダーアプリの不具合が重なると、切り分けが難しくなる好例です。
企業環境で特に注意すべきポイント
KB5079473は約4.5GBという大容量の更新です。メモリやストレージが限られた端末、回線が細い拠点では、ダウンロードとインストールにかなりの時間がかかります。また、一部でMIDI機器が動作しなくなる報告や、インストール時に
0x80070306
エラーで失敗するという報告もあります。企業環境では、GPUドライバやセキュリティソフトとの互換性に注意しつつ、必ず段階的に展開することが鉄則です。
なお、3月15日にはEnterprise向けにホットパッチ更新KB5084597がリリースされ、RRAS(ルーティングとリモートアクセスサービス)のリモートコード実行脆弱性3件が再起動なしで修正されています。ホットパッチプログラムに登録しているEnterprise端末は自動適用されますが、登録していない環境では通常の3月パッチで修正済みです。
業務を止めないための7つの実践的対策
ここからは、企業のIT管理者が月例更新を安全に運用するための具体的な対策を紹介します。個人ユーザーにとっても参考になる内容を含んでいますので、ぜひ最後まで読んでください。
対策1段階展開(リング展開)を徹底する
まず、更新プログラムを「全台一斉」に適用するのは絶対に避けてください。先行検証グループ(パイロットリング)に10〜20台ほどのPCを設定し、1〜3日間の動作確認を行ったうえで、問題がなければ部門単位で順次展開するのがベストプラクティスです。Windows Update for Business(WUfB)やMicrosoft Intuneを使えば、この展開リングの管理を自動化できます。
対策2更新前に必ずシステム復元ポイントを作成する
万が一のロールバックに備えて、更新適用前にシステム復元ポイントを作成しておきましょう。企業環境では、バッチスクリプトやグループポリシーを使って全端末に自動で復元ポイントを作成させる運用が効果的です。
対策3更新履歴のKB番号と既知の問題を必ず確認する
更新適用後は、
設定 → Windows Update → 更新の履歴
で、適用されたKB番号を確認してください。そのKB番号でMicrosoftの公式サポートページを検索すれば、既知の問題と回避策の最新情報が得られます。
対策4イベントビューアによるログ監視を習慣化する
更新直後に
eventvwr.msc
を開き、「システム」ログと「アプリケーション」ログにエラーや警告が出ていないか確認します。特にMSMQを使っている環境では「Insufficient resources」、Secure Boot関連では「TPM-WMI」ソースのイベントID 1801が繰り返されていないかが重要な確認ポイントです。
対策5KIR(Known Issue Rollback)を理解しておく
KIRとは、問題のある更新プログラム全体をアンインストールしなくても、問題の部分だけをMicrosoft側からリモートで無効化できる仕組みです。一般向けPCでは放っておけば最大24時間以内に自動修正されますが、企業管理下のPCでは専用のグループポリシーをインストール・設定する必要があります。KIRの存在を知っているかどうかで、障害発生時の初動対応の速さが大きく変わります。
対策6更新プログラムのアンインストール手順を事前に準備する
最悪の場合、更新プログラム自体を削除する必要があります。
設定 → Windows Update → 更新の履歴 → 更新プログラムをアンインストールする
から該当のKB番号を選択して削除できます。起動できない場合は、Windows回復環境から「トラブルシューティング → 詳細オプション → 更新プログラムのアンインストール」で対応します。企業管理者はWSUSやIntuneで対象KBを除外する設定も用意しておきましょう。
対策7ドライバとファームウェアを事前に最新化する
2026年3月のKB5079473で見られたように、更新プログラム自体ではなく、古いドライバやベンダーアプリとの互換性問題がトラブルの原因になることが多々あります。特にGPUドライバ、チップセットドライバ、ストレージコントローラドライバは、更新プログラム適用前に最新版にしておくことで、多くの問題を未然に防げます。
2026年6月に迫るSecure Boot証明書期限切れへの備え
月例更新の不具合対策と並んで、企業のIT管理者が今すぐ動くべき問題がもうひとつあります。それが、Secure Boot証明書の期限切れです。
2011年に発行されたMicrosoftのSecure Boot証明書(KEK CA 2011、Windows Production PCA 2011、UEFI CA 2011)は、2026年6月から順次有効期限を迎え、10月までにすべて失効します。証明書が更新されないまま期限を過ぎると、Windowsブートマネージャーのセキュリティ更新が受けられなくなり、ブートレベルの脆弱性(BlackLotusなど)に対する保護が失われます。
重要なのは、PCが起動できなくなるわけではないという点です。Secure Boot証明書が期限切れになっても、PC自体は起動し、通常のWindows Updateも適用できます。しかし、起動プロセスのセキュリティ更新が止まるため、時間が経つほどセキュリティリスクが蓄積していきます。
Microsoftはすでに月例更新を通じて新しい2023年版証明書の展開を開始しており、2024年以降に製造されたPCの多くはすでに新証明書がインストール済みです。Dell、Lenovo、HPといった主要OEMも協力体制を敷いており、ファームウェアアップデートの提供を進めています。企業のIT管理者は、レジストリキー
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot
配下のUEFICA2023Statusの値を確認し、「Updated」となっていればOKです。まだ更新されていない場合は、OEMのファームウェアアップデートの適用とグループポリシーによる証明書展開設定を速やかに実施してください。
過去の月例更新トラブルから学ぶ傾向と教訓
2025年から2026年にかけてのWindows11月例更新トラブルを振り返ると、いくつかの明確な傾向が浮かび上がります。
まず、個人ユーザーよりも企業環境のほうが圧倒的に影響を受けやすいという点です。プロビジョニング、VDI、Active Directory、サードパーティ製セキュリティソフトなど、複数の要素が絡み合って初めて顕在化する問題が多く、テスト環境ですり抜けやすい特徴があります。2024H2のXAMLパッケージ問題はその典型例で、「1台ずつ素直に更新してそのまま使っている」家庭用PCでは再現しませんでした。
次に、更新プログラム自体のバグではなく、エコシステム全体の互換性問題であるケースが増えています。2026年3月のSamsung Galaxy Connectアプリの件のように、更新と同時期にベンダー側のアプリやドライバが不具合を起こすと、あたかもWindows Updateが原因であるかのように見えてしまいます。冷静な切り分けが重要です。
そして、MicrosoftのOOB(定例外)パッチ対応が迅速化している点も見逃せません。2026年1月のリモートデスクトップ障害では、わずか4日後にOOBパッチが配信されました。3月にはEnterprise向けに再起動不要のホットパッチという新しい提供形態も活用されており、「問題が起きても素早く手当てできる」体制が整いつつあります。ただし、OOBパッチの存在を知らなければ対応が遅れるため、Microsoft公式のリリースノートやWindows Release Health Dashboardを定期的にチェックする習慣が大切です。
企業のIT管理者が今月すべきアクションまとめ
| 優先度 | アクション | 対象 |
|---|---|---|
| 最優先 | KB5079473の段階展開とパイロットテストの実施 | 全Windows11端末 |
| 最優先 | Secure Boot証明書の更新状況を全端末で確認 | 2012年以降のPC・サーバー |
| 高 | OEMファームウェアアップデートの適用 | Dell・Lenovo・HP等の管理端末 |
| 高 | GPUドライバ・セキュリティソフトの最新化 | 全端末 |
| 中 | プロビジョニング設定の見直し(XAML問題対策) | Enterprise版・VDI環境 |
| 中 | KIR用グループポリシーの事前準備 | ドメイン参加端末 |
| 通常 | ロールバック手順書の整備と周知 | 情シス部門全体 |
現場で即使える!月例更新トラブル時のPowerShellコマンド集
ここからは、情シス歴10年以上の現場経験をベースに、「実際にトラブルが起きたときに手を動かせるコマンドと手順」を惜しみなく公開します。公式ドキュメントには載っているけど読みづらい、あるいはそもそも載っていない”現場の知恵”を中心にまとめました。コピペでそのまま使えるものばかりなので、ブックマークしておいて損はないはずです。
更新プログラムの適用状況を一発で確認するコマンド
まず、トラブルの切り分けで最初にやるべきことは「そもそもどのKBが入っているのか」の確認です。GUIの「更新の履歴」をポチポチ開くのは1台ならいいですが、10台、100台となると現実的ではありません。PowerShellなら一発です。
Get-HotFix | Sort-Object -Property InstalledOn -Descending | Select-Object -First 10
これで直近にインストールされた更新プログラム10件が、日付の新しい順に表示されます。KB5079473が入っているかどうか、いつ適用されたかが一目でわかります。ただし注意点として、Get-HotFixはすべての累積更新を拾えないケースがあるのです。より正確に確認したい場合は、DISMコマンドを使います。
DISM /Online /Get-Packages /Format:Table | findstr "KB5079473"
こちらのほうが確実です。特に「更新を当てたはずなのに反映されていない気がする」という問い合わせがユーザーから来たとき、この2つのコマンドで事実確認するのが鉄板の初動対応になります。
リモートで複数台の適用状況を一括確認する方法
企業環境で真価を発揮するのが、PowerShellリモーティングとの組み合わせです。あらかじめ対象PCのリストをテキストファイルに用意しておけば、一括で確認できます。
$computers = Get-Content "C:\admin\pc-list.txt"
Invoke-Command -ComputerName $computers -ScriptBlock { Get-HotFix -Id "KB5079473" } -ErrorAction SilentlyContinue | Select-Object PSComputerName, HotFixID, InstalledOn
このコマンドを実行すると、リストに含まれるPC名・KB番号・適用日時が一覧で返ってきます。「適用されていないPC」は結果に表示されないので、逆に言えば「出てこなかったPC=未適用」として特定できるわけです。朝イチで流しておけば、午前中にはパッチの展開状況を把握できます。ただし、WinRM(PowerShellリモーティング)が有効になっていることと、ファイアウォールでTCP 5985/5986が開いていることが前提条件です。グループポリシーで一括有効化している企業であれば問題ありませんが、そうでない場合は事前に
Enable-PSRemoting -Force
を対象端末で実行しておく必要があります。
更新失敗時の「鉄板リカバリ手順」を完全解説
情シスをやっていると、「Windows Updateが失敗して何度やり直しても通らない」という問い合わせは月に数回は必ず来ます。ネット検索すると「DISMとSFCを実行しましょう」と書いてあるサイトが大量に出てきますが、正直なところ実行する順番とタイミングを間違えると効果がないのです。ここでは、10年の経験から導き出した「本当に効く順番」を紹介します。
ステップ1Windows Updateのキャッシュをリセットする
まず最初にやるべきことは、更新プログラムのダウンロードキャッシュを丸ごと削除することです。キャッシュが壊れているせいで更新が通らないケースは、体感で3割くらいあります。以下のコマンドを管理者権限のコマンドプロンプトで順番に実行してください。
net stop wuauserv
net stop bits
net stop cryptsvc
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start wuauserv
net start bits
net start cryptsvc
ポイントは、SoftwareDistributionフォルダを削除ではなくリネームしている点です。削除してしまうと、万が一この操作が原因で別の問題が起きたときに元に戻せません。リネームなら、問題がなければ数日後に手動で消せばいいし、問題があれば名前を元に戻すだけで復旧できます。これは地味ですが、現場で何度も救われたテクニックです。
ステップ2DISMでコンポーネントストアを修復する
キャッシュのリセットだけで直らない場合は、Windowsのコンポーネントストア(WinSxSフォルダ)自体が破損している可能性があります。ここで登場するのがDISMです。
DISM /Online /Cleanup-Image /CheckHealth
まずこれで「そもそも修復が必要なのか」を確認します。数秒で結果が出ます。「修復可能」と表示されたら、次のコマンドを実行します。
DISM /Online /Cleanup-Image /RestoreHealth
これがメインの修復コマンドです。Windows Updateから正常なファイルをダウンロードして、壊れた部分を差し替えてくれます。所要時間は10分〜30分で、ネットワーク環境やストレージの状態によって変わります。途中で止まったように見えることがありますが、焦って閉じないでください。特に20.0%付近で長時間止まることがありますが、これは正常です。
もしこのコマンドが
0x800f081f
エラーで失敗する場合、インターネット経由で修復用ファイルを取得できていません。企業のプロキシ環境やWSUS管理下のPCでは頻繁に起こります。その場合は、Windows11のISOファイルをマウントして、ローカルのinstall.wimを修復ソースとして指定します。
DISM /Online /Cleanup-Image /RestoreHealth /Source:E:\sources\install.wim /LimitAccess
「E:」はISOをマウントしたドライブレターに読み替えてください。/LimitAccessオプションを付けることで、Windows Updateへのアクセスを試みずにローカルソースだけを使って修復するため、プロキシの問題を回避できます。
ステップ3SFCでシステムファイルを修復する
DISMが完了したら、必ず再起動してからSFCを実行してください。この「必ず再起動」がとても大事で、再起動せずにSFCを走らせると、DISMの修復結果が反映されていない状態でチェックすることになり、意味がありません。
sfc /scannow
「Windows リソース保護は、整合性違反を検出しませんでした」と表示されれば問題なしです。もし「破損したファイルが見つかりましたが、一部は修復できませんでした」と出る場合は、SFCをもう1回実行してみてください。2回目で修復できることが意外とあります。それでもダメなら、最終手段としてインプレース修復インストール(上書きインストール)が必要です。
最終手段インプレース修復インストール
DISMもSFCも効かないレベルの破損は、実際に年に数回は遭遇します。2026年2月のKB5077181で報告された「78%→79%でTrustedInstallerがクラッシュする」問題は、まさにDISMでは修復不可能なPSFXコンポーネントの不整合が原因でした。こうなったら、Windows11のISOから
setup.exe
を実行して「個人用ファイルとアプリを引き継ぐ」オプションで上書きインストールするのが唯一の解決策です。ファイルもアプリも設定もすべて残ったまま、Windowsのシステムファイルだけが新品に置き換わります。所要時間は30分〜1時間程度です。ただし、BitLockerが有効な環境では事前にBitLockerを一時停止してください。停止せずに修復インストールを走らせると、回復キーの入力を求められて詰みます。
manage-bde -protectors -disable C:
修復完了後、安定動作を確認してから再度有効化します。
manage-bde -protectors -enable C:
Secure Boot証明書の更新状況をPowerShellで確認する具体的な手順
2026年6月の期限切れに向けて、「自社の端末がちゃんと新しい証明書に更新されているのか」を確認する方法を、GUI操作とPowerShellの両面から解説します。これは意外とまとまった情報がなく、現場で困っている人が多いポイントです。
レジストリで確認する方法
最もシンプルなのは、レジストリキーを直接確認する方法です。PowerShellで以下を実行します。
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "UEFICA2023Status" -ErrorAction SilentlyContinue
返ってくる値が「Updated」なら、2023年版の新しい証明書がすでにインストールされています。「InProgress」なら更新処理の途中、値が存在しない場合は未着手の可能性があります。
イベントログで確認する方法
新しい証明書がファームウェアに適用されていない場合、「システム」ログのソース「TPM-WMI」にイベントID 1801のエラーが繰り返し記録されます。これをPowerShellで一括確認するには以下のコマンドが使えます。
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='TPM-WMI'; Id=1801} -MaxEvents 5 -ErrorAction SilentlyContinue
このコマンドの結果が何も返ってこなければ、ひとまず問題なしです。イベントが記録されている場合は、OEMのファームウェアアップデートがまだ適用されていない可能性が高いので、PCメーカーのサポートページから最新のBIOS/UEFIファームウェアを入手してください。
複数端末の証明書状況を一括レポートする方法
企業管理者向けに、複数台の証明書更新状況をCSVで出力する実用的なスクリプトを紹介します。
$computers = Get-Content "C:\admin\pc-list.txt"
$results = Invoke-Command -ComputerName $computers -ScriptBlock {
$status = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "UEFICA2023Status" -ErrorAction SilentlyContinue).UEFICA2023Status
$secureboot = Confirm-SecureBootUEFI -ErrorAction SilentlyContinue
@{
ComputerName = $env:COMPUTERNAME
SecureBootEnabled = $secureboot
CertStatus = if($status){$status}else{"NotStarted"}
}
} -ErrorAction SilentlyContinue | Select-Object ComputerName, SecureBootEnabled, CertStatus
$results | Export-Csv -Path "C:\admin\secureboot-report.csv" -NoTypeInformation -Encoding UTF8
このスクリプトを月に1回程度実行しておけば、6月の期限切れまでに「どの端末がまだ未対応なのか」を確実に把握できます。Intuneのレポート機能やWindows Autopatchを使っている企業であれば、Secure Bootのステータスレポートも活用できますが、それらが使えない環境ではこのPowerShellスクリプトが生命線になるはずです。
Windows Updateがいつまでも終わらないときの「本当の原因」と対処法
情シスの電話相談で月例更新のたびにトップ3に入る問い合わせが、「更新が終わらない」です。「もう2時間くらいグルグル回ってるんですけど……」という電話を何百回受けたかわかりません。ここでは、長年の経験で分類してきた「終わらない原因ベスト3」とその対処法をお伝えします。
原因1ストレージの空き容量不足
意外と多いのがこれです。2026年3月のKB5079473は約4.5GBもあるため、Cドライブの空き容量が10GB未満だとインストールに失敗するか、異常に時間がかかります。ユーザーに「空き容量を確認してください」と言っても「どうやるの?」と返ってくることが多いので、現場では以下のコマンドで一発確認しています。
Get-PSDrive C | Select-Object @{Name="FreeGB";Expression={::Round($_.Free/1GB,2)}}
返ってきた数値が15GB未満なら要注意、10GB未満なら更新が停滞する可能性大です。ディスクのクリーンアップを案内するか、不要ファイルの削除をリモートで実行しましょう。
原因2サードパーティ製セキュリティソフトとの競合
トレンドマイクロ、CrowdStrike、SentinelOneなどのエンドポイント保護製品が、Windows Updateの動作と干渉するケースは以前から繰り返し報告されています。2025年12月のKB5072033でもトレンドマイクロのDLP機能との互換性問題が公表されました。更新が長時間進まない場合、セキュリティソフトのリアルタイム保護を一時的に無効化して再試行すると通ることがあります。ただし、これは一時的な措置であり、更新完了後は必ず保護を再有効化してください。セキュリティソフト側のアップデートで互換性が修正される場合も多いので、ベンダーのサポートサイトも並行して確認しましょう。
原因3Windows Updateサービス自体のスタック
上記2つに該当しない場合、Windows Updateのバックグラウンドサービスが内部的にスタック(固まっている)している可能性があります。これを確認するには、以下のコマンドでサービスの状態を見ます。
Get-Service wuauserv, bits, cryptsvc, msiserver | Select-Object Name, Status, StartType
すべてRunningであれば動いてはいます。ただ「動いているけど進んでいない」パターンでは、前述のキャッシュリセット手順(SoftwareDistributionフォルダのリネーム)が効果的です。もうひとつ、あまり知られていませんが、UsoClient.exeを使って手動でスキャンをトリガーする方法もあります。
UsoClient.exe StartScan
これはWindows Updateのオーケストレーターにスキャンのやり直しを指示するコマンドで、GUIの「更新プログラムのチェック」ボタンとほぼ同じ動作をバックグラウンドで行います。タスクスケジューラやログオンスクリプトに仕込んでおくと、ユーザーが何もしなくても定期的にチェックが走るようになります。
グループポリシーで月例更新を制御する実践テクニック
企業環境では、Windows Updateを「好き勝手に適用される」状態にしておくのは論外です。かといって完全にブロックするとセキュリティリスクが跳ね上がります。ここでは、グループポリシーを使って「いい塩梅」で制御するための設定を紹介します。
更新の適用を最大35日間延期する設定
グループポリシーエディター(
gpedit.msc
)を開き、以下のパスに移動します。
コンピューターの構成 → 管理用テンプレート → Windowsコンポーネント → Windows Update → Windows Update for Business
ここにある「品質更新プログラムをいつ受信するかを選択してください」というポリシーを有効にし、延期日数を設定します。たとえば7日間の延期を設定しておけば、Patch Tuesdayの配信日から7日後に自動適用されます。その7日間で先行テストグループの結果を見て、問題があればさらに延期するか、問題なければ予定通り適用される、という運用が可能です。なお、最大で35日間まで延期できますが、あまり長く延期するとセキュリティリスクが高まるため、推奨は7日間、最長でも14日間に留めるのが現実的なバランスです。
特定のKBをブロックする方法
WSUSやIntuneを使っている環境であれば、特定のKB番号を「拒否」に設定するだけでブロックできます。しかし、これらの管理ツールがない小規模環境では、Microsoftが公開している「Show or Hide Updates」トラブルシューター(wushowhide.diagcab)を使う方法があります。このツールを実行すると、適用可能な更新プログラムの一覧が表示され、チェックを外した更新は非表示になり、自動インストールされなくなります。ただし、このツールはあくまで個別端末ごとの操作であり、大量のPCを一括管理するには不向きです。
情シスが見落としがちな「月例更新後のチェック項目」
更新を当てて再起動した後、「問題なさそうだから大丈夫」で終わらせていませんか? 実は、更新直後にしか確認できない重要なチェック項目があります。これらを習慣化するだけで、トラブルの早期発見率が格段に上がります。
ビルド番号の確認
更新が本当に反映されたかどうかは、ビルド番号で確認するのが最も確実です。
winver
コマンドを実行して、表示されたビルド番号が期待どおりか確認してください。2026年3月のKB5079473の場合、ビルド番号は26100.8037(24H2)または26200.8037(25H2)になるはずです。PowerShellで確認する場合は以下のコマンドです。
::OSVersion.Version
保留中の再起動の確認
更新が適用されたように見えても、実は再起動が保留されていて完了していないケースがあります。これをPowerShellで確認する方法は以下のとおりです。
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
Trueが返ってきたら再起動が必要な状態です。ユーザーが「再起動しましたよ?」と言っているのに実はスリープ復帰しただけだった、というのは情シスあるあるの極みです。このコマンドで事実確認しましょう。
直近のWindows Updateログを素早く確認する
Windows11ではWindows Updateのログが従来のテキスト形式ではなくETL形式で記録されており、直接読むことができません。人間が読めるログに変換するコマンドが以下です。
Get-WindowsUpdateLog
このコマンドを実行すると、デスクトップにWindowsUpdate.logというテキストファイルが生成されます。中身は膨大ですが、
FAILED
や
ERROR
で検索すれば、更新に失敗した箇所をピンポイントで特定できます。「更新が成功したと言っているのに再起動後に挙動がおかしい」といった微妙なケースでは、このログが原因特定の決定打になることが多いです。
PSWindowsUpdateモジュールで更新管理を自動化する方法
PowerShell標準のコマンドだけでも相当なことができますが、PSWindowsUpdateというコミュニティモジュールを使うと、Windows Updateの操作がさらに柔軟になります。企業環境でも広く使われている実績のあるモジュールです。
インストール手順
管理者権限のPowerShellで以下を実行します。
Install-PackageProvider -Name NuGet -Force
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
Install-Module -Name PSWindowsUpdate -Force
インターネットに接続できない閉域環境では、別のPCでモジュールをダウンロードしてオフラインでインストールする手順が必要です。その場合は
Save-Module -Name PSWindowsUpdate -Path "C:\temp"
で保存し、USBメモリなどで対象端末に持ち込んでください。
利用可能な更新プログラムを確認する
Get-WindowsUpdate -MicrosoftUpdate
これで、Microsoft Updateカタログから取得可能なすべての更新プログラムが一覧表示されます。
特定のKBを除外して残りを一括適用する
「KB5079473はまだ様子見だけど、それ以外の更新は適用したい」という場面では、以下のように特定のKBを除外できます。
Install-WindowsUpdate -MicrosoftUpdate -NotKBArticleID "KB5079473" -AcceptAll -AutoReboot
-AutoRebootオプションを付けると、更新適用後に自動で再起動されます。業務時間外のメンテナンスウィンドウで実行する場合に便利です。逆に、再起動のタイミングを制御したい場合は-IgnoreRebootオプションに変更してください。
「更新のたびに毎回プリンタが壊れる問題」への根本対策
これは公式ドキュメントにはほとんど書かれていないのに、現場では毎月のように発生する超・頻出トラブルです。月例更新を適用した直後、「プリンタが使えなくなった」「印刷ジョブが詰まって動かない」という問い合わせが嵐のように来るのは、情シスなら誰でも経験があるはずです。2026年3月のKB5079473でもIPPプリンタの印刷障害が報告されています。
根本原因は、Windows Updateがプリンタドライバの互換性チェックを強化しているためです。特にネットワークプリンタやIPP(Internet Printing Protocol)対応プリンタで顕著に発生します。対処法は以下の手順が最も確実です。
- まず印刷スプーラーサービスを停止します。管理者権限のコマンドプロンプトで
net stop spoolerを実行してください。
- 次に、
C:\Windows\System32\spool\PRINTERSフォルダ内のファイルをすべて削除します。これが詰まった印刷ジョブの残骸です。
- 印刷スプーラーサービスを再起動します。
net start spoolerを実行してください。
- それでも直らない場合は、プリンタを一度削除して再追加してください。ドライバの再インストールが行われ、更新後の新しいドライバスタックとの整合性が取れます。
なお、この手順をスクリプト化して共有フォルダに置いておくと、ヘルプデスク対応が格段に楽になります。「プリンタが動かなくなったらこのバッチファイルを実行してね」と案内するだけで済むようになるからです。
Windows11の月例更新と企業PCの対策に関する疑問をさらに深掘り
WSUSとIntuneのどちらで更新管理すべきですか?
結論から言うと、2026年時点ではIntuneへの移行を強く推奨します。WSUSは依然としてサポートされていますが、Microsoftの投資はWindows Update for Business(WUfB)とIntuneに集中しています。WSUSは運用負荷が高く、サーバーの肥大化やDB破損などのトラブルも頻発します。ただし、閉域ネットワークやインターネット接続が制限された環境では、WSUSが唯一の選択肢になることもあります。その場合は、PowerShellで定期的にWSUSサーバーのクリーンアップを実行して肥大化を防ぐことが重要です。
Invoke-WsusServerCleanup -CleanupObsoleteComputers -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates
を月1回のスケジュールタスクに入れておくのがおすすめです。
テスト環境がない小規模企業はどうすればいいですか?
専用のテスト環境を用意できない場合でも、「犠牲の1台」戦略は実行可能です。情シス担当者の自分のPCを先行適用端末にして、1〜2日間使い倒してから全社展開する。これだけでも「全台一斉適用」よりはるかにリスクが下がります。もう少し踏み込むなら、Hyper-Vを使って仮想マシン上にテスト環境を作る方法もあります。Windows11 ProやEnterpriseにはHyper-Vが標準搭載されているので、追加コストゼロでテスト環境を構築できます。月例更新の検証用に1台の仮想マシンを常時稼働させておけば、本番に近い環境でのテストが可能です。
Quick Machine Recoveryとは何ですか?企業で使えますか?
2026年3月のKB5079473から、Quick Machine RecoveryがWindows11 Professionalのドメイン非参加・エンドポイント管理未登録端末で自動有効化されました。これは、Windowsが起動できなくなるような重大なエラーが発生したとき、Windows Updateを通じてリモートから修正プログラムを自動適用して回復する仕組みです。2024年7月のCrowdStrike障害のような「世界中のPCが一斉にブルースクリーンになる」事態を防ぐために開発されました。Enterprise環境ではWindows Autopatch経由で管理されますが、IT管理者が明示的に制御できるため、意図しない自動修復が走る心配はありません。
ぶっちゃけこうした方がいい!
ここまで読んでくれた方に、正直な本音を語ります。情シスを10年以上やってきて、Windows Updateの対応に費やしてきた時間は、正直なところ膨大です。そして、その経験から導き出したぶっちゃけの結論は、「完璧な事前テストは不可能だから、ロールバックの速さで勝負する」ということです。
よく「テスト環境で1週間検証してから本番適用しましょう」と言われますが、現実を見てください。XAML問題のようにプロビジョニング後にしか発現しない不具合、Samsung Galaxy Connectのようにベンダーアプリとの組み合わせでしか起きない不具合、特定のGPUドライバとの相性問題──これらをすべてテスト環境で再現するのは物理的に無理です。何百パターンもの組み合わせを全部試すなんて、天文学的な工数がかかります。
だからこそ、私がずっとやってきたのは「問題が起きたら5分でロールバックできる体制を作る」ことです。具体的にはこの3つです。まず、更新適用前のシステム復元ポイント作成を全端末で自動化する。次に、問題が起きたKBをWSUSやIntuneで即座にブロックできるよう手順を整備しておく。そして、DISMとSFCの手順、キャッシュリセット手順、最悪の場合のインプレース修復手順をワンクリックで実行できるバッチファイルとして共有フォルダに置いておく。この3つがあれば、何が起きても半日以内に復旧できます。
もうひとつ大事なのは、「ニュースやフォーラムの騒ぎを鵜呑みにしない冷静さ」です。2026年3月のKB5079473も、ネット上では「大規模障害」「BSOD多発」と騒がれましたが、実際にはWindows Latestの調査で報告件数は10件未満、Microsoftも問題を認識していないとの回答でした。10億台以上のPCで10件って、確率で言えば0.000001%ですよ。そういう記事に振り回されて更新を何週間も止めるほうが、よっぽどセキュリティリスクが高い。AIが脆弱性を自動発見する時代に、パッチの適用を2週間遅らせるのは、家の鍵を開けっぱなしにするのと同じです。
最終的に、月例更新との付き合い方で一番大事なのは「怖がりすぎず、油断しすぎず、手を動かせる準備だけは怠らない」ことです。この記事で紹介したPowerShellコマンドやバッチファイルを、自分の環境に合わせてカスタマイズして手元に置いておく。それだけで、毎月のPatch Tuesdayが「恐怖のイベント」から「ルーティンワーク」に変わります。道具を持っている人間は強いんです。ぜひ今日から、自分なりの”月例更新サバイバルキット”を作ってみてください。
このサイトをチップで応援
Windows11の月例更新と企業PCの対策に関するよくある質問
個人のWindows11ユーザーも月例更新を遅らせたほうがいいですか?
基本的には、個人ユーザーは速やかに適用することをおすすめします。2026年3月のKB5079473で報告された不具合も、数十億台のWindows PCのうちごく少数の事例に限られており、Microsoftも「一般ユーザーには大きな影響はない」と公式に発表しています。脆弱性を放置するリスクのほうが、更新による不具合リスクよりもはるかに大きいのが現実です。ただし、更新前にシステム復元ポイントを作っておけば、万が一の場合でもすぐに元に戻せるので安心です。
Windows10を使い続けている場合、月例更新はどうなりますか?
Windows10は2025年10月14日にサポートが終了しています。2026年3月時点で月例セキュリティ更新を受け取るには、有償のESU(拡張セキュリティ更新プログラム)への加入が必要です。ESU未加入の場合、セキュリティ修正は一切配信されません。個人向けESUも提供されていますので、Windows11への移行がすぐにできない場合は検討してください。
更新プログラムをアンインストールしたらセキュリティは大丈夫ですか?
アンインストールすると、その更新に含まれていたセキュリティ修正もすべて元に戻ります。つまり、修正済みの脆弱性が再び露出する状態になります。アンインストールはあくまで緊急回避策であり、問題が解決されたら速やかに再適用することが前提です。企業環境では、ネットワークレベルでの防御(ファイアウォール・IPS)を強化し、アンインストール期間のリスクを最小化する運用を組み合わせてください。
Secure Boot証明書の期限が切れるとPCが起動できなくなりますか?
いいえ、PCの起動自体はできます。ただし、ブートプロセスのセキュリティ更新が受けられなくなり、将来的にブートレベルの脆弱性に対する保護が低下します。すぐに目に見える問題は起きませんが、放置すればするほどセキュリティリスクが蓄積する「静かな時限爆弾」です。2026年6月までに新しい2023年版証明書への更新を完了させておくことを強く推奨します。
AIが脆弱性を自動発見する時代に企業はどう備えるべきですか?
2026年3月のPatch Tuesdayでは、完全自律型AIペネトレーションテストエージェント「XBOW」がWindowsの重大な脆弱性(CVSS 9.8)をソースコードなしで発見し、CVEとして正式に認定されるという画期的な出来事がありました。これは、脆弱性の発見速度がAIによって飛躍的に上がることを意味しており、裏を返せば攻撃者もAIを使って脆弱性を見つける時代が来ているということです。パッチ適用の迅速さが、これまで以上に企業の生命線になります。
今すぐパソコンやスマホの悩みを解決したい!どうしたらいい?
いま、あなたを悩ませているITの問題を解決します!
「エラーメッセージ、フリーズ、接続不良…もうイライラしない!」
あなたはこんな経験はありませんか?
✅ ExcelやWordの使い方がわからない💦
✅ 仕事の締め切り直前にパソコンがフリーズ💦
✅ 家族との大切な写真が突然見られなくなった💦
✅ オンライン会議に参加できずに焦った💦
✅ スマホの重くて重要な連絡ができなかった💦
平均的な人は、こうしたパソコンやスマホ関連の問題で年間73時間(約9日分の働く時間!)を無駄にしています。あなたの大切な時間が今この悩んでいる瞬間も失われています。
LINEでメッセージを送れば即時解決!
すでに多くの方が私の公式LINEからお悩みを解決しています。
最新のAIを使った自動応答機能を活用していますので、24時間いつでも即返信いたします。
誰でも無料で使えますので、安心して使えます。
問題は先のばしにするほど深刻化します。
小さなエラーがデータ消失や重大なシステム障害につながることも。解決できずに大切な機会を逃すリスクは、あなたが思う以上に高いのです。
あなたが今困っていて、すぐにでも解決したいのであれば下のボタンをクリックして、LINEからあなたのお困りごとを送って下さい。
ぜひ、あなたの悩みを私に解決させてください。
まとめ
Windows11の月例更新は、企業のセキュリティを守る不可欠な仕組みですが、2026年に入ってからもリモートデスクトップの認証障害、シャットダウン不能、XAMLコンポーネントのクラッシュ、Outlookフリーズなど、業務に直結する不具合が繰り返し発生しています。そして3月のKB5079473では79件以上の脆弱性修正が行われ、「適用しないリスク」も過去最大級に高まっています。
大切なのは、「更新を当てるか・当てないか」の二択ではなく、「どう当てるか」を組織として設計することです。段階展開、ロールバック手順の事前準備、KIRの活用、ドライバの最新化──こうした対策を日常のIT運用に組み込むことで、「セキュリティを守りながら業務も止めない」バランスが実現できます。
さらに、2026年6月にはSecure Boot証明書の期限切れという大きな節目が待っています。月例更新の対応に追われる今だからこそ、証明書の更新状況を確認し、OEMファームウェアの適用を進めておくべきです。「更新=すぐ全部当てる」の時代から、「組織としてアップデート戦略を設計する」時代へ。この記事が、あなたの環境をより安全に、より安定して運用するための一助になれば幸いです。






コメント