Linuxカーネル、LLMがバグ修正を加速——リリースあたりの修正数が2倍超に
Linux bugs fixed per release over time: >2× rise since 2026-04
Linux 7.2カーネルは16,418件の非マージコミットと2,652人の開発者を集め、過去2番目に多忙な開発サイクルとなった。初参加の開発者は613人で過去最多を更新。Assisted-byタグ付きの変更は1,111件と7.1の301件から急増し、Sashikoレビューシステムを称えるReported-byタグも252件に達した。Fixesタグ付きコミットは4,830件に上り、LLMによるバグ発見がカーネル開発の実態を変えつつある。
LLM支援を受けて開発されたコミットを正確に追跡することは不可能かもしれないが、カーネルコミュニティは本気で試そうとするほど気にしていないように感じられることもある。
HNでの議論
101- ogoffart
自分のプロジェクトでも同じことに気づいた。
エージェントはバグ修正に大いに役立つ。バグレポートをエージェントに指し示すだけでいい。再現、デバッグ、修正までやってくれる。我々は「ただ」レビューするだけでいい（時にはもっと詳細を尋ねたり、別のアプローチの方がいいと伝えたりするが）。これでバグ修正がずっと速く、自動化される。
そして同時に、我々のライブラリにはバグレポートが減っているように思える。
ユーザーはエージェントにコーディングさせているだけで、エージェントはバグを報告せず、どうにか回避してしまうのだろう。
なので全体として、オープンなバグの数は減少している。なんだかいい感じだ。
一方で、他人のエージェントが作ったPRが大量に来る。巨大なコードの塊をただ投げつけられると、レビューするのは簡単ではないので、少し圧倒されることがある。
- zdw
Greg KHがLLMが生成したものの洪水について動画を出している: https://www.youtube.com/watch?v=NnV_cWeoo5Q 、HNスレッド: https://news.ycombinator.com/item?id=49929391
これには彼がどう対応し、その多くに反論しているか、またバグレポートだけでなくパッチを求めているかが含まれている
- 05kqhg
見出しは「7.2カーネルの開発統計」で、最後の段落は「リリースごとのLinuxバグ修正数：2026-04以降2倍超の増加」という編集された見出しとは対照的に、LLMに非常に批判的だ。この見出しはある種のMythosのバグ発見を示唆しているように見える。
最後の段落から：
「Linuxカーネルは研究や実験ではなく、本番利用を目的としている。しかし現在、カーネルの開発プロセスとコミュニティに対して大規模な実験が行われている。」
- jayd16
こうした類の宣伝文句の大きな問題は、対照群がないことだ。歴史的な数字は有効ではない。なぜなら、十分な資金を持つ主体のインセンティブが変わったからだ。LLMなしでパッチ数を増やす、同等に資金のある取り組みがなければ、影響を定量的に測ることは本当にできない。
- AmazingEveryDay
機械生成のamdgpuヘッダファイルはどれだけ巨大になり得るのか、そろそろ制限を設ける時期かもしれない。
- dash2
なので、導入されたバグに対する生存分析をバイブコーディングする価値はありそうだ。ただ、バグが発見されるというイベントが起きるまでバグの存在すら分からないので、厳密には生存分析ではない……。これに関する公開データセットはあるのだろうか、URLは？
- tosti
7.3にアップグレードする人への注意：/dev/input/eventsが欠けていたため、Slackwareマシンを7.3-rc7から7.2.10にダウングレードした。その結果、キーボードとマウスはコンソールでしか動かなかった。
環境によって異なるかもしれない。
- cwillu
タイトルを勝手に編集しないでください。
（編集：タイトルは修正されました）