Ubuntu自動更新と深夜再起動設定｜unattended-upgrades

Ubuntuサーバーをインターネットに公開して運用していると、OSや各種ライブラリのゼロデイ脆弱性への迅速な対応が不可欠になります。しかし、セキュリティパッチを手動で適用し続けるのは運用負荷が高く、作業漏れのリスクも伴います。

一方で、不用意に自動更新を有効にすると、日中の業務時間帯に突然サーバーが再起動したり、サービスの依存関係が崩れてWebサイトが停止したりするトラブルを懸念する運用者も少なくありません。

この記事では、Ubuntu 24.04 LTSおよびUbuntu 26.04 LTSを対象に、標準ツールであるunattended-upgradesを活用して、セキュリティ修正のみをバックグラウンドで安全に自動適用し、カーネル更新に伴う再起動を深夜帯（02:00など）に限定して完全制御する具体的な手順を解説します。

この記事で行うこと
前提条件・対象読者
unattended-upgradesの基本仕様と安全設計
1. なぜすべての更新ではなく「セキュリティ更新」だけを適用するのか
2. 自動更新が実行されるタイミング
手順1：パッケージのインストールと自動更新の有効化
1. パッケージのインストール
2. 対話型画面による自動更新の有効化
手順2：深夜帯の自動再起動（02:00）を設定する
1. 50unattended-upgrades の編集
2. 自動再起動パラメータの変更
手順3：特定パッケージの更新を除外する（Blacklist設定）
1. ブラックリストの記述方法
2. 正規表現の注意点
手順4：Ubuntu 24.04以降の「needrestart」による予期せぬサービス再起動を防ぐ
1. needrestartの仕様変更とは
2. 重要サービスを自動再起動から除外する方法
手順5：ドライラン（–dry-run）で設定を事前検証する
1. シミュレーションコマンドの実行
手順6：更新ログと再起動状態を確認する
1. ログファイルの確認
2. 再起動が必要かどうかのステータス確認
メール通知を設定したい場合
トラブルシューティング：よくある問題と対処法
1. 1. サーバー起動直後にaptコマンドがロックされて使えない
2. 2. スケジュールされた深夜再起動を緊急キャンセルしたい
よくある質問（FAQ）
まとめ
次に読むおすすめ記事
参考情報

この記事で行うこと

unattended-upgradesの仕組みと、更新対象をセキュリティ修正に限定する理由の理解
自動更新機能の有効化と実行スケジュールの確認
深夜帯（例: 午前2時）に限定した自動再起動（Automatic-Reboot）の設定
業務影響を避けるための特定パッケージ（カーネルやミドルウェア）の更新除外（Blacklist）
Ubuntu 24.04 LTS以降で導入されたneedrestartによる予期せぬサービス再起動の制御
ドライラン（シミュレーション）とログ確認による安全な事前検証

前提条件・対象読者

この記事は、以下のような環境および読者を対象としています。

対象OS: Ubuntu 24.04 LTS (Noble Numbat)、Ubuntu 26.04 LTS (Resolute Peacock)
必要な権限: sudo権限を持つ一般ユーザー、またはroot権限
対象読者: 自宅サーバー、VPS、クラウド（AWS EC2、さくらのVPSなど）でUbuntuサーバーを運用しており、安全にセキュリティパッチを自動適用したいエンジニア

なお、コンテナホスト（Dockerホスト）や一般的なLinuxディストリビューションでも基本思想は共通ですが、設定ファイルのパスやデフォルトの挙動はUbuntu LTS環境を基準に説明します。

unattended-upgradesの基本仕様と安全設計

Ubuntu Serverでは、unattended-upgradesというパッケージが最初から組み込まれており、バックグラウンドでセキュリティアップデートを定期的に適用する機能が備わっています。

なぜすべての更新ではなく「セキュリティ更新」だけを適用するのか

Linuxのパッケージアップデート（apt upgrade）には、新機能の追加や細かなバグ修正を含む「通常アップデート」と、重大な脆弱性を修正する「セキュリティアップデート」の2種類があります。

