【重要】このブログのスタンス：速報性と予防効果を最優先する理由（クリックで展開）
当サイトのトップページにも記載していますが、改めて、私たちの情報発信における最も重要なスタンスについてお話しさせてください。
トラブルシューティング手法などの一般記事は十分な精査を行った後に公開していますが、毎月のWindows Updateに関する記事においては「速報性と予防効果を最優先」してお届けしています。
なお、公開内容に錯誤などが含まれていた場合は、速やかに修正や続報の提供を行っています。この点はご了承の上、ご寛容ください。
このサイトではWindows Update情報や、Winの不具合情報などを発信する上で、完全な正確性より、速報性や予防効果に重きを置いているなどいくつかの注意点があります。
これは、単なる免責事項ではありません。読者の皆様のPCを深刻なトラブルから守るために、私たちが最も大切にしている編集方針です。
- 2026/09/18 07：40頃の情報に基づく整理
- 参考：自分の環境（PC）に適用されたKBを適切に調べる/削除する方法
- 参考：Win OSを「とにかく安定した状況で利用したい」という方へ
- 1.【時系列】不具合報告と動向（追跡ログ）
- 不具合情報追跡（2026/09/18 07:40頃時点）
- 不具合情報追跡（2026/09/15 14：00頃時点）
- 不具合情報追跡（2026/09/14 06：50時点頃）
- 1. Microsoft 公式の既知の問題（新規追加）
- 1. Microsoft 公式の既知の問題（新規追加）
- 2. コミュニティ報告（増加傾向）
- ■ ファイル履歴のバックアップ失敗（増加）
- ✔ 1. バックアップ先ドライブに接続できない（接続エラー）
- ✔ 2. 表示上は「正常」だがバックアップが実行されない
- ✔ 3. バックアップが途中で止まる（進行しない）
- ✔ 4. ファイル履歴の設定画面が固まる／応答しない
- ✔ 5. バックアップ先のフォルダー構造が壊れる（まれ）
- プロ/上級者向け補足（クリックで展開します）
- ● 通常フォーマットでは消えない NTFS 内部メタデータ
- ● Volume GUID が変わらず「前のドライブ扱い」になる
- ● 排他制御のロック情報が残留する
- ● Catalog / Configuration の整合性が壊れると復旧不能
- ● OS のクリーンインストール不能と構造的に同じ問題
- ■ AMD GPU/CPU 環境でのクラッシュ・フリーズ（新規報告）
- ■ ファイル履歴のバックアップ失敗（増加）
- 3. 企業環境での問題（新規）
- 4. Secure Boot / WinRE / DU（変化なし）
- 5. EFI 領域不足（変化なし）
- 6. UI 変更（Feature Flags）（変化なし）
- 不具合情報追跡（2026/09/11 08：30時点頃）
- 不具合事前お知らせ版情報（2026/09/09時点）
2026/09/18 07：40頃の情報に基づく整理
このセクションは、2026 年 9 月 9 日（水）11：00 頃に確認された初動評価をもとに、
2026 年 9 月 18 日（金）07：40 時点までの追加情報を反映して再構成しています。
広範囲で重大な障害は確認されていませんが、環境依存の事例が増えているため、
最新の注意点を併記しています。
早めの適用を推奨（2026/09/18 07：40頃）
今回の定例更新（KB5124008 / KB5122878）は、600件以上のセキュリティ修正を含み、
ゼロデイ脆弱性の修正も複数含まれています。初動時点では広範囲で重大な不都合は確認されておらず、
早めの適用が望ましい更新と判断されています。
ただし、2024〜2026 年の Windows Update は OS 基盤（Secure Boot／WinRE／署名 DB／NVRAM／ESP）に
毎月変更が入る構造に変化しており、環境依存の不都合が発生する可能性は例年より高い点に留意が必要です。
特に、デスクトップ改変ツールや UI カスタマイズツールは競合の原因となるため、
適用前に一時的に無効化またはアンインストールしておくことが推奨されます。
- 致命的なシステム障害：なし（初動時点：2026/09/09）
- 注意すべき構成（2026/09/18 時点の評価）：
・EFI／回復パーティションが狭い PC
・Secure Boot 証明書（2023 CA）展開対象の PC
・古い UEFI／未更新 BIOS 環境
・Ryzen（古い BIOS／古いドライバー構成）
・BitLocker＋TPM＋PCR7 構成
・Windows Hello（PIN／指紋）必須環境
・RGB 制御ユーティリティ／古い inpoutx64.sys 系ドライバー
・温度監視／ファン制御／OC ツールなど低レベルアクセス系ユーティリティ
・USB ドック／外付け GPU／古い周辺機器
・ファイル履歴（File History）利用環境 - 推奨アクション：バックアップ取得後、少数端末でのパイロット適用 → 問題なければ段階展開
適用前にこれだけは必ず（2026/09/18 07：40頃）
初動時点で提示した以下 10 項目は、2026/09/18 時点でも有効です。
1. 復元ポイント作成
2. イメージバックアップ取得
3. BitLocker 回復キーの確認
4. デスクトップ改変ツール・UI カスタマイズツールの一時無効化
5. RGB 制御ユーティリティ／監視ツールの古いドライバー確認
6. BIOS/UEFI 更新の有無を確認（Secure Boot 証明書移行対応）
7. EFI／回復パーティションの空き容量確認
8. 適用後は「Shift＋完全シャットダウン」→ 再起動で環境を完全読み込み
9. 回復環境（WinRE）が正常起動するか確認
10. 復元ポイント数が異常に減っていないか確認（署名 DB 更新後の挙動チェック）
補足：
Ryzen 環境では極めて少数ながら起動不能となる事例が過去に存在します。
Secure Boot や BitLocker を安易に無効化して回避するのは危険です。
また、File History 利用者は差分破損や設定初期化が発生する可能性があるため、
簡易修復（初期化・削除）は避けてください。
筆者所感として、2024〜2026 年の Windows Update は「環境依存の不都合」が増えており、
広範囲で重大障害が出ない月でも、構成によっては大きな影響が出るケースが続いています。
“自分の環境は安全だろう”と油断せず、毎月の更新前に基本的な確認を行うことが重要になったと感じています。
参考：自分の環境（PC）に適用されたKBを適切に調べる/削除する方法
現状のWinUpでは、グラフィカルインターフェース（GUI）から適用されたすべてのKBを参照することができません。またそのため、グラフィカルインターフェース（GUI）からの削除も限定されたものしかできなくなっております。
以下の記事をご参照ください。
【資料】Windows の更新プログラムを“正しく”一覧する-導入された KB を確実に確認/削除するための技術リファレンス【2026/09/08】
参考：Win OSを「とにかく安定した状況で利用したい」という方へ
一般的事項
- この項目は、導入に費用も手間もかかるため、現状のWindows Updateの仕組みを理解するための「参考情報」として設置しています。興味のある方は「【コラム-不具合撲滅】究極の選択-実は経済的？一般ユーザーこそ「Windows 11 LTSC」へ乗り換えるべき理由：1ライセンスからの購入と将来への備え【2026/03/29】」を御覧ください。
- 正直なところ、不必要な機能更新を完全に排除するには、法人向けの「安定版（LTSC）」を利用する以外に、現状根本的な解決策がありません。
- 24H2をレジストリから固定しても25H2と同じパッチが適用されてしまうことから、24H2固定は不具合防止という観点からは現状意味をなしません。
段階的適用に関する事項
WinUp適用操作時の当ブログ推奨事項
現状のWinUp動作より、以下の適用方法を推奨します。
OSとUEFIの状態を“完全初期化”してから更新を開始する（推奨）
※ インターネット接続状態で実行します。
※ 高速スタートアップを普段から無効化している場合は「完全シャットダウン」のみでOKです。
- OSの高速スタートアップ無効化
- マザーボードのFast Boot無効化
- 完全シャットダウン（Shiftキーを押しながらシャットダウン）
WinUp動作実行
※ バックアップソフトの自動バックアップやセキュリティソフトのスキャンが動作していないことを確認してください。（ファイルホールドの防止）
※ ノートPCはACアダプタ接続を推奨します。
※ VPNは切断しておくと通信が安定します。
- デスクトップで何も動作させていない状態でWinUpを開始
- 完了後に「更新の確認」を再度実行（追加分がある場合があります）
- 最後に完全シャットダウン（Shift＋シャットダウン）
※ WinUp後の完全シャットダウンは、更新後のUEFI初期化とSecure Boot鍵の再読み込みを確実に行うための安定化処置です。
※ 技術的な補足（深掘り）※クリックで展開します
■ Secure Boot 鍵・UEFI の初期化が正しく行われる
再起動では省略されることがある Secure Boot 鍵の再読み込み や NVRAM の再初期化 が、完全シャットダウンでは必ず実行されます。
これにより、証明書更新後の鍵や UEFI の設定が正しく反映されます。
■ OS 認証（Microsoft 認証サーバー）との整合性が取れる
完全シャットダウン後の起動では、OS 内部の認証情報と Microsoft 認証サーバー側の情報が同期されやすくなります。
これにより、まれに発生する OS 認証の齟齬 や BitLocker の認証まわりの不整合 が解消されることがあります。
■ ユーザープロファイルの軽微な破損が修正されることがある
再起動では修正されない、ユーザープロファイルの軽微な不整合（設定の反映漏れ・一時的な破損）が、完全シャットダウンを挟むことで修正されるケースがあります。
更新後の動作が安定しやすくなるため、結果的に WinUp の成功率向上につながります。
■ WinRE の署名DBの再読み込み
WinUp後は WinRE が更新されることがありますが、再起動では署名DBが再読み込みされない場合があります。
完全シャットダウンを挟むことで、WinRE の署名DBが正しく再読み込みされ、回復環境の整合性が保たれます。
1.【時系列】不具合報告と動向（追跡ログ）
不具合情報追跡（2026/09/18 07:40頃時点）
現時点で注意を払うべき環境
09/18追記内容
2026 年 9 月 14 日〜17 日にかけて、Microsoft は帯域外更新 KB5129195（25H2/24H2 向け）を公開し、RDS／Hyper-V Plan9 共有／USB Audio Class 1.0（マルチチャンネル）の 3 件を修正しました。これらは 9 月定例更新（KB5124008）で発生した既知の問題として公式に認められていたもので、企業環境・一般ユーザー双方に影響が出ていたため、今回の OOB によって一定の改善が確認されています。
しかし、今回の OOB 更新は「累積的（Cumulative）」であり、定例 KB を内包しているものの、DU（Dynamic Update）や Safe OS DU、WinRE DU の整合性は環境依存であるため、更新順序や既存の状態によっては例外挙動が残存する可能性があります。また、修正された 3 件以外の不具合は依然として増加傾向にあり、特に以下の項目は 9 月 15 日以降に報告数が増えています。
- Active Directory ドメイン信頼の問題（企業環境）
9 月 16 日に Microsoft が既知の問題リストへ追加した項目で、Machine Identity Isolation ポリシーが有効な資格情報を拒否し、ドメイン参加 PC のサインインが失敗する事例が増加しています。特に Server 2025 機能レベル未満のドメインコントローラーを利用している環境で顕著で、グループポリシー適用失敗や認証遅延も併発しています。 - AMD GPU（Radeon 系）のフリーズ・ブラックスクリーン
RX 6600／7700 XT／7800 XT／7900 GRE／7900 XTX／9070 XT など複数世代で報告が増加。ゲーム・動画再生・通常操作のいずれでも突然のブラックアウトやフリーズが発生し、再起動ループに陥るケースもあります。イベントログには GPU Timeout や LiveKernelEvent が多数記録され、ドライバーの初期化失敗が疑われます。現場ではドライバーのロールバックが有効とされるものの、根本的な改善には至っていません。 - Explorer.exe クラッシュ（黒画面）
サインイン直後に黒画面のまま UI が表示されない問題が増加しています。タスクマネージャーから explorer.exe を手動再起動することで復旧する例が多いものの、再発性が高く、特に AMD GPU 環境と併発するケースが目立ちます。内部的には WDDM と UI スタックの噛み合わせ不良が疑われています。 - ファイル履歴（File History）のバックアップ失敗
外部ドライブを認識しない、バックアップが開始されない、設定画面が応答しないなどの症状が増加しています。既存の履歴が壊れている場合は NTFS 内部メタデータや Volume GUID の残留が原因となり、通常の再設定では復旧できないケースもあります。特に KB 適用前後で履歴が混在している環境では、Catalog／Configuration の整合性が壊れやすく、バックアップ世代が作成されない事例が複数報告されています。 - USB Audio Class 1.0 のコード 10・無音・音量ゼロ
マルチチャンネル（8ch／3D Audio）については今回の OOB で改善が確認されていますが、標準ステレオ構成でもコード 10、無音、音量ゼロの症状が残存しています。特に古い USB DAC や USB オーディオインターフェースで顕著で、デバイスマネージャー上で初期化に失敗する事例が継続しています。
今回の OOB 更新は「累積的」であり、定例 KB5124008 を内包しているため、単体で適用しても OS ビルドは最新状態になります。しかし、DU（Dynamic Update）や Safe OS DU、WinRE DU は別経路で配信されるため、必ずしも OOB に含まれているわけではありません。ネット常時接続の PC では DU が自動適用される可能性が高いものの、Microsoft は「必ず適用される」とは明言していないため、環境によっては DU が当たらず、Safe OS／WinRE の署名整合性が崩れる可能性があります。
また、オフラインで長期間放置されていた PC をいきなりオンラインに戻した場合、Windows Update の状態遷移（10 万通り以上あるとされる）が Microsoft の想定から外れ、DU／SSU／Safe OS DU／WinRE DU が正しく適用されず、更新失敗や例外挙動が発生する可能性があります。このため、現行の Windows Update の構造では、「定例 KB → DU → SSU → OOB」の順番で適用することが最も安全と考えられます。
以上の理由から、今回の OOB によって既知の問題 3 件は改善されたものの、未修正の問題は依然として広がっており、特に AMD GPU／Explorer.exe／ファイル履歴／Active Directory の 4 系統は継続的な注意が必要です。深刻な脆弱性の修正が含まれているため、更新適用は基本的に推奨されますが、環境によっては追加の対策や検証が必要となる場合があります。
更新適用順序に関する考察
以下は慎重派としての意見であり、あくまで私の感想に近いものです。しかしながら、毎回の更新時に付随して DU（Dynamic Update）や Safe OS DU など OS 基盤に対する変更が配信されている現状を鑑みると、一考の余地があると考えています。
更新適用順序に関する考察（クリックで展開）
不具合情報追跡（2026/09/15 14：00頃時点）
2026年9月15日に Windows 11（25H2 / 24H2）向けの帯域外更新 KB5129195 が配信され、以下の不具合が修正されました。
- RDS（Remote Desktop Services）の接続障害の修正
- Hyper-V（Plan9共有）の不具合の修正
- USB Audio Class 1.0 デバイスの音声出力問題の修正
- CVE-2026-62721（特権昇格脆弱性）の解消
今回の修正により、9月9日配信分で報告されていた一部の前処理（Dynamic Update / Safe OS DU）に関連する問題が改善された可能性があります。ただし、これは現時点では推定であり、Microsoft 公式の明確な言及はありません。
なお、Secure Boot 証明書更新（PCA 2026 / UEFI CA 2023）に関連する「警備員（Guard）系の挙動」については、現時点で新規の障害情報は出ていません。
引き続き、起動時の認証挙動や BitLocker（PCR7）関連の動作については追跡を継続します。
現時点では、今回の帯域外更新による新規の重大障害は確認されていません。
不具合情報追跡（2026/09/14 06：50時点頃）
今回の 9 月定例 KB（KB5124008 / KB5122878）は、2026/09/11 時点では「重大な不具合なし」と判断されていましたが、2026/09/14 時点で Microsoft が 3 件の新規既知の問題を公式に認めた ことで、状況が大きく変化しています。
特に USB Audio Class 1.0 の動作不能 / Claude Cowork の機能低下 / RDS 接続不能 は公式認定済みであり、一般ユーザーおよび企業環境の双方に影響が出ています。
一方で、Secure Boot 証明書更新・WinRE・Dynamic Update（DU）・EFI 領域不足・UI 変更（Feature Flags）など、OS 基盤まわりの重要ポイントについては 「9/11 時点から大きな変化なし」 と評価されています。
| 項目 | 9/11 時点 | 9/14 時点 | 変化 |
|---|---|---|---|
| Microsoft 公式の既知の問題 | なし | 3 件追加（USB Audio、Claude Cowork、RDS） | 増加 |
| コミュニティ報告 | ファイル履歴（少数） | ファイル履歴（増加）、AMD クラッシュ（新規） | 増加 |
| 企業環境での問題 | なし | Always-On VPN 接続断（少数）、RDS 接続不能（公式） | 増加 |
| Secure Boot / WinRE / DU | 変化なし | 変化なし | 変化なし |
| EFI 領域不足 | 少数報告 | 少数報告 | 変化なし |
| UI 変更（Feature Flags） | なし | なし | 変化なし |
1. Microsoft 公式の既知の問題（新規追加）
9/14 時点で Microsoft が新規に 3 件の既知の問題を公式に認めています。
・USB Audio Class 1.0 デバイスの動作不能
・Hyper‑V / WSL のフォルダー共有が機能しなくなる（Plan9共有の不具合）
・RDS（リモートデスクトップサービス）の接続不能
これらは一般ユーザー・企業環境ともに影響が出ています。
1. Microsoft 公式の既知の問題（新規追加）
2026/09/14 時点で、Microsoft は 9 月のセキュリティ更新プログラムに関する既知の問題を新たに 3 件公式に認めています。
・USB Audio Class 1.0 デバイスの動作不能
・Hyper‑V / WSL のフォルダー共有が機能しなくなる（Plan9共有の不具合）
・RDS（リモートデスクトップサービス）の接続不能
これらは一般ユーザー・企業環境ともに影響が出ています。
解消策
※3 件とも、恒久的な解決策（正式な修正パッチ）はまだ提供されていません。
■ USB Audio Class 1.0 デバイスの動作不能（暫定的な回避策）
- マルチチャネル設定を 2ch（ステレオ）に変更すると復旧する場合あり
- 8ch / 3D Audio などのマルチチャネル機能を使用しない
- 別の USB オーディオデバイス（ヘッドセット等）に切り替える
■ Hyper‑V / WSL のフォルダー共有が機能しなくなる（Plan9共有の不具合：暫定的な回避策）
- Plan9共有を使用しない運用に切り替える（WSL の
--mountなど） - Hyper‑V VM を標準共有方式に切り替える
- 共有フォルダーを使う作業を一時的にローカルへ移す
- 企業環境では KB5124008 のアンインストールが現実的な暫定策
■ RDS（リモートデスクトップサービス）の接続不能（暫定的な回避策）
- KB5124008 / KB5124012 をアンインストール（企業環境で推奨される暫定策）
- Always-On VPN 環境では証明書ベースのトンネルを再設定
- 企業環境では Microsoft サポートへの問い合わせが推奨
既知の問題の詳細（クリックで展開します）
Microsoft 公式「この更新プログラムの既知の問題」（引用・クリックで展開）
USB オーディオ デバイスの起動に失敗するか、音が出なくなることがあります
現象
2026 年 9 月 8 日の Windows セキュリティ更新プログラム (KB5124012) をインストールした後、一部の USB オーディオ クラス 1.0 デバイス が起動またはオーディオの生成に失敗する可能性があります。 影響を受けるデバイスでは、次の現象の 1 つ以上が発生する可能性があります。
- デバイスは、デバイス マネージャーにエラー「このデバイスを起動できません (コード 10)」と表示します。
- オーディオ出力はありません。
- ボリューム コントロールが応答しないか、ゼロのままです。
- サウンド設定が応答しないか、使用できない。
- 一部のデバイスは、標準のステレオ構成では機能しても、8 チャンネルや 3D オーディオ モードなどのマルチチャンネル オーディオ機能を使用するとエラーが発生する場合があります。 一部のお客様からは、このような場合に 2 チャンネル モードに切り替えることでオーディオを復元できるという報告がありました。
この問題は、USB オーディオ クラス 1.0 デバイスに限定されます。
次のステップ
Microsoft は解決に取り組んでおり、追加情報があれば、このドキュメントが更新されます。
Hyper-V ベースの Linux VM でホスト フォルダー共有を使用できない場合があります
現象
2026 年 9 月のセキュリティ更新プログラム (KB5124008) をインストールした後、HCS マネージド仮想マシンを使用するアプリケーションは、Plan9 を使用して Linux VM とホスト フォルダーを共有するときに問題が発生する可能性があります。 影響を受ける仮想マシンは正常に起動しますが、Plan9 を使用して Windows ホストから共有されているフォルダーはゲスト環境で表示されないか、アクセスできません。これらの共有フォルダーに依存するアプリケーションまたはサンドボックス環境で、Plan9 ドライブ共有がマウントされていないことを示すエラーが表示される場合があります。 Claude Cowork と Linux 用 Windows サブシステム (WSL) は、この問題の影響を受ける 2 つのアプリケーションです。 Plan9 機能を使用しない Standard Hyper-V 仮想マシンは、この問題の影響を受けません。
次のステップ
Microsoft は解決に取り組んでおり、追加情報があれば、このドキュメントが更新されます。
リモート デスクトップ サービスは、2026 年 9 月のセキュリティ更新プログラム後に応答しなくなる可能性があります
現象
2026 年 9 月の Windows セキュリティ更新プログラムをインストールした後、一部の組織でリモート デスクトップ サービス (RDS) に関する問題が発生する可能性があります。一部の環境では、RDS が不安定になり、RDP 接続が数分後に失敗したり、サインインの問題が発生したり、サーバーが “リモート デスクトップ構成をお待ちください” でハングしたりする場合があります。 Microsoft 管理コンソール (MMC)、RDS ライセンス診断ツール、エクスプローラーなどの関連ツールも応答しなくなる可能性があります。 さらに、Windows Update ページが応答を停止し、読み込みインジケーターが継続的に表示される場合があります。
Microsoft サポート
即時の回避策が必要な IT 管理者は、ビジネス向け Microsoft サポートにお問い合わせください。Resolution
Microsoft は、今後の Windows 更新プログラムでこの問題に対処するよう取り組んでおり、詳細が決まり次第提供します。
※上記は Microsoft 公式ドキュメントからの引用です。
2. コミュニティ報告（増加傾向）
2026/09/14 時点では、コミュニティベースの報告が 9/11 時点より増加しています。
特に ファイル履歴のバックアップ失敗 と AMD GPU/CPU 環境でのクラッシュ・フリーズ の2件が顕著です。
■ ファイル履歴のバックアップ失敗（増加）
KB5124008 適用後、ファイル履歴が正常にバックアップを開始できず、
「バックアップが失敗する」「バックアップが開始されない」 といった報告が増えています。
9/11 時点では少数でしたが、9/14 時点では複数のユーザーから同様の事例が確認されています。
Microsoft はまだこの問題を公式には認めていません。
意外と気が付きにくいものですので、症状を具体的かつ多めに列挙しておきます。
✔ 1. バックアップ先ドライブに接続できない（接続エラー）
- ファイル履歴がバックアップ先ドライブを「利用不可」と表示する
- 外付け HDD / NAS は正常に認識されているのに、ファイル履歴だけが接続できない
- 「ドライブに接続できません」「ドライブが見つかりません」などのエラーが出る
✔ 2. 表示上は「正常」だがバックアップが実行されない
- ファイル履歴画面では「バックアップはオン」と表示される
- しかし実際にはバックアップが開始されない
- 「バックアップ中…」のまま進行しない
- バックアップ履歴が更新されない（タイムスタンプが変わらない）
✔ 3. バックアップが途中で止まる（進行しない）
- バックアップ開始後、進捗が 0% のまま動かない
- 数分後に「バックアップに失敗しました」とだけ表示される
- イベントログに「FileHistory Engine Error」が記録されるケースあり
✔ 4. ファイル履歴の設定画面が固まる／応答しない
- 設定画面が開かない
- 「ファイル履歴を使用する」ボタンが反応しない
- バックアップ先の選択画面が表示されない
✔ 5. バックアップ先のフォルダー構造が壊れる（まれ）
- FileHistory フォルダー内の構造が壊れている
- 新しいバックアップ世代が作成されない
- 古い世代だけが残る
- KB適用前の履歴が混在している環境で発生しやすい
プロ/上級者向け補足（クリックで展開します）
プロ/上級者向けの補足ですが、「とにかくこじれると厄介になる理由」でもあります。闇雲にご自分で修復を実行せず、「自分が理解できているかの確認」にも利用してくださいね。
なお、ファイル履歴は「新規開始時」だけでなく「既存履歴の操作時」にも内部情報が影響するため、状態がこじれていると通常操作でも正常に動作しないことがあります。
※ プロ向け補足：ファイル履歴が「こじれる」と復旧が難しくなる内部構造
ファイル履歴は単なるバックアップ機能ではなく、NTFS の内部メタデータ・排他制御・Volume GUID・FileHistory フォルダー内部の Catalog/Configuration など複数の要素が複雑に絡み合った仕組みです。
このため、新規にバックアップを開始する場合だけでなく、既存の履歴を操作する場合でも、壊れた内部情報が邪魔をして正常に動作しないことがあります。
● 通常フォーマットでは消えない NTFS 内部メタデータ
NTFS の内部メタデータ（$MFT、$LogFile、$Extend、$Secure など）はクイックフォーマットでは初期化されません。
そのため、壊れた FileHistory の残骸が残っていると、新規開始時も既存履歴の操作時も同じように失敗します。
● Volume GUID が変わらず「前のドライブ扱い」になる
フォーマット後でも Volume GUID が変わらない場合、ファイル履歴は壊れた履歴を参照し続けます。
これは新規開始時だけでなく、既存履歴の操作時にも影響します。
● 排他制御のロック情報が残留する
排他制御のロックが壊れた状態で残ると、バックアップが開始できない、設定画面が固まるなどの症状が発生します。
これは「新規開始時の問題」ではなく、既存履歴の操作時にも発生する問題です。
● Catalog / Configuration の整合性が壊れると復旧不能
Catalog や Configuration が壊れていると、新しい世代が作成できないだけでなく、既存の履歴を参照する処理も失敗します。
つまり、現状の履歴を使う場合でもクリアが必要になることがあります。
● OS のクリーンインストール不能と構造的に同じ問題
OS のクリーンインストール時に壊れた EFI/GPT が残っているとインストールできない現象と同様に、
ファイル履歴も OS からは内部メタデータを修復できません。
そのため、新規開始時だけでなく、既存履歴の操作時にも「クリア（完全初期化）」が必要になる場合があります。
■ AMD GPU/CPU 環境でのクラッシュ・フリーズ（新規報告）
KB5124008 / KB5126052 適用後、AMD GPU または CPU を搭載した環境で「突然のクラッシュ」「フリーズ」「再起動ループ」 といった症状が発生するという新規報告が増えています。Radeon 系 GPU で顕著との声があり、通常のドライバー更新では改善しないケースも報告されています。
Microsoft はこの問題をまだ公式には認めていません。
● 現行の具体的な発生状況
現時点で報告されている主な症状は次のとおりです。
- ゲームや動画再生中に画面がブラックアウトし、そのままフリーズする
- 負荷が高くない場面でも突然フリーズし、電源ボタン長押し以外に復帰手段がない
- 起動直後～数分以内にクラッシュし、再起動ループになる
- イベントログに GPU Timeout / LiveKernelEvent が多数記録される
- Radeon ドライバーが初期化に失敗し、「表示ドライバーの応答停止」系のエラーが増える
特に Radeon 系 GPU（6000/7000/8000 シリーズ）で顕著で、Ryzen 5000/7000/9000 系 CPU 環境でも同時に不安定化するケースがありますが、主因は GPU と Windows のグラフィックスタック（WDDM）の噛み合わせ不良と見られます。
● 過去の Ryzen 9000 番台 CPU 不具合との違い（簡易比較）
以前報告されていた Ryzen 9000 番台（例：Ryzen 9 7900X / 7950X / 9900X など）の不具合は、主に次のような特徴がありました。
- Windows Update 適用後に CPU の電力管理（SMU）・PBO・スケジューラの挙動が不安定化
- WHEA（特に Cache Hierarchy Error）が大量発生する
- BIOS 設定と OS の電源管理が噛み合わず、CPU 側が主犯となってクラッシュする
これに対して、今回の KB5124008 / KB5126052 適用後の不具合は、GPU（Radeon）と WDDM の相互作用が主因であり、CPU は巻き込まれているに過ぎないケースが多いと考えられます。症状（フリーズ・再起動ループ）は似ていますが、根本原因は（推定ですが）「CPU 側」ではなくGPU/WDDM 側」にある点が重要な違いです。
● 現時点での暫定的な対策
公式の修正パッチはまだ提供されていないため、現場で効果が報告されている暫定策をまとめます。
注意を要する手段（KBアンインストール）
KB5124008 / KB5126052 をアンインストールする（暫定的な回避策）
設定 → Windows Update → 更新履歴 → 「更新プログラムをアンインストール」から該当 KB を削除し、再起動します。
ただし、これらの KB にはセキュリティ更新が含まれている可能性があるため、アンインストールはあくまで「安定性を優先した一時的な回避策」として判断してください。
また、アンインストール後は Windows Defender の定義更新（DU）や他のセキュリティ更新との整合性が一時的に崩れる可能性があります。
そのため、ネットワークに接続しない状態で運用する・必要最小限の通信に限定するなど、セキュリティを確保した運用が必須となります。
なお、該当環境で RITR（ポイントインタイムリストア）によるロールバックが利用可能な場合は、アンインストールよりも RITR を用いた復旧の方が望ましいケースがあります。
RITR はセキュリティ更新の整合性を保ったまま更新前の状態に戻せるため、可能であればそちらを優先してください。
一般的手段
- Radeon ドライバーを 1～2 バージョン前にロールバックする
最新版では改善しないケースが多く、24.5.1 / 24.4.1 / 24.3.1 など少し前の安定版に戻すことで
症状が軽減する例があります。 - Windows のドライバー更新を一時的にブロックする
KB 削除後に再度同じドライバーや WDDM が自動適用されるのを防ぐため、
グループポリシーや「ドライバー更新の停止」ツール等で自動更新を抑制します。 - 高速スタートアップを無効化する
コントロールパネル → 電源オプション → 「高速スタートアップを有効にする」のチェックを外すことで、
ドライバー初期化不良によるクラッシュが減るケースがあります。 - AMD チップセットドライバーを最新版に更新する
CPU 側の電力管理と OS の電源管理の噛み合わせが改善され、再起動ループが減る例があります。 - BIOS の Resizable BAR / Above 4G Decoding を一時的に無効化する
Radeon 系 GPU で不安定な場合、PCIe メモリマッピング周りの設定を一時的にオフにすることで
安定するケースがあります（ただしゲーム性能は低下します）。 - PBO / Curve Optimizer を一時的に無効化する（CPU 側が不安定な場合）
Ryzen CPU の電力管理設定を標準に戻すことで、再起動ループが収まる例があります。
いずれも「根本的な修正」ではなく暫定的な回避策であり、今後 Microsoft や AMD から
公式なアナウンスや修正パッチが出る可能性があります。
AMD 環境で KB5124008 / KB5126052 適用後に不安定化した場合は、まず KB のアンインストール（非推奨）とドライバーのロールバックを検討し、そのうえで上記の設定変更を組み合わせて様子を見るのが現時点での現実的な対応方針です。
3. 企業環境での問題（新規）
KB5124008 / KB5126052 適用後、企業環境において Always-On VPN の接続断 が新規に報告されています。
特に証明書ベースのトンネル方式（IKEv2 / SSTP / IPsec）で、認証処理が途中で失敗し、
接続が維持できない・自動再接続が行われない といった事例が確認されています。
また、RDS（リモートデスクトップサービス）の接続不能は Microsoft が公式に認めた既知の問題となっており、RDS 構成の読み込みが停止する、ライセンス認証が進まない、接続後数分で切断されるなど、複数の副次的症状が発生しています。
● 企業環境で確認されている具体的な症状
- Always-On VPN が起動時に接続されず、手動接続も失敗する
- 証明書ストアの読み込みが遅延し、認証処理がタイムアウトする
- RDS 接続後、数分でセッションが強制切断される
- RDS ライセンスサービスが応答しなくなり、管理コンソールが開かない
- Windows Update 画面が固まり、RDS 関連の構成が読み込まれない
● 残念ながら、詳細な一般化した対処の提示は出来ません（企業環境の構成差）
企業環境では、VPN・証明書・RDS・ネットワーク構成・セキュリティポリシーが大きく異なるため、「共通の原因」や「共通の対処法」を提示することが事実上不可能です。同じ Always-On VPN でも、以下の要素が企業ごとに異なります。
- 証明書の発行元（AD CS / 外部 CA）
- IKEv2 / SSTP / IPsec のどれを使っているか
- RDS の構成（単一 / ファーム / ゲートウェイ / ブローカー）
- セキュリティポリシー（GPO / Intune / MDM）
- ネットワーク機器（FortiGate / Palo Alto / Cisco / YAMAHA 等）
このため、一般化した「確実な対処法」を提示することはできません。
以下はあくまで「多くの企業環境で共通して有効だった最低限の一般的対処」です。
● 一般的に有効とされる最低限の対処（企業環境向け）
- KB5124008 / KB5126052 のアンインストール（非推奨・要検証）
ただし、セキュリティ更新が含まれるため、本番環境での即時適用は推奨されません。
検証環境で動作確認を行い、ネットワーク分離した状態で一時的に回避策として利用するケースがあります。 - Always-On VPN の証明書再読み込み（certutil / 再起動）
証明書ストアの読み込み遅延が原因の場合、再読み込みで改善することがあります。 - RDS サービスの再起動（企業環境では慎重に）
一時的に接続が回復するケースがありますが、根本解決ではありません。 - RITR（ポイントインタイムリストア）によるロールバック
企業環境では最も安全な回避策です。セキュリティ整合性を保ったまま更新前の状態に戻せます。 - Microsoft サポートへの問い合わせ（企業環境では最終手段）
RDS や Always-On VPN の構成差が大きいため、企業固有の構成に応じた回答が得られます。
企業環境では構成差が大きいため、このセクション以上の詳細な一般化はできません。本番環境での対応は、必ず検証環境での再現確認と、セキュリティポリシーとの整合性を確認したうえで実施してください。
4. Secure Boot / WinRE / DU（変化なし）
Secure Boot 証明書更新、WinRE の署名 DB、Dynamic Update（DU）および Safe OS DU に関する新規情報はありません。boot.stl 欠落問題は「オフライン展開環境のみ」で継続しています。
5. EFI 領域不足（変化なし）
EFI システム領域不足による 0x800f0922 系の更新失敗は、9/11 時点から変化なく少数報告のままです。
6. UI 変更（Feature Flags）（変化なし）
Explorer やデスクトップ GUI の後日変更に伴う不具合は、9/14 時点でも新規報告はありません。
不具合情報追跡（2026/09/11 08：30時点頃）
2026 年 9 月 11 日 08:30 JST 頃の初回レポートです。実質的には初回の追跡になりますので、総合版としています。
特別注意事項：従来の復元ポイント生成数の減少
この件は不具合/障害ではありませんが、障害発生時の回復に差し支えますので、無作為抽出での確認やテキスト配布による現場個々のPCでの確認/報告をお勧めします。
なお、詳細は以下の記事をご覧ください。
【システムの復元】環境由来、それとも新機能の影響??? 重要な可能性の高い警告【2026/09/06】
2026/09/11 08：30頃時点の注目点
2026 年 9 月 8 日配信の定例 KB（KB5124008 / KB5122878）について、9 月 11 日（金）08：30 時点での全体的な状況をまとめます。
結論として、現時点で広範囲に発生している重大な不都合は確認されていません。
ただし、今月の更新は OS 基盤（Secure Boot／WinRE／署名 DB／DU／Safe OS DU）に手が入る構造であるため、以下の点に引き続き注意が必要です。
■ 今月の最大の注目点：古い UEFI での Secure Boot 証明書保持失敗
2026 年 6 月から段階的に展開されている Secure Boot 証明書（UEFI CA 2023 / PCA 2026）への移行は、UEFI ファームウェアの実装状況に強く依存します。
- 古い UEFI／未更新 BIOS の環境では、新しい証明書保持に失敗する可能性があります。
- この事象は OS 側ではなく、マザーボードの BIOS/UEFI の更新状況が大きく影響します。
- そのため、今回の KB を適用する前に、BIOS/UEFI の最新バージョンが提供されていないか必ず確認してください。
証明書保持に失敗した場合、起動遅延・追加再起動・Secure Boot Error などの例外挙動が発生する可能性があります。
■ Win11 / Win10 の軽微な不都合は「環境依存」の可能性が高い
今回確認されている軽微な不都合（ファイル履歴のバックアップ失敗、ドメイン信頼関係の破損、Secure Boot Error など）は、いずれも 発生頻度が低く、特定環境に依存している可能性が高いと見られます。
そのため、多台数展開の環境では、具体的例を列挙して「このような事象があれば報告というアナウンス」を提供することなども考慮してくださいね。
- 多数環境では問題は発生していません。
- ただし、特定の構成（古い UEFI、Server 2019 DC、古いドライバーなど）でのみ発生する可能性があります。
- そのため、読者の皆様には、もし KB 適用後に事例が発生した場合はコメント欄で報告いただけると助かります。
当ブログでは、こうした「環境依存型の少数例」については、読者からの報告をもとに随時追跡し、必要に応じて続報記事で注意喚起を行います。
■ EFI システム領域の不足には引き続き注意
Windows 10 / 11 共通で、EFI システム領域（ESP）が狭い PC では更新失敗が発生しやすい状況が続いています。
- 特に 100MB 前後の古い ESP を持つ PC は、0x800f0922 系の更新失敗が起きやすいため注意してください。
- KB5124008 / KB5122878 は OS 基盤に変更が入るため、ESP の空き容量が不足していると更新が適用できない可能性があります。
- 必要に応じて、ESP の拡張や不要な回復パーティションの整理を検討してください。
以上の理由から、今回の KB は「重大な不都合はないものの、基盤更新が多い月」であり、環境差による例外挙動が発生する可能性がある点に注意が必要です。
■ Windows 11 / Windows 10 共通
Dynamic Update（DU）／Safe OS DU の構造変化
| 現象 | 内容 | 情報源 |
|---|---|---|
| boot.stl ファイルの欠落 | 動的更新を既存の Windows イメージに展開する際、boot.stl が含まれていないと WinPE 起動が失敗（0xc0430001）。 |
[公式 1] |
| 対象環境 | オフライン展開環境のみ（オンライン更新では発生しない）。 | [公式 1] |
| 回避策 | Update WinPE スクリプトを使用するか、boot.stl を手動コピー。 |
[公式 1] |
Secure Boot 証明書更新（UEFI CA 2023 / PCA 2026）
- 追加再起動が 1 回発生する可能性（正常動作）。
- 高信頼性ターゲティングデータで識別されたデバイスのみ段階的に展開。
- 古い UEFI 環境では証明書保持に失敗する可能性（推測）。
■ Windows 11（25H2 / 24H2）
1. 確定的な不都合（Microsoft 公式・修正済分を含む）
| 不具合 | 状況 | 情報源 |
|---|---|---|
| マウスカーソル設定のリセット | 修正済み（KB5124008） | [公式 1] |
| デスクトップ背景が黒くなる | 修正済み（KB5124008） | [公式 1] |
| Teams/Outlook の予期せぬ終了（Arm64） | 修正済み（KB5124008） | [公式 1] |
| リモートデスクトップ音声再生不可 | 修正済み（KB5124008） | [公式 1] |
| boot.stl 展開問題 | 注意喚起あり（オフライン展開のみ） | [公式 1] |
| Secure Boot 証明書更新 | 正常動作（追加再起動 1 回） | [公式 1] |
2. 発生頻度は低いが複数報告がある不都合
| 不具合 | 内容 | 再現性 |
|---|---|---|
| ファイル履歴が動かなくなる | KB5124008 適用後にバックアップ失敗。 | 低（複数報告） |
| ドメイン信頼関係の破損 | Server 2019 DC と組み合わせで Secure Channel が壊れる。 | 低（複数報告） |
| Secure Boot Error | 起動時に Secure Boot Error が出る。 | 低（複数報告） |
3. 不確かだが技術的背景から注目すべき事象（推測）
| 事象 | 内容 | 背景 |
|---|---|---|
| 【推測】Secure Boot 証明書更新の段階的展開 | 対象デバイスが限定されているため環境差が出る可能性。 | 公式で段階的展開と明言。 |
| 【推測】WinRE 署名 DB 再読み込み後の起動遅延 | 証明書 DB 再構築の影響。 | 過去にも複数例あり。 |
| 【推測】古い UEFI で証明書保持失敗 | 2011 証明書の失効に伴う移行問題。 | 公式アナウンスあり。 |
| 【推測】RGB ツール／inpoutx64.sys の競合 | 古いドライバーが署名検証でブロックされる可能性。 | 既知問題として公式認定済み。 |
| 【推測】WMIC 完全削除によるスクリプト障害 | 企業環境で既存スクリプトが動作不能になる可能性。 | 公式アナウンス済み。 |
| 【推測】Feature Flags による後日 UI 不都合 | タスクバー小型化など段階的展開の影響。 | 過去にも複数例あり。 |
■ Windows 10（22H2 ESU）
1. 確定的な不都合（Microsoft 公式・修正済分を含む）
| 不具合 | 状況 | 情報源 |
|---|---|---|
| BitLocker Group Policy の問題 | 修正済み（KB5122878） | [公式 1] |
| リモートデスクトップ音声再生不可 | 修正済み（KB5122878） | [公式 1] |
| Secure Boot 証明書更新 | 正常動作（追加再起動 1 回） | [公式 1] |
2. 発生頻度は低いが複数報告がある不都合
| 不具合 | 内容 | 再現性 |
|---|---|---|
| BitLocker 回復キー入力要求 | 推奨されない Group Policy 構成で発生（修正済み）。 | 低 |
| Secure Boot 証明書更新の追加再起動 | 正常動作。 | 低 |
| EFI／回復パーティション容量不足 | 更新失敗の可能性。 | 低 |
3. 不確かだが技術的背景から注目すべき事象（推測）
| 事象 | 内容 | 背景 |
|---|---|---|
| 【推測】Secure Boot 証明書移行に伴う起動遅延 | ESU 対象でも証明書更新が継続。 | 証明書有効期限の問題。 |
| 【推測】古い UEFI で証明書保持失敗 | 2011 証明書の失効に伴う移行問題。 | 公式アナウンスあり。 |
| 【推測】DU / Safe OS DU 欠落によるアップグレード失敗 | boot.stl 問題の影響。 | 公式ドキュメントで明言。 |
| 【推測】ESU 期間中の例外挙動 | ESU 独自の更新メカニズムによる。 | 推測。 |
■ 結論（2026/09/11 08:30 時点）
- 新規の重大不都合はなし。
- 8 月の不都合はすべて修正済み。
- ファイル履歴／ドメイン信頼関係／Secure Boot Error は軽微だが複数報告あり。
- boot.stl 問題はオフライン展開のみで継続。
- Secure Boot 証明書更新は正常動作（追加再起動 1 回）。
不具合事前お知らせ版情報（2026/09/09時点）
2026/09/08配信 KB（KB5124008 / KB5122878）による障害の現状
現時点（2026/09/09 11:00頃）での俯瞰をまとめます。
Windows 11（25H2 / 24H2）
- 確定的な不具合（公式）：なし※ただし、
boot.stl欠落による「オフライン展開環境での起動失敗（0xc0430001）」は公式に記載あり（一般ユーザーは非該当）。 - 発生頻度は低いが注目すべき不具合：
・デスクトップ背景が黒くなる（8月プレビュー由来 → KB5124008で修正済）
・マウスカーソル設定が反映されない（同上）
・Arm64環境で Teams/Outlook が予期せず終了（修正済）
・リモートデスクトップの音声がローカル再生されない（修正済） - 潜在的な不具合（技術的背景による推測）：
・Secure Boot 証明書（PCA 2026 / UEFI CA 2023）更新後の一時的な起動遅延
・古いUEFI環境で証明書保持に失敗 → 再起動増加の可能性
・WinRE署名DB更新後の初回起動遅延
・inpoutx64.sys（古い監視ドライバー）使用環境でのゲームクラッシュ
・RGB制御ユーティリティ／監視ツールとの競合
・WMIC 完全削除によるスクリプト障害
・Feature Flags による後日発生型 UI 不具合（Explorer／タスクバー）
Windows 10（22H2 / ESU）
- 確定的な不具合（公式）：なし※BitLocker 回復キー要求の問題は KB5122878 で修正済。
- 発生頻度は低いが注目すべき不具合：
・BitLocker 回復キー入力要求（修正済）
・リモートデスクトップ音声がローカル再生されない（修正済）
・Secure Boot 証明書更新時の追加再起動（正常動作） - 潜在的な不具合（技術的背景による推測）：
・Secure Boot 証明書移行（2023 CA）に伴う起動遅延
・古いUEFI環境で証明書保持失敗の可能性
・EFI／回復パーティションの容量不足による更新失敗
・DU / Safe OS DU の欠落によるアップグレード失敗（boot.stl 問題）
・ESU期間中の Secure Boot 証明書移行に伴う例外挙動
2. 今回の公式発表と独自障害予測
Microsoft公式発表を含む記事開始時点の不具合（2026/09/09時点）
Microsoftが公式に認めている、今回の更新プログラムに関する既知の問題と、当サイトが独自調査により「准既知の不具合（公式未掲載だが注意が必要と判断した事象）」として扱う内容は以下の通りです。
1. Windows 11 Version 25H2・24H2 (KB5124008) の不具合
- 問題1：boot.stl 欠落による起動失敗（オフライン展開環境のみ）
- 現象：Dynamic Update（DU）を既存のWindowsイメージに展開する際、
boot.stlが含まれていないとインストールメディアからの起動が失敗（0xc0430001）。 - 回避策/状況：一般ユーザーのWindows Updateでは発生しない。企業環境でオフライン展開を行う場合は、WinPE更新スクリプトを使用するか、
boot.stlを手動コピーすることで回避可能。
- 現象：Dynamic Update（DU）を既存のWindowsイメージに展開する際、
- 問題2：Secure Boot 証明書更新時の追加再起動
- 現象：Secure Boot証明書（UEFI CA 2023 / PCA 2026）更新対象デバイスでは、1回限りの追加再起動が発生する場合がある。
- 回避策/状況：正常動作。ユーザー側での対処は不要。
- 問題3：8月プレビュー由来の軽微な不具合（KB5124008で修正済）
- 現象：デスクトップ背景が黒くなる／マウスカーソル設定が反映されない／Arm64環境でTeams・Outlookが予期せず終了／リモートデスクトップ音声がローカル再生されない。
- 回避策/状況：すべてKB5124008で修正済み。
2. Windows 10 Version 22H2 (ESU) (KB5122878) の不具合
現在、Microsoftはこの更新プログラムに関する既知の問題を公表していません。
- 補足：BitLocker回復キー要求の問題はKB5122878で修正済み。
- Secure Boot証明書更新時の追加再起動は正常動作。
公式情報ページ
本サイト独自の障害予測（2026/09/09時点）
Win11 (25H2 / 24H2) で発生する可能性のある障害 (KB5124008適用後)
- 予測される障害1：Secure Boot証明書更新後の一時的な起動遅延
- 【予測の根拠】：WinRE署名DBの再読み込みが行われるため、初回起動が遅くなる事例が過去にも複数報告されている。
- 予測される障害2：古いUEFI環境での証明書保持失敗
- 【予測の根拠】：Secure Boot証明書（UEFI CA 2011 → 2023）移行はファームウェア依存。古いUEFIでは保持失敗 → 再起動増加の可能性。
- 予測される障害3：inpoutx64.sys（古い監視ドライバー）使用環境でのゲームクラッシュ
- 【予測の根拠】：Microsoftが公式に既知の問題として認定済み。RGB制御ユーティリティや監視ツールが同ドライバーを使用する場合がある。
- 予測される障害4：WMIC削除によるスクリプト障害
- 【予測の根拠】：KB5124008でWMICが完全削除。企業環境で既存スクリプトが動作不能になる可能性。
- 予測される障害5：Feature Flagsによる後日発生型UI不具合
- 【予測の根拠】：タスクバー小型化などの新機能が段階的展開。過去にも「後日UIが変わったタイミングで不具合発生」が複数例あり。
Win10（22H2 ESU）で発生する可能性のある障害 (KB5122878適用後)
- 予測される障害1：Secure Boot証明書移行に伴う起動遅延
- 【予測の根拠】：ESU対象デバイスでもSecure Boot証明書更新が継続。WinRE署名DB再読み込みが発生する可能性。
- 予測される障害2：古いUEFI環境での証明書保持失敗
- 【予測の根拠】：2011年発行のSecure Boot証明書が2026年6月から順次失効。古いUEFIでは新証明書保持に失敗する可能性。
- 予測される障害3：EFI/回復パーティション容量不足による更新失敗
- 【予測の根拠】：KB5122878は大容量更新。EFI領域が狭いPCでは0x800f0922系の失敗が発生しやすい。
- 予測される障害4：DU / Safe OS DU の欠落によるアップグレード失敗
- 【予測の根拠】：boot.stl問題はオフライン展開環境で発生。Safe OS DUが欠落している環境ではアップグレード失敗の可能性。
おまけ：本来発生しない想定であった CA 証明書の都合による起動不能が発生した機序の推定
このセクションは、あくまで筆者による推定であり、Microsoft や OEM ベンダーから公式に開示された情報ではありません。
ただし、過去の事例・Secure Boot の仕様・署名 DB（db / dbx）の構造から見て、「なぜ本来は起動できるはずなのに、起動不能が発生し得るのか」をある程度の深度で説明できると判断したため、おまけとして機序の推定をまとめます。
前提：本来は「古い CA が残っていても起動できる」設計である
Secure Boot の標準仕様では、古い CA（例：2023 CA）が残っていても、新しい CA（例：2026 CA）が追加されていなくても、OS の起動は拒否されない設計になっています。
つまり、「CA 証明書の更新に失敗しても、通常は起動できる」というのが前提です。前回の月例で「CA 証明書が更新できていなくても起動は可能」という結論になったのは、この仕様に基づいています。
推定される機序①：禁止リスト（dbx）のみが更新される「部分成功」
Secure Boot の署名 DB は、大きく分けて許可リスト（db）と禁止リスト（dbx）で構成されています。
標準的な更新シナリオでは、
- db（許可リスト）に新しい CA（2026 CA）を追加する
- dbx（禁止リスト）に「明らかに危険な古い証明書」だけを追加する
- 古い CA（2023 CA）は、少なくとも一時的には許可リスト側に残す
ところが、一部の環境では db の更新が失敗し、dbx の更新だけが成功する「部分成功」状態が発生している可能性があります。
この場合、
- 新しい CA（2026 CA）が許可リストに存在しない
- 古い CA（2023 CA）が禁止リスト（dbx）側に入ってしまう
- 結果として「許可された CA が 1 つも存在しない」状態になる
Secure Boot は「許可された証明書が存在しない」状態をOS を起動してはならない状況とみなすため、起動を拒否し、BitLocker の回復要求や起動不能といった現象が発生し得ます。
推定される機序②：OEM ごとの Secure Boot 実装差と古い UEFI／BIOS
Secure Boot の仕様は Microsoft が定義していますが、実際の実装は OEM（マザーボードメーカー／PC メーカー）が行います。
そのため、
- db / dbx の更新順序
- 古い CA の扱い（残すか、禁止するか）
- NVRAM 上の署名 DB の構造
- TPM の PCR 設定との連動
といった部分が OEM ごとに微妙に異なります。
特に、古い BIOS／古い UEFI／古い署名 DB が残っている環境では、
- dbx の更新だけが新仕様に追従してしまう
- db 側が古いまま、あるいは更新に失敗したまま残る
- 古い CA が「禁止対象」として扱われる
という「標準仕様から見れば例外的な挙動」が発生し得ます。
この結果、本来は起動できるはずの構成が、OEM 実装差と古い環境の組み合わせによって起動不能に陥る可能性があります。
推定される機序③：Ryzen 環境での「部分成功 → 起動不能」パターン
過去の事例から見ると、Ryzen（AMD）環境では Secure Boot／署名 DB 更新が「部分的に成功した状態」で止まるケースが他の構成より多い傾向があります。
これは、
- チップセット固有の初期化順序
- OEM が採用している UEFI 実装
- 古い BIOS バージョンとの組み合わせ
などが絡んだ結果と推定されます。
Ryzen 環境で起動不能が発生した事例の多くは、
- Secure Boot の有効化／無効化を繰り返している
- BitLocker／TPM／PCR7 が複雑な構成になっている
- 古いドライバーや古い UEFI が残っている
といった「環境依存の要素が積み重なった状態」で発火しているように見えます。
筆者としての総括：仕様上は起動できるはずだが、環境依存の例外が現実には存在する
総合すると、仕様上は「CA 証明書の更新に失敗しても起動できる」設計であるにもかかわらず、現実には起動不能が発生し得る理由は、
- db / dbx の更新が「部分成功」に終わるケースがある
- 古い CA が禁止リスト側に入ってしまう OEM 実装が存在する
- 新しい CA が許可リスト側に正常に追加されていない環境がある
- 古い UEFI／BIOS／署名 DB が残っている構成で、これらが複合的に作用する
という複数要因の組み合わせによる「環境依存の例外」だと推定されます。
繰り返しになりますが、このセクションはあくまで筆者による推定であり、
公式な技術文書ではありません。
ただし、読者が「なぜ本来は起動できるはずなのに、起動不能が発生し得るのか」を理解する一助になればと考え、おまけとして機序の推定をまとめました。
どのような機材で発生しやすいか（推定）
今回の CA 証明書更新に伴う起動不能は広範囲ではありませんが、以下のような構成では発生しやすいと推定されます。
- 古い BIOS／古い UEFI が残っている PC
Secure Boot の実装が旧仕様のまま残っている場合、db / dbx の更新順序が標準と異なる可能性があります。 - Ryzen（AMD）環境で、署名 DB が古いままの構成
過去の事例から、Ryzen 環境では Secure Boot の更新が「部分成功」で止まるケースが他より多い傾向があります。 - OEM 独自の Secure Boot 実装を採用している機種
特に自作 PC／BTO PC／一部の海外 OEM は、db / dbx の扱いが標準仕様と異なる場合があります。 - BitLocker＋TPM＋PCR7 が複雑に構成されている環境
Secure Boot の証明書更新と PCR の整合性が崩れると、起動拒否や回復要求が発生しやすくなります。
成功と表示されていても内部で書き換えに失敗している可能性（推定）
Secure Boot の証明書更新や署名 DB（db / dbx）の書き換えは、UEFI 上では「成功」と表示されていても、内部では一部の処理が失敗している可能性があります。これはユーザー側で確認する手段がなく、特に古い UEFI／古い BIOS／OEM 独自実装の環境では発生しやすいと推定されます。
このような「表面上は成功だが内部では部分失敗している」状態では、古い CA が禁止リスト（dbx）側に入ってしまったり、新しい CA が許可リスト（db）に追加されないなど、起動不能につながる例外的な挙動が発生する可能性があります。
現状、この内部状態をユーザーが直接確認する方法はありません。
もし事前にできる対策があるとすれば、マザーボードの BIOS／UEFI を（対応版がある場合には）最新バージョンへ更新しておくことが最も有効です。最新ファームウェアでは Secure Boot の実装が新仕様に追従しているため、署名 DB の「部分成功」や「禁止リストだけ更新される」などの例外が発生しにくくなります。
※ ほかのメーカーも同様ですが、「特にHP製品ではBIOSが独特ということが言われています」ので、必ずHPのサポートページを確認してくださいね。
どうしたらいいのか（推定ベースの対処）
推定される機序を踏まえると、以下の対処が有効と考えられます。
- BIOS／UEFI を最新化してから更新を適用する
db / dbx の扱いが新仕様に追従しているため、部分成功のリスクが大きく下がります。 - 署名 DB（db / dbx）を初期化しない
誤って初期化すると古い CA が禁止扱いになる可能性があります。 - Secure Boot を安易に無効化しない
無効化 → 再有効化の過程で db / dbx が再構成され、部分成功が発生する可能性があります。 - BitLocker 回復キーを必ず事前に確認する
起動不能が発生した場合、回復キーがないと復旧が困難になります。 - 古い周辺機器・古いドライバーを一時的に外す／無効化する
Secure Boot の検証フェーズで競合が起きる可能性を減らします。
以上はあくまで推定に基づく対処ですが、環境依存の不都合が増えている現状では、
事前準備として有効であると考えられます。
諸注意情報等
この記事について
この記事は、2026年9月8日に配信された Windows Update 定例更新（Bリリース）（Windows 11: KB5124008 / Windows 10 ESU: KB5122878）について、現在進行中の不具合情報および予防・回避策に特化して解説するものです。
| 項目 | 内容 |
|---|---|
| 対象KB | Win11 (25H2 / 24H2): KB5124008 Win10 (22H2 ESU): KB5122878 |
| キーワード | Windows Update, 不具合, Secure Boot証明書更新, WinRE署名DB, Dynamic Update, boot.stl, WMIC削除, 2026年問題, インストール失敗, 2026年9月 |
| 最新情報更新日 | 2026/09/09 … 初版公開（2026/09/09 11:00頃） 2026/09/11 … 08:30時点の情報を反映（初動評価の更新） 2026/09/14 … 07:50時点の情報を反映（環境依存の不都合の追加） 2026/09/18 … 07:40時点の最新情報を反映（RDS／Hyper-V／USB Audio Class 1.0 の修正、AMD GPU・Explorer・File History の追加事例を反映） ※ 以降の追記は本文中の時系列セクションにて随時反映します。 |
アップデート適用前の準備と心構え
Windows Updateには、予期せぬ不具合のリスクが常に伴います。アップデートを適用する前には、必ず万全の準備を行い、ご自身のPCとデータを守るための「自衛策」を講じてください。
具体的な準備の手順については、以下のまとめ記事で詳細に解説しています。アップデート作業を開始する前に、必ず一度ご確認ください。
最低限、以下の3点は必ず実施するようにしてください。
- システムの復元ポイントの作成
- システム全体のイメージバックアップの取得
- BitLocker回復キーの確認と保管
Q&A（2026/09/18 07：40時点）
一般向け
Q1. 更新後にアプリがクラッシュします。故障でしょうか？
A1. 故障ではなく、古いドライバーの競合が原因の可能性が高いです。
特に inpoutx64.sys を使用する古い監視ツールや RGB 制御ユーティリティは、
今回の更新（KB5124008）と競合しやすく、ゲームやユーティリティがクラッシュする事例があります。
ドライバー更新または該当ツールの停止で改善する場合があります。
Q2. 更新後に起動が遅くなりました。問題ですか？
A2. Secure Boot 証明書更新後の一時的な挙動です。
今回の更新では Secure Boot 証明書（UEFI CA 2023 / PCA 2026）が段階的に展開されており、
WinRE の署名DB再読み込みが行われるため、初回起動が遅くなることがあります。
通常は1回限りで、故障ではありません。
Q3. 更新後に BitLocker の回復キーを求められました。
A3. Windows 10 ESU の一部構成で発生していた問題で、KB5122878 にて修正済みです。
推奨されない BitLocker Group Policy を使用している環境で発生していましたが、
今回の更新で改善されています。
Q4. 更新後にデスクトップ背景が黒くなりました。
A4. 8月プレビュー（KB5120998）由来の不具合で、KB5124008で修正済みです。
今回の定例更新を適用することで改善します。
Q5. 更新中に「0x800f0922」エラーが出て失敗します。
A5. EFIパーティションの容量不足が原因の可能性があります。
Secure Boot 証明書更新や WinRE 更新が入るため、システム領域が狭いPCでは失敗しやすくなります。
EFI領域の拡張が必要になる場合があります。
Q6. Ryzen（AMD）環境で起動不能になりました。故障ですか？
A6. 故障ではなく、Secure Boot 証明書更新の「部分成功」が原因の可能性があります。
古い BIOS／古い UEFI／古い署名DBが残っている環境では、
CA 証明書の更新が内部で失敗し、起動不能になる例外的な事例があります。
BIOS/UEFI を最新化することで改善する場合があります。
Q7. ファイル履歴（File History）が壊れました。どうすれば？
A7. 簡易修復（初期化・削除）は絶対に避けてください。
今回の更新に限らず、ファイル履歴は差分破損や設定初期化が起きやすい構成です。
バックアップ先の再接続、別ドライブへの退避、履歴の手動コピーなど慎重な対応が必要です。
特殊（一般向け：Windows 10 延長サポート）
- Windows 10 は 2025 年 10 月で通常サポートが終了しています。
2026 年以降も Windows 10 を安全に使うには、ESU（延長セキュリティ更新）の契約が必要です。 - 2026 年は Secure Boot 証明書更新が重なる重要な年です。
ESU を適用していない Windows 10 は、Secure Boot 証明書の更新が受け取れず、
将来的に起動不能リスクが高まる可能性があります。 - 今回の KB5122878 は ESU 契約者のみが受け取れる更新です。
BitLocker 回復キー問題の修正や Secure Boot 証明書更新など、
Windows 10 を継続利用する上で重要な修正が含まれています。 - 一般ユーザーでも ESU の導入判断が必要です。
・Windows 10 を今後も使い続けたい
・PC が古くて Windows 11 にアップグレードできない
この場合は ESU の導入を検討する必要があります。
特殊（上級者・PC管理者向け：Windows 10 ESU）
- ESU は毎年更新が必要です（2025 → 2026 → 2027 → 2028）。
更新していない端末は Secure Boot 証明書更新を受け取れず、起動不能リスクが高まります。 - Secure Boot 証明書（UEFI CA 2011 → 2023 → PCA 2026）移行は ESU 環境で継続展開されます。
古い UEFI 環境では保持処理が複数回走る、または失敗する場合があります。 - EFI / 回復パーティションの容量不足は ESU 環境で顕著です。
Secure Boot 証明書更新や WinRE 更新が入るため、EFI が 100MB 程度しかない古い PC では
0x800f0922 が発生しやすくなります。 - 2028 年 10 月に ESU が完全終了します。
その後は Windows 10 を安全に運用する方法がなくなるため、
2026〜2028 の間に Windows 11 への移行計画が必須です。
上級者・PC管理者向け
Q1. Secure Boot 証明書更新後に再起動が増えました。問題ですか？
A1. 正常な挙動です。
古い UEFI 環境では証明書保持処理が複数回走ることがあります。
Q2. WinRE の署名DB更新後に起動が遅くなります。
A2. 初回のみ発生する正常な挙動です。
2回目以降は通常速度に戻ります。
Q3. WMIC が削除されてスクリプトが動きません。
A3. KB5124008 で WMIC が完全削除されました。
PowerShell（Get-WmiObject / CIM）への移行が必須です。
Q4. Ryzen環境で Secure Boot が壊れたように見えます。
A4. 証明書更新の「部分成功」が原因の可能性があります。
BIOS/UEFI の最新化で改善する場合があります。
記事中の専門用語の解説（2026/09/18 07：40時点）
- Secure Boot 証明書（UEFI CA 2023 / PCA 2026）
- Windows の起動時に「信頼できるブート構成かどうか」を検証するための電子証明書です。
2026 年は旧証明書（UEFI CA 2011）が失効するため、新しい証明書（UEFI CA 2023 / PCA 2026）への移行が段階的に行われています。 - 古い BIOS／古い UEFI／OEM 独自実装の環境では、証明書更新が「部分成功」に終わり、起動不能が発生する例外的な事例があります。
- Windows の起動時に「信頼できるブート構成かどうか」を検証するための電子証明書です。
- 署名DB（db / dbx）
- Secure Boot が使用する「許可リスト（db）」と「禁止リスト（dbx）」の総称です。
- db が更新されず、dbx のみ更新されると古い CA が禁止扱いとなり、起動不能が発生する可能性があります。
- WinRE 署名DB（Recovery Environment Signature Database）
- Windows 回復環境（WinRE）が使用する署名データベースです。
- 更新後は署名DBの再読み込みが行われるため、初回起動が一時的に遅くなることがあります（正常な挙動）。
- Dynamic Update（DU）
- Windows のアップグレード時に、最新のセットアップコンポーネントやドライバーを自動取得する仕組みです。
- オンライン更新では自動適用されますが、オフライン展開環境で欠落すると起動不能（0xc0430001）が発生する場合があります。
- Safe OS Dynamic Update（Safe OS DU）
- Windows セットアップの「安全な OS フェーズ」で使用される更新コンポーネントです。
- boot.stl を含む Safe OS DU が欠落していると、オフライン展開環境で WinPE が起動できず、0xc0430001 が発生します。
- boot.stl
- Windows セットアップが WinPE（Windows Preinstallation Environment）を起動する際に必要となる構成ファイルです。
- オフライン展開環境で欠落していると、インストールメディアからの起動が失敗します。
- WMIC（Windows Management Instrumentation Command-line）
- Windows の管理情報を取得するための古いコマンドラインツールです。
- KB5124008 で完全削除され、今後は PowerShell（CIM / WMI）への移行が必須となります。
- inpoutx64.sys
- 古い監視ツールや RGB 制御ユーティリティが使用する低レベルアクセスドライバーです。
- 今回の更新（KB5124008）と競合し、ゲームやユーティリティがクラッシュする既知の問題が Microsoft により認定されています。
- EFI パーティション（ESP）
- Windows の起動に必要なブートローダーや Secure Boot 証明書を格納する領域です。
- 容量が不足していると更新が失敗し（0x800f0922）、Secure Boot 証明書更新が適用できない場合があります。
- TPM / PCR7
- TPM は暗号鍵を安全に保持するハードウェアモジュール、PCR7 は起動構成の整合性を記録する領域です。
- Secure Boot 証明書更新と PCR の整合性が崩れると、BitLocker 回復要求や起動拒否が発生する場合があります。
最後に（2026/09/18 07：40頃時点）
記事を最後までお読みくださりありがとうございました。
2026 年 9 月の定例更新は、表面的な新機能よりも、Secure Boot 証明書の更新、WinRE の署名 DB 更新、WMIC の完全削除など、OS の基盤部分に手が入る内部メンテナンス色の強い月となりました。これらは将来の安定運用に向けた重要な更新ですが、環境によっては一時的な起動遅延や、古いドライバーとの競合が発生する可能性があります。
2026/09/18 07：40 時点では、広範囲で発生している重大な不具合は確認されていません。ただし、今回の月例は環境依存の例外挙動が発生しやすい月であり、特定の構成では注意が必要です。
特に以下の構成では、例外的な挙動が発生する可能性があります：
- 古い BIOS／古い UEFI が残っている PC
- Ryzen（AMD）環境で署名 DB が古いままの構成
- Secure Boot 証明書更新が「部分成功」で止まる可能性がある環境
- BitLocker＋TPM＋PCR7 が複雑に構成されている PC
- ファイル履歴（File History）を利用している環境
- AMD GPU（Radeon 系）でフリーズ・ブラックスクリーンが発生する構成
- Explorer.exe がサインイン直後にクラッシュする構成
これらの構成では、起動不能・BitLocker 回復要求・ファイル履歴の差分破損・GPU フリーズなど、広範囲ではないものの、刺さる人には刺さる不都合が発生する可能性があります。
また、Secure Boot 証明書の段階的展開に伴い、古い UEFI／未更新 BIOS 環境では証明書保持処理が複数回走る、または内部で失敗する場合があります。多数環境では問題は起きていませんが、特定構成でのみ発生するケースがあるため、今後も慎重な観測が必要です。
本記事では、初動（9/9）、総合版（9/11）、中間情報（9/14）、そして最新情報（9/18）を反映し、今後新たな動きがあり次第、時系列セクションに追記してまいります。
もしこの記事がお役に立てましたら、ぜひ SNS でのシェアをお願いいたします。皆様のフィードバックが、次の検証の大きな力になります。
付録：この記事の作成プロセス（AI協働メモ 2026-09/18版）
1. この記事の目的と役割
2026年9月の定例更新（KB5124008 / KB5122878）は、表面的な新機能よりも、OS基盤の更新（Secure Boot・WinRE・WMIC削除・DU構造）が中心となりました。
この記事は、これらの内部更新がユーザー環境にどのような影響を与えるかを整理し、「何が起きているのか」「どう備えるべきか」を理解できるようにすることを目的としています。
- Secure Boot 証明書更新による起動挙動の変化を技術的に説明する。
- WinRE署名DB更新に伴う初回起動遅延の理由を整理する。
- WMIC削除に伴う企業環境のスクリプト障害リスクを明示する。
- DU / Safe OS DU の欠落がオフライン展開環境で起動失敗を招く理由を説明する。
- EFI/NVRAM/ESP の容量不足が更新成功率に与える影響を整理する。
- 一般ユーザー・管理者が取るべき自衛策を提示する。
2. 筆者の関連経験・専門性
この記事の執筆にあたり、主筆である井上 公敬の以下の経験・知見が活かされています。
- 30年以上の機材利用・保守経験： PC-98時代から現代のAI PCまで幅広く扱い、OS修復・ブート構造解析に長年従事。
- Windowsコミュニティでの実績： Microsoft コミュニティのWindows部門モデレーター経験を持ち、OS内部仕様に精通。
- UEFI/NVRAMの実機解析スキル： Secure Boot証明書（db/KEK）やUEFI変数の状態をPowerShellで直接検証。
- 専門メディア運営15年以上： 「Win PCトラブル解決ガイド」を長期運営し、実務者視点での検証記事を多数公開。
- 寒冷地での運用経験： 北海道十勝の厳しい環境でのPC運用ノウハウを持ち、理論だけでなく実働環境での安定性を重視。
3. AIとの協働内容（調査・議論のポイント）
記事作成の過程で、AI（Gemini / Perplexity / Copilot）とは以下のような論点について議論・検証を行いました。
- Secure Boot 証明書（UEFI CA 2023 / PCA 2026）の段階的展開と起動挙動への影響。
- WinRE署名DB更新後の初回起動遅延の技術的背景。
- WMIC削除による企業スクリプトの互換性問題。
- Dynamic Update（DU）と Safe OS DU の構造変化、boot.stl 欠落時の起動失敗要因。
- EFI/NVRAM/ESP の容量不足が更新成功率に与える影響。
- WSUS/SCCM/MDT環境での DU の扱いと閉域網でのリスク。
- 2026年証明書問題（UEFI CA 2011失効）の実務的影響。
4. 主な参照情報・検証方法
この記事の作成にあたり、以下の情報源と検証手法を重視しました。
- Microsoft公式ブログ（Windows Insider Blog / Quality Update Blog）
- KB5124008 / KB5122878 の公式ドキュメント
- 実機PC（複数世代）での更新挙動の観測（起動遅延・署名DB再読み込み・DU適用状況）
- PowerShellによるSecure Boot証明書状態の直接確認
- SetupDiag / CBS.log / WindowsUpdate.log の解析
- 海外フォーラム（Reddit / TechCommunity）での初期不具合報告の比較分析
※ 上記以外にも、筆者の長年の実体験と一般的な技術情報に基づき、「現時点で最も安全な解釈」を優先して記述しています。
この記事中の広告リンクについて
この記事中の広告リンク一覧です。
記事本文中の広告リンク
このブログは、広告収入によって運営されていますが、この記事の本文中に個別の広告リンクは含まれていません。
サイドバーやヘッダー部分などの広告
広告が表示されています。
業者名や商品名など
この記事では明示的にプロモーションとして取り扱っているものはありません。
ただし、過去のプロモーションなどで取り扱った商品名や企業名などがプロモーション目的ではなくとも記載されている場合があります。
過去のプロモーションなどで取り扱った企業名は、できる限りステマ規制に関する表示についてのアフィリエイト等関連業者名一覧の項で記載していますので、お手数ですがそちらでご確認ください。
コメント