UbuntuサーバーはLTSとinterim releaseのどちら？

Ubuntu LTS と interim release の違い: 要点

サーバーで Ubuntu LTS と interim release のどちらを選ぶかは、そのリリースがセキュリティ更新を受けられる期間で決まります。LTS の標準セキュリティメンテナンス期間は 5 年です。interim release は 9 か月で、その後は更新が停止するため、アップグレードまたは再構築が必要です。他の利用者が依存する環境では LTS を使用してください。再構築を関係者への確認なしで実施できる環境に限り、interim release を使用してください。

LTS は long term support を意味します。Canonical は 2 年ごとの偶数年の 4 月に 1 つの LTS を公開し、その間の 6 か月ごとに 1 つの interim release を公開します。26.04 LTS は 23 April 2026 にリリースされ、標準セキュリティメンテナンスは 2031 年まで続きます。26.10 は 15 October 2026 にリリースされる予定です。これは interim release であるため、更新期間は July 2027 に終了します。

各 Ubuntu リリースのサポート期間

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

これは、2026年8月時点で Canonical が公開しているポリシー上の数値であり、テスト用サーバーで測定した値ではありません。LTS では、標準のセキュリティメンテナンスが 60 か月提供されます。これは、5年間で 1 回の計画的なリリースアップグレードに相当します。中間リリースのサポート期間は 9 か月です。同じ5年間、中間リリースの運用を続けると、10 回のリリースアップグレードが必要です。リリースをスキップできず、5年間には10回のリリースが含まれるためです。

Ubuntu Pro のサブスクリプションを利用すると、LTS のサポート期間は 120 か月、つまり10年に延長されます。また、対象範囲が main コンポーネントからアーカイブ全体に広がります。2026年8月時点では、Pro は個人利用で最大5台まで無料です。これは、小規模な VPS フリートの多くをカバーできます。中間リリースには同等の制度がありません。提供されるサポートは9か月のみで、サブスクリプションによって延長することもできません。

実サーバーで9か月が意味するコスト

26.10を例に考えます。26.10は2026年10月15日にリリースされ、セキュリティメンテナンスは2027年7月に終了します。これは、2026年7月に25.10で終了したものと同じ9か月のパターンです。カレンダーだけを見ると、4分の3年ごとに1回のメンテナンス期間があるように見えます。しかし、この見方は誤りであり、しかもコストが高くなる方向に誤っています。

リリースアップグレードでは、稼働中のオペレーティングシステムを置き換えます。do-release-upgrade は apt のソースを書き換え、サードパーティーのリポジトリを無効にし、インストール済みパッケージのほぼすべてのバージョンを変更します。また、編集済みの設定ファイルについて確認を求め、最後に再起動します。そのため、バックグラウンドジョブではなく、計画したメンテナンス期間として実施します。

ssh 経由で実行すると、接続が切れた場合にツールが保護してくれます。ツールは独自の screen セッションを開始し、2つ目の sshd を起動することを事前に通知します。

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

そのまま許可します。ファイアウォールまたはプロバイダー側の独立したネットワークファイアウォールで1022がブロックされている場合、このフォールバックは利用できません。その状態で接続が切れると、パッケージの更新が中途半端な状態で残ります。自分で tmux または screen の内部から実行すれば、どのサーバーでも同じ保護を得られます。

設定ファイルに関する確認が、15分のアップグレードを1時間に変える原因です。

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

自分のファイルを維持すると、新しいデフォルトで変更された内容を取り込めません。メンテナーのファイルを採用すると、ハードニング設定が失われ、再設定するまで無防備になります。リリースで何が変更されたかを把握しない限り、どちらの選択も安全ではありません。そのため、リリースノートの確認は任意の事前課題ではなく、メンテナンス期間の作業の一部です。

さらに、サーバーの台数分だけ増えます。中間リリースのトラックでVPSを1台運用すると、5年間でアップグレード期間は10回です。VPSが5台なら50回になります。ただし、すべてのサーバーを使い捨てにして、イメージから再構築する場合は別です。LTSトラックで5台を運用すると、同じ期間のアップグレードは5回で済み、それぞれを実施する月も選べます。

Ubuntu のリリースをスキップできない理由

アップグレードの経路は固定されています。中間リリースは、次のリリースへアップグレードします。LTS は、次の LTS へ直接アップグレードするか、指定した場合は次の中間リリースへアップグレードします。2 つ先のリリースへ一度にアップグレードすることはできません。26.10 から 28.04 LTS に移行するには、27.04 と 27.10 を経由するか、マシンを再インストールする必要があります。

この仕組みを理解しておくと、このルールが変更されない理由が分かります。do-release-upgrade は changelogs.ubuntu.com から meta-release ファイルを取得し、特定の移行専用に構築されたアップグレードツールをダウンロードします。Canonical は移行を 1 つずつ構築してテストするため、リリースをスキップする移行にはツールもテスト実績もありません。アップグレーダーが慎重さから拒否しているわけではありません。提供できるもの自体が存在しないためです。

