Linuxのバージョン確認コマンド｜OSはos-release、カーネルはuname -rで見る

Linuxのバージョン確認は、cat /etc/os-releaseでディストリビューションの版を、uname -rでカーネルの版を見る、という2本立てが基本です。この2つは別の番号で、Ubuntu 24.04のGAカーネル（リリース時の標準カーネル）は6.8系、Rocky Linux 9.8のカーネルは5.14系というように一致しません。

この記事では、2026年10月27日にUbuntu・Debian・Rocky Linux・AlmaLinux・Amazon Linux・Alpine・Fedoraの公式コンテナイメージ10種で取得した実際の出力をもとに、OSとカーネルの確認コマンド、更新後に再起動を待っているカーネルの見分け方、コンテナやWSL2で結果が食い違う理由、複数台の版を集める実装、サポート期限の判定までを扱います。

まとめ：LinuxのOS版とカーネル版の確認コマンド

ディストリビューションの版は/etc/os-release、カーネルの版はuname -rで確かめてください。スクリプトで判定するなら、各社のreleaseファイルやlsb_releaseではなく、os-releaseのIDとVERSION_IDを読む実装が一番壊れにくい方法です。

• OSの版：cat /etc/os-release。実測した10イメージの全てに存在し、VERSION_IDで版が分かる
• 点リリースまで見る：UbuntuはPRETTY_NAMEやVERSION（24.04.5など）、Debianは/etc/debian_version（13.7など）。Debian 13はos-releaseのDEBIAN_VERSION_FULLにも出る
• カーネルの版：uname -r。更新後に再起動していなければ、導入済みの新しいカーネルとは番号が違う
• 再起動待ちの判定：Ubuntuはneedrestart -b -k、RHEL系はneeds-restarting -rで分かる
• コンテナ内：uname -rはホストのカーネルを返す。イメージの版はos-releaseで見る
• 期限の判定：OSの期限は配布元の公式表で見る。kernel.orgのLTS表でRHELやUbuntuの標準カーネルの寿命を判定しない

Linuxのバージョン確認で最初に分けるOSの版とカーネルの版の違い

「Linuxのバージョン」という言葉は、2つのものを指します。1つはUbuntu 24.04やRHEL 9といったディストリビューションの版、もう1つはLinuxカーネル自体の版です。ディストリビューションはカーネルにパッケージ管理やライブラリを組み合わせた製品で、その全体像はLinuxの仕組みとディストリビューションを扱った解説で整理しています。

ディストリビューションの版とカーネル番号が一致しない理由と具体例

ディストリビューションは、kernel.orgのカーネルから系列を選んで、自社で修正を当て続けます。RHEL系はOSの版ごとに1つの系列を保守し、Ubuntuはカーネルのライフサイクルのとおり、リリース時のGAカーネルに加えて、後の版の系列を移植したHWEカーネルも同じOS版で選べます。版の数字がずれるのはこのためです。次の表は、2026年10月27日に各ディストリビューションの公式リポジトリから取得できた標準カーネルの番号です。

これらはkernel.orgの最新番号（後述）とは別に、配布元が保守する番号です。RHEL 9系の5.14はkernel.orgの長期サポート版（LTS）にも含まれない系列ですが、Red Hatが修正を当てて保守しています。番号だけを見て「古いカーネルだ」と判断するのは誤りです。カーネルがOSの中で何を受け持つかは、カーネルの役割と仕組みを実装目線でまとめた記事が前提知識になります。

どちらの版を見るべきかをパッケージ・脆弱性・ドライバの用途別に判断

用途が決まれば、見る版も決まります。

• パッケージの導入手順を選ぶ：OSの版。aptかdnfか、どのリポジトリを足すかはディストリビューションと版で決まる
• ベンダーの脆弱性情報と照合する：OSの版とパッケージの版。RHELやUbuntuの勧告はカーネルも含めてパッケージ単位で出る
• ドライバやeBPFなど機能の有無を確かめる：カーネルの版。ただしディストリビューションは新機能を古い系列へ移植することがある

