2025年5月のWindows Update以降、一部のWindows 11環境にて深刻な起動障害が報告されています。とくに仮想マシンにおいて、ACPI.sysという重要なシステムドライバに起因するエラーが顕著に発生し、企業インフラにも影響を及ぼしました。
問題の概要と背景
今回の障害はWindows 11のバージョン22H2および23H2を対象とした5月の月例更新によって引き起こされました。 この更新は通常通りWindows Updateにより配信され、多くの端末が自動的にアップデートを受け取りました。ACPI.sysはWindowsの起動に不可欠なシステムドライバであり、電源制御やハードウェア初期化を担う重要な役割を果たしています。そのため、破損や読み込みエラーが発生すると、OS自体がブートできないという重大な障害を引き起こします。今回の更新では、特定の仮想環境や構成において、このドライバに関する署名エラーや不整合が発生したと見られており、OSの保護機構が異常を検知し、起動を停止させる処理に移行したと考えられます。さらに、問題の一因として、特定の仮想ハードウェア設定との非互換性や、署名検証の失敗が疑われています。Microsoftはこれを早期に認識し、緊急対応の検討に入りましたが、影響を受けた端末数は予想を上回り、企業インフラやクラウドベースの開発環境にまで深刻な影響を及ぼしました。
エラーの詳細と影響範囲
影響を受けたのは、主にAzure Virtual MachinesやHyper-V、Citrixなど仮想化技術を使用した構成です。仮想環境ではACPIのエミュレーションに依存するため、このようなシステムドライバの破損が即座に起動不能へ直結します。一部の物理マシンでも報告がありますが、圧倒的多数は仮想マシンです。 また、家庭用エディションであるWindows HomeやProでの被害報告は限定的で、法人向け環境に集中しているのが特徴です。Microsoftの調査でも、クラウドベースのインフラとの関係性が強調されており、仮想化の拡大とともに複雑化した更新管理の限界が露呈した格好です。
Microsoftの対応とパッチ情報
この問題に対し、Microsoftは通常のパッチとは別に緊急の修正プログラム「KB5062170」をリリースしました。本パッチを適用することで、ACPI.sysエラーを修正し、Build 22621.5415および22631.5415へとアップデートが行われます。 ただし、これは自動更新の対象ではなく、Windows Updateカタログから手動でダウンロード・適用する必要があります。企業ではWSUS（Windows Server Update Services）やIntuneを通じて適用を集中管理する方法もありますが、それには事前の承認や展開ポリシーの整備が不可欠です。また、グループポリシーエディターを使用して一時的に自動更新を停止する設定も検討されました。パッチには再起動が伴うため、業務時間外の適用が推奨されており、24時間稼働の環境では特に計画的な対応が求められます。Microsoftはこの件について、Windows Release Healthポータルにて技術的な説明とあわせ、インシデント対応記録を公開しています。企業ユーザーはこれを定期的に確認し、他の未確認エラーの兆候をいち早く察知する必要があります。
起動不能時の具体的対処法
もしACPI.sysエラーによってWindowsが起動しない場合、まず試すべきは「Windows回復環境（WinRE）」の起動です。そこからシステムの復元や、更新のアンインストールを試みることが可能です。しかし、WinREが有効になっていない環境では、問題が複雑化します。 この場合、別のPCから該当のVHD（仮想ハードディスク）をマウントし、データドライブとして内容を確認・バックアップ。その後、元の環境へ戻し再起動を試すという、高度な手動作業が必要になります。Azure環境ではMicrosoftが専用の復旧手順を案内しており、それに従った操作が推奨されます。仮に復旧が困難な場合は、以前のスナップショットへのロールバックを試みるか、VHDからのクリーンブート構成を作成し直すといった代替手段も存在します。仮想環境のスナップショット取得や、クラウドバックアップの有無がこのような場面で命運を分ける要素となります。
仮想環境特有のリスクと注意点
仮想マシンは物理マシンに比べてスナップショットの取得や複製が容易な反面、ホストOSとゲストOSの更新タイミングのずれが思わぬドライバ競合を招くことがあります。 ACPI.sysのようなカーネルレベルのドライバがこれに該当し、仮想化レイヤーとの間で同期がとれないと深刻な障害が発生します。したがって、仮想環境の運用においては、更新プログラムの事前検証、段階的展開、そして即時ロールバックが可能な構成の設計が不可欠です。特にAzureやCitrixを業務インフラに組み込んでいる企業は、システムアーキテクチャの見直しが求められます。仮想マシンの世代（Generation 1と2）や、使用する仮想ディスク形式（VHDとVHDX）などの違いも、エラー発生のリスクに直結する場合があります。すべての構成に共通する「絶対安全なパターン」は存在しないため、仮想基盤の特性を理解し、各段階での検証と保守を徹底する必要があります。
今後の対策と予防策
今回の事例から学ぶべきは、重大障害の多くが「正常に動作していた構成に予期せぬ変更が加えられたときに発生する」という点です。更新に対しては、影響評価と安全確認を並行させる必要があります。特に中小企業や個人ユーザーにおいては、システムのバックアップ取得や復旧メディアの作成が、最小限の備えとして強く推奨されます。 IT部門を持たない環境でも、外部ストレージへの定期的な保存や、USB起動ディスクの保持は低コストで実現可能な対策です。また、公式のWindows更新履歴やフォーラム情報を日頃からウォッチしておくことで、未知の障害にも早期対応できます。さらに、BCP（事業継続計画）やDR（災害復旧）計画の一環として、ITリスクの特定と緊急時対応フローの整備も不可欠です。サイバー攻撃や自然災害と同様に、更新トラブルも業務停止の引き金になることから、運用マニュアル、責任者連絡系統、代替端末の準備といった非技術的対策も含めた多層的な防御体制の構築が求められます。
企業と個人に求められる行動
企業のIT管理者には、パッチマネジメント体制の見直しが求められています。これは単に更新を適用するか否かを判断するだけでなく、展開の優先順位付け、障害発生時の即時切り戻し手段、ユーザー部門との情報共有までを含む総合的な運用管理体制の構築が鍵を握ります。 一方、一般ユーザーには、自身のPC環境の脆弱性を知り、少なくとも「何が起きているのかを判断できる目」を持つことが重要です。トラブルは避けられないものとして備えを怠らない。その意識が次の障害から大切なデータや作業環境を守るのです。さらに、企業ではシステム担当者によるトレーニングや定期的な復旧訓練を実施することも、初動対応の質を左右します。反面、個人では頼れるリソースが限られているため、わかりやすい手順書やチェックリストを事前に準備することが、復旧成功率を高めます。また、サポート窓口や専門家にすぐにアクセスできる体制を整えておくことも、精神的な安心につながります。
まとめと教訓
今回のACPI.sysエラーは、システムの中核となるドライバに対する更新の失敗が、どれほど広範な影響を及ぼしうるかを如実に示した事例です。仮想環境、特にクラウドベースのVMでは1つの更新が多くのインスタンスに波及し、業務停止を招く可能性があるという点を私たちは再認識すべきです。今後もOSやドライバの進化とともにリスクはゼロにはなりませんが、それを許容しつつ備えることが持続的な運用の鍵となります。 Windowsの更新を盲目的に受け入れるのではなく、検証と監視のプロセスを構築し、適用判断を冷静に行う。企業でも個人でも、その姿勢が求められます。ITインフラの複雑化に伴い、知識と備えが分水嶺となる時代が到来しています。
