Linuxカーネルのメモリ管理で長年レビューを担当してきたLorenzo Stoakes氏が、5つの領域でレビュアー登録を削除するパッチをメーリングリストに投稿した。理由として挙げたのは、AI生成パッチの流入によってレビューに割ける時間が不足していることだ。今回辞退したのはレビュアーとしての役割であり、メンテナとしての職務を離れるわけではない。Linuxカーネル開発では、AIによるコード生成の普及に伴って人間のレビュー負担が増しており、今回の判断もその影響をうかがわせる。

AD

AI生成パッチの急増を受け、5領域のレビュアーを辞退

Stoakes氏は11月10日（UTC）、4本のパッチをLinux Kernel Mailing List（LKML）に投稿した。このうち3本は、担当領域ごとのメンテナやレビュアーを記載した「MAINTAINERS」ファイルから、自身のレビュアー登録を削除するものだ。削除するのは1本目が1行、2本目と3本目が各2行の計5行で、対象はメモリ管理の中核、その他のメモリ管理、メモリ回収（reclaim）、Rust向けメモリ管理、Rustのアロケータとなる。残る1本は「CREDITS」ファイルに、THP（Transparent Huge Pages、透過的巨大ページ）の共同メンテナを務めた経歴を6行追加する内容だ。THPについてはZi Yan氏が後任となったため、自身が復帰する必要はないと説明している。

MAINTAINERSファイルでは、「M:」がメンテナ、「R:」がレビュアーを表す。今回削除されたのは5つの「R:」行のみで、メンテナとしての登録は変更されていない。Stoakes氏はパッチのカバーレターで、AI生成のパッチ系列が大量に流れ込む現状では、自身が保守する領域以外のレビューまで引き受ける余裕がないと説明した。今後はメンテナとして責任を負う領域に作業時間を集中させる方針だ。

11月11日にこの件を報じたTom's Hardwareは、THPも辞退の対象として扱っている。ただし、実際のパッチを見ると、THPについてはレビュアー登録の削除ではなく、過去の貢献をCREDITSファイルに記録する変更であり、ほかの5領域とは異なる。また、Stoakes氏はメーリングリストでの返信で、AI生成パッチが増えてきた経緯にも言及している。当初は質の低いAI生成物、いわゆる「AIスロップ」を時折見かける程度だったが、やがて週に1回以上、数日に1回と頻度が高まり、現在では目にするパッチの半数、場合によってはそれ以上を占めるという。ただし、これは統計的な調査結果ではなく、同氏自身の経験に基づく印象である。

ネットワークでは最大半数がAI主導か、無線やstagingでは受け入れを制限

AI生成パッチの増加による負担は、Linuxカーネルのほかの開発領域でも問題になっている。ネットワーク担当のKicinski氏は、Linux 7.3向けのpull requestで、共同担当のPaolo氏とともにマージした変更の件数を報告した。内訳は「net」が632件、「net-next」が648件で、このうちnet-nextの3分の1から半数は、AI主導とみられる優先度の低い修正やコード整理だという。この発言は、Phoronixが2026年8月20日に報じている。

Linux 7.3のnet-nextでマージされた変更のうち、AI主導と推定される件数

net-nextの総件数

648件

AI主導とみられる件数

約216〜324件

約33〜50%がAI主導と推定全648件

出典：Kicinski氏の概算に基づく計算。AI利用の有無を個別に検証した統計ではない。

648件の3分の1は216件、半数は324件に相当する。ただし、Kicinski氏自身が大まかな推定であると断っており、AI主導とみられる変更を厳密に分類した数字ではない。また、この割合はマージされたnet-nextの変更に関するもので、投稿されたパッチ全体や、net側の632件に当てはまるわけではない。

一方、無線サブシステムでは、レビュー対象を厳しく選別する動きが出ている。担当者のJohannes Berg氏は、syzbotが生成したAIパッチについて、3秒程度の確認で明らかに正しいと判断できるものを除き、ほぼすべて無視する方針をLKMLで表明した。LLMが生成したパッチに通常のレビューコメントを付け、修正を求める議論を続けるつもりはないという。Phoronixは8月6日、この方針を報じるとともに、stagingサブシステムでもセキュリティ修正を除くAI・LLM生成パッチの受け入れを拒否するようになったと伝えている。

