はじめに

2026年8月18日、Linux のネットワーク担当メンテナ Jakub Kicinski が Linus Torvalds に宛てたプルリクエストに、こう書きました。

We are completely overwhelmed, of course. （我々は当然ながら、完全に手一杯だ）

この一文が世界中で報じられました。同じ時期に「Linux カーネルの CVE が1リリースあたり2,000件に迫る」というニュースも流れています。並べて読むと、カーネルが AI に押し潰されつつあるように見えます。

ですが、数字の意味は見出しとはかなり違います。

CVE が急増しているのは、脆弱性が急に増えたからではありません。kernel.org は2024年から自分自身で CVE 番号を採番する組織になっていて、「バグ修正なら片っ端から番号を振る」という方針を公式ドキュメントに明記しています。 そこに AI のバグ発見量が掛け算されている、というのが構造です。この前提を抜くと、件数は必ず誤読されます。

この記事では次の4点を扱います。

  1. 何が起きているのか — メンテナ本人の原文で。本人が付けている留保も含めて
  2. CVE 2,000件の正体 — 公式ドキュメントが自ら説明している「多すぎる理由」
  3. パッチはどう流れるのか — サブシステム・メンテナ・stable ツリーの地図
  4. コミュニティはどう適応しているか — netdev・staging・stable の3つの手

出典は lore.kernel.org の原文と docs.kernel.org の公式ドキュメントです。メーリングリストの原文は逐語で引用し、報道でしか確認できなかったものはそう明示します。

1. 🌊 何が起きているのか——メンテナ本人の言葉で

1-1. Linux 7.3 のプルリクエスト（2026年8月18日）

Kicinski が Torvalds に送った [GIT PULL] Networking for 7.3 の冒頭部分を、原文から引きます。

Quick and dirty count suggests we (Paolo and I) merged a very similar number of net (632) and net-next (648) patches. This is not telling the full story either because 1/3 to 1/2 of the net-next patches also *seem* like AI-driven low priority fixes, cleanups and clarifications.

（雑に数えたところ、我々（Paolo と私）がマージしたのは net が632、net-next が648とほぼ同数だった。これも全体像を表してはいない。net-next のパッチの3分の1から半分は、AI 主導の低優先度な修正・整理・明確化の*ように見える*からだ）

そして続く段落が、報じられた一文です。

We are completely overwhelmed, of course. The glimmer of hope is that we secured sufficient LLM budget and access (thank you Meta!) to run reviews with multiple frontier models on each patch. This eliminates some hallucinations.

（我々は当然ながら完全に手一杯だ。一筋の光明は、各パッチに対して複数のフロンティアモデルでレビューを走らせるだけの LLM 予算とアクセスを確保できたことだ（Meta に感謝！）。これでハルシネーションのいくつかは除去できる）

1-2. その12日前（2026年8月6日）

同じ人物が、7.2-rc7 のプルリクエストでこう書いていました。

In the last 9 days there were 405 postings explicitly tagged with [PATCH net], vs 687 with [PATCH net-next]. 37% of posted patches being fixes is pretty crazy, and that’s likely undercounting because LLM “researchers” more often post fixes without knowing to tag the patches for specific trees.

（直近9日間で [PATCH net] と明示的にタグ付けされた投稿が405件、[PATCH net-next] が687件あった。投稿パッチの37%が修正というのはかなり異常だ。しかもこれは過小評価だろう。LLM「研究者」たちは、特定のツリー向けにタグを付けることを知らないまま修正を投稿することが多いからだ）

9日間で投稿1,092件。 数字の桁を実感するには、こちらのほうが分かりやすいかもしれません。

1-3. 本人が付けている留保——報道が落としている部分

ここが、この記事でいちばん書きたかったところです。

Kicinski は、自分の数字にかなり慎重な留保を付けています。 報道の見出しはそこを落としますが、原文には全部書いてあります。

原文の表現 意味
Quick and dirty count 「雑に数えた」——厳密な集計ではないと自分で断っている
*seem* like AI-driven 「AI 由来の*ように見える*」——アスタリスクで囲んで強調している。断定していない
This is not telling the full story この数字は全体像ではない
that's likely undercounting （37%という数字は）おそらく過小評価だ
I don't have historic data 過去との比較データを持っていない
summer vacations disrupted our patch processing (and presumably - generation) quite a bit 夏季休暇が処理（そしておそらく生成も）をかなり乱したので、単純比較は難しい

