Linuxカーネル7.2の開発終盤で、AIを使ったコードレビューが修正の流れを変え始めた。Linus Torvalds氏が8月9日に公開した第7リリース候補（rc7）には500コミットが入り、前週のrc6は615コミットに達した。Torvalds氏は、この大量の修正の多くが各種AIツールによるレビューに起因すると説明し、規模の大きなリリース候補を「新常態」と呼んだ。焦点はAIが何行書いたかではなく、AIが見つけた問題を人間がどこまで検証し、正式版の前に安全に取り込めるかへ移っている。
615コミットのrc6、500コミットのrc7
異変がはっきりしたのは8月2日のrc6だった。Torvalds氏は告知を「このrcは巨大だ」と切り出し、少なくともコミット数では過去数年で最大のrc6だと説明した。Torvalds氏の公式GitHubミラーでタグ間を比較すると、rc5からrc6までに615コミットが加わっている。マージウィンドウを閉じて新機能の投入を終えた後としては、目を引く量である。
しかも、増加は翌週も収まらなかった。8月9日のrc7にも、rc6以降の500コミットが入った。rcは正式版へ進む前に修正を検証する候補であり、番号が後ろへ進むほどリリース判断が近づく。それでも7.2は2週続けて大きな修正群を抱えた。Torvalds氏は規模に「喜んでいるとは言えない」としながらも、多数の修正を抱える状態を新常態として受け止めている。
ここで615と500が表すのはコミット数である。変更したコードの行数でも、見つかった脆弱性の数でもない。小さな境界チェックの追加と、大きな基盤の作り直しはどちらも一つのコミットとして数えられるため、規模の数字から危険度や品質を直接判断することはできない。
生成コードより先に、AIレビュー後の修正
rc7告知でTorvalds氏が結び付けたのは、AIによるコード生成とコミット増ではない。「修正の多く」が各種AIツールのレビューによって生じた、という関係である。AIがパッチを大量に書き、それがそのままLinuxへ入ったという意味にはならない。ツールが問題を指摘した後には、修正案の作成、テスト、担当メンテナーの確認、署名を伴うマージが残る。
AIレビュー由来の正確な件数や、使われたツール別の内訳は示されていない。したがって、rc6の615件やrc7の500件を「AI修正の件数」と読み替えることもできない。Torvalds氏の説明から確定できるのは、複数のAIレビューが無視できない数の修正を生み、その結果がリリース候補全体の規模に表れたことまでだ。
レビューの入口とパッチの作者も分けて考える必要がある。AIツールが境界条件や資源解放の漏れを指摘しても、どの修正を採るかはコードの文脈と再現試験を踏まえて決める。問題発見にAIを使ったという記録は、元のコードや修正コードをAIが生成した証拠にはならない。今回のコミット増が語るのは、発見能力の拡張と、その後に必要な人間の作業量である。
それでも変化は大きい。Linuxの公式ガイドラインは、ツールが貢献量を増やし得る一方、レビュー担当者とメンテナーの時間は希少だと見る。問題発見の量が増えても、指摘を確かめ、妥当な修正へ変える仕事は残る。AIレビューは検証を消すのではなく、検証すべき候補を増やす装置としてLinux開発へ入り込んでいる。
なぜ大きくても延期しないのか
rc7の500コミットは広い範囲に散らばっている。Torvalds氏によれば、大部分はGPU、サウンド、ネットワークなどのドライバに加え、ファイルシステム、コアネットワーク、アーキテクチャコードへ入った小さな修正だ。特定の中核機能を一度に置き換える変更群ではないため、コミット数の大きさがそのままリリース延期の理由にはならなかった。
比較的大きな変更もある。Torvalds氏はIBM Z向け暗号処理を担うs390/zcryptの修正、btrfsでfixup worker基盤を復活させる変更、netfilterのipset修正を挙げた。ただし、これらを含めても「特に恐ろしいものは見当たらない」と判断している。数が多いことへの警戒と、個々の変更に延期を要する異常がないという評価は両立する。
前週のrc6も構成は似ていた。60%弱がドライバ、20%がネットワーク、残る20%がアーキテクチャ、ツール、ファイルシステムなどである。ネットワークの一部はカンファレンス時期にたまった作業の反映だった。Torvalds氏はこの時点でも変更の大きさに不安を示したが、リリースを遅らせる兆候はないと述べていた。
つまり、7.2で採られている基準は単純な件数の上限ではない。変更が局所的か、テスト可能か、重大な回帰の兆候があるかを見ている。500件の小修正を抱えたrc7より、サブシステム全体を壊す一件の回帰の方が、日程には強く効く。
ツールが増やす量と、人が引き受ける責任
Linuxの公式ガイドラインは、AIを含むツールが貢献量を増やし得る一方、レビュー担当者とメンテナーの時間は希少だと明記している。ツールが問題を検出した場合は、その事実を変更履歴に記す。何を使い、どの部分へ影響し、どうテストしたかを開示することも推奨される。AIレビューの成果を取り込むほど、由来を追える記録が必要になる。
ガイドラインが対象にするのは、チャットボットが生成した関数に限らない。従来型の修正ツールが提案した変更、ツールが書いた変更履歴、問題の検出や修正後のテストも開示の対象に含む。AIだけに別の入口を設けるのではなく、ツールが開発判断へ実質的に関わったかを基準に透明性を求めている。
責任の所在も変わらない。投稿者は提出内容を理解し、レビューで説明できなければならない。メンテナーは通常の変更として扱うほか、追加テストを求め、優先度を下げ、内容を確認できなければ却下できる。AIが問題発見の量を増やしても、Linuxへ入れる判断を自動化する規則にはなっていない。
8月10日時点で、kernel.orgが掲載するmainlineは7.2-rc7である。Torvalds氏は重大な問題が出なければ翌週末、日付にすれば8月16日前後の正式リリースを見込む。AIレビューが生んだ大量の小修正を「新常態」として維持できるかは、最後の週に変更量が落ち着き、500コミットの後に重大な回帰が見つからないかで決まる。
