• HOME
  • OSのカーネルアップデートとセキュリティパッチの適用手順（WordPressを動かすVPS向け）

2026年5月30日

  • シェア
  • ツイート

    • 2026年5月30日

    OSのカーネルアップデートとセキュリティパッチの適用手順（WordPressを動かすVPS向け）

    WordPress を VPS やクラウドのサーバーで動かしているなら、OS のセキュリティパッチは「自動で取り込み、再起動だけは計画して行う」形にすると、安全性と安定性のバランスが取りやすくなります。カーネルの更新は再起動するまで反映されない点が見落とされやすいので、再起動が必要かを判定する方法と、更新後にサイトが戻らなかったときの戻し方まで含めて説明します。Ubuntu／Debian 系と、AlmaLinux・Rocky Linux などの RHEL 系の両方を扱います。

    この記事の対象と前提

    共用レンタルサーバーやマネージド WordPress ホスティングでは、OS の更新は事業者が行うため利用者の作業はありません。この記事は、root 権限を持って自分で OS を管理している VPS やクラウドインスタンスが対象です。

    作業前に確認しておきたいのは次の2点です。

    • OS のサポート期限：サポートが終わった OS にはセキュリティパッチが出ません。cat /etc/os-release でバージョンを確認し、ディストリビューションの公式サイトでサポート期限を確かめてください。たとえば CentOS 7 や Ubuntu 20.04 の標準サポートはすでに終了しています（2026年10月現在）
    • バックアップ：更新前に VPS のスナップショット、またはデータベースのダンプと wp-content のバックアップを取っておきます。カーネル更新で起動しなくなったときに、最短で戻せるのはスナップショットです

    現在のカーネルと更新の有無を確認する

    まず、いま動いているカーネルと、インストール済みで未反映のカーネルがあるかを確認します。

    # 動作中のカーネル
uname -r

# Ubuntu / Debian：更新可能なパッケージ
sudo apt update
apt list --upgradable

# RHEL 系：セキュリティ更新だけを一覧
sudo dnf updateinfo list --security

    uname -r の結果と、インストールされている最新のカーネルのバージョンが違う場合、新しいカーネルは入っているのに再起動していない状態です。脆弱性の修正はまだ効いていません。

    Ubuntu / Debian でパッチを適用する

    手動で適用する場合は次のとおりです。

    sudo apt update
sudo apt upgrade

    apt upgrade は依存関係で新しいパッケージが必要な更新を保留することがあります。カーネルのメタパッケージ（linux-generic など）の更新が保留されたまま残っている場合は、内容を確認してから sudo apt full-upgrade を使います。

    unattended-upgrades で自動化する

    Ubuntu では unattended-upgrades が標準的に使われ、セキュリティ更新を自動で取り込めます。有効かどうかは次のファイルで確認できます。

    # /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

    自動再起動の設定は /etc/apt/apt.conf.d/50unattended-upgrades にあります。WordPress サイトを動かしているサーバーでは、勝手に再起動されると予期しないダウンタイムになるため、自動再起動はオフのままにして、再起動は計画して行う運用が無難です。夜間の自動再起動を許容できるなら、時刻を指定して有効にする方法もあります。

    Unattended-Upgrade::Automatic-Reboot "false";
// 許容する場合の例
// Unattended-Upgrade::Automatic-Reboot "true";
// Unattended-Upgrade::Automatic-Reboot-Time "04:00";

    設定を変えたら、sudo unattended-upgrade --dry-run --debug で実際に何が対象になるかを確認できます。

    再起動が必要かを判定する

    Ubuntu／Debian では、再起動が必要な更新が入ると /var/run/reboot-required が作られ、原因になったパッケージが /var/run/reboot-required.pkgs に記録されます。

    if [ -f /var/run/reboot-required ]; then
  cat /var/run/reboot-required.pkgs
fi

    また、needrestart が入っていれば、ライブラリの更新後に再起動が必要なサービス（php-fpm や nginx など）を案内してくれます。カーネル以外の更新では、OS 全体ではなくサービスの再起動だけで済む場合も多くあります。

    RHEL 系（AlmaLinux / Rocky Linux）でパッチを適用する

    RHEL 系では dnf でセキュリティ更新だけを適用できます。

    sudo dnf upgrade --security