最後の一行はとくに重要です。Kicinski 自身が「今回のサイクルは夏休みの影響で他と比べにくい」と冒頭に書いているのに、これを添えて報じた記事を筆者は見つけられませんでした。

⚠️ この記事が採らなかったもの

複数の報道が「Red Hat のエンジニアが、AI パッチの洪水をメンテナのトリアージに対する DoS（サービス妨害）だと表現した」と書いています。ただ、筆者が確認した範囲では、この発言をした人物の氏名と、発言の場（メーリングリスト・講演・ブログのいずれか）を特定できませんでした。

発言そのものが無かったと言いたいのではなく、帰属先を確認できない引用は載せないという方針です。特定できた時点で追記します。

2. 🔢 CVE 2,000件の正体——「脆弱性が増えた」ではない

もうひとつのニュースが CVE 件数です。ここは前提を知らないと確実に誤読します。

2-1. 出どころは「講演の予告スライド」

2026年8月27日、stable カーネルのメンテナ Greg Kroah-Hartman が social.kernel.org にこう投稿しました。

Some talks just write themselves, @KernelRecipes is going to be fun this year!

（勝手に書き上がっていく講演というものがある。今年の Kernel Recipes は楽しくなりそうだ）

添付されていたのはグラフ画像1枚です。投稿本文に数値の記載はありません。

したがって、以下のリリース別の件数は、Phoronix がそのグラフを読み取って報じた数値です。 講演そのものは2026年9月21〜23日にパリで開かれる Kernel Recipes 2026 で、本稿執筆時点ではまだ行われていません。

カーネル 1リリースあたりの CVE 件数（Phoronix による読み取り）
Linux 6.x の大半 およそ500件
Linux 7.0 1,000件を突破
Linux 7.2 1,500件を突破
Linux 7.3 2,000件に迫る勢い

2-2. kernel.org は2024年から自分で CVE を採番している

💡 ワード解説：CNA（CVE 採番機関）と kernel.org

CVE は公開された脆弱性に一意の番号を付ける仕組みです。番号を割り当てる権限を持つ組織を CNA（CVE Numbering Authority） と呼びます。

The Linux Kernel Organization（kernel.org）は2024年2月13日に CNA として登録されました。 それ以前は、カーネル外部の個人や企業が勝手にカーネルの CVE を採番していて、公式ドキュメントはそれを「不適切なやり方・不適切な理由で採番されることが非常に多かった」と書いています。自分たちで採番権を握ったのは、その状況をコントロールするためでした。

つまり件数は「見つかった脆弱性の数」ではなく、kernel.org が番号を振ると決めた修正の数です。方針が変われば件数も変わります。

2-3. 公式ドキュメントが自ら「多すぎる理由」を説明している

ここが決定打です。カーネルの公式ドキュメント Documentation/process/cve.rst に、次の記述があります。

Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.

（注意：Linux カーネルはシステム内で低いレイヤに位置するため、ほとんどどんなバグもカーネルのセキュリティを侵害するために悪用され得る。しかし修正の時点では悪用可能性が明らかでないことが多い。このため CVE 採番チームは過度に慎重であり、識別したあらゆるバグ修正に CVE 番号を割り当てる。これが、Linux カーネルチームが発行する CVE が一見して大量である理由を説明している）

「一見して大量に見えるのはこういう理由です」と、公式が先回りして書いているわけです。件数の急増を「Linux が急に危険になった」と読むのは、この記述の存在を知らないまま数字だけを見た結果になります。

ドキュメントには他にもこう書かれています。

  • CVE は修正が stable ツリーに入ったあとに自動的に採番される。未修正の問題には自動採番されない
  • 現在サポートされていないカーネルバージョンの問題には CVE を割り当てない

2-4. Greg Kroah-Hartman 自身の統計が、その構造を裏づけている

2026年7月3日、Kroah-Hartman は同じ場所に、2026年上半期のベンダー別 CVE 発行件数を投稿しています。

