LinuxカーネルにAIのバグ報告が殺到、レビュアー不足が深刻に

Linuxカーネルのバグを見つけるのは、今や簡単になりました。しかし、それを直すのは別の話です。ZDNETが2026年11月12日に伝えたところによると、AIツールが生み出すバグ報告やパッチがあまりに多く、レビューを担う人々が疲弊しており、少なくとも著名なカーネルメンテナーの一人がコードの大半のレビューをやめました。

CVE（Common Vulnerabilities and Exposures、共通脆弱性識別子）は、文書化されたセキュリティ上の欠陥に付けられる公開の識別番号です。メンテナーとは、カーネルの一部を担当し、どのパッチを取り込むかを決める人で、ボランティアの場合も企業の社員の場合もあります。レビュアー（reviewer）は、提案されたパッチを読み、取り込む前に正しいことを確認する人です。スマートフォンからスーパーコンピューターまで動かすOSの中核であるLinuxカーネルは、こうした人々の少数に支えられています。

Linuxのバグ報告の洪水はどれほどの規模か

ZDNETによると、Linux CVEチームは2026年、11月2日までの時点で1日平均27件のCVEを報告しました。ZDNETはこの数をカーネル固有の考え方でも説明しています。Linuxでは、どんなバグでもセキュリティ上のバグになり得る、というものです。

Tom's Hardwareが8月28日のPhoronixの報道を引いて伝えたところでは、カーネルは1リリースあたり修正されるCVEが2,000件に近づいており、Linux 6.x時代の大半の約500件から増えています。安定版カーネルのメンテナーであるGreg Kroah-Hartman氏がKernel Recipes 2026向けに用意したスライドでは、Linux 7.0で1,000件超、Linux 7.2で1,500件超と示されていました。この傾向が続けば、Linux 7.3は2,000件を超える可能性があるとTom's Hardwareは述べています。

Tom's Hardwareは、この急増の主因を、35年かけて4,000万行を超えたソースツリーをAIツールで調べる人々の存在とみており、カーネルの品質が急に落ちたとは見ていません。こうしたツールは、人間がめったに見直さない目立たない部分まで届き、ときに本物の欠陥を見つけます。今年のLinuxのCVE記録には、AI支援の静的解析で見つかり、その後Intel Product Securityが確認した脆弱性がすでに明記されています。

ZDNETの記事は、企業側の数字も加えています。MicrosoftのFORGE Labは、AIスキャンシステムMDASHが上流のLinuxカーネルに対して59件のバグ報告を出し、その中には少なくとも21年前からある欠陥が含まれると発表しました。同ラボによると、これらの発見を報告にまとめるのに4人月以上かかり、ボトルネックは人間の労力でした。バグの発見と修正は極端に均衡を欠いている、とも述べています。Windows側では、直近のPatch Tuesdayに726件のCVEが含まれ、その大半がAIによる発見に由来するとZDNETは指摘しています。

なぜカーネルのメンテナーは燃え尽きかけているのか

負担は、名前の挙がった事例に表れています。ZDNETによると、2026年11月10日、ARMのエンジニアでカーネルメンテナーのLorenzo Stoakes氏は、メモリ管理の中核、misc、reclaim、Rust関連の各セクションでのコードレビューをやめました。これらはレビュアーとして担当していた領域です。同氏は2014年からカーネルに貢献しています。AIが生成するパッチシリーズの現在の流量を考えると、自分がメンテナンスしている領域を除いて一般的なレビューを提供する余裕はない、と書きました。さらに、AI生成の粗悪な投稿は最初はときどき、次に毎週、次に数日おきに現れ、今では目にするものの半分かそれ以上になっている、と付け加えています。

ZDNETによると、安定版カーネルのメンテナーGreg Kroah-Hartman氏もOpen Source Summit Europeの質疑応答で同じことを述べました。LLMが生成するパッチの猛攻をレビューするだけの人数がおらず、メンテナーは10年前から燃え尽きている、というものです。要望は率直で、カーネルにはもっとレビュアーが必要だと訴えています。

Tom's Hardwareはネットワーク分野で数値の例を挙げています。Linux 7.3のネットワーク向けプルリクエストで、メンテナーのJakub Kicinski氏は、このサイクルで扱った648件のnet-nextパッチのうち、3分の1から半分が、AI主導の優先度の低い修正、整理、説明の追加に見えると見積もりました。チームは完全に圧倒されている、と書いています。

