公開2026.07.11更新2026.09.05 11 人が閲覧（直近 30 日）インフラ・クラウド

BIOSとは？UEFIとの違いから設定変更・サーバー運用まで実装者向けに解説

BIOS（バイオス）は、パソコンやサーバーの電源を入れた直後に最初に動き、ハードウェアを初期化してOSを起動させる、マザーボード上のファームウェアです。この記事では、電源投入からOS起動までにBIOSが担う処理の流れ、設定がどこに保存されるのかという仕組み、そして旧来のレガシBIOSと後継のUEFIの違い（MBR/GPTやSecure Boot）を整理します。あわせて、いま自分が触っている機がどちらで起動しているかを判定するコマンド、仮想化支援機能の有効化やブート順の変更といったBIOS設定の勘所、サーバー運用でのファームウェア更新やBMC/IPMIとの関係まで、実際に業務システムの基盤を設計・運用する担当者の視点で掘り下げ、設定に踏み込むべき条件と触るべきでない場面の判断基準も示します。

まとめ：BIOSの役割とUEFI・サーバー運用で押さえる要点

BIOSは、電源投入から数秒間だけ主役を務める起動専用のソフトウェアです。CPUやメモリ、ストレージといったハードウェアを検査・初期化する処理（POST）を行い、起動可能なディスクを探してブートローダーを読み込み、そこでOSへ制御を引き渡します。設定値は、かつては電池でバックアップするCMOSに、現在のUEFI機ではフラッシュROM上のNVRAMに保持され、ブート順やハードウェアの有効・無効を管理します。

押さえる勘所は3点にまとまります。第一に、いま出荷される機器の大半は厳密には「UEFIファームウェア」で動いており、画面上ではBIOSと呼ばれても中身はUEFI仕様である点。旧来のレガシBIOSはMBR方式で2TB超のディスクから起動できず、UEFIはGPT方式で大容量に対応しSecure Bootでブートの改ざんを検知します。第二に、サーバーや検証機で仮想化基盤を組むなら、BIOS設定でIntel VT-x／AMD-Vといった仮想化支援を有効にする作業が実装の前提になること。第三に、ファームウェアの更新は障害修正やセキュリティ対応の効果が大きい反面、失敗すると起動不能に直結するため、更新すべき理由と手順を確認してから行う判断が要る点です。

手を動かす順序としては、まず自機がUEFI起動かレガシ起動かを判定し、次にBIOS／UEFIの版数を棚卸しして、変更が要る項目だけを1つずつ切り替えます。判定も棚卸しも設定確認もコマンドで済むため、本文ではその実行例をそのまま載せました。以下で仕組みと設定・運用の判断を具体的に見ていきます。

BIOSとは何か電源投入からOS起動までを担うファームウェアの仕組み

BIOSはBasic Input/Output Systemの略で、その名の通りハードウェアへの基本的な入出力を橋渡しする土台にあたります。OSがまだ読み込まれていない電源投入直後、コンピューターを動かせる状態まで持っていくのがBIOSの仕事です。まずは、起動時に何が順番に起きるのかという中身から整理します。

電源投入後にPOSTでハードを検査しブートローダーへ引き渡す起動の流れ

電源ボタンを押すと、CPUはあらかじめ決められたアドレスからファームウェアの命令を読み始めます。最初に走るのがPOST（Power-On Self Test）で、CPU・メモリ・グラフィックス・ストレージといった主要な部品が正常に応答するかを検査する工程です。ここで致命的な異常があれば、ビープ音やエラーコードで停止を知らせ、OSの起動には進みません。

POSTを通過すると、BIOSはあらかじめ設定されたブート順に従って起動可能なデバイスを探します。見つかったディスクの先頭にあるブートローダー（レガシBIOSならMBRの先頭領域、UEFIならEFIシステムパーティション上の起動ファイル）を読み込み、そこへ制御を渡すわけです。以降はブートローダーがOSカーネルを読み込むため、BIOSの役割はこの引き渡しで一区切りとなります。起動が遅い、特定のディスクから立ち上がらないといったトラブルは、この検査とブート順のどこで止まっているかを切り分けると原因に近づけます。

