Linus Torvalds氏は2026年5月24日、Linux 7.1-rc5を公開した。その告知で目立ったのは、新機能や個別修正の一覧よりも、リリース候補の後半に入ってもなお変更量が大きいことへの警告だった。Torvalds氏はrc5について、従来のrc5よりかなり大きいと述べ、その多くがランダムなドライバ周辺の軽微な修正であるため恐怖感は小さい一方、rc5の時点でその変更量に見合う価値があるとは思えない、という趣旨を示した。
今回の発言で重要なのは、AI支援を使ったコード投稿を一律に否定したわけではない点だ。Torvalds氏が問題にしたのは、AIコードレビューをきっかけにした複数の修正系列を含め、リリース候補後半に持ち込むには重要度が低い変更が増えていること。つまり論点は「AIが書いたかどうか」だけではなく、「その変更は今マージすべきなのか」というカーネル開発の時間軸にある。
rc5で問題になったのは、修正の正しさより提出時期だった
Torvalds氏は、問題の変更を「修正」であること自体は認めている。だが、多くは長く残っていた緊急性の低い問題であり、linux-nextに置いて次のマージ期間で取り込むほうが良い、という判断を示した。Linuxカーネルでは、次期リリースへ入れたい変更を集中的に受け入れるマージ期間の後、複数のリリース候補を通じて安定化を進める。rc5はその後半にあたり、本来なら新しい変更の量が落ち着き、回帰の修正に重心が移っているべき段階である。
この文脈では、軽微な修正でも意味が変わる。開発序盤なら歓迎される掃除や古い不具合の修正でも、rc5では「いま触らなくてよい箇所を触る変更」になり得る。Torvalds氏は、今後はこの種の不要な変更により厳しくなり、重要でない修正を含むプルリクエストには押し返す、と予告した。ここでの基準は、修正が存在するかではなく、それが回帰か、またはリリース候補後半に入れるほど深刻かなのだ。
この件について、一部では「AI生成コードへの怒り」と要約されがちだが、実際のTorvalds氏の投稿を読むと焦点はもう少し実務的だ。AIコードレビューが古い不具合候補を見つけ、それがパッチ系列として提出されることはある。しかし、見つかった問題が本当に今回のリリースを止めるべきものなのか、次の開発サイクルへ回すべきものなのかを判断する責任は、ツールではなく提出者とメンテナーに残る。
「低リスク」は「ゼロリスク」ではない
Torvalds氏がrc5の大きさを問題視した理由は、単なる管理上の美学ではない。彼は、軽微な修正は問題を起こす確率が低いとしても、低いことはゼロではないと説明した。リリース候補の後半で小さな変更が大量に入ると、一つひとつの危険度は低くても、全体として安定性確認の面積が広がる。
Linuxカーネルのような巨大プロジェクトでは、この積み上がりが重要になる。多数のサブシステムやドライバにまたがる修正では、あるドライバの局所的な変更が、そのハードウェアだけに閉じるとは限らない。ビルド構成、依存関係、サブシステム間の相互作用があるため、見た目が小さい変更でも検証対象は増える。
そのため、rc5段階での判断軸は「この修正は正しいか」だけでは足りない。「この時点で入れることで、リリース全体の安定化に本当に寄与するか」まで問われる。Torvalds氏が求めたのは、投稿者がプルリクエストを出す前に、その変更が回帰修正なのか、深刻な問題なのか、それとも開発用の積み残しへ回せるものなのかを見直すことだった。
希少資源はメンテナーの注意力
今回のrc5発言は、前週に報じられたAI支援のバグ報告問題ともつながっている。Linux 7.1-rc4の文脈では、AIツールを使った報告が重複し、セキュリティ関連のリストがほぼ管理不能になっているというTorvalds氏の不満が取り上げられた。複数の人が同じツールで同じコードを調べれば、同じ問題候補が何度も上がる。さらに、すでに修正済みの話題や公開の議論へ戻せば済む報告でも、メンテナーは確認と誘導に時間を使う。
rc4で問題になったのは報告の流量であり、rc5で問題になったのはパッチの流量である。どちらにも共通するのは、AIが候補を増やすことで、最終判断を担う人間側の処理量が増える点だ。AIは疑わしい箇所や機械的な修正案を大量に見つけられる。しかし、その候補が既知の問題か、既に直っているか、今回のリリースで扱うべきか、設計上正しい直し方かまでは、プロジェクトの文脈を読まなければ判断できない。
これは、AI支援の価値を否定する話ではない。むしろ、AIによって発見候補の量が増えたからこそ、提出者が「候補」を「貢献」に変える工程の重要性が増している。候補のまま投げれば、メンテナーの受信箱を埋める。背景を確認し、既存議論を読み、適切な時期と形に整えて出せば、同じAI支援でもプロジェクトへの負荷は大きく変わる。
カーネルのAI方針は、禁止ではなく人間の責任を明確にしている
Linuxカーネルの公式ドキュメントにも、AIコーディング支援に関する方針が用意されている。そこでは、AI支援を使う場合でも通常のカーネル開発プロセス、コーディング規約、パッチ提出手順に従う必要があるとされている。ライセンス面では、すべての貢献がGPL-2.0-onlyと互換でなければならず、適切なSPDXライセンス識別子も必要になる。
特に重いのが署名の扱いだ。公式文書は、AIエージェントがSigned-off-byタグを追加してはならないと明記している。Developer Certificate of Origin、つまりDCOを法的に証明できるのは人間だけであり、人間の提出者がAI生成コードをレビューし、ライセンス要件を満たすことを確認し、自分の署名で責任を負う必要がある。
一方で、AIや専門解析ツールが貢献に関わったことを追跡するため、Assisted-byタグの形式も示されている。これは「AIを使うな」ではなく、「使ったなら人間が責任を持ち、必要な帰属と確認を残せ」という設計である。今回のTorvalds氏の警告も、この方針と矛盾しない。問題はAI利用の有無ではなく、責任ある提出になっているか、リリース段階に合う判断ができているかである。
企業開発にも跳ね返るのは、コード生成ではなくレビュー配分の問題だ
今回の話は、Linuxカーネルの特殊な文化だけに閉じない。企業の開発現場でも、AI支援によって小さな修正案、静的解析の指摘、リファクタリング候補、テスト追加案は増える。ここでレビュー担当者がすべてを同じ優先度で見ると、本当に重要な障害修正や設計変更の判断が遅れる。
実務上の教訓は、AI利用の申告欄を追加するだけでは不十分だということだ。プルリクエストには、その変更がどの不具合や要件に対応するのか、なぜ今入れる必要があるのか、既存の議論や修正と重複していないか、リリース直前なら次のサイクルへ回せない理由があるのかを示す必要がある。AIが見つけた候補であっても、人間がその優先度と時期を説明できなければ、レビューの入口で止めるほうが全体の安定性には近い。
Torvalds氏のrc5告知が示したのは、AI時代のオープンソース開発で最も不足するものが、コードそのものではなく文脈を読んだ判断になりつつあるという現実である。AIは問題候補を増やせるが、リリースを安定させるのは候補の量ではない。どの変更を今入れ、どの変更を次へ送るかを選ぶ規律である。