UEFIとは？BIOSとの違いからSecure Boot・GPT・サーバー運用まで実装者向けに解説

UEFI（Unified Extensible Firmware Interface）は、パソコンやサーバーの電源を入れた直後に最初に動き、ハードウェアを初期化してOSを起動させる、マザーボード上のファームウェア規格です。旧来のレガシBIOSに代わる後継仕様として業界で標準化され、いま出荷される機器の大半はこのUEFIで動いています。この記事では、UEFIがOS起動前に担う初期化とブートの流れ、EFIシステムパーティションやブート変数といった構成、そしてレガシBIOSとの違い（MBRとGPT・Secure Boot）を実装者の目線で整理します。あわせて、CSMを無効化してUEFIネイティブへ寄せる判断や、WindowsとLinuxで起動を両立させる勘所、サーバー基盤やクラウド移行でUEFI前提が効く場面まで掘り下げ、寄せるべき条件と据え置く場面の線引きも示すのが本記事の狙いです。BIOS側の詳しい役割はBIOSとは？UEFIとの違いから設定変更・サーバー運用まで実装者向けに解説にまとめており、本記事はUEFIを主語に読み進められる構成にしています。

まとめ：UEFIの役割とBIOSとの違い・実装で押さえる要点

UEFIは、電源投入からOS起動までの数秒間だけ主役を務める、起動専用のファームウェア規格です。CPUやメモリ、ストレージを検査・初期化し、EFIシステムパーティションに置かれた起動ファイルをブートマネージャが読み込み、そこでOSへ制御を引き渡します。設定値やブートエントリはフラッシュROM上のNVRAMに保持され、電池が切れても消えにくい作りになりました。画面表示が「BIOS設定」であっても、中身はこのUEFI仕様である機がほとんどです。

押さえる勘所は3点にまとまります。第一に、UEFIはGPT方式で2TBを超える大容量ディスクから起動でき、Secure Bootで署名のないブートローダーの実行を止めてブート段階の改ざんを検知する点。第二に、古いOSや周辺機器との互換のために互換モード（CSM）を挟んでいる機は、更改のタイミングでUEFIネイティブへ寄せておくと後の拡張で詰まりにくいこと。第三に、サーバー基盤や仮想化基盤、クラウド移行では、GPT前提・Secure Bootの運用ルール・TPM連携をあらかじめ設計に織り込む判断が要る点です。以下で仕組みと違い、そして実装・運用の判断を順に見ていきます。

UEFIとは何かOS起動前のハードウェア初期化とブートの仕組み

UEFIは、OSがまだ読み込まれていない電源投入直後に、コンピューターを動かせる状態まで持っていくファームウェアの規格です。EFI（Extensible Firmware Interface）を土台に業界団体（UEFI Forum）が仕様を統一し、版は2.x系（2020年代時点で2.10前後）まで重ねてきました。まずは、起動時に何が順番に起きるのか、設定やブート情報がどこに保持されるのかという中身から整理します。

電源投入からブートマネージャがOSへ制御を引き渡すまでの流れ

電源ボタンを押すと、CPUは決められたアドレスからファームウェアの命令を読み始め、まずPOST（Power-On Self Test）でCPU・メモリ・ストレージといった主要な部品が正常に応答するかを検査します。ここで致命的な異常があれば、ビープ音やエラー表示で停止を知らせ、OSの起動へは進みません。検査を通過すると、UEFIはブートマネージャと呼ばれる仕組みに移ります。

ブートマネージャは、NVRAMに登録されたブートエントリ（起動候補の一覧）を順に見て、EFIシステムパーティション上の起動ファイルを読み込み、そこへ制御を渡します。レガシBIOSがディスク先頭のMBRを無条件に実行していたのに対し、UEFIは「どのファイルをどの順で起動するか」をエントリとして管理する点が構造上の違いです。起動が遅い、特定のディスクから立ち上がらないといったトラブルは、このエントリと起動ファイルのどこで止まっているかを切り分けると原因に近づけます。

EFIシステムパーティションとNVRAMのブート変数が担う役割

UEFIの起動を支えるのが、EFIシステムパーティション（ESP）と呼ばれる専用領域です。ディスク上にFAT形式で用意され、OSごとのブートローダーやファームウェアのドライバー、更新ツールなどが置かれます。WindowsもLinuxも、このESPに自分の起動ファイルを配置してブートマネージャから呼び出してもらう作りで、複数OSの共存もこの領域の使い分けで成り立ちます。

もう一方の柱がNVRAMに保持されるブート変数です。どのエントリをどの順番で試すか、次回だけ一時的にどのデバイスから起動するかといった情報が、フラッシュROM上の不揮発領域に記録されます。かつてのCMOSがボタン電池頼みだったのに対し、この方式なら電池が切れても起動設定が消えにくくなりました。ブートエントリが壊れてOSが見つからないときは、このブート変数を確認・修復する操作が復旧の入口になります。

UEFIとレガシBIOSの違いをGPTとSecure Bootで比較整理