ベンダー 件数（2026年上半期）
Linux 2,308
Google 1,752
n/a 1,308
Microsoft 843
OpenClaw 495
Oracle Corporation 445
Adobe 395
Red Hat 340
Apache Software Foundation 310
Apple 284

そこに添えられた本人のコメントが、この記事の主張そのものです。

I gotta change my talk where I say “we are #2” as that’s not the case by far anymore. Hopefully the other vendors get their act together and start properly reporting all CVEs to the system, not just the ones that they feel like submitting…

（「我々は2位だ」と言っている自分の講演を修正しないといけない。もうまったくそんな状況ではない。他のベンダーもきちんと体制を整えて、提出したいと思ったものだけでなく、すべての CVE をきちんとシステムに報告するようになってほしいものだ）

Linux の件数が突出しているのは、Linux が突出して脆弱だからではなく、Linux が突出して正直に報告しているから——というのが、採番している当人の見方です。ここまで来ると、件数を他社と横並びで比較すること自体が意味を持たないと分かります。

✅ 数字の読み方（まとめ）

CVE 件数 ＝ AI バグハンターの発見量 × 「バグ修正なら片っ端から番号を振る」という寛容な採番方針

この掛け算の結果です。分解すると、増えているのは前者（発見量）であって、カーネルの危険度ではありません。 実際、見つかっているものの多くは低優先度で、影響のほとんどない古いドライバのコードだと報じられています。

3. 🛤️ パッチはどう流れるのか——AI はどこから入ってくるのか

数字の話が続いたので、地図を置きます。カーネル開発を知らない読者には、ここが分からないと以降が読めません。

flowchart TD A[開発者がパッチを投稿] --> B[サブシステムの
メーリングリスト] B --> C{メンテナがレビュー} C -->|採用| D[サブシステムツリー
net と net-next] C -->|却下| Z[差し戻し] D --> E[Linus のツリー
メインライン] E --> F[stable ツリー
バックポート] F --> G[CVE を採番] X[LLM が生成した
修正・整形] -.流入.-> B Y[AI バグハンターの
報告] -.流入.-> B
💡 ワード解説：サブシステム・メンテナ・net-next・stable

Linux カーネルは巨大なので、サブシステム（ネットワーク、ファイルシステム、各種ドライバなど）に分かれ、それぞれにメンテナがいます。パッチは GitHub のプルリクエストではなく、サブシステムごとのメーリングリストにメールとして投稿されます。メンテナが読み、議論し、良ければ自分のツリーに取り込みます。

  • net — ネットワークのバグ修正用ツリー。今のリリースに入れる直し
  • net-next — ネットワークの新機能・改善用ツリー。次のリリース向け
  • メインライン — Linus Torvalds のツリー。各サブシステムのメンテナがここへプルリクエストを送る
  • stable ツリー — リリース済みバージョンに、重要な修正だけをバックポート（後方移植）して配るツリー。実際に多くの機器で動いているのはこちら

AI が流入するのは図の左側、メーリングリストへの投稿の段階です。ここは誰でも投稿でき、投稿の手間はほぼゼロ。一方でレビューする側の時間は増えません。非対称性がそのまま負荷になる、というのが今回の構造です。

4. 🛠️ コミュニティはどう適応しているか

「圧倒されている」で話を終えると、実態を見誤ります。この夏のあいだに、少なくとも4つの対応が動いています。

4-1. netdev — AI にはフロンティアモデル複数でレビューを当てる

前述のとおり、Kicinski はプルリクエストの中で対応策を書いています。原文の続きです。

That said, in terms of review, the LLMs can only do so much. The sad truth is that our APIs (especially for rare events like PCIe errors, timeouts etc.) have always been racy, and now LLMs don’t let us ignore that. I expect our direction for the next release will be to tweak the reviews a little bit more, but start shifting focus to letting the LLMs take care of the busy work - managing patchwork, automating common process complaints, editing commit messages, and maybe applying patches which already got “reviewed-by” tags from people we trust…