実務ではOSの版を主に、カーネルの版を補助に使う場面が大半です。ドライバの動作要件を確かめる場合も、カーネル番号に加えて、配布元の対応表や必要な機能・設定を確認してください。

LinuxのOSを確認するコマンド一覧と出力から分かる項目の早見表

OSを確認するコマンドは複数ありますが、分かる情報と使える環境がそれぞれ違います。「使えなかった環境」の列は、10種のコンテナイメージで実際に打った結果です。

uname -sは、LinuxならLinux、FreeBSDならFreeBSDと、カーネルの種類を返します。UNIX系が混在する環境では、まずこれで「そもそもLinuxか」を確かめてください。LinuxとBSDの違いはFreeBSDとLinuxの違いを実装目線で比べた記事で整理しています。バージョン確認以外の日常的なコマンドは、用途別に引けるLinuxコマンド一覧とあわせて手元に置くと迷いません。

ディストリビューションが分からないサーバーで上から順に試す確認手順

引き継いだばかりのサーバーで、どのディストリビューションかも分からないことがあります。その場合は、仕様で場所が決まっているファイルから順に読み、無ければ調査用の一覧に切り替えます。

# 1. 仕様で決まった2か所を優先順に読む
for f in /etc/os-release /usr/lib/os-release; do
  [ -r "$f" ] && { cat "$f"; break; }
