12月9日、Linux Foundation主催の「Open Source Summit Japan」の会場となった東京・虎ノ門ヒルズのフロアは早朝から多くの人々であふれていました。参加者のお目当ては2年ぶり[1] の来日となった“ Linux ＆ Gitクリエーター” ことLinus Torvalds氏と聞き手役のDirk Hohndel氏（Verison所属、以下Dirk）によるトークセッションです。
2年ぶりの日本でのトーク、Linus Torvalds氏（左）とDirk Hohndel氏
めったにインタビューやキーノートに登壇することがないLinusのリアルな声を聞くことができる貴重な機会である本セッションは今回で29回目、東京は他の会場よりも多い6回目の開催となります。「 我々は毎回、日本に来ることをとても楽しみにしている。毎回、立ち見が出るほど満員となる東京の会場でセッションを開催できるのは本当にうれしい」（ Dirk）と登壇者の二人も満員の参加者も楽しみにしていたこのトークセッションでLinusは何を語ったのか、本稿ではその概要を紹介します。
カーネル開発は“退屈”くらいがちょうどいい
東京でのサミット開催の約1週間前となる11月30日、Linusは2025年最後のカーネルとなる「Linux 6.18」を公開し、同時に次の「Linux 6.19」に向けて2週間のマージウィンドウ期間に入りました。なお、Linusはこのトークセッションの5日後の12月14日にLinux 6.19の最初のリリース候補版となる「Linux 6.19-rc1」を公開しています
Dirkは最初の質問として「Linux 6.18のハイライトは？」と聞いていますが、これに対しLinusは「いつもと同じ、退屈なもの。だけど僕は退屈なものが好きなんだ。とくにカーネル開発においては刺激的なものを求めたりはしない。“ 着実な進歩（solid progress）” こそがカーネル開発のキーワードで、僕はそれを35年続けている。実際、カーネルアップデートの大半は新規ハードウェアのサポートで、カーネルの半分は文字通り、ハードウェアドライバでできている」と答えています。Linusは以前から継続的で地道なプロセスこそがLinuxカーネル開発の本質であるとコメントしていますが、そのポリシーがまったく変わっていないことを冒頭から示したスタートとなりました。
Linux 6.18は公開から3日後の12月3日に長期サポート版（LTS）となることが明らかになり、今後2年間に渡ってサポートされるカーネルとなります。ここ数年はその年の最後にリリースされたカーネルがLTSになることが多く、また、LTSとなることはリリース後に発表されていますが、LinusはLTSとなるカーネルについて「基本的には年末に出るカーネルがLTSになるということで誰もが認識しているし、実際にそうなっていることが多いけど、絶対に決まっているというわけじゃなくて、柔軟性をもたせている。事前に“ このバージョンがLTSになる” と公式に決定してしまうと、“ じゃあLTSに必要な機能を全部詰め込まなきゃ” とあわてる開発者があらわれる。つまり安定したLTSカーネルであるはずのものに、あせった人々が作った新しいコードが組み込まれてしまい、安定性に支障をきたしてしまう。そういう事態は避けたい（実際にそういうことがあった） 」と語っています。
もっとも最近では「年末のリリース＝LTS」というパターンに開発者もユーザも慣れてきていて、「 LTSを前にしてあれもこれもと機能を詰め込む人は少なくなった」（ Linus）そうです。2ヵ月ごとにメインラインカーネルがアップデートされ、LTSがほぼ1年ごとに提供されるという“ solid progress” がLinuxカーネル開発の通常のスタイルとしてすでにひろく浸透しており、「 あわてなくても次のリリース（またはLTS）を待てばいいということに多くの人々が気づいたからでは」とLinusはコメントしています。
マージ、 マージ、 マージして、 夢の中でもマージして……
「僕はもうコーディングはしていない」―Dirkから「最近のきみは（カーネル開発で）何をやっているの？」という質問に対し、Linusはこう答えています。2年前のトークセッションも同じように「もうコードは書いていない」と発言したLinusですが、では何をしているのかというと、「 ほかの人が開発したコードやほかの人がメンテナンスしたコードを受け取り、マージすること」 、つまりマージこそが自分の仕事だと明言しています。2週間のマージウィンドウ期間中にLinusが受け取るのは「だいたい1万2,000件くらいのコミット、数百件のプルリクエスト」（ Linus）という膨大な量で、2週間のうちの最初の1週間は「9時から5時までではなく、文字通り朝から晩までずっとマージ」しており、残りの1週間は遅れてやってきたリクエストの処理や、詳しく調べる必要があるコードの調査などに当てているそうです。
これだけの量のコードをマージするとなると、「 必然的にマージの競合（コンフリクト）が発生するのでは？」（ Dirk）という疑問も湧いてきますが、Linusは「マージで衝突が発生するとき、つまり2人が同時に同じ領域に触れてしまったときは、何が起こったのか、何が間違っていたのかを突き止めなければならない。僕はずっとマージをしているので、サブシステムメンテナーには事前マージをしないでほしいと頼んでいる。それぞれの担当分野に関しては彼らのほうが詳しいかもしれないけど、マージに関して僕より詳しい人はいないし、僕のほうがずっとうまくできるから、どんなコンフリクトが発生しているかを把握しやすい」と答えています。マージが複雑すぎる場合などはサブメンテナーにテストディレクトリで事前マージを依頼することもあるそうですが、それはLinusのマージ結果と比較するためであり、「 僕のマージで問題がある場合もあるけど、実際には彼らのマージで問題が発生しているほうがずっと多い」（ Linus）とのこと。
僕よりマージに詳しい人間はいない
「マージばかりやっているので、最近は眠っているときでも夢のなかでマージしている」というLinusですが、数百人のメンテナーと数千人の開発者が関わり、約4000万行にも上るLinuxカーネルを9週間ごとにリリースできているのは、Linusがひたすらマージ作業に徹していることも重要なポイントだといえます。「 僕がやることは全体を把握するだけで、細かい部分はそれぞれの開発者に任せているし、サブメンテナーをほぼ完全に信頼している。コードのことは気にせずに、メンテナンスとフロー、そしてリリーススケジュールがきちんと守られ、すべてがうまく機能することに集中している。それが僕の仕事だ」（ Linus）
齢55にして“怒りの炎”は衰えず…？
なお、メンテナー/サブメンテナーを完全に信頼しているというLinusでも、（ かつてほどではないにしても）ときどき怒りのスイッチがオンになってしまうことがあるようです。Dirkから「メンテナーに対して腹を立てるのはどんなとき？」と聞かれると、Linusはすぐに「マージウィンドウ終了予定日の前日の土曜日にプルリクエストが届いたとき」と答えています。マージの仕上げの作業を終え、ひと息ついてから最初のリリース候補版（RC1）の準備をしようとしているタイミングで、真新しいプルリクエストが手元に届いたら…Linusでなくとも感情の抑制に苦労しそうですが、そういう場合はなるべく「もう手遅れ。あと9週間待つように。もっと状況を理解するべきだ」と返すそうです。実際、カーネル開発者のメーリングリスト（LKML）では、マージウィンドウ最終日にプルリクエストを送ってきたメンテナー/サブメンテナーがLinusにこんこんとたしなめられていることがよくあり、残念ながら「彼らは（このタイミングでは送ってはいけないと）わかっているはずなのに送ってくる」（ Linus）という状況はなかなか改善されないようです。
もうひとつ、Linusが「本当に腹を立ててしまうこと」として挙げていたのが、バグの責任を認めない開発者の言動です。Linusはマージ作業とは別に、毎日自分のマシンでカーネルを起動し、テストを実行していると話していましたが、カーネルを起動すると必ずどこかでバグが見つかるので、担当者がやるべきテストをしていないことに気づくといいます。そういうときはなるべく丁寧に、感情をぐっとこらえつつ、メンテナーに対して「きみは自分の仕事をしていない」という主旨のメールを送るように努力しているそうです。「 何十年も一緒に仕事をしてきた人たちが、わかっているはずなのにそういう態度をとっている（バグを放置している）と、やっぱりイライラしてしまう」と不快感を示したLinusですが、いらだちを覚えるのはバグそのものに対してではないという点をあらためて強調していました。「 バグが発生するのは避けられないことだ。我々は完璧ではない。どんなに最新の注意を払い、最善を尽くしてたとしても、これからもずっとバグは発生するだろう。でもバグを指摘されたのに、“ それは私のミスでした。すぐ直します” とは言わずに、“ バグを直したら別のバグが発生した” みたいな言い訳をする態度は許されない。システムが信頼できるものではないということを意味するからだ。僕も指摘するときはなるべく直接的にならないように、礼儀正しくふるまうように努力をしているんだけど…（僕の指摘で）もしこの会場の誰かの心を傷つけていたなら本当に申し訳ない」（ Linus）
毎度腹を立ててすいません
“ツールとしてのAI”には期待している
Linuxカーネル開発という長年にわたる巨大プロジェクトでは、さまざまなプロセスにおいてツールによる自動化が行われてきていますが、Dirkの次の質問は「Linusがいままで話してきたいくつかのプロセス ―マージ、コンフリクトへの対応、バグの検知などに最新のAI技術やAIツールが使われる余地はあるか」というものでした。これに対しLinusはすぐに「もちろんある」と答えており、このトークセッションの翌日に行われる「Linux Kernel Maintainer Summit」で、ツールにAIを使う場合のポリシーについても議論する予定だと話しています。
Linusはここで開発ツールとしてのAIに対して思うところをこう発言しています。
「僕はAIというテーマは嫌いだ。AIが嫌いなのではなく、AIがあまりにも誇大宣伝されすぎていて、テクノロジの世界がAI一色になっているところがいやなんだ。だけど僕はツールとしてのAIは強く信じているし、コードレビューにAIを使うプロジェクトはすでに進行中だ。一方でコードを書くためのAIにはあまり興味がない。僕にとって興味があるのはコードメンテナンスを支援するツールとしてのAIだ。AIによってチェックされたコードが僕の手元に届くようになれば、僕のワークフローもずいぶん楽になるんじゃないかな」
メンテナンスツールとしてのAIには強い可能性を感じているが、コーディングツールとしてのAIには興味がない ―これがLinusの現在のAIに対する見解のようです。なお、発言内で触れられていた“ コードレビューにAIを使うプロジェクト” とはある企業と共同で行っている内部プロジェクトで、既存の複雑なツールチェーンに新たにAIレイヤを追加し、そこでパッチをチェックしたり不良コードをリリースしないようにする機能をもたせる開発を行っているそうです。Linusはこのツールの問題特定能力とその説明能力を見て「このツールが欲しい!と思った」と高く評価しており、「 Linuxは現在、多くのAIワークロードのベースになっているけど、Linuxカーネル開発ではあまり使われてこなかった。でも今後は変わってくるだろう」とコメントしています。
一方でLinusが「あまり興味がない」としたAIによるコーディングですが、これに関してDirkは「これから開発を始める人にとってLLMやAIツールが役に立つと思ったことは？ とくに4000万行ものコードを抱えるカーネル開発に、より多くの開発者が参加するのにAIツールが役立つ可能性はあるだろうか」という質問をしています。対してLinusは「カーネル開発には多くの人々が参加しているが、カーネルは特殊な分野でもある。プログラミングにおいてもっとも興味深い分野のひとつであり、多くの人々がカーネル開発に目を向けてくれたらいいと思う」としたうえで、「 だがプログラマとしてスタートするなら、カーネルから始めるのは避けたほうが無難じゃないかな。最初はあまり複雑じゃない、もっと小さなプロジェクトから始めたほうがいい」と回答しており、初心者がAIツールに頼りながらカーネル開発にジョインすることはあまり推奨していないようです。
AIコーディングにあまり興味を示さない理由について、Linusはコンパイラとの比較を通して次のように語っています。
「AIは全般的に誰でも使えるツールだと僕は思っている。しかしそれは新しくてエキサイティングな一方で、古くさいものだともいえる。人々がコンパイラを使い始めたころ、コンパイラによってコードを書く作業が格段に楽になったのと同じ現象だからだ。僕が使い始めたころのコンパイラはわりとひどいものだったけど、現在のコンパイラはまるで魔法のようで、コンパイラによってプログラマは詳細がわからなくても仕事ができるようになった。“ AIで10倍プログラミングが速くなった” なんていう人がいるけど、コンパイラによってプログラミングは1000倍加速した。つまりAIはそれほど特別なものではなく、突然プログラミングに革命を起こす存在ではないということだ。だって何十年も前にすでにコンパイラがそれを成し遂げているんだから。仮に今後、AIが10倍、100倍のスピードアップを実現したとしても、AIがツールであることは何も変わらない。もちろんAIはすばらしいツールで、新しいことを可能にする。10倍、100倍のスピードでより多くのすばらしいプロジェクトを達成できるようにするだろう。でもあくまでもツールでしかない ―これが僕の考えだ。もし10年後にロボットが世界を支配するようなことになって、僕らがみんな殺されてしまうような事態になったら、僕が間違っていたと認めよう」（ Linus）
AIはそんなに特別なものじゃない
もっともAIツールがコンパイラよりすぐれている点もいくつかあることはLinusも認めており、これまで見てきた中で気に入っているAIのケイパビリティとして「チェッカーにすべての詳細を説明する必要がない」ことを挙げています。「 コンパイラに自分の意図を説明するときは非常に低いレベルで説明しなくてはならなくて、多大な労力を要する。でもAIは抽象化のレイヤがもうひとつあるので、より高いレベルで説明することが可能だ。これによって、人間がより簡単に、効率的に仕事をすることが可能になるだろう。だから僕は、AIに関するこの騒ぎが少し落ち着いてから起こることのほうを楽しみにしているよ」（ Linus）
カーネル開発における鉄の掟 ――“ノーリグレッション”
バグの責任を取らないメンテナーについての話が出たとき、Linusは「カーネルには“ ノーリグレッション（no regression）” という非常に厳格なポリシーがある。これはリグレッションが起こらないという意味ではなく、リグレッションにきちんと対応し、“ これはリグレッションなんだけど…” みたいな言い訳をしないという姿勢のことだ」と、ノーリグレッションを引き合いにしてその対応の重要性を強調していました。
Linusがカーネル開発における絶対のルールとして定めているノーリグレッションとは、新しい機能追加によって前のバージョンで動いていた機能が動作しなくなることを認めないというポリシーです。とくにカーネルの変更がユーザ空間のアプリケーションに影響を及ぼすことをLinusは非常に嫌っており、ノーリグレッションのルールを守らない開発者に対してきびしい口調で批判することもたびたびありました。しかしLinuxカーネルに限らず、OSやアプリケーション開発における後方互換性の担保は技術的にもコスト的にも難易度が高いことも事実です。
トークセッションの最後、Dirkはあらためてノーリグレッションについて「いま動いているものを壊さないという要求に応えることができているプロジェクトは非常に少ない。なぜノーリグレッションは難しいのか」とLinusに尋ねました。ここでLinusは「カーネル開発者の中には、ノーリグレッションというルールを気に入っていない人がいることも知っている」と前置きしたうえで、ノーリグレッションの難しさには技術的な問題と文化的な問題があると説明しています。
技術的な難しさ
…リグレッションは長期間発見されにくい。たとえば過去に挙動が変更されたことに気づかないまま古いLTSカーネルを使っていて、2年後に新しいカーネルに更新したときに問題が表面化することがよくある。しかしそのときにはもう新しい挙動を前提としたアプリケーションがたくさん存在するので、もとに戻そうとすると別のリグレッションが発生してしまう。そのためLinuxカーネルでは「プログラムごとに挙動を変える」というアーキテクチャ的には「非常に醜い、ソフトウェアエンジニアとしてはやりたくないこと」（ Linus）までしてノーリグレッションを貫いてきた
文化的な難しさ
…開発者、とくにオープンソースの開発者はプログラミングが好きで、新しいことを探求したがる傾向にある。彼らは新しい動作を目にすると「この変更が正しいんだ。古いモデルは間違っていて、新しいものに変更する必要がある」と考えがちだが、カーネルやライブラリのように多くのソフトウェアが依存関係にある基盤においてあるプログラムの挙動の変更をすることは、単なるバグ修正にとどまらず、そのプログラムに依存しているすべてのプログラムを壊してしまうことにつながる。何十年も前に書かれていまは誰もメンテナンスしていないライブラリに依存しているケースも多く、開発者が簡単に「プログラムの問題を修正したから再コンパイルして」といって済む問題ではない
こうした理由からは、Linuxカーネルでは「既存のインタフェースの挙動は維持する」「 改善や変更など新しいことをする場合には新しいインタフェースを使用する」という厳格なルールを設け、これを採用し続けてきました。しかし実際に4000万行のコードでノーリグレッションを徹底することは難しく、Linusも「ほかのオープンソースやクローズドソースで同じアプローチを取っているプロジェクトはほとんどない」とその困難さを認めています。「 ほかのプロジェクトでもノーリグレッションを採用してくれると嬉しいけど、僕はまだ世界の王になったわけじゃない（Not yet King of the World） 。だからみんなのためのルールを作ることはできないけど、カーネルのためのルールは僕が作らなければならないんだ」（ Linus）
我はまだ世界の王にあらず
冒頭のLinusの「退屈が好き」という言葉に象徴されるように、Linusのカーネル開発における姿勢やはやりのトレンド技術（今回はAI）に対する見解は驚くほど変わっていません。しかし、ノーリグレッションへのアプローチに見られるように、Linusの変わらない“ 退屈” なスタイルと、ときには反発されることも少なくない徹底したルールとポリシーの実践こそがLinuxという巨大プロジェクトを30年以上に渡って継続させ、世界中のあらゆるワークロードの基盤へと進化してきた原動力でもあるように思えます。“ 世界の王” ならぬ“ Linuxの王” として、2026年以降も変わらぬスタイルでプロジェクトを牽引していくことを心から願っています。