提示されるリリースは、設定の次の 1 行で決まります。

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts は次の LTS だけを提示します。Prompt=normal は、LTS かどうかにかかわらず次のリリースを提示します。Prompt=never は何も提示しません。これは、意図していないアップグレードを、善意の同僚が開始するのを防ぐ方法です。LTS ではないリリースでは、lts は normal とまったく同じ動作をします。どちらの設定でも、26.10 の次のリリースは 27.04 だからです。このチェックは Checking for a new Ubuntu release を出力し、その後に New release ... available. 行または No new release found. を出力します。

もう 1 つ、スケジュールに関するルールで混乱しやすい点があります。LTS から LTS へのアップグレードは、新しい LTS がリリースされた当日には提示されません。最初のポイントリリースで開始され、26.04.1 は 27 August 2026 に予定されています。ポイントリリースは Ubuntu の新しいバージョンではありません。4 か月分の修正をまとめて新しいインストールメディアに反映した、同じリリースです。この待機期間が設けられているのは、アップグレード経路にその 4 か月分のテスト結果を反映してから提示するためです。Prompt=lts を設定した 24.04 のマシンが、2026 年の夏を通じて No new release found. と応答していても、故障していたわけではありません。ポリシーに従って動作していたのです。経路が開いたら、24.04 から 26.04 LTS へのアップグレードが、計画してリハーサルすべき作業になります。

中間リリースを選ぶべき場合

実際に中間リリースが有利になるのは、次の4つの場合です。

• 現在このサーバーで、LTS のアーカイブに含まれていない kernel または userspace のバージョンが必要な場合。
• そのマシンが build host、CI runner、または test box で、イメージから再構築する場合。アップグレードがメンテナンス時間ではなく、新しいインスタンスの作成になります。
• LTS の凍結後に hardware または hypervisor の機能が追加され、backport が存在しない場合。
• 次の LTS に含まれる内容を確認する場合。28.04 は 26.10、27.04、27.10 を基に構成されるため、予備の VPS で breaking change を見つけるほうが、重要なサーバーで見つけるよりコストが低くなります。

中間リリースを選ぶ人の多くは、新しい distribution ではなく、1つの新しい package を必要としています。より低コストな方法が2つあります。hardware enablement stack を使うと、後続リリースの kernel を LTS に導入できます。24.04 では sudo apt install linux-generic-hwe-24.04 であり、2回目の point release 以降、各 point release で更新されます。単一の application であれば、container image または vendor 独自の repository を使うことで、オペレーティングシステム全体ではなく、必要な1つの要素だけを更新できます。

中間リリースを選ぶべきでない場合

• 有料ユーザーがいるシステムや、オンコール対応のローテーションがあるシステム。使用することのないパッケージバージョンと引き換えに、年 2 回の強制アップグレードを受け入れることになります。
• unattended-upgrades がセキュリティパッチを自動適用しているサーバー。自動化の品質は、取得元の security ポケットの品質に左右されます。
• 手作業でアップグレードするサーバー群。実際のコストは、1 回の作業時間にサーバー台数を掛けたものになるためです。
• インストール後、1 年間確認しないもの。忘れられた中間リリースは、9 か月後にはパッチ未適用のインターネット公開サーバーになります。

最後の問題は気付きにくいため危険です。リリースがサポート終了になると、そのパッケージは old-releases.ubuntu.com に移動します。そのため sudo apt update は archive.ubuntu.com に対して 404 エラーで失敗し始めます。ディスク上のパッケージリストは古くなります。unattended-upgrades はタイマーどおりに実行され続け、/var/log/unattended-upgrades/unattended-upgrades.log に次のような行を書き込み続けます。

No packages found that can be upgraded unattended and no pending auto-removals

この行は、完全にパッチが適用されたサーバーでも、4 か月前にリリースがサポート終了したサーバーでも同じように表示されます。誰かが apt のエラーを確認するか、サポート終了日を管理していない限り、そのマシンがどちらの状態なのかを示す情報はありません。

最初に中間リリースへ入る種類の変更

2026年3月、Canonical のエンジニアが Ubuntu discourse で、26.10 の secure boot 用に提供される署名済み GRUB bootloader から機能を削減する案を提案しました。この案では、btrfs、hfsplus、xfs、zfs の filesystem driver、JPEG と PNG の image parser、Apple partition table、LVM 上の /boot、RAID 1 以外の software RAID、そして LUKS で暗号化された /boot を削除します。理由として示されているのは、bootloader 内の parser が繰り返し security bug の原因になることと、storage および encryption の処理は initramfs に置くべきだということです。initramfs は、kernel が実際の root filesystem を mount する前に mount する小さな初期 RAM filesystem です。2026年8月時点では、これは議論中の提案であり、リリース済みの変更ではありません。