なお、UEFI環境ではブートローダーを挟まずカーネル自体をEFIアプリケーションとして起動する経路もあります。LinuxカーネルはEFI boot stub（kernel.org公式ドキュメント）を備えており、EFIシステムパーティションにカーネルイメージを置けばファームウェアが直接読み込みます。起動経路の切り分けでは、GRUB等のブートローダーで止まっているのか、その手前のファームウェアで止まっているのかを分けて見ると早いです。

設定値を保持するCMOS・NVRAMとファームウェアを書き込むフラッシュROMの役割

BIOSには、書き換えない「プログラム本体」と、利用者が変える「設定値」の2種類のデータがあります。プログラム本体は、マザーボード上のフラッシュROM（SPIフラッシュ）に書き込まれており、ファームウェア更新のときだけ内容を書き換えます。電源を切っても消えない不揮発性の記憶なので、次に電源を入れたときも同じファームウェアが立ち上がる作りです。

一方、ブート順や日時、各デバイスの有効・無効といった設定値は、古い設計ではCMOSと呼ばれる小容量のメモリに保持され、マザーボードのボタン電池（CR2032など）で内容を維持していました。この電池が切れると日時がリセットされ、設定が初期値に戻るのはこのためです。現在のUEFI機では、設定値もフラッシュROM上のNVRAM領域に保存する方式が広く採られ、電池依存は薄まっています。設定を工場出荷時に戻す「CMOSクリア」は、この設定値だけを消してプログラム本体には手を付けない操作にあたります。

NVRAMに置かれるのは設定値だけではありません。UEFIでは起動エントリ（どのディスクのどの起動ファイルを、どの順で試すか）もEFI変数としてNVRAMに記録され、Linuxからはefibootmgr（GitHubリポジトリ）で参照・変更できます。OSを入れ直したのに古いエントリが残って起動順が想定どおりにならない、という詰まり方はここを見ると解けます。

UEFI起動かレガシ起動かをコマンドで判定して版数まで確認する

「BIOS設定」と表示されていても中身がUEFIである機は多く、画面の見た目からは判別できません。判定にはコマンドを使うのが確実です。LinuxではEFI変数が公開されるディレクトリの有無、WindowsではファームウェアタイプのプロパティがそれぞれUEFI起動かどうかを示します。あわせて、ベンダー名・版数・リリース日をdmidecode（公式サイト）で読み出しておくと、後述するファーム更新の要否判断にそのまま使えます。

# Linux: このディレクトリが存在すればUEFIで起動している（無ければレガシ起動）
ls /sys/firmware/efi

# BIOSベンダー・版数・リリース日をSMBIOSから読み出す（root権限が要る）
sudo dmidecode -t bios

# 起動エントリと起動順をNVRAMから一覧する
sudo efibootmgr -v

# Windows PowerShell: BiosFirmwareType が Uefi なら UEFI 起動
Get-ComputerInfo -Property BiosFirmwareType

dmidecodeが表示するBIOS Versionとリリース日は、ベンダーのリリースノートと突き合わせる際の起点になります。サーバーが複数台あるなら、この2コマンドを構成管理ツールで一斉に流し、機種と版数の一覧を作っておくと、脆弱性情報が出たときに対象機を数分で絞り込み可能です。手元の1台だけを見て回る運用では、台数が増えた時点で棚卸しが破綻します。

レガシBIOSとUEFIの違いをMBR・GPTとSecure Bootの観点で比較

「BIOS」と一括りに語られがちですが、実装には世代差があります。1980年代から続く旧来のレガシBIOSと、その制約を解消するために業界で標準化されたUEFIです。両者は起動の考え方から扱えるディスク、セキュリティまで異なり、どちらで動いているかは実務の判断に直結します。

16ビット動作とMBRに縛られたレガシBIOSの制約と起動方式

