Linuxカーネル最新版のトピック｜利用者が知っておきたい変更点

Linuxカーネルは年に3〜4回のペースでメジャーリリースを重ねており、2024年末にリリースされた6.12が現行のLTS（Long Term Support）カーネルとして多くの配布環境に採用されています。「安定しているから触らない」という判断が許される時代は終わりつつあり、スケジューラの刷新やセキュリティ関連の構造変化はアプリケーション挙動や運用ツールの動作にも影響を及ぼすようになりました。本記事では6.12 LTSを中心軸に、6.13〜6.15系で加わった主な変更を俯瞰し、現場の判断に使える視点を整理します。

6.12 LTSが節目となる理由：三つの構造的変化

Linuxカーネルにおいて、6.12は単なるバグフィックスリリースではありません。長年にわたって議論されてきた複数の大型機能が一斉にマージされた「節目のリリース」です。運用担当者が特に把握しておくべき変化は次の三点です。

一点目は、デフォルトスケジューラの交代です。カーネル5.x系まで長らく使われてきたCFS（Completely Fair Scheduler）に代わり、EEVDF（Earliest Eligible Virtual Deadline First）が正式にデフォルトへ昇格しました。EEVDFはタスクへのCPU割り当てをデッドラインベースで管理するアルゴリズムで、高負荷時のレイテンシ特性がCFSより安定する傾向があります。Webサーバーやデータベースのような「応答時間のばらつき」を重視するワークロードでは、チューニング不要で恩恵を受けられるケースが報告されています。

二点目は、sched_ext（BPFベースのスケジューラ拡張機構）のマージです。eBPFプログラムでスケジューラのポリシーをユーザー空間から差し替えられるこの仕組みは、カーネルを再コンパイルせずにスケジューラを実験・適用できる点で、クラウド事業者や研究用途で注目されています。本番環境への即時導入を勧めるものではありませんが、将来的に「ワークロード特性ごとにスケジューラを切り替える」という運用が現実になる可能性を示しています。

三点目は、PREEMPT_RT（リアルタイムプリエンプション）のメインライン統合です。長年パッチセットとして別管理されてきたこの機能が公式ツリーに入ったことで、産業用・組み込み用途での採用障壁が大幅に下がりました。サーバー運用では直接関係しない場合が多いですが、IoTゲートウェイやエッジ環境でLinuxを使う現場には大きな意味を持ちます。

セキュリティ周辺の変化：名前空間・io_uring・Rustの進行

6.12以降のカーネル系列では、セキュリティに関わる変更も複数の層で進んでいます。

まずio_uringの扱いに注意が必要です。高性能な非同期I/Oインターフェースとして普及したio_uringですが、過去に複数の権限昇格脆弱性が発見された経緯から、一部のエンタープライズ向けカーネル（Red Hat系など）ではデフォルトで制限された状態で提供されています。6.13以降ではio_uringに対するLSM（Linux Security Module）フックが強化されており、SELinuxやAppArmorとの連携でより細かい制御が可能になりました。io_uringを活用するアプリケーション（一部のデータベースやファイルサーバーなど）を運用している環境では、カーネルアップデート後にパフォーマンスや動作の変化が生じることがあるため、事前のステージング検証が推奨されます。

次に、Rustドライバーの統合が着実に進んでいます。6.x系では一部のネットワークドライバーとファイルシステム層の補助コンポーネントがRustで実装されはじめており、メモリ安全性に由来するバグクラスの削減が期待されています。現時点では主要なドライバーの置き換えには至っていませんが、将来のカーネルにおいてRustコンポーネントが前提となる流れは不可逆と見るべきです。カーネルビルドをカスタマイズする運用環境では、ビルドツールチェーンへのRustコンパイラ追加が将来的に必要になることを念頭に置いておくとよいでしょう。

ユーザー名前空間（user namespaces）の制限強化も続いています。非特権ユーザーによる名前空間作成を制限するカーネルパラメータ（kernel.unprivileged_userns_clone）はDebianやUbuntuのデフォルト設定で制限方向に傾いており、コンテナランタイムやChrome系ブラウザの一部機能に影響する場合があります。アップデート後に予期しない動作変化を経験した場合は、この設定値を確認する価値があります。

