Ubuntu LTSと中間リリースはどっち？サーバー運用の選び方

Ubuntu LTS と中間リリースの比較：結論

サーバーで Ubuntu LTS と中間リリースのどちらを選択するかは、セキュリティアップデートの提供期間という 1 つの指標で決まります。LTS は 5 年間の標準的なセキュリティメンテナンスを提供します。一方、中間リリースは 9 か月でアップデートが終了するため、アップグレードまたは再構築が必須となります。他者が依存する環境には LTS を使用してください。中間リリースは、誰の許可も得ずに再構築できる環境でのみ使用してください。

LTS は Long Term Support（長期サポート）を意味します。Canonical は 2 年ごとに 1 回、偶数年の 4 月に LTS をリリースし、その間に 6 か月おきに中間リリースを公開します。26.04 LTS は 2026 年 4 月 23 日にリリースされ、標準的なセキュリティメンテナンスは 2031 年まで続きます。26.10 は 2026 年 10 月 15 日に予定されている中間リリースであり、サポート期限は 2027 年 7 月となります。

各 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 回の計画的なリリースアップグレードに相当します。中間リリース（interim release）のサポート期間は 9 か月です。同じ 5 年間で中間リリースを使い続ける場合、リリースを飛ばすことはできないため、5 年間に 10 回のリリースが存在することになり、10 回のアップグレードが必要となります。

Ubuntu Pro サブスクリプションを適用すると、LTS のサポート期間は 120 か月（10 年間）に延長され、カバー範囲も main コンポーネントからアーカイブ全体へと拡大されます。2026 年 8 月現在、Pro は個人利用であれば最大 5 台まで無料で利用でき、小規模な VPS 群のほとんどをカバー可能です。中間リリースにはこれに相当する延長オプションはありません。9 か月間が提供されるすべてであり、サブスクリプションによって延長されることはありません。

実運用サーバーにおける9ヶ月のコスト

26.10を例に挙げます。このバージョンは2026年10月15日にリリースされ、セキュリティメンテナンスは2027年7月に終了します。これは25.10が2026年7月に終了したのと同様の9ヶ月サイクルです。カレンダーで見ると、3四半期に1回のメンテナンス期間があるように見えます。しかし、この解釈は誤りであり、コストの面でより深刻な誤解を招きます。

OSのアップグレードは、稼働中のOSをその場で置き換えます。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 ?

既存のファイルを保持すると、新しいデフォルト設定の変更点を見逃します。メンテナーのファイルを採用すると、再設定するまで施したセキュリティ対策が失われます。どちらの回答も、そのリリースでの変更内容を把握していなければ安全ではありません。そのため、リリースノートの確認はオプションの宿題ではなく、メンテナンス期間の一部となります。

さらに、サーバーの台数分だけ作業が増えます。interimトラックの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はchanglogs.ubuntu.comからメタリリースファイルを取得し、特定の移行用に構築されたアップグレードツールをダウンロードします。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は2026年8月27日に予定されています。Prompt=ltsを設定した24.04のサーバーで、2026年の夏の間ずっとNo new release found.と表示されていたとしても、それは故障ではありません。ポリシーに従っているだけです。アップグレードパスが開かれたら、24.04から26.04 LTSへのアップグレードを計画し、リハーサルを行う必要があります。

中間リリースが適切な選択となる場合

中間リリースが真に有効な4つのケースを挙げます。

• LTSアーカイブには含まれていないカーネルやユーザー空間のバージョンが、今すぐこのサーバーで必要な場合。
• そのマシンがビルドホスト、CIランナー、あるいはイメージから再構築するテスト用ボックスであり、アップグレードがメンテナンスウィンドウではなく新規インスタンスの作成として完結する場合。
• LTSのリリース後にハードウェアやハイパーバイザーの機能が追加され、バックポートが存在しない場合。
• 次期LTSに含まれる内容を確認したい場合。28.04は26.10、27.04、27.10を基に構成されます。予備のVPSで破壊的変更を見つけることは、本番環境で見つけるよりもコストが低く済みます。

中間リリースを求める人の多くは、OS全体ではなく、特定のパッケージの新しいバージョンを必要としています。その場合、より低コストな2つの解決策があります。ハードウェア有効化スタック（HWE）を利用すれば、後のリリースのカーネルをLTSに導入できます。24.04では sudo apt install linux-generic-hwe-24.04 がこれに該当し、2回目のポイントリリース以降、順次更新されていきます。単一のアプリケーションであれば、コンテナイメージやベンダー提供のリポジトリを利用することで、OS全体を入れ替えることなく特定のコンポーネントのみを更新可能です。

中間リリースを選択すべきではない場合

• 有料ユーザーを抱える環境や、オンコール体制が必要な環境。年2回の強制的なアップグレードを受け入れることになりますが、その見返りとして得られるパッケージバージョンを一度も使わない可能性があります。
• unattended-upgrades によるセキュリティパッチ適用を行っているサーバー。この自動化の信頼性は、参照先のセキュリティリポジトリの有効性に完全に依存します。
• 手作業でアップグレードを行っているサーバー群。実際のコストは、1台あたりの作業時間にサーバー台数を掛け合わせたものになるためです。
• インストール後に1年間放置するようなサーバー。忘れていた中間リリースは、9ヶ月後にはパッチが適用されないインターネット公開サーバーと化します。