レガシBIOSは、16ビットのリアルモードで動作し、ディスクの先頭512バイトに置かれたMBR（Master Boot Record）を読み込んで起動します。この方式には設計上の頭打ちがあり、MBRのパーティションテーブルが持てるエントリは4つだけで、5つ以上に分けるには拡張パーティションという二段構えの構造が必要です。この点はMicrosoft Learn「WindowsとGPTのよくあるご質問」にも、MBRディスクは4つのパーティションテーブルエントリのみをサポートすると明記されています。同ページはMBR時代のパーティション分割ルールが十分に規定されておらず、隠しセクターへの独自情報の書き込みが切り分けの難しい不具合を生んできたとも述べています。

加えて、レガシBIOSは起動デバイスを順に試すだけで、読み込むブートローダーが正当かどうかを検証しません。仕組みが単純で互換性は高い反面、ブート領域を書き換えるタイプのマルウェアに対して無防備でした。米国のNISTが2011年4月に公開したSP 800-147「BIOS Protection Guidelines」は、BIOSの不正な改変が「BIOS破損による恒久的なサービス拒否」や「持続的なマルウェアの埋め込み」につながると位置づけており、ブート段階の保護が独立した課題として扱われてきた経緯が読み取れます。古い産業機器や一部の組み込み用途では今もレガシBIOSやその互換モード（CSM）が残りますが、新規の設計で積極的に選ぶ理由は乏しくなっています。

GPTと大容量対応・Secure Bootを備えたUEFIの仕組みと移行の位置づけ

UEFI（Unified Extensible Firmware Interface）は、EFIを土台に業界団体が仕様を統一したファームウェアの規格で、UEFI Forumが公開する仕様は2.11系（2024年12月公開時点）まで版を重ねています。32ビット／64ビットで動作し、GPT（GUID Partition Table）方式でディスクを管理するため、2TBをはるかに超える大容量ストレージから起動可能です。前掲のMicrosoft Learnによれば、GPTの長さは理論上2の64乗論理ブロックまで許容され、Windows Server 2003 SP1以降は最大18エクサバイトのrawパーティションが扱え、パーティション数はWindowsの実装上128個までとされています。MBRの4エントリと比べると、区画設計の自由度は桁違いです。

EFIシステムパーティション（ESP）という専用領域に起動ファイルを置く点も、レガシとの構造的な違いです。同ドキュメントはESPのサイズをおよそ100MBとし、UEFIシステムのブートドライブにはESPとMicrosoft予約パーティション（MSR）、OSを含む基本データパーティションが必要だと記しています。グラフィカルな設定画面やマウス操作、ネットワーク起動（PXE／HTTP Boot）に対応するのもUEFIの範囲です。

安全面の柱がSecure Bootです。起動する各コンポーネントにデジタル署名を求め、署名が確認できないブートローダーやドライバーの実行を止めることで、ブート段階での改ざんを検知します。Microsoft LearnのSecure Boot解説は、これをUEFIファームウェアとOSの間で結ぶ信頼の連鎖として説明しています。この起動段階の署名検証の仕組みを詳しく整理した記事がセキュアブートとは？UEFIが署名でOSの起動を守る仕組みと有効化・確認を実装目線で解説です。署名検証の土台となる鍵や計測値を保護するハードウェアについてはTPM2.0とはもあわせて確認すると、ブート経路の守りが層になっている構図が掴めます。現在市販されるPCやサーバーは、画面表示こそ「BIOS設定」でも、内部はこのUEFIファームウェアで動く機が大半です。レガシからUEFIへの移行は、単なる画面の刷新ではなく、扱えるディスク容量とブートの安全性を底上げする世代交代にあたります。

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

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

観点	レガシBIOS	UEFI
動作モード	16ビット（リアルモード）	32／64ビット
ディスク方式	MBR（テーブルは4エントリ）	GPT（Windows実装で128区画）
起動容量の上限	2TBが実質の頭打ち	最大18EBのrawパーティション
ブートの検証	なし	Secure Bootで署名検証
設定画面	テキスト・キーボード操作	グラフィカル・マウス対応も
ネットワーク起動	PXE中心	PXEに加えHTTP Bootなど

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