ストレージとネットワーク：実務に近い変更点

ストレージ層では、Btrfsの改善が継続しています。6.12以降ではRAID56の信頼性向上が図られており、書き込みホールへの対処が以前より堅固になりました。とはいえBtrfs RAID56は依然として「十分な検証なしに本番採用するには早い」という評価が根強く残っています。データの冗長性が重要な環境では、RAID構成の変更前に現在のカーネルバージョンとBtrfsのリリースノートを照合することが欠かせません。

ext4については大きな破壊的変更はないものの、フォールトインジェクション関連のデバッグ機能が拡充されており、障害再現テストの精度が向上しています。XFSも安定性改善が中心で、6.13以降ではオンラインチェック機能（xfs_scrub）の信頼性が高まりました。

ネットワーク層では、Multi-Path TCP（MPTCP）の実装がさらに成熟し、6.14以降ではip mptcpサブコマンドを通じた設定インターフェースが整備されました。また、eBPFベースのネットワークフィルタリングはTC（Traffic Control）層との統合が進み、XDP（eXpress Data Path）を使った高速パス処理の適用範囲が広がっています。帯域制御やロードバランサーをソフトウェアで実装している環境では、新しいeBPFフックを利用することでカーネルバイパスに近いパフォーマンスを得られる可能性があります。

2026年現在の配布環境でカーネルを確認する手順

実際の運用環境でカーネルの状況を把握するには、まず現在の稼働バージョンを確認することから始まります。uname -rでカーネルリリース番号が表示され、cat /proc/versionでビルド情報の詳細を参照できます。

主要ディストリビューションの2026年時点での状況を整理すると、Ubuntu 24.04 LTS（Noble）は6.8系を基盤としつつHWE（Hardware Enablement）カーネルで6.11以降を提供しています。Debian 13（Trixie）は6.12ベースで出荷される見込みです。RHEL 9系はアップストリームの6.x系とは異なる独自バックポートカーネルを使用しており、バージョン番号だけで機能の有無を判断できない点に注意が必要です。Arch LinuxやFedoraのような転がりの速いディストリビューションでは、6.14〜6.15系が既に標準となっています。

カーネルのアップデートを計画する際は、利用しているカーネルモジュール（特にDKMS管理のサードパーティドライバー）の対応状況を先に確認するのが定石です。dkms statusコマンドで登録済みモジュールの一覧と状態を確認でき、アップデート後にモジュールが再ビルドされていることをdkms autoinstallで保証できます。

切り戻し判断と運用上の注意点

カーネルアップデート後に問題が発生した場合、GRUBの起動メニューから前のカーネルを選択することで即座に切り戻しが可能です。多くのディストリビューションは旧バージョンのカーネルを一定期間保持しており、dpkg --list | grep linux-image（Debian系）やrpm -qa kernel（Red Hat系）で現在インストールされているカーネルを確認できます。

本番環境へのカーネルアップデートを安全に進めるうえでよく使われる手順としては、まずステージング環境で新カーネルの動作検証を行い、アプリケーションのベンチマーク結果と主要ログを比較することが挙げられます。特にEEVDFへの切り替え前後ではスケジューラ由来のレイテンシ変化が生じる可能性があり、APMツールやsarのデータを比較基準として持っておくと判断がしやすくなります。

また、カーネルパラメータの互換性にも注意が必要です。/etc/sysctl.confや/etc/sysctl.d/配下に記述したパラメータが、新カーネルで廃止・改名されていることがあります。sysctl -a 2>&1 | grep "No such"で無効なパラメータを洗い出す確認を、アップデート後の手順に組み込んでおくと見落としを防げます。

カーネルの変化は一度に追いかけるものではなく、自分の環境に関係するサブシステム（スケジューラ・ネットワーク・ストレージ・セキュリティ）ごとにリリースノートを定期的に確認する習慣が、長期的な運用品質の維持につながります。kernel.orgのChangeslogと各ディストリビューションのリリースノートを組み合わせることで、アップストリームの変化が自分の環境にどう反映されるかを把握しやすくなります。