最後のケースは静かに進行するため、非常に危険です。リリースがサポート終了（EOL）を迎えると、パッケージは 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のフォーラムにおいて、26.10で提供されるセキュアブート用署名済みGRUBブートローダーの機能を削減する提案を行いました。この提案では、btrfs、hfsplus、xfs、zfsのファイルシステムドライバー、JPEGおよびPNGの画像パーサー、Appleパーティションテーブル、LVM上の/boot、RAID 1以外のソフトウェアRAID、およびLUKSで暗号化された/bootのサポートが削除されます。提示された理由は、ブートローダー内のパーサーがセキュリティ脆弱性の温床となっており、ストレージや暗号化のロジックは、カーネルがルートファイルシステムをマウントする前に読み込む小さなRAMファイルシステムであるinitramfsに含めるべきであるというものです。2026年8月現在、これは議論中の提案であり、製品版に実装された変更ではありません。

ほとんどのVPSインスタンスでは、セキュアブートを使用せず、GPTパーティションテーブル上の標準的なext4 /bootから起動するため、影響はありません。推測で判断せず、自身の環境を確認してください。もしルートがZFSである場合、あるいは/bootがbtrfs上やLUKS内にある場合、これこそが暫定リリースで最初に直面する種類の変更です。スレッド内で影響を受けるユーザーに対して推奨されているのは、LTS版を使い続けることです。この助言こそが、すべてを物語っています。暫定リリースは変更を試すための場であり、LTSは2年間の暫定リリースを経て問題が洗い出された後に変更が到達する場所です。

同様のパターンは、あらゆる暫定リリースにおいて小規模な形で見られます。データベース、言語ランタイム、init設定のデフォルトバージョンが更新されるため、これまで動作していた設定ファイルが機能しなくなることがあります。デフォルト設定を前進させることこそが暫定リリースの役割であり、10回に及ぶアップグレードのたびにリリースノートを確認することが、ユーザーが支払うべき対価の一部となります。

構築時のトラック選択

インストール時にトラックを選択してください。後からの変更は再インストールや一連のアップグレード作業を伴うためです。新しいサーバーでは、以下の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. と返答されるはずです。もし中間リリースが提示される場合、Prompt が normal に設定されています。これが意図的なものかどうかを判断する必要があります。pro security-status は、インストール済みのパッケージがどの更新ストリームでカバーされているかを表示し、マシンがサブスクリプションに紐付いていない場合はその旨を明確に伝えます。

次に、サポート終了日をサーバーの構築メモの残りの部分と一緒に、いつでも確認できる場所に書き留めてください。これは 新しいVPSでの最初の10分間 に行う作業の一部です。誰かの記憶の中にしかないサポート期限は、気づかないうちに過ぎ去ってしまうからです。6ヶ月ごとの激しい変化を完全に避けたいのであれば、FreeBSDのリリースモデルとLinuxの比較 を1時間ほど読んでから、どちらのOSで運用するかを決定することをお勧めします。

FAQ

本番環境のサーバーで Ubuntu の中間リリースを使用すべきですか？

ほとんどの場合、使用すべきではありません。中間リリースはリリースから 9 か月でセキュリティアップデートが終了するため、本番環境で運用し続けるには、半年に一度のペースで永続的にアップグレード作業が必要になります。例外として、CI ランナーやビルドホストのように、イメージから再構築することが前提の環境であれば問題ありません。これらはアップグレードではなく、新しいインスタンスへの入れ替えとして運用できるためです。実際のユーザーが依存しているサーバーであれば、LTS をインストールし、アップグレードに費やすはずだった時間を他の作業に充てるべきです。

Ubuntu の中間リリースのサポート期間はどのくらいですか？

9 か月です。26.10 は 2026 年 10 月 15 日にリリースされ、2027 年 7 月にセキュリティメンテナンスが終了します。これは 25.10 が 2026 年 7 月に終了したのと同様のサイクルです。すべての中間リリースは、4 月または 10 月にリリースされ、9 か月後に終了します。LTS は 5 年間の標準セキュリティメンテナンスが提供され、Ubuntu Pro を適用することで 10 年間に延長可能です。なお、2026 年 8 月時点で、Ubuntu Pro は個人利用であれば最大 5 台まで無料で利用できます。

アップグレード時に Ubuntu のリリースを飛ばすことはできますか？

できません。do-release-upgrade は一度に 1 つのステップしか進めません。中間リリースは次のリリースへ、LTS は次の LTS へ直接アップグレードできます。26.10 から 28.04 LTS へ移行するには、27.04 および 27.10 を経由してアップグレードするか、OS を再インストールする必要があります。Canonical は一度に 1 つの遷移のみを構築・テストしており、アップグレードツールもその特定のジャンプ用に提供されるため、2 段階のジャンプをサポートするツールは存在せず、提供もされません。

Ubuntu のリリースがサポート終了（EOL）を迎えるとどうなりますか？

パッケージは old-releases.ubuntu.com に移動されるため、sudo apt update は archive.ubuntu.com に対して 404 エラーを返し、そのリリースに対する新しいセキュリティアップデートは一切公開されなくなります。サーバー上でこの状態を通知する機能はありません。サーバーは稼働し続け、トラフィックを処理し続けますが、新たに発見された脆弱性はすべて放置されたままになります。復旧には時間的制約のある中でのリリースアップグレードか、サーバーの再構築が必要になるため、症状が出る前に期限を監視してください。

LTS のカーネルは新しいハードウェアに対して古すぎますか？

通常は古くありません。LTS は 5 年間同じカーネルを使い続けるわけではないからです。ハードウェア有効化スタック（HWE）により、ポイントリリースごとに新しいリリースのカーネルが LTS に取り込まれます。サーバーインストール時に linux-generic-hwe-24.04 のようなパッケージを指定することで、これを選択可能です。カーネルが原因だと決めつける前に、uname -r を実行して現在のカーネルバージョンを確認してください。もし不足しているのがカーネルではなくユーザー空間のバージョンであれば、マシン全体を中間リリースへ移行するよりも、コンテナやベンダーリポジトリを利用する方が変更の影響を小さく抑えられます。