Linus Torvaldsは2026年9月6日、Linux 7.3-rc2を公開し、これを「全部入り」のrc2だと書いた。マージウィンドウが閉じた直後で最も静かなはずの一週間に、rc1のタグからrc2のタグまで681件のコミットが積み上がっている。Torvalds自身は原因を一つに絞らず、マージウィンドウ中に忘れられていたEDACのpull、複数のファイルシステムからの修正、drmとネットワークの流入を並べたうえで、「たまたまかもしれないが、当然みんなAIのせいにするだろう」と冗談で締めた。末尾にはウインクの顔文字が付く。The Registerはこの一言を見出しに据えたが、gitのタグ差分が裏づけるのは規模の異常さまでであり、原因の特定はそこに含まれない。
「full fat」の中身を数え直す
rc1タグからrc2タグまでのコミット数を、v6.8以降の16サイクルすべてについて同じ条件で数えると、7.3-rc2の681件は最大値になる。比較の起点と終点をどちらもリリース候補のタグに固定し、マージコミットを含む件数で揃えた結果である。区間の長さも6.9日から7.8日の範囲に収まっており、日数の違いで説明できる差ではない。
データを表で見る
| コミット数 (commits) | |
|---|---|
| 6.8 | 391 |
| 6.9 | 390 |
| 6.10 | 323 |
| 6.11 | 336 |
| 6.12 | 382 |
| 6.13 | 424 |
| 6.14 | 277 |
| 6.15 | 339 |
| 6.16 | 240 |
| 6.17 | 225 |
| 6.18 | 363 |
| 6.19 | 342 |
| 7.0 | 434 |
| 7.1 | 475 |
| 7.2 | 433 |
| 7.3 | 681 |
16サイクルで2番目に多いのは7.1-rc2の475コミットであり、7.3-rc2はこれを43.4%上回る。6.x時代の12サイクル、つまりv6.8からv6.19までの平均は336.0コミットであり、681件はその約2.03倍にあたる。Torvaldsが「忙しいrc2だという感じはしなかったが、明らかにそうだった」と書いた体感は、少なくとも件数の水準としては裏づけが取れる。
ただし段差はrc2で突然生じたのではない。メジャー番号が7.xへ移ってからの3サイクル（v7.0からv7.2）の平均はすでに447.3コミットで、6.x平均を33.1%上回っている。その7.x水準に対しても、今回の681件はさらに1.52倍だ。つまり7.3-rc2の異常さは、緩やかに上がっていた床の上に、今回のサイクル固有の跳ね上がりが乗った結果として読める。
数え方の限界も押さえておきたい。コミット数は件数であり、変更の大きさを映さない。1件あたりの変更行数がどれだけ違うかは、この比較からは見えない。比較対象もv6.8以降の16サイクルに限られ、それより前まで遡って最大だとは言えない。
7.x平均の447.3コミットも母数は3サイクルにとどまり、個々のサイクルの振れに引っ張られやすい数字である。6.x台から7.x台への床の上昇自体を、AIツールの普及に結びつける根拠はこの計算にはない。バージョン番号の変更は開発量の変化と直接の因果を持たないためだ。
Torvaldsが原因として挙げたもの、挙げなかったもの
アナウンス本文でTorvaldsが規模の要因として並べたのは、マージウィンドウ中に忘れられていたEDACの遅れたpull、複数のファイルシステムからの修正、散在する修正を含む相応の規模のdrm pullの3つだ。加えて、ネットワークとBPFの修正、複数のドライバツリーも要因に挙げている。本人はEDACのpullを「わりと小さいもの」と書き添えており、どれか一つを主犯として立てていない。
変更の内訳についても、Torvaldsは具体的な配分を示した。ツーリングがパッチ全体の約20%を占め、その中心はsched_extとselftestsだという。ドライバを除けばツーリングが最大の変更源で、以下ファイルシステム、コアカーネル、ネットワークと続く。この内訳にAIという語は一度も出てこない。
そのうえで最後に、「特におかしなものは見当たらない。rc2の時期としては少し異常だが」「そして単一の原因があるわけでもない」と書き、原因の探索を締めくくっている。AIが登場するのは、この後の一文だけである。「たまたまかもしれないが、当然みんなAIのせいにするだろう。それが本当に原因かどうかは別として、責めるには手軽な相手だからだ」。文末のウインクを含めて読めば、これは原因の指摘というより、原因を特定できないことへの自嘲に近い。
一週間前にも、似た調子の予告があった。8月30日の7.3-rc1アナウンスで、Torvaldsは「残りが順調に、小さく何事もなく進むことを願おう。とはいえ何を言っているのか。まず小さくはならないだろうが、願うだけは自由だ」と書いている。これはrc2に限らず7.3サイクル全体についての見通しであり、同じアナウンスではrc1のパッチ全体の約3分の1をAMD DCN6のレジスタヘッダと新世代向けコードだけで占めると説明していた。AIを名指しする前から、本人は今回のサイクルが軽くは終わらないと踏んでいたことになる。
615と681と2,000、どれが正しいのか
同じrc2について、流通している数字は一つではない。Torvaldsのアナウンスに添付された変更一覧は292人・615コミット、リポジトリのタグ間差分は681コミット、そして集約系サイトの一部は「約2,000コミット・694人の貢献者」と伝えた。コミット数で約3倍、人数で約2.4倍の開きがある。
615と681の差は説明がつく。アナウンスに付く変更一覧は非マージコミットだけを列挙する仕組みで、サブシステムのツリーを取り込むマージコミットは数に入らない。一方でタグ間差分は、rc2側にだけ存在するコミットをマージも含めて数える。差の66件がマージコミットにあたり、Torvaldsが週内に取り込んだpullの本数の目安になる。どちらも正しい数え方であり、何を数えたかを言わずに「コミット数」とだけ書くと、同じリリース候補について別々の数字が並ぶことになる。
2,000という数字の側は、そう説明できない。当該サイトは計数方法を明記しておらず、rc1を含む累計やlinux-next由来の集計を混ぜた可能性は残る。ただし出所の分からない数字は、それが引用されるたびに規模の印象だけを膨らませる。Linuxカーネルの開発量をめぐる議論では、AIによる増加を語るときほど、その数字がどのタグ間で、マージを含めて数えられたのかを確かめる必要がある。
メンテナーの負荷は数字でどこまで見えるか
rc2の5日前、2026年9月1日にGreg Kroah-Hartmanが7.3は厳しいサイクルになると警告していた。自身の投稿によれば、USB関連の「todo」メールボックスには1,732通の滞留があり、明らかな修正や重複を除いたあとも1,094通が残っていたという。「カーネル開発の世界で物事が落ち着く気配はない。『安定している』はずの古いサブシステムでさえそうだ」というのが彼の言葉である。
品質側の指標も動いている。Kernel Recipes 2026に向けたKroah-Hartmanの発表資料によれば、リリースあたりのCVE件数は6.9から6.19の期間で平均約500件だったのに対し、7.0以降は1,000件を超え、7.2では1,500件を超えた。ただしPhoronixによれば、その多くは古い、あるいは使われていないドライバの低優先度の脆弱性だという。件数の増加は、そのまま品質の悪化を意味しない。
機械が見つける側の数字もある。GoogleのカーネルエンジニアRoman Gushchinが2026年3月に公開したAIレビュー基盤Sashikoは、開発元の資料によれば、Fixedタグ付きの直近1,000件のupstreamコミットのうち53.6%で既知の不具合を検出し、それらはすべて人間のレビューで見逃されていたという。誤検出は20%以内だと同氏は説明する。いずれの数値も発表者本人の資料と自己申告に基づき、独立した検証を経ていない。有用性の示唆にはなるが、AIレビューがrc2の681コミットをどれだけ生んだかを測る材料にはならない。
つまり、負荷が増えたことを示す数字と、その原因を特定する数字は別物である。前者は複数の当事者から出ているが、後者は誰からも出ていない。
カーネルが動かしたのは原因論ではなく手続きだった
原因の議論が決着しない一方で、カーネルは投稿の作法の側に手を入れている。AI支援投稿を扱う文書Documentation/process/coding-assistants.rstは2025年12月23日にSasha Levinが追加したもので、2026年に入ってから3回改訂された。7月1日にChristian Braunerが帰属の記述を簡素化し、7月2日にLorenzo Stoakesが関連文書へのリンクを足し、8月2日にはWilly Tarreauがバグを探すときの重要な手順を書き加えている。これらは8月20日のdocs-7.3マージで7.3に取り込まれた。まさにこのサイクルの成果物である。
文書が求める手続きは具体的だ。AIの支援を受けた投稿にはAssisted-by: LLM [TOOL1] [TOOL2]形式のタグを付けることが推奨される。一方で、「AIエージェントはSigned-off-byタグを付けてはならない。DCO（開発者原本証明）を法的に証明できるのは人間だけである」とする規定は、こちらは緩めていない。
バグ報告についても、非自明なものは再現手順による検証を求める。あわせてビルド・テストの実施、checkpatch.plの通過、get_maintainer.plの使用も求め、実施できなかった項目は明示するよう要求する。未検証の報告と未テストの修正の分析にメンテナーの時間が使われすぎている、というのが背景の説明だ。
責任の所在を人間側に固定するというこの設計は、量が増えること自体を止めない。止めるのは、検証されていないものが検証済みの顔をして流れ込むことである。日本の利用者にとってこの区別が効くのは、LTS（Long Term Support、長期サポート）カーネルを採用する場面だ。組み込み機器や国内のサーバー基盤でカーネルを長期運用する場合、リリースごとに1,000件を超えるCVEのうち、自社の構成で実際に効くものを選り分ける作業が増える。件数の増加が低優先度のドライバ脆弱性に偏っているなら、その選別コストの見積もりは変わる。
7.3の正式版は、rc1が8月30日だったことと通常7週から8週というサイクル長から、10月中旬から下旬に出る見込みだ。rc3以降の件数が6.x平均の336件前後へ戻るのか、7.x水準の450件前後で高止まりするのかは、同じタグ間差分で誰でも数えられる。その数字が落ち着いたとき、Torvaldsが冗談で名指しした相手が本当に犯人だったのかを、初めて件数以外の材料で議論できるようになる。
