以下の内容はhttps://error-daizenn.hatenablog.com/entry/2026/01/16/221121より取得しました。


Windows 11 22H2の「Intelligence Update」0x00000000失敗とオフライン更新の整理(物理隔離環境)


本記事が扱う事象は、Windows 11 Version 22H2 をインターネット未接続の物理隔離(air-gapped:物理隔離)環境で運用する際、Windows Update に「Windows Intelligence Update – Installation failed: 0x00000000」と表示され、更新が進まないケースです。2026年1月16日(UTC)に Microsoft Learn のQ&Aへ同趣旨の報告が投稿され、同時に「必要な更新パッケージを事前に入手してオフラインで適用したい」という運用要件も示されています。 (Microsoft Learn)

事象の輪郭:0x00000000が示す“失敗”とオフライン要件の衝突

本記事の対象となる事象は、更新の取得経路が断たれた状態で“定義・保護系の更新”が Windows Update に残り続ける構造です。 (Microsoft Learn)

Microsoft Learn の投稿では、Windows 11 Version 22H2 をオフライン運用しているにもかかわらず、Windows Update の画面に「Windows Intelligence Update」が提示され、インストールに失敗した結果として 0x00000000 が表示されています。さらに、Windows Security platform の更新(KB5007651)や、MSRT(Microsoft Malicious Software Removal Tool:悪意のあるソフトウェアの削除ツール)を手動導入しても改善しなかった、という経緯が併記されています。 (Microsoft Learn)

ここで重要なのは、オフライン環境では「更新を探す」「更新の適用可否を判定する」「必要な前提パッケージへ誘導する」といった一連の流れが、クラウドやMicrosoftの配信基盤と分離される点です。そのため、画面上は“更新がある”ように見える一方で、実体(必要なパッケージ一式)に到達できず、結果として失敗表示だけが残る、という条件差が生じます。そうすることによって、単発のKB導入だけでは状況が動かないケースが出ます。

「Intelligence Update」の実体:DefenderのSecurity intelligence(セキュリティインテリジェンス)と配布経路

「Intelligence Update」は多くの環境で Microsoft Defender Antivirus(Defender アンチウイルス)のセキュリティインテリジェンス更新(KB2267602系)を指す運用上の表示名です。 (Microsoft Learn)

Microsoftの整理では、Defenderのセキュリティインテリジェンス更新は主に KB2267602 として配布され、エンジン更新も同梱される運用が示されています。一方で、クラウド配信保護(cloud-delivered protection:クラウド配信保護)はインターネット接続を前提とし、オフラインでは同じ動線で更新できない条件となります。 (Microsoft Learn)

このため、物理隔離環境で“同等の更新状態”を作るには、Windows Update に頼らず、定義ファイルのオフライン配布パッケージを別経路で持ち込む方式が実務上の確認点になります。Microsoftは定義更新の手動導入向けに専用のダウンロード経路(実行ファイル形式)を提供しており、更新画面の「Intelligence Update」とは別の導入ルートを前提に設計されています。 (Microsoft)

つまり、画面上の失敗表示を“Windowsの品質更新(quality update:品質更新)全体の失敗”と同一視すると、切り分けが難しくなります。要点を整理すると、Defender系の更新は「取得元と適用手順」がWindows本体の累積更新(cumulative update:累積更新)と異なります。

22H2のサポート条件:更新が来ない状態が“異常”ではない可能性

Windows 11 Version 22H2 はエディションによってはサポート終了(提供終了)となっており、月例の更新が供給されない前提に入り得ます。 (Microsoft Learn)

Microsoftのライフサイクル告知では、Windows 11 version 22H2 の Home / Pro 等は 2024年10月8日で更新提供が終了する旨が示されています。これは「セキュリティ更新を含む更新が提供されない」状態に移行するという意味であり、物理隔離であっても前提は変わりません。 (Microsoft Learn)

この点から、2026年時点で22H2を運用している場合、Windows Update に提示される項目が「Defender系など一部の更新」へ偏る、あるいは“整合しない表示”が残る、といった現象が起きても不思議ではありません。さらに、質問への回答として「25H2へアップグレード」を案内する投稿もあり、OS世代を上げること自体が前提整理の中心になっています。 (Microsoft Learn)

