Windows Update で KB5058499 のインストールが 98% で失敗し、0x800f0922 でロールバックを繰り返す。CBS.log に BFSVC と memtest.efi、Last Error=0x70 が大量に出ているなら、原因は C: ではなく EFI システム パーティション（ESP）の空き容量不足が濃厚です。ESP を拡張・整理して更新を通す手順を解説します。
起きている症状を整理：98%で失敗する KB5058499 と 0x800f0922
KB5058499 の適用が最後の最後（98% 付近）で止まり、再起動後に「更新を元に戻しています」と表示されてロールバックする場合、更新の“本体”は展開できているのに、ブート（起動）に関わる最終処理で失敗している可能性が高いです。特に UEFI/GPT 環境では、Windows はブート用のファイルを EFI システム パーティション（ESP） に書き込んで整合性を取ります。このタイミングで失敗すると、結果として 0x800f0922 という比較的あいまいなエラーに丸め込まれます。
| 見える現象 | よくある裏側 | 判断のポイント |
|---|---|---|
| KB5058499 が 98% で失敗しロールバック | 更新の最終フェーズでブート/回復系のファイル更新に失敗 | 再起動直後に戻る／何度やっても同じ% |
| Windows Update のエラーが 0x800f0922 | 予約領域・ESP・WinRE など “システム領域” 起因で起きやすい | C: の空きが十分でも発生する |
| C:\Windows\Logs\CBS\CBS.log に BFSVC と memtest.efi、Last Error=0x70 が多発 | ESP へのコピーに失敗（容量不足が典型） | 0x70 は実質「空き容量が足りない」系の失敗として扱える |
CBS.log の読みどころ：BFSVC、memtest.efi、Last Error=0x70
このパターンで重要なのは、ログが “ファイル破損” を示しているのではなく、書き込み先の領域が足りずにコピーできないことを示している点です。
- BFSVC：Boot File Servicing（ブートファイルの保守）に関わる処理の略称としてログに出ることがあります。更新プログラムがブート関連ファイルを差し替える局面で登場します。
- memtest.efi：Windows メモリ診断などで使われる EFI 実行ファイルです。更新で置き換え対象になり、ESP 側へコピーされることがあります。
- Last Error=0x70：Win32 のエラーコードとしては 112（ERROR_DISK_FULL）に相当し、直感どおり “空き容量が足りない/書き込めない” と読むのが自然です。
ログの具体例：どんな行が並んだら ESP 不足を疑うか
CBS.log は環境ごとに表現が少し変わりますが、次のように「BFSVC」「copy」「EFI 側のパス」「0x70」が近い行に固まって出てくると、ESP の空き不足を強く疑えます（あくまで例です）。
... BFSVC: Attempting to copy ...\memtest.efi to \EFI\Microsoft\Boot\memtest.efi
... BFSVC: Failed to copy file ... Last Error = 0x70
... Failed to finalize ... 0x800f0922ポイントは、同じ失敗が短い間隔で繰り返されることです。コピーに失敗すると更新はリトライしますが、容量が増えない限り結果は変わらないため、ログが “同じエラーの連打” になりやすいです。
DISM（ScanHealth/RestoreHealth）や sfc /scannow は、主に Windows 本体（コンポーネントストアやシステムファイル）の整合性を直すための手段です。ESP がいっぱいで「コピー先がない」状態では、いくら Windows 本体が健全でも最後の書き込みで失敗します。したがって、DISM/SFC を回しても改善しないのは理屈に合っています。
まず確認：ESP の容量と空き、更新失敗の“根拠”を固める
対処に入る前に、ESP が本当にボトルネックかを短時間で確認します。やることは「ESP の容量」「ESP の空き」「どこが膨れているか」の 3 点です。ここを押さえると、闇雲な再試行や、関係の薄い修復コマンドで時間を消耗しにくくなります。
ディスクの管理で ESP のサイズを確認する
最も簡単なのは Windows 標準の「ディスクの管理」です。ESP は通常、「EFI システム パーティション」として表示され、ファイルシステムは FAT32、サイズは 100MB〜数百MB です。
| ESP サイズの目安 | 更新で詰まりやすさ | コメント |
|---|---|---|
| 100MB 前後 | 高い | 古い構成でよく見ます。最近の更新や複数 OS/メーカー領域があると不足しがちです。 |
| 260MB 前後 | 中 | 一般的なサイズですが、ベンダーファイルが多いと満杯になることがあります。 |
| 300MB〜500MB | 低い | ブート更新が絡む Windows Update でも余裕が出やすいサイズです。 |
diskpart で “System” と FAT32 を見つける（GUI が苦手な人向け）
GUI で見つけにくい場合は diskpart でも確認できます。管理者のコマンドプロンプトで実行してください。
diskpart
list disk
select disk 0
list volume
exit一覧の中で FAT32 かつ System（または EFI 相当）になっている小さめのボリュームが ESP です。サイズが 100MB 付近で、しかも空きが少ないなら “犯人” としてかなり濃厚です。
ESP を一時マウントして空きを見る（空き容量の確証を取る）
ESP は通常ドライブ文字が付いていません。次のコマンドで一時的に S: としてマウントできます。
mountvol S: /Sマウントできたら、空きや肥大化しているフォルダを確認します。
dir S:\
dir /a S:\EFI
fsutil volume diskfree S:確認が終わったら必ず解除します。
mountvol S: /D注意：ESP は起動に直結する領域です。むやみに削除すると起動不能になる可能性があります。自信がない場合は、後述の「拡張」または「インプレースアップグレード」を優先してください。
解決の王道：EFI システム パーティション（ESP）を拡張する
ログに memtest.efi のコピー失敗と 0x70 が出ている場合、最も再現性が高い解決策は ESP の拡張です。理由は単純で、更新が必要とするブートファイル群を書き込める “器” を用意することが、根本原因に直接効くからです。
拡張のゴール：300MB 前後を目安にする
「どれくらい増やせばいいか」は環境によって変わりますが、経験則としては 300MB 前後にしておくと、Windows Update のブート関連更新で詰まりにくくなります。すでに 260MB ある場合でも、メーカー固有の残骸が多い環境では 300〜500MB にしておくと余裕が出ます。
拡張前のチェックリスト（失敗しない準備）
| 項目 | なぜ必要か | 具体例 |
|---|---|---|
| バックアップ | ESP 操作に失敗すると起動不能のリスクがあるため | システムイメージ、重要データの退避、回復ドライブ作成 |
| BitLocker の一時停止 | パーティション変更で回復キー要求になることがあるため | 「保護の中断」→作業後に再開 |
| 回復手段の用意 | 万一のブート修復に備える | Windows インストールメディア/回復ドライブ |
| ディスク構成の把握 | ESP の右側に別パーティションがあると移動が必要なため | ESP→MSR→C:→回復パーティション、など |
「ディスクの管理」だけで拡張できない理由
Windows 標準の「ディスクの管理」は、パーティションの “移動” ができません。ESP の隣に未割り当て領域がない、あるいは間に別のパーティション（MSR や回復パーティションなど）が挟まっている場合、ESP をそのまま拡張できないことが多いです。そのため実務では、パーティションを移動できるツールを使って ESP の直後に空きを作り、そこへ拡張する流れになります。
拡張作業の流れ（一般的な考え方）
- ディスク構成を確認し、ESP の後ろに連続した未割り当て領域を作れるか判断する
- 必要に応じて C: などを少し縮小し、パーティションを移動して ESP の隣へ未割り当て領域を寄せる
- ESP を 300MB 前後まで拡張する（FAT32 のまま）
- 再起動して Windows が正常に起動することを確認する
- KB5058499 を再実行する
作業手順そのものはツールや構成で変わりますが、重要なのは「ESP の直後に空きが必要」という点です。ここが理解できていると、ツールが違っても迷いにくくなります。
拡張後にやっておくと安心な確認
更新を再実行する前に、次の確認を入れると “やったのに別要因だった” を早期に切り分けできます。
- ディスクの管理で ESP のサイズが増えていること
- 一時マウントして空きが十分あること（数十MB 以上を目安）
- 再起動が安定していること（BitLocker 回復キー要求が出ないこと）
拡張が難しいとき：ESP をマウントして不要ファイルを整理する（慎重に）
物理ディスクの空きが少ない、パーティションの移動が怖い、企業端末でツールが使えない――こうした事情で拡張が難しい場合は、ESP の中身を整理して空きを作る方法があります。ただし、これは 誤ると起動不能になり得るため、削除ではなく「退避→確認→削除」の順で進めるのが安全です。
基本手順：マウント → バックアップ → 容量の大きいものから退避
まず ESP をマウントします（まだなら実行）。
mountvol S: /S次に、ESP 全体を別ドライブへバックアップします。容量は小さいので、基本的には丸ごとコピーできます。
mkdir C:\ESP_Backup
robocopy S:\ C:\ESP_Backup /MIR /R:0 /W:0バックアップが取れたら、ESP 内のフォルダサイズを見て “どこが太っているか” を把握します。
dir /a S:\EFI
dir /a S:\EFI\Microsoft
dir /a S:\EFI\Bootエクスプローラーで S: を開いても構いませんが、削除操作は慎重に行ってください。
削除・退避の判断ポイント（危険度の目安）
| 場所/フォルダ例 | 危険度 | 考え方 |
|---|---|---|
| S:\EFI\Microsoft\Boot | 非常に高い | Windows の起動に直結します。原則として触りません。 |
| S:\EFI\Boot | 高い | 汎用ブートローダーが入ることがあります。軽々に削除しない。 |
| S:\EFI\Microsoft\Recovery | 中〜高 | 回復関連に影響する可能性があります。目的を理解していないなら触らない。 |
| S:\EFI\（PC メーカー名：HP/Dell/Lenovo など） | 中 | 診断ツールや独自回復の残骸が積み上がっていることがあります。まずは C: へ退避してから、起動確認後に削除を検討します。 |
| 明らかなログ・キャッシュ・旧版バックアップと分かるもの | 低〜中 | 名称と用途が確実に分かる場合のみ。迷ったら削除しない。 |
実際の現場では、ESP 内にメーカー固有のフォルダが大量にあり、そこが数十MB〜を占有しているケースがあります。こうした環境で 不要分を退避して空きを確保した途端に KB5058499 が通ることがあります。ただし「そのメーカー固有フォルダが本当に不要か」は機種や設定で変わり得るため、いきなり削除せず、まずはバックアップを作り、必要なら退避に留めるのが無難です。
整理後の確認：空きが増えたか、起動が安定しているか
退避/削除後は、次の 2 点を確認します。
- 空き容量：
fsutil volume diskfree S:で増えたこと - 再起動テスト：1回ではなく複数回再起動し、BitLocker 回復キー要求などが出ないこと
問題がなければ ESP のマウントを解除し、Windows Update を再実行します。
mountvol S: /D0x800f0922 の別原因もある：ただしログで切り分けできる
0x800f0922 は “原因が 1 つに決まらない” エラーでもあります。検索すると VPN/プロキシ、セキュリティソフト、.NET の有効化、WinRE 更新失敗など様々な記事が出てきます。そこで迷わないために、ログでの切り分けを先に押さえておくと有利です。
| よくある原因候補 | ありがちな症状 | 今回のパターンとの違い |
|---|---|---|
| ESP/予約領域の不足 | 終盤で失敗、ロールバック、BFSVC/ブート関連が出る | memtest.efi のコピー失敗や 0x70 が出るなら本命 |
| VPN/プロキシ等で更新サーバーへ到達できない | ダウンロード段階で止まる、同じ%で長時間変わらない | ESP 書き込みのログとは方向性が違う |
| .NET 機能の有効化/無効化が絡む失敗 | 特定の累積更新や機能更新で失敗、CBS に機能名が出る | ブートファイルのコピー失敗が主役なら優先度は下がる |
| WinRE（回復環境）更新失敗 | reagentc 周りや回復パーティションのエラーが出る | memtest.efi と ESP の 0x70 が明確ならまず ESP を片付ける |
つまり、「0x800f0922 だから○○」ではなく「CBS.log の失敗箇所で判断する」のが最短ルートです。今回のようにブート用ファイルのコピー失敗が明確なら、ESP の空き確保が最優先になります。
最終手段：インプレースアップグレードで更新・修復する
ESP を広げるのも整理するのも難しい、あるいは更新の失敗が複合要因で泥沼化している場合は、インプレースアップグレードが有効です。これは Windows のセットアップ（Media Creation Tool や ISO）を “上書き” し、アプリやデータを保持したままシステムを修復・更新する方法です。
- Windows のセットアップを起動し、「個人用ファイルとアプリを引き継ぐ」を選択
- 作業中に Windows のシステム領域が再構成され、更新が通りやすくなる
- 更新コンポーネントの破損や不整合も同時に解消できることがある
インプレースアップグレードは “手間は増えるが成功率が高い” という位置づけです。特に業務端末などでパーティション操作を避けたい場合、管理方針としてこちらが選ばれることもあります。
よくある誤解：C: の空きが十分でも直らない理由
この問題は、C: の空き不足とは別物です。ESP はディスク上の別パーティションであり、C: が 200GB 空いていても ESP が 1〜2MB しか空いていなければ、ブートファイルの差し替えに失敗します。更新の最後（98%）で止まるのは、Windows が「本体の更新 → 再起動 → ブート/回復系の更新 → 完了」の順で進むため、最後の工程で転けると “ほぼ完了に見える” からです。
トラブルシュートの実践ポイント：再現性を上げるコツ
同じ症状でも、対処の順序を誤ると時間だけが溶けます。次の順で進めると、遠回りになりにくいです。
| 優先 | やること | 狙い |
|---|---|---|
| 1 | CBS.log で BFSVC/memtest.efi/0x70 を確認 | ESP 起因かを確定させる |
| 2 | ESP のサイズと空きを確認（ディスクの管理 or mountvol） | 容量不足の“証拠”を取る |
| 3 | ESP を 300MB 前後へ拡張 | 根本解決（最も成功率が高い） |
| 4 | 拡張不可なら、ESP 内を退避して空きを作る | 物理的に書き込み先を確保する |
| 5 | インプレースアップグレード | 更新基盤ごと立て直す |
現場で役立つ「確認コマンド」まとめ
「どのコマンドを打てばいいか」を探す時間が一番もったいないので、よく使うものをまとめます。管理者で実行してください。
| 目的 | コマンド例 | 補足 |
|---|---|---|
| CBS.log の場所を確認 | notepad C:\Windows\Logs\CBS\CBS.log | 巨大な場合はコピーしてから見ると軽くなります。 |
| ESP をマウント | mountvol S: /S | S: は空いている文字に変更して構いません。 |
| ESP の空きを確認 | fsutil volume diskfree S: | 数字で空きが把握できます。 |
| マウント解除 | mountvol S: /D | 作業後の付けっぱなしは避けます。 |
万一のときのために：ESP 操作後に起動しなくなった場合の復旧メモ
基本的には「バックアップを取ってから慎重に作業」すれば問題は起きにくいのですが、万一、ESP の操作後に起動できなくなった場合は慌てずに次の順で対応します。ここでは “最小限の復旧手順の考え方” をメモとしてまとめます（環境により手順が変わるため、企業端末やデュアルブート環境では無理をせず管理者/専門家に相談してください）。
まず試す：スタートアップ修復
Windows のインストールメディアや回復ドライブで起動し、「トラブルシューティング」→「詳細オプション」→「スタートアップ修復」を試します。多くのケースはこれで自動修復されます。
手動修復の一例：bcdboot でブートファイルを作り直す
自動修復で直らない場合、UEFI ブート情報を作り直すために bcdboot を使うことがあります。代表例は次の流れです（コマンドは状況により変わります）。
diskpart
list vol
select vol X （FAT32 かつ System のボリューム）
assign letter=S
exit
bcdboot C:\Windows /s S: /f UEFIこれは「C:\Windows を起動元として、ESP（S:）へ UEFI 用のブートファイルを再配置する」イメージです。デュアルブート環境では他 OS のブートローダー構成に影響することがあるため、目的が Windows 単独起動の復旧であることを確認してから実行してください。
実務で刺さる補足：BitLocker とデュアルブート環境は特に注意
ESP の操作は、BitLocker やデュアルブート（Linux 併用など）環境で事故りやすいポイントです。
- BitLocker：パーティション変更で回復キー入力を求められることがあります。作業前に「保護の中断」を行い、完了後に戻します。
- デュアルブート：ESP に Windows 以外のブートローダー（GRUB など）がある場合があります。メーカー固有フォルダのつもりで削除すると致命傷になり得ます。
不安がある場合は、無理に整理で攻めず、拡張やインプレースアップグレードのように “戻しやすい” ルートを優先してください。
再発防止：ESP を「小さく作らない」「増えたら早めに整理する」
一度通して終わりではなく、次の大型更新で再発することがあります。再発を防ぐコツは 2 つです。
- 最初から ESP を 300MB 以上で確保しておく（PC 入れ替え・再インストール時の設計）
- メーカー診断ツールやファームウェア更新の残骸が増えていないか、年に1回程度チェックする
Windows Update がブート周りに触れる更新は今後も起こり得ます。ESP を “見えないから放置” ではなく、容量が有限なシステム領域として扱うことで、更新失敗のトラブルを大きく減らせます。
まとめ：KB5058499 の 98% 失敗（0x800f0922）は ESP の空き不足が本命
KB5058499 が 98% で失敗して 0x800f0922 になるうえ、CBS.log に BFSVC と memtest.efi、Last Error=0x70 が並ぶなら、まず疑うべきは EFI システム パーティション（ESP）の空き容量不足です。C: の空きや DISM/SFC にこだわるより、ESP のサイズと空きを確認し、拡張または 慎重な整理で “書き込み先” を確保するのが近道です。どうしても難しい場合は、インプレースアップグレードで修復する選択肢もあります。
コメント