作業量はカーネルが何を残すかにも影響しています。Tom's Hardwareによると、開発者のAndrew Lunn氏は4月、ISAやPCMCIA時代のハードウェア向けの古いネットワークコード約28,000行の削除を提案しました。AIやファジングのツールが欠陥を見つけ始め、そのハードウェアを誰も使っていなくても、メンテナーが修正せざるを得なくなったためです。Linux 7.3では古いSGIとIBMのドライバーコードが削除され、FreeVxFSファイルシステムドライバーも、メンテナーが古い互換性コードは主に自動バグ検査ツールの餌になっていると述べた後に削除されました。

カーネルコミュニティはAIを拒んでいるのか

いいえ。Tom's Hardwareはこの点を明確にしています。Kroah-Hartman氏自身、ローカルで動かすAI支援のファジングツールでカーネルのバグを見つけています。問題にされているのは、検証されていないAIの出力が、確認のために人間へ丸投げされることです。Tom's Hardwareによると、同氏は最近、正当なセキュリティ修正を除き、LLM生成パッチをカーネルのstagingサブシステムから締め出しました。更新されたカーネルのガイドラインも、人間の検証なしに提出されたAI生成の報告はメンテナーの時間を無駄にしかねないと警告しています。チームはまた、複数のフロンティアモデルへのアクセスを確保し、パッチのレビューや幻覚による誤った結果の除去に役立てています。

修正は報告に追いつき始めているのか

初期の兆しはありますが、決定的なものではありません。ZDNETによると、Linus Torvalds氏はLinux Kernel Mailing Listへの投稿で、Linux 7.4-rc2の新しいコードの多くはAIによる修正が牽引したと書きました。少なくともBPF側では、修正の到着が新しい報告より速くなっており、他の大半の領域はまだそこまで至っていないが、流れが変わり始めている兆しかもしれない、と述べています。ただし、期待しすぎないように、という助言でした。

Kroah-Hartman氏はそれほど楽観的ではありません。ZDNETに対し、プロジェクトは近づいているがまだ到達していないと語り、人間が承認したAIの修正がAIのバグ報告を上回る時期の見積もりは拒みました。cURLプロジェクトの作者で、低品質なAI報告を率直に批判してきたDaniel Stenberg氏は、ZDNETに、これまでのところ自分のプロジェクトは洪水をかなりうまくさばけていると考えている、と述べました。ただし、その週に誰が新しい発見を送ってくるかによって、量は増減するといいます。

• 1日27件のCVE：ZDNETによる、2026年11月2日までのLinux CVEチームの平均。
• カーネル1リリースあたり2,000件近いCVE：6.x時代の大半は約500件、Tom's Hardwareによる。
• Linux 7.3サイクルのネットワークパッチ648件のうち3分の1から半分が優先度の低いAI主導の作業と判断、メンテナーJakub Kicinski氏による。

企業にとって何が変わるのか

サーバー、コンテナ、ネットワーク機器、組み込み機器でLinuxを動かす日本企業にとっての実務的な教訓は、カーネルのセキュリティ勧告の件数は増え続ける一方で、各修正を担う人手は限られたままだという点です。CVEの件数だけではリスクはほとんど分かりません。新しい項目の多くは目立たないドライバーに関するものだからです。重要なのは、そのうちどれが自社で実際に使うハードウェアとカーネル構成に影響するかです。

ここから三つの習慣が導かれます。使っているディストリビューションが出す安定版カーネルの更新を追い、適用までの時間を短くすること。有効にしているカーネル機能とドライバーの一覧を維持し、勧告を素早く仕分けられるようにすること。そして、AIの助けを借りてバグ報告を出す場合は、先に人間が各問題を再現すること。メンテナー自身のガイドラインが、未検証の報告は時間の無駄だと述べているためです。Linuxに依存する企業は、レビューの時間を資金面や人員面で提供することでも直接貢献できます。Kroah-Hartman氏によれば、それが最も不足している資源です。

留意点として、修正が報告を上回る時期については、取り上げた情報源は何も述べていません。BPFに関するTorvalds氏の観察も、心強いがその領域に限られると説明されています。現在は、確立した傾向ではなく、パッチ適用の忙しい季節とみなすのが妥当です。