メインコンテンツにスキップ

リーナス・トーバルズが語ったLinux 35年：パッチ、Git、退屈なカーネル、AIレビュー

経営
思考メモ
Linuxの35年は、レビューと統合の負荷をトーバルズ1人に集中させない仕組みづくりの歴史である。パッチの手作業での書き直しから始まり、BitKeeperとGitによる分散化、約10週間ごとの定型リリース、そして2026年のAIによる自…
作者

obelos

公開

2026年11月8日

更新日

2026年11月8日

Linuxの35年は、レビューと統合の負荷をトーバルズ1人に集中させない仕組みづくりの歴史である。パッチの手作業での書き直しから始まり、BitKeeperとGitによる分散化、約10週間ごとの定型リリース、そして2026年のAIによる自動パッチレビューまで、課題は一貫して「人間のレビュー能力をどうスケールさせるか」にある。本記事では、2026年10月のOpen Source Summit Europeで行われたリーナス・トーバルズとダーク・ホーンデルの対談を、公開資料で裏付けを補いながら整理する。

Keynote: Linus Torvalds, Creator of Linux… - Dirk Hohndel, Ericsson & Linus Torvalds, Linux & Git

対談の概要

対談は2026年10月9日、チェコ・プラハで開かれたOpen Source Summit + Embedded Linux Conference Europe 2026の基調講演として行われた。Linux Foundationは同イベントをLinux 35周年の節目と位置づけている。

トーバルズは講演を好まず、近年はホーンデルとの対談形式でのみ登壇している。ホーンデルはEricsson Software Technologyの責任者で、VMwareやVerizonでオープンソース部門を率いてきた。2人はダイビングログアプリ「Subsurface」の共同開発者でもある。同年5月の北米イベントでの対談が、LWNによれば30回目にあたる。

対談で触れられた出来事を年表にまとめる。

時期 出来事
1991年 Linux 0.01公開。パッチはメールで受け取り、週1回程度tarballで配布
2002年 カーネル開発が商用の分散型SCM「BitKeeper」を採用
2005年4月 BitKeeperの無償提供が終了。4月7日にGitの最初のコミット
2005年7月 Gitの保守を浜野純（Junio C Hamano）氏に引き継ぎ
2005年10月 2週間のマージウインドウ＋週1回のrcという運用の継続を表明
2026年3月 Googleの技術者がAIレビューシステム「Sashiko」を公開
2026年4月 Linux 7.0リリース
2026年7月 トーバルズがメーリングリストでAIツールの利用を明確に支持
2026年10月 Linux Plumbers ConferenceでSashikoの運用実績を報告。本対談

初期Linux：パッチを書き直していた時代

1991年当初、トーバルズは他の開発者から届いたパッチをそのまま適用せず、内容を理解したうえで自分で書き直していた（動画 02:12）。協業型の開発手法を身につけるまでには時間がかかり、届いたパッチをそのまま適用する方が効率的だと気づいたのは、自身が「怠け者」だと自覚してからだと語っている（02:38）。

当時は専用のバージョン管理システムを使っていなかった。運用は次の3段階である（04:43）。

  1. 開発者がdiffで作ったパッチをメールで送る
  2. トーバルズがほぼ毎日パッチを適用する
  3. 週1回程度、ソースツリー全体をtarballとして公開する

この方式では、すべての変更がトーバルズ1人を経由する。貢献者が増えるにつれて彼の処理能力がボトルネックになり、1990年代末には「Linus doesn’t scale」という議論がコミュニティで起きた。後のBitKeeper採用とGit開発は、このボトルネックへの回答である。

BitKeeperからGitへ

Gitは、BitKeeperで学んだ分散型の運用を手放さないために、2005年4月に約1週間半で作られた（動画 11:18, 17:58）。

BitKeeperが教えたこと

カーネル開発は2002年に商用の分散型SCM「BitKeeper」へ移行した。分散型では各開発者が完全な履歴を手元に持つ。トーバルズは各サブシステムの保守担当者から変更を「pull」でまとめて取り込めるようになり、未処理の作業が彼1人に積み上がらなくなった（08:14）。

2005年4月の決裂