done
# 2. 読めなかったときだけ、各社のrelease系ファイルを一覧にする
[ -r "$f" ] || ls -1 /etc/*release /etc/*version 2>/dev/null
# 3. カーネルの種類・版・アーキテクチャは常に取る
uname -s -r -m

1の段階で読めないのは、古いサーバーや組み込み機器のほか、空のscratchイメージにアプリだけを置いた最小コンテナ、権限の設定が崩れた環境などです。2で/etc/redhat-releaseや/etc/alpine-releaseのようなファイル名が出れば、系統の見当が付きます。ただし/etc/debian_versionはUbuntuにもあるので、これだけでDebianと決めないでください（理由は後述）。

ログイン前に出るissueの表示をOSの版の根拠にしない理由

コンソールのログイン画面に出る「Ubuntu 24.04 LTS」のような文字列は、/etc/issueの中身です。issue(5)のマニュアルは、このファイルを「ログインプロンプトの前に表示するメッセージまたはシステム識別情報」と定めています。中身は案内文にすぎず、管理者が警告文に書き換えることも珍しくありません。版の判定や手順書にはos-releaseを使ってください。

os-releaseファイルでディストリビューションの版を確認する手順

os-release(5)の仕様は、/etc/os-releaseを優先し、無いときだけ/usr/lib/os-releaseを読み、両方を混ぜないよう求めています。中身はシェル変数と同じキー=値の書式です。実測した10イメージでは、全てで/etc/os-releaseが../usr/lib/os-releaseへのシンボリックリンクでした。

$ docker run --rm ubuntu:24.04 cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.5 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
...（以下URL類は省略）

主要ディストリビューション10種のos-release実測値

2026年10月27日に公式コンテナイメージでcat /etc/os-releaseを実行し、判定に使う項目だけを抜き出した表です。タグが指すイメージは更新されるので、後日取得すると点リリースの番号は変わります。値の引用符の有無はディストリビューションによって違います。

VERSION_IDの粒度がそろっていない点に注意してください。RHEL系は9.8のようにマイナー版まで、Alpineは3.22.7のようにパッチ番号まで入りますが、Ubuntuはリリースの年と月（24.04＝2024年4月）、Debianはメジャー版の番号（13）だけです。Amazon Linux 2023は2023で固定され、どの更新日の版かは、表の項目の中ではPRETTY_NAMEの末尾（20260930）にだけ出ます。/etc/system-releaseにも同じ文字列が入っていました。Rocky LinuxのイメージはDocker Hubのrockylinux/rockylinux:9で取得しました。

ID・VERSION_ID・ID_LIKEの意味とLinuxが何系かの見分け方

画面で読むならPRETTY_NAME、プログラムで判定するならIDとVERSION_IDを使います。仕様では、IDは版を含まない小文字の識別子、VERSION_IDはOS名やコードネームを含まない版の文字列と定義されています。PRETTY_NAMEに版番号を入れるかどうかはOS側の判断に任されているので、PRETTY_NAMEを文字列解析する実装は避けてください。なお、ID以外の項目は仕様上すべて任意で、ローリングリリースのOSなどではVERSION_IDが無いこともあります。空なら取得失敗ではなく「書かれていない」と扱ってください。

「このLinuxは何系か」を知りたいときはID_LIKEを見ます。パッケージ方式やAPIが近いOSの識別子を、近い順に空白区切りで並べる項目です。上の表のとおり、Ubuntuはdebian、Rocky・AlmaLinuxはrhel centos fedoraと書き、Amazon Linux 2023はfedoraだけを書きます。Debian・Fedora・Alpineのように系統の親そのものにはID_LIKEが無いので、判定はIDとID_LIKEを合わせて行う必要があります（実装例は後の章）。

点リリースの番号はVERSION_IDに出ないためUbuntuとDebianで見る場所

Ubuntu 24.04.5やDebian 13.7のような点リリースの番号は、どちらもVERSION_IDには出ません。見る場所はディストリビューションごとに違います。

• Ubuntu：os-releaseのPRETTY_NAMEかVERSION（24.04.5 LTS）
• Debian：/etc/debian_versionの中身（13.7、12.15）。Debian 13はos-releaseに独自項目DEBIAN_VERSION_FULL=13.7もあり、Debian 12には無い

落とし穴は、Ubuntuにも/etc/debian_versionがある点です。実測では、Ubuntu 26.04でforky/sid、24.04でtrixie/sid、22.04でbookworm/sidと、土台にしたDebianの開発版の名前が入っていました。Ubuntuの版とは関係が無いので、「debian_versionがあるからDebian」「中身がtrixieだからDebian 13」という判定は誤りになります。

lsb_releaseや各社のreleaseファイルを後回しにする理由

古い手順書にはcat /etc/redhat-releaseやlsb_release -aがよく出てきます。前者はRHEL系にしか無く、後者は実測した10イメージのどれにも入っていませんでした。Ubuntu 24.04のコンテナでapt install lsb-releaseを実行すると、次のように表示されます。

$ lsb_release -a
Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.5 LTS
Release:	24.04
Codename:	noble

Debian 13のlsb-releaseパッケージの説明には、LSBパッケージへの依存をやめて/etc/os-releaseの情報を使う最小実装だと書かれています。つまり、同じ情報の出どころはos-releaseです。パッケージを足してまで使う理由は薄いので、手順書と自動化にはos-releaseだけを書くと決めておくと、ディストリビューションが増えても手順が分岐しません。ファイル名が分からない環境の調査でgrep -H "" /etc/*releaseを使う方法は、grepコマンドのオプションとログ検索を扱った記事で触れています。

Linuxカーネルのバージョンを確認するコマンドと再起動待ちの見分け方

カーネルの版はuname -rで確認します。uname(1)のマニュアルによると、-rがカーネルのリリース番号、-vがカーネルのビルド情報、-mがマシンのハードウェア名で、-aは不明な項目を除いて全てを並べます。次はUbuntu 24.04.4の仮想マシンで取得した出力です。

$ uname -r
6.8.0-117-generic
$ uname -m
x86_64
$ cat /proc/version
Linux version 6.8.0-117-generic (buildd@lcy02-amd64-102) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #117-Ubuntu SMP PREEMPT_DYNAMIC Tue May  5 19:26:24 UTC 2026

/proc/versionはproc_version(5)で定義された、カーネル自身が返す文字列です。ビルドに使ったコンパイラの版とビルド日時まで分かります。Ubuntu 26.04ではunameがRust製のuutils coreutils 0.10.0に置き換わっていましたが（uname --versionで確認）、-rと-mの出力形式は同じでした。

uname -rの番号の読み方とディストリ独自の後置部分の意味

6.8.0-117-genericのうち、先頭の6.8.0が元にしたカーネルの系列、ハイフン以降がディストリビューション側のビルド番号と種類です。Rocky Linux 9.8なら5.14.0-687.60.1.el9_8.x86_64、AlmaLinux 10.2なら6.12.0-211.68.1.el10_2.x86_64、Amazon Linux 2023なら6.1.188-233.386.amzn2023.x86_64のように、末尾の記号で配布元とOSの版が分かります。

脆弱性の修正が入ったかどうかは、先頭の系列だけでは分かりません。6.8.0-147.147のような完全なパッケージ版を配布元の勧告と照合してください。UbuntuでLivepatchを使っている場合は、再起動なしで稼働中のカーネルに当たった修正があるので、Livepatchの状態確認の手順にあるcanonical-livepatch statusで適用状態も確かめます。同じ6.8.0でも、2026年10月27日にUbuntu 24.04のリポジトリにあった最新は-147で、-117のまま動いているカーネルはそれより前のビルドです。

hostnamectlでOSとカーネルとアーキテクチャを1回で表示する方法

systemdで動くサーバーなら、hostnamectlをサブコマンド無しで実行するだけで、OSの名前、カーネル、アーキテクチャ、仮想化の種類が並びます。systemd 255のUbuntu 24.04.4仮想マシンでの出力（一部抜粋）です。

$ hostnamectl
 Static hostname: colima
  Virtualization: apple
Operating System: Ubuntu 24.04.4 LTS
          Kernel: Linux 6.8.0-117-generic
    Architecture: x86-64
 Hardware Vendor: Apple Inc.

Architectureの表記はx86-64とハイフンで、uname -mのx86_64とは違います。スクリプトで比較するなら、どちらのコマンドの値かをそろえてください。--json=prettyを付けるとKernelReleaseやOperatingSystemPrettyNameをキーにしたJSONで出るので、監視ツールへ渡すときに扱いやすくなります。コンテナの中ではsystemdが動いていないため、AlmaLinux 10のイメージでは「System has not been booted with systemd as init system」で失敗しました。systemd自体の役割はsystemdの役割を解説した記事を参照してください。

Ubuntu・Debianで導入済みカーネルと稼働中カーネルの差を確かめる手順

apt upgradeで新しいカーネルを入れても、再起動するまでuname -rは古い番号のままです。「カーネルを確認したのに番号が変わらない」というときは、導入済みのカーネルと稼働中のカーネルを並べて比べます。Ubuntu 24.04のコンテナにlinux-image-virtualとneedrestartを入れ、更新前後の差を擬似的に作った例です。コンテナでは稼働中のカーネルがホスト（ここではUbuntu 24.04.4の仮想マシン）のものになり、コンテナ内に入れたカーネルは起動に使われません。コマンドの使い方と出力の読み方を示すための例として見てください。

$ uname -r                                  # 稼働中
6.8.0-117-generic
$ dpkg -l 'linux-image-*' | awk '/^ii/{print $2, $3}'   # 導入済み
linux-image-6.8.0-147-generic 6.8.0-147.147
linux-image-virtual 6.8.0-147.147
$ cat /var/run/reboot-required
*** System restart required ***
$ sudo needrestart -b -k
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.8.0-117-generic
NEEDRESTART-KEXP: 6.8.0-147-generic
NEEDRESTART-KSTA: 3

/var/run/reboot-requiredは、update-notifier-commonが入っている環境でカーネル導入時に作られる目印です。より確実なのはneedrestart -bの機械向け出力で、KCURが稼働中、KEXPが導入済みのうち起動されるはずのカーネルです。needrestartのREADMEは、KSTAの値を0＝判定できない、1＝更新待ちなし、2＝ABI互換の更新待ち、3＝版の更新待ち、と定めています。監視でKSTAが2以上なら再起動の計画を立ててください。

RHEL系でrpm -q kernelとneeds-restarting -rを使う手順

Rocky Linux・AlmaLinux・RHELでは、導入済みのカーネルをrpm -q kernel-coreで一覧にし、uname -rと見比べます。--lastを付けると導入日時の新しい順に並びます。ただし、最後に導入したものが最高バージョンとは限らないため、版番号も確認してください。Rocky Linux 9.8のコンテナにkernel-coreとdnf-utilsを入れて取った出力で、上のUbuntuと同じく稼働中のカーネルはホストのものです。

$ rpm -q --last kernel-core
kernel-core-5.14.0-687.60.1.el9_8.x86_64      Tue Oct 27 00:05:33 2026
$ needs-restarting -r; echo "rc=$?"
Core libraries or services have been updated since boot-up:
  * dbus
  * dbus-broker
  * systemd

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943
rc=1

needs-restartingの説明のとおり、-rは再起動が必要なら終了コード1、不要なら0を返します。判定は起動後に更新されたパッケージ名で行い、Rocky Linux 9.8の実装（needs_restarting.pyのNEED_REBOOT）では、kernel・kernel-rt・glibc・linux-firmware・systemd・dbus系・microcode_ctlが対象でした。kernel-coreだけを入れた上の例でカーネルが理由に挙がらず、systemdとdbusで再起動要と出たのはこのためです。通常のdnf updateではkernelパッケージも一緒に更新されるので、監視スクリプトでは終了コードで分岐させてください。

Linuxカーネルの最新バージョンとkernel.orgのLTS系列

「Linuxの最新バージョン」と聞かれたときに答える番号は、kernel.orgの系列表で決まります。2026年10月27日に取得したreleases.jsonの値です。

保守終了の予定はkernel.orgのリリース一覧の表によります。ただし、この番号が意味を持つのはカーネルを自分でビルドする場合や、系列をそのまま使う組み込み機器の場合です。ディストリビューションの標準カーネルは配布元が保守するので、手元のuname -rがkernel.orgの最新より古くても、それだけで更新の必要は判断できません。6系の後半で何が変わったかは、Linuxカーネル6.19の新機能とサポート終了を扱った記事にまとめています。

コンテナとWSL2でLinuxのバージョン確認結果が食い違う原因と対処

開発環境でよく起きるのが、「os-releaseはUbuntuなのに、カーネル番号が見慣れない」という食い違いです。原因は、コンテナとWSL2のどちらも、中のディストリビューションと外のカーネルが別物である点にあります。

Dockerコンテナ内のunameがホストのカーネル番号を返す仕組み

コンテナは仮想マシンと違い、ホストのカーネルを共有する仕組みです。そのためコンテナ内でuname -rを打つと、イメージの中身に関係なくホストのカーネルの番号が返ります。macOS上のColima（Ubuntu 24.04の仮想マシン）で試すと、Rocky LinuxやAlpineのイメージでも全て同じ番号でした。

$ for img in ubuntu:24.04 rockylinux/rockylinux:9 alpine:3.22; do
    docker run --rm "$img" sh -c '. /etc/os-release; echo "$ID $VERSION_ID $(uname -r)"'
  done
ubuntu 24.04 6.8.0-117-generic
rocky 9.8 6.8.0-117-generic
alpine 3.22.7 6.8.0-117-generic

Rocky Linux 9の標準カーネルは5.14系なのに、コンテナの中では6.8が返る、ということです。Mac上のDockerがどの仮想マシンで動くかはColimaの導入手順と設定を扱った記事で触れています。コンテナの中からホストのOSを知りたい場合、os-release(5)は、実行環境がホストのos-releaseを/run/host/os-releaseとして渡してよいと定めていますが、Dockerの既定では置かれません。

WSL2のmicrosoft-standard表記とホスト側OS情報の見分け方

WSL2では、Microsoftが配布する専用カーネルの上で各ディストリビューションが動きます。WSL2-Linux-Kernelのリリース一覧で2026年10月27日にLatestと表示されていたのは6.18.54.1で、公式のビルド設定ではリリース文字列の末尾に-microsoft-standard-WSL2が付きます。インストールしたUbuntuやFedoraの標準カーネルではありません。WSL1との構造の違いはWSL2の仕組みとWSL1との違いをまとめた記事で扱っています。

WSL2のカーネルはWindows側のwsl --updateで更新され、中のディストリビューションでapt upgradeをしても変わりません。カーネル起因の不具合を調べるときは、Windows側のwsl --versionでカーネルの版を確かめるのが先です。

systemd-detect-virtによる仮想マシン・コンテナ・WSLの判定

版の食い違いを見たら、まず「自分がどこで動いているか」を確かめると原因が早く絞れます。systemd-detect-virtは仮想化の技術を短い名前で表示し、何も検出しなければnoneを出して0以外の終了コードを返します。Colimaの仮想マシンでの結果です。

$ systemd-detect-virt
apple
$ systemd-detect-virt --container || echo "not in container"
none
not in container

識別子は、Dockerがdocker、Podmanがpodman、WSLがwsl、KVMがkvm、EC2のNitroがamazonです。入れ子の環境では原則として最も内側を返し、--vmを付けると仮想マシンだけを見ます。コンテナ内でだけuname -rの値を「ホストのカーネル」として記録する、といった使い分けをスクリプトに組み込めます。軽量なコンテナイメージにはsystemdが入っていないので、その場合はホストや仮想マシンの側で実行してください。

シェルスクリプト・SSH・Python・Ansibleで複数サーバーのバージョンを集める実装

サーバーが数台を超えると、1台ずつログインして確かめる方法は続きません。版の確認を自動化する型を、規模の小さい順に示します。

os-releaseを読み込みID_LIKEで分岐するシェルスクリプトの例

os-releaseの仕様にある読み込み方をもとに、OS・カーネル・アーキテクチャを1行で出し、系統で分岐するスクリプトです。os-releaseをシェルで読み込めるのは、書式がシェル変数と互換だからです。

#!/bin/sh
# OSとカーネルの版を1行で出し、apt系かdnf系かを判定する
if [ -e /etc/os-release ]; then f=/etc/os-release; else f=/usr/lib/os-release; fi
. "$f"
echo "os=${ID} ${VERSION_ID} kernel=$(uname -r) arch=$(uname -m)"
case " ${ID} ${ID_LIKE:-} " in
  *" debian "*) echo "family=debian" ;;
  *" rhel "*|*" fedora "*) echo "family=rhel" ;;
  *) echo "family=other" ;;
esac

空白で囲んでから比較しているのは、ID_LIKE="rhel centos fedora"のような複数値の中から単語単位で探すためです。ID自体も判定に含めているので、ID_LIKEを持たないDebian本体やFedora本体も正しく分かれます。7種のイメージで実行すると、Ubuntu・Debianがfamily=debian、Rocky・AlmaLinux・Fedora・Amazon Linux 2023がfamily=rhel、Alpineがfamily=otherになりました。Amazon Linux 2023はID_LIKEがfedoraだけなので、「RHEL互換」ではなく「dnfを使う系統」として扱われる点に注意してください。Alpineのbusybox shでもこのスクリプトはそのまま動きました。

SSHで数台のOSとカーネルの版を1行ずつ集めるループの書き方

Ansibleを入れるほどでもない数台なら、手元からSSHでコマンドを流すだけで一覧が作れます。公開鍵認証が通っている前提で、BatchMode=yesを付けてパスワード待ちで止まらないようにしています。鍵の設定はSSH接続の仕組みと公開鍵認証の設定を扱った記事を参照してください。

for h in web01 web02 db01; do
  printf '%s ' "$h"
  ssh -o BatchMode=yes "$h" '. /etc/os-release; echo "$ID $VERSION_ID $(uname -r) $(uname -m)"'
done

リモート側のコマンドを単引用符で囲んでいるのは、$IDや$(uname -r)を手元ではなく接続先で展開させるためです。出力はホスト名・ID・版・カーネル・アーキテクチャの順に空白区切りで並ぶので、そのまま表計算ソフトに貼れます。

Pythonのplatformモジュールでos-releaseを辞書として読む実装例

監視や棚卸しのツールをPythonで書くなら、os-releaseを自前で解析する必要はありません。Python公式のplatformモジュールには3.10でplatform.freedesktop_os_release()が追加され、/etc/os-release、無ければ/usr/lib/os-releaseを読んで辞書で返します。どちらも読めないときはOSErrorを送出します。

import platform

info = platform.freedesktop_os_release()
ids = [info["ID"]] + info.get("ID_LIKE", "").split()
print(info["ID"], info.get("VERSION_ID", ""), platform.release(), platform.machine())
print("family=rhel" if "rhel" in ids or "fedora" in ids else "family=debian" if "debian" in ids else "family=other")

python:3.12-slimのイメージ（中身はDebian 13）で実行すると、1行目はdebian 13 6.8.0-117-generic x86_64、2行目はfamily=debianでした。DebianにはID_LIKEが無いので、info["ID_LIKE"]と添字で書くとKeyErrorになります。get()で既定値を渡しているのはそのためです。

Ansibleのsetupモジュールで全台の版とカーネルを一覧化する手順

構成管理にAnsibleを使っているなら、新しいスクリプトは要りません。ansible.builtin.setupモジュールのfilterは、シェルと同じワイルドカードで返す項目を絞れます。

$ ansible all -m ansible.builtin.setup -a 'filter=ansible_distribution*'
$ ansible all -m ansible.builtin.setup -a 'filter=ansible_kernel'

Playbookの中で条件分岐に使うときは、Ansibleのfacts解説のとおりansible_facts['distribution']・ansible_facts['distribution_major_version']・ansible_facts['kernel']のように、ansible_接頭辞を外して参照します。結果を台帳に取り込めば手作業の転記を減らせます。応答しなかったホストは結果に出ないので、台帳の台数と突き合わせて取得漏れを確かめてください。

確認した版からサポート期限を判定し更新計画へつなげる判断基準

版を確かめる目的の多くは、「このサーバーはいつまで修正を受けられるか」を知ることです。期限は必ず配布元の公式表で照合してください。

主要ディストリビューションの標準サポート終了日の早見表

2026年10月27日時点で、各配布元の公式表から取った期限です。Ubuntuはリリースサイクルの公式ページ、RHELはRed Hatの製品ライフサイクルAPI、DebianはDebianのリリース一覧、CentOSはCentOSのダウンロードページによります。

表に無いもののうち、CentOS Linux 7は2024年6月30日、Amazon Linux 2は2026年6月30日にサポートが終わっています。os-releaseのIDがcentosでVERSION_IDが7、またはamznでVERSION_IDが2のサーバーが見つかったら、更新の対象です。移行先の選び方はCentOS終了後の後継OSへの移行判断を扱った記事とAmazon Linux 2からAL2023へ移す手順の記事にまとめています。Ubuntu 26.04への更新で変わる点はUbuntu 26.04 LTSの新機能とアップグレードの記事が詳しいです。

os-releaseには期限をSUPPORT_END=YYYY-MM-DDで書く項目も定義されています。実測した10イメージでは、Rocky Linux 9が2032-05-31、AlmaLinux 10が2035-06-01、Amazon Linux 2023が2029-06-30、Fedora 43が2026-12-02を書いていた一方、Ubuntu・Debian・Alpineには項目自体がありませんでした。grep SUPPORT_END /etc/os-releaseで値が出ればそれを目安にし、出なければ上の公式表を見に行ってください。

期限切れのOSを放置してよい場面と更新作業を外部へ任せるべき条件

延長保守まで終わったOSを残してよいのは、外部・社内ネットワークから隔離し、認証情報やホストとの共有領域を持たせず、用途と廃棄日を決めた検証用の仮想マシンに限る、というのがこの記事の推奨です。この条件を満たすなら、更新するより作り直すほうが手間は小さく済みます。

一方、外部に公開しているWebサーバーや、個人情報を扱う業務システムの土台で標準保守が切れているなら、更新計画を先送りしてはいけません。Debian 12のように標準保守が終わってLTSに移った版は、修正の対象パッケージが絞られます。bookwormのリリース情報によるとLTSの対象はi386・amd64・armhf・arm64・ppc64elだけで、それ以外のアーキテクチャは保守が終わっています。残り期間は移行の準備に充ててください。同じ台帳の中にRHEL系とUbuntu系が混ざり、アプリの動作確認まで含めた移行が必要な場合は、社内の担当者1人で抱えると止まりがちです。OSの更新とアプリの移行を一体で計画し、クラウド上に作り直す選択肢まで比べたいときは、一創のインフラ構築（AWS・Google Cloud・Azure）で、現行の版の棚卸しから移行後の保守まで相談できます。

よくある質問

LinuxのOSを確認するコマンドは何を使えばよいですか？

ディストリビューションの名前と版はcat /etc/os-release、カーネルの版はuname -rで確認します。systemdが動いているサーバーならhostnamectlで、OSの名前、カーネルの版、アーキテクチャがまとめて表示されます。コンテナのようにsystemdが無い環境では、cat /etc/os-release; uname -rと2つを続けて打ってください。

CentOSやAlmaLinuxのバージョンはどう確認しますか？

cat /etc/os-releaseでVERSION_IDを見てください。RHEL系はAlmaLinuxの10.2のようにマイナー版まで入ります。/etc/redhat-releaseや/etc/almalinux-releaseでも1行で表示できますが、ディストリビューションごとにファイル名が違うので、手順書にはos-releaseを書くほうが後から困りません。CentOS Linux 7・8はサポートが終わっているので、表示されたら移行を検討してください。

uname -rとuname -aの違いは何ですか？

uname -rはカーネルのリリース番号だけを表示します。uname -aはカーネル名、ホスト名、リリース番号、ビルド情報、アーキテクチャなどを1行に並べます。スクリプトで版を比較するなら、余分な情報が無い-rを使ってください。どちらもディストリビューションの版は表示しません。

Linuxの最新バージョンはいくつですか？

カーネルは2026年10月27日時点でkernel.orgのmainlineが7.3です（系列表は本文のkernel.orgの章）。OSの最新はそれとは別の番号で、Ubuntuの最新LTSが26.04、AlmaLinuxが10.2、Debianが13（13.7）です。どれも更新が続くので、最新の番号は各公式ページで確かめてください。

FreeBSDのバージョンはどう確認しますか？

FreeBSDではfreebsd-versionを使います。freebsd-version(1)のマニュアルによると、-kがインストール済みカーネル、-uがインストール済みユーザーランド、-rが稼働中カーネルの版とパッチレベルです。-kと-rが違えば、更新後に再起動していない状態です。uname -rも使えますが、ユーザーランドだけを更新したときの版は分かりません。

関連記事

• Linuxコマンド一覧｜用途別早見表48選とUbuntu 26.04での変更点
• Ubuntu 26.04 LTS（Resolute Raccoon）とは｜リリース日・新機能と24.04からのアップグレード【26.04.1対応】
• CentOSとは？RHEL互換OSの終了とCentOS Stream・後継OSへの移行判断を実装目線で解説【2026年版】
• Amazon Linux 2のサポート終了後の移行手順｜AL2023へ移す棚卸しと詰まる箇所
• Linuxカーネル6.19の新機能とサポート終了｜リリース日・6.19.14・7.0以降への移行