「あなたが修正するのは自分だけのバグではない」、リーナス・トーバルズ氏が東京開催のOpen Source Summit Japan基調講演で語ったこと（後編）

昨日（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年前に書かれたもう実際にはメンテナンスされていないライブラリに依存しているかもしれません。

インフラストラクチャの変更が動作を変える改善を行おうとする場合、それを修正するのは本当に難しいのです。

ですから、カーネルが常に持っているルールは、「私たちはそのような種類の改善は行いません。新しいことをする場合には新しいインターフェースを使用し、古いインターフェースはそのままにしておきます」ということです。

私はカーネルのルールを作るだけ

しかし、他のオープンソースプロジェクトや、その点に関する他のプロジェクトでさえ、このアプローチを採用しているものはほとんどありません。

私はもっと多くのプロジェクトがそうすることを願っていますが、私はまだ世界の王ではないので、他のすべての人々のためにルールを作ることはできません。私はカーネルのルールを作るだけです。