通常アップデートまで自動で適用してしまうと、パッケージの仕様変更によって既存のWebアプリケーションやデータベースが動作しなくなるリスクがあります。unattended-upgradesは、デフォルトで公式のセキュリティリポジトリ（security）およびUbuntu ProのESM（Expanded Security Maintenance）のみを対象とするよう設計されており、システムの安定性を損なわずに脆弱性だけを迅速に塞ぐことができます。

自動更新が実行されるタイミング

自動更新はcronではなく、systemdのタイマー機能（apt-daily.timerおよびapt-daily-upgrade.timer）によって管理されています。

apt-daily.timer: 1日に2回実行され、パッケージリストの更新（apt update相当）を行います。
apt-daily-upgrade.timer: 1日に1回実行され、実際のパッケージダウンロードと適用（unattended-upgrade）を行います。

これらはサーバーへの負荷集中を避けるため、一定のランダムな遅延（RandomizedDelaySec）を設けて実行されます。

手順1：パッケージのインストールと自動更新の有効化

まず、必要なパッケージが導入されているか確認し、自動更新の基本設定を有効化します。

パッケージのインストール

Ubuntu Serverでは通常インストール済みですが、最小構成（Minimal）などで未導入の場合は以下のコマンドでインストールします。

sudo apt update
sudo apt install -y unattended-upgrades update-notifier-common

対話型画面による自動更新の有効化

以下のコマンドを実行すると、ターミナル上に設定画面が表示されます。

sudo dpkg-reconfigure -plow unattended-upgrades

画面に「自動的にアップデートパッケージをダウンロードしてインストールしますか？」というプロンプトが表示されるので、「はい（Yes）」を選択してEnterキーを押します。

これにより、/etc/apt/apt.conf.d/20auto-upgrades というファイルが自動生成（または更新）され、日次の自動更新が有効になります。

設定ファイルの内容を確認します。

cat /etc/apt/apt.conf.d/20auto-upgrades

以下のように両方の値が “1” になっていれば正常です。

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Update-Package-Lists “1”: 1日ごとにパッケージリストを更新します（0で無効）。
Unattended-Upgrade “1”: 1日ごとにセキュリティパッチの自動適用を実行します（0で無効）。

手順2：深夜帯の自動再起動（02:00）を設定する

カーネル（linux-image）などの重要コンポーネントが更新された場合、変更を有効化するにはOSの再起動が必要です。

しかし、デフォルトのunattended-upgradesでは自動再起動は無効（false）になっており、手動で再起動するまで古いカーネルのまま稼働し続けます。かといって即時再起動を有効にすると、日中のアクセス集中時間帯にサーバーが突然リブートしてしまう危険があります。

そこで、再起動が必要な場合のみ「指定した深夜時刻（午前2時など）」に自動再起動する設定を行います。

50unattended-upgrades の編集

メイン設定ファイルである /etc/apt/apt.conf.d/50unattended-upgrades をテキストエディタで開きます。

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

自動再起動パラメータの変更

ファイル内を検索し、以下の行を探して修正します（行頭の // はコメントアウトなので必ず削除してください）。

// 修正前:
//Unattended-Upgrade::Automatic-Reboot "false";
//Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
//Unattended-Upgrade::Automatic-Reboot-Time "now";

// 修正後:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

各パラメータの意味は以下の通りです。

Automatic-Reboot “true”: パッチ適用後に再起動が必要（/var/run/reboot-required が存在）な場合、自動で再起動を実行します。再起動が不要な更新だった場合は再起動しません。
Automatic-Reboot-WithUsers “true”: SSH等でログイン中のユーザーが残っていても再起動を実行します。falseにした場合、セッションが残っていると再起動がスキップされます。
Automatic-Reboot-Time “02:00”: 再起動を実行する時刻を24時間形式（ローカルタイムゾーン）で指定します。午前2時であれば “02:00″、午前4時半であれば “04:30” と記述します。

この設定を入れておくと、パッチ適用時に再起動フラグが立った場合、直ちにリブートするのではなく、Linuxの内部コマンド shutdown -r 02:00 がスケジュールされ、深夜の指定時刻まで安全に待機します。

手順3：特定パッケージの更新を除外する（Blacklist設定）

