LTSカーネルのサポート期間をめぐる最新の議論まとめ

LTSカーネルの「長期」はどれくらいを意味するのか

Linuxカーネルには通常の安定版（Stable）とは別に、長期サポート版（LTS: Long Term Support）が存在します。LTS指定を受けたカーネルは、セキュリティ修正とバグ修正のバックポートが通常よりも長い期間にわたって提供され、ディストリビューション・組み込み機器・Androidデバイスの基盤として広く活用されてきました。

2011年ごろから、LTSカーネルのサポート期間は段階的に延伸されてきました。当初は2年前後だったものが、2017年ごろには6年超に設定される例も登場し、4.14・4.19・5.4・5.10といったカーネルがそれぞれ約6年間のサポートを受けてきたことで、業界には「LTS＝6年」というイメージが定着していきました。

ところが、このサポート期間の長さをめぐって、2022年末ごろからLinuxカーネルの主要メンテナであるGreg Kroah-Hartman（以下GKH）が問題提起を行い、コミュニティ内で活発な議論が続いています。その内容は、単なる技術論にとどまらず、オープンソースの持続可能性や下流との責任分担という本質的な問いにまで及んでいます。

「2年で十分」── 上流メンテナ側の問題提起

GKHがLKML（Linux Kernel Mailing List）や各種カンファレンスで繰り返し示してきた論点は、主に二点に集約されます。

• 6年間のバックポート作業は保守コストが高く、少数のメンテナに過大な負荷をかけている
• 古いLTSカーネルを実際にテストしているユーザーや組織はきわめて少なく、品質保証が形骸化しつつある

GKHは「LTSを6年に延ばしたのは実験だったが、実際にはうまくいっていない」と明言し、デフォルトのLTSサポート期間を2年に短縮することを提案しました。根拠として特に強調されたのが、古いLTSカーネルのリリース候補（rc）テストに参加するテスターの数が極端に少ない現状です。「誰も実際に使っていないならば、長期間メンテナンスし続ける意味はない」というのがその主旨です。

この主張はメンテナの現実的な工数という観点から理解できる部分が大きい一方、下流の実装者やエンタープライズユーザーにとっては受け入れがたい面もあります。製品のライフサイクルとカーネルのサポート期間を連動させて設計してきた現場では、前提が覆されることになるからです。

ディストリビューションと組み込みが直面する現実

LTSカーネルの恩恵を最も強く受けてきたのは、長期間の製品サポートを必要とするディストリビューションと、組み込み・IoT分野の開発者です。

UbuntuのLTS版（5年〜10年サポート）やDebianのstableリリース、Red Hat Enterprise Linux（RHEL）などは、それぞれが採用するカーネルに対して独自のパッチを重ねながら運用しています。ただしこれらのディストリビューションは上流カーネルのLTS期間とは独立した自社サポートラインを持っているため、上流の期間短縮が直接かつ即座に影響するわけではありません。

より大きな影響を受けるのがAndroidエコシステムです。AndroidデバイスはGoogleが定めるAndroid Kernel Support Policyに基づいてLTSカーネルを採用しており、5.10・5.15・6.1といったバージョンが多数のスマートフォンや組み込みデバイスで稼働しています。端末のライフサイクル（販売から3〜5年程度のセキュリティアップデート提供）に対応するには、カーネルの上流サポートが途切れた後も下流でバックポートを継続する必要が生じ、コストが大きく跳ね上がります。

さらに、IEC 62443準拠の産業制御システムや車載向けLinuxを手掛けるCIP（Civil Infrastructure Platform）プロジェクトは、10年以上の超長期サポートを必要としており、上流の方針変更は深刻な懸念事項です。「カーネルを更新すること自体がリスクになる環境」が産業用途には多く、短サイクルでの更新要求には応じられない実態が現場にはあります。

2025年以降のLTS指定と期間の変化

