この記事の対象読者
- Windows 11の導入でSecure Bootに遭遇した方
- Linuxのデュアルブート環境を構築したい方
- PCの自作や組み立てに興味がある方
- 「UEFIってBIOSの新しいやつでしょ？」で止まっている方
この記事で得られること
- UEFIの設計思想と技術的な優位性の理解
- GPTパーティションとESP（EFI System Partition）の仕組み
- Secure Bootの動作原理と設定方法
- UEFIシェルの基本操作スキル
この記事で扱わないこと
- UEFIファームウェアの開発方法
- 各メーカー固有のUEFI設定画面の操作手順
- レガシーBIOSの詳細（別記事で解説）
1. Windows 11が突きつけた「UEFI必須」の壁
「このPCではWindows 11を実行できません」
2021年、Windows 11の発表とともに多くの人がこのメッセージに遭遇した。その要件リストには「UEFI、Secure Boot対応」の文字。
私も自作PCユーザーとして、この要件には少し驚いた。2015年に組んだPCはスペック的には十分だったが、レガシーBIOSでインストールしていたため対象外。「え、BIOSモードでインストールしただけでアウト？」
調べてみると、MicrosoftがUEFIを必須にした理由がわかってきた。セキュリティだ。Secure Bootがなければ、ブートプロセスへの攻撃を防げない。
この記事では、現代PCの標準となったUEFIについて、その設計思想から実践的な操作方法まで徹底解説する。
ここまでで、なぜUEFIを理解する必要があるかイメージできただろうか。次は、用語を整理していこう。
2. 前提知識の確認
本題に入る前に、この記事で使う用語を整理しておく。
2.1 EFI System Partition（ESP）とは
ESP（EFI System Partition）とは、UEFIファームウェアがブートローダーを探す特別なパーティションのこと。FAT32でフォーマットされ、.efiファイル（実行可能なブートローダー）を格納する。Windowsでは通常100〜500MBのサイズ。
2.2 GPT（GUID Partition Table）とは
GPT（GUID Partition Table）とは、UEFIと共に策定された新しいパーティションテーブル形式。MBRの2TB制限を解消し、最大18EB（エクサバイト）、128パーティションまで対応。ディスク末尾にバックアップテーブルを持つ。
2.3 Secure Bootとは
Secure Bootとは、UEFIの機能の一つで、OSのブートローダーがデジタル署名されているかを検証する仕組み。署名されていないコードの実行を拒否することで、ブートキット（起動時に感染するマルウェア）から保護する。
2.4 NVRAM（Non-Volatile RAM）とは
NVRAM（Non-Volatile RAM）とは、電源を切っても内容が保持されるメモリのこと。UEFIはここにブート設定やSecure Bootの鍵を保存する。レガシーBIOSのCMOS RAMに相当するが、容量と機能が大幅に拡張されている。
これらの用語が押さえられたら、次に進もう。
3. UEFIが生まれた背景
3.1 BIOSの限界
1981年に登場したBIOSは、当時としては優れた設計だった。しかし、40年以上経った今、その限界が明確になっていた。
| 課題 | BIOSの制約 |
|---|---|
| ディスク容量 | 2TBまで（32ビットアドレッシング） |
| パーティション数 | 4つまで（拡張パーティションで回避可能） |
| 起動速度 | 遅い（16ビットモード、逐次初期化） |
| セキュリティ | なし（署名検証なし） |
| 拡張性 | 低い（INT 13hの制約） |
3.2 EFIからUEFIへ（2000年〜2005年）
2000年: Intelが64ビットItaniumプロセッサ向けにEFI（Extensible Firmware Interface）を開発。x86の16ビット制限を完全に排除した新設計。
2005年: IntelがEFIの開発をUEFI Forumに移管。140社以上のベンダーが参加する業界標準として発展。
2012年: Windows 8でUEFI + Secure Bootがデフォルト有効に。この時点でPCメーカーはUEFI対応を事実上義務化。
2024年12月: UEFI 2.11、ACPI 6.5a、PI 1.9が同時リリース。RISC-Vアーキテクチャへの対応強化。
3.3 主要ベンダーとエコシステム
UEFI Forumの主要メンバー:
- Intel: 創設メンバー、Itanium向けEFIの開発元
- AMD: x86-64アーキテクチャの提供
- Microsoft: Windows OSの要件定義、Secure Boot鍵管理
- AMI（American Megatrends）: ファームウェアベンダー、Aptio
- Insyde: ファームウェアベンダー、InsydeH2O
- Phoenix Technologies: ファームウェアベンダー、SecureCore
- Apple: Macの独自実装（T2チップ統合など）
背景がわかったところで、次はUEFIの具体的な仕組みを見ていこう。
4. UEFIの基本概念と動作原理
4.1 UEFIのアーキテクチャ
UEFIは階層化されたアーキテクチャを持つ。
┌─────────────────────────────────────────────────────────────┐
│ オペレーティングシステム │
├─────────────────────────────────────────────────────────────┤
│ OSローダー（.efi） │
│ （Windows Boot Manager, GRUB, etc.） │
├─────────────────────────────────────────────────────────────┤
│ UEFIブートサービス │
│ （メモリ管理、プロトコル、イベント、タイマー） │
├─────────────────────────────────────────────────────────────┤
│ UEFIランタイムサービス │
│ （変数、時刻、仮想メモリ、リセット） │
├─────────────────────────────────────────────────────────────┤
│ プラットフォーム初期化（PI） │
│ （SEC → PEI → DXE → BDS） │
├─────────────────────────────────────────────────────────────┤
│ ハードウェア │
└─────────────────────────────────────────────────────────────┘
4.2 UEFIの起動フェーズ（PI: Platform Initialization）
電源ON
│
▼
┌──────────────────────────────────────────────────────────┐
│ SEC（Security Phase） │
│ ・CPUのリセットベクタから実行開始 │
│ ・キャッシュをRAMとして一時使用（CAR: Cache-As-RAM） │
│ ・TPMの初期化、Root of Trust確立 │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ PEI（Pre-EFI Initialization） │
│ ・メインメモリの初期化（DIMM検出、タイミング設定） │
│ ・チップセットの初期化 │
│ ・HOB（Hand-Off Block）でDXEにデータ引き継ぎ │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ DXE（Driver Execution Environment） │
│ ・各種デバイスドライバのロード │
│ ・UEFIプロトコルの初期化 │
│ ・ブートオプションの列挙 │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ BDS（Boot Device Selection） │
│ ・ブートマネージャの起動 │
│ ・ESPからブートローダー（.efi）の検索・実行 │
└──────────────────────────────────────────────────────────┘
│
▼
OSローダー → OS起動
4.3 GPTの構造
┌────────────────────────────────────────────────────────┐
│ LBA 0: Protective MBR │
│ （レガシーツールとの互換性のため） │
├────────────────────────────────────────────────────────┤
│ LBA 1: Primary GPT Header │
│ ・署名: "EFI PART" │
│ ・ヘッダサイズ、CRC32チェックサム │
│ ・パーティションエントリの位置 │
├────────────────────────────────────────────────────────┤
│ LBA 2-33: Partition Entry Array │
│ ・各パーティションのGUID、開始/終了LBA、属性 │
│ ・最大128エントリ（各128バイト） │
├────────────────────────────────────────────────────────┤
│ │
│ パーティション領域 │
│ │
├────────────────────────────────────────────────────────┤
│ LBA -33〜-2: Backup Partition Entry Array │
├────────────────────────────────────────────────────────┤
│ LBA -1: Backup GPT Header │
│ （プライマリが破損した場合のリカバリ用） │
└────────────────────────────────────────────────────────┘
4.4 Secure Bootの信頼チェーン
┌────────────────────────────────────────────────────────┐
│ PK（Platform Key） │
│ ・ファームウェアの最上位鍵（通常はメーカーが設定） │
│ ・KEKの変更を承認する │
└────────────────────────────────────────────────────────┘
│ 署名
▼
┌────────────────────────────────────────────────────────┐
│ KEK（Key Exchange Key） │
│ ・DB/DBXの変更を承認する鍵 │
│ ・OSベンダー（Microsoft等）の鍵 │
└────────────────────────────────────────────────────────┘
│ 署名
▼
┌────────────────────────────────────────────────────────┐
│ DB（Signature Database）- 許可リスト │
│ ・信頼された署名/ハッシュのリスト │
│ ・Microsoft UEFI CA、Microsoft Windows Production │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ DBX（Forbidden Signature Database）- 拒否リスト │
│ ・拒否された署名/ハッシュのリスト │
│ ・既知の脆弱なブートローダー等 │
└────────────────────────────────────────────────────────┘
│ 検証
▼
┌────────────────────────────────────────────────────────┐
│ OSブートローダー（.efi） │
│ ・bootmgfw.efi（Windows） │
│ ・shimx64.efi → grubx64.efi（Linux） │
└────────────────────────────────────────────────────────┘
注意: 2024年にPKfail脆弱性が発見され、200以上のモデルで出荷時の鍵管理に問題があることが判明した。また、Microsoft UEFI CA 2011証明書が2026年6月に期限切れとなる予定。
基本概念が理解できたところで、これを実際に確認・操作してみよう。
5. 実際に確認・操作してみよう
5.1 UEFI環境の確認（Windows）
# UEFI環境確認スクリプト（Windows PowerShell）
# 管理者権限で実行
Write-Host "=== UEFI環境診断 ===" -ForegroundColor Cyan
# 1. 起動モードの確認
Write-Host "`n[1. 起動モード]" -ForegroundColor Yellow
try {
$uefiMode = Confirm-SecureBootUEFI
Write-Host " 起動モード: UEFI" -ForegroundColor Green
Write-Host " Secure Boot: 有効" -ForegroundColor Green
} catch {
# Secure Bootが確認できない場合
$biosMode = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State" -ErrorAction SilentlyContinue)
if ($null -ne $biosMode) {
Write-Host " 起動モード: UEFI" -ForegroundColor Green
Write-Host " Secure Boot: 無効" -ForegroundColor Yellow
} else {
Write-Host " 起動モード: レガシーBIOS" -ForegroundColor Red
}
}
# 2. ディスクパーティション情報
Write-Host "`n[2. パーティション情報]" -ForegroundColor Yellow
$disks = Get-Disk
foreach ($disk in $disks) {
Write-Host " ディスク $($disk.Number): $($disk.FriendlyName)"
Write-Host " パーティションスタイル: $($disk.PartitionStyle)"
Write-Host " サイズ: $([math]::Round($disk.Size / 1GB, 2)) GB"
}
# 3. EFI System Partition（ESP）の確認
Write-Host "`n[3. EFI System Partition]" -ForegroundColor Yellow
$esp = Get-Partition | Where-Object { $_.Type -eq "System" }
if ($esp) {
Write-Host " ESP検出: ディスク $($esp.DiskNumber), パーティション $($esp.PartitionNumber)"
Write-Host " サイズ: $([math]::Round($esp.Size / 1MB, 2)) MB"
} else {
Write-Host " ESP: 見つかりません" -ForegroundColor Red
}
# 4. UEFIブート変数
Write-Host "`n[4. UEFIブート情報]" -ForegroundColor Yellow
$bootConfig = bcdedit /enum firmware 2>$null
if ($bootConfig) {
Write-Host " UEFIブートエントリが存在します"
} else {
Write-Host " UEFIブートエントリを取得できません（権限不足の可能性）" -ForegroundColor Yellow
}
# 5. TPM情報
Write-Host "`n[5. TPM（Trusted Platform Module）]" -ForegroundColor Yellow
$tpm = Get-Tpm
if ($tpm.TpmPresent) {
Write-Host " TPM: 搭載" -ForegroundColor Green
Write-Host " 有効: $($tpm.TpmEnabled)"
Write-Host " 準備完了: $($tpm.TpmReady)"
} else {
Write-Host " TPM: 非搭載または無効" -ForegroundColor Yellow
}
5.2 UEFI環境の確認（Linux）
#!/bin/bash
# UEFI環境確認スクリプト（Linux用）
echo "=== UEFI環境診断 ==="
# 1. 起動モードの確認
echo -e "\n[1. 起動モード]"
if [ -d /sys/firmware/efi ]; then
echo " 起動モード: UEFI"
# EFI変数へのアクセス確認
if [ -d /sys/firmware/efi/efivars ]; then
efi_var_count=$(ls /sys/firmware/efi/efivars | wc -l)
echo " EFI変数数: $efi_var_count"
fi
# ファームウェアビット数
if [ -f /sys/firmware/efi/fw_platform_size ]; then
fw_bits=$(cat /sys/firmware/efi/fw_platform_size)
echo " ファームウェア: ${fw_bits}ビット"
fi
else
echo " 起動モード: レガシーBIOS"
fi
# 2. Secure Boot状態
echo -e "\n[2. Secure Boot]"
if [ -f /sys/firmware/efi/efivars/SecureBoot-* ]; then
sb_value=$(od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-* 2>/dev/null | tail -1 | awk '{print $NF}')
if [ "$sb_value" == "1" ]; then
echo " Secure Boot: 有効"
else
echo " Secure Boot: 無効"
fi
else
echo " Secure Boot: 確認不可"
fi
# 3. EFI System Partition
echo -e "\n[3. EFI System Partition]"
esp=$(lsblk -o NAME,PARTTYPE,SIZE,MOUNTPOINT | grep -i "c12a7328-f81f-11d2-ba4b-00a0c93ec93b")
if [ -n "$esp" ]; then
echo " ESP検出:"
echo "$esp" | while read line; do
echo " $line"
done
else
echo " ESP: 見つかりません"
fi
# ESPの内容確認
if mountpoint -q /boot/efi 2>/dev/null; then
echo -e "\n ESP内容 (/boot/efi/EFI/):"
ls -la /boot/efi/EFI/ 2>/dev/null | head -10
fi
# 4. ブートエントリ
echo -e "\n[4. UEFIブートエントリ]"
if command -v efibootmgr &> /dev/null; then
echo " 現在のブート順序:"
efibootmgr 2>/dev/null | head -15
else
echo " efibootmgrがインストールされていません"
echo " インストール: sudo apt install efibootmgr"
fi
# 5. GPTパーティション情報
echo -e "\n[5. パーティションテーブル]"
for disk in /dev/sd? /dev/nvme?n?; do
if [ -b "$disk" ]; then
pt_type=$(sudo fdisk -l "$disk" 2>/dev/null | grep "Disklabel type" | awk '{print $3}')
if [ -n "$pt_type" ]; then
echo " $disk: $pt_type"
fi
fi
done 2>/dev/null
5.3 UEFIシェルの基本操作
UEFIシェルは、OSを起動する前に使えるコマンドラインインターフェース。
Shell> help # コマンド一覧
Shell> map # ファイルシステム一覧
Shell> fs0: # ESPに移動（通常fs0:）
FS0:\> ls # ファイル一覧
FS0:\> cd EFI\ubuntu # ディレクトリ移動
FS0:\> shimx64.efi # ブートローダー実行
Shell> bcfg boot dump # ブートエントリ一覧
Shell> bcfg boot add 0 fs0:\EFI\ubuntu\shimx64.efi "Ubuntu"
# ブートエントリ追加
Shell> memmap # メモリマップ表示
Shell> pci # PCIデバイス一覧
Shell> dmpstore # NVRAM変数の表示
Shell> reset # システム再起動
5.4 設定ファイルテンプレート
GRUB設定（UEFI環境・標準）: /etc/default/grub
# /etc/default/grub - UEFI環境用標準設定
# タイムアウト設定
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu
# デフォルトエントリ
GRUB_DEFAULT=0
# カーネルパラメータ
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
# UEFI固有設定
# GOP（Graphics Output Protocol）を使用
GRUB_GFXMODE=1920x1080
GRUB_GFXPAYLOAD_LINUX=keep
# ターミナル設定（GUIメニュー）
GRUB_TERMINAL_OUTPUT=gfxterm
# Windows検出（デュアルブート用）
GRUB_DISABLE_OS_PROBER=false
GRUB設定（Secure Boot有効環境）: /etc/default/grub
# /etc/default/grub - Secure Boot有効環境用設定
# タイムアウト設定
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu
# デフォルトエントリ
GRUB_DEFAULT=0
# カーネルパラメータ
# module.sig_enforce: カーネルモジュールの署名検証を強制
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
# UEFI + Secure Boot固有設定
GRUB_GFXMODE=1920x1080
GRUB_GFXPAYLOAD_LINUX=keep
GRUB_TERMINAL_OUTPUT=gfxterm
# 重要: Secure Boot環境では以下に注意
# ・サードパーティドライバ（NVIDIA等）はMOK登録が必要
# ・unsigned カーネルモジュールはロードできない
# Windows検出
GRUB_DISABLE_OS_PROBER=false
# リカバリモードを有効（トラブルシューティング用）
GRUB_DISABLE_RECOVERY="false"
GRUB設定（高解像度ディスプレイ環境）: /etc/default/grub
# /etc/default/grub - 4K/HiDPI環境用設定
# タイムアウト設定
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu
# デフォルトエントリ
GRUB_DEFAULT=0
# カーネルパラメータ
# video=: 起動時の解像度指定
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=3840x2160"
GRUB_CMDLINE_LINUX=""
# 4K/HiDPI向け設定
# 注意: 一部のファームウェアでは高解像度非対応
GRUB_GFXMODE=3840x2160,1920x1080,auto
GRUB_GFXPAYLOAD_LINUX=keep
# フォントサイズ調整（HiDPI用）
# 大きいフォントを使用する場合は別途フォント生成が必要
# grub-mkfont -s 32 -o /boot/grub/fonts/DejaVuSansMono32.pf2 \
# /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
# GRUB_FONT=/boot/grub/fonts/DejaVuSansMono32.pf2
GRUB_TERMINAL_OUTPUT=gfxterm
GRUB_DISABLE_OS_PROBER=false
設定変更後のコマンド:
# UEFI環境でのGRUB再インストール
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
# Secure Boot環境の場合（shimを使用）
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --no-uefi-secure-boot
# 設定の更新
sudo update-grub
# インストール確認
efibootmgr -v
5.5 よくあるエラーと対処法
| 症状 | 原因 | 対処法 |
|---|---|---|
| "Secure Boot violation" | 署名されていないブートローダー | Secure Bootを一時無効化、またはMOKに署名を登録 |
| "No bootable device" | ESPが見つからない/破損 | UEFIシェルでESPを確認、ブートエントリを再作成 |
| "Windows cannot be installed to this disk (GPT)" | UEFIモードで起動していない | BIOS設定でUEFIブート有効化、CSM無効化 |
| Linuxインストール後、Windowsが起動しない | ブート順序の変更 |
efibootmgrでブート順序を修正 |
| "Verifying shim SBAT data failed" | SBATポリシー違反 | shimを最新版に更新、またはSBAT設定をリセット |
| デュアルブートでOS選択画面が出ない | GRUBがWindowsを検出していない |
GRUB_DISABLE_OS_PROBER=false設定後、update-grub実行 |
実際の操作方法がわかったところで、次はどのような状況でどう設定すべきかを見ていこう。
6. ユースケース別ガイド
6.1 Windows 11新規インストール
想定読者: 自作PCユーザー、Windows 11へのアップグレードを検討中の方
推奨構成: UEFI + GPT + Secure Boot有効 + TPM 2.0
サンプルコード（インストール前チェック）:
# Windows 11インストール要件チェックスクリプト
# 管理者権限で実行
Write-Host "=== Windows 11 インストール要件チェック ===" -ForegroundColor Cyan
$passed = $true
# 1. CPU確認
Write-Host "`n[1. CPU]" -ForegroundColor Yellow
$cpu = Get-WmiObject -Class Win32_Processor
$cpuName = $cpu.Name
$cpuCores = $cpu.NumberOfCores
$cpuSpeed = [math]::Round($cpu.MaxClockSpeed / 1000, 2)
Write-Host " 名前: $cpuName"
Write-Host " コア数: $cpuCores（要件: 2以上）"
Write-Host " 速度: ${cpuSpeed}GHz（要件: 1GHz以上）"
if ($cpuCores -ge 2 -and $cpuSpeed -ge 1) {
Write-Host " [PASS]" -ForegroundColor Green
} else {
Write-Host " [FAIL]" -ForegroundColor Red
$passed = $false
}
# 2. メモリ確認
Write-Host "`n[2. メモリ]" -ForegroundColor Yellow
$ram = [math]::Round((Get-WmiObject -Class Win32_ComputerSystem).TotalPhysicalMemory / 1GB, 2)
Write-Host " 容量: ${ram}GB（要件: 4GB以上）"
if ($ram -ge 4) {
Write-Host " [PASS]" -ForegroundColor Green
} else {
Write-Host " [FAIL]" -ForegroundColor Red
$passed = $false
}
# 3. UEFI + Secure Boot確認
Write-Host "`n[3. UEFI + Secure Boot]" -ForegroundColor Yellow
try {
$secureBootState = Confirm-SecureBootUEFI
Write-Host " UEFI: 有効"
Write-Host " Secure Boot: 有効"
Write-Host " [PASS]" -ForegroundColor Green
} catch {
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State"
$sbState = Get-ItemProperty -Path $regPath -ErrorAction SilentlyContinue
if ($null -ne $sbState) {
Write-Host " UEFI: 有効"
Write-Host " Secure Boot: 無効（有効化が必要）"
Write-Host " [WARN] Secure Bootを有効にしてください" -ForegroundColor Yellow
} else {
Write-Host " UEFI: 無効（レガシーBIOS）"
Write-Host " [FAIL] UEFIモードでの起動が必要です" -ForegroundColor Red
$passed = $false
}
}
# 4. TPM確認
Write-Host "`n[4. TPM]" -ForegroundColor Yellow
$tpm = Get-Tpm
if ($tpm.TpmPresent -and $tpm.TpmReady) {
# TPMバージョン確認
$tpmVersion = (Get-WmiObject -Namespace "root\cimv2\security\microsofttpm" -Class Win32_Tpm).SpecVersion
Write-Host " TPM: 搭載・有効"
Write-Host " バージョン: $tpmVersion（要件: 2.0）"
if ($tpmVersion -like "2.0*") {
Write-Host " [PASS]" -ForegroundColor Green
} else {
Write-Host " [WARN] TPM 2.0が推奨されます" -ForegroundColor Yellow
}
} else {
Write-Host " TPM: 非搭載または無効"
Write-Host " [FAIL] TPM 2.0が必要です" -ForegroundColor Red
$passed = $false
}
# 5. ディスクパーティション確認
Write-Host "`n[5. ディスクパーティション]" -ForegroundColor Yellow
$systemDisk = Get-Disk | Where-Object { $_.IsBoot -eq $true }
Write-Host " パーティションスタイル: $($systemDisk.PartitionStyle)（要件: GPT）"
if ($systemDisk.PartitionStyle -eq "GPT") {
Write-Host " [PASS]" -ForegroundColor Green
} else {
Write-Host " [FAIL] GPTへの変換が必要です" -ForegroundColor Red
$passed = $false
}
# 結果サマリー
Write-Host "`n=== 結果 ===" -ForegroundColor Cyan
if ($passed) {
Write-Host "Windows 11のインストール要件を満たしています" -ForegroundColor Green
} else {
Write-Host "一部の要件を満たしていません。上記の[FAIL]項目を確認してください" -ForegroundColor Red
}
6.2 Linux + Windowsデュアルブート
想定読者: 開発者、Linux初心者
推奨構成: UEFI + GPT、両OSを同じESPに
サンプルコード（デュアルブート設定確認・修復）:
#!/bin/bash
# デュアルブート環境の診断・修復スクリプト
echo "=== デュアルブート環境診断 ==="
# root権限チェック
if [ "$EUID" -ne 0 ]; then
echo "このスクリプトはroot権限で実行してください"
echo "sudo $0"
exit 1
fi
# 1. ESP確認
echo -e "\n[1. EFI System Partition確認]"
ESP_MOUNT="/boot/efi"
if mountpoint -q "$ESP_MOUNT"; then
echo " ESP: $ESP_MOUNT にマウント済み"
ESP_DEVICE=$(findmnt -n -o SOURCE "$ESP_MOUNT")
echo " デバイス: $ESP_DEVICE"
echo -e "\n ESP内のブートローダー:"
ls -la "$ESP_MOUNT/EFI/" 2>/dev/null
else
echo " [ERROR] ESPがマウントされていません"
echo " 修復コマンド: mount /dev/sda1 /boot/efi # デバイス名は環境に合わせて変更"
fi
# 2. ブートエントリ確認
echo -e "\n[2. UEFIブートエントリ]"
if command -v efibootmgr &> /dev/null; then
efibootmgr -v
echo -e "\n Windows検出:"
if efibootmgr | grep -qi "windows"; then
echo " [OK] Windowsブートエントリあり"
else
echo " [WARN] Windowsブートエントリなし"
fi
echo -e "\n Linux検出:"
if efibootmgr | grep -qi "ubuntu\|grub\|linux"; then
echo " [OK] Linuxブートエントリあり"
else
echo " [WARN] Linuxブートエントリなし"
fi
else
echo " efibootmgrがインストールされていません"
apt install -y efibootmgr
fi
# 3. os-proberによるOS検出
echo -e "\n[3. os-prober によるOS検出]"
if command -v os-prober &> /dev/null; then
detected=$(os-prober 2>/dev/null)
if [ -n "$detected" ]; then
echo " 検出されたOS:"
echo "$detected" | while read line; do
echo " $line"
done
else
echo " [WARN] 他のOSが検出されませんでした"
echo " 原因: Windows高速スタートアップが有効の可能性"
echo " 対処: Windowsで「高速スタートアップを有効にする」を無効化"
fi
else
echo " os-proberがインストールされていません"
apt install -y os-prober
fi
# 4. GRUB設定確認
echo -e "\n[4. GRUB設定確認]"
GRUB_CONFIG="/etc/default/grub"
if [ -f "$GRUB_CONFIG" ]; then
os_prober_setting=$(grep "GRUB_DISABLE_OS_PROBER" "$GRUB_CONFIG")
echo " 現在の設定: $os_prober_setting"
if echo "$os_prober_setting" | grep -q "true"; then
echo " [WARN] os-proberが無効になっています"
echo " 修復: GRUB_DISABLE_OS_PROBER=false に変更"
else
echo " [OK] os-proberが有効です"
fi
fi
# 5. 修復オプション
echo -e "\n=== 修復コマンド ==="
echo "# GRUBの再インストール（UEFI）"
echo "grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB"
echo ""
echo "# GRUB設定の更新"
echo "update-grub"
echo ""
echo "# Windowsブートエントリの手動追加（必要な場合）"
echo "efibootmgr -c -d /dev/sda -p 1 -L 'Windows Boot Manager' -l '\\EFI\\Microsoft\\Boot\\bootmgfw.efi'"
6.3 Secure Boot + サードパーティドライバ
想定読者: NVIDIAドライバ利用者、カスタムカーネルモジュール利用者
推奨構成: UEFI + Secure Boot有効 + MOK（Machine Owner Key）登録
サンプルコード（MOK登録手順）:
#!/bin/bash
# MOK（Machine Owner Key）登録スクリプト
# NVIDIAドライバ等のサードパーティモジュール用
echo "=== MOK（Machine Owner Key）登録ガイド ==="
# Secure Boot状態確認
echo -e "\n[1. Secure Boot状態確認]"
if [ -d /sys/firmware/efi ]; then
sb_file=$(ls /sys/firmware/efi/efivars/SecureBoot-* 2>/dev/null | head -1)
if [ -n "$sb_file" ]; then
sb_value=$(od -An -t u1 "$sb_file" 2>/dev/null | tail -1 | awk '{print $NF}')
if [ "$sb_value" == "1" ]; then
echo " Secure Boot: 有効"
echo " → MOK登録が必要です"
else
echo " Secure Boot: 無効"
echo " → MOK登録は不要です（ただし有効化を推奨）"
fi
fi
else
echo " レガシーBIOSモードです（Secure Boot非対応）"
exit 0
fi
# MOKキーの存在確認
echo -e "\n[2. MOKキー確認]"
MOK_PRIV="/var/lib/shim-signed/mok/MOK.priv"
MOK_DER="/var/lib/shim-signed/mok/MOK.der"
if [ -f "$MOK_PRIV" ] && [ -f "$MOK_DER" ]; then
echo " MOKキー: 既に存在します"
echo " 秘密鍵: $MOK_PRIV"
echo " 証明書: $MOK_DER"
else
echo " MOKキー: 存在しません"
echo -e "\n キー生成コマンド:"
echo " sudo mkdir -p /var/lib/shim-signed/mok"
echo " sudo openssl req -new -x509 -newkey rsa:2048 \\"
echo " -keyout $MOK_PRIV \\"
echo " -out $MOK_DER \\"
echo " -nodes -days 36500 -subj '/CN=My MOK/'"
fi
# MOK登録状態確認
echo -e "\n[3. MOK登録状態]"
if command -v mokutil &> /dev/null; then
echo " 登録済みMOK一覧:"
mokutil --list-enrolled 2>/dev/null | head -20
else
echo " mokutilがインストールされていません"
echo " インストール: sudo apt install mokutil"
fi
# 登録手順の表示
echo -e "\n=== MOK登録手順 ==="
echo "1. MOKを登録キューに追加:"
echo " sudo mokutil --import $MOK_DER"
echo " （パスワードを設定）"
echo ""
echo "2. システムを再起動"
echo " sudo reboot"
echo ""
echo "3. 起動時にMOK管理画面が表示される"
echo " 'Enroll MOK' → 'Continue' → パスワード入力 → 'Enroll' → 'Reboot'"
echo ""
echo "4. モジュールに署名:"
echo " sudo /usr/src/linux-headers-\$(uname -r)/scripts/sign-file \\"
echo " sha256 $MOK_PRIV $MOK_DER <モジュールファイル.ko>"
echo ""
echo "5. NVIDIAドライバの場合（自動署名）:"
echo " sudo apt install nvidia-driver-xxx"
echo " # dkmsが自動的にMOKで署名する"
ユースケースが把握できたところで、この記事を読んだ後の学習パスを確認しよう。
7. 学習ロードマップ
この記事を読んだ後、次のステップとして以下をおすすめする。
初級者向け（まずはここから）
- BIOSとUEFIってなんだ？ - BIOSとUEFIの違いを俯瞰
- Arch Wiki - UEFI - 実践的なUEFI設定ガイド
- Arch Wiki - Secure Boot - Secure Bootの設定方法
中級者向け（実践に進む）
- UEFI Specification Version 2.11 - 公式仕様書
- Microsoft Learn - UEFI firmware requirements - Windows向け要件
- rEFInd Boot Manager - 高機能ブートマネージャー
上級者向け（さらに深く）
- TianoCore EDK II - UEFIのリファレンス実装
- NSA - Guidance for Managing UEFI Secure Boot (2025) - セキュリティガイダンス
- UEFI Forum - Specifications - ACPI、PIなど関連仕様
8. まとめ
この記事では、現代PCの標準となったUEFIについて以下を解説した。
- UEFIは2000年にIntelが開発したEFIを起源とし、UEFI Forumで標準化された
- GPTパーティションとESPを使用し、大容量ディスク・高速起動・セキュリティを実現
- Secure Bootは署名検証によりブートプロセスへの攻撃を防ぐが、完璧ではない
- Windows 11はUEFI + Secure Boot + TPM 2.0が必須、Linuxも対応が進んでいる
私の所感
正直、最初は「BIOSからUEFIへの移行」を単なる技術的アップグレードだと思っていた。でも調べてみると、これはセキュリティの観点から見た必然的な進化だとわかった。
ブートプロセスへの攻撃（ブートキット）は、OSが起動する前に実行されるため、OS上のセキュリティソフトでは検出できない。Secure Bootはこの「信頼の起点」を確立するための仕組みだ。
ただし、PKfail脆弱性や証明書の期限切れ問題が示すように、仕組みがあっても運用が伴わなければ意味がない。UEFIとSecure Bootを理解した上で、自分の環境が適切に設定されているか確認することが重要だ。
参考文献
- UEFI Forum - Specifications - UEFI 2.11, ACPI 6.5a, PI 1.9 公式仕様
- Wikipedia - UEFI - UEFIの概要と最新動向
- Microsoft Learn - UEFI firmware requirements - Windows向けUEFI要件
- Arch Wiki - UEFI - 実践的なUEFI設定ガイド
- Arch Wiki - Secure Boot - Secure Bootの設定方法
- NSA - Guidance for Managing UEFI Secure Boot (2025) - セキュリティガイダンス
- TianoCore EDK II - GitHub - UEFIリファレンス実装
関連記事