著者 Linuxカーネルの歴史と重要な設計判断
Linux kernel 0.01から7.xまでを、GPLv2採用、microkernel論争、git誕生、LTSモデルの決定とともに整理します。各判断がサーバー運用に与えた影響も解説します。
Linux カーネルの歴史：概要
Linux kernel の歴史は、1991 年 9 月の version 0.01 から、現在サーバーで起動している 7.x series まで続いています。リリース一覧は、歴史の中で最も重要でない部分です。少数の決定が Linux kernel の形を定め、それぞれが、今日午後に借りるサーバーにも影響を与えています。そもそも 1991 年に新しい kernel が必要だった理由については、Unix、AT&T のライセンス、そして BSD を停滞させた訴訟に関する詳しい経緯を参照してください。
ここで示す日付とバージョン番号は、kernel.org と同サイトが公開しているリリース履歴に基づいています。2026 年 8 月時点の状況は次のとおりです。7.0 は 2026 年 4 月 12 日にリリースされ、7.1 は 2026 年 6 月 14 日にリリースされ、7.2 は release candidate の段階です。
1992 年の GPL 採用が現在も重要な理由
Version 0.01 は 1991 年 9 月 17 日、Torvalds が自ら作成したライセンスの下で公開されました。ソースコードの配布を義務付け、さらに重要な条項として「料金のために配布してはならず、『取り扱い』費用も認めない」と定めていました。1991 年当時、ソフトウェアはフロッピーディスクで配布され、フロッピーディスクの複製や郵送には費用がかかりました。この条項により、商用 Linux ディストリビューションは不可能でした。
Torvalds はこの方針を変更しました。GNU General Public License (GPL) への移行は、1992 年 1 月の 0.12 のリリースノートで発表され、1992 年 2 月 1 日に発効しました。1992 年 3 月の Version 0.95 が、このライセンスの下で公開された最初のリリースです。その後 Linux 上に構築されたすべてのビジネスは、この変更を基盤としています。
Kernel は GPL version 2 only であり、version 3 には移行していません。Torvalds は 2007 年に移行を拒否しました。主な理由は GPLv3 の anti-tivoisation rule です。この規則では、GPL code を搭載して出荷するデバイスに、そのコードの改変版も受け入れさせる必要があります。Torvalds は、ロックされたハードウェアをメーカー自身の事業上の判断と考えました。2017 年、kernel 開発者は Kernel Enforcement Statement を公開しました。これは GPLv3 の要素を 1 つ取り入れています。違反を通知された後に違反を是正した者は、最初の違反時点でライセンスを永久に失うのではなく、ライセンスを保持できます。
サーバーでは、2 つの結果が生じます。起動する kernel binary には、対応するソースコードを受け取る権利が付随します。そのため、検査も再ビルドもできない Linux kernel を誰かから渡されることはありません。また、kernel の copyright notice には、通常の system call で kernel services を利用する user programs はライセンスの対象外であると記載されています。これが、proprietary databases や monitoring agents が何の問題もなく Linux 向けに出荷できる理由です。Permissive licence では逆の圧力が生じます。platform を選ぶ前に、この違いを理解しておく価値があります。Linux と FreeBSD のサーバープラットフォームとしての比較を参照してください。
実運用でモノリシックカーネルが主流になった理由
1992年1月29日、Andrew Tanenbaum は comp.os.minix ニュースグループに「LINUX is obsolete」という題名のメッセージを投稿しました。彼は2つの主張を示しました。ドライバーとファイルシステムが1つの特権アドレス空間内で動作するモノリシックカーネルは1970年代の設計であり、それらが通常のプロセスとして動作するマイクロカーネルこそが将来の設計だという主張です。もう1つは、Linux は Intel 386 に強く依存しているため、他の環境へ移植されることはないという主張でした。
移植性に関する主張には、移植によって答えが示されました。1995年3月の Version 1.2 では Alpha、SPARC、MIPS が追加されました。1996年6月の Version 2.0 では、64-bit Alpha への移植が追加されました。
設計に関する主張には、妥協案で対応しました。Linux はマイクロカーネルにはなりませんでした。その代わり、ロード可能なカーネルモジュールを導入しました。これは実行中のカーネルに挿入したり、再び取り外したりできるオブジェクトファイルです。そのため、ドライバーをカーネルバイナリとは別に配布できます。
lsmod | head
modinfo virtio_net | head -5lsmod は現在ロードされているモジュールを一覧表示します。modinfo はモジュールの元になったファイルと、受け付けるパラメーターを表示します。仮想サーバーでは、ディスクやネットワークの処理経路の大部分がモジュールで構成されています。そのため、実際には認識したことのないハードウェアでも、1つのカーネルイメージで起動できます。カーネルは新しいハードウェアを通知するだけです。どのモジュールをロードするか、デバイスにどの名前を付けるかは、ユーザー空間のデーモンが決めます。この仕組みによって、デバイス管理は init システムの中に組み込まれました。これは systemd を避けにくくなった理由の1つでもあります。
モジュールによって、マイクロカーネル設計に伴うコストを負担せずに柔軟性を得られました。ドライバーを独立したプロセスで隔離すると、呼び出しのたびにコンテキストスイッチとメッセージの送受信が必要です。1992年当時、そのコストは大きなものでした。
Linux が引き受けたコストは、運用計画に組み込む必要があります。モジュールは完全なカーネル権限で動作するため、不正なモジュールが1つのプロセスではなくマシン全体を停止させる可能性があります。この問題が特に現れるのが、カーネルツリー外のモジュールです。mainline に含まれていないベンダー製ドライバーは、新しいカーネルごとに再ビルドする必要があります。アップグレード中にこれを行うのが DKMS です。ビルドに失敗すると、再起動後にそのデバイスが単に利用できなくなります。
SMP の完成に 15 年かかった理由
1996 年 6 月の Linux 2.0 は、対称型マルチプロセッシング（SMP）をサポートした最初のカーネルでした。これは、1 つのカーネルを複数の CPU で実行する仕組みです。最初の実装では、big kernel lock（BKL）という単一のロックを使用していたため、カーネルコード内に入れるプロセッサは常に 1 つだけでした。そのため、2 番目の CPU はユーザー空間で計算するワークロードには効果がありましたが、システムコール中心のワークロードにはほとんど効果がありませんでした。システムコールは同じロックの後ろで待機したためです。
このロックの削除には 15 年かかりました。残っていた利用箇所は、主に Arnd Bergmann によって粒度の細かいロックへ移行され、BKL は 2.6.39 で削除されました。2.6.39 は 2011 年 5 月 18 日にリリースされています。スケジューラの改良も同じように長い時間を要しました。2.6.0 では O(1) scheduler が導入され、2007 年の 2.6.23 から Completely Fair Scheduler（CFS）が使われ、2023 年 10 月の 6.6 では CFS が EEVDF に置き換えられました。
この作業が進んだため、現在では 4 vCPU のプランは珍しくありません。ただし、理解しておくべき限界もあります。共有仮想サーバーでは、カーネルがスレッドをスケジュールし、ハイパーバイザーがカーネルをスケジュールします。top を実行して、%st フィールドを確認してください。steal time は、カーネルが使用できる状態だった CPU をホストが別のゲストに割り当てた時間です。そのため、カーネル内部のチューニングで取り戻すことはできません。
2.6 系列でカーネルのビルド方法が変わった理由
2.6 より前は、バージョン番号が2つの系列に分かれていました。2番目の番号が偶数なら安定版系列（2.4）、奇数なら開発版系列（2.5）でした。2.4 は2001年1月4日に、2.6 は2003年12月17日にリリースされたため、ユーザーは次の安定版系列を約3年間待つ必要がありました。ディストリビューションは待てなかったため、バックポートを行いました。2つのベンダーがどちらも「2.4」を出荷していても、含まれるパッチは数千個単位で異なっていました。
この分割は2.6 の後に廃止されました。現在の mainline は約2週間のマージウィンドウを開いて新しい変更を取り込み、その後、変更が落ち着くまでリリース候補版を公開し、9〜10週間ごとにリリースします。これは kernel.org が現在も説明している周期です。もう一方の仕組みは、2005年3月4日に最初の stable tree がリリースされたことで導入されました。これは2.6.11 に対する修正のみの更新で、Greg Kroah-Hartman と Chris Wright が保守しました。stable tree は修正を取り込み、新機能は受け付けません。
副作用として、バージョン番号は保証ではなくなりました。3.0、4.0、5.0、7.0 は書き直し版ではありません。Torvalds は2番目の番号が大きくなりすぎて気になると、最初の番号を上げます。そのため、7.0 は2026年4月に6.19 の後継として登場しました。サーバーで重要なのは、ディストリビューションがどのブランチを追跡しているか、そしてそのブランチにまだ修正が提供されているかです。
2005 年 4 月、BitKeeper の離脱から git が生まれた経緯
2002 年 2 月から、2.5 系列の開発では、Larry McVoy の会社 BitMover が提供するプロプライエタリな分散バージョン管理システム BitKeeper が使われていました。BitMover は、条件付きで kernel 開発者に無料ライセンスを提供していました。競合するバージョン管理ツールの開発に取り組んではならず、BitKeeper をリバースエンジニアリングしてはならないという条件です。多くの開発者は、内容を読むことを許されていないツールで free kernel を開発することを好みませんでした。
2005 年 4 月、Andrew Tridgell が BitKeeper のリポジトリと通信するプログラムを実演した後、その関係は破綻しました。BitMover はこれをリバースエンジニアリングと判断し、無料ライセンスを撤回しました。kernel は開発サイクルの途中でバージョン管理システムを失いました。
git の開発は 2005 年 4 月 3 日に始まりました。Torvalds は 4 月 6 日に発表しました。4 月 7 日には git 自身の履歴がすでに git で管理されており、git が self-hosting になりました。複数のブランチを初めてマージしたのは 4 月 18 日です。2005 年 6 月、git は 2.6.12 のリリースを管理しました。その後まもなく Torvalds は保守を Junio Hamano に引き継ぎ、kernel の開発に戻りました。
この設計は、問題から直接導かれました。何千人もの貢献者が存在し、誰も信頼していないネットワーク越しにメンテナー同士が相互に変更を取り込む必要があったためです。各オブジェクトには内容のハッシュを名前として付けます。そのため、過去の履歴を 1 バイト変更すると、それ以降のすべてのコミットの名前が変わります。これが、clone が単なる主張ではなく証拠になる理由です。すべての deploy pipeline、すべての configuration repository、多くのチームが push する code host、そして 自分で運用できる git server は、kernel をめぐるライセンス論争から生まれました。
LTS モデルが保証すること、保証しないこと
Mainline は通常運用に使うものではありません。Mainline リリースは 9〜10 週間後に後続リリースへ置き換えられます。stable ツリーには、各リリースの後も数週間にわたって修正が提供されます。通常 LTS と表記される Longterm ブランチには、修正が数年間提供されます。ディストリビューションは通常、このブランチを基盤に構築されます。
2009 年 12 月にリリースされた 2.6.32 で、このモデルの有効性が証明されました。RHEL 6、Debian 6、SUSE Linux Enterprise 11 SP1、Ubuntu 10.04 LTS がすべてこのバージョンを採用し、このブランチは登場から 6 年以上経過した 2016 年 2 月まで保守されました。Red Hat はさらに長く対応し、RHEL 6 が 2020 年に終了するまで、2.6.32 ベースのカーネルに独自の backport を提供しました。この 10 年間のサポートを無償で再現することが、CentOS が存在し、Rocky Linux と AlmaLinux がそれを置き換えた主な理由です。
この保証期間は何度も変更されています。2 年だった時期もあれば、一部のブランチでは 6 年だった時期もあります。2023 年、stable のメンテナーは既定の期間を 2 年に戻しました。古いツリーへの backport にはメンテナーの時間がかかり、古いブランチは実際のテストがほとんど行われないためです。2026 年 2 月 25 日、Greg Kroah-Hartman は、それらのブランチに依存する企業との協議を経て、より長い見通しを再び公開しました。現在の枠組みでは、保守期間は 3〜6 年です。
The data behind this chart
[
{
"kernel": "5.10",
"released": "2020-12-13",
"eol_projected": "Dec 2026",
"maintained_for": 6.0
},
{
"kernel": "5.15",
"released": "2021-10-31",
"eol_projected": "Dec 2026",
"maintained_for": 5.1
},
{
"kernel": "6.1",
"released": "2022-12-11",
"eol_projected": "Dec 2027",
"maintained_for": 5.0
},
{
"kernel": "6.6",
"released": "2023-10-29",
"eol_projected": "Dec 2027",
"maintained_for": 4.2
},
{
"kernel": "6.12",
"released": "2024-11-17",
"eol_projected": "Dec 2028",
"maintained_for": 4.1
},
{
"kernel": "6.18",
"released": "2025-11-30",
"eol_projected": "Dec 2028",
"maintained_for": 3.1
}
]2026 年 8 月時点で、kernel.org には 6 個の Longterm ブランチが掲載されています。最も古い 5.10 は、Dec 2026 に終了する時点で、6.0 年間修正が提供されたことになります。最も新しい 6.18 は、Dec 2028 まで継続する見込みです。これは 3.1 年間の修正提供に相当します。
これらの日付は契約上の保証ではなく、最低限の目安として扱ってください。6.6 と 6.12 の見通しは、どちらも 2026 年 2 月に延長されました。一方、利用者のいないブランチは予定より早く廃止される可能性があります。通常はディストリビューションが選択を行います。Debian 13 は 6.12 を採用し、Ubuntu 26.04 LTS は 7.0 を採用します。この差が、サーバーにおける LTS と中間リリースの選択の実質的な内容です。また、Ubuntu 24.04 を 26.04 にアップグレードするときに、実際に環境下で変わる部分でもあります。
ここから 1 つ注意点が生じます。Ubuntu 24.04 で uname -r を実行すると、6.8.0-51-generic のような値が表示されます。これは upstream のベースにディストリビューション独自の backport を加えたものです。そのため、番号から分かるのはブランチの出発点であり、含まれる修正の内容ではありません。カーネルをバージョン文字列だけで判定するスキャナーが、ディストリビューションのカーネルに対して誤検知を出すのは、まさにこのためです。
現在、カーネルで議論されていること
2 つの議論が進行中です。どちらも、誰が作業を担うのかが論点です。
Rust は 2022 年 12 月の 6.1 で、基盤機能として導入されました。7.0 では実験的という位置付けが外れたため、カーネルの中核言語は C、アセンブリ、Rust です。また、ビルドに nightly compiler は不要になりました。争点は保守です。C のメンテナーがインターフェースを変更すると、確認していない Rust バインディングを壊す可能性があります。その修正を誰の責任にするのかが議論されています。
2 つ目の議論は、AI によるコントリビューションです。機械支援によるパッチがメーリングリストに届く量が増えたことを受け、Sasha Levin は 2025 年 7 月にポリシーを提案しました。この文書は 2025 年 12 月 23 日にコミットされ、現在はカーネル自身のプロセス文書 docs.kernel.org/process/coding-assistants.html に掲載されています。AI エージェントは Signed-off-by タグを追加してはいけません。この行は Developer Certificate of Origin (DCO) を認証するものであり、認証できるのは人だけだからです。支援を受けた場合は Assisted-by: タグで申告します。ツールは著者ではないため、レビュー中に Co-developed-by: から変更されました。生成コードは GPL-2.0-only と互換性が必要です。パッチを送信する人が内容をレビューし、その責任を負います。
このポリシーの背景にあるのは、レビュー時間への圧力です。パッチの生成には数秒しかかかりませんが、レビューにはメンテナーの午後の時間が必要です。タグを付けても、この不均衡は解消されません。維持されるのは来歴です。履歴には各変更に署名した人物が記録され続けます。これは、2004 年に DCO が保護する目的で導入された性質です。
レンタルサーバーにとって、この歴史が意味すること
- ライセンスがあるため、プロバイダーが起動する kernel を読み取り、再構築できます。また、プロプライエタリソフトウェアもその上で実行できます。
- モノリシック設計のため、1 つのドライバーのバグでマシン全体が再起動します。また、out-of-tree モジュールは kernel をアップグレードするたびに再構築が必要です。
- リリースモデルのため、バージョン番号から分かることは多くありません。一方、ブランチとその end-of-life 日を見れば、ほぼすべてを判断できます。
- 仮想化方式によって、実行できる操作が決まります。KVM では独自の kernel を起動してモジュールをロードできます。一方、ホストの kernel を共有するコンテナ仮想化では、
uname -rでホストのバージョンが表示され、modprobeは失敗し、複数の sysctl は読み取り専用になります。
FAQ
Linux カーネルはなぜ GPLv3 ではなく、いまだに GPLv2 なのですか？
Torvalds は 2007 年に GPLv3 の採用を見送りました。主な理由は、GPL コードを搭載したデバイスに、そのコードの改変版も受け入れさせる反 Tivoization 条項です。Torvalds は、ハードウェアをロックするかどうかはメーカーの事業判断だと考えています。実際には、再ライセンスもほぼ不可能です。カーネルの著作権は数千人の貢献者が保有しており、頼れる著作権譲渡契約もないためです。カーネルは GPL-2.0-only なので、GPLv3 のみで提供されたコードは統合できません。
Linux カーネルはモノリシックカーネルですか、それともマイクロカーネルですか？
ロード可能なモジュールを備えたモノリシックカーネルです。ドライバーとファイルシステムはカーネルのアドレス空間内で動作し、lsmod には現在ロードされているものが表示されます。モノリシックカーネルは速度に優れる一方、障害の影響範囲が大きくなります。不具合のあるモジュールによってマシン全体が panic する可能性があるためです。マイクロカーネルであれば、通常は 1 つのプロセスだけが失われます。1992 年以降は、ユーザー空間で動作する FUSE ファイルシステムや、実行前にカーネルが検証する eBPF プログラムによって、この違いは小さくなっています。
mainline、stable、longterm カーネルの違いは何ですか？
mainline は Torvalds のツリーで、9 から 10 週間ごとにリリースされます。新機能はまず mainline に入ります。stable は直近の mainline リリースを基にし、数週間にわたってバグ修正を受け取ります。longterm ブランチは数年間にわたって修正を受け続けます。ディストリビューションは通常、このブランチを基にカーネルをビルドします。kernel.org には、現在の longterm ブランチと、それぞれの予定された EOL 日が掲載されています。
Linux カーネルは AI が作成したコードを受け入れますか？
はい。2025 年 12 月に定められたポリシーに基づきます。使用したツールを Assisted-by: タグに記載する必要があります。AI agent は Signed-off-by 行を追加してはなりません。また、生成コードは GPL-2.0-only と互換性が必要です。提出者である人間は sign-off を行います。これは、パッチをレビューし、Developer Certificate of Origin に基づく責任を負うことを意味します。
サーバーではどのカーネルバージョンを実行すべきですか？
ほとんどの場合、ディストリビューションが保守しているものを使います。ディストリビューションのカーネルは、longterm ブランチ、バックポートされた修正、ベンダーによるテストを組み合わせたものです。プロバイダーのイメージやサポート契約も、通常はこのカーネルを前提としています。特定のドライバーや機能が必要な場合は、より新しい mainline カーネルをビルドします。ただし、移行先のブランチの EOL 日を確認してから採用してください。