（とはいえレビューという点では、LLM にできることには限りがある。悲しい事実だが、我々の API は——とくに PCIe エラーやタイムアウトのような稀なイベントについては——昔から競合状態を抱えていて、いま LLM がそれを無視させてくれなくなっただけだ。次のリリースでの方向性は、レビューをもう少し調整しつつ、LLM に雑務を任せる方向へ焦点を移すことになると思う——patchwork の管理、よくあるプロセス上の指摘の自動化、コミットメッセージの編集、そしておそらくは、信頼している人から「reviewed-by」タグが付いたパッチの適用まで）

読み飛ばしやすいですが、真ん中の一文が重要です。

our APIs have always been racy, and now LLMs don’t let us ignore that （我々の API は昔から競合状態を抱えていて、いま LLM がそれを無視させてくれなくなっただけだ）

AI が新しい問題を作ったのではなく、前からあった問題を隠しておけなくなった、とメンテナ本人が書いている。これは押し潰されている人の言葉というより、現実を正確に見ている人の言葉です。

4-2. staging — LLM 生成パッチを原則却下、ただし例外あり

2026年8月3日、Greg Kroah-Hartman が linux-staging メーリングリストに「LLM policy for drivers/staging/ going forward」という投稿をしました。

drivers/staging/ は、品質がまだ本流に届かないドライバを置く場所です。彼はその存在意義をこう説明しています。

drivers/staging/ exists PRIMARILY as a place for new kernel developers to learn how to get involved in kernel development. It contains loads of “low hanging fruit” with regards to code cleanups and api changes, perfect for new developers to learn the process in a safe and friendly way

（drivers/staging/ は主として、新人のカーネル開発者がカーネル開発への関わり方を学ぶ場所として存在している。コード整理や API 変更に関する「取りやすい果実」が大量にあり、新人が安全かつ友好的にプロセスを学ぶのに最適だ）

そのうえで、こう結論します。

So this mean that anyone attempting to use a LLM to cleanup or “fix” any code in drivers/staging/ is EXPLICITLY defeating the whole purpose of it existing in the first place.

（つまり、drivers/staging/ のコードを LLM で整理したり「修正」したりしようとする者は、そもそもそこが存在している目的そのものを明確に台無しにしている）

ここは技術的な話ではなく、「新人が登る梯子を、機械が先に全部登ってしまったら梯子の意味がなくなる」という話です。禁止の理由が「AI の品質が低いから」ではないところが、この投稿の面白さだと思います。

例外も明示されています。

Note, LLMs are very good at finding suspect “security issues” in kernel code these days. But even with the best of the current and next generation tools, at least 1/3 of the results they generate are flat out wrong or harmful. So, if you think your LLM-found/fixed issue in a drivers/staging/ file is really valid, it’s fine to submit it BUT you must have first tested it on the actual hardware for the driver, and described how you have done so, in order for us to be willing to take the change.

（最近の LLM は、カーネルコードの疑わしい「セキュリティ問題」を見つけるのが非常に得意だ。だが現世代・次世代の最良のツールをもってしても、生成される結果の少なくとも3分の1は完全に間違っているか有害である。だから、もし LLM が見つけた／直した drivers/staging/ の問題が本当に妥当だと思うなら、投稿してくれて構わない。ただし、そのドライバの実機で先にテストし、どうテストしたかを記述していることが、我々がその変更を受け入れる条件だ）

彼はこの投稿を、ジムの比喩で締めています。drivers/staging/ は筋力を鍛えるためのジムであり、重い物を機械に持たせていいのは、どういう持ち上げ方が可能かを既に体で知っている人だけだ、と。

4-3. stable — AI で選別し、AI の偽陽性を弾く

stable ツリーのバックポート選別には、共同メンテナである NVIDIA の Sasha Levin が作った AUTOSEL という、LLM と埋め込み技術を使った Rust 製の分類器が使われていると報じられています（この運用の詳細は報道ベースです）。stable チームが AI モデルでパッチをレビューし偽陽性を弾く運用に入っている、という点も同様です。

AI が生んだ量を、AI で捌く。 皮肉ではありますが、量の問題に対しては合理的な回答です。

4-4. 投稿ルール — 「AI に丸投げするな」を公式文書に

カーネルには Documentation/process/coding-assistants.rst という公式文書があります（2025年12月にコミットされ、Linux 7.0 で出荷済み）。この文書自体は当サイトでLinux 7.2 の記事で詳しく扱ったので、ここでは今回の文脈で効く一点だけを引きます。