なお、Windows 11 version 25H2 は Microsoft の更新履歴ページとして存在し、継続的な月例更新の枠組みに乗ることが前提になっています。言い換えると、オフライン運用の難しさを下げるには、まず“サポート対象のバージョンであること”が判断材料として重要である、という整理になります。 (Microsoft サポート)

オフラインで更新を成立させる設計:LCU/SSUと前提パッケージの扱い

オフライン適用では、累積更新(LCU:Latest Cumulative Update)とサービススタック更新(SSU:Servicing Stack Update)の関係を崩さない手順設計が中核です。 (Microsoft Learn)

Windows本体の更新は、Microsoft Update Catalog(Microsoft更新カタログ)等から更新パッケージを入手し、.msu あるいは .cab を管理者権限で適用する形が一般的です。ただし、更新は単体で完結せず、適用順序や前提KBが絡むため、物理隔離で“必要分だけ”を持ち込むほど設計負荷が上がります。Microsoft Learn のDISM手順では、/Add-Package によりパッケージ導入ができ、前提となる累積更新が必要になる場合があることも明記されています。 (Microsoft Learn)

また、SSUは更新を適用するための基盤コンポーネントであり、更新プロセスの信頼性を上げる目的で提供されます。近年はSSUとLCUが結合して配布される形も一般化しており、オフライン側で古いSSUのまま運用すると、LCUの適用可否や整合性判定が崩れる可能性があります。 (Microsoft Learn)

以上を踏まえると、物理隔離環境の更新は「(1) 対象OSバージョンをサポート対象に揃える」「(2) 月例更新はSSU/LCUの組み合わせで持ち込む」「(3) Defender定義は別系統で配る」という3レーン分離が実務設計として自然です。なお、ここで一部の手順は運用要件により表現が揺れやすく、適用範囲が広くなりまs。

更新の種類 代表例(表示名) オフラインでの論点 主な確認点
OS品質更新 LCU(累積更新) 前提KB・順序が絡む 対象ビルド、SSU/LCU整合
更新基盤 SSU(サービススタック) 古いと適用失敗が出る SSU同梱/別配布の扱い
Defender定義 Security intelligence 取得経路が別 定義配布の持込方式

ただし、22H2のようにサポート終了版を前提にしていると、Catalog上で得られるKBの組み合わせが「最新へ追従する」意味を持ちにくくなります。そのため、次章のとおり“更新の目的”を先に分けて整理する必要があります。

0x00000000を“直す”前に整理すべき論点:目的別に評価軸を分ける

0x00000000の表示を単独で追うより、OS更新・Defender更新・運用ポリシーの三者を分離して評価することが合理的です。 (Microsoft Learn)

第一に、OS本体を「サポート対象のバージョンへ移行する」目的があります。これは更新の供給を受け続ける条件であり、物理隔離でも“持ち込める更新”の質が変わります。Microsoftのライフサイクル上、22H2(Home/Pro等)は2024年10月8日で終了しているため、2026年時点の更新設計としては前提が厳しい、という構造になります。 (Microsoft Learn)

第二に、Defenderのセキュリティインテリジェンス更新はOS更新とは別の配布設計で、クラウド保護はオンライン前提です。したがって、Windows Update 画面の「Intelligence Update」失敗をゼロにすることと、マルウェア定義を最新化することは一致しない可能性があります。言い換えると、“画面表示の完了”をKPIにすると、本来の目的(定義の更新)とズレます。 (Microsoft Learn)

第三に、物理隔離環境では「何を更新対象とし、どこまでを許容するか」という運用ポリシーが必ず絡みます。例えば、OSを新しい版へ移行できない制約がある場合、Defender定義だけを別ルートで更新してリスク低減を図る、といった代替設計が現実的になります。一方で、OSの月例更新が止まった状態は脆弱性面で条件差が生じる可能性があるため、判断材料としては“バージョン移行の可否”が最も重くなります。 (Microsoft Learn)




以上の内容はhttps://error-daizenn.hatenablog.com/entry/2026/01/16/221121より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14