Windows Update が 100% まで進んだ直後に 0x800f0905 でロールバックしてしまう――しかも SSD のクローン後に EFI／WinRE パーティションを誤って消してしまった……。そんな最悪の組み合わせでも、落ち着いて正しく対処すれば復旧できます。本稿は「WinRE 再構築にこだわらず、まずコンポーネント ストアを健全化する」実務視点の手順を、背景原理と失敗しやすいポイントまで含めて詳述します。
発生していた症状の整理
- Windows 10 Pro 22H2 環境。累積更新プログラムのインストールが 100% まで到達するが、再起動直後に 0x800f0905 でロールバック。
- Microsoft Defender の定義更新は成功（ネットワークやサービスは稼働）。
- SSD クローン後、「未使用領域」と誤認して EFI システム パーティション（ESP） と Windows 回復環境（WinRE）パーティション を削除。
- 一般的な修復（DISM／SFC／Windows Update トラブルシューティング）では改善なし。
- 自力で EFI／WinRE を作り直し、
reagentc /enableまで試すも GUID や DiskPart のRETAIN等で躓いて未解決。
結論：0x800f0905 は「コンポーネント ストア壊れ」。WinRE の有無は無関係
0x800f0905 は Windows の Servicing Stack（コンポーネント ストア／WinSxS）に破損または不整合があるときに典型的に出るエラーです。WinRE が存在しなくても Windows Update 自体は動作します。よって「WinRE の再構築＝更新の解決」ではありません。最短で確実なのは、OS のコアとコンポーネント ストアを良品に置き換える インプレース修復（Repair Install） です。
最短解：インプレース修復（Repair Install）
前提と準備（成功率を上げるチェックリスト）
| 項目 | 推奨／目安 | 理由 |
|---|---|---|
| C: の空き容量 | 20GB 以上 | セットアップの展開・一時ファイルに必要。足りないと途中失敗の原因に。 |
| 周辺ストレージ | 不要な外付けドライブは外す | ブートファイルが別ディスクに書かれる事故を防止。 |
| サードパーティ AV | 一時的に無効化 | インストーラーのファイル操作を妨げる例がある。 |
| BitLocker | システムドライブの保護を一時停止 | 再起動後のセットアップ段階で回復キー入力を求められるのを回避。 |
| 電源 | ノート PC は AC 接続 | バッテリー切れは致命的。 |
| ブート構成 | マルチブート・複数 OS は一時的に切断 | BCD 更新の混乱を避ける。 |
ISO の入手と起動
- Microsoft 公式の Media Creation Tool で、現在の環境と同じ エディション／言語／アーキテクチャ の Windows 10（22H2）の ISO を取得。
- ISO ファイルを右クリック → [マウント]。仮想ドライブが割り当てられる。
- 仮想ドライブ直下の
setup.exeを管理者として実行。
ウィザードの要点
- 「Windows Update から更新プログラムを入手しますか？」は [今は実行しない] を選択。
（手元の ISO を唯一のソースとして使用することで、破損状態の影響を最小化） - ライセンス条項に同意。
- 「引き継ぐもの」は [個人用ファイルとアプリを引き継ぐ] を確認し、続行。
実行と完了後
- 数回再起動し、サインインしてデスクトップに戻れば完了。アプリ・設定・ユーザーデータは維持される。
- 起動後 1 分ほど待ってから 設定 → Windows Update を開き、累積更新を適用。
健全性の確認（任意だが推奨）
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow </code></pre> <p>両コマンドでエラーが出なければ、コンポーネント ストアとシステムファイルは良好と判断できます。</p>
<h3>よくある失敗ポイントと回避策</h3>
<ul>
<li><strong>空き容量不足：</strong>クリーンアップ（<code>cleanmgr</code> や一時ファイル削除）で 20GB 以上確保。</li>
<li><strong>ドライバーの干渉：</strong>古いストレージ／RST ドライバーは更新。周辺機器は最小構成。</li>
<li><strong>企業ネットワークのプロキシ：</strong>オフラインで進める（「今は実行しない」）。</li>
<li><strong>破損が重度：</strong>ISO の整合性が重要。同一バージョン・同一言語・同一アーキテクチャを厳守。</li>
</ul>
</section>
<section>
<h2>なぜ 0x800f0905 が出るのか（技術背景）</h2>
<p>Windows Update は <em>Servicing Stack</em>（コンポーネント ストア＝WinSxS）に格納されたマニフェスト・カタログ・バイナリの整合性に依存します。更新中は CBS（Component-Based Servicing）エンジンが <code>Pending.xml</code> を用意し、再起動時にパッケージを段階適用します。<strong>0x800f0905</strong> はこの過程で、欠損・署名不一致・依存関係の崩壊が検出された典型的なシグナルです。</p>
<p>主因には以下が挙げられます。</p>
<ul>
<li>中断された更新、クローン・バックアップからの不完全復元。</li>
<li>過度な「クリーンアップ」（<code>/ResetBase</code> の乱用など）で差分削除。</li>
<li>サードパーティ製 AV／チューナー系ソフト等によるファイルフック。</li>
<li>ストレージの不良セクタ・ファイルシステム不整合。</li>
</ul>
<p>この種の破損は点修復が難しいため、<strong>インプレース修復による「良品の上書き」</strong>が最短・最確実になります。</p>
</section>
<section>
<h2>WinRE は更新に不要――誤解しやすいポイント</h2>
<ul>
<li><strong>事実：</strong>Windows Update は OS パーティションとブートローダが正常なら完結します。</li>
<li><strong>誤解：</strong>「WinRE がないから更新に失敗する」→ <strong>誤り</strong>。WinRE は回復用の別環境であり、更新経路の必須要素ではありません。</li>
<li><strong>実務：</strong>更新のために WinRE を先に直す必要はありません。むしろ <em>誤設定の WinRE</em> はブート障害（<code>INACCESSIBLE_BOOT_DEVICE</code> など）を誘発し得ます。</li>
</ul>
</section>
<section>
<h2>更新後の「念のため」健全性チェックとログの見方</h2>
<h3>基本コマンド</h3>
<pre><code>DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
chkdsk C: /scan
ログ所在（参考）
C:\Windows\Logs\CBS\CBS.log（CBS エンジンの詳細）C:\Windows\WindowsUpdate.log（PowerShell のGet-WindowsUpdateLogで生成）C:\$WINDOWS.~BT\Sources\Panther（セットアップ系）
「STORE corruption」「hash mismatch」「failed to resolve package」等の記述が見られた場合、コンポーネント ストアの不整合が濃厚です。
必要になったら：WinRE パーティションの安全な再構築（任意）
繰り返しになりますが、更新の解決自体に WinRE は不要です。BitLocker 復旧や自動修復、回復ドライブの作成などが必要になったタイミングで再構築すれば十分です。以下は GPT ディスク前提の代表手順です（サイズやディスク番号は環境に合わせて調整してください）。
パーティション種別と GUID（GPT）
| 用途 | Type GUID | 典型サイズ | ファイルシステム |
|---|---|---|---|
| EFI System Partition | c12a7328-f81f-11d2-ba4b-00a0c93ec93b | 100–300MB | FAT32 |
| Microsoft Reserved (MSR) | e3c9e316-0b5c-4db8-817d-f92df00215ae | 16MB | 未フォーマット |
| Basic Data (Windows) | ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 | 任意（C: など） | NTFS |
| Windows RE Tools | de94bba4-06d1-4d40-a16a-bfd50179d6ac | 1GB 以上推奨 | NTFS |
WinRE 再構築の流れ
- 状態確認
reagentc /info「Windows RE の状態 : 無効」なら次へ。 - C: の末尾に 1GB 以上の空きを確保（必要に応じて縮小）。
- DiskPart で WinRE 用パーティションを作成（数値は例）。
diskpart
list disk
select disk 0
list volume
select volume C
shrink desired=1024 minimum=1024
create partition primary size=1024
format quick fs=ntfs label="Windows RE tools"
set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
gpt attributes=0x8000000000000001
assign letter=R
exit - WinRE 画像を配置（フォルダ作成とコピー）。
md R:\Recovery\WindowsRE
copy C:\Windows\System32\Recovery\Winre.wim R:\Recovery\WindowsRE\Winre.wim - RE の登録と有効化
reagentc /setreimage /path R:\Recovery\WindowsRE /target C:\Windows
reagentc /enable
reagentc /info </code></pre> <p>最後の <code>/info</code> で WinRE の状態が「有効」になり、場所が <code>R:\Recovery\WindowsRE</code> を指していれば成功です。<br>作業後は <code>R:</code> のドライブレターを外しておくと安全です（管理者コマンドで <code>mountvol R: /d</code>）。</p>
<h3>注意（やってはいけない操作）</h3>
<ul>
<li><strong>GUID を間違える</strong>：Type GUID は 1 文字違いでも別物。コピペ推奨。</li>
<li><strong>属性の誤設定</strong>：<code>gpt attributes=0x8000000000000001</code>（Hidden + Required）を忘れるとマウントや自動修復で不具合。</li>
<li><strong>DiskPart の <code>RETAIN</code> 誤用</strong>：目的と合わない保持設定はボリューム管理を複雑化させる。基本は不要。</li>
</ul>
</section>
<section>
<h2>EFI／ブートの再構築が必要なケース（上級者向けメモ）</h2>
<p>今回の主題（0x800f0905）とは切り離して考えるべきですが、ESP を削除してしまった／別ディスクにブートファイルが逃げた場合は、UEFI ブートエントリを作り直します。既に OS が起動できているなら、再構築は「必要になった時のみ」行ってください。</p>
<ol>
<li>ESP（FAT32 100–300MB）を作成し、仮のドライブレター（例：<code>S:</code>）を一時付与。</li>
<li>ブートファイルを再配置。</li>
</ol>
<pre><code>bcdboot C:\Windows /s S: /f UEFI
実行後、UEFI の起動順で該当ディスクを先頭に設定します。作業を誤ると起動不能になるため、バックアップと復元手段（インストールメディアの回復コンソール等）を用意した上で慎重に。
「なぜインプレース修復で直るのか」をもう一歩深掘り
- OS コアの再配置：既存のレジストリ・ドライバー・アプリを保持しつつ、良品の OS ファイルとコンポーネント ストアに置き換える。
- Servicing Stack の再初期化：累積更新の前提となる SSU/LCU 連携が整う。
- ユーザー影響が最小：クリーンインストールに比べ再構成コストが小さい。
逆に DISM/SFC のみで直らないケースは、破損が広範かつ依存解決が不能な状態です。点検修理ではなく「ユニット交換」するのが理にかなっています。
更新前後の実務チェックリスト
| タイミング | チェック項目 | 具体的操作 |
|---|---|---|
| 前 | バックアップ | ユーザーファイルを外付けやクラウドへ複製。 |
| 前 | BitLocker 一時停止 | コントロールパネル → BitLocker 管理 → 一時停止。 |
| 前 | 外付け媒体の取り外し | USB HDD／SSD／SD カード等を外す。 |
| 中 | セットアップの選択 | 「今は実行しない」「個人用ファイルとアプリを引き継ぐ」を選ぶ。 |
| 後 | Windows Update | 累積更新（LCU）を適用、再起動。 |
| 後 | 健全性確認 | DISM と SFC を実行。 |
| 後 | BitLocker 再有効化 | 保護を再開し、回復キー保管を見直す。 |
ケーススタディ：8 か月続いた 0x800f0905 を解消
あるユーザー環境（Windows 10 Pro 22H2）では、SSD クローン後に EFI／WinRE を「未使用領域」と誤認して削除。以降の累積更新は毎回 100% で止まり、再起動直後に 0x800f0905 でロールバックしていました。DISM／SFC／トラブルシューティングも空振り。WinRE の再構築や reagentc、DiskPart の属性設定に時間を費やしましたが改善せず。
方針を転換し、インプレース修復を実行。「Windows Update から更新プログラムを入手しますか？」は 今は実行しない を選択し、個人用ファイルとアプリを引き継ぐ で進行。完了後、累積更新を適用できるようになり、最終的にすべての更新が正常に完了。ユーザーは 8 か月悩んだ更新障害から解放されました。
トラブルが続く／別症状が出る場合の追加手当
- ストレージ検査：
chkdsk /scanとベンダー提供の診断で物理不良を確認。 - スタートアップ修復の準備：回復ドライブ（USB）を作っておくと安心（WinRE 再構築後）。
- ネットワーク要因：企業環境の SSL インスペクション／プロキシがある場合、隔離ネットワークやオフラインで修復。
- ログ解析：インストール失敗の直近で Panther／CBS ログを時系列で確認。「0x800f0905」と併記される副次コード（
0x800f0922等）があれば併発要因を潰す。
FAQ（よくある質問）
Q. WinRE を無効のまま放置しても大丈夫？
A. 更新には影響しません。ただし自動修復、初期化、BitLocker 回復などのシナリオで不便になります。必要になったら本稿の手順で安全に再構築してください。
Q. インプレース修復はデータを消しますか？
A. いいえ。選択肢で「個人用ファイルとアプリを引き継ぐ」を選べば基本的に保持されます。ただし万一に備え、重要データのバックアップは必須です。
Q. DISM／SFC で直らないのはなぜ？
A. 破損が広範・依存解決不能・ソース自体が壊れている等のとき、点修復では限界があります。インプレース修復で良品ソースに置き換えるのが近道です。
Q. EFI も消してしまった場合は？
A. OS が起動できるうちは焦って触らず、バックアップを取ってから bcdboot で再構築してください。誤操作はブート不能を招きます。
Q. 「今は実行しない」を選ぶ理由は？
A. 破損した更新スタックの影響を避け、ISO の良品ファイルだけで修復を完結させるためです。
まとめ
- 0x800f0905 はコンポーネント ストアの不整合が主因。WinRE の有無は直接関係しない。
- 最短解はインプレース修復。ISO をマウントして
setup.exe→ 「今は実行しない」→「個人用ファイルとアプリを引き継ぐ」。 - 修復後に Windows Update を実行し、
DISM/SFCで健全性を確認。 - WinRE は必要になった時点で正しい GUID と属性で安全に再構築。
- パーティション操作は慎重に。誤設定はブート不能のリスク。
- バックアップと空き容量、周辺機器の取り外し、BitLocker 一時停止で成功率を高める。
以上の流れに沿えば、長期化しがちな 0x800f0905 でも確実に収束できます。まずは OS コアの健全化に集中し、回復環境は「必要になったら正しく作る」。これが現場で再現性の高い王道手順です。
コメント