Linus Torvalds氏は2026年7月15日、Linuxカーネルの開発方針を巡るメールで、Linuxを「反AIプロジェクトにはしない」と宣言した。AI利用に納得できない参加者には、オープンソースの流儀でforkするか、プロジェクトを離れる選択肢があるとも言い切った。
強い言葉だけを拾えば、AI推進派による反対派への最後通告に見える。だが、議論の起点はAI生成コードの全面解禁ではなかった。AIレビューシステム「Sashiko」の指摘を誰へ送り、誤検知を誰が確かめるのか。Linuxが突き当たったのは、生成速度が上がった後に残る人間の時間配分である。
Torvalds氏の答えも、AIへ判断を明け渡すというものではない。Linuxの現行ルールは、AIが作ったコードを人間が読み、ライセンスを確認し、自分の署名で引き受けるよう定めている。入口は開く。しかし、責任の出口は人間から動かさない。
火種はSashikoを誰の受信箱につなぐか
発端となった「Linking Patchwork with Sashiko?」スレッドは、Linux Media Mailing Listで5月30日に始まった。Patchworkはメールで届くパッチを追跡する仕組みであり、ここへSashikoのレビュー結果を結び付ければ、作者とメンテナーは指摘を同じ流れで処理できる。ところが、自動メールの宛先を決める段階で、効率と同意がぶつかった。
長年のカーネル開発者Laurent Pinchart氏は、Sashikoの指摘を作者へ送る前に、利用したいメンテナーが内容を選別し、正しいか確かめるべきだと主張した。AIからの連絡を望まない作者の意思も尊重する。その根拠として、Software Freedom Conservancy（SFC）が6月18日に公表した勧告の冒頭2項目を挙げた。
Roman Gushchin氏は、そこへ人手を挟めば「メンテナーを助ける」というSashikoの目的を達成できないと反論した。重大な欠陥が見つかった場合、作者がオプトアウトしているかを確認し、メンテナーが手作業で転送するのか。Torvalds氏はこの流れに加わり、AIは明らかに有用な道具であり、他人の利用を妨げる主張は受け入れないと表明した。
選択肢ごとに、消える仕事と移る仕事が違う。
| 運用 | 最初の受信者 | 得られる効果 | 人間側に残る負担 |
|---|---|---|---|
| 作者へ自動送信 | パッチ作者と公開リスト | 中継を省き、修正を早く始められる | 作者が誤検知を選別する |
| メンテナーが事前確認 | サブシステムのメンテナー | 低品質な指摘を作者へ流さずに済む | メンテナーが全件を読む |
| オプトイン運用 | 利用を選んだ作者や領域 | 個人の選択を守りやすい | 通知経路と例外処理が複雑になる |
この表のどの行を選んでも、検証作業そのものは消えない。AI導入の成否は、その作業を機械が減らすのか、別の人の受信箱へ移すのかで決まる。
53.6%という自己評価をどう読むか
Sashikoは、Linux Foundationに属するApache License 2.0のオープンソースプロジェクトである。公開サービスはLinux Kernel Mailing List（LKML）を監視し、Googleが計算資源とLLMトークンを提供する。モデルを呼び出して一度だけ感想を書かせる仕組みではなく、カーネル専用のプロンプトと多段の検証手順を組み合わせたエージェント型レビューシステムだ。
公開READMEには11段階の工程が記されている。まず変更の目的と設計を読み、実装がコミットメッセージと合うかを確かめる。次に実行経路、メモリなどの資源管理、ロックと並行処理を追い、安全性とハードウェア固有の制約を調べる。その後、重複した指摘をまとめ、反証と突き合わせ、重大度を付けてメールへ変換する。サブシステムごとのプロンプトも使う。
プロジェクトはGemini 3.1 Proを使った公開ベンチマークで、既知バグを含む過去1,000件の上流コミットを対象に、53.6%を検出したと報告している。判定には別のAI judgeが使われ、レビュー結果を既知の問題記述と比較する。偽陽性は限定的な手動確認で20%以内だったという。ただし、後者はREADME自身が「測りにくい」と認める参考値であり、同じ入力でも結果が変わり得るとも明記している。
53.6%は、すでに修正されたバグをどこまで再発見できたかという再現率だ。さらに判定自体にもAIが入る。実際のメールで1件の正しい指摘を得るまで、作者が何件の誤検知を読み、何分を費やすのかは分からない。サブシステムごとに前提も違う。実運用の価値を測るには、発見数と一緒に、指摘単位の適合率と確認に費やした時間が要る。
3月のlinux-mmで示された数字も、この違いをよく表す。メンテナーのAndrew Morton氏は、Sashikoレビューを含むメールのうち22件で作者が修正の必要を認め、2件は修正不要、1件は判定不能、10〜15件は未回答だったと報告した。これに対し、別の開発者は未回答を10件と置けば35件中22件、約63%になるが、「1本のパッチで少なくとも1指摘が当たった割合」にすぎず、全指摘の信号対雑音比は分からないと指摘した。有用性は確認できる。自動配信の妥当性は、まだ別に測らなければならない。
人間が署名し、責任を引き受ける
Linuxカーネルの公式文書「AI Coding Assistants」は、受け入れ条件を明快に定めている。AIエージェントはSigned-off-byを付けてはならない。Developer Certificate of Origin（DCO）を法的に証明できるのは人間であり、投稿者が生成コードをレビューし、GPL-2.0-onlyとの互換性を確かめ、自分の署名を付け、貢献の全責任を負う。
AI支援を隠すことも想定していない。推奨される記録はAssisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]である。誰が最終責任を負うかをSigned-off-byで固定し、どのモデルと専門ツールが関わったかをAssisted-byで追跡する。生成元の開示と法的な引き受けを、別のタグへ分けた設計だ。
バグ報告には、さらに厳しい実証が求められる。公式のSecurity bugs文書は、AI支援で発見した問題を公開情報として扱うよう指示する。同じ道具を使った複数の調査者が、同じ日に同じ問題を報告する事例が続いたためだ。報告者は影響する版を特定し、再現手順を実際に動かす。Linuxの脅威モデルに照らして影響を説明し、可能ならテスト済みの修正も添える。
同じ問題は、2026年5月17日のLinux 7.1-rc4告知でも表面化した。Torvalds氏は、重複するAI報告によって非公開のsecurity listが「ほぼ管理不能」になったと説明した。すでに直った問題の転送と重複確認に時間を使い、報告者同士は非公開ゆえに互いの投稿を見られない。Linuxの公式文書がAI支援による発見を公開情報として扱い、再現・影響説明・修正を求めるのは、こうした重複と検証コストを抑える運用と整合する。
個人の拒否と共有工程の折り合い
今回引用されたSFC勧告は、AIの全面禁止を求める文書ではない。AIを拒む人の自己決定を支える一方、AIを使う貢献者も排除しないよう求める。提出前には人間が十分に読み、利用したモデルと関与の仕方を機械可読な形で残す。人が確認しない投稿は、プロジェクトが明示的に指定した場所へ限る。FOSSを大きく前進させられる場合には、プロプライエタリなAIを戦略的に使う判断も認めている。
対立したのは、個人がAIを拒む自由と、共有された開発工程へその拒否をどう反映するかである。Theodore Tso氏は、SFC勧告が主に生成コードを想定しており、コードレビューやバグ解析、長期サポート版へのバックポートでは事情が変わると論じた。作者がAIを拒むたびに、メンテナーがSashikoの報告を読み直して言い換える運用は、限られた保守時間を削る。
Torvalds氏は後続メールで、AIレビューはcheckpatchより非自明な問題を見つけることがあると評価した。同時に、checkpatchが長年の調整で痛みより価値を増やしたように、Sashikoにも同じ改善が必要だと書いている。この発言は、現状の出力を無条件で信頼する宣言ではない。技術的な成績を測り、悪い通知を減らしながら使うという立場である。
本人の利用歴も、その線に沿う。Torvalds氏は個人プロジェクト「AudioNoise」で、Pythonの可視化ツールをGoogle Antigravityに書かせた。ただし、同プロジェクトをデジタル音響処理を学ぶための玩具と説明している。試して性能を判断することと、Linuxカーネルへ同じ任せ方を持ち込むことを分けている。
誤検知のコストを工程の外へ押し出さない
Sashikoの公開サービスでは、Googleが推論費用を負担する。だが、報告を読んで正誤を確定する時間までGoogleが提供するわけではない。作者へ直送すれば作者が払い、メンテナーがゲートになればメンテナーが払う。オープンソースでは、この人間時間こそ不足しやすい資源だ。
そのため、今後の評価にはバグ検出率より細かな運用指標が要る。サブシステム別の誤検知率、重複除去後のメール数、作者が採用した指摘の割合を測る。さらに、1件の修正へ到達するまで作者とメンテナーが費やした分数を比べる。重大な指摘だけを直送する閾値や、作者ではなく専用リストへ集約する経路も、その数字から決めるべきだ。
Linuxが今回閉じたのは「AIを使うか」という入口の議論である。開いたままなのは、Sashikoが人間の仕事を本当に減らせるかという検証だ。メールの量と修正採用率が改善し、Assisted-byの先に説明できる人間が残るなら、AIレビューはカーネル開発の標準的な道具になり得る。負担が別の受信箱へ移るだけなら、53.6%の再現率が高くても運用は長続きしない。
