オープンソースソフトウェア（OSS）の根幹を長らく支え続けてきたLinuxカーネルの開発現場で今、不可解かつ劇的な変化が起きている。つい数ヶ月前まで、生成AIを用いたツールによるバグ報告は「AI slop（AIのゴミ）」と揶揄され、処理する価値のないスパムと同等に扱われていた。しかし2026年に入り、AIツールが提出するセキュリティインシデントの報告やパッチ修正案の品質が突如として跳ね上がった。この現象はカーネルメンテナたちを驚愕させていると同時に、巨大なエコシステム全体に新たな波紋を投げかけている。
ヨーロッパで開催されたKubeCon + CloudNativeCon EUにおいて、Linuxカーネルを中心的に牽引する一人であるGreg Kroah-Hartman氏は、この劇的な変化が現在進行形で起きていることを明かした。重要なのは、話がLinuxカーネルだけで完結していない点だ。Kroah-Hartman氏は中核的なオープンソース保守者の間で同じ傾向が共有されていると述べ、OpenSSFのCTOである Chris Robinson氏も、先端AIツールが人気の高いオープンソースプロジェクトから短時間で大量の脆弱性候補を洗い出し、上流に流し込む状況を警戒している。AIはようやく役に立つ道具になり始めたが、その価値はそのまま保守の仕事量増加と表裏一体でもあるのだ。
数カ月前の「ノイズ」が、今は捨てにくい報告へ変わった
Kroah-Hartman氏の証言で重いのは、変化がかなり急だったことだ。彼によれば、数カ月前まで届いていたAI生成のセキュリティ報告は、明白に間違っているか、質が低いものが多かった。ところがこの1カ月ほどで空気が変わり、実際に検討すべき報告が増えてきたという。何が転換点だったのか本人にも断言できず、ツールの性能向上なのか、利用者や企業の増加なのかは見えていない。
この「理由ははっきりしないが、受信箱に入ってくるものの質は変わった」という感覚は、現場の判断としてはかなり具体的である。AIを巡る議論は、どうしても派手なデモやベンチマークの話に流れやすい。だが保守者にとって重要なのは、届いた報告がレビューに回す価値を持つかどうかだ。そこが変わったからこそ、Kroah-Hartman氏はもはや無視できないと語っている。
年初には、AI由来の低品質な報告が開発者コミュニティを疲れさせる例も出ていた。cURLプロジェクトがバグ報奨金の支払いを止めた件は、その象徴として受け止められた。そこから数カ月で、同じAI起点の報告が今度は実在の不具合や脆弱性の手掛かりを含むようになったのであれば、論点は単純なノイズ対策から、選別と吸収の運用設計へ移る。
もっとも、Kroah-Hartman氏はLinuxカーネルについては「処理しきれない量ではない」とも述べている。カーネルは分散した大規模チームで、レビューの受け皿も比較的大きいからだ。裏を返せば、同じ波が小規模なプロジェクトへ届いたときの重みはまったく違う。AIの精度向上は、保守体制の差をそのまま露出させるのだ。
実用段階に入ったのは、コード生成よりレビュー補助
修正パッチの叩き台として、すでに無視しにくい
Kroah-Hartman氏自身の実験でも、AIの実用性は限定付きながら確認されている。かなり雑なプロンプトを投げたところ、AIは60件の問題と修正案を返し、そのうち約3分の1は誤りだった一方で、残りのかなりの部分は妥当だったという。誤った回答であっても、相対的には実在する問題に触れていたとされる。さらに修正パッチの約3分の2は正しかったといい、人手による整理や changelog の補強、既存コードとの擦り合わせは必要でも、最初から捨てるには惜しい水準まで来ている。
ここで見えてくるのは、AIがすぐにカーネルコードの主執筆者になるという話ではないことだ。むしろ価値が出ているのは、単純なエラー処理、見落としやすい条件分岐、初期レビュー段階での指摘といった、反復が多く機械に寄せやすい部分である。派手な自動生成より、地味だが数の多い確認作業を圧縮するところで効き始めている。
Sashikoの統合が示すのは、AI利用の制度化だ
この流れを象徴するのが Sashiko である。Google発のコードレビュー支援ツールで、現在はLinux Foundationのプロジェクトとして扱われ、ほぼすべてのカーネルパッチ上で動いていると説明されている。ネットワーキングやBPFの領域では以前からLLMベースのレビューが使われており、DRMなどの領域でも知見は蓄積されていた。Sashiko はそうした個別の取り組みを共通インターフェースへ寄せ、サブシステムごとの観点やプロンプトを持ち寄れる形にしようとしている。
ここで重要なのは、AIレビューの価値がモデル単体の賢さだけでは決まらないことだ。どの観点で、どの段階で、誰に結果を返すのかによって使い勝手は大きく変わる。ストレージなら見るべき癖があり、グラフィックスなら別の落とし穴がある。そうした文脈をレビュー支援に織り込めるなら、AIは抽象的な万能査読者ではなく、各領域ごとの補助線になる。
Kroah-Hartman氏も、AIレビューを権威ではなく補助として位置づけている。全部を見つけるわけではなく、間違いも残る。ただし明白な問題を早く拾い、保守者が目を通す前に投稿者へフィードバックを返せる。カーネル開発ではこの初速が大きい。メンテナが読む前に自動系の指摘で手戻りが進めば、人間は難しい判断に時間を回しやすくなる。
精度が上がるほど、上流側のセキュリティ運用は重くなる
Robinson氏が語る懸念は、その裏側にある。Anthropicなどの先端AIツールは、広く使われるオープンソースプロジェクトから数分で数百件規模の脆弱性候補を見つけられる段階に近づいているという。もしその一部でも妥当であれば、保守者の机に届く報告量は急増する。しかも、届く内容が全部ノイズではなくなるほど、機械的に捨てることが難しくなる。
増えるのは、まずトリアージの仕事である。報告が正しいか、再現条件はあるか、影響範囲はどこか、既知の問題と重複していないか。AIが発見を高速化しても、この確認工程まで自動化できたわけではない。Kroah-Hartman氏が「小さな問題が多い」と見ているのも示唆的で、重大なゼロデイばかりが増えるわけではないが、小粒の不具合が大量に押し寄せるだけでも保守者の時間は削られる。
Robinson氏は別の側面も挙げている。企業や開発チームがAIツールを既存パイプラインへ急いで組み込む一方で、認証、アクセス制御、データ取り扱いといった基礎的な安全策が追いついていないという問題である。AIは脆弱性を見つける道具である前に、新しい運用リスクを持ち込む道具でもある。OpenSSFが開発者向けのガイダンスやツール整備を進めようとしているのは、この二つの課題が同時に膨らんでいるからだ。
そこへ規制要因も重なる。EU Cyber Resilience Act（CRA）は、EU向け製品を出荷するメーカーに対し、脆弱性の報告やソフトウェア部品表の提示を求める。制度の狙い自体は理解しやすいが、現場では報告の流れがいっそう形式化し、上流のオープンソース保守者が受ける圧力も強まる。AIで見つかる候補が増え、規制で報告義務が整えば、入口の流量はさらに上がる公算が大きい。
問われるのはAIの性能競争ではなく、保守の受け皿をどう広げるか
ここまでを並べると、争点は「AIがコードを書けるか」ではないとわかる。少なくとも2026年3月のLinuxカーネル周辺で起きている変化は、発見と初期レビューの自動化が実務に入り込み、保守者の仕事配分を変え始めたことにある。AIは開発者を一気に置き換えるのではなく、保守フローの前段へ深く入り込んできた。
そのとき本当に効いてくるのは、モデルの派手さより共有インフラの有無である。Sashiko がLinux Foundationのもとで広く使える形に移ったことは、資金や計算資源を持つ一部サブシステムだけが恩恵を受ける状態を改める試みと読める。AIレビューが大規模プロジェクトだけの武器にとどまれば、小規模保守者はAIが増やした仕事を受け取る側に回るだけだ。
今後の分岐点はそこにある。財団やセキュリティ団体が、レビュー支援、トリアージ手順、教育、ガイダンスを共有資産として整えられれば、AIは保守者の時間を奪う存在ではなく、難しい判断へ集中するための前処理になりうる。逆に受け皿づくりが遅れれば、精度向上はそのまま受信箱の飽和に変わり、上流の遅延として跳ね返る。Linuxカーネル保守者の評価反転は、AI礼賛の号砲ではない。オープンソースが次に整えるべき運用基盤が、かなり具体的な輪郭を持って現れたという知らせである。
Sources
