新しいサーバーOSが、古いCPUで動かない。2026年のLinuxディストリビューション選びとサポート期限の地図

こんにちは、インフラエンジニアのryuです。

今年はOSの移行の話をよく聞きます。新機能が魅力的だからではなく、期限が来てしまったからという理由のほうが多いのではないでしょうか。

実際、2026年は区切りが重なった年でした。Amazon Linux 2のサポートが6月30日に終わり、Ubuntuは4月に新しいLTSが出て、RHEL 10系への移行が本格化しています。

しかも今回の移行には、これまでになかった落とし穴があります。新しいOSが、手元の古いサーバーのCPUでは起動しないという事態が起き始めているのです。

今日は2026年のサーバーOS選びを、サポート期限とハードウェアの2軸で整理してみます。どれが優れているかという話ではなく、どこで判断が分かれるのかという地図の話です。

2026年、サポート期限がいくつも重なった¶

まず全体像から確認しましょう。主要なサーバー向けディストリビューションの期限を、1枚の表にまとめます。

この表を眺めると、今年が「待っていても解決しない年」だったことが分かります。

Amazon Linux 2には、もう更新が来ない¶

いちばん切実なのがAmazon Linux 2です。2026年6月30日で標準のセキュリティ更新が終わり、以後は新しい脆弱性が見つかっても修正が出ません。

AWSは後継のAmazon Linux 2023への移行を案内しており、そちらは2029年6月までサポートされます。

ただ、移行は単なるバージョンアップではありません。amazon-linux-extras が無くなっていたり、パッケージの入れ方が dnf に統一されていたりと、手順書の書き換えが必要になります。

EC2のAMIだけでなく、ECSのタスク定義やEKSのノードグループ、Lambdaのランタイム、コンテナのベースイメージにも古い指定が残っていることがあります。動いているから気づかない、というのがこの種の期限切れのやっかいなところです。

RHEL系は「10年」、Ubuntu LTSは「5年＋延長」¶

期限の考え方そのものも、系統によって違います。

RHEL系は1つのメジャーバージョンで約10年という長いサイクルです。前半がフルサポート、後半がメンテナンスサポートという二段構えで、後半は新機能が入らず修正だけが届きます。

UbuntuのLTSは2年ごとに出て、標準サポートが5年。Ubuntu Proを契約すると合計10年のESM（拡張セキュリティメンテナンス）になり、さらにLegacyの追加で最大15年まで延ばせる仕組みです。

つまり、無料で長く使いたいならRHEL系の無償クローン、契約を前提に新しい機能を早く取り込みたいならUbuntu、という傾向があるわけです。

「フルサポート終了」は、終わりではないが節目ではある¶

RHEL系の二段構えは、初めて見ると分かりにくいところです。来年2027年5月末にはRHEL 9がフルサポートを終えますが、これは使えなくなる日ではありません。

フルサポートの期間は、新しいハードウェアへの対応や機能の追加が入ります。メンテナンスサポートに移ると、届くのは重要な不具合と脆弱性の修正だけになります。

つまりフルサポートの終了は、そのバージョンで新しい機械を増やしにくくなる日だと考えると実務の感覚に近いです。既存機の運用は続けられても、数年後に調達するサーバーで同じOSを使える保証はなくなっていきます。

このあたりを押さえておくと、「まだ期限まで5年あるから大丈夫」という判断が少し慎重になります。

RHEL 10が持ち込んだ新しい分かれ道は、CPUの世代¶

ここからが今年のいちばん大きな話題です。

RHEL 10は、対応するCPUの下限を上げました。x86-64-v3という命令セットのレベルを必須にしたのです。

x86-64は長く使われてきたアーキテクチャなので、世代をまとめてv1からv4までのレベルに分けた呼び方があります。v3はAVX2に対応した世代、ざっくり言うとIntelのHaswell以降、AMDではExcavator以降です。

Red Hatはv1とv2をRHEL 8と9で非推奨として扱い、RHEL 10では非サポートにしました。結果として、古い物理サーバーや、古い互換モードで動かしている仮想マシンでは、インストーラーがglibcのエラーで止まることがあります。

要件を満たさない環境では、起動時に「Fatal glibc error: CPU does not support」という形で弾かれます。設定の問題ではないので、チューニングでは回避できません。

これまでOSの選定というと、パッケージの新しさやサポート年数の比較でした。2026年はそこに、手元のハードウェアが通るかどうかという条件が加わったことになります。

自分の環境がどのレベルかを先に確認する¶

移行の検討を始めるなら、まずCPUのレベルを調べるのが先です。設計を考える前に、候補から外れるハードウェアを把握しておくほうが早いからです。

確認は既存のOS上でできます。

# AVX2 があるかどうかで x86-64-v3 をおおまかに判断できる
lscpu | grep -o -m1 -E 'avx2|avx512f'

# glibc が認識している x86-64 のレベルを見る（glibc 2.33 以降）
/lib64/ld-linux-x86-64.so.2 --help | grep -E 'x86-64-v[0-9]'

# 仮想マシンなら、ハイパーバイザー側のCPU互換設定も確認する
cat /proc/cpuinfo | grep -m1 'model name'

仮想化基盤を使っている場合は、物理CPUが新しくてもゲストに見せるCPUの互換レベルを古い世代にそろえている構成があります。クラスタ全体の移行互換を優先した設定が、そのままOSの足切り条件に引っかかるわけです。

この手の調査は、構成を図にしてから始めると漏れが減ります。やり方はコマンドを打つ前に、1枚の図を描いてみる。インフラの理解が急に進む『構成図トレーニング』にまとめてあります。

AlmaLinuxは古いCPU向けのビルドを残した¶

