AIコードレビューでLinux 7.2-rc7に400件超の修正、ボトルネックは人手によるトリアージへ

Linuxのリリース候補版は、正式リリースが近づくにつれて変更規模が徐々に縮小するのが通例だ。しかし7.2-rc7には依然として400件を超える修正が取り込まれ、230人以上のコントリビューターが関与した。Linus Torvaldsは、この比較的多い修正件数を、各種AIレビュー・ツールによって生まれた「新常態」と表現している。変更はドライバー、ファイルシステム、ネットワーク、アーキテクチャ関連コードに分散しており、単一の重大なリグレッションが原因ではない。ここでのAIの主な役割は、既存のコードやレビュー待ちのpatchをスキャンして疑わしい箇所を指摘することだ。修正については、引き続き人間が作成または確認し、サブシステムのメンテナーによる審査と通常のマージ手続きを経る必要がある。

代表的なツールであるSashikoはRustで実装され、LKMLメーリングリストを監視しながら、段階的なプロトコルを用いてアーキテクチャ、セキュリティ、リソース管理、並行処理などの専門的なレビューを模擬する。メンテナーは以前、`Fixes:`タグが付いた既知の問題1,000件をGemini 3.1 Proでバックテストし、元のレビューで見逃されていたバグの約53%を発見できたとしている。このサービスはすでに数万件のpatchsetを処理している。ただし、これはプロジェクト側による自己評価であり、推定される誤検知率は依然として約20%に達する。また、複数のツールが同じ問題を繰り返し報告すると、機械処理で節約した時間がメンテナーのトリアージコストへと転化してしまう。

エンジニアリングチームにとって重要な変化は、「AIがLinuxを書き始めた」ことではなく、コードレビューのスループットに不均衡が生じたことだ。モデルは潜在的な欠陥を並列に大量生成できる一方、人間は依然として問題を再現し、影響を判断し、重複を排除したうえで、修正に対する責任を負わなければならない。今後注目すべきなのは、報告に実行可能なreproducerが添付されるか、公開済みの問題やマージ済みの修正との重複を事前に排除できるか、そして各サブシステムが異なる誤検知の許容基準を採用するかどうかだ。rc7のコミット数だけでは、すべての修正がAIによって発見されたとは証明できず、patchの増加をそのままカーネルの安全性向上と同一視することもできない。