Windows 11の累積更新が失敗する「0x80073712（コンポーネントストア破損）」と「0x800f0915（修復コンテンツなし）」を直す実務手順

Windows 11 で「累積更新プログラムだけが入らない」「SFCは通ることもあるのに、DISM /RestoreHealth は必ず落ちる」という症状は、単なる更新キャッシュ不良ではなく、コンポーネントストア（WinSxS）側の破損や参照先の不整合が絡んでいることが多いです。とくにエラー 0x80073712（component store corrupted）と、DISM の 0x800f0915（repair content could not be found）はセットで出やすく、漫然とトラブルシューターや SoftwareDistribution 削除を繰り返しても直りません。
この記事では「再イメージ以外の現実的な打ち手」を、現場で回しやすい順に整理します。

Windows 11の累積更新が失敗する「0x80073712（コンポーネントストア破損）」と「0x800f0915（修復コンテンツなし）」を直す実務手順

症状の整理：なぜ「累積更新だけ」落ちるのか

0x80073712 は、更新の土台になる CBS（Component-Based Servicing） が参照するマニフェストやコンポーネント情報が壊れている状態で出やすいエラーです。
一方 0x800f0915 は、DISM が修復に必要なファイルを Windows Update からもローカルソースからも取得できない ときに発生します。ここで重要なのは「インターネットがある／ない」よりも、修復ソースがOSのビルド・エディションと一致しているか、そして WSUS/SCCM やポリシーが修復用ダウンロードを止めていないかです。

まずやるべき「最短で効く」復旧ルート（修復インストール系）

台数が多い環境では、1台ずつCBS破損を手作業で直すより、OSを保ったままの修復（インプレース修復） が最も成功率と工数のバランスが良いです。

1) Windows Update を使う「修復再インストール」（設定から）

Windows 11 には、更新コンポーネントを使ってOSを修復する導線があり、アプリや設定を保持したまま復旧できるケースがあります。
設定アプリから「回復」周りにある「Windows Update を使用して問題を修正（再インストール）」系の操作を試します。これで CBS/コンポーネントストアの整合性が再構築 され、累積更新が通ることがよくあります。

2) ISO からのインプレースアップグレード（同一/新しめビルド）

「すでに最新に近いバージョンなのに壊れている」端末でも、同一世代のビルドで上書き修復すると直ることがあります。ポイントは次の2つです。

ISO は 対象端末と同じ言語・エディション・世代（例：23H2/24H2） に揃える
可能なら より新しい累積更新を含むメディア（入手できる範囲で新しいもの）を使う

「25H2 だから上げようがない」という状況でも、修復の目的は“上げる”ではなく“壊れた土台を作り直す”なので、同世代メディアでの修復が効く場合があります。

手作業で直すルート：DISM が 0x800f0915 になる原因を潰す

修復インストールを避けたい／検証したい場合は、DISM が修復ファイルを見つけられていない原因を詰めます。

3) 修復ソース指定の“よくある失敗”を避ける（Index 指定が肝）

「WIM を指定したのにダメ」は、Index（エディション番号）の不一致が典型です。たとえば Pro 端末に対して Home の Index を参照すると、ソース指定しても直りません。
やるべきことは以下の流れです。

ISO をマウントして sources\install.wim または install.esd を確認
Get-WimInfo 相当で どの Index が Pro / Enterprise か を特定
RestoreHealth の Source を install.wim:<Index> 形式で指定する
企業環境では LimitAccess を付け、Windows Update に取りに行かない挙動に固定する（逆に、社内ポリシーが邪魔しているなら外して挙動を確認）

ここが合うと、0x800f0915 が消えて修復が進むケースが多いです。

4) WSUS/SCCM 環境で「修復コンテンツの取得先」が詰まっていないか

SCCM 配布で更新が落ちる端末は、端末が参照する更新・修復の取り先が複雑です。次を確認します。

「修復用のオプション機能コンテンツを Windows Update から直接ダウンロードする」系のポリシーが無効になっていないか
端末が Microsoft 側へ取りに行くことを許可する設計なのか（許可しないなら、社内に修復ソース（WIM/Features on Demand）を用意する）
プロキシやSSLインスペクションが、修復コンテンツ取得だけ失敗していないか

0x800f0915 は「ネットがあるのに出る」ことが普通にあります。原因は“通信”より“到達先と許可設計”であることが多いです。

破損ポイントを絞って当てに行く：CBSログ、pending.xml、マニフェスト

5) CBS.log を見て「壊れている名前」を特定する

C:\Windows\Logs\CBS\CBS.log に、破損したマニフェストやパッケージ名が出ます。ここで “どの KB／どのコンポーネント” が壊れているかが分かると、修復ルートが具体化します。

6) pending.xml が残骸になっているケース

更新適用途中でこけた端末では、pending.xml が残って整合性を崩していることがあります。
安易に消すのは危険ですが、更新が何か月も進まない状態で、CBSログにも pending の不整合が明確なら、回復環境や安全な手順で処理対象にする価値があります（この領域は運用ポリシーとバックアップ前提で進めます）。

“更新そのもの”を当てる：.msu から .cab を取り出して追加する

7) 累積更新を手動で分解し、CAB を DISM で投入する

「Windows Update は失敗するが、パッケージを直接入れると進む」ケースがあります。累積更新（.msu）から中身の .cab を取り出し、Add-WindowsPackage で投入して、CBSログとイベントで進捗と失敗点を確認します。
この方法は成功すれば強力ですが、環境差が出やすいので、同型機で検証してから横展開するのが安全です。

それでも直らない場合の判断基準：再イメージの前にやるべきこと

8) 「直す」より「戻す」ほうが早い境界線

次の条件が揃うと、手作業修復は沼りやすいです。

DISM がソース一致・到達性OKでも修復できない
CBS.log に複数の破損が連鎖している（マニフェスト多数、パッケージ依存が崩壊）
端末が業務影響なく短時間で差し替え可能

この場合は、修復インストール（保持）→ダメなら再イメージの順が、最終的に最安になります。逆に「端末固有設定が重い」「再セットアップが高い」なら、修復インストールを最優先に置くべきです。

運用で再発を減らすポイント（複数台で同時発生する場合）

最後に、同様の端末が20台規模で出ているなら、個別端末の偶発より“運用要因”を疑ったほうが早いです。

更新の配布リングを分け、先行グループで破損が出た時点で止められるようにする
修復ソース（ISO/WIM/FOD）を社内で標準化し、端末と完全一致するメディアをいつでも参照できるようにする
キャッシュ削除やトラブルシューターを「第一手」にしない（効果が薄いのに時間を吸う）
“累積だけ落ちる端末”は、早期に 修復インストールで土台を再構築する運用に寄せる

0x80073712 と 0x800f0915 は、いわば「更新の土台が壊れて、修復材料も届いていない」状態です。キャッシュ消しで粘るより、(1) 修復インストールで土台を作り直す、それが難しければ (2) ソース一致を徹底して DISM の修復経路を成立させる、最後に (3) CAB の直当てや再イメージという順で進めると、台数が多い現場でも最短距離になりやすいです。