Microsoftは2026年5月、Windows 11向け累積セキュリティ更新プログラム「KB5089549」の一部デバイスへのインストールが失敗する問題を公式に認め、回避策を公開した。

何が起きているのか

問題の根本原因は、EFIシステムパーティション（ESP）の空き容量不足だ。特にESPの空き容量が10MB以下のデバイスで顕著に発生する。

更新プログラム適用の流れとしては、インストール自体は最初のフェーズまで正常に進むものの、再起動フェーズの進捗が35〜36%付近でロールバックが始まる。ユーザーには「Something didn’t go as planned. Undoing changes.（問題が発生しました。変更を元に戻しています。）」というメッセージが表示される。

システムログには以下のようなエントリが残るため、原因特定の手がかりになる：

  • SpaceCheck: Insufficient free space
  • ServicingBootFiles failed. Error = 0x70
  • SpaceCheck: <値> used by third-party/OEM files outside of Microsoft boot directories

エラーコードとして報告されるのは 0x800f0922 だ。

回避策：Known Issue Rollback（KIR）の活用

Microsoftは現時点で根本的な修正を開発中としており、当面はKnown Issue Rollback（KIR）と呼ばれるWindowsの機能を使った回避策を案内している。KIRは、Windows Updateを通じて配信された問題のあるアップデートをロールバックする仕組みだ。

企業の管理環境でIT部門がWindows Updateを制御している場合は、グループポリシーを手動でインストール・設定することで対応できる。設定後はデバイスの再起動が必要で、グループポリシーは問題の原因となっている変更を一時的に無効化する。

KIRグループポリシーの展開・設定手順はMicrosoftサポートサイトで公開されている。

今月のWindows Updateを巡る問題の連鎖

KB5089549は4月2026年のWindows 11アップデートが引き起こしていたBitLocker回復画面への強制起動問題の修正も含んでいた。しかし今度は別の問題が浮上した格好だ。

加えてMicrosoftは今月、以下の問題も対応・確認している：

  • Windows Autopatchのバグ：管理ポリシーで制限されているはずのドライバー更新が、EU内のAutopatch管理デバイスに誤って展開されていた問題
  • 4月のセキュリティ更新：脆弱なドライバーを使用するサードパーティ製バックアップアプリケーションで障害が発生する問題

更新プログラムが更新プログラムの問題を修正し、また別の問題を生む——こうした状況が続いている。

日本のIT管理者・エンジニアへの実務ポイント

影響確認の優先手順：

  • 管理下のWindows 11デバイスのESP空き容量を確認する（diskpart や PowerShell で Get-Partition コマンドから確認可能）
  • 10MB以下の空き容量しかないデバイスを優先的に特定し、KB5089549の適用を保留するか、KIRグループポリシーを事前に展開する
  • エンドポイント管理ツール（Microsoft Intune、Microsoft Endpoint Configuration Manager等）を使っている場合は、展開リングの前段階（パイロットグループ）での動作確認を徹底する

ESPの空き容量不足が発生しやすいケース：

  • OEMが出荷時にESPを小さく設定している端末
  • セキュアブート関連のサードパーティツールがESP領域にファイルを配置しているケース
  • 長期間アップグレードを繰り返してきた端末

ESPの拡張は手順が複雑で、リカバリーメディアが必要になることもある。ツールを使って安易に進めるより、まずは影響端末の特定とKIRによる暫定対処を優先すべきだ。

筆者の見解

Windows Updateを「すぐ当てたら壊れた」という報告は以前にも増して増えている印象だ。今回のKB5089549のケースも、BitLocker問題を直しつつ別の問題を含んでいるという構図で、管理者として「どのタイミングで当てるか」の判断がますます難しくなっている。

もっとも、数日様子を見てから適用する判断は、怠慢ではなくれっきとしたリスク管理だと筆者は考えている。特にESPの容量という、見落とされがちなインフラ側の制約が原因なのだから、焦って適用して現場を止めるよりも、一呼吸置いて検証してから展開するフローを社内で確立することの方が長期的には正解だ。

MicrosoftにはKIRという回避機能があり、今回もそれを案内しているのは評価できる。ただ、ESPの容量管理という本来はOEMやデプロイ設計段階で吸収しておくべき問題が、毎月の定例更新で露出し続けているのは「もったいない」の一言に尽きる。品質検証の段階でこのパターンを継続的につぶしていく仕組みが整えば、現場のIT管理者の負担は大きく下がるはずで、Microsoftにはその力が十分あると信じている。

出典: この記事は Microsoft confirms Windows 11 security update install issues の内容をもとに、筆者の見解を加えて独自に執筆したものです。