Windows 10 のオフライン WIM を DISM で更新しようとすると、「CBS_E_NEW_SERVICING_STACK_REQUIRED (0x800f0823)」や「0x80070002」が出て累積更新プログラム（LCU）が入らないことがあります。本記事では Windows 10 Version 2004 を例に、原因の切り分けから正しい SSU/LCU の適用順、x64/ARM64 の選び間違いを防ぐ具体手順をまとめます。
起きている現象：オフライン更新で “それっぽい” エラーが出て前に進まない
Windows ADK の DISM を使い、Windows 10 のインストールイメージ（WIM）をオフラインのまま更新する手順は一般的です。ところが、更新パッケージの選び方や適用順を少しでも外すと、エラーが変化しながら延々と失敗し続けることがあります。
| 項目 | 内容（例） |
|---|---|
| 対象イメージ | Windows 10 Version 2004（ビルド 10.0.19041.208 など）を含むオフライン WIM |
| 更新方法 | Windows ADK 2004 の DISM で /Add-Package を実行 |
| 発生したエラー① | CBS_E_NEW_SERVICING_STACK_REQUIRED (0x800f0823)（「SSU が必要」系） |
| 発生したエラー② | 0x80070002（「ファイルが見つからない」系） |
一見すると「ADK が古い？」「更新を 1 月→2 月→3 月…と順番に全部当てるべき？」と疑いたくなりますが、結論から言うと 最初に確認すべきポイントは別 です。
根本原因：WIM のアーキテクチャと更新パッケージのアーキテクチャが一致していない
オフライン更新で最も破壊力が高い落とし穴が、x64（amd64）イメージに ARM64 用の累積更新（LCU）を当ててしまう などの「アーキテクチャ不一致」です。これが起きると、エラーの内容が一貫しないことがあります。たとえば SSU 不足のように見える 0x800f0823 が出たり、途中で 0x80070002 に変わったりします。
まずは “今扱っている WIM が何者か” を DISM で確定させる
更新パッケージを探しに行く前に、対象 WIM の アーキテクチャ と ビルド を確定させます。複数インデックス（Home / Pro / Enterprise など）を含む WIM では、対象インデックスを間違えないようにしてください。
dism /Get-ImageInfo /ImageFile:C:\images\install.wim出力例（イメージ）：
Index : 1
Name : Windows 10 Pro
Architecture : amd64
Version : 10.0.19041.208ここで Architecture : amd64 と出ている場合、実務上は x64 と同義 です（「amd64」と表示されるから AMD 専用という意味ではありません）。
| DISM の表示 | 一般的な呼び方 | 意味 | 更新パッケージ選択の注意 |
|---|---|---|---|
| amd64 | x64 | Intel/AMD 64bit | 「for x64-based Systems」を選ぶ |
| arm64 | ARM64 | ARM 64bit | 「for ARM64-based Systems」を選ぶ |
| x86 | 32bit | Intel 32bit | 「for x86-based Systems」を選ぶ |
Microsoft Update カタログの “タイトル” を信じすぎない（必ず x64/ARM64 を確認）
Microsoft Update カタログで KB 番号を検索すると、同じ KB でも複数のアーキテクチャ向けのパッケージが並びます。ここで「Version 2004」と書かれているだけで飛びつくのが危険です。
- WIM が x64（amd64）なのに「for ARM64-based Systems」を選ぶ → 高確率で失敗
- WIM が ARM64 なのに「for x64-based Systems」を選ぶ → 高確率で失敗
- さらに厄介なのは、失敗時のエラーが
アーキテクチャ不一致と明示されないケースがあること
実際にハマりやすい例として、Windows 10 Version 2004 の x64 イメージに対して、誤って「2021-05 Cumulative Update for Windows 10 Version 2004 for ARM64-based Systems (KB5003173)」のような ARM64 向け LCU を適用しようとすると、DISM ログに次のような行が出て失敗します。
requires Servicing Stack v10.0.19041.504 but current Servicing Stack is v10.0.19041.153
CBS_E_NEW_SERVICING_STACK_REQUIRED (0x800f0823)このメッセージだけを見ると「SSU が古いのが原因」と断定してしまいがちですが、その前に、そもそも適用しようとしている .msu が x64 用か ARM64 用か を疑ってください。アーキテクチャが違えば、正しい SSU を選んでいても噛み合わず、遠回りになります。
「ADK が古い？」「更新を順番に当てる？」という疑問への結論
ADK のイメージバージョンが原因か
Windows ADK 2004（10.0.19041 系）を使って Windows 10 Version 2004（同じく 19041 系）のイメージを更新すること自体は、方向性として自然です。今回のようなケースで真っ先に疑うべきは ADK よりも、更新パッケージの取り違え（アーキテクチャ、対象バージョン） です。
もちろん運用上は「できるだけ新しい ADK / WinPE アドオン」を使うほうが無難ですが、ADK を更新しても、ARM64 用 LCU を x64 WIM に当てている限り解決しません。
累積更新プログラムは 1 月→2 月→3 月…と全部当てる必要があるか
結論：通常は不要です。Windows 10 の LCU（累積更新プログラム）は名前の通り累積で、基本的には「最新の LCU を 1 本当てれば過去分を内包」しています。
ただし、次の 2 点だけは例外として意識してください。
- SSU が別配布の時期：特定の LCU が「この SSU 以上が必要」と要求することがあります。その場合は SSU → LCU の順で適用が必要です。
- 前提パッチがある特殊ケース：まれに特定の更新が前提条件になることがあります（ただし一般的な LCU 運用では多くありません）。
正しい更新手順：オフライン WIM に SSU/LCU を適用する “王道フロー”
ここからは、実務で再現性が高い手順を、ミスりやすいポイント込みでまとめます。特に「どこで間違ったのか分からない」状態に陥ったときは、手順を一度テンプレ化して、毎回同じ流れで検証する のが近道です。
手順全体像
- WIM のバージョン・アーキテクチャ・対象インデックスを確認
- Microsoft Update カタログから “同じアーキテクチャ” の SSU と LCU を入手
- WIM をマウント
- （必要なら）SSU を先に適用
- LCU を適用
- 適用結果を
/Get-Packagesで確認 - アンマウントしてコミット
コマンド例（そのまま流用できるテンプレ）
パスは環境に合わせて変更してください。タイプミス対策として、更新ファイル名は短くする・フォルダを分けるのがコツです。
REM 1) イメージ情報確認
dism /Get-ImageInfo /ImageFile:C:\images\install.wim
REM 2) マウント（例：Index 1 を対象）
md C:\mount
dism /Mount-Image /ImageFile:C:\images\install.wim /Index:1 /MountDir:C:\mount
REM 3) （必要なら）SSU を適用（例：KB4598481 など）
dism /Image:C:\mount /Add-Package /PackagePath:C:\updates\SSU\windows10.0-kb4598481-x64.msu
REM 4) LCU を適用（例：KB5003173 の “x64” 版など）
dism /Image:C:\mount /Add-Package /PackagePath:C:\updates\LCU\windows10.0-kb5003173-x64.msu
REM 5) 反映状況の確認
dism /Image:C:\mount /Get-Packages /Format:Table
REM 6) コミットしてアンマウント
dism /Unmount-Image /MountDir:C:\mount /Commitポイントは、SSU と LCU のファイル名に x64 / arm64 が明示されるように保存しておくことです。人間は必ず取り違えます。仕組みで防ぐほうが強いです。
SSU と LCU の関係を整理：0x800f0823 を正しく理解する
0x800f0823（CBS_E_NEW_SERVICING_STACK_REQUIRED）は、一般的には 「より新しいサービス スタック更新プログラム（SSU）が必要」 という意味で出ます。オフライン更新でもオンライン更新でも、このメッセージが出たらまず SSU 周りを疑います。
SSU とは何か（なぜ先に必要になるのか）
SSU（Servicing Stack Update）は、Windows の更新を適用するための “更新エンジン側” を更新するパッケージです。更新作業そのものを司る部品なので、ここが古いままだと新しい LCU を処理できず、エラーになります。
- LCU：OS の機能・修正（累積）
- SSU：更新を適用する基盤（サービススタック）
ログの
requires Servicing Stack v10.0.19041.504 but current Servicing Stack is v10.0.19041.153は、「最低でも 19041.504 の SSU が必要なのに、イメージ内のサービススタックは 19041.153 しかない」という意味です。
“SSU 同梱 LCU” の時期もある（だからこそ混乱する）
Windows 10 Version 2004 / 20H2 の運用では、時期によっては SSU が LCU に同梱される 形になり、個別に SSU を当てなくても良いケースが増えました。一方で、古い LCU を当てる検証や、特定の KB に固定したい運用では、依然として「SSU を先に」が効いてきます。
実務の判断を簡単にするため、次の表のように整理しておくと便利です（“迷ったら SSU→LCU” と覚えるのも手です）。
| 状況 | 推奨手順 | よくある失敗 |
|---|---|---|
| SSU が別配布の LCU を適用したい | SSU → LCU | LCU だけ当てて 0x800f0823 |
| SSU 同梱の LCU（新しめ）を適用したい | 基本は LCU だけ（ただし環境次第） | 別アーキテクチャの LCU を当てて迷走 |
| 原因切り分けが目的 | まずアーキテクチャ確認 → その後 SSU/LCU | SSU 探しに行って時間を溶かす |
0x80070002 を見たら：本当に “ファイルが無い” のか、開けないのか
0x80070002 は一般的に「ファイルが見つからない」ですが、オフライン更新の文脈では “DISM が .msu を正しく参照できていない” という広い意味で出ることがあります。
典型原因：パスのタイプミス、引用符漏れ、長すぎるパス
まずは泥臭い確認が最優先です。特に、ログに wwindows10... のような誤字が混じっていた場合は、そこが原因の可能性が高いです。
- パスにタイプミスがないか（スペル、拡張子、フォルダ名）
- 空白を含むパスならダブルクォートで囲む
- ネットワーク共有よりもローカルに置いて試す（権限・遅延の切り分け）
- ファイルを右クリックして「ブロックの解除」（ダウンロード由来でブロックされる場合）
アーキテクチャ不一致でも “展開に失敗して 0x80070002” になることがある
もう一つ厄介なのが、アーキテクチャ不一致や、そもそも対象 OS ではない更新を指していると、DISM 内部で .msu を展開・解析する途中で失敗し、結果として 0x80070002 のような汎用エラーに見える場合があることです。
そのため 0x80070002 を見たら、パス確認の次に 「その .msu は本当に x64 版か？ ARM64 版か？」 をセットで確認してください。
中身を確認する：.msu を展開して “x64 の cab か” を見る
Microsoft Update カタログから落とした .msu は、内部に .cab を含むアーカイブです。ファイル名やタイトルを見ても不安が残る場合は、展開して中身を目視すると誤配布を防げます。
md C:\temp\kb
expand -F:* C:\updates\LCU\windows10.0-kb5003173-x64.msu C:\temp\kb展開後のファイル名や cab 名に x64 や arm64 の文字列が含まれることが多く、最終確認として使えます。
エラーコード別：最短で原因に辿り着くチェック表
| エラー | 意味（要約） | 最優先で見る場所 | やること（上から順に） |
|---|---|---|---|
| 0x800f0823 | 新しい SSU が必要（または整合性が取れていない） | DISM.log / CBS.log の “requires Servicing Stack” 行 | ① WIM のアーキテクチャ確認（amd64 / arm64） ② LCU が同じアーキテクチャか確認 ③ 対象バージョン向け SSU を用意して SSU→LCU ④ それでもダメなら、別の LCU（より新しい/古い）で切り分け |
| 0x80070002 | 参照できない/開けない（ファイル不在・パス誤り等） | 実行したコマンド行、PackagePath | ① パスのタイプミス・引用符を確認 ② ローカルパスに置き直す ③ expand で .msu を展開できるか確認 ④ アーキテクチャ不一致がないか再確認 |
ログの見方：DISM.log と CBS.log を “読む順番” を決める
オフライン更新は、ログを見ないと永遠に迷子になります。読む順番だけ決めておくと、再現性が一気に上がります。
- DISM.log：処理の入口。どのパッケージを、どの順番で、どこに当てようとしたかが分かる。
- CBS.log：更新の本丸。SSU 要求や依存関係、パッケージ評価の詳細が出る。
オフライン WIM をマウントしている場合、CBS.log はマウント先の Windows\Logs\CBS 配下に出ることが多いです（環境により出力先は変わります）。まずは DISM.log で “何を当てたか” を確定し、次に CBS.log で “なぜ弾かれたか” を追うのが効率的です。
実務での事故を減らす運用ルール（オリジナル提案）
同じミス（特にアーキテクチャ取り違え）は、気を付けるだけでは防げません。更新作業が定期運用なら、フォルダ設計と命名規則で “間違えようがない” 状態を作るのが一番です。
更新ファイルの置き方を固定する
| フォルダ例 | 置くもの | 狙い |
|---|---|---|
C:\updates\19041\x64\SSU | x64 の SSU だけ | ARM64 が物理的に混ざらない |
C:\updates\19041\x64\LCU | x64 の LCU だけ | KB を選ぶ作業を単純化 |
C:\updates\19041\arm64\LCU | ARM64 の LCU だけ | ARM64 を扱うときだけ参照 |
ファイル名に “x64/arm64” を残す（短縮しない）
ダウンロードした .msu を自分ルールで短くリネームすると、後から見分けがつかなくなりがちです。少なくとも以下の 3 要素は残すのがおすすめです。
- KB 番号（例：KB5003173）
- アーキテクチャ（x64 / arm64）
- 種別（SSU / LCU）
検証は “1 回の適用で完了する状態” を作る
更新の順番を迷い始めたときほど、検証条件を減らすのが大切です。
- 最初は「最新の LCU（正しいアーキテクチャ）」だけを当ててみる
- SSU 必須のエラーが出たら、その時点で SSU→LCU の 2 本構成に切り替える
- それでもダメなら、WIM のベースが想定と違う（インデックス違い、別バージョン）可能性を疑う
よくある質問（同じ沼に落ちたときの答え）
Q. 「amd64」と表示されるのに、ARM64 を選んでしまいました…
A. amd64 は x64 の意味です。ARM64 とは別物なので、Microsoft Update カタログでは必ず「for x64-based Systems」を選び直してください。更新が通ったら、ほとんどの場合それが原因です。
Q. SSU として KB4598481 を当てたのに 0x800f0823 が消えません
A. まず LCU のアーキテクチャ（x64/ARM64）を再確認してください。SSU の KB が合っていても、LCU が違うアーキテクチャなら噛み合いません。また、対象が Version 2004 ではなく別の WIM（20H2 や別ビルド）をマウントしていないかも併せて確認すると安全です。
Q. 0x80070002 が出て、どこが悪いのか分かりません
A. まずは “コマンドの PackagePath が本当に存在するか” を確認し、次に .msu を expand で展開できるかを見てください。展開できない場合はファイル破損や権限、アーキテクチャ不一致が疑えます。パスのタイプミス（特に 1 文字違い）も多いので、コピー＆ペーストで固定化するのがおすすめです。
今回のケースを一言でまとめると
Windows 10 Version 2004 のオフライン WIM を DISM で更新できないとき、0x800f0823 や 0x80070002 で迷走したとしても、最終的な解決が 「WIM と同じアーキテクチャ（x64）向けの累積更新（for x64-based Systems）を取り直して適用する」 だけで済むことがあります。
オフライン更新は、アーキテクチャ確認 → SSU/LCU の整合性 → パスとログ の順で潰すと、無駄に月次更新を “順番に全部当てる” という遠回りを回避できます。更新運用のテンプレとチェックリストを手元に残し、次回からは短時間で再現できる状態にしておくのが最終的な勝ち筋です。
コメント