Ubuntuの最新版を本番サーバーに入れるべきか｜interim releaseとLTSの採用判断

「ubuntu 最新バージョンにアップグレードすべきか」——この問いは、サーバー管理者なら必ず一度は直面する。ところが「最新＝最良」と思い込んで最新のinterim release（暫定版）をそのまま本番サーバーに入れてしまい、9ヶ月後にサポートが切れてセキュリティアップデートが届かなくなる、というトラブルが現場では繰り返されている。

Ubuntuには6ヶ月ごとに出る「interim release」と、2年ごとに出る「LTS（長期サポート版）」の2系統がある。サポート期間は前者が9ヶ月、後者が5年（Ubuntu Proなら最大10年）と、実に10倍以上の差がある。どちらを本番に採用するかで、その後の運用コストは大きく変わる。

この記事では、ubuntu 最新バージョンの確認コマンドから、LTSとinterim releaseの違い、本番サーバーへの採用判断基準、実務でよくある落とし穴まで解説する。

UbuntuのリリースモデルーーLTSとinterim releaseの定義

Ubuntuのバージョン番号は「年.月」形式だ。22.04なら「2022年4月リリース」を意味する。リリースには2つの系統がある。

・LTS（Long Term Support）：西暦の偶数年4月にリリースされる長期サポート版。Ubuntu 22.04・24.04・26.04がこれにあたる。標準サポートは5年間。Ubuntu Pro（個人・小規模利用は無料）に登録すると最大10年のExtended Security Maintenance（ESM）が利用できる。
・interim release（暫定版）：LTS以外の6ヶ月ごとのリリース。Ubuntu 24.10・25.04・25.10がこれにあたる。サポートは9ヶ月で終了し、以降のセキュリティアップデートは一切提供されない。

種別	リリース頻度	サポート期間	本番への推奨
LTS	2年に1回（偶数年4月）	5年（Ubuntu Proで10年）	推奨（原則これのみ）
interim release	6ヶ月に1回	9ヶ月	非推奨（開発環境のみ）

ubuntu 最新バージョンが出るたびに「これを入れるべきか」と悩む前に、まずその版がLTSかinterim releaseかを確認することが第一歩だ。Ubuntu 26.04 LTS の概要を把握しておくと、LTSのリリースサイクル感覚がつかみやすい。

ubuntu 最新バージョンをサーバー上で確認する手順

1. lsb_release -a でバージョンと系統を確認する

最も手軽なのがlsb_releaseコマンドだ。

「Description:」の末尾に「LTS」が付いていればLTS版だ。付いていなければinterim releaseと判断できる。点数付きのバージョン表記（24.04.2）はポイントリリース（累積アップデート版）を意味し、通常はインストールイメージに含まれる最新パッチが適用された状態で配布される。

2. /etc/os-release で確認する

lsb_releaseコマンドが入っていない最小インストール環境では/etc/os-releaseを直接読む。

「VERSION」の行に「LTS」と表記があればLTS版だ。interim releaseの場合はLTS表記がなく、バージョン番号とコードネームのみが表示される。

3. ubuntu-security-status でパッケージのサポート状況を確認する

現在のサーバーでどのパッケージがサポート期間内かを確認するコマンドだ。ubuntu-advantage-toolsパッケージに含まれる。

「receive security updates until 4/2029」のようにEOL日付が具体的に表示される。複数台のサーバーを管理している場合、定期的にこのコマンドを実行して期限を把握しておくことが重要だ。

本番サーバーへの採用判断基準

ubuntu 最新バージョンが出るたびに本番採用の判断を求められる。以下の3点を基準にしてほしい。

1. サポート期間から逆算して判断する

本番サーバーの採用判断で最も重要なのはサポート期間だ。interim releaseは9ヶ月でEOLを迎える。本番環境でEOLになると、その後のセキュリティパッチは公式では提供されない。

受講生から「Ubuntu 25.10を本番に入れた直後に引き継いだが、着任から3ヶ月後にEOLを迎えてLTSへの移行対応を迫られた」という相談を受けたことがある。9ヶ月という期間はあっという間だ。

