Windows 11 Version 22H2 環境で「Intelligence Update（インテリジェンス更新）」が失敗し、インストール エラーが 0x00000000 と表示される事象が報告されています。とくにネットワーク分離などのオフライン運用では、更新の取得経路や依存関係の差が表面化しやすく、原因特定が難しくなります。本記事では、関連しやすい Windows Update エラー 0x80070490（ドライバー障害が主因と整理される）も含め、発生要因と論点を構造で整理します。 (Microsoft Learn)
- 発生している事象と更新の位置づけ
- エラー0x00000000と0x80070490をどう結び付けるか
- Microsoft Learnが示す「ドライバー障害」発生構造
- オフライン運用で論点になりやすい確認軸
発生している事象と更新の位置づけ
Windows 11 22H2 で「Intelligence Update」と表現される更新は、文脈によって対象が揺れます。実務上は、Microsoft Defender の「Security Intelligence Update（セキュリティ インテリジェンス更新）」や「Windows Security platform（Windows セキュリティ プラットフォーム）」更新、あるいは悪意のあるソフトウェア削除ツール（MSRT）など、セキュリティ系の定期更新を指して扱われることがあります。Microsoft Q&A でも、Windows Security platform（KB5007651）や MSRT を含む更新がオフライン環境で失敗する事例が併記されています。 (Microsoft Learn)
0x00000000 は原因を直接示さない表示になりやすく、更新の種類と取得経路を同時に整理する必要があります。
この点から、同じ「更新の失敗」でも、(1) Defender 系の定義・プラットフォーム更新、(2) 累積更新や機能更新（Feature Update（機能更新））、(3) サービス系の基盤更新が混在し、結果としてログ上の失敗点が異なる可能性があります。なお、Windows 11 は 22H2 から 23H2 への移行で enablement package（有効化パッケージ）を使う案内があり、機能更新の設計自体が「小さな切替」になっている側面もあります。 (Microsoft Learn)
エラー0x00000000と0x80070490をどう結び付けるか
Windows Update 画面に出る 0x00000000 は、検索しても一次情報がまとまりにくい類型として知られています。コミュニティでは、Defender の更新や Windows Update の一括処理の途中で 0x00000000 が表示され、進捗が 0% のまま失敗する、といった症状が語られています。 (Super User)
0x80070490 は Microsoft Learn で「ドライバー障害が原因」と整理されており、0x00000000 の背後で同種の失敗が起きているかが実務上の確認点になります。 (Microsoft Learn)
要点を整理すると、表示コードそのものより「どの段階で失敗したか（ドライバー処理・基盤更新・依存ファイル解決）」が判断材料になります。そのため、次のように“表示の性格”を分けて考えると論点が整理しやすくなります。
| 観点 | 0x00000000 | 0x80070490 |
|---|---|---|
| 表示の性格 | 汎用的で原因を特定しにくい | 原因類型が整理されている |
| 典型的な文脈 | Defender/複数更新の一括処理中など | 更新中のドライバー障害 |
| 調査の軸 | 失敗した更新の種類・取得経路 | ドライバー関連の失敗点 |
つまり、0x00000000 が出たケースでも、個別の更新（例：Defender、プラットフォーム、機能更新）ごとにログ上の失敗要因を分解し、0x80070490 で説明される「ドライバー処理の失敗」に合致するかを見ていく、という整理になります。 (Microsoft Learn)
Microsoft Learnが示す「ドライバー障害」発生構造
Microsoft Learn の 0x80070490 解説では、更新のインストール時にドライバー処理が失敗することが中核原因として挙げられています。症状は「保留中の更新が残る」「Servicing Stack Update（サービス スタック更新）が失敗する」「Feature Update（機能更新）のインストールが失敗する」など、多様に現れうると整理されています。 (Microsoft Learn)
同資料では、保留中更新・レジストリの古い/不整合な記録・SetupConfig.ini の破損・ドライバーファイルやハードリンク欠落が主因候補として列挙されています。 (Microsoft Learn)
ここで重要なのは、失敗が「ドライバーそのもの」だけでなく、更新処理が参照する構成情報やファイル参照（ハードリンク）にまで及ぶ点です。言い換えると、更新エンジンは“ファイルが存在するか”だけでなく、“正しい参照形で存在するか”も前提としており、その前提が崩れると更新が連鎖的に失敗しやすくなります。なお、Windows Update 全般のエラーは複数パターンがあり、権限やコンポーネント更新の失敗など、別系統の要因も並立します。 (Microsoft Learn)
以上を踏まえると、0x00000000 として見えている事象でも、内部的には「ドライバー処理失敗に起因する更新停止」か、「更新基盤（コンポーネント/権限/依存関係）の別要因」かで、切り分けの筋道が変わります。ここが次の論点である“オフライン運用時の取得経路”と結び付きます。
オフライン運用で論点になりやすい確認軸
オフライン環境では、更新の取得経路がオンライン標準と異なるため、同じ更新でも成立条件が変わります。Microsoft Q&A の事例でも、インターネット非接続の前提で「必要ファイルを手動でそろえる」課題が前面に出ています。 (Microsoft Learn)
オフラインでは「更新の種類」「依存する更新基盤」「配布方式（WSUS/カタログ/メディア）」の3点が揃わないと失敗が再現しやすい、という整理が実務向けです。
たとえば Defender 系の更新は頻度が高く、更新単体の適用だけでなく、セキュリティ基盤コンポーネント側の更新が同時期に入る場合があります。一方で、機能更新の文脈では、22H2 から 23H2 への移行は enablement package（有効化パッケージ）で案内されており、同じ「更新」でも配布物の位置づけが異なります。そうすることによって、必要な前提（サービス スタック更新の状態、保留中更新の有無、ドライバー処理の整合性）の差が結果に直結します。 (Microsoft Learn)
なお、0x00000000 のように汎用表示になる場合は、失敗した更新を特定して「それが Defender 系か、基盤更新か、機能更新か」を分けたうえで、0x80070490 が示すドライバー系の失敗構造に当てはまるかを見ていくのが整理として自然です。ここで、更新ぷログラムの保留や SetupConfig.ini などの構成ファイル不整合が絡むと、同一端末でも時期によって再現条件が変わる余地があります。 (Microsoft Learn)