Indicate what could not be done. If the fix could not be built or tested, or if no reproducer could be produced, say so explicitly: maintainers currently waste too much time analyzing unverified reports and untested fixes.

（できなかったことを示せ。 修正をビルドできなかった、テストできなかった、再現手順を作れなかったのなら、そう明示的に書け。メンテナは現状、検証されていない報告と未テストの修正の分析に、あまりにも多くの時間を浪費している）

「AI を使うな」ではなく、「できていないことを、できていないと書け」。要求されているのは技術ではなく、報告の誠実さのほうです。

📌 筆者の見方（カーネル開発は専門外ですが）

筆者はカーネル開発が本業ではなく、ふだんは ESP32 まわりの組み込みと個人開発が中心です。そのうえで、今回いちばん背筋が伸びたのは Greg Kroah-Hartman の一文でした。「実機で先にテストし、どうテストしたかを記述していること」。

これは当サイトが自分の記事に課しているルールと、言葉までほぼ同じです。データシートを読んだだけの値は書かない、オシロで見た波形は見たと書き、見ていないものは見ていないと書く。カーネルという世界でいちばん硬い現場が、AI パッチの洪水に対して出した答えが、モデルの良し悪しの話ではなく「お前は実機に載せたのか」だった——ここに、専門外ながら深く納得しました。ゲートを「AI が書いたかどうか」ではなく「人間が実機で確かめたかどうか」に置いている。前者は判定できませんが、後者は書けば分かるし、書かなければバレます。

もうひとつ、Kicinski の書きぶりも印象に残りました。彼は溺れかけている当事者なのに、自分の数字には quick and dirty count、*seem* like AI-driven、I don't have historic data と留保を重ねています。手一杯だと言いながら、測っていないことを測ったようには書かない。 記事を書く側としては、ここを落として「半分が AI」とだけ見出しにするのは、まさに彼が困っている種類の不正確さを自分がやることになるな、と思いました。だから本文では留保を表にして残しています。

自分の作業に引き寄せると、怖いのは非対称性です。LLM に ESP-IDF の修正を書かせるのは数十秒ですが、その修正が本当に正しいかを実機で確かめるのは数十分かかります。手元では後者を省かないので詰まりませんが、これを他人のメーリングリストに向けて省略すると、生成コストが自分に、検証コストが相手に乗る構図になる。生成が安くなったぶん、検証を省いた投稿の迷惑さだけが増幅された、というのが今回の事象の本質だと受け止めました。道具の問題ではなく、コストを誰に押し付けるかの問題です。

そう考えると、Kroah-Hartman が drivers/staging/ を「ジム」と呼んだのは的確でした。筆者も ESP32 で最初に L チカを動かしたとき、あの遠回りが後で効いたと思っています。重量を機械に持たせていいのは、自分の体で持ち方を覚えた人だけ。新人が登る梯子を機械が先に登ってしまうという懸念には、組み込みで学んできた側として素直に頷けました。

まとめ

観点 内容
発言 2026年8月18日、Jakub Kicinski が Linux 7.3 のプルリクエストに「We are completely overwhelmed, of course」と記述
パッチ数 net 632件・net-next 648件。net-next の3分の1から半分が AI 由来と見られる（本人が「雑な集計」「〜のように見える」と留保）
本人の留保 夏季休暇で処理が乱れ比較困難／過去データを持たない／過小評価の可能性
CVE 件数 6.x 世代は約500件 → 7.0 で1,000件超 → 7.2 で1,500件超 → 7.3 は2,000件に迫る（Phoronix によるスライドの読み取り値）
CVE 急増の正体 脆弱性の激増ではない。kernel.org が2024年2月13日から自前 CNA で、公式ドキュメントが「識別したあらゆるバグ修正に番号を振る」「だから一見大量に見える」と明記
裏づけ 採番当人の Greg Kroah-Hartman が「他ベンダーも出したいものだけでなく全部報告してほしい」と投稿
適応① netdev：複数のフロンティアモデルでレビュー。今後は LLM に雑務を移す方針
適応② staging：LLM 生成パッチを原則却下。例外は実機テスト済みでその方法を記述したもの
適応③ stable：AUTOSEL などで選別、AI の偽陽性を AI で弾く（報道ベース）
適応④ 公式文書：「できなかったことを明示せよ」
未確認 「Red Hat エンジニアの DoS 発言」は発言者と場を特定できず、本記事では帰属しない

