Ubuntu 26.04 LTS 本番採用の移行判断｜Snap 依存サービス影響確認と 5 年サポート設計

Ubuntu 26.04 LTS が本番候補になるまでの経緯と現状

Ubuntu 26.04 LTS は 2026年4月にリリースされ、リリース直後から約5か月が経過しました。現時点（2026年9月）では最初のポイントリリースも公開されており、カーネルの安定度・パッケージの熟成という観点では「本番検討フェーズ」に入ったといえます。

一方で、現場の多くの運用担当者が24.04 LTS（Noble Numbat）上で稼働中のシステムを抱えており、「26.04 LTS に移行すべき時期か」という判断に迷っているケースが多く見られます。Ubuntu の LTS は通常リリース後6〜12か月を目安に移行判断を下す現場が増えますが、今回は Snap の扱いが大きく変わっている点が判断を複雑にしています。

本記事では、Snap 依存サービスの影響確認を中心に、段階的な移行手順・検証・切り戻し・5年サポート設計まで一連の流れを整理します。

Snap 依存サービスの影響範囲を最初に洗い出す

Ubuntu 22.04 以降、Firefox をはじめ複数の公式パッケージが Snap 版に切り替わりました。26.04 LTS では snapd 自体のバージョンが上がり、snap パッケージの自動更新タイミングや refresh スケジュールが変更されています。本番環境では「更新タイミングの不意打ち」がサービス断につながるリスクがあるため、移行前に現行システムの Snap 依存を棚卸しすることが出発点です。

まず現環境でインストール済みの Snap パッケージを確認します。

snap list
systemctl list-units --type=service | grep snap

出力に snap.*.service 形式のユニットが含まれている場合、そのサービスは snapd が管理しています。コンテナ・仮想マシン環境では /snap のマウントポイントやループバックデバイスが増加することがあり、監視ツールの「デバイス数超過アラート」が誤検知を起こすケースも報告されています。

影響を分類する際は次の3点を基準にするとよいでしょう。

• Snap 版パッケージの有無：snap list で一覧取得し、業務上クリティカルなものを抽出する
• snap refresh スケジュールの確認：snap get system refresh.schedule でメンテナンスウィンドウ外に更新が走らないか確認する
• ループバックデバイス数：losetup -a | wc -l で現状を把握し、26.04 移行後に比較できるようにしておく

Snap に頼らず deb パッケージで代替できるサービスは、移行前に切り替えておくと移行後のトラブルシューティングがシンプルになります。

移行判断の基準と do-release-upgrade を使った手順

本番移行の判断には「移行しないリスク」と「移行するリスク」の両方を天秤にかける必要があります。24.04 LTS の標準セキュリティサポートは2029年4月まで継続するため、今すぐ移行しなくても2〜3年の猶予はあります。一方、26.04 LTS 上でしか提供されない新しいカーネル機能（特定のeBPF拡張やファイルシステム機能）を必要とするワークロードでは早期移行が合理的な選択肢になります。

移行を決断した場合、インプレースアップグレードは do-release-upgrade コマンドで実施します。本番環境では必ずステージング環境で手順を通しておくことが前提です。

# アップグレード前の状態スナップショット取得（仮想環境の場合）
# 物理環境では事前にフルバックアップを取得すること

# パッケージを最新化してから実行する
sudo apt update && sudo apt full-upgrade -y
sudo do-release-upgrade

アップグレードプロセスは対話的に進みますが、SSH セッションが切断された場合の復旧を考慮し、tmux または screen のセッション内で実行することを現場では標準的な手順として採用しています。

アップグレード完了後に優先して確認すべき項目は以下のとおりです。

• カスタムリポジトリ（/etc/apt/sources.list.d/）が新リリースに対応しているか
• サードパーティ製のカーネルモジュール（DKMS ビルドが成功しているか）
• AppArmor プロファイルが新しい snapd バージョンと競合していないか
• Python・Ruby・Node.js 等のシステムパッケージバージョン変更による依存エラー

移行後の検証手順と切り戻し設計

移行直後の検証は「サービスが起動しているか」だけでなく、「期待どおりに動作しているか」まで確認することが重要です。特に Snap 由来のサービスは、snapd の起動順序が systemd ユニット間の依存関係に影響するため、起動は成功していても機能が一部制限されているケースがあります。

