今回の特別情報：6月の CA/DB 証明書の更新（切り替え）について
概要
現在進行している Secure Boot 関連の CA/DB 証明書更新は、6 月の Windows Update で段階的に反映される見込みです。ただし、一般ユーザー側で「マザーボード上の証明書が更新されたかどうか」を完全に確認する手段は存在しません。一部のマザーボードでは UEFI（BIOS）内の Key Management 画面から確認できる場合がありますが、メーカー実装差が大きく、すべての機種で確認できるわけではありません。また、PowerShell などから証明書情報を取得する方法もありますが、抽出できる項目に制限があり、100％の照合が可能とは言えません。
なお、CA/DB 証明書が期限切れになったとしても、PC が起動不能になるといった深刻な影響は発生しないとされています。これはメーカー各社が公式に案内している内容と一致しています。影響が出るとすれば、将来のセキュリティ更新や Secure Boot 関連の更新が正常に適用されるかどうかといった部分であり、コンシューマー側で現実的に取れる対策は「今後の KB 更新が問題なく適用されるかを見守る」ことになります。
6 月は実際に証明書切り替えが行われるタイミングであり、セキュリティ関連の更新も多い時期です。そのため、6 月以降数回の Windows Update の挙動を確認していくことが重要です。特に Secure Boot を有効にしている環境では、更新が正常に通っているかを継続的にチェックしておくと安心です。
一般ユーザーが確認しておきたいポイント
今回の CA/DB 証明書更新について、一般ユーザーが実際に確認すべき点は複雑な操作ではありません。次の 3 点を押さえておけば十分です。
1. Windows Update が正常に完了しているか
「設定 → Windows Update」で更新が失敗していないかを確認します。特に 6 月以降の更新が毎回正常に適用されていれば、証明書更新も内部で問題なく処理されていると考えて差し支えありません。
2. Secure Boot が無効化されていないか
「設定 → 更新とセキュリティ → 回復 → 今すぐ再起動 → UEFI 設定」で Secure Boot が有効になっているかを確認します。無効になっている場合、証明書更新が適用されない可能性があります。
3. 特定のエラー（0x800f0922 など）が繰り返し出ていないか
更新が毎回同じエラーで失敗する場合、ESP 容量不足など別の要因が潜んでいる可能性があります。この場合は、更新が通るかどうかを重点的に確認する必要があります。
これら 3 点が問題なくクリアできていれば、CA/DB 証明書の更新について特別な操作を行う必要はありません。Windows Update が正常に適用され続けていることが、最も確実な確認方法になります。
上級者・PC管理者向け：CA/DB 証明書更新の技術的背景
ここから先は、Secure Boot や証明書階層の仕組みをより深く理解したい方向けの技術的な補足です。
（クリックで展開）上級者・PC管理者向け：CA/DB 証明書更新の技術的背景
一般事項
■ Secure Boot の証明書階層について
Secure Boot は複数の証明書階層（PK / KEK / DB / DBX）で構成されており、今回の更新対象は主に「KEK（Key Exchange Key）」および「DB（許可リスト）」です。これらは UEFI 内部に格納されており、Windows Update によって段階的に更新されます。
■ なぜ「期限切れ＝起動不能」にならないのか
Secure Boot の検証は「署名の信頼性」を確認する仕組みであり、証明書の有効期限そのものを厳密にチェックする設計ではありません。期限切れ状態でも既存の OS ブートローダーは署名が一致しているため、起動不能にはなりません。
■ PowerShell で確認できる範囲と限界
PowerShell の Get-SecureBootUEFI コマンドで KEK や DB の一部情報を取得できますが、メーカー実装差が大きく、抽出できる項目も限定的です。特に「更新されたかどうかの完全照合」は不可能で、あくまで目安として扱う必要があります。
■ UEFI（BIOS）で確認できる機種がある理由
ASUS・MSI・Dell など一部メーカーは Key Management 画面で KEK/DB の日付や署名者を表示できますが、これはメーカー独自実装であり、すべての機種で確認できるわけではありません。
■ 実務的に重要なのは「今後の更新が通るか」
証明書更新が未適用のまま長期間放置すると、将来の Secure Boot 関連更新（脆弱性対策）が適用できなくなる可能性があります。したがって、6 月以降の Windows Update が正常に適用されているかを確認することが、最も現実的で確実な対策となります。
※信頼性モニターは「Windows Update が表面上成功していても、内部で失敗→修復が発生していた」ケースを検出できるため、CA/DB 証明書更新のような低レイヤー更新の確認に有効です。
■ 信頼性モニターで確認すべきポイント（上級者向け）
Windows Update は Servicing Stack による自動修復が強化されており、表面上は「成功」と表示されていても、内部では一度失敗してから修復されているケースがあります。特に CA/DB 証明書更新のような低レイヤーの処理では、この“裏側の失敗”が後の更新トラブルの予兆になることがあります。次の項目を信頼性モニターで確認しておくと、異常の早期発見につながります。
1. Windows Update の「失敗 → 成功」パターン
同じ KB が「失敗」と「成功」で連続して記録されている場合、内部で修復処理（CBS / DISM）が走った可能性があります。頻発する場合は、証明書更新や Secure Boot 関連の処理が安定していない可能性があります。
2. “Windows Modules Installer” のエラー
信頼性モニター上で「Windows Modules Installer（TrustedInstaller.exe）」の停止やエラーが記録されている場合、コンポーネントストア（WinSxS）や証明書ストアの更新処理が正常に完了していない可能性があります。
3. “Servicing Stack” 関連の警告
「Windows Update Servicing Stack」や「CBS（Component-Based Servicing）」の警告が散発的に出ている場合、Secure Boot 関連の更新が適用される際に問題が発生する可能性があります。
4. 再起動直後の「アプリケーションエラー」や「ドライバ読み込み失敗」
証明書更新はブートチェーンに関わるため、再起動直後にドライバ読み込みエラーが増える場合、Secure Boot の検証プロセスに影響が出ている可能性があります。
5. “更新プログラムの構成に失敗しました” が単発で出ていないか
単発の失敗は珍しくありませんが、6 月以降に繰り返し発生する場合、証明書更新が内部で適用されていない可能性があります。
■ 信頼性モニターに表示されないケースについて
Windows Update の自動修復機能（Servicing Stack）が強化された影響で、内部では一度失敗してから修復が行われていても、信頼性モニターには「成功」としか表示されないケースがあります。特に Secure Boot や CA/DB 証明書更新のような低レイヤーの処理は GUI に記録されにくく、裏側の失敗が見えないことがあります。
■ ログを確認すべき状況（上級者向け）
次のような症状がある場合は、CBS.log や DISM.log を確認する価値があります。
・6 月以降の更新が連続で失敗する
・信頼性モニターに Windows Modules Installer のエラーが頻発する
・Secure Boot 有効環境で再起動直後のドライバエラーが増える
・Windows Update が成功と失敗を繰り返す
・0x800f0922 など ESP 容量不足が疑われる
■ どのログを見ればよいか
・C:\Windows\Logs\CBS\CBS.log（コンポーネントストアの整合性）
・C:\Windows\Logs\DISM\dism.log（修復処理の詳細）
・Get-WindowsUpdateLog で生成される WindowsUpdate.log（更新処理全体）
これらのログは、信頼性モニターに現れない内部エラーを把握する際に有効です。
1.【時系列】不具合報告と動向（追跡ログ）
不具合事前お知らせ版情報（5/26現在）
資料：先行情報・インサイダー版の記録
5/27（日本時間）に配信予定と見られるプレビュー KB と同等の内容を含むインサイダー版（Release Preview / Beta / Canary など）の動向を総合すると、現時点で「起動不能級」「大量クラッシュ級」「広範囲で再現性の高い重大障害」といった赤ランプ級の事象は確認されていません。マイクロソフト公式・国内外ニュース・技術系ブログ・コミュニティのいずれを見ても、5 月第 4 週プレビュー相当ビルドで深刻な不具合が広く共有されている状況にはなく、過去に見られたような“事前炎上”も起きていない認識です。
今わかる範囲の俯瞰
・公式情報や技術系ニュースを見ても、プレビュー相当ビルドでの起動不能級・大量クラッシュ級の報告はなし。
・過去の不具合追跡記事で見られた「配信前からインサイダー版で致命的バグが観測されているため要警戒」というパターンではなく、今回は事前段階で大きなノイズが上がっていない。
・そのため、現時点では「インサイダー段階で大炎上レベルの障害は確認されていない」という整理が妥当。
注意しておきたいポイント
・今年に入ってからも「インサイダー段階では静かだったが、一般配信後に特定構成でだけ深刻化した」ケースが複数ある。
・特に BitLocker / デバイス暗号化有効環境、ESP 容量がギリギリのマシン、特定ベンダのセキュリティソフト常駐環境は、今年の“持病ポイント”として引き続き警戒が必要。
・今回もこれらの構成は人柱検証枠に回しておくのが無難。
まとめ
インサイダー版の時点で赤ランプ級の障害は上がっていないが、ESP 容量不足や暗号化まわりなど、今年繰り返し問題化している領域は引き続き注意が必要という状況です。
2026/05/13配信KBによる障害の現状
2026/05/13 配信分について、主要コミュニティ・技術系ニュース・国内外フォーラムの動向を総合すると、今回の更新は「広範囲で深刻な障害が発生している」という状況には至っていません。報告されている事象はどちらかというとピンポイント寄りの環境依存が中心で、1 月・4 月に見られたような起動不能級・大量 BSOD 級の重大トラブルとは性質が異なります。そのため、当ブログでの障害カウント基準（＝「一般ユーザーが即時ロールバックすべきレベル」）に照らすと、Windows 11 / Windows 10 ともに重大障害 0 件と整理できます。
重大障害
Windows11
全般的/広範な重大障害なし。
Windows10
全般的/広範な重大障害なし。
補足：報告されている主な事象（重大障害には該当しないもの）
Windows 11（KB5089549 / 25H2・24H2）
・インストール失敗（0x800f0922）…多くはESP（EFI System Partition）容量不足が原因と見られ、更新が入らないだけで既存環境を破壊するタイプではない。
・一部環境でネットワーク速度低下・不安定化の報告…ただし「起動不能」「大量クラッシュ」には至らず、影響は限定的。
Windows 10（ESU：KB5087544 ほか）
・レガシーアプリの挙動差、RDP 警告まわりの細かな変化が話題。
・しかし起動不能・大量 BSOD・アプリ壊滅級の広範障害は確認されていない。
まとめ：重大障害カウントは 0 / 0（Win11 / Win10）で妥当。ただし本文中に「※Windows 11 では KB5089549 のインストール失敗（0x800f0922, ESP 容量不足）および一部環境での速度低下が報告されています」と補足を添えておくと、後日読み返した際の整合性が高まります。
よくある質問（2026/05/26版）
6 月に予定されている CA/DB 証明書の切り替えについて、読者の方から寄せられそうな質問をまとめました。事前情報版としてご活用ください。
Q1. 証明書が期限切れになると本当に起動しなくなるのですか？
A. 起動しなくなることはありません。Secure Boot は「署名の一致」を確認する仕組みであり、有効期限そのものは起動可否に直結しません。メーカー各社も「期限切れ＝起動不能にはならない」と明言しています。
Q2. 自分の PC が証明書更新されたかどうか確認する方法はありますか？
A. 一般ユーザーが完全に確認する方法はありません。UEFI の Key Management 画面で確認できる機種もありますが、メーカー実装差が大きく、PowerShell での確認も“目安”に留まります。最も確実なのは「Windows Update が正常に通っているか」を見ることです。
Q3. 6 月の更新で何か操作が必要ですか？
A. 特別な操作は不要です。Windows Update を通常通り適用していれば、自動的に証明書更新が行われます。
Q4. Secure Boot を無効にしているとどうなりますか？
A. Secure Boot が無効の場合、証明書更新が適用されない可能性があります。特に理由がなければ有効化しておくことを推奨します。
Q5. 0x800f0922 などのエラーが出た場合はどうすればいいですか？
A. ESP 容量不足など別の要因が関係している可能性があります。更新が繰り返し失敗する場合は、エラー内容に応じた対処が必要です。
参考記事：
【システム領域不足】WinUpやOSアップグレードの失敗を解消する【2025/09/15】
【MiniTool Partition Wizard】「システムで予約済みのパーティションを更新できませんでした」を一発解決！【2025/09/22】
Q6. 信頼性モニターは確認したほうがいいですか？
A. 一般ユーザーは不要です。ただし、上級者や管理者は「失敗→成功」パターンや Modules Installer のエラーがないか確認すると、内部の異常を早期に察知できます。なお、Windows Update の方式変更については次の記事も参考になります。
コメント