• Linux生みの親のリーナス・トーバルズ氏が、Claude Codeを使ってLinuxカーネルの高速化パッチを作った
  • 小さな読み込みを8スレッドで行うテストで、処理は約3倍（毎秒約1,000万回から3,000万回超）になった
  • 測定は本人のノートPC1台だけで、まだ本流には取り込まれていない
  • 1スレッドの一部ケースは遅くなり、メモリの扱いにも未解決の課題が残る
  • Linuxには「Assisted-by」タグというAI利用の公開ルールがある

AIは、世界でいちばん厳しいと言われるオープンソース開発の現場にまで入ってきたのでしょうか。Linuxの生みの親が、自分のブランチでClaude Codeを使ったと明かし、速度が約3倍になったと報告しています。何が起きたのか、どこまで信頼できるのかを見ていきます。

何が起きた？トーバルズ氏が公開したパッチ

2026年10月12日ごろ、リーナス・トーバルズ氏が自分のLinuxツリーにnoref-filemap-read-with-llmというブランチを公開しました。

Hardware Bustersによると、中身は8本のパッチの連続（パッチシリーズ）です。Claude Codeがコードとテストを書き、説明文の下書きも作ったと、本人が添え書き（カバーレター）に書いています。

カバーレターには、作業は「私の指示のもとで」行われ、測定は「自分のマシン」で実行したとあります。最初に見つけたのはPhoronixの記者で、そこから複数のメディアに広がりました。

対象はLinux 7.3-rc6の上に載るコードで、まだ正式には取り込まれていません。

ページキャッシュとは？何を速くしたのか

ページキャッシュ（よく使うファイルをメモリに置いておく仕組み）

パソコンは、一度読んだファイルの中身をメモリに残しておきます。次に同じファイルを読むとき、ストレージまで取りに行かなくて済むからです。この仕組みがページキャッシュです。

Linuxのファイル読み込みの多くは、この仕組みを通ります。だから、ここが少し速くなるだけでもサーバーの動きに影響します。

ボトルネックは「参照カウンタ」

問題になっていたのは、複数のスレッド（同時に動く作業の単位）が同じファイルを少しずつ読む場面です。

読むたびに、各スレッドは「いま何人がこのデータを使っているか」を数えるカウンタ（参照カウンタ）を増やしたり減らしたりします。全員が同じカウンタを書き換えるので、CPUのコア同士が同じメモリの一角を奪い合います。

Hardware Bustersによると、8スレッドで16バイトずつ読むテストでは、コア間の衝突のうち99.92%がこの奪い合いでした。

RCUで「数えない」読み方に

新しい方式では、読み込み中にカウンタを触りません。代わりにRCU（読み手を止めずに、あとでまとめて安全に片づける仕組み）を使います。

キャッシュから外れたデータは、すぐには解放しません。全部の読み手が通り過ぎたことを確認してから、メモリに返します。

1つのCPUに1,024ページを超える解放待ちがたまると、片づけを急がせる安全弁も付いています。

どれくらい速くなった？数字で確認

測定したのは、トーバルズ氏のCore i7-8565Uのノートパソコン（4コア・8スレッド）です。Hardware Bustersによる数字は次のとおりです。

  • 8スレッドの読み込み1回あたりのCPUサイクル数は、約2,950から約725に減った
  • 毎秒の読み込み回数は、約1,000万回から3,000万〜3,300万回に増えた（約3倍）
  • コア間の衝突（HITM）は、30,538回から101回に減った
  • 1スレッドでは、約452から約408サイクルに減り、約10%軽くなった

衝突は約300分の1に減っています。奪い合いが減ったという説明と、数字が合っています。

ただし、これは16バイトという極端に小さい読み込みを、8つのスレッドが同じファイルに一斉に行う特別なテストです。サーバー全体が3倍になるという意味ではありません。

課題とリスク：速くなる代わりに失うもの

カバーレターには、うまくいかない点も書かれています。DEV Communityの分析記事もこの点を取り上げています。

1つ目は、遅くなる場面があることです。まだ割り当てられていないメモリ領域に読み込むと、一度失敗してから、従来の経路でやり直す流れになります。1スレッドの16バイト読み込みは、約4,150サイクルから約6,550サイクルに増えました。

