LinuxカーネルのstagingがLLMパッチを自動拒否へ。例外はセキュリティ修正のみ
Linuxカーネルのナンバー2が、新人開発者の学びの場にLLM生成パッチが殺到している現状に線を引いた。
Linuxカーネルのナンバー2が、新人開発者の学びの場にLLM生成パッチが殺到している現状に線を引いた。
ジムにフォークリフトを持ち込むな
Linuxカーネルにはdrivers/staging/と呼ばれる領域がある。
本流にはまだ入れられないドライバを一時的に収容する場所だが、それだけが目的ではない。コードの整理やAPIの変更など、手が届きやすい作業が大量に残されており、カーネル開発に初めて参加する人が実戦の中でプロセスを学ぶための練習場として機能してきた。
ここに置かれたコードをカーネルにロードするとTAINT_CRAPフラグが立つ。品質は保証しない。だが学ぶ場としては開いている。そういう約束で成り立っている空間だ。
そのstagingに、LLMが生成したパッチが押し寄せている。
グレッグ・クロー＝ハートマン（Greg Kroah-Hartman）氏が現地時間8月3日、Linuxカーネルのメーリングリストに新しい方針を投稿した。drivers/staging/に投稿されるLLM生成パッチを今後自動的に拒否するという宣言だ。
クロー＝ハートマン氏はLinux Foundationのフェローであり、stableカーネルのリリース責任者にしてstagingの管理者でもある。トーバルズ氏に次ぐ存在だ。
氏はその投稿で、LLMによるコード整理や修正がstagingの存在目的を「明確に無効化する」と述べている。
stagingにある「ここを直せ」という類の課題を、LLMに代わりにやらせれば効率は上がる。だがそれは、重量挙げをロボットに任せてジムに通ったと言い張るのに等しい。腕が太くなるのは自分で持ち上げた人だけだ。
セキュリティ修正という唯一の例外
全面拒否ではない。1つだけ例外がある。
LLMがstagingのコード内にセキュリティ上の問題を発見し、それが本物であれば、修正パッチの提出は認められる。ただし条件がある。実際のハードウェアでドライバをテストし、どうテストしたかを説明し、提出の正当性を自ら守れなければならない。
背景にはLLMの精度の問題がある。LLMはカーネルコード内の疑わしい箇所を見つける能力を既に持っているが、最良のモデルでも結果の少なくとも3分の1は誤りか有害だとクロー＝ハートマン氏は指摘した。テストと検証の工程は、その3分の1を除外するためにある。
LLMの使用を隠して提出しても見抜けるとも警告している。意図的にメンテナーを欺こうとする者には、これが事前の警告だ、と。
急増する新規貢献者の影
今年に入り、カーネル開発コミュニティに異変が起きている。
Linux 7.0（2026年4月リリース）では、初回貢献者がそれまでの水準から約50%急増した。続くLinux 7.1（同年6月リリース）では新規貢献者が530人に達し、7.0が記録した489人を更新した。LWN.netのジョナサン・コルベット氏はこの増加をLLMベースの開発ツールの普及にほぼ直結すると分析している。7.1で新規開発者が最も多く触れた領域の5番目が、まさにdrivers/stagingだった。47人の新規開発者がこの練習場に入っている。
数字はそれだけではない。7.0でAssisted-byタグ（LLMの使用を示す開示タグ）を付けたコミットは31件だった。7.1では299件に跳ね上がった。コルベット氏は、規則に従わず開示していない開発者が相当数いることを指摘しており、LLMが関与した実際のコミット数はさらに多い。
新規貢献者が増えること自体は歓迎すべき変化だ。だがその増加が、LLMにコードを書かせて投稿ボタンを押しただけの行為に支えられているとすれば、コミュニティにとっては量が増えても質の担い手は増えていない。
仕事とジム
クロー＝ハートマン氏は投稿の中で、セキュリティ研究者ブルース・シュナイアー氏が7月30日にThe Guardianに寄稿したエッセイを参照している。
シュナイアー氏はそのエッセイで「仕事とジム」という枠組みを提示した。荷物を部屋の端から端へ運ぶ仕事なら、フォークリフトでもロボットでも使えばいい。だがジムで他人に重りを持ち上げさせても筋肉はつかない。
同じ原理がAIの使い方にも当てはまる。成果物が必要なだけの作業（仕事）ならAIに任せてもいい。だが、やること自体に意味がある作業（ジム）では、AIに委ねた時点で目的が消える。
stagingは「ジム」だ。カーネル開発のプロセスを身につけるための場所であり、きれいなコードを生産するための場所ではない。コードの問題点をあえて残しているのも、そこから始めて学び、成長してもらうためだ。
LLMにそれをやらせれば、きれいなコードは手に入るかもしれない。だが、カーネル開発者は育たない。
矛盾ではなく、境界線
3週間前、トーバルズ氏はメーリングリスト上で明言した。Linuxは反AIプロジェクトではない。AIは道具であり、嫌なら fork（分岐）しろ、と。staging以外の領域では、AI/LLMで生成したコードは引き続き許容されている。人が検証し、署名し、責任を負う限り、何を使うかは問わない。
クロー＝ハートマン氏自身も、別の場面ではLLMを使っている。氏が拒否したのはLLMそのものではなく、学びの場への侵食だ。
カーネル開発のコミュニティはこの半年、AIとの境界を1本ずつ引いてきた。4月には公式のAI利用ガイドライン（coding-assistants.rst）がマージされ、5月にはAIで発見したバグの扱いを定めた文書（threat-model.rst）が加わった。7月にはAssisted-byタグの運用見直しが議論され、トーバルズ氏のAI容認宣言が続いた。
2026年4月 AI利用ガイドラインを正式採用 Assisted-byタグの開示規則を含む59行の文書がマージ 2026年4月 Linux 7.0で初回貢献者が約50%増 489人の新規参加。LLM開発ツールの普及が背景 2026年5月 AIで発見したバグの公開ルール追加 同一バグが複数の研究者に同日到達する時代への対応 2026年6月 Linux 7.1で新規貢献者530人 Assisted-byタグ付きコミットは31件→299件に急増 2026年7月 トーバルズ氏「反AIではない」宣言 AIは道具であり嫌なら分岐しろ、と明言 2026年8月 stagingでLLMパッチを自動拒否 新人の学びの場を守るため。セキュリティ修正のみ例外 |
そして8月、No.2がstagingにだけ壁を立てた。
道具としてのAIは歓迎する。だが、人が自分の手で学ぶ場所には持ち込むな。世界最大のオープンソースプロジェクトが出した、現時点での答えだ。