「BIOS」と一括りに語られがちですが、実装には世代差があります。1980年代から続く旧来のレガシBIOSと、その制約を解消するために標準化されたUEFIです。両者は扱えるディスク容量からブートの安全性まで異なり、どちらの前提に立つかは基盤設計の判断に直結します。BIOS側の細かな設定手順は前掲のBIOS記事に譲り、ここではUEFIが何を変えたかに絞ります。

MBRの容量制約を超えてGPTで大容量ディスクに対応する仕組み

レガシBIOSはディスク先頭512バイトのMBR（Master Boot Record）から起動するため、扱えるのは2TBまで、基本パーティションは4つまでという頭打ちがありました。大容量ディスクの全域を1つの起動ボリュームにできないのは、このMBRの設計上の限界が理由です。

UEFIはGPT（GUID Partition Table）方式でディスクを管理し、2TBをはるかに超える容量から起動でき、パーティション数の実質的な制限も緩みます。GPTはパーティション情報を先頭と末尾に二重で持ち、破損に強い構造です。既存のMBRディスクを後からGPTへ変換する道もありますが、変換とファーム側の起動モード切り替えはセットで進める必要があり、片方だけ変えるとOSが起動しなくなる点に注意が要ります。新規のサーバー調達では、最初からGPT前提で組んでおくのが無難です。

Secure Bootが署名検証でブートの改ざんを検知する仕組み

UEFIの安全面の柱がSecure Bootです。起動する各コンポーネント（ブートローダーやドライバー）にデジタル署名を求め、署名を確認できないコードの実行を止めることで、OSが立ち上がる前の段階での改ざんを検知します。署名を検証する鍵はファームウェアに階層で保持され、プラットフォーム鍵（PK）を頂点に、鍵の更新を許す鍵（KEK）、許可リスト（db）と失効リスト（dbx）で信頼の連鎖を組み立てます。

実務では、Windowsは標準でSecure Bootに対応し、主要なLinuxディストリビューションもshimと呼ばれる署名済みの橋渡しで起動できます。一方、自前でビルドしたカーネルモジュールや古いドライバーを入れると署名検証で弾かれることがあり、その切り分けが要る場面もあります。安全性を底上げする仕組みである以上、むやみに無効化せず、無効化するなら理由と影響を確認したうえで判断するのが筋です。

レガシBIOSとUEFIを起動方式・容量・安全性の観点で比較

両者の違いを、基盤設計で効く観点に絞って並べると次のようになります。既存機の更改やサーバー調達で、どちらの前提に立つかを見極める材料になります。

要点はこうです。2TBを超えるディスクから起動する、あるいはブートの改ざんを検知したいなら、選択肢はUEFI一択になります。レガシBIOSを選ぶ理由は、UEFI非対応の古いOSや周辺機器との互換を維持する場合にほぼ限られるという位置づけです。互換モードでレガシとして動かしている機は、更改の機会にUEFIネイティブへ寄せておくと、後のディスク拡張やセキュリティ要件で行き詰まりにくくなります。

UEFI環境の実装判断とサーバー・クラウド移行での運用の勘所

ここからは概念ではなく、実際に業務システムの基盤を組み・運用するときの判断に踏み込みます。CSMの扱い、WindowsとLinuxの起動両立、そしてサーバー基盤とクラウド移行でのUEFI前提を順に見ていきます。仮想化を前提にした基盤設計は仮想化技術とは？種類・仕組みからサーバー仮想化の採用判断まで実装目線で解説もあわせて参照すると全体像がつかめるはずです。

CSM互換モードを無効化してUEFIネイティブへ寄せる採用条件

CSM（Compatibility Support Module）は、UEFIファームウェア上でレガシBIOS互換の起動を可能にする仕組みです。古いOSやレガシ前提の周辺機器を延命したい局面では役立ちますが、GPTの大容量対応やSecure BootといったUEFI本来の利点は、CSMを挟んでいると得られません。判断の軸はシンプルで、互換維持が要らないなら無効化し、UEFIネイティブで起動する構成へ寄せます。

寄せるべきなのは、2TB超のディスクを起動ボリュームに使う、Secure BootやBitLockerといった署名・暗号化の仕組みを前提にする、あるいはWindows 11のようにUEFIとTPMを要件とするOSを載せる場合です。逆に据え置く判断が要るのは、UEFI非対応の古い業務アプリや専用ボードが起動段階で必要な、限られたケースに絞られます。CSMの有効・無効を切り替えるとブート方式が変わり、既存のOSが起動しなくなることがあるため、切り替えは再インストールや移行の計画とセットで進めます。

WindowsとLinuxでUEFI起動を両立させる実装の勘所

1台の機や仮想マシンでWindowsとLinuxを共存させるなら、両者を同じ起動方式でそろえるのが原則です。片方をUEFI、もう片方をレガシで入れると、ブートマネージャからうまく呼び出せず起動選択でつまずきます。どちらもUEFIで統一し、それぞれのブートローダーをESPに配置して、NVRAMのブートエントリで順序を管理する形に寄せます。