基本的な検証コマンドを以下に示します。

# 失敗しているユニットを一覧表示
systemctl --failed

# snap 経由のサービスに限定して状態確認
systemctl list-units 'snap.*' --state=active

# journald でエラーレベルのログだけ抽出
journalctl -p err -b

切り戻し設計については、インプレースダウングレードは Ubuntu では公式にサポートされていません。そのため「切り戻し」は事実上バックアップからの復元またはスナップショットの巻き戻しを意味します。本番移行前に次の準備を済ませておくと、最悪のケースでも復旧時間を最小化できます。

• 仮想マシン・クラウドインスタンスではスナップショットをアップグレード直前に取得する
• 物理サーバーでは Clonezilla 等を使ったディスクイメージバックアップを事前に保存する
• アプリケーションデータは移行とは独立した定期バックアップで保護する（移行作業に引きずられないよう分離する）

Blue/Green 方式で新旧環境を並走させ、ロードバランサーで切り替える運用ができる環境では、この方式が最も安全な移行パターンです。新環境の検証が完了するまで旧環境を維持することで、切り戻しコストを大幅に下げられます。

5年サポート設計：ESM と EOL を見据えたライフサイクル管理

Ubuntu 26.04 LTS の標準セキュリティサポートは2031年4月まで、Ubuntu Pro（旧 Ubuntu Advantage）に含まれる ESM（Expanded Security Maintenance）を適用すれば2036年4月まで延長できます。この10年間のサポートウィンドウをどう活用するかは、システムの陳腐化リスクと更新コストのバランスで決まります。

多くの企業では「標準サポート終了の1年前に次の LTS への移行を開始する」というポリシーを採用しています。26.04 LTS を採用する場合、2030年初頭には次の移行検討を始めるスケジュールを今のうちに計画に入れておくと、後になって慌てずに済みます。

Ubuntu Pro の適用状況は以下で確認できます。

pro status

ESM を活用する場合、esm-apps と esm-infra の両チャンネルが有効になっているかを確認します。インフラ系パッケージ（OpenSSL・glibc 等）は esm-infra、アプリケーション系パッケージは esm-apps でカバーされる仕組みです。特に規制産業（金融・医療・公共）では、EOL 後のパッケージに対するセキュリティパッチ供給の継続が監査上の要件になることがあるため、ESM の契約状況をドキュメントとして残しておくことが現場では求められています。

2026年現行環境での差分と見落としやすいポイント

24.04 LTS から 26.04 LTS への移行で、現場でよく報告されている差分をいくつか整理します。

Python デフォルトバージョンの変化：26.04 LTS ではシステム Python のバージョンが上がっており、/usr/bin/python3 が指すバージョンが変わる可能性があります。自社スクリプトが特定バージョンに依存している場合は、仮想環境（venv）への完全移行を検討する時機です。

netplan と NetworkManager の統合強化：26.04 では netplan バックエンドとして NetworkManager を利用するケースが増えています。既存の netplan 設定ファイルがアップグレード後に期待どおり適用されるか、ステージング環境で必ず確認してください。

systemd バージョン更新に伴う Unit ファイルの挙動変化：ProtectSystem や PrivateTmp 等のサンドボックス設定が新しい systemd では既定値から変わるケースがあります。カスタム Unit ファイルを多数管理している環境では、systemd-analyze verify を使って事前に警告を確認する手順を組み込むとよいでしょう。

snap refresh の時間帯制限：26.04 における snapd では refresh.timer の既定値が変更されています。本番環境でメンテナンスウィンドウ外に Snap パッケージが更新されないよう、移行後に snap set system refresh.metered=hold や refresh.schedule の設定を確認・再適用することが必要です。

Ubuntu 26.04 LTS の本番採用は「すぐに移行すべき」でも「しばらく様子見」でもなく、現行システムの Snap 依存度・ワークロードの要件・移行コストの3軸で判断が変わります。ステージング環境での手順検証と切り戻し設計を先に固め、本番移行の Go/No-Go 判断を根拠のある形で下せる準備を整えることが、安定した運用の出発点になります。