業務で利用しているミドルウェア（Nginx、MySQL、PostgreSQLなど）や、独自のビルドモジュールを組み込んでいるカーネルなど、「自動でバージョンアップされると困るパッケージ」は更新対象から除外（ブラックリスト登録）できます。

ブラックリストの記述方法

同じく /etc/apt/apt.conf.d/50unattended-upgrades を開き、Unattended-Upgrade::Package-Blacklist セクションを編集します。

設定値はPythonの正規表現として解釈されます。

Unattended-Upgrade::Package-Blacklist {
    // カーネル関連の自動更新をすべて停止したい場合
    "linux-";

    // NginxとMySQLの自動更新をピン留め除外したい場合
    "nginx$";
    "mysql-server$";
    "mariadb-server$";

    // 特定の共有ライブラリを除外したい場合
    "libc6$";
};

正規表現の注意点

パッケージ名の末尾に $ を付けることが推奨されます。

例えば、"nginx" とだけ書くと、前方一致で nginx-common や nginx-core なども意図せず一致して除外されます。厳密にそのパッケージ名のみを除外したい場合は、"nginx$" のように末尾を固定します（先頭の ^ はunattended-upgradesによって自動的に補完されます）。

手順4：Ubuntu 24.04以降の「needrestart」による予期せぬサービス再起動を防ぐ

Ubuntu 24.04 LTS（Noble）以降の環境でサーバーを運用する際、最も注意すべき重要な仕様変更が needrestart のデフォルト挙動です。

needrestartの仕様変更とは

libcやOpenSSLなどの共有ライブラリが更新された場合、OSを再起動しなくても、そのライブラリを使用しているデーモン（サービス）を再起動しなければ脆弱な古いコードがメモリ上に残り続けます。

Ubuntuではこの検出と再起動を needrestart というパッケージが担っていますが、Ubuntu 24.04 LTS以降、更新後に影響を受けるサービスを「自動的に即座に再起動する（Automatic mode）」挙動がデフォルトとなりました。

これにより、OS全体の再起動は深夜2時に遅延させていても、パッチが当たった日中の瞬間にWebサーバー（NginxやApache）やDockerデーモンが勝手に再起動し、接続中のユーザーが一瞬切断される事態が発生します。

重要サービスを自動再起動から除外する方法

基幹サービスが予期せぬタイミングで再起動されるのを防ぐため、設定を追加します。設定ファイル /etc/needrestart/needrestart.conf を直接書き換えるのではなく、/etc/needrestart/conf.d/ 配下に独自の設定ファイルを配置するのがUbuntuの作法です。

設定ファイルを作成します。

sudo nano /etc/needrestart/conf.d/disable-service-restart.conf

以下の設定を記述します。

# 特定の重要サービスを自動再起動から除外する
$nrconf{override_rc} = {
    qr(^nginx\.service$) => 0,
    qr(^apache2\.service$) => 0,
    qr(^mysql\.service$) => 0,
    qr(^docker\.service$) => 0,
};

上記の設定を入れておくと、他の軽微なプロセスは自動再起動されつつも、Webサーバーやデータベース、Dockerデーモンだけは日中の自動再起動から保護されます。除外されたサービスは、深夜のOS自動再起動時、またはメンテナンス時に手動で再起動すれば問題ありません。

もし「すべてのサービスについて自動再起動を停止し、再起動が必要なサービスの一覧ログを出力するだけにしたい」という場合は、以下のように記述します。

# サービスを自動再起動せず、リスト表示のみにする
$nrconf{restart} = 'l';

手順5：ドライラン（–dry-run）で設定を事前検証する

設定が完了したら、実際に更新や再起動を待つ前に、意図通りに動作するかシミュレーション（ドライラン）を行います。

シミュレーションコマンドの実行

以下のコマンドを実行します。-v は詳細出力、--dry-run は実際の更新や再起動を行わないテストモードです。

sudo unattended-upgrade -v --dry-run

実行すると、以下のような診断ログが出力されます。

Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=noble-security, o=UbuntuESM,a=noble-infra-security
Initial blacklist: nginx$ mysql-server$
Option --dry-run given, *not* performing real actions
Packages that will be upgraded: libssl3
Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
All upgrades installed