この議論を受けて、kernel.orgにおけるLTS指定の運用は実際に変化しています。2022年末にLTS指定を受けた6.1カーネルは当初2年間のサポートが予告されていました。しかしその後、複数のディストリビューションベンダーやGoogleからの明示的なサポート継続意思表明を受けて、EOLが延長される形になっています。

2023年末にLTS指定を受けた6.6カーネルでも同様に延長議論が行われました。2024年末の6.12についても、LTS指定後の期間をめぐってコミュニティでの議論が続いており、最終的なEOLは「下流から手が挙がるかどうか」に左右される構図が続いています。

ここで浮かび上がってきたのは、「デフォルトは2年だが、実際にケアする下流ベンダーが意思を示せば延長する」という運用モデルへの移行です。サポート期間を事前に一律で約束するのではなく、実際の利用実態と貢献意思に応じて柔軟に決定するという方向性が、現在のコミュニティの合意に近い姿になっています。

「誰がケアするか」モデルへの転換と各陣営の動き

この一連の議論が示す本質的な変化は、カーネルLTSのサポートが「上流コミュニティが一方的に提供するもの」から「ステークホルダーが共同でケアするもの」へと性格を変えつつある点にあります。

Googleはすでに独自のAndroid共通カーネル（ACK: Android Common Kernel）を管理しており、上流のLTSサポートが終了しても自社でバックポートを継続する体制を整えています。CIPプロジェクトはさらに独自のスーパーLTS（SLTS）という枠組みを打ち出し、特定のカーネルを超長期でメンテナンスする取り組みを進めています。5.10カーネルは2036年ごろまでの維持がCIPにより計画されており、上流LTSとは完全に切り離された独立したサポートラインが形成されつつあります。

大手クラウドプロバイダーや通信事業者も独自のカーネルブランチを持つケースが増えており、「上流LTSに全面依存する」時代から「上流での修正を取り込みながら、自社で一定のメンテナンス能力を持つ」時代へのシフトが加速しています。ただし、この方向性は中小規模の組織や独自メンテナンスのリソースを持たない開発者にとっては負担の増加を意味します。上流が当てにならなければ、ディストリビューション選択や更新ポリシーの根本的な見直しを迫られるからです。

運用担当者が今おさえておくべきポイント

この議論を踏まえ、実務的な観点から現在注目しておくべき点を整理します。

LTSのEOLはkernel.orgで定期的に確認する
kernel.orgの「Active kernel releases」ページには、現在サポート中の各カーネルブランチとEOL予定日が掲載されています。LTS期間は下流ベンダーの動向次第で変動することがあるため、年に1〜2回は確認する習慣が実務上有効です。かつての「6年あるから安心」という前提はもはや通用しません。

使用しているディストリビューションの独自サポートラインを基準にする
RHEL・Ubuntu・Debian・AlmaLinux・Rocky Linuxなど、主要ディストリビューションは上流カーネルのLTS期間とは独立したサポートスケジュールを持っています。上流LTSが短縮されても、ディストリビューション側が独自のパッチを当て続けているケースが多く、実務上はディストリビューションのサポート期間を基準とした計画が安全です。

組み込み・産業用途では上流依存をあらかじめ限定的に捉える
制御システムや組み込みLinux向けの開発では、上流LTSの期間だけに依拠したサポート計画は現実的ではありません。CIPプロジェクトやベンダー提供のBSPサポートを組み合わせた多層的な体制を設計段階から検討することが、リスク管理の観点からも重要です。

LTSカーネルのサポート期間をめぐる議論は、オープンソースコミュニティにおける「誰が誰のためにどこまでケアするか」という根本的な問いに直結しています。現状では、上流メンテナの現実的な工数制約とダウンストリームの長期ニーズとの間で最適解が模索されており、固定した答えはまだ出ていません。方針の変化を継続的に追いながら、特定の上流期間への過度な依存を避けた構成を意識することが、今後の運用設計における基本的な姿勢になるでしょう。