本番サーバーにはLTSのみを採用する、という原則を崩さないことが長期的な運用コストを下げる最善策だ。

2. アップグレードコストを考慮する

interim releaseはLTSへの「踏み台」として使われることがある。例えば 24.10→25.04→25.10→26.04 のように段階アップグレードをするケースだ。しかしこの方式は毎回の移行テスト・動作確認・ミドルウェア対応が発生し、運用コストが累積する。

LTSからLTSへのアップグレードであれば、do-release-upgradeのデフォルト動作（Prompt=lts設定）により次のLTSだけを対象にできる。本番サーバーではこの直接アップグレードが原則だ。

3. 新LTS直後の採用タイミングを見極める

新しいLTSがリリースされた直後（0ヶ月目）から全台移行するのは避けた方が良い。過去にはLTSのリリース直後にインストーラーや特定ハードウェアドライバー周りの問題が報告されるケースがあった。

現場での定石は「1台の検証機でリリース後1～3ヶ月かけて動作確認を行い、問題がなければ段階展開する」だ。特にミッションクリティカルなサービスでは最初のポイントリリース（例：26.04.1）が出てから移行計画を動かすのが安全な判断軸になる。

interim releaseを使ってよい場面

interim releaseが有効なのは以下の限定された場面だ。

・開発・テスト環境：EOLのリスクが本番と比べて限定的で、最新カーネルの動作確認が主目的の場合
・デスクトップ用途：最新ドライバーやデスクトップ環境の新機能を優先する個人PCや学習用途
・次期LTSの先行評価：開発環境で次のLTSに搭載される機能を事前に評価したい場合

いずれも「9ヶ月でEOLになっても業務に支障がない環境」であることが前提だ。本番サーバーへのinterim release適用は、特別な技術的理由がない限り避けること。

よくある判断ミスとその対処

「Prompt=normal」設定でinterim releaseに移行してしまった

do-release-upgradeは/etc/update-manager/release-upgradesの設定に従ってアップグレード先を決める。デフォルト設定を変更していない場合は「Prompt=lts」になっているが、過去にインストールした他のツールや手順書がこの設定を「Prompt=normal」に変えているケースがある。

本番サーバーでは必ず「Prompt=lts」になっていることを定期的に確認しておくこと。

EOL後もそのまま動き続けているサーバーを放置してしまった

Ubuntu 25.10のように9ヶ月でEOLを迎えるinterim releaseがEOL後もそのまま稼働しているケースが実際にある。EOL後はapt updateでパッケージリポジトリにアクセスできなくなるため、エラーでようやく気づくことも多い。

このエラーが出た場合は/etc/apt/sources.listのURLが「archive.ubuntu.com」から「old-releases.ubuntu.com」に切り替わっていないことが原因だ。EOL版には新規パッケージもセキュリティパッチも提供されないため、速やかにLTSへ移行すること。

本記事のまとめ

確認・判断ポイント	コマンド・設定
現在のバージョンと系統確認	lsb_release -a（末尾のLTS表記を確認）
OS情報をファイルで確認	cat /etc/os-release
パッケージのEOL状況確認	ubuntu-security-status
アップグレード先系統の確認	cat /etc/update-manager/release-upgrades
LTSへの設定固定	release-upgradesのPrompt=ltsを確認・維持
本番サーバーの原則	LTSのみ採用・interim release禁止
新LTS採用タイミング	1台の検証機で1～3ヶ月確認後に段階展開

ubuntu 最新バージョンがLTSかinterim releaseかを見極めることが、本番サーバー採用判断の出発点だ。サポート期間・アップグレードコスト・移行タイミングの3軸を基準に、長期運用に耐えられるバージョン選定を行ってほしい。

---

• 前のページへ：Ubuntu LTSのサポート期間を運用計画に落とし込む方法｜標準保守5年とESM延長を踏まえた更新タイミングの決め方
• この記事の属するカテゴリ：Linuxtipsへ戻る