こうした対応には、それぞれ違いがある。Stoakes氏は担当するレビュー領域を減らし、Berg氏はAI生成パッチの大部分を確認対象から外し、stagingでは原則として受け入れを拒否する。いずれも、限られた人的資源を優先度の高い作業に振り向けるための措置といえる。ただし、Stoakes氏はパッチの受け入れ自体を制限したわけではなく、必要に応じてほかの領域もレビューする可能性を残している。また、ネットワーク担当のKicinski氏は、AIを排除するのではなく、レビュー作業に活用する方向も模索している。

AD

AIを使ったレビュー効率化も進むが、人間の確認は不可欠

Stoakes氏は今回の変更について、メーリングリストで「純粋に事務的な措置」と説明している。レビュアー登録を外しても、結局はこれまでと同じように多くのパッチをレビューすることになるかもしれないという。また、KVM（Kernel-based Virtual Machine）関連の仕事で多忙になったことも理由の一つに挙げており、辞退の原因をAI生成パッチだけに求めることはできない。ただし、同じ返信ではAI生成パッチの急増を深刻な問題として捉え、状況はさらに悪化しているとも述べている。レビューの負担が増しているという認識自体は、今回の変更理由と一貫している。

こうした問題に対し、AIをレビュー作業に取り入れる動きも進んでいる。Kicinski氏はMetaの支援によってLLMの利用枠を確保し、各パッチを複数の最先端モデルでレビューしていると説明した。今後はPatchworkによるパッチ管理やコミットメッセージの編集など、付随する事務作業にもLLMを活用したい考えだ。ただし、AIがレビューで担える作業には限界があるとも認めている。また、LWNの7月21日付記事では、Ted Ts'o氏がAIレビューツール「Sashiko」について、自身の作業負荷を減らす効果に期待していることが紹介されている。

AI支援によるパッチ作成が必ずしも問題視されるわけではないことも、過去の事例から分かる。LWNの7月2日付記事は、LLMを活用した2つの大規模パッチ系列に対する開発者の反応を比較している。Kiryl Shutsemau氏のパッチ系列は7回の改訂を経ており、LLMの利用そのものがレビューで問題になることはなかった。同氏は投稿前に生成コードを自ら8〜10回確認したと説明しており、LWNも受け入れ可能なパッチ系列になり得ると評価した。一方、Rik van Riel氏が提出した40本のパッチ系列について、Stoakes氏は「現状ではマージ不可能。近くすらない」と厳しく批判した。

両者の違いについて、LWNはAIツールの利用そのものではなく、提出前に人間がどれだけ手間をかけたかが重要だったと分析している。AIを使っていても、開発者自身がコードを十分に検証し、レビューで指摘された問題に対応していれば、受け入れられる可能性はある。反対に、十分な確認を経ていないパッチが大量に投稿されれば、その検証作業はカーネルのレビュアーに押し付けられる。問題の中心にあるのはAIの利用そのものよりも、生成されたコードの品質と、それを確認する人間の負担だ。

今回確認されたメモリ管理、無線、staging、ネットワークの事例は、AI生成パッチの増加に対する対応が一様ではないことを物語っている。レビューの対象を絞る開発者がいる一方で、AIを使ってレビューの効率化を図る開発者もいる。いずれの方法も、人間のレビュー時間が限られているという共通の課題に対する取り組みだ。ただし、これらの事例だけでLinuxカーネル開発全体の傾向を判断することはできず、各サブシステムでの対応が今後も続くかを確認する必要がある。

Stoakes氏が辞退した5領域のいずれかでレビュアー登録が復活したり、無線やstagingでAI生成パッチに対する制限が緩和されたりすれば、現在の対応方針が変わったことになる。また、Kicinski氏が今後のネットワーク更新でもAI主導とみられる変更の割合を公表すれば、パッチの流入状況を比較する手掛かりになる。ただし、同じ基準による推定が続くとは限らず、割合の変化だけでAIレビューの効果を評価することは難しい。

Linuxカーネルはサーバーから組み込み機器まで幅広い製品の基盤となっており、レビュー体制の変化は修正パッチの受け入れや提供速度にも影響し得る。今後の焦点は、AI生成パッチの受け入れを制限する方法と、AIによってレビューを効率化する方法のどちらが、コードの品質を維持しながら開発者の負担を軽減できるかにある。単に処理できるパッチの件数を増やすだけでなく、問題のある変更を確実に見つけ、人間の確認作業を減らせるかが重要になる。