MBR2GPTでMBRディスクをGPTへ変換する検証と実行の手順

稼働中のWindows機をレガシからUEFIへ寄せるとき、ディスクを作り直さずにパーティション形式だけを変える道具がMBR2GPT.EXE（Microsoft Learn）です。同ドキュメントによれば、このツールはサポートされているWindowsの System32 ディレクトリに標準で置かれ、ディスク上のデータを変更・削除せずにMBRからGPTへ変換します。既定ではWindows PEからの実行に限られ、稼働中のWindowsから走らせるには /allowFullOS を付けます。

:: 変換できるディスクかを検証だけ行う（ディスクには手を加えない）
mbr2gpt.exe /validate /disk:0

:: 検証を通ったらGPTへ変換する（完了後はGPTモードでのみ起動する）
mbr2gpt.exe /convert /disk:0

:: 稼働中のWindowsから実行する場合はブロック解除を明示する
mbr2gpt.exe /convert /disk:0 /allowFullOS

:: 変換後にパーティション形式を確認する（Gpt列のアスタリスクが目印）
DiskPart.exe

実行前に押さえるべき前提条件も同ドキュメントに列挙されています。対象がMBRであること、MBRパーティションテーブルのプライマリパーティションが最大3つであること、拡張／論理パーティションが無いこと、アクティブなシステムパーティションが存在すること、そしてプライマリGPTとセカンダリGPTを書き込む空き（ディスク先頭に16KB＋2セクター、末尾に16KB＋1セクター）が空いていることです。BitLockerで暗号化されたボリュームは保護を中断していれば変換でき、変換後は保護機能をいったん削除して作り直します。

変換そのものより事故が起きやすいのはその後です。同ドキュメントも変換後にファームウェア側をUEFI起動へ切り替える必要があると明記しており、切り替えを忘れると起動しません。/validate だけを先に流して戻り値を確認し、対象機のバックアップを取ってから /convert に進む二段構えが安全です。戻り値7はディスクのジオメトリやレイアウトが要件を満たさない場合、戻り値6はボリュームが暗号化されている場合を指すため、失敗時はこの番号から原因を辿れます。

サーバー・業務システムでのBIOS/UEFI実装判断と設定運用の勘所

ここからは概念ではなく、実際に業務システムの基盤を組み・運用するときの判断に踏み込みます。仮想化基盤を前提にした設定、サーバー特有のファーム更新、そしてブートセキュリティの扱いを順に見る構成です。物理サーバーそのものの役割や種類を先に押さえたい場合はサーバーとはから辿ると全体像が繋がります。

仮想化支援VT-x・AMD-Vの有効化とブート順・電源管理の設定勘所

サーバーや検証機で仮想マシンを動かす前提なら、最初に確認するのがBIOS設定内の仮想化支援機能です。Intel VT-x（画面上はIntel Virtualization Technology）やAMD-V、ネストした仮想化やI/O直結に使うVT-d／AMD-Viは、既定で無効になっている機があり、無効のままだとハイパーバイザーが起動時にエラーを返す作りです。これらを有効にして初めて、ハイパーバイザーが物理CPUの仮想化支援を使って仮想マシンを効率よく動かせます。仮想化基盤そのものの仕組みは仮想化技術とはで体系的に整理しているので、あわせて確認すると設定の意味が掴めます。

設定画面に入る前に、いまCPU側で仮想化支援が見えているかをOSから確認しておくと、再起動の回数を減らせます。Linux環境なら/proc/cpuinfoのフラグ、Windowsならsysteminfoの出力に判定材料が出ます。

# Intel VT-x なら vmx、AMD-V なら svm がフラグに並ぶ
grep -o -w -E 'vmx|svm' /proc/cpuinfo | sort -u

