Linux 7.0は、2026年4月12日に安定版へ到達する見通しだ。kernel.orgでは2026年4月5日時点のmainlineが7.0-rc7とされ、Linus Torvalds氏もrc7の告知で翌週末の最終リリースに向けて順調だとの見方を示した。もっとも、今回の「7.0」という数字自体には、過去の節目のような特別な意味はない。Torvalds氏は7.0-rc1の告知で、新しいメジャー番号にした理由を「大きな数字で混乱しやすいから」と説明し、大きな新機能の追加や旧インターフェイスとの決別を意味するものではないと明言している。

それでも、この開発サイクルを軽く扱うのは適切ではない。LWN.netによると、7.0のマージウィンドウは2026年2月22日に閉じ、非マージコミットだけで11,588件に達した。単一の目玉機能で引っ張る周期ではない一方、ディストリビューションや企業向け基盤ソフトウェアに効く差分が、この一つの窓に厚く積み上がったことは確かである。

Linuxのメジャーバージョン更新は、長らく「安定版と不安定版の境界」や「設計思想の断絶」を表すものではなくなっている。今回もその慣例に従う。しかし、名称が象徴的に控えめであることと、中身が実務的に小さいことは別問題である。Linux 7.0はまさにその典型であり、見出しほど劇的ではない一方で、ファイルシステム、言語基盤、性能、保守性の各面で2026年の実装現場に効いてくる更新を含んでいる。

AD

7.0の本質は「番号」ではなくマージウィンドウの厚みにある

Torvalds氏は7.0-rc1の告知で、「新しいメジャー番号は、単に自分が大きな数字に弱いから付けた」と率直に書いたうえで、それが「大きな新機能」や「古いインターフェイスの放棄」を意味しないと述べている。さらに現在のリリースcadenceでは、こうしたメジャー番号の更新はおおむね3.5年ごとに起きるだろうとも説明した。つまり7.0は、ユーザーランドや開発者に何らかの断絶を迫る“時代の変わり目”ではない。

しかし、LWNが追った7.0のマージウィンドウを見ると、このサイクルが単なる見た目の更新で終わらないことも分かる。コミット数の多さだけでなく、対象領域が広い。ファイルシステムのエラーレポート改善、XFSの自己修復機能、ext4のdirect I/O処理改善、Rustサポートの位置づけ変更が重なっている。Linuxカーネルのリリースは常に多層的だが、7.0は「象徴性は薄いのに、運用上は重い」世代だと言える。

Rustはついに「実験」から外れた

このサイクルで最も象徴的な変更のひとつは、RustサポートがLinux 7.0で正式にexperimental扱いを外れたことだろう。LWNのマージウィンドウ報告は、この点を7.0の重要項目として明記している。

これは、カーネル全体がRustへ大きく舵を切ったという意味ではない。Cが中心である構造は変わらないし、既存コードベースが一気に置き換わるわけでもない。それでも、「試験導入」段階から一段上がったことの意味は小さくない。少なくとも、Rustを使うこと自体を例外的な試みではなく、カーネル開発の正規の選択肢として扱う方向へ進んだと読めるからだ。

この変化の重みは、短期的なコード量よりも、メンテナの判断基準と将来の受け入れ方に現れる可能性が高い。Linux 7.0は「Rustカーネルの完成版」ではないが、「Rustを採る理由を毎回ゼロから説明しなくてよい段階」に近づいた世代として記憶される公算がある。

AD

ext4とXFSで進む、性能改善と障害対応の再設計

ファイルシステムまわりでも、7.0は地味ながら実務に直結する変更を含む。Theodore Ts’oによるext4のv7.0-rc1向けプルリクエストでは、複数ファイルに対するconcurrent direct I/O writesの書き込み性能改善のため、unwritten extentsの分割をI/O完了時まで遅延させる変更が取り込まれた。これはベンチマーク映えする派手な新機能ではないが、ストレージ集約型のワークロードでは効き方が分かりやすい種類の改善である。

一方、XFSではDarrick J. Wongが“autonomous self healing of filesystems”と題したプルリクエストを送り、その後Carlos Maiolinoがマージした。LWNは7.0のマージウィンドウ報告のなかでChristian Braunerによるfilesystem error reportingの作業を取り上げ、XFSのself-healing系統の作業がこのfserrorブランチと結びついていることも伝えている。

ここで大きいのは、単に「壊れても直る」という印象的な言葉ではなく、Linuxのファイルシステムがエラー報告と障害処理をより体系的に扱おうとしている点だ。性能最適化と信頼性向上は別々に語られがちだが、7.0ではext4とXFSがそれぞれ異なる角度から、I/O経路の改善と障害時のふるまい整理を進めている。エンタープライズ用途では、こうした変更の方がバージョン番号の節目よりはるかに大きな意味を持つ。

Phoronixのプレビューが示すのは、単独の看板より広い更新の広がりだ

Phoronixは、Linux 7.0を一つの目玉機能で要約するより、Intel TSXの既定値、AMD EPYCでの性能観測、ext4、XFS、I/Oエラー報告、Rustといった複数テーマの束として眺めている。一次情報で個々の項目をすべて追い切れているわけではないため、ここで各ベンダーの未検証なハードウェア名を断定的に並べるのは避けるべきだが、7.0が「一枚看板の新機能」ではなく「広い下回りの改良」であると見ている。

この視点は、Linux 7.0の評価軸を定めるうえで有効だ。7.0で問われるのは、新番号に見合う象徴的な物語があるかどうかではない。どの層の利用者が、どの差分を実際に取りにいくべきかである。ストレージを重く使う環境であればext4とXFSの差分が先に来るし、カーネル内の新規実装や安全性の議論を抱える組織ならRustの扱い変更の方が先に効く。

AD

Linux 7.0は「記念碑」ではなく、2026年の評価項目を増やす更新である

Linux 7.0を歴史的転換点のように語るのは誤りだ。Torvalds氏自身がそうした読み方を否定しているし、今回の番号変更は命名上の整理に近い。しかし、そのことは7.0を軽量な更新だと意味づける理由にはならない。11,588件の非マージコミットが示すのは、Linuxの通常運転そのものが、すでに一つの大きな産業基盤の更新作業だという現実である。

4月12日に安定版が予定通り出たとして、現場がまず確認すべきなのは三つある。ストレージ運用者は、ext4のdirect I/O改善とXFSの障害通知経路が自分たちのI/Oパターンや監視設計にどう効くかを見極めるべきである。カーネル開発を抱える組織は、Rustが「実験」ではなくなったことを、採用ポリシーやレビュー体制の見直しにつなげられるかを問われる。ディストリビューションやOEMは、派手な新機能より、こうした下回りの改良をどの時点で取り込むかという現実的な判断を迫られる。Linux 7.0は、その優先順位を各現場に突きつける更新だ。

Sources