※ 6分21秒
公式に認めた事実と周辺事情
2026年5月配信の定例KBおよびプレビューKB（KB5089573）を適用する際、インストール進行状況が35～36%付近に達した段階で処理が失敗し、エラーコード「0x800f0922」と共に元の状態へロールバックされる不具合が多発していました。
これについて、Microsoft公式および技術ソースにより「EFIシステムパーティション（ESP）の空き容量が10MB以下」のデバイスで発生することが完全に確定情報としてアナウンスされました。
公式に認めた事実と周辺事情
2026年5月配信の定例KBおよびプレビューKB（KB5089573）を適用する際、インストール進行状況が35～36%付近に達した段階で処理が失敗し、エラーコード「0x800f0922」と共に元の状態へロールバックされる不具合が多発していました。
これについて、Microsoft公式および技術ソースにより「EFIシステムパーティション（ESP）の空き容量が10MB以下」のデバイスで発生することが完全に確定情報としてアナウンスされました。
このあたりの経緯について
KB5089549（5月「定例」）について
- 「0x800f0922 ＝ ESP（EFIシステムパーティション）の空き容量不足」「35〜36％で止まってロールバック」という“公式確定”は、5月中旬（5/15〜5/19頃）に5月定例パッチであるKB5089549向けに明示されました。
- Microsoftによるサポート記事の更新や、問題のある変更を自動で差し戻すKIR（Known Issue Rollback）、レジストリを用いた
EspPaddingPercentの一時的回避策が公開されたのは、すべてこの5月中旬のタイミングの話です。
つまり、すでに先月の「定例パッチ」の時点で、ESP空き容量10MB以下が原因でWindows Updateが物理的にストップしてしまう仕様の壁は、公式側で認められていました。
KB5089573（5/27プレビュー）について
- こちらは、「5月定例（KB5089549）で大きなボトルネックになった0x800f0922／35％前後の適用失敗が、その後に配信されたプレビュー版でも全く同じように起きている」という“現場側からの悲鳴と検証記事”が追って出てきた、という時系列の流れになります。
今回のプレビュー更新は任意適用のためスルーが容易ですが、5月定例の段階ですでに「起動土台の空き容量不足」の関門は公式に敷かれており、今回の件も含めて「来週以降のセキュリティ更新（必須適用）では誰もが必ず直面する問題」へと地続きで繋がっています。
解決手順
1. 現在の空き容量の確認方法
まずは、ご自身のパソコンの起動土台（ESP領域）にどの程度の空き容量があるかを確認する必要があります。
そのため、正確な容量と使用量を監査するには、信頼できるサードパーティ製のパーティション管理ソフト（MiniTool Partition Wizard 無料版など）を使用し、視覚的にFAT32領域（ESP）の「未使用領域」が十分に確保されているかを確認してください。
実際の表示の様子と「隠れた消費量」の計算
かなりのケースで、Windows標準機能とパーティション管理ソフトの間で表示に大きな乖離が発生します。
参考として以下の筆者の環境での画像をご覧ください。筆者は事前にESP領域を500.00MBへ物理的に拡張してしまっているため一見分かりにくいのですが、実際には内部で37.57MBをすでに消費している状態です。
これを旧規格の一般的な「全体で100MB」の構成にそのまま当てはめて計算してみると、内部の空き領域は自動的に残り62.43MB（未使用領域が約62MB）まで減っていることになります。
今回これほど大規模な適用失敗が騒がれている頻度から逆算しても、最初から空き容量が物理的に不足しているユーザーはある程度以上の割合で確実に存在します。そうでなければ、Microsoftが公式に容量問題を認めて注意喚起を出すような行動を取るはずがない、というのが長年の経験則から言える不都合な真実です。
空き容量はどの程度残っていれば安全なのか？
ここで最も強調しておきたい重要な自衛策は、「Microsoftが10MB以下で失敗すると言っているから、11MBの空きがあれば大丈夫」などと考えるのは絶対にやめてほしいということです。
過去のWindows Updateの歴史を振り返っても、例えば「Cドライブの空き容量が10GB程度ないとアップデートが失敗する」と案内されていても、実際の現場では18GB程度の余剰がないと高確率で処理が詰まって危なくなるという厳然たる事実が存在します。
Microsoftのアナウンスは、あくまで「アップデートが完全に強制停止・ロールバックに至る限界値が10MB未満」という風に読める書き方をしています。しかし、処理が完全に弾かれなかったとしても、内部的な修復処理の負荷が原因で、表面上は成功に見えても内部で一度失敗している現象（サイレントfail）の引き金にならないか、という安全マージンまでは考慮された数字ではありません。
【結論としての目安】
怪我を避けるための安全な判断基準として、個人的にはMicrosoftが提示した数字の「2倍以上」となる【20MB～25MB以上の空き容量】が最低でも必須であり、環境が複雑なマルチブート機やサーバー機においては【50MB程度以上の空き容量】が物理的に確保されていなければ無難とは言えない（いつ踏んでもおかしくない）と考えておくべきです。
▼ Windows標準「ディスクの管理」の表示例
▼ 「MiniTool Partition Wizard」での正確な確認例
2. 領域の拡張手順（自衛策）
空き容量が10MB以下で、今後のWindows Updateが一切入らなくなるリスクを回避するための主な解決策は以下の通りです。
- 上級者向け：パーティション管理ツールを用いた領域の拡張
隣接するCドライブの先頭を数100MBほど削って後ろに詰め、空いたスペースをESP領域に結合することで、データを保持したままESPを300MB～500MB程度へ物理的に拡張します。ただし、パーティションのセクタ単位の操作は、誤るとシステムが一切起動しなくなる重大なヒューマンエラーのリスクを伴います。 - 初心者向け：OSのクリーンインストールによる再構成
最も確実かつ安全な方法です。現代の最新OSインストールメディアからPCを立ち上げ、一度ドライブ全体のパーティションをすべて削除してからWindowsを入れ直すことで、自動的に現代の安全基準に適した広いESP領域（100MBの壁を超えたサイズ）が自動的に再構築されます。
コメント