Linux側はGRUBなどのブートローダーをESPへインストールし、Secure Bootを有効にしたままなら署名済みのshim経由で起動させます。Windows側はインストーラーがESPへ自前のブートファイルを置くため、あとから順序をブート変数で整えれば選択メニューから両OSを起動する流れです。仮想環境で組む場合は、ハイパーバイザー側の仮想マシン設定でファームウェアをUEFIに指定しておく前提が要り、その仕組みはハイパーバイザーとは？Type1・Type2の違いから仮想化基盤の選定まで実装者向けに解説で整理しています。

サーバー基盤とクラウド移行でUEFIを前提に据える場面の判断

物理サーバーでは、UEFIに加えてBMC/IPMIによる遠隔管理やファームウェア更新が運用の勘所になります。更新は障害修正やセキュリティ対応の効果が大きい反面、失敗すると起動不能に直結するため、更新すべき理由と手順を確認してから行う判断が要ります。ファーム世代をそろえておくと、同一構成のサーバー群を並べたときの挙動差を抑えられ、運用の手間を減らせる点も利点です。オンプレとクラウドをどう使い分けるかはオンプレミスとクラウドの違いとは？コスト・セキュリティ・拡張性で比較し選び方まで解説も判断材料になります。

クラウドへ移す局面では、既存のレガシBIOSイメージがそのまま動くとは限りません。移行先の仮想マシンがUEFI起動を前提とする場合、GPTへの変換やブートローダーの入れ替えを移行手順に織り込む必要があります。こうしたサーバー基盤の設計・移行・運用を外部の知見も交えて進めるなら、AWSインフラ構築会社｜設計・移行・運用まで対応｜株式会社一創のような、要件整理から本番運用まで一貫して伴走できる支援先を早い段階で巻き込むと、起動方式やパーティション設計で後戻りしにくくなります。UEFIを前提に据えるかどうかは、扱うディスク容量とセキュリティ要件、そして移行先の制約から逆算して決めるのが実装者の判断です。

よくある質問

UEFIとレガシBIOSではどちらが速く起動しますか？

一般には、UEFIのほうが起動は速くなりやすいです。32／64ビットで動作して並列にハードウェアを初期化でき、GPT上の起動ファイルへ直接ジャンプできるため、レガシBIOSの逐次的な検査より無駄が少ない構造になっています。ただし体感差はストレージの種類やファーム実装、常駐する起動オプションにも左右されるため、速度だけで方式を選ぶより、容量やセキュリティ要件と併せて判断するのが実務的です。

今使っている機がUEFIかレガシBIOSか確認する方法は？

Windowsなら「システム情報」を開き、BIOSモードの項目が「UEFI」か「レガシ」かで判別できます。ディスクの管理でシステムディスクがGPTかMBRかを見る方法でも見当がつくはずです。Linuxなら特定のシステムディレクトリの有無でUEFI起動かどうかを確認できます。いずれも再起動は不要で、現状の起動方式をその場で把握できます。

レガシBIOSからUEFIへ後から切り替えられますか？

切り替えられる場合が多いですが、ディスクをMBRからGPTへ変換する作業と、ファーム側の起動モードをUEFIへ変える作業をセットで進める必要があります。片方だけ変えるとOSが起動しなくなる点に注意が必要です。現在のWindowsには無停止に近い変換ツールも用意されていますが、実行前のバックアップと、失敗時に戻せる手順の用意を必ずそろえておきます。

Secure Bootは無効にしても問題ありませんか？

無効化自体は可能ですが、ブート段階の改ざんを検知する仕組みを外すことになるため、原則は有効のまま運用します。無効化が要るのは、署名されていない自前のドライバーや古いブート環境を起動させる限られた場面です。無効化するなら、その理由と影響範囲を確認し、対象作業が終わったら戻す運用にしておくと安全側に倒せます。

UEFIでもCSMを使えば古いOSは動きますか？

CSMを有効にすればレガシBIOS互換で古いOSを起動できます。ただしGPTの大容量対応やSecure BootといったUEFIの利点は使えなくなる点に留意が必要です。延命目的の一時策と割り切り、互換維持が要らなくなった時点でCSMを無効化してUEFIネイティブへ寄せる方針にしておくと、後々の拡張やセキュリティ対応で行き詰まりにくくなります。

関連記事

• BIOSとは？UEFIとの違いから設定変更・サーバー運用まで実装者向けに解説（UEFIの前身であるBIOS側の役割・設定・レガシの詳細）
• ハイパーバイザーとは？Type1・Type2の違いから仮想化基盤の選定まで実装者向けに解説（仮想マシンでUEFI起動を指定する前提）
• 仮想化技術とは？種類・仕組みからサーバー仮想化の採用判断まで実装目線で解説（サーバー仮想化の全体像）
• オンプレミスとクラウドの違いとは？コスト・セキュリティ・拡張性で比較し選び方まで解説（基盤更改・クラウド移行の判断）