BitKeeperの開発元BitMoverは、一部の開発者がBitKeeperをリバースエンジニアリングしたことを理由に、無償版の提供を打ち切った。トーバルズは既存のSCMをいずれも採用せず、自作を選んだ。

日付（2005年） 出来事
4月6日 LKMLに「Kernel SCM saga..」を投稿し、BitKeeperからの移行を表明
4月7日 Gitの最初のコミット。メッセージは「the information manager from hell」
4月16日 Linux 2.6.12-rc2をGitで管理する最初のカーネルコミット
7月26日 「Meet the new maintainer..」で保守を浜野純氏に引き継ぎ
12月21日 浜野氏のもとでGit 1.0リリース

日付はGitLabによるGit 20年史とO’Reilly『Version Control with Git』による。

数か月で手放し、5年で標準に

トーバルズがGitを保守したのは約4か月で、その後の発展には直接関わっていない（15:46）。Gitを書いた理由は、カーネル開発を続けるための道具が必要だったからであり、VCSそのものへの関心ではない。初期のGitは扱いにくいと敬遠されたが、約5年でCVSやSubversionに代わるデファクトスタンダードになった（14:15）。現在のGitの大部分は、20年以上保守を続ける浜野氏のもとで形づくられている。

マージウインドウと「退屈なカーネル」

現在のカーネルは、2週間のマージウインドウと週1回のrc（リリース候補）で構成される約9〜10週間のサイクルで、時計のように規則正しくリリースされている（動画 20:18）。

不定期リリースの問題

かつては安定版（偶数系列：2.4など）と開発版（奇数系列：2.5など）を分け、開発版が数年続いてから次の安定版を出していた。リリース間隔が長いため、ディストリビューションは開発版の機能を独自に安定版へバックポートし、安定版と開発版の差が大きく開いて混乱が生じた（21:04）。

定型サイクルの確立

Git移行と同じ2005年に、トーバルズは2週間のマージウインドウの後、rcをおよそ週1回出す運用を続けると表明した。カーネルの公式ドキュメントが定める流れは次のとおりである。

  1. マージウインドウ（約2週間）：新機能を取り込む。取り込む変更は事前にサブシステムのツリーで集約・テスト済み
  2. rc1公開：新機能の受け付けを終了する
  3. rc2以降（週1回）：修正のみを取り込む。通常rc6〜rc9まで続く
  4. 正式リリース：回帰の一覧を主な判断材料にして出す。直後に次のマージウインドウが開く

Linuxカーネルのリリースサイクル（マージウインドウ→rc1→rc2以降→正式リリース）

Linuxカーネルのリリースサイクル（マージウインドウ→rc1→rc2以降→正式リリース）

正式リリースの直後に次のマージウインドウが開くため、サイクルは途切れずに回り続ける。

直近の例として、Linux 7.0は2026年2月9日にマージウインドウが開き、2月22日にrc1、4月12日に正式リリースとなった。6.19の次を7.0としたのも機能上の理由ではなく、マイナー番号が大きくなりすぎたためである。

退屈であることの価値

トーバルズはカーネルが「退屈」であることを重視する（24:24）。劇的な変更を一度に入れるのではなく、小さな変更を定期的に積み重ねる。新機能がマージウインドウに間に合わなければ次のサイクルを待てばよく、待ち時間は最大でも約10週間である。この予測可能性が、各社の開発者が並行して作業し、ディストリビューションが計画的に新カーネルを採用することを可能にしている。

AIによるパッチレビュー：Sashiko

カーネル開発では、GoogleのAIレビューシステム「Sashiko」がパッチのレビュー工程にすでに組み込まれている（動画 26:17）。保守担当者の負担は減った一方で、AIが生成したパッチとレビューが大量に飛び交う状況も生まれている（28:43）。

Sashikoの仕組み

項目 内容
公開 2026年3月、Googleのカーネルチームのローマン・グシチン（Roman Gushchin）氏がLKMLで発表
実装 Rust製。保存先はSQLite。GitHubでOSSとして公開
入力 lore.kernel.orgのメーリングリストアーカイブをNNTPで監視し、新着パッチを取得。ローカルのgitからも読み込める
モデル 既定はGemini 3.1 Pro。Claudeなど他のLLMも設定で選択可能
費用 上流カーネル向けの推論費用はGoogleが負担
名前 布の擦り切れを補強する日本の刺繍「刺し子」に由来

