Linux 7.3-rc2はなぜ大きいのか――「AIのせい」は冗談、課題は修正量の増加

Linux 7.3-rc2は、カーネル開発サイクルで通常もっとも落ち着くことが多い段階にしては、かなり大きな更新になった。マージウィンドウ（新機能を取り込む期間）の直後に出るrc2は、開発者が一息つき、不具合が見つかり始めるまで時間がかかるため、一般には修正量が少ない。ところがLinus Torvalds氏は今回を「full fat（中身の詰まった）」なRCだと表現した。本人には特別に忙しい週には感じられなかったものの、実際のパッチ量はそうではなかったという。 1127

「AIのせい」は原因の断定ではない

Torvalds氏は、規模を説明する単一の要因を示してはいない。マージウィンドウに間に合わなかったEDAC（メモリーエラー検出・訂正関連）の取り込みもあったが、全体の規模を説明するには小さすぎる、としている。複数のファイルシステムからの修正に加え、多数の細かな修正を含む比較的大きなDRM（グラフィックス表示系）プルも到着した。こうした状況での「AIのせいにしよう」という発言は、LLMが直接今回のrc2を巨大化させたという結論ではなく、冗談としての言及だ。 11

一方で、この冗談には現実的な背景がある。Torvalds氏は以前から、AIツールによるレビューによって見つかる問題が増え、後期RCが大きくなる傾向を「新しい普通」と表現していた。ただしこれは、AIがすべてのパッチを書いた、あるいは各修正を引き起こした、という意味ではない。人間の保守担当者が評価し、修正し、取り込むべき問題の候補が増えている、ということだ。 34

Linux 7.3-rc2に入った主な修正

今回の変更は、特定の重大障害への緊急対応に集中したものではない。全体ではドライバーが大きな割合を占め、ドライバー以外ではツール関連が約2割、続いてファイルシステム、カーネル中核、ネットワークが目立つ。 18

主な修正・整理には、次の項目が含まれる。

• ハイブリッドCPUでの性能挙動を改善する、キャッシュ認識型スケジューリングの「misfit」修正 9
• kmalloc() の呼び出しを kmalloc_obj() へ移す、ツリー全体にわたる整理 9
• NVIDIA Blackwell搭載GPU向けのNouveauディスプレイ修正 9
• RustサポートとRustコンパイラ環境がある場合、RandStructセキュリティを既定で無効化する変更 9
• 7.3のマージウィンドウから漏れていたEDACの変更 9
• BPFベリファイアの強化、およびスケジューラーの回帰不具合の修正 23

つまり今回の大きさは、ひとつの問題に由来するというより、複数サブシステムの妥当な保守作業が同時期に集まった結果と見るのが適切だ。

すでに大きかった7.3-rc1の後に続く

背景として、Linux 7.3-rc1の時点でカーネルツリーはすでに大きく膨らんでいた。コード行数の集計では、Linux 7.2の約4042万行から約56万行増え、7.3-rc1は約4098万行となった。 513

ただし、この4098万行は実行可能なコードだけを意味しない。検出されたコード約3094万行に加え、コメント約491万行、空行約513万行などを含むツリー全体の集計値である。 13

この規模のプロジェクトが、すでに大きなマージウィンドウを終えたうえでテスト・修正段階へ入っていることが、今回のrc2のボリュームをより目立たせている。

AI/LLM時代に増える「見つける仕事」と「確かめる仕事」

Linuxの安定版保守を担うGreg Kroah-Hartman氏は、AI/LLMに関係するバグ報告や提案パッチの増加により、Linux 7.3は「rough（厳しい）」なサイクルになる可能性があると警告している。有用な報告もある一方で、レビュー、優先順位付け、再現確認、修正の検証を担うのは依然としてカーネル開発者だ。長年ほとんど触られていないコードやドライバーに関する報告も、その負荷を増やし得る。 32

セキュリティ修正の推移は、その作業量を示す一例だ。Linux 6.9から6.19では1リリース当たりの修正済みCVEはおおむね500件だったのに対し、7.0では1000件超、7.2では1500件超に増えた。傾向が続く場合、7.3では2000件に近づく可能性がある。ただしこれは最終的な7.3の件数ではなく、あくまで見通しである。 1234

正式版までの期間は延びるのか

Linux 7.3-rc2は正式な安定版ではなく、テスト向けのプレリリースだ。kernel.orgでは2026年9月6日付で7.3-rc2が掲載されている。 30

rc2が大きいことだけで、正式リリースの延期が決まるわけではない。しかしサイクル後半まで大きな修正や回帰不具合が持ち込まれるなら、保守側はRCを追加してテスト期間を取る選択ができる。修正を十分に落ち着かせて検証する時間を確保することと、急速に変化する修正群を抱えたまま予定日に安定版を出すことの間には、明確なトレードオフがある。

利用者やLinuxディストリビューションにとっての要点は、7.3が本質的に危険だということではない。多数の修正が十分にテストされた品質改善へ収束するのか、それとも終盤の変更を増やし続けるのかが、今回のサイクルの健全性を左右する。「AIのせい」という一言は、欠陥発見の自動化が進んでも、判断・統合・検証という人間の作業まで自動化されるわけではない、という緊張関係を端的に表している。