以前の記事で、古いノートパソコンに Ubuntu を導入しました。その後、Python の Flask サーバーと Tailscale を使って、ものすごく簡単な自宅サーバーを勉強と実験用に運用しています。
Ubuntu を入れたら次に覚えたいのが、「パッケージを最新に保って Ubuntu の安全性を高める」ことです。本記事では、手動でやる apt update / apt upgrade の基本から始めて、最初から動いている自動更新（unattended-upgrades）の仕組み、さらにカーネル更新後の自動再起動の有効化まで、順に見ていきます。
2026年5月にも Linux カーネルのローカル権限昇格（LPE）脆弱性が複数公開されました（2026年5月27日時点で Ubuntu のセキュリティ更新にはパッチが未到達）。攻撃者が一般ユーザー権限から root を奪える深刻な内容です。こういう緊急のセキュリティ更新が来たときに「気づくのが遅れる」「reboot を忘れる」を防ぐためにも、自動化までやっておくと安心です。
apt update と apt upgrade の違い
Ubuntu でパッケージを最新化する基本コマンドは 2 つあります。よく似た名前で混同しやすいですが、役割は別物です。
apt update— パッケージリスト（最新版情報）を取得するだけ。実際のパッケージは何も変わりませんapt upgrade— 取得したリストに基づき、実際にバージョンアップを当てます
update（情報収集）→ upgrade（実適用）という 2 段階構成です。
手動でアップグレードしてみる
実際に打ってみます。
sudo apt update
sudo apt upgrade
sudo apt upgrade を実行すると、更新対象のパッケージ一覧と「[Y/n]」プロンプトが表示されるので、Y を入力すれば進みます。更新対象がなければ「0 upgraded, 0 newly installed, …」と出て終わります。
2 つのコマンドを && でつなぐと、apt update が成功した時だけ apt upgrade を実行できます。
sudo apt update && sudo apt upgrade
ここまでが手動の基本です。次に、Ubuntu がこの作業をどこまで自動でやってくれているかを確認します。
自分の Ubuntu で確認してみる
Ubuntu が自動で何をやってくれているか、2 つのコマンドで確認できます。
セキュリティの自動更新が ON になっているか
cat /etc/apt/apt.conf.d/20auto-upgrades
以下のように 2 行とも "1" になっていれば、セキュリティの自動更新は ON です。
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
もしこのファイルが存在しないか "0" になっていれば、セキュリティの自動更新は無効です。
再起動が必要な状態か
ls /var/run/reboot-required
ファイル名が表示されれば再起動待ち、No such file or directory というメッセージが出れば再起動不要です。再起動待ちなら、カーネル更新などが当たっているので sudo reboot で再起動してください。
自動更新ツール（unattended-upgrades）は何をしてくれるか
unattended-upgrades は Ubuntu / Debian 系の標準パッケージで、apt update / apt upgrade を人手なしで定期実行するための自動化ツールです。apt 本体を内部で呼び出して使います。Ubuntu では最初からインストール済みで、しかも最初から有効化されています（先ほど確認した 20auto-upgrades ファイルがインストール時に自動生成されているためです）。ただしカーネル更新後の自動再起動だけは別途オプトインが必要で、それが本記事の本丸です。
動作の流れ
ツールが毎日勝手に動いている裏側は、こういうチェーンになっています。
- systemd（Linux 標準のサービス管理機構）の
apt-daily-upgrade.timerが、毎日決まった時刻に発火（デフォルトは朝 6:00〜7:00 頃） - timer が対応する
.service（「何を起動するか」の指示書）を呼び出す .serviceに書かれた起動コマンドに従って、ツール本体（unattended-upgrades）が起動- ツールが
/etc/apt/apt.conf.d/の設定ファイルを読み、何をするか決める apt update→ 対象パッケージをapt upgrade→ ログ出力
つまり「いつ起動するか」は systemd が、「起動した後で何をするか」は apt-conf 配下の設定ファイルが決めている、という二段構成です。
なお「何をするか」の対象は、デフォルトではセキュリティ更新だけですが、50unattended-upgrades の Allowed-Origins を編集すれば通常のバグ修正やサードパーティ repo（Docker / Tailscale など）も自動更新の対象に広げられます（本記事ではそこまではやっていません）。
設定ファイルの構成
設定の場所は役割で 2 系統に分かれています。
| 系統 | 場所 | 何を決めるか |
|---|---|---|
| systemd 設定 | /lib/systemd/system/ の apt-daily.timer / apt-daily-upgrade.timer および対応する .service |
発火時刻・起動コマンド・実行条件 |
| unattended-upgrades 自身の設定 | /etc/apt/apt.conf.d/ 配下の複数ファイル |
対象パッケージ・再起動方針・ON/OFF |
以降は apt-conf 配下に注目します。/etc/apt/apt.conf.d/ 配下のファイルは番号順に読み込まれ、同じ項目があれば後に読まれた方が優先されます。本記事に関係するのは次の 3 つです。
/etc/apt/apt.conf.d/10periodic— スケジュール詳細を決めるファイル（インデックス更新の頻度、自動アップグレードの ON/OFF など）/etc/apt/apt.conf.d/20auto-upgrades— 自動更新を ON にする 2 行が書かれている、先ほど見たファイル/etc/apt/apt.conf.d/50unattended-upgrades— 対象パッケージや再起動方針などの詳細ポリシー
本記事で編集するファイル
次の章から、設定を入れていきます。本記事で触るのは 10periodic と 50unattended-upgrades の 2 つで、それぞれ次の理由で編集します。
10periodic— 更新ファイルを事前ダウンロードしておくと実適用時のダウン時間が短くなる、といった細かい運用改善のため50unattended-upgrades— デフォルトで無効になっているカーネル更新後の自動再起動を有効化するため。これを有効にしないと、せっかくセキュリティパッチが当たっても古いカーネルで動き続けてしまいます（本記事の本丸）
20auto-upgrades は既に正しく設定されているので、本記事では触りません。順に進めていきます。
10periodic を編集して更新スケジュールを最適化する
このファイルには「毎日何をするか」のスイッチが 3 行並んでいます。そのうち 1 行だけ値を変えて、更新ファイルの事前ダウンロードを有効化します。
まずバックアップを取ります。
sudo cp /etc/apt/apt.conf.d/10periodic /etc/apt/apt.conf.d/10periodic.bak-20260527
続けて nano で開きます。
sudo nano /etc/apt/apt.conf.d/10periodic
最終的に以下の 3 行になるよう編集します（2 行目だけ "0" → "1" に変更、他はそのまま）。
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "0";
各行はもとのデフォルトから次のように編集しています。
Update-Package-Lists—"1"のまま（変更なし）。apt のインデックスを毎日更新Download-Upgradeable-Packages—"0"→"1"に変更。更新ファイルを事前ダウンロードしておく（実適用時の中断時間が短くなる）AutocleanInterval—"0"のまま（変更なし）。家庭用 PC ではキャッシュ累積がほぼ問題にならないので、本記事ではデフォルトに任せます。気になる場合は日数（例:"7"で 7 日に 1 回）を入れて、古い apt キャッシュ（/var/cache/apt/archives/配下の.debファイル）の自動削除を有効化できます
50unattended-upgrades を編集して自動再起動を有効化する
ここが本記事の本丸です。 カーネル更新後の自動再起動はデフォルトで無効になっているので、これを有効化します。
このファイル自体は長いのですが、本記事で触るのは自動再起動に関する 3 行だけです。
自動再起動を入れるか入れないかの判断
カーネル更新の場合、新しいカーネルで動き始めるには再起動が必要です。unattended-upgrades には「カーネル更新が入ったら自動で再起動までやる」機能がありますが、デフォルトでは無効です。
今回は、朝 4:00 JST に自動再起動を有効化することにしました。深夜帯で使っていない時間帯、かつ自動アップグレード本体（朝 6:00〜7:00）より前なので、カーネル更新が当たった日でも次回の更新作業の前にきれいに新カーネルになっていてくれる時刻です。
なお、ここで指定する時刻は OS のローカルタイムゾーンで解釈されます。日本でインストールしていれば通常 JST になっていますが、念のため timedatectl で確認してください。
timedatectl
出力に Time zone: Asia/Tokyo (JST, +0900) と表示されれば OK です。Asia/Tokyo になっていなければ、以下で JST に切り替えます。
sudo timedatectl set-timezone Asia/Tokyo
編集する 3 行
まずバックアップを取ります。
sudo cp /etc/apt/apt.conf.d/50unattended-upgrades /etc/apt/apt.conf.d/50unattended-upgrades.bak-20260527
続けて nano で開きます。今回は長いファイルで特定の行を編集するので、-l オプションを付けて行番号を表示させます。
sudo nano -l /etc/apt/apt.conf.d/50unattended-upgrades
以下の 3 箇所を編集します（行番号は環境によりズレることがあります）。
| 行 | 編集前 | 編集後 |
|---|---|---|
| 94 | //Unattended-Upgrade::Automatic-Reboot "false"; |
Unattended-Upgrade::Automatic-Reboot "true"; |
| 98 | //Unattended-Upgrade::Automatic-Reboot-WithUsers "true"; |
Unattended-Upgrade::Automatic-Reboot-WithUsers "true"; |
| 103 | //Unattended-Upgrade::Automatic-Reboot-Time "02:00"; |
Unattended-Upgrade::Automatic-Reboot-Time "04:00"; |
- 1 行目 (
Automatic-Reboot "true") — 自動再起動そのものを有効化 - 2 行目 (
Automatic-Reboot-WithUsers "true") — SSH でログインしているユーザーがいても再起動する。これをfalseにすると、SSH 接続を張ったまま離席している日に再起動されない - 3 行目 (
Automatic-Reboot-Time "04:00") — 再起動時刻
保存は Ctrl + O → Enter、終了は Ctrl + X です。
編集後、3 行とも先頭の // が消えていることを確認します。
sudo grep -nE "Automatic-Reboot" /etc/apt/apt.conf.d/50unattended-upgrades
期待する出力：
94:Unattended-Upgrade::Automatic-Reboot "true";
98:Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
103:Unattended-Upgrade::Automatic-Reboot-Time "04:00";
これで設定編集は終わりです。
動作確認
dry-run（試運転）で設定の正しさをチェック
設定が壊れていないか、--dry-run オプション付きで実行してシミュレーションします（dry-run は「実際には更新を当てず、何をしようとするかだけログに出す」モードです）。
sudo unattended-upgrade --dry-run --debug 2>&1 | tail -30
エラーが出なければ設定は正しいです。出力はおおむね以下のような形になります。
Checking: <パッケージ名> ...
Packages that will be upgraded: <あれば列挙、無ければなし>
No packages found that can be upgraded unattended and no pending auto-removals
現時点でセキュリティ更新の対象がなければ「upgrade なし」の旨が出ます。設定ファイルに構文エラーがある場合は、ここでエラーとして表面化します。
systemd timer がちゃんと予約されているか
実際に毎日この仕組みを動かしているのは apt-daily 系の systemd timer です。次回実行予定が入っているかを確認します。
systemctl list-timers --all | grep apt
2 つの timer が active で、次回実行時刻が表示されれば OK です。
<曜日> <次回実行時刻> ... apt-daily.timer apt-daily.service
<曜日> <次回実行時刻> ... apt-daily-upgrade.timer apt-daily-upgrade.service
apt-daily.timer— 1 日 2 回（朝と夜の時間帯）にインデックス更新apt-daily-upgrade.timer— 朝 6:00〜7:00 頃に実際のアップグレードを適用
バックアップを削除する
動作確認まで終わったら、/etc/apt/apt.conf.d/ 配下に作ったバックアップを削除します。残しておくと、sudo apt update を打つたびに「無効な拡張子だから無視するよ」という Notice が毎回出ます。
sudo rm /etc/apt/apt.conf.d/10periodic.bak-20260527
sudo rm /etc/apt/apt.conf.d/50unattended-upgrades.bak-20260527
完了後の運用
自動で動き続けるので、日々の操作は不要です。気が向いたときに以下のコマンドで状況確認できます。
何が更新されたか・エラーが出ていないかを見る
systemd timer 経由の実行ログ：
sudo journalctl -u apt-daily-upgrade --since "1 month ago" | tail -50
unattended-upgrades 専用のログ（最後の 100 行）：
sudo tail -n 100 /var/log/unattended-upgrades/unattended-upgrades.log
更新結果をメールや Slack に通知する方法もありますが、家庭運用では設定の手間に見合わないと判断して入れていません。
apt の実行履歴で「ホントに動いているか」を確認する
unattended-upgrades が本当に毎日動いているか不安なときは、apt の実行履歴ログを見ます。手動 / 自動を問わず、apt が実行した内容が時系列で残っています。
sudo cat /var/log/apt/history.log | tail -50
Commandline: /usr/bin/unattended-upgrade で始まる行が自動更新の実行記録です。日付・時刻と一緒に「何のパッケージを更新したか」が見えるので、ちゃんと動いていることが目で確認できます。
再起動が保留中かを 1 行でチェック
記事の冒頭で紹介した ls /var/run/reboot-required で随時チェックできます。本記事の設定後はカーネル更新が当たっても 04:00 に自動で再起動されますが、04:00 まで待てない場合は sudo reboot で手動再起動してもかまいません。
知っておきたい注意点
- セキュリティ更新のパッケージしか自動適用されません。通常のバグ修正や機能改善は引き続き手動
apt upgradeが必要です。カーネル LPE のような脆弱性対応は自動で当たりますが、それ以外は自動化されない点に注意してください - サードパーティ apt リポジトリは対象外。Docker / NodeSource / Tailscale など Ubuntu 公式以外で配布されている apt リポジトリは、デフォルトの
Allowed-Originsに含まれていません。これらは緊急度の高いセキュリティ更新でも自動適用されず、手動apt upgradeで都度更新する必要があります。Allowed-Originsを編集して対象に加えることも可能ですが、配布元の更新スタイルが各社まちまちで事故になりやすいので、私は手動運用のままにしています - systemd timer はサスペンド中は動きません。ただし
apt-daily-upgrade.timerにはPersistent=trueが設定されているので、次に電源 ON になったときに逃した分が遅れて発火します。常時稼働でなくても問題ありません
参考
/etc/apt/apt.conf.d/10periodic— スケジュール設定/etc/apt/apt.conf.d/50unattended-upgrades— ポリシー設定/var/log/unattended-upgrades/— 実行ログ/var/log/apt/history.log— apt の実行履歴（手動/自動どちらも残る）/var/run/reboot-required— 再起動保留フラグjournalctl -u apt-daily-upgrade— systemd 経由のログ