パッチの差分だけでは文脈が不足するため、周辺コードやgit履歴もLLMに渡す。1パッチのレビューで入力が約180万トークンに達する例もある。プロジェクトページでは、人間のレビューをすり抜けたバグの53.6%を検出でき、誤検知率は約20%以内としている。

運用実績

2026年10月のLinux Plumbers Conferenceで、グシチン氏は公開から1年未満の実績を報告した。

指標 値
パッチレビュー数 19万1,000件超（99のメーリングリスト）
Sashikoに言及した上流カーネルのコミット 1,277件
Sashikoに言及したlinux-nextのコミット 1,567件
Sashikoに言及した2026年のカーネルCVE 463件

一方で、2026年のLSFMM+BPF Summitでは、大きなパッチやパッチセットではレビュー品質が下がり、コミットログの記述に引きずられる傾向が報告されている。人間のレビューと同じ弱点を持つということである。

2026年7月の論争

Sashikoの指摘をどう扱うかで、メーリングリスト上で意見が割れた。開発者のローラン・ピンシャール（Laurent Pinchart）氏は、Software Freedom ConservancyのAI生成物に関する提言を踏まえ、保守担当者がSashikoの指摘を先に精査してからパッチ作者へ伝えるべきだと主張した。グシチン氏はそれではツールの効用が失われると反論し、トーバルズもこれを支持した。トーバルズはAIは他の道具と同じく明らかに有用な道具だと述べ、カーネルを反AIのプロジェクトにはしない、受け入れられないならフォークするか離れればよいという立場を示した。

この結果、論点は「AIを使うか」から「AIの出力をどう運用するか」に移った。誤検知の扱い、AIが生成したパッチの増加、レビューのトラフィック増加が、現在の保守担当者の課題である。パッチの投稿者がAI生成コードを自分で確認し、ライセンスの適合性を確かめ、最終責任を負うという原則は変わらない。

プログラミングへの「ゲートウェイドラッグ」としてのAI

トーバルズは、AIを本番のカーネル開発にそのまま使うことには慎重である一方、プログラミングへの入り口としては優れた道具だと評価している（動画 33:06）。根拠は自身の趣味の電子工作での経験である。

AudioNoiseの例

トーバルズは2024年末からギターエフェクターの自作を趣味にしており、カーネルのリリース告知でもはんだごてを使う大人向けのLEGOと表現していた。2026年1月には、デジタルオーディオエフェクトを試すリポジトリAudioNoiseをGPLv2で公開した。

部分 言語 書き方
エフェクト本体（信号処理） C トーバルズが手で書いた
音声サンプルのビジュアライザー Python Google Antigravityによるバイブコーディング

READMEには、PythonよりもアナログフィルタのほうがわかるのでAIに任せた、という趣旨の説明がある。従来ならWeb検索で見つけたコードを真似て動かしていた作業を、AIに直接やらせた形である。

使い分けの基準

トーバルズの使い分けは明確である。自分が得意でないUIデザインなどの周辺部分はAIに任せ、ものづくりの楽しさを取り戻す（34:50）。一方、長期の保守が必要な本番コードについては、バイブコーディングは入門には良いが保守には向かないという立場を以前から示している。コードの責任を負える領域かどうかが、AIに任せる範囲の境界になっている。

まとめ

Linuxの開発プロセスは、ボトルネックを見つけるたびに道具と運用を変えて人間のレビュー能力を広げてきた。対談の要点は次の3つである。

  1. 集中を分散へ：パッチの書き直しとtarball配布から、BitKeeperを経てGitへ移り、統合作業を保守担当者の階層に分散した
  2. 不定期を定型へ：約10週間のサイクルで小さな変更を積み重ね、カーネルを予測可能で「退屈」なものにした
  3. 人力のレビューにAIを追加：Sashikoは公開1年未満で19万件超のパッチをレビューした。ただし最終責任は人間が持ち、AIの出力をどう運用するかが次の課題になっている

参考