# KVMのデバイスファイルが見えていれば仮想化支援が使える状態
ls -l /dev/kvm

# ネストした仮想化の可否（Intel機の例。Y なら有効）
cat /sys/module/kvm_intel/parameters/nested

# Windows: Hyper-V の要件をまとめて確認する
systeminfo.exe

ブート順の設定も実務で触る頻度が高い項目です。OSの再インストールや復旧では、起動デバイスの先頭を一時的にUSBや光学ドライブへ変える操作が要ります。サーバーでは、消費電力を抑える省電力設定（C-State）やターボ動作の可否、NUMAの扱いが性能を左右するため、レイテンシを詰めたい基盤では省電力を抑えて応答を優先する調整も選択肢に入る領域です。ディスク側をハードウェアRAIDで束ねる構成なら、RAIDコントローラのモード（RAID／AHCI）をどちらに置くかも起動可否に直結するため、RAIDとはで構成の考え方を確認したうえで設定順序を決めると手戻りが減ります。設定変更後は、意図した項目だけが変わったかを保存前に見直すと、ブート不能のような取り返しのつかない事故を避けられます。

サーバーのファームウェア更新とBMC・IPMIによる遠隔管理での注意点

サーバー機のBIOS／UEFI更新は、デスクトップPCより慎重さが要る作業です。多くのサーバーはBMC（Baseboard Management Controller）を搭載し、iLO（HPE）やiDRAC（Dell）、IPMIといった仕組みで、OSが動いていなくても遠隔から電源操作・コンソール表示・ファーム更新を行えます。データセンターに足を運ばずに更新できる利点がある一方、BMC自体のファームや認証情報の管理を怠ると、そこが侵入経路になり得ます。

新しい世代の機種では、IPMIに代わる管理インターフェースとしてDMTFが策定するRedfish（仕様はDSP0266）が広く実装されています。HTTPSとJSONで構成情報を読み書きできるため、BIOS設定値や版数の棚卸しをスクリプトで回せる点が運用面の違いです。

# BMCのRedfish APIから現在のBIOS設定値をJSONで取得する
curl -k -u admin:PASSWORD https://bmc.example.local/redfish/v1/Systems/1/Bios

# 搭載ファームウェアの一覧と版数を取得する
curl -k -u admin:PASSWORD https://bmc.example.local/redfish/v1/UpdateService/FirmwareInventory

# IPMI経由で電源状態を確認する（旧来の機で使う）
ipmitool -I lanplus -H bmc.example.local -U admin -P PASSWORD power status

更新で押さえるべきは、更新理由の明確化と失敗時の備えです。脆弱性対応や特定ハードの不具合修正など、変更履歴（リリースノート）で自機に効く修正があるかを確かめてから適用します。更新中の電源断は起動不能の主因になるため、冗長電源やUPSの状態を確認し、可能なら二重化されたファーム領域（プライマリ／バックアップ）を持つ機を選ぶと安全です。NISTが2018年5月に公開したSP 800-193「Platform Firmware Resiliency Guidelines」は、プラットフォームファームウェアに対して保護（protection）・検出（detection）・復旧（recovery）の3機構を求めており、更新失敗や改ざんからの復旧経路を持つことを設計要件として扱っています。調達時に「壊れたときにどう戻すか」を仕様として確認する根拠にできます。

多数のサーバーやクラウド基盤を対象に、こうしたファーム管理や更改を含めて設計・運用を外部に相談したい場合は、AWSのインフラ構築のように、オンプレからクラウド移行までを見据えた基盤支援を受ける選択肢もあります。オンプレとクラウドのどちらへ寄せるかは、更新運用の手間と可用性の要件から逆算するのが妥当です。

Secure Bootとブートセキュリティを業務環境でどう扱うかの判断