チェックすべきポイントは以下の通りです。

Allowed origins: セキュリティリポジトリ（noble-securityなど）が含まれているか
Initial blacklist: 手順3で指定した除外パッケージ名が表示されているか
Packages that will be upgraded: 更新対象のパッケージが正しくリストアップされているか

エラーが表示されず、「All upgrades installed」で終了すれば設定は正常です。

手順6：更新ログと再起動状態を確認する

運用開始後に自動更新が正しく行われているか、または再起動が保留されているかを確認する方法を把握しておきましょう。

ログファイルの確認

unattended-upgradesの実行ログは /var/log/unattended-upgrades/ に保存されます。

/var/log/unattended-upgrades/unattended-upgrades.log: 実行日時、対象パッケージ、再起動スケジュールのサマリー
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log: dpkgによる詳細なパッケージ展開ログ

最新のログを確認するには以下のコマンドを使用します。

sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log

再起動がスケジュールされた場合、ログ末尾に以下のようなメッセージが記録されます。

WARNING Found /var/run/reboot-required, rebooting
WARNING Shutdown msg: Reboot scheduled for Wed 2026-09-10 02:00:00 JST, use 'shutdown -c' to cancel.

再起動が必要かどうかのステータス確認

システム全体で再起動が要求されているかどうかは、以下のファイルの有無で判定できます。

ls -l /var/run/reboot-required

ファイルが存在する場合、どのパッケージが再起動を要求しているかは以下のファイルで確認できます。

cat /var/run/reboot-required.pkgs

出力例:

linux-image-6.8.0-55-generic
linux-base

メール通知を設定したい場合

サーバーで外部送信可能なメール環境（Postfixやmsmtpなど）が整っている場合、更新結果やエラーを管理者のメールアドレスに通知できます。

/etc/apt/apt.conf.d/50unattended-upgrades を編集します。

// 送信先メールアドレスの指定
Unattended-Upgrade::Mail "admin@example.com";

// 通知タイミングの指定（on-change: 更新があった時のみ / only-on-error: エラー時のみ / always: 毎回）
Unattended-Upgrade::MailReport "on-change";

通常はメールが過剰に届くのを防ぐため、更新が発生した時だけ通知する “on-change” または異常時のみの “only-on-error” が実用的です。

トラブルシューティング：よくある問題と対処法

1. サーバー起動直後にaptコマンドがロックされて使えない

Ubuntuの仮想マシンやPCを起動した直後、sudo apt update や sudo apt install を実行すると「Could not get lock /var/lib/dpkg/lock-frontend」というエラーが出ることがあります。

これは、前述のsystemdタイマーが「前回起動していなかった分の自動更新」を起動直後にキャッチアップ実行しているためです。

この挙動を停止し、起動直後の割り込みを無くして次回スケジュール時刻まで待機させるには、タイマーのPersistent設定を無効化します。

sudo systemctl edit apt-daily.timer

エディタが開いたら、以下の内容を記述して保存します。

[Timer]
Persistent=false

同様に apt-daily-upgrade.timer にも設定します。

sudo systemctl edit apt-daily-upgrade.timer

[Timer]
Persistent=false

設定反映のため、デーモンをリロードします。

sudo systemctl daemon-reload

2. スケジュールされた深夜再起動を緊急キャンセルしたい

メンテナンス作業などで、今夜予定されている自動再起動を取り消したい場合は、通常のshutdownキャンセルコマンドを実行します。

sudo shutdown -c "Manual maintenance"

よくある質問（FAQ）

Q: セキュリティ以外の通常パッケージも自動更新したい場合はどうすればいいですか？

A: /etc/apt/apt.conf.d/50unattended-upgrades の Unattended-Upgrade::Allowed-Origins セクションにある "${distro_id}:${distro_codename}-updates"; の行頭コメント（//）を外すことで通常アップデートも対象になります。ただし、予期せぬ挙動変更を避けるため、本番サーバーではデフォルト（セキュリティのみ）のまま運用することを強く推奨します。