AIバグ報告の洪水で、Linuxカーネルが13万行のコード削除へ
Linuxカーネル7.1のネットワーク担当メンテナーが、13万8161行を一気に削除するプル・リクエストを送った。AI生成のバグ報告が洪水のように押し寄せ、古いドライバーを守り続ける余裕が失われた。アマチュア無線サブシステムも退場する。
Linuxカーネル7.1のネットワーク担当メンテナーが、13万8161行を一気に削除するプル・リクエストを送った。AI生成のバグ報告が洪水のように押し寄せ、古いドライバーを守り続ける余裕が失われた。アマチュア無線サブシステムも退場する。
核心は「長らく孤児状態」のコード
2026年4月24日（日本時間）、Linuxカーネルのネットワーク担当メンテナーであるJakub Kicinski（以下、Kicinski）が、リーナス・トーバルズ（Linus Torvalds）宛てに「Networking deletions for 7.1」という件名のプル・リクエスト（pull request）を送った。差分は311ファイルで14行の追加に対し、13万8161行の削除。この規模はカーネル開発史でも稀に見る大粛清だ。
対象はアマチュア無線（AX.25／NET/ROM／ROSE）サブシステム、ISDNサブシステムとBluetooth CMTP、CAIFネットワーク層、旧ATMプロトコルと関連ドライバー、そして3Com・AMD Lance・SMSC・富士通FMVJ18X・8390系といったISA／PCMCIA時代のイーサネット・ドライバー群だ。パケット通信の黎明期を支えたAX.25プロトコルもここで姿を消す。
この決断は、突発的なものではない。Kicinskiがプル・リクエスト本文で吐露した事情は、メンテナーの悲鳴そのものだった。
「LLM黙示録」を生き延びるための3つの策
Kicinskiはメール冒頭で、投稿の速度が変わったことに触れ、それに対応するため並行して3つの施策を進めていると書いた。より賢いLLMコードレビュー・ツールの整備、新参者を導きつつ必要なら投稿を抑制するメール・ボットの運用、そして長らく孤児状態になったコードの削除だ。今回のプル・リクエストは3番目にあたる。
元の英文ではLLM-pocalypse（LLM黙示録）という造語まで飛び出していた。カーネル・メンテナーの用語としてはかなり率直だ。
「アマチュア無線やNFCのような古いコードは、長年コア・ネットワーク開発者の負担になってきた。syzbotはBKL時代のコードでバグを見つけるのが大好物で、新参者がそのバグを修正しようと飛びついてくる。」
Kicinskiが挙げたsyzbotはGoogleが運用しているカーネル・ファザー（fuzzer）で、自動でバグを掘り当ててはLKMLに投稿する。BKL（Big Kernel Lock）時代のコードとは、90年代から2000年代初頭に書かれた、今となっては触る人のいないコードのことだ。そこにLLMが加わった結果、報告は増え、直す人は増えない。
Sashikoの登場と「魔法の弾丸」の不在
Kicinskiの文章でとりわけ興味深いのは、LLMレビュー・ツールの使いこなしについての赤裸々な告白だ。彼はローカル・プロンプトを調整してみたが限界が見えてきたと書き、Sashikoと比較してSashikoが見つけるバグの半分以上を見落としていると認めた。
Sashiko（刺し子）は日本の補強刺繍の名を冠した、Googleが開発しLinux Foundationに寄贈したAIコードレビュー・システムだ。Roman Gushchin（以下、Gushchin）がLKMLで今年3月に発表した。Gemini 3.1 Proを使い、過去1000件の修正コミットを試したところ53.6%のバグを検出した。しかもそのバグは全て人間のレビューを通過したものだという。
Kicinskiは続けて、Sashiko＋Geminiの組み合わせは実在するバグを多く見つけるが、周辺の瑣末な問題や偽陽性も同時に報告してくると述べた。共同メンテナーのPaolo Abeniの見解として、LLMの出力を確認する作業に時間の約4割が費やされているとKicinskiは伝えている。さらに彼はSashikoとClaude、それに意味解析ツールsemcodeを組み合わせた手作りの仕掛けを試し、偽陽性は大幅に減ったが、今度はGeminiが見つけていた本物の問題を取りこぼしたと報告した。
「希望していた魔法の弾丸は、まだ見つかっていない。」
言い換えれば、どのAI構成も何かを拾い、何かを落とす。複数を回せば重複と食い違いが同時に発生し、人間の判断負荷は減らない。
「使っているのか、思い出に浸っているだけか」
削除理由の説明はさらに踏み込んでいく。アマチュア無線コードは偶に使う人がいたかもしれないが、多くのユーザーはとうにユーザー空間の実装に移っていると彼は書いた。上流のカーネルを直接使う人はごくわずかで、メンテナーとして名乗り出る人もいない。
これまで削除議論が起きるたびに「残してほしい」という声は上がってきたが、Kicinskiは率直に書いている。その人たちが実際に使っているのか、単にコードが消えるのが寂しいだけなのかが判然としないのだ。この「判然としない」という言い方に、長年のメンテナーが背負ってきた微妙な疲労が滲む。
一方で朗報もある。NFCサブシステムは引き取り手が見つかったため生き延びる。つまり今回は「人が付けば残す」という判断基準が貫かれている。
誰が損をして、誰が得をするのか
削除されるドライバーの多くは1990年代のISA／PCMCIA時代のイーサネット・カードのためのコードだ。3C509、NE2000互換のWD80x3、SMSC SMC9194、AMD Lance、富士通FMVJ18X。名前を聞いてピンと来る人は、かなりのベテランだろう。今日のハードウェアとしては現実的な選択肢ではなく、ほとんどのユーザーには体感できる影響はない。
しかし、AX.25サブシステムの撤去は別の層に響く。アマチュア無線のパケット通信でLinuxを使い続けてきた少数の実用ユーザー、博物館的な環境を維持している愛好家、古い機器のデバッグ用に現役カーネルを使っていた教育現場。こうした人々には、最新カーネルへのアップグレードを諦めるか、モジュールとして外部リポジトリから取り込む必要が生じる。Kicinskiは「可能なものはGitHubリポジトリに移した」と書いており、完全な廃棄ではなく、メインライン（mainline）からの退場だ。
AIが作り、AIが壊す力学
この決定を、AIがカーネル開発を壊している証拠と読むこともできるし、逆にAIが開発プロセスを成熟させている証拠と読むこともできる。どちらの読みにも一理ある。
擁護する立場の論理はこうだ。syzbotもSashikoも、実在するバグを見つけている。人間のレビューを通過した欠陥が、機械には見える。これは明らかな進歩だ。ただし速度が速すぎて、人間の処理能力を超えた。処理能力を超えた分野のうち、誰も使っていない古いコードは「撤去」で対応するしかない。これは合理的な選別に見える。
批判する立場の論理もある。Linuxの強みは長年、古いハードウェアでも動くという後方互換性だった。AI報告への対応コストを理由に古い資産を切り捨てる判断は、Microsoftが何度となく繰り返してきた「古いものを切る」文化にLinuxが近づいている兆候でもある。Tom's Hardwareのコメント欄では、まさにその懸念を口にする読者がいた。
そしてもう一つの視点は、AIに作業を任せる立場の倫理だ。カーネル開発者はLLMの出力を検証する作業だけに、時間の約4割を取られている。この時間はLLM提供企業ではなく、ボランティア開発者の負担として計上されている。Sashikoはトークン代をGoogleが負担しているが、査読の人的コストは誰も肩代わりしない。
次の13万行はどこから来るか
注目すべきは、Kicinskiがこれを「3つ並行する施策の1つ」と位置付けていることだ。残り2つ、つまりLLMレビューツールの改良とメール・ボットによる投稿制御はまだ途中であり、今回の削除だけでは問題は終わらない。
他のサブシステムの保守担当者たちも、この13万行の削除を注視している。同じ理屈は、グラフィックス・ドライバーの旧世代サポートにも、ストレージ・スタックの化石コードにも、音声サブシステムの骨董品にも当てはまる。AIが古いコードを睨み続ける限り、削除提案は繰り返し浮上する。
かつてトーバルズは「ユーザー空間を壊してはならない」と声を荒げてきた。しかし、ユーザー空間に出ていった古いプロトコルのカーネル実装は、今や「壊してもよい」領域に分類されつつある。この分水嶺がどこまで広がるのか、その答えはまだ誰も持っていない。
魔法の弾丸はないとKicinskiは書いた。だからこそ、銃弾の届かない場所にある古いコードは、音もなく役目を終える。これが2026年のLinuxが選んだ答えだ。
参照元
他参照
