トーバルズが決断したLinuxカーネルのAIルール：あなたが全てのコードの責任者だ

トーバルズのアプローチは、彼らしい率直さだ。彼はドキュメントでAIについて延々と議論することを「無意味なポーズ」と呼び、そもそもドキュメントはAIスパムを提出するような人間のためではなく、「善良な開発者」のためにあると述べている 。真の防御策は「誰でもゴミを送りつけることはできるが、メンテナーはそれを無視できる」ということだと彼は主張する 。このポリシーは、したがって、悪意のある行為者を止めるためではなく、善良な行為者が責任を持って行動するためのフレームワークを作るために、メンテナーを支援するよう設計されている。

限界点：AIバグスパムの「管理不可能」な洪水

コード提出ポリシーが先制的だったのに対し、セキュリティ報告ルールは危機への直接的な反応だった。2026年5月、トーバルズはLinuxカーネルの非公開セキュリティメーリングリストが「ほぼ完全に管理不可能」になったと公に発表した 。原因は、AIが生成した脆弱性レポートの圧倒的な量だった。

これらは質の高い発見ではなかった。彼らが分析していると主張するコードを理解していない人々からの、場当たり的で、しばしば重複した、あるいは完全に幻覚（ハルシネーション）による報告だった 。トーバルズはこれらを、問題が既に修正されているかどうかを確認したり、調査対象のサブシステムを理解したりすることなく、報告を送りつけて姿を消す「ドライブバイ・コントリビューター（ひき逃げ貢献者）」からのものだと表現した 。

更新されたドキュメントは、今やシンプルなルールを義務付けている。AIツールを使用して潜在的なバグを発見した場合、それを公に、関連するメンテナーに報告しなければならない。非公開のセキュリティリストへの報告は禁止され、報告はプレーンテキストで簡潔に行い、バグを再現するための検証済みの方法を含める必要がある 。トーバルズの希望はさらに強い。彼は、本当の問題を発見したコントリビューターには、単に報告を送るだけでなく、問題を深く理解し、修正パッチを提出してほしいと考えている 。

AIがオープンソースにもたらす3つの頭痛の種

Linuxカーネルの2つのポリシーは、AI生成コードがすべてのオープンソースプロジェクトに提示する、より大きな課題の縮図である。セキュリティメーリングリストの危機と厳格な責任ルールは、3つの構造的問題を浮き彫りにしている。

1. 大規模なメンテナー燃え尽き症候群

オープンソースのメンテナンスは、既に限られたレビュー帯域幅の中で、燃え尽き症候群のリスクが高い活動だ。AIツールは提出物の量を桁違いに増加させるが、それを評価するために利用可能な人間の時間は変わらない 。シグナル対ノイズ比は崩壊する。カーネルの答えはトリアージ（優先順位付け）への賭けだ。ルールを明確にして、低品質のAI生成コントリビューションを迅速に、そして謝罪なく却下できるようにするのである。

2. 責任の空白

従来のオープンソースの品質保証は、開発者の評判とDCOの法的コミットメントに依存している。AIエージェントはそのどちらも提供しない。一見正しそうに見えるが、微妙に間違っていたり、盗用されたりしたコードを生成する可能性がある。カーネルの解決策は、すべての責任を人間の提出者に固定し、悲惨なパッチの責任をAIに転嫁することを不可能にすることだ 。しかし、これは、より小規模で構造化されていない多くのプロジェクトが再現したり強制したりすることが難しい、ガバナンス上の負担を人間に課すことになる。

3. LLMの分かれ道：Copilotは許容、「スロップ」は排除

新ポリシーの注目すべき詳細の一つは、特定の例外措置だ。Microsoftが所有するAIコーディングアシスタントであるGitHub Copilotは、カーネルへのコントリビューションでの使用が明示的に承認されている 。メンテナーが引いた線は、「AI」対「人間」ではなく、慎重な支援付き開発と無責任な自動化の間にある。「AIスロップ」という用語は、後者を指す公式な略語となった 。これはコントリビューターにとって、同じツールが責任を持って使用されることも無謀に使用されることもあり、両者を区別するのは人間の開発者に対するコミュニティの信頼だけという、居心地の悪い新たな現実を生み出す。新しいポリシーはこの問題を完全には解決しない。それは、開発者とメンテナーが自分たちで解決するように責任を手渡しているのだ 。