「自動更新を有効にしたはずなのに、実際にセキュリティパッチが当たっているか分からない」——そんな不安を抱えたことはありませんか。Ubuntu/Debianのapt自動更新（unattended-upgrades）は、設定を入れただけでは安心できません。本当に動いているかは/var/log/unattended-upgradesのログを見て初めて確認できます。本記事ではUbuntu 24.04 LTSを基準に、apt/snapの自動更新設定とログをコマンドで点検し、放置された未適用パッケージがないかを見分ける手順を、出力例つきで解説します。
なぜ「入れたつもり」の自動更新が止まっていることがあるのか
2026年8月だけでも、Linuxまわりでは見過ごせない動きが続いています。米CISAは2026年8月27日、LinuxカーネルのIPv6スタックの脆弱性を含む3件を「悪用が確認された脆弱性カタログ（KEV）」に追加し、行政機関に対して2026年8月30日までという極めて短い是正期限を設定しました。2026年7月には、XFSファイルシステムの競合状態を突く「RefluXFS」（CVE-2026-64600）が報告され、1,640万件以上のシステムに影響が及ぶ可能性があると分析されています。さらに2026年3月には、net/bondingサブシステムに19年近く見過ごされてきたゼロデイ脆弱性（CVE-2026-43456）の修正が入ったばかりです。OpenSSHも2026年8月11日に10.5/10.5p1をリリースし、複数のセキュリティ修正を含んでいます。
こうした修正は、自動更新が正常に動いていれば数日〜数週間のうちに自分の環境にも届きます。逆に言えば、自動更新の設定が実は無効になっていた、あるいはエラーで止まっていた場合、これらの修正が何ヶ月も適用されないまま放置されることになります。Ubuntu 24.04 LTS（Noble Numbat）はメインリポジトリに対し5年間の無償セキュリティメンテナンスが付いていますが、それは「自動更新が正しく動いていれば」の話です。まずは自分の環境で本当に動いているかを確認しましょう。
apt/unattended-upgradesの自動更新設定を確認する
自動更新が有効になっているか
設定ファイルを直接見るのが一番早い方法です。sudo不要・ファイルは変更しません。
cat /etc/apt/apt.conf.d/20auto-upgrades何を見ているか：apt が「パッケージ一覧の自動取得」と「自動アップグレード」をそれぞれ有効にしているかどうかの設定値です。
正常な出力例：
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";判断基準：両方とも "1" なら有効です。どちらかが "0"、あるいはファイル自体が存在しない（No such file or directory）場合は自動更新が無効になっています。この場合は次のコマンドで有効化できます（sudoが必要・設定ファイルを書き換えます）。
sudo dpkg-reconfigure -plow unattended-upgrades画面の指示で「Yes」を選ぶと 20auto-upgrades が自動生成されます。元に戻したい場合は、同じコマンドで「No」を選ぶか、ファイル内の値を手動で "0" に書き換えれば無効化できます。
どのパッケージが対象になっているか
grep -A3 "Allowed-Origins" /etc/apt/apt.conf.d/50unattended-upgrades何を見ているか：自動更新の対象になっているリポジトリ（通常はセキュリティ更新のみ）の一覧です。
正常な出力例（コメント行 // が外れている行が有効な設定）：
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
"${distro_id}ESMApps:${distro_codename}-apps-security";
};判断基準：-security を含む行が有効になっていればセキュリティ更新は対象です。通常アップデート（-updates）まで自動化したい場合は、該当行の先頭の // を外して追加しますが、機能追加を含む更新も自動で入るため、業務用サーバーでは慎重に判断してください。
実行スケジュールを確認する
unattended-upgradesは systemd のタイマーで定期実行されます。どのタイマーがいつ次に走るかを確認します。
systemctl list-timers apt-daily.timer apt-daily-upgrade.timer --all何を見ているか：パッケージ一覧の取得（apt-daily.timer）と自動アップグレード本体（apt-daily-upgrade.timer）が、次にいつ実行される予定かです。タイマーの仕組み全般をもう少し広く点検したい場合は、systemctl list-timers点検2026年8月版で他の自動処理タイマーも合わせて確認できます。
正常な出力例：
NEXT LEFT LAST PASSED UNIT
Fri 2026-08-29 07:12:00 JST 3h left Thu 2026-08-28 06:58:02 JST 20h ago apt-daily-upgrade.timer
Fri 2026-08-29 12:34:00 JST 8h left Thu 2026-08-28 12:20:11 JST 14h ago apt-daily.timer判断基準：LAST（前回実行日時）が1〜2日以内であれば正常に動いています。LAST が何日も前のまま、あるいはタイマー自体が一覧に出てこない場合は停止しています。その場合は次のコマンドで有効化します（sudo必要・サービスの起動状態を変更します）。
sudo systemctl enable --now apt-daily.timer apt-daily-upgrade.timer実際にパッチが当たっているかログで確認する
直近の実行ログを見る
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log何を見ているか：自動更新が「いつ・何を」処理したかの実行履歴です。ログファイルは root 所有のため sudo が必要ですが、読むだけで変更は加えません。
正常な出力例：
2026-08-28 06:58:03,112 INFO Starting unattended upgrades script
2026-08-28 06:58:04,301 INFO Allowed origins are: ['o=Ubuntu,n=noble,l=Ubuntu,c=security']
2026-08-28 06:58:12,558 INFO Packages that will be upgraded: openssh-server openssh-client
2026-08-28 06:59:01,004 INFO All upgrades installed判断基準：直近数日以内に Starting unattended upgrades script の行があり、All upgrades installed や No packages found that can be upgraded（対象なし＝正常）で終わっていれば問題ありません。逆に次のような行があれば異常です。
ERRORやTracebackを含む行がある → 更新処理が途中で失敗している- 最後の実行から1週間以上ログが更新されていない → タイマー自体が止まっている（前項で確認）
E: Could not get lock /var/lib/dpkg/lock-frontend→ 他のapt処理と競合して失敗した（一時的な現象であることが多いが、繰り返す場合は原因のプロセスを確認する）
未適用のパッケージが残っていないか
ログとは別に、今この瞬間に更新待ちのパッケージがどれだけあるかを直接確認できます。sudo不要・変更なしです。
apt list --upgradable 2>/dev/null正常な出力例（更新待ちなし）：
Listing... Done判断基準：Listing... Done だけならすべて適用済みです。パッケージ名がずらりと並ぶ場合は未適用の更新が残っています。特に openssh-server・linux-image-*・libssl* など security 関連のパッケージが並んでいる場合は優先的に手動で適用してください（sudo必要）。
sudo apt update && sudo apt upgrade「本当に自動更新が動くか」をログを待たずにその場で試したい場合は、実際には何もインストールしないドライランで確認できます（sudo必要ですが、システムへの変更は一切行いません）。
sudo unattended-upgrade --dry-run --debug大量のデバッグ行が出ますが、末尾近くの Packages that will be upgraded または No packages found that can be upgraded を見れば、現時点で自動更新が正しく対象パッケージを判定できているかが分かります。
snapの自動更新も忘れずに確認する
Ubuntuではブラウザや一部のツールがsnap経由で配布されており、aptとは別に更新スケジュールを持っています。sudo不要です。
snap refresh --time何を見ているか：snapパッケージ全体の自動更新（refresh）が次にいつ実行される予定かです。
正常な出力例：
timer: 00:00~24:00/4
last: today at 06:32 JST
next: today at 14:47 JST
判断基準：last が直近（数時間〜1日以内）であれば正常です。last の記録がない、あるいは非常に古い日付の場合、ネットワーク制限やスナップサーバーへの到達性の問題が疑われます。個別のsnapが更新待ちかどうかは次のコマンドで確認できます。
snap refresh --list更新待ちがなければ All snaps up to date. と表示されます。パッケージ名が並ぶ場合は sudo snap refresh で手動更新できます（sudo必要）。
異常が見つかったときの対応と元に戻す方法
症状 | 疑わしい原因 | 次の一手 |
|---|---|---|
20auto-upgradesが存在しない/値が0 | 自動更新が無効化されている |
|
タイマーのLASTが何日も前 | systemdタイマーが停止 |
|
ログにERROR/Tracebackが頻発 | ネットワーク不調やパッケージ依存関係の破損 |
|
apt list --upgradableに多数残る | 自動更新の対象外（-updatesが無効等） | 50unattended-upgradesの対象範囲を見直すか手動apt upgrade |
snap refresh --timeのlastが古い | スナップサーバーへの到達性問題 |
|
ここで紹介したコマンドはすべて確認用（読み取り専用）か、有効化しても設定ファイルの値を1行変えるだけの軽い変更です。dpkg-reconfigure や systemctl enable はいつでも同じコマンドの逆操作（Noを選ぶ、あるいは disable）で元に戻せるため、試して壊す心配はほとんどありません。なお、OpenSSHのように自動更新の対象になっていても再起動やサービス再読み込みが必要な場合があるため、openssh-server が更新された形跡がある日は、SSHログとauthorized_keys突合2026年8月版もあわせて確認しておくと安心です。
Debian 12 “Bookworm” でも設定ファイルの場所・コマンド自体は同じですが、Ubuntu特有の -security オリジン表記や、Ubuntu Proに関するメッセージ（esm-apps 等）は出ません。Debianはリリース単位でのポイントリリース（例：Debian 12.8で50件のセキュリティ修正・68件のバグ修正）としてまとまって配布される点もUbuntuとの違いとして押さえておくとよいでしょう。
まとめ
apt自動更新は「設定を入れた」ことと「実際に動いている」ことは別物です。/etc/apt/apt.conf.d/20auto-upgradesで有効化を確認し、systemctl list-timersで実行スケジュールを確認し、/var/log/unattended-upgrades/unattended-upgrades.logとapt list --upgradableで実際に適用されているかを見る——この3段階を月1回でも確認する習慣があれば、2026年8月のCISA KEV追加やOpenSSH 10.5のような重要な修正を取りこぼさずに済みます。snapを使っている場合はsnap refresh --timeも忘れずに。