Secure Bootは、署名のないブートコンポーネントを弾いてブート段階の改ざんを検知する仕組みで、業務端末やサーバーの標準的な防御線として有効です。ただし運用では副作用もあります。署名されていない自作ドライバーや一部のLinuxディストリビューション、古い仮想化ツールが起動を拒否される場合があり、その際は必要な鍵（証明書）を登録するか、対象環境だけSecure Bootの扱いを見直す判断が要ります。

有効か無効かは画面に入らなくても確認できます。判定を先に済ませてから、例外が要る環境かどうかを検討する順序にすると、無駄な再起動を挟まずに済みます。

# Linux: Secure Boot の有効・無効を確認する
mokutil --sb-state

# 登録済みの鍵（MOK）を一覧して例外の有無を見る
mokutil --list-enrolled

# Windows PowerShell: True なら Secure Boot 有効
Confirm-SecureBootUEFI

実務では、まず有効を既定線に置き、業務上どうしても署名の通らないコンポーネントがある環境に限って例外を検討する順序が扱いやすいです。加えて、BIOS設定画面に入るための管理者パスワードを設定し、ブート順やSecure Bootを不用意に変えられないようにしておくと、端末レベルのブート改ざんに対する守りが一段固まります。ゼロにはできませんが、署名検証とパスワード保護を重ねるだけで、狙われやすいブート経路の隙は着実に塞げます。

BIOS設定に踏み込むべき条件とファーム更新を見送るべき場面の判断基準

最後に、独自の視点として、BIOS設定に手を入れるべき条件と、あえて触らず見送るべき場面を言い切っておきます。BIOSは起動の土台であるだけに、変更が裏目に出ると起動不能に直結し、リカバリの手間が跳ね上がる領域です。だからこそ、踏み込む線引きを先に決めておく価値があります。

仮想化・起動デバイス変更でBIOS設定に踏み込むべき具体条件

設定変更が明確に要るのは、次のような条件がそろう場面です。第一に、仮想マシンやコンテナ基盤を新たに構築し、VT-x／AMD-VやVT-dが無効のままハイパーバイザーが起動しないケース。第二に、OSの再インストールや大容量ディスクへの換装で、レガシからUEFIへブートモードを切り替える、あるいはブート順を変える必要があるケース。第三に、リリースノートに自機の脆弱性や既知不具合の修正が明記され、ファーム更新の効果が具体的に見込めるケースです。

こうした場面では、変更前の設定を控えておき、1回の作業で変える項目を絞るのが安全策になります。仮想化支援やブートモードの変更は、有効・無効の切り替え1つで挙動が大きく変わるため、変更点を1〜2項目に限定し、起動確認を挟みながら進めると切り分けが利くはずです。判断の目安として、目的（仮想化を動かす・大容量ディスクから起動する・既知の不具合を消す）が1文で言えるなら、その設定変更は踏み込む価値があります。

安易なファーム更新や設定変更を見送るべき場面の判断の具体基準

逆に、BIOSに触るのを見送るべき場面もはっきりあります。1つは、いま安定して動いている機に対し、「新しい版が出たから」という理由だけでファームを更新するケースです。更新は障害修正と引き換えに起動不能のリスクを負う作業なので、自機に効く修正がリリースノートに無いなら、動いているものは触らないのが妥当な判断になります。もう1つは、意味を理解しないまま省電力やメモリのタイミング（XMP等）を変えるケースで、体感の効果が乏しい一方で不安定化や起動失敗を招きやすい領域です。

判断基準を整理するとこうなります。「この変更で何が良くなるか」を具体的な事象で説明できないなら、その設定変更・更新は見送る。そして、更新が避けられない場合でも、電源の安定とバックアップ経路（二重化ファームやBMC経由の復旧手段）を確認してから着手する。この2つを守るだけで、成果の薄い変更で基盤を不安定にする失敗も、更新失敗で起動不能に陥る失敗も避けられます。迷ったときは、稼働中の本番機ほど変更のハードルを上げ、検証機で挙動を確かめてから本番へ反映する順序が安全です。

ファーム運用の負担から逆算するオンプレとクラウドの分担の考え方