ほとんどの VPS instance では、secure boot を使わず、GPT partition table 上の通常の ext4 /boot から boot するため、何も変わりません。思い込まずに自分の環境を確認してください。root が ZFS である場合、または /boot が btrfs 上もしくは LUKS 内にある場合、この変更は中間リリースで最初に影響を受ける種類のものです。このスレッドで影響を受けるユーザーに勧められている対策も、LTS を使い続けることです。この助言には、要点が1文でまとまっています。中間リリースは変更を試す場所です。LTS は、2年間の中間リリースで何が壊れるかが判明した後に、その変更が到達する場所です。

同じパターンは、各中間リリースでより小さな形でも現れます。database、language runtime、init configuration の default version が更新されるため、動作していた configuration file が動作しなくなることがあります。default を更新することは中間リリースの役割です。そのため、10回ある upgrade の前に毎回 release note を読むことが、受け入れるべき運用コストになります。

サーバー構築時にトラックを選択する

インストール時にトラックを選択してください。後から変更すると、再インストールするか、複数回のアップグレードが必要になります。新しいサーバーでは、4 つのコマンドで現在の状態を確認できます。

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a には、インストールするつもりだったリリース名が表示されます。LTS では、説明行の末尾が LTS になります。Prompt 行は、プロバイダーのイメージに含まれていたトラックではなく、選択したトラックと一致している必要があります。現在の LTS で do-release-upgrade -c を実行すると、No new release found. と返るはずです。代わりに interim release が提示される場合は、Prompt が normal に設定されているため、それが意図したものか判断してください。pro security-status では、インストール済みパッケージのうち、どれだけが各更新ストリームの対象になっているかを確認できます。また、マシンがサブスクリプションに登録されていない場合は、そのことが明確に表示されます。

次に、サポート終了日を、サーバーの他の構築メモと並べて、後からもう一度確認できる場所に記録してください。これは 新しい VPS の最初の 10 分間 に行う作業の一部です。サポート期限を誰かの記憶だけに頼ると、気付かないうちに期限切れになるためです。6 か月ごとの更新作業を完全に避けたいのであれば、いずれかの環境を多数のサーバーに導入する前に、Linux と比較した FreeBSD のリリースモデル を 1 時間かけて読む価値があります。

FAQ

Ubuntu の interim release を本番サーバーで実行すべきですか？

ほとんどの場合、実行すべきではありません。interim release はリリースから9か月後にセキュリティ更新の提供が終了するため、そのトラックで本番運用すると、およそ半年ごとに必ずアップグレードする必要があり、それが恒久的に続きます。例外として妥当なのは、CI runner や build host のように、そもそもイメージから再構築するマシンです。この場合、アップグレードは作業期間ではなく新しいインスタンスの作成になります。実際のユーザーがそのサーバーに依存しているなら、LTS をインストールし、節約したアップグレード期間を別の作業に使ってください。

Ubuntu の interim release はどのくらいの期間サポートされますか？

9か月です。26.10 は 15 October 2026 にリリースされ、セキュリティメンテナンスは July 2027 に終了します。これは July 2026 に終了した 25.10 と同じ形です。すべての interim release がこの方式に従い、April または October にリリースされ、9か月後に終了します。LTS には5年間の標準セキュリティメンテナンスが提供され、Ubuntu Pro を利用すると10年間に延長されます。2026年8月時点では、個人利用で最大5台まで無料です。

Ubuntu のリリースを飛ばしてアップグレードできますか？

できません。do-release-upgrade は1段階ずつ進みます。interim release は次のリリースへ移行し、LTS は次の LTS へ直接移行できます。26.10 から 28.04 LTS に移行するには、まず 27.04 と 27.10 を経由してアップグレードするか、マシンを再インストールする必要があります。Canonical は移行を1回ずつ構築してテストし、upgrader はその移行専用のツールをダウンロードします。そのため、2段階の移行に対応するツールはなく、提示されることもありません。

Ubuntu のリリースがサポート終了に達するとどうなりますか？

そのリリースのパッケージは old-releases.ubuntu.com に移動します。そのため sudo apt update は archive.ubuntu.com に対して 404 エラーで失敗し、そのリリース向けの新しいセキュリティ更新は一切公開されなくなります。マシン上では、この事実は通知されません。サーバーは動作し続け、ネットワークトラフィックを提供し続けますが、新たに公開された脆弱性はすべて未対策のまま残ります。復旧には、時間に追われながらリリースアップグレードを実行するか、再構築する必要があります。そのため、症状ではなく日付を確認してください。

新しいハードウェアに対して LTS の kernel は古すぎませんか？

通常は問題ありません。LTS は元の kernel を5年間使い続けるわけではないためです。hardware enablement stack である HWE は、後続リリースの kernel を point release のタイミングで LTS に取り込みます。server install では、linux-generic-hwe-24.04 のようなパッケージによって HWE を有効にできます。kernel が原因だと決めつける前に、uname -r で現在の状態を確認してください。不足しているのが kernel ではなく userspace のバージョンであれば、interim track 全体にマシンを移行するより、container または vendor repository を利用するほうが変更を小さくできます。