2つ目は、メモリの解放が遅れることです。解放待ちのページは、メモリ管理の空き容量の数字に出てきません。Hardware Bustersによると、トーバルズ氏自身がこの部分を最も解決できていない点としています。

実際、2GiBの仮想マシンでの負荷テストでは、6本版のパッチは4CPUと8CPUでOOMキラー（メモリ不足で動作中のプロセスを強制終了する仕組み）を起こしました。8本そろえた版では完走したとされています。

3つ目は、試験が足りないことです。測ったのは1台のノートPCだけで、他の機種やメモリが足りない状況での確認はこれからです。第三者による再現もまだありません。

AI支援開発はどう変わる？従来との比較

次に、AI利用のルールを見ます。Linuxカーネルには、AIが関わったパッチの扱いを定めた公式文書があります。ITsFossによると、Linux 7.0で入りました。

中身は次の3点です。

  • AI支援のコードもGPL-2.0-onlyのライセンスを守る
  • AIエージェントはSigned-off-by（責任を負う署名）を付けられない
  • AIが手伝ったパッチにはAssisted-byタグを付ける

つまり、AIの利用は禁止していません。ただし、結果に責任を持つのは必ず人間の提出者です。

従来のやり方と並べると、違いが分かります。

  • 従来：人が設計し、書き、テストし、署名する
  • 今回：人が方向を決め、AIが書き、試験を作り、人が測定して責任を持つ

なお、Startup Fortuneによると、トーバルズ氏は2024年10月にはAI話の9割は誇大宣伝だと語っていました。2026年7月には「Linuxは反AIのプロジェクトではない」と書いています。立場はかなり変わったことになります。

日本の開発者・企業への影響

Linuxは日本でも、Webサービスやクラウド、工場の機器、スマートフォンなど、さまざまな場所で動いています。カーネルの読み込み処理が速くなれば、日本のユーザーにも恩恵が届くかもしれません。

ある中小企業のインフラ担当者を考えてみましょう。自社のサーバーで、同じ設定ファイルを大量のプロセスが読んでいるとします。今回のような改善が正式に取り込まれれば、設定を変えなくても負荷が下がるかもしれません。

開発チームにとっては、進め方のほうが参考になります。AIに書かせ、人が測り、弱点まで公開するという手順は、社内の開発ルールを作るときのヒントになります。

たとえば「AIを使った箇所は記録に残す」「責任者は必ず人間にする」というルールなら、すぐ真似できるはずです。

ただし、カーネルの変更は影響範囲が広く、まだ取り込まれてもいません。今すぐ本番環境に入れるものではありません。

よくある質問（FAQ）

Q1. このパッチはもうLinuxに入りましたか？

いいえ。まだ取り込まれていません。Linux 7.3-rc6の上に載った実験的なブランチです。次の開発サイクル（7.4）に入るかどうかも、まだはっきりしていません。

Q2. 本当に3倍速くなるのですか？

特定のテストでは、毎秒の読み込み回数が約3倍になりました。ただし小さな読み込みを8スレッドで同じファイルに行う条件で、1台のノートPCでの結果です。実際の用途ではもっと小さい改善にとどまる可能性があります。

Q3. AIが書いたコードは安全に使えますか？

カーネルでは、AIが書いたかどうかにかかわらず、人間の提出者が全責任を負います。今回は、トーバルズ氏が自分で測定し、弱点も書き出した上での公開です。レビューと追加試験が通るまでは、安全とは言い切れません。

Q4. Assisted-byタグとは何ですか？

AIが手伝ったパッチに付ける印です。形式はAssisted-by: AGENT_NAME:MODEL_VERSIONで、使った道具も並べて書けます。AIを共同著者ではなく道具として扱う考え方に基づいています。

まとめ

  • トーバルズ氏がClaude Codeでページキャッシュの高速化パッチを作り、AI利用を自ら公表した
  • 特定のテストで読み込み回数は約3倍になったが、測定は本人のノートPC1台だけ
  • 1スレッドで遅くなる場面とメモリ管理の課題が残っている
  • Linuxのルールでは、AI支援でも責任を負うのは人間の提出者

次の一歩として、自分のチームでも「AIを使った箇所を記録し、責任者を決める」ルールを1つ作ってみてください。

参考文献