「AIは過剰に宣伝されているが、ツールとしては大いに信じている」、リーナス・トーバルズ氏が東京開催のOpen Source Summit Japan基調講演で語ったこと（前編）
昨日（2025年12月9日）、都内で開催されたLinux Foundation主催によるイベント「Open Source Summit Japan」の基調講演にLinuxの作者として知られるリーナス・トーバルズ氏が登壇しました。
同氏によると東京で同氏が基調講演に登場するのは7回目。同氏の基調講演は対談形式で行われるのが常であり、今回もベライゾンのOpen Source Program Officeを主導するDirk Hohndel氏がトーバルズ氏に質問する形式で行われています。
本記事では、その基調講演の中から、トーバルズ氏が生成AIを用いたツールについてどのような考えを持っているのか、そしてLinuxがリグレッションを起こさず後方互換性を維持している理由とその難しさについて語っている部分を、ダイジェストとして2つの記事で紹介しましょう。
この記事は前編として、生成AIについてトーバルズ氏が話した部分を記事にしています（後編はこちら）。
AIは過剰に宣伝されているが、ツールとしては大いに信じている
トーバルズ氏 私がここに来たのは、毎年恒例のメンテナーサミットが明日開催されるからです。そこで私たちが議論する予定の大きなテーマの1つが、AIを使用する際の私たちのツールとポリシーを拡大することです。
私はAI全般の話題が嫌いですが、それはAIを嫌っているからではなく、AIが過剰に宣伝されているからです。テクノロジー領域全体がAIになって、他のことは重要ではないかのように扱われているのですから。
しかし同時に、私はAIをツールとして大いに信じています。私たちは（AIを使って）コードレビューを行うプロジェクトを進めています。個人的な話としては、私はメンテナーであり、私にとって非常に重要なのはコードレビューなので、コードを書くためのAIにはあまり興味がないのです。
今では、多くの人がプログラミングについて話すとき、AIを使ってコードを書くことを話題にしますが、私にとっては、コードのメンテナンスを助けるツールとしてのAIも同様に興味深いものに感じています。
実際のところ、どこまで話していいのか分かりませんが、私たちはすでにいくつかの内部プロジェクトを進めていて、パッチをチェックし、ツールチェーンでAIを使用することで悪いコードをリリースしないようにしている人たちがいます。
私にコードが届く前に彼らがチェックするようになって、私のワークフローもずっと軽くなることを願っています。
これは長い間議論されてきたことでありますが、実際にAIでコードレビューを行える段階に来ており、そのうちのいくつかは非常に有望であるため、私はその実現を大いに信じています。そして、来年には、それが私たちのフローにおいて本当に不可欠な部分になることを願っています。
守秘義務があるため名前は伏せますが、最近、現時点ではまだ開発中の、コードの変更を確認するためのAIツールを見る機会がありました。そのAIツールは問題の特定と説明において素晴らしい仕事をしていました。
私はその結果を見て「このツールが欲しい」と思いました。
これは本当に良い例だと思いますが、このマージウィンドウ期間中にこのAIツールを使って起きたことで、私が（コードの変更に）異議を唱えた点について、AIツールはそれに加えて独自の異議をいくつか追加しました。つまりAIツールが、専門家が見つけた問題以上のものを見つけたのです。これは素晴らしい兆候です。
ですから、これは間違いなく本物です。誇大広告なところはありますが、AIツールは疑いの余地なく非常に興味深いものでもあります。
私たちはまだLinuxカーネルの開発支援にAIツールをあまり使用していませんが、その起用は間違いなくこれから起きることでしょう。
コンパイラの進化と比べたらAIはそれほど特別ではない
Hohndel氏 大規模言語モデルやAIツールは人々が開発を始めることをどの程度支援できると思いますか？ 例えばLinuxカーネルは1400万行ものコードでできていて、さまざまな領域のプロセスが存在するなど、開発者として始める前に学ぶべきことがあまりにも多すぎます。
AIツールはこうした分野への開発に人々が参入するのを容易にできると思いますか？
トーバルズ氏 まず言いたいのは、Linuxカーネルの開発者は多くいますが、それでも一般にLinuxカーネルはプログラミングを始める場所ではないと思います。それは少し特別なものです。
私はプログラミングの分野においてカーネルの開発は最も興味深い分野の一つであると本当に思っています。ですから、カーネル開発に興味を持つことを強くお勧めしますが、同時に、もしあなたがプログラミングを始めるのならば、カーネルから始めるのではなく、それほど大きくなく複雑でもない小さなプロジェクトを考えるべきです。
一方で、私はAIが誰でも使えるツールだと思っています。AIツールは新しくエキサイティングに見えますが、実のところコードを書くことを簡単にしたコンパイラと変わりません。
私がLinuxを始めた頃のコンパイラはかなりひどかったことを思い出してください。それに比べれば、現在のコンパイラは魔法のようです。
文字通り、現在のコンパイラはプログラマが多くの詳細を知らなくても自分の仕事をできるようにしてくれます。これは非常に大きなことです。
人々はAIツールがプログラミングを10倍加速すると言いますが、コンパイラはこれまでにプログラミングを1000倍加速してきたのです。これと比べれば、AIはそれほど特別ではありません。AIが突然プログラミングに革命を起こすと考えないでください。
コンパイラを書いた人々が何十年も前にそれをやってきたのです。AIツールがそのコンパイラの上でプログラミングを10倍、あるいは100倍を加速したとしても、それは依然として単なるツールです。
それが私の意見です。そして、もし10年後にAIがロボットを乗っ取って私たち全員を殺していたら、私が間違っていたということになります。私の負けです（笑）。
≫後編に続きます。後編ではLinuxがリグレッションを起こさず後方互換性を維持している理由とその難しさについて語っています。
Page 2
昨日（2025年12月9日）、都内で開催されたLinux Foundation主催によるイベント「Open Source Summit Japan」の基調講演にLinuxの作者として知られるリーナス・トーバルズ氏が登壇しました。
同氏によると東京で同氏が基調講演に登場するのは7回目。同氏の基調講演は対談形式で行われるのが常であり、今回もベライゾンのOpen Source Program Officeを主導するDirk Hohndel氏がトーバルズ氏に質問する形式で行われています。
本記事では、その基調講演の中から、トーバルズ氏が生成AIを用いたツールについてどのような考えを持っているのか、そしてLinuxがリグレッションを起こさず後方互換性を維持している理由とその難しさについて語っている部分を、ダイジェストとして2つの記事で紹介しましょう。
この記事では後編として、Linuxがリグレッションを起こさず後方互換性を維持している理由とその難しさについてを記事にしています（前編はこちら）。
Linuxはリグレッションを起こさないというルールがある
Hohndel氏 あなたは以前、Linuxには「リグレッション（機能の追加や変更によって既存のソフトウェアの挙動が変わってしまうこと）を起こさず、後方互換性を破らない」というルールがあることに言及しました。
Linux以外にそのルールを持っているプロジェクトが非常に少ないのは興味深いところです。そういえばここに来る途中、空港での会話で、Python 3.14にアップグレードしたところあなたが今趣味のプロジェクトで使っているツールが壊れてしまったという話をしましたね。
Linuxカーネルが要求する「機能しているものを壊さない」ということが、なぜ他のプロジェクトではそれほど難しいのでしょうか？
リグレッションを起こさないと言うのは簡単だ
トーバルズ氏 その答えの1つは、それが技術的に難しいからです。なので、カーネル開発者の全員が私のリグレッションを起こさないというルールを好んでいるわけではありません。しかも、それを長期にわたって維持するのは本当に難しいことです。
例えば、新しいバージョンが登場して長い時間が経過した後、そのバージョンでリグレッションを起こしていたことが発見されることがあります。
誰かが古いLTS（長期サポート版）カーネルを採用していて、新バージョンのLinuxカーネルが登場してから2年後に新バージョンにアップグレードしたら、そのときまで2年前の登場時に変更されていた動作変更に気付けなかったということがあり得ます。
新しいカーネルは少しだけ動作が異なるだけだったため、あなたの特定のアプリケーションが壊れたことには他に誰も気付かなかったのです。そして登場からすでに2年が経過しているため、すでに他のアプリケーションがその新しいカーネルの動作に依存し始めているとすると、「ああ、もう古いリグレッションを修正することはできない。なぜならそうすると、すべての新しいプログラムでリグレッションが発生してしまうからだ」となります。
これを修正するのは困難です。つまり「リグレッションを起こさない」と言うのは簡単ですが、実際にそれを守り続けるのは難しいのです。
私たちは、それを守るために、あるプログラムはこの動作を期待しているが、他のプログラムは新しい動作を期待していると認識して、異なるプログラムに対して異なる動作をする、というような、常軌を逸したことさえ行ってきました。普通のソフトウェアエンジニアなら、そんなことはしたくないでしょう。
あなたが修正するのは自分だけのバグではない
もう一つの問題は、特にオープンソースの開発者たちは皆、プログラミングを愛しているから開発を続けている、という点です。
まあ、全員ではなく一部は単に仕事として開発をしている人もいますが、多くはソフトウェアを作り、新しいことを探求し、興味深いプログラムを作るのが本当に好きだから開発をしています。
だから私たちには、新しいことを行うこと、新しい動作を作ることに興味があるわけで、「これが正しい動きだからこの変更を行う。古いモデルからは多くの学びを得たが、古いモデルは間違っていたから直す」と言いたくなるのです。
そうしたい気持ちは分かりますよね？ 私は100％分かります。
しかし、もしもあなたが他の人々が依存するライブラリを作成している場合、あるいは他の人々が依存するライブラリが依存するカーネルを作成している場合、あなたが修正するのは自分だけのバグではありません。あなたはあなたのプロジェクトに依存しているすべてのプログラムを壊しているのです。
そして、開発者として「問題を修正したから、アプリケーションを再コンパイルしてくれ」と言うのは非常に簡単ですが、多くの場合そのアプリケーションは、例えば私自身が腹を立てたトイプロジェクトのケースでは、30年前に書かれたもう実際にはメンテナンスされていないライブラリに依存しているかもしれません。
インフラストラクチャの変更が動作を変える改善を行おうとする場合、それを修正するのは本当に難しいのです。
ですから、カーネルが常に持っているルールは、「私たちはそのような種類の改善は行いません。新しいことをする場合には新しいインターフェースを使用し、古いインターフェースはそのままにしておきます」ということです。
私はカーネルのルールを作るだけ
しかし、他のオープンソースプロジェクトや、その点に関する他のプロジェクトでさえ、このアプローチを採用しているものはほとんどありません。
私はもっと多くのプロジェクトがそうすることを願っていますが、私はまだ世界の王ではないので、他のすべての人々のためにルールを作ることはできません。私はカーネルのルールを作るだけです。