もう一段引いた判断として、そもそもファームウェアを自分たちで面倒を見るのかという分担の問題があります。物理サーバーを自社で持つ限り、版数の棚卸し、リリースノートの読み込み、更新の計画停止、失敗時の復旧手段の確保は自分たちの仕事です。台数が10台を超えたあたりから、この作業は片手間では回らなくなります。

クラウドのマネージドな仮想サーバーへ寄せると、ファーム層はサービス提供者の責任範囲に入り、こちらが触る対象からBIOS設定そのものが消えます。代わりにインスタンスタイプの選定や課金の設計といった別の管理が発生するため、負担がゼロになるわけではありません。判断材料としては、専用ハードウェアの性能要件（NUMAやI/O直結の必要性）、機器を自社設置しなければならない制約、そしてファーム運用に割ける人手の3点で切り分けるのが実際的です。判断の全体像はオンプレミスとクラウドの違いで費用と可用性の観点から整理しています。

よくある質問

BIOSの実務でよく検索される疑問を、設定や運用の判断に直結する形で回答します。

BIOSとUEFIはどちらを使えばよいですか？

新規の環境では、特別な理由がない限りUEFIを選びます。2TBを超えるディスクから起動でき、Secure Bootでブートの改ざんを検知できるためです。レガシBIOS（互換モード）を選ぶのは、UEFIに対応しない古いOSや周辺機器との互換をどうしても維持したい場合にほぼ限られます。現在市販の機はUEFIで動くものが大半で、画面上「BIOS」と表示されても中身はUEFIです。どちらで起動しているかは、Linuxなら/sys/firmware/efiの有無、WindowsならBiosFirmwareTypeの値で確定できます。

BIOSの設定画面はどうやって開きますか？

電源を入れた直後に、メーカーが指定するキーを繰り返し押して開きます。よく使われるのはDelete、F2、F1、Esc、F10などで、機種やマザーボードメーカーによって異なります。起動時に画面下部へ「Press F2 to enter Setup」のような案内が一瞬表示されることが多いです。Windowsが高速起動で立ち上がる機では、OSの回復メニューからUEFI設定へ入る経路のほうが確実な場合もあります。サーバー機なら、BMCの遠隔コンソールから起動画面を掴むほうが、現地でキーを連打するより確実です。

BIOSの設定をリセットするとどうなりますか？

ブート順やデバイスの有効・無効、日時などの設定値が工場出荷時の状態に戻ります。プログラム本体（ファームウェア）は消えず、あくまで設定値だけが初期化される操作です。設定変更後に起動しなくなった、挙動がおかしいといった場面で、原因の切り分けとして有効な手段です。リセット後はブート順や仮想化支援など、必要な設定を再度入れ直します。UEFI機ではNVRAM上の起動エントリも初期状態へ戻るため、複数OSを入れている環境では起動メニューの再作成が要ります。

BIOSのアップデートは必要ですか？

常に必要というわけではありません。更新は、脆弱性の修正や特定ハードウェアの不具合対応、新しいCPUへの対応といった、自機に効く理由があるときに行います。安定して動いている機を「新しい版が出たから」という理由だけで更新するのは、起動不能のリスクに見合いません。更新するなら、リリースノートで効果を確かめ、電源の安定を確保してから実施します。判断の前提として、dmidecodeやRedfishで現在の版数を把握しておくと、対象機の絞り込みが速くなります。

BIOSとファームウェアは何が違うのですか？

ファームウェアは、ハードウェアに組み込まれた制御用ソフトウェアの総称で、BIOS／UEFIはそのうちマザーボード上で起動を担う代表例です。つまりBIOSはファームウェアの一種にあたります。ルーターやプリンター、SSDのコントローラーなどにもそれぞれファームウェアがあり、BIOS／UEFIはコンピューター全体を起動可能な状態へ持っていく役割のファームウェア、と位置づけると整理しやすいです。サーバーではBMCやRAIDコントローラ、NICにも個別のファームウェアがあり、更新計画はそれらを含めて立てます。