# 再起動が必要かを判定（dnf-plugins-core に含まれる）
sudo dnf needs-restarting -r

    needs-restarting -r は、再起動が必要なら終了コード1とともにその旨を表示します。

    自動化には dnf-automatic を使います。/etc/dnf/automatic.conf で upgrade_type = security と apply_updates = yes を設定し、タイマーを有効にします。

    sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

    ディストリビューションのバージョンによって dnf の世代や設定ファイルの書き方が変わることがあるため、使用中のバージョンのドキュメントも確認してください。なお、RHEL 系では古いカーネルが一定数残る設定（/etc/dnf/dnf.conf の installonly_limit）になっており、新しいカーネルで問題が出ても前のカーネルで起動し直せます。

    再起動を安全に行う手順

    カーネルの更新を反映するには再起動が必要です。WordPress サーバーでは次の順で行うと、問題が起きても原因を追いやすくなります。

    1. アクセスの少ない時間帯を選び、関係者に告知する
    2. スナップショットまたはバックアップを取得する
    3. 必要なサービスが起動時に自動で立ち上がる設定か確認する
    4. 再起動し、サービスとサイトの応答を確認する

    3 の確認は、手動で起動していたサービスが再起動後に止まったままになる事故を防ぐためです。サービス名は環境に合わせて読み替えてください。

    systemctl is-enabled nginx php8.3-fpm mariadb

sudo reboot

# 再起動後
uname -r
systemctl --failed
curl -I https://example.com/

    systemctl --failed に何も表示されず、サイトが 200 を返し、管理画面にログインできれば完了です。WP-Cron に依存する予約投稿やバックアップのジョブがある場合は、次回の実行が正常に行われるかも確認しておきます。

    再起動を減らすライブパッチという選択肢

    カーネルのライブパッチは、再起動せずに一部の脆弱性修正を稼働中のカーネルに適用する仕組みです。Ubuntu では Ubuntu Pro の Livepatch、RHEL では kpatch などがあり、提供条件や対象はディストリビューションと契約形態によって異なります。

    # Ubuntu Pro を利用している場合の例
sudo pro enable livepatch
canonical-livepatch status

    ライブパッチは再起動の頻度を減らすものであり、再起動を不要にするものではありません。対象外の修正や累積した更新を反映するため、定期的な再起動の計画は残しておきます。

    更新後に起動しない・不具合が出たとき

    カーネル更新後の問題は、起こりやすい順に次のように確認します。

    1. サービスが起動していない：systemctl --failed と journalctl -b -p err でエラーを確認し、該当サービスを起動します。最も多いのは自動起動の設定漏れです
    2. 特定のカーネルモジュールが読み込めない：独自にビルドしたモジュールや一部のセキュリティ製品は、新しいカーネルに合わせた再ビルドが必要なことがあります。dmesg や journalctl -k でモジュール関連のエラーを確認します
    3. 起動自体ができない：VPS のコンソール（シリアルコンソールや VNC）から GRUB のメニューを開き、詳細オプションから1つ前のカーネルを選んで起動します。それでも戻らなければスナップショットから復元します

    前のカーネルで起動して問題がなければ、ディストリビューションの不具合情報を確認し、修正版が出るまでそのカーネルで運用する判断もあります。RHEL 系では grubby で既定のカーネルを変更できます。古いカーネルは Ubuntu では sudo apt autoremove --purge で整理できますが、問題が解決するまでは残しておくのが安全です。

    運用ルールの例

    • セキュリティ更新は自動で取り込む（unattended-upgrades または dnf-automatic）
    • 再起動が必要かを毎週確認し、必要なら月に1回など決まった時間帯に再起動する
    • 深刻な脆弱性が公表されたときは、ディストリビューションのセキュリティ情報を確認して臨時で適用する
    • 更新・再起動の記録を残し、サイトの不具合が出たときに時期を照合できるようにする

    まとめ

    • uname -r と更新状況を確認し、カーネルは再起動して初めて反映されることを押さえておきます
    • Ubuntu／Debian は unattended-upgrades、RHEL 系は dnf-automatic でセキュリティ更新を自動化し、再起動は計画して行います
    • 再起動前にはバックアップとサービスの自動起動設定を確認し、再起動後は systemctl --failed とサイトの応答で確認します
    • 不具合が出たら、サービス、カーネルモジュール、起動の順に切り分け、GRUB で前のカーネルに戻すかスナップショットから復元します
    Views: 65

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