ここで各ディストリビューションの姿勢が分かれました。

AlmaLinuxは、10系でx86-64-v2向けのビルドを別に用意しています。2026年5月26日に出た10.2でもこの並行ビルドは続いていて、EPELのパッケージもそろえられています。

一方でRocky Linux 10は、RHEL 10と同じくx86-64-v2のサポートを外しました。上流との互換をどこまで厳密に守るか、という方針の違いがそのまま出たかたちです。

古い資産をあと数年動かしたい事情があるなら、AlmaLinuxのv2ビルドは現実的な逃げ道になります。逆に、上流との差分を一切持ちたくない現場では、その差分自体が判断材料になるでしょう。

CentOS Stream 10という選択肢もありますが、こちらはRHEL 10の開発が先に進む場所です。検証や開発には向きますが、安定稼働させたい本番向けとは性格が違う点に注意してください。

Ubuntu 26.04 LTSは、中身がけっこう入れ替わった¶

4月23日に出たUbuntu 26.04 LTS（コードネームはResolute Raccoon）も、従来のLTS更新とは少し毛色が違います。

カーネルは7.0、systemdは255から259へ。Pythonは3.12から3.14に上がりました。OpenSSHは10.2系で、耐量子の鍵交換に対応し、OpenSSLにもML-KEMなどのアルゴリズムが入っています。

見逃せないのは、基本的なコマンドの実装が入れ替わったことです。sudo は標準がsudo-rsになり、ls や cp といった中核コマンドはrust-coreutilsが提供するようになりました。従来のGNU版も利用できますが、既定ではない構成です。

初期RAMディスクの作成もinitramfs-toolsからdracutに変わり、apt は3.1系で apt-key コマンドが削除されました。

自動化スクリプトへの影響を先に確かめる¶

こうした入れ替えは、手で触っている限りはほとんど気になりません。問題が出るのは自動化の部分です。

古い手順書に apt-key add が残っていれば、その行は動きません。コマンドの細かいオプションやエラーメッセージの文言に依存した処理も、実装が替わると挙動が変わることがあります。

最後の行は特に重要です。26.04 LTSは、systemdでSysV形式のサービススクリプトとの互換を持つ最後のリリースだと案内されています。/etc/init.d に古いスクリプトを置いて動かしている環境は、このLTSの期間中に書き換えておくのが安全です。

systemdのユニットをどう読み解くかは設定を直して再起動したのに、何も変わらない。systemdの言い分をsystemctlとjournalctlで読み解くで扱っているので、移行前の確認に使ってみてください。

では、2026年は何を選べばいいのか¶

ここまでの材料を、判断の順番に並べ直します。

まずハードウェアです。x86-64-v3を満たさない機械が残っているなら、選べるOSはそこで絞られます。次にサポート期限。システムの想定寿命より先にOSの期限が来ないかを見ます。

そのあとで、周辺のエコシステムと運用する人の慣れを見ます。監視エージェントやミドルウェアの対応表、社内の手順書がどちらの系統で書かれているか、という話です。

代表的なケースをまとめると、次のようになります。

この表を見て「結局、現場の事情で決まる」と感じた方は正解です。OS選定は優劣の比較ではなく、制約の積み上げで決まる作業です。

土台の知識は、どのディストリビューションでも変わらない¶

ここまで違いばかり書いてきましたが、実務でやることの大半は共通です。

パッケージ管理のコマンド名は違っても、サービスの起動と停止はどちらもsystemdですし、ログを追う場所も、ディスクやプロセスの調べ方もほぼ同じです。容量トラブルの切り分け方はディスクが100％なのに、duで数えると空いている。Linuxの容量トラブルを切り分ける順番のとおりで、ディストリビューションが変わっても手順は変わりません。

だからこそ、移行のたびに慌てないためには土台を押さえておくのが結局いちばん速いと感じます。基本のコマンドから順に固めたい方はLinuxコマンド入門：初心者が最初に覚えるべきコマンドから、体系的に学び直したい方はInfraAcademyのLinuxのロードマップをのぞいてみてください。手を動かす環境づくりにはDockerでLinux環境を作る方法も使えます。

まとめ¶

2026年のサーバーOS選びで押さえるべき点を振り返ります。

Amazon Linux 2は6月30日で終了し、移行は待ったなしの状態です。RHEL 10系はx86-64-v3が必須になり、古いCPUの機械は候補から外れます。AlmaLinuxだけがx86-64-v2向けのビルドを残しているので、古い資産の逃げ道として使えます。

Ubuntu 26.04 LTSは標準サポートが2031年までで、中身はsudo-rsやrust-coreutils、dracutへと大きく入れ替わりました。手作業への影響は小さいものの、自動化された構築手順には確認が必要です。

判断の順番は、ハードウェアの条件、サポート期限、エコシステム、そして運用する人の慣れ。この順に当てはめていくと、選択肢は自然に絞られていきます。

期限の話は気が重いものですが、棚卸しの良い機会でもあります。まずは手元のサーバーでCPUのレベルと現在のOSの期限を確認するところから始めてみてはいかがでしょうか。

参考記事¶

• Ubuntu release cycle（Canonical 公式のサポート期限一覧）
• Ubuntu 26.04 LTS release notes（公式リリースノート）
• Ubuntu 26.04 LTS summary for LTS users（LTS利用者向けの変更点まとめ）
• Red Hat Enterprise Linux Life Cycle（Red Hat 公式のライフサイクル）
• Exploring x86-64-v3 for Red Hat Enterprise Linux 10（Red Hat Developer）
• Amazon Linux 2 FAQs（AWS 公式・サポート終了について）
• General Availability of AlmaLinux OS 9.8 and 10.2 Stable!（AlmaLinux 公式ブログ）