当サイトでは2週間ほど前に、AI が OSS の脆弱性を2,436件見つけた話を書きました。今回はちょうどその裏側です。AI がバグを見つける力は本物で、だからこそ見つけた先の人間の処理能力が詰まる。同じ現象の光と影として並べて読むと、どちらか一方だけを見て「AI は OSS を救う／壊す」と結論する話ではないことが分かります。

そして重要なのは、カーネルコミュニティがこの夏のあいだに実際に手を打っていることです。禁止一辺倒でもなく、無制限の受け入れでもなく、サブシステムごとに違う答えを出している。ネットワークは AI でレビューを増やし、staging は「実機で試したか」を条件にし、stable は選別を自動化する。35年もののコードベースが、新しい種類の負荷に対して数か月で運用を組み替えている——それ自体が、このプロジェクトの体力の証拠だと思います。

よくある質問（FAQ）

Q. Linux カーネルは AI のせいで危険になったのですか？

いいえ。CVE 件数の増加は「脆弱性が増えた」ことを意味しません。kernel.org は2024年2月から自分自身が CVE 採番機関で、公式ドキュメントに「採番チームは過度に慎重であり、識別したあらゆるバグ修正に CVE 番号を割り当てる」「これが一見して大量に見える理由だ」と明記しています。AI が発見量を押し上げた結果、この寛容な採番方針と掛け算されて件数が伸びている、という構造です。報道によれば、見つかっているものの多くは低優先度で、影響のほとんどない古いドライバのコードです。

Q. 「net-next の半分が AI 由来」は確定した数字ですか？

いいえ。Kicinski 自身が原文で「雑に数えた（quick and dirty count）」と断り、「AI 主導のように見える（*seem* like AI-driven）」とアスタリスクで囲んで書いています。さらに「過去のデータを持っていない」「夏季休暇で処理が乱れたので比較が難しい」とも書いています。メンテナの体感を含む見積もりであって、計測値ではありません。

Q. Linux は AI が書いたパッチを禁止したのですか？

カーネル全体としては禁止していません。禁止されたのは drivers/staging/ サブシステムで、しかも例外があります。Greg Kroah-Hartman の投稿によれば、LLM が見つけた／直した問題でも、そのドライバの実機で先にテストし、どうテストしたかを記述していれば投稿してよいとされています。他のサブシステムでは、AI 支援そのものは公式文書で認められています（ただし Signed-off-by は人間しか付けられません）。

Q. なぜ staging だけ特別扱いなのですか？

品質の問題というより、場の目的の問題です。drivers/staging/ は新人開発者がカーネル開発の作法を学ぶための場所として存在していて、コード整理のような「取りやすい果実」がわざと残されています。そこを LLM が一掃してしまうと、学ぶ場所そのものが消えてしまう。Kroah-Hartman はこれを「そもそもの存在目的を明確に台無しにしている」と書いています。

Q. 個人がカーネルにパッチを送るとき、AI を使ってもいいのですか？

使えます。ただし公式文書が求めているのは、できなかったことを明示することです。原文はこうです——「修正をビルドできなかった、テストできなかった、再現手順を作れなかったのなら、そう明示的に書け。メンテナは現状、検証されていない報告と未テストの修正の分析にあまりにも多くの時間を浪費している」。AI の関与を示す Assisted-by タグの扱いも含めた詳細は、当サイトのLinux 7.2 の記事で扱っています。

Q. この問題は Linux カーネルだけの話ですか？

カーネルがいちばん可視化されているだけで、構造は OSS 全般に共通します。パッチやバグ報告は投稿の手間がほぼゼロなのに対し、レビューする側の時間は増えません。生成が安くなるほど、この非対称性が効いてきます。カーネルの対応（サブシステムごとに条件を変える、雑務を自動化する、報告に「未検証」の明示を求める）は、他のプロジェクトにも参考になる形だと思います。

関連記事

参考