2026年6月26日に「セキュアブート証明書（Microsoft UEFI CA 2011 など）」の有効期限が到来します。期限切れそのものは直ちにPCを起動不能にする“時限爆弾”ではありませんが、準備不足だと起動エラー・BitLockerの回復要求・マルチブート環境の不整合といったトラブルに発展します。本稿では、Windows Updateの配信方針からBIOS/UEFI更新、自作PCの具体的手順、企業での運用まで、実務目線での安全な対応を整理します。
なぜ「2026年6月26日」が話題になるのか（背景と前提）
Secure Boot は、UEFI ファームウェアに格納された信頼ストア（PK/KEK/db/dbx）を用い、OS ブートローダーやドライバーの署名を検証する仕組みです。ここで信頼の根となる「Microsoft UEFI CA 2011（通称：サードパーティ CA）」などの証明書に有効期限が設定されており、その代表的な期限が 2026年6月26日 です。これ以降、署名検証に証明書の期限を厳密に見る実装や、古い証明書チェーンしか持たない環境では、起動時の検証プロセスに影響が出る可能性があります。
ただし実装によっては、起動前に「正しい現在時刻」を厳密に扱えないため、有効期限の評価を緩和する設計もあります。したがって、すべてのPCが期限当日に動かなくなるわけではありません。とはいえ、証明書・dbx（禁止リスト）・ブートローダーの更新を最新化しておくことが、確実で安全な備えです。
結論（要点の先出し）
- Microsoft は 2025〜2026 年にかけて月例更新（Patch Tuesday）で、期限切れ影響を最小化するための更新を段階的に配信します。Windows Update を有効にしていれば、原則として追加操作は不要です。
- Windows Update はPCのBIOS/UEFIそのものを書き換えるものではありません（※ただしOEMが提供する「デバイス ファームウェア（UEFI カプセル）」をWindows Update経由で受け取る場合はあります）。OEM製PCはメーカー推奨のBIOS/UEFI更新を確認・適用、自作PCはマザーボードベンダーが公開する最新版BIOSを確認・必要に応じて適用しましょう。
- マルチブート（Windows + Linux 等）やカスタムブートローダー環境は影響を受けやすいため、OS側ブートローダー更新・shim更新（Linux系）・鍵/証明書の移行を早めに実施して検証するのが安全です。
ユーザー別の対応方針（個人／自作PC／企業）
個人ユーザー（メーカー製PC）
- Windows Update を通常通り適用（自動更新をON）。
- メーカー（OEM）が出している BIOS/UEFI 更新の有無を確認。推奨版が出ていれば適用。
- BitLocker 利用時は更新前に回復キーを確保。更新後の初回起動で回復キーが要求される場合があります。
- 更新後に msinfo32 で「セキュア ブートの状態: 有効」を確認。
自作PC・ショップブランドPC
- マザーボードベンダーの公式ページで、対象型番の最新BIOS/UEFIとリリースノートを確認（Secure Boot/TPM/Intel ME/AMD PSP に関する更新があれば特に適用推奨）。
- BIOS 更新は UEFI内蔵ユーティリティ（EZ Flash, M-Flash など）や UEFIカプセルで実施。電源はAC直結、OCは一時解除、USBメモリはFAT32で。
- Windows Update をすべて適用。再起動後、msinfo32やPowerShellで状態を確認。
- 不安があれば、組み立て店舗やサポート業者に依頼。
企業（数十〜数千台規模）
- WSUS / Windows Update for Business / Intune で配布リング（先行・パイロット・本番）を設定し、段階展開。
- BIOS/UEFI更新はベンダーツール（Lenovo Vantage, Dell Command, HP Image Assistant 等）や UEFI Capsule 更新をパイロット適用→検証→本番。
- 監視：Secure Boot 有効/無効、UEFI/Legacy、TPM2.0状態、OSビルド、ブートローダーバージョン、dbx更新適用を収集し可視化。
- BitLocker 回復キーの保全（Entra ID / AD DS / MBAM / Key Escrow）を事前確認。更新前の周知・SOPを整備。
Windows Update と BIOS/UEFI 更新の関係（正しく理解する）
よくある誤解として「Windows Update がBIOSを勝手に書き換える」があります。実際には、Windows Update は OS コンポーネントやブートローダー、dbx などのUEFI変数の更新を配布します。一方、BIOS/UEFI 本体の更新は、OEMが提供したファームウェアパッケージ（UEFIカプセル）を Windows Update 経由で配る場合がありますが、これはOEMが配布を委任しているだけで、Windowsが直接BIOSを書き換えるわけではありません。従って、OS側の更新とファームウェア側の更新は役割が異なると理解してください。
実務向けチェックリスト（期限1年前〜当日まで）
| 時期 | やること | 担当 | 目的 / 成果物 |
|---|---|---|---|
| 〜2025年Q4 | 資産棚卸：機種/型番/BIOSバージョン/OS/TPM/起動方式（UEFI/Legacy） | IT / 情シス | 対象と優先度の可視化 |
| 2026年Q1 | Windows Update リング設計、先行検証（パイロット10〜30台） | IT / 情シス | 配布時の副作用確認 |
| 2026年Q2 | OEM BIOS/UEFIの推奨版を順次適用、BitLocker回復キー点検 | IT / PC管理者 | ブートチェーン健全性の担保 |
| 〜2026/6/26 | 全端末の状態確認（Secure Boot有効・dbx更新済・ブート成功） | IT / 全ユーザー | 本番安定化・問い合わせ削減 |
安全な更新手順（個人・自作PC向け 詳細）
- Windows 設定 → Windows Update → 更新プログラムのチェック → すべて適用 → 再起動。
- OEM/マザーボードのサイトで BIOS/UEFI の最新情報を確認。リリースノートに「Secure Boot/TPM/ME/PSP/マイクロコード」等があれば適用優先度高。
- BIOS更新準備：
- 電源はAC直結（ノートはバッテリ残量50%以上）。可能ならUPS。
- オーバークロック設定を標準へ戻す。XMP/EXPOは一時OFF。
- USBメモリを FAT32 で用意、ファイルはベンダー手順通りに配置。
- BitLocker 回復キーの控え（Microsoftアカウント/組織ポータル/紙）。
- UEFIセットアップに入り、内蔵ユーティリティ（EZ Flash/M-Flash/Q-Flash など）で更新。メッセージに従い再起動。
- 起動後に msinfo32 を開き、「セキュア ブートの状態: 有効」「BIOS モード: UEFI」を確認。
コマンドで素早く健全性をチェック（PowerShell）
管理者権限の PowerShell で実行し、Secure Boot・TPM・UEFI/Legacy・BIOS などの要点を一覧できます。
# 管理者 PowerShell
$sb = (Get-CimInstance -Namespace root\wmi -ClassName MS_SecureBoot).SecureBootEnabled
$fwType = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control").PEFirmwareType
$uefi = if($fwType -eq 2){"UEFI"} else {"Legacy/BIOS"}
$tpminfo = Get-CimInstance -Namespace root\cimv2\Security\MicrosoftTpm -ClassName Win32_Tpm -ErrorAction SilentlyContinue
$tpmenabled = if($tpminfo){ $tpminfo.IsEnabled_InitialValue } else { $false }
$bios = (Get-CimInstance -ClassName Win32_BIOS).SMBIOSBIOSVersion
$os = (Get-CimInstance -ClassName Win32_OperatingSystem).Caption
[PSCustomObject]@{
OS = $os
FirmwareMode = $uefi
SecureBootEnabled = $sb
TPM_Enabled = $tpmenabled
BIOS = $bios
} | Format-List
db/dbx/KEK の内容そのものはバイナリ（EFI_SIGNATURE_LIST）で保持されるため、人が直接読むのは難しいですが、Get-SecureBootUEFI -Name dbx などで更新の痕跡（サイズ/タイムスタンプ）を把握できます。
BIOS/UEFI 更新が「必要になる」典型パターン
- 古いマザーボードで、Secure Boot 実装や鍵ストア更新（db/dbx）が最新の仕様・互換性に追随していない。
- OEMが、起動時の検証を強化（古い証明書チェーンや脆弱なブートローダーを拒否）し、その反映にファームウェア更新が必要。
- Intel ME / AMD PSP / マイクロコードのセキュリティ修正が同梱され、総合的な安定性・安全性が上がる。
逆に、最新のWindows Update適用・dbx更新のみで十分な環境も多く、すべてのPCにBIOS更新が必須というわけではありません。ただし、メーカーが推奨する場合は従うのが安全です。
マルチブート（Windows + Linux 等）の注意点
- Linux 側の shim / GRUB / カーネルは、Secure Boot 証明書・鍵の移行方針に従った最新ビルドへ更新すること。
- 順番は「各OSのブートローダー更新」→「dbx更新・BIOS更新」の順が安全（先に拒否リストを厳格化すると、古いブートローダーが弾かれることがある）。
- 起動テストは実機で行い、Fast Boot を OFF にして数回コールドブート。BitLocker を使う Windows は回復キーを手元に。
よくある質問（FAQ）
Q. 2026/6/26 を過ぎると、全PCが起動不能になりますか？
A. いいえ。多くの環境では直ちに起動不能にはなりません。ただし、古い証明書チェーンしか持たないブートローダーや、厳密な期限チェックを行う実装に切り替えられた場合、影響が顕在化します。最新のWindows Update適用と、必要に応じたBIOS/UEFI更新で予防的に対処してください。
Q. Microsoft は Windows Update で何をしてくれるの？
A. 例年通り、ブートチェーンの信頼性を高めるための修正、禁止リスト（dbx）の更新、ブートローダー/OSコンポーネントの更新を月例更新の枠内で順次配布します。ユーザーは Windows Update を有効にし、通常運用で問題ありません。
Q. Windows Update だけで十分？ BIOS/UEFI 更新は不要？
A. 環境次第です。Windows Update はBIOSそのものを更新しないため、OEMがBIOS更新を推奨する場合は従うのが安全です。特に Secure Boot/TPM/ME/PSP/マイクロコードに関する改善が含まれる場合は適用を検討してください。
Q. 自作PCでも対応できる？
A. 可能です。マザーボードの最新BIOSを適用し、Windows Updateを最新化すればOKです。作業に不慣れな場合は、購入店のサポートや専門業者へ依頼するのが確実です。
Q. 企業ではどのように段階展開すべき？
A. 先行リング（IT/ヘルプデスク/パワーユーザー）→パイロット（部門代表）→本番の順で、起動成功率・BitLocker復号率・イベントログをモニタリング。障害率のしきい値を超えないことを確認して本番展開します。
トラブル対処（起動できない／回復キー要求など）
| 症状 | 原因候補 | 対処 |
|---|---|---|
| BitLocker回復キーの要求 | ブートチェーンの構成変更（BIOS更新/セキュリティ変数更新） | 回復キーで解除→再起動→安定化。事前にキーを保全しておく。 |
| 「セキュアブート違反」エラー | dbx により古いブートローダーが拒否 | OS側のブートローダー/カーネルを最新へ。必要なら一時的にSecure BootをOFFにして復旧後、再度ON（最終的にはONが推奨）。 |
| 起動が極端に遅い／再起動ループ | BIOS設定の不整合、周辺機器のUEFIドライバー相性 | 初期化（Load Optimized Defaults）→最小構成で検証→周辺機器を順に接続。 |
ベストプラクティス（安全と可用性を両立）
- UPS常用またはノートPCのバッテリ満充電でBIOS更新。停電・ケーブル抜けを避ける。
- 更新前に現在のBIOS設定を写真やスマホで記録。万一の初期化に備える。
- RAID/NVMe/CSM/FastBootの設定は、ブートに直結するため変更の影響が大きい。メモを残す。
- 企業では「更新前バックアップ」「回復メディア」「回復キーの配布手順」を標準化。
- マルチブートは、OS側の更新→dbx更新→BIOS更新の順を基本に、段階的に検証。
技術的補足：どこが更新され、何が維持されるのか
- OS側（Windows Update）で更新されるもの： ブートローダーや初期ブートに関わるコンポーネント、Secure Boot の禁止リスト（dbx）などのUEFI変数。
- ファームウェア側（BIOS/UEFI）で更新されるもの： Secure Boot 実装の改善、鍵ストアの扱い、マイクロコード、Intel ME/AMD PSP、周辺機器互換性など。
- 維持すべき状態： UEFIモード + Secure Boot 有効 + TPM2.0有効（Windows 11 要件）。
導入・展開の実例テンプレート（企業向け）
以下は、数百〜数千台を想定した「現実的な進め方」の例です。
- 資産可視化：機種/BIOS/OS/TPM/UEFI/暗号化の有無をCMDBやスクリプトで収集。
- リスク分類：旧機種・Legacy/CSM・マルチブート・製造/医療機器など停止許容度の低い装置を高リスクに分類。
- パイロット設計：各ベンダー/各モデルで代表台を選定。Windows Update（先行）→ OEM BIOS（先行）→ 再起動検証。
- 広域展開：夜間メンテナンスに合わせリモート再起動を予定。BitLocker回復対応のヘルプデスク要員を増員。
- モニタリング：成功率・障害率・平均復旧時間（MTTR）をダッシュボードで可視化。
「しない方がいいこと」リスト
- 本番機での一括強行アップデート（段階展開なし）。
- 回復キー未保全のままBIOS更新。
- オーバークロック有効のままファームウェア更新。
- 安易なSecure Boot無効化（恒久的OFF）。復旧時の一時OFFはやむを得ないが、最終的にはONに戻す。
まとめ
Microsoft からの更新（Windows Update）を日頃から適用していれば、2026年6月26日のセキュアブート証明書の期限に伴うリスクは低く管理できます。 ただし、OEM/マザーボードの推奨BIOSが案内されている場合は、セキュリティと安定性の両面で適用が推奨です。自作PCでも手順通りに進めれば問題なく対応できます。家庭でも企業でも、「最新化」「段階検証」「回復キーの準備」という三点を押さえ、計画的に臨みましょう。
付録：よく使う確認ポイント早見表
| 確認項目 | 確認場所 | OKの目安 | 備考 |
|---|---|---|---|
| Windows Update | 設定 > Windows Update | 最新の状態 | 再起動の保留がないこと |
| Secure Boot | msinfo32 | 有効 | BIOSモードがUEFIであること |
| TPM 2.0 | tpm.msc / デバイス セキュリティ | 使用可能 | Windows 11 要件 |
| BIOS/UEFI | ベンダーの更新ユーティリティ | 推奨版 | 電源と回復キーに注意 |
| db/dbx 更新 | イベントログ/PowerShell | 最新適用 | 古いブートローダーを拒否 |
付録：Intune / スクリプトでの簡易検出例（企業）
デバイス準拠性の一環として、Secure Boot と UEFI 起動を確認するスクリプトの例です（出力が True であれば合格）。
$sb = (Get-CimInstance -Namespace root\wmi -Class MS_SecureBoot).SecureBootEnabled
$fwType = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control").PEFirmwareType
$uefi = ($fwType -eq 2)
if ($sb -and $uefi) { Write-Output "True" } else { Write-Output "False" }
最後に：実務の優先順位
- まずWindows Updateを完全適用（自動更新ON）。
- BIOS/UEFIの推奨版があるか確認（あれば適用）。
- 回復キーを必ず保全（家庭：Microsoftアカウント、企業：Entra ID/AD/MBAM等）。
- 再起動と検証（msinfo32、PowerShell、実アプリ動作）。
- マルチブートは段階的に（OS側更新→dbx→BIOS）。
コメント