「Linuxのカーネルはこまめにアップデートすべきか、それとも触らない方がよいのか」。サーバーを運用していると必ず一度は迷うテーマです。カーネルはシステムの中核であるがゆえに、更新は恩恵も大きい一方で、失敗するとシステムが起動しなくなるリスクもあります。
この記事では、カーネルアップデートのメリット・デメリットを整理したうえで、実際の更新手順、再起動の判断、そして失敗したときに前のカーネルへ戻す方法までを、運用の視点で解説します。読み終えるころには「自分のサーバーは更新すべきか」を自分で判断できるようになります。
そもそもカーネルアップデートとは何か
カーネルは、CPU・メモリ・ディスクといったハードウェア資源を管理し、その上で動くソフトウェアとハードウェアの橋渡しをする、Linuxの「核」にあたる部分です。まず、よく混同される3つの言葉を区別しておきます。
| 言葉 | 意味 |
|---|---|
| カーネルアップデート（更新） | 配布元が用意した新しいカーネルパッケージに入れ替えること。パッケージ管理（dnf/apt）で行う日常的な作業 |
| カーネルアップグレード | より新しいバージョンのカーネルへ更新すること。機能追加やパフォーマンス向上が目的 |
| カーネル再構築（リビルド） | ソースコードから、必要な機能を足し引きして自分でカーネルをビルドすること。現在の一般的な運用ではほぼ不要 |
いまのサーバー運用で「カーネルアップデート」と言えば、ほとんどの場合はパッケージ管理ツールで配布元の新しいカーネルに入れ替えることを指します。ソースからの再構築が必要になる場面は、特殊なデバイスを使う一部のケースに限られます。
カーネルをアップデートするメリット
| メリット | 内容 |
|---|---|
| セキュリティ修正 | カーネルに見つかった脆弱性が塞がれる。公開サーバーでは最重要の理由 |
| 新しいハードウェア対応 | 新しいCPU・NIC・ストレージのドライバが取り込まれ、使えるようになる |
| 性能・安定性の向上 | スケジューラやファイルシステムの改善で処理性能・安定性が上がることがある |
| 不具合の修正 | 既知のカーネルバグが修正される |
特にインターネットに公開しているサーバーでは、セキュリティ修正を取り込むためのカーネルアップデートは「した方がよい」ではなく「する必要がある」作業だと考えてください。
デメリットとリスク
| デメリット | 内容・対策 |
|---|---|
| 再起動が必要 | 新しいカーネルを有効にするには再起動が必要。サービス停止のタイミング調整がいる |
| 起動しなくなる可能性 | まれに新カーネルで起動トラブルが起きる。→ 前のカーネルを残しておけば切り戻せる（後述） |
| ドライバ・モジュールの不整合 | 自前でビルドした外部モジュールがある場合、カーネル更新で作り直しが必要になることがある |
デメリットの多くは「前のカーネルを消さずに残しておく」「更新前にバックアップを取る」という運用でカバーできます。リスクを理由に更新を止めるより、切り戻せる状態を整えたうえで更新する方が、結果的に安全です。
実際の更新手順
現在のカーネルバージョンは uname -r で確認できます。更新前後で見比べると、正しく入れ替わったかが分かります。
# いま動いているカーネルのバージョンを確認
uname -r
# 例: 5.14.0-362.el9.x86_64uname はカーネルやシステムの情報を表示するコマンドです。unameを含むバージョン確認コマンドの詳細は本体で解説しています。
RHEL系（AlmaLinux / Rocky Linux など）
# システム全体を更新（カーネルも含まれる）
sudo dnf upgrade --refresh
# カーネルだけを更新したい場合
sudo dnf upgrade kernel
# インストール済みカーネルの一覧（複数残っているのが正常）
rpm -q kernelRHEL系は、既定で古いカーネルを数世代残す設定になっています。これは切り戻しのための安全策なので、無理に消さないでおきます。
Ubuntu / Debian系
# パッケージ情報を更新してからアップグレード
sudo apt update
sudo apt full-upgrade
# インストール済みカーネルの一覧
dpkg --list | grep linux-image更新後の再起動と、その判断
カーネルを更新しても、再起動するまでは古いカーネルで動き続けます。新しいカーネルを有効にするには再起動が必要です。「いま再起動すべきか」を判断する目安を持っておくと運用が楽になります。
# 再起動が必要かどうかの目安（Ubuntu/Debian）
# このファイルがあれば再起動が推奨されている
ls /var/run/reboot-required 2>/dev/null && echo "再起動が推奨されています"
# RHEL系：稼働中カーネルと最新インストール済みカーネルの差を確認
needs-restarting -r公開サーバーでセキュリティ修正のカーネルを入れた場合は、修正が有効になるのは再起動後です。メンテナンス枠を確保して速やかに再起動するのが望ましい運用です。逆に、業務時間中で止められない場合は、後述のライブパッチという選択肢もあります。
失敗に備える：前のカーネルで起動して切り戻す
新しいカーネルで起動トラブルが起きても、前のカーネルが残っていれば切り戻せます。再起動時に GRUB のメニューから、一つ前のカーネルを選んで起動します。
- 起動時に GRUB メニューを表示し、「Advanced options（詳細オプション）」から旧バージョンのカーネルを選ぶ
- 旧カーネルで正常に起動できれば、問題の新カーネルを調査・除去できる
- だからこそ、更新後すぐに古いカーネルを削除しないことが重要（RHEL系が数世代残すのはこのため）
この「前のカーネルを残しておき、いざとなれば選んで起動する」仕組みがあるため、カーネルアップデートは身構えるほど難しい作業ではありません。切り戻し手段を確保したうえで更新する、というのが運用の基本姿勢です。
2026年の現行環境での違い
- ソースからの再構築はほぼ不要：現在はディストリビューションが提供するカーネルパッケージを使うのが標準で、自分でソースをビルドする場面は特殊用途に限られます。
- 再起動なしで当てるライブパッチ：緊急のセキュリティ修正を再起動せずに適用する仕組み（RHEL系の kpatch、Ubuntu の Livepatch など）が実用化されています。止められないサーバーの応急策として選択肢に入ります。ただし恒久対応としては、後日きちんと再起動して新カーネルへ切り替えるのが原則です。
- 長期サポート（LTS）カーネル：頻繁に最新へ追従するより、ディストリビューションが保守する安定版カーネルを使い、そこへ配布されるセキュリティ更新を当てていくのが、サーバー運用では一般的です。
まとめ：更新すべきかの判断基準
カーネルアップデートをするかどうかは、次のように考えると迷いません。公開サーバーでセキュリティ修正が出ているなら「切り戻せる状態を整えたうえで更新し、メンテナンス枠で再起動する」。機能追加目的の任意アップグレードなら「本当に必要か、リスクに見合うかを見極めてから」。いずれの場合も、前のカーネルを残し、更新前にバックアップを取っておけば、失敗しても元に戻せます。カーネルの更新は、恐れて放置するより、安全網を張ってから淡々と回す運用対象だと捉えるのが現場の考え方です。
コメント