Linux kernel における Rust の実験が終わった。失敗したからではない。成功したからだ。2025年、東京で開催された Kernel Maintainer Summit で、メンテナたちはコンセンサスに達した。Rust はもう実験ではない。kernel の正式な一部であり、「反対意見はゼロ」だった。1

これは単なる技術的マイルストーンではない。保守的なコミュニティがどのようにして基盤技術の変更を決断するか——そして、証拠が伝統を覆すために何が必要だったかという事例研究だ。

問いを突きつけた証拠

システムコードにおけるメモリ安全性の議論は、長年にわたって蓄積されてきた。Microsoft は、毎年発行する CVE のうち約70%がメモリ安全性の問題——バッファオーバーフロー、use-after-free、ダブルフリーなど——に起因すると報告している。これらはメモリ安全な言語がコンパイル時に構造的に防ぐカテゴリだ。2 Linux kernel に限定した数値は手法によって異なるが、パターンは一貫している。C コードベースにおけるセキュリティ脆弱性の支配的なクラスは、Rust のオーナーシップモデルが排除するクラスそのものだ。

理論的な議論を超えて kernel コミュニティを動かしたのは、本番環境の実績だった。Android 16 デバイスは 6.12 kernel 上で、Rust で完全に書き直された匿名共有メモリアロケータ ashmem を搭載して出荷されている。本番環境で数百万台のデバイスがすでに kernel 内の Rust コードを実行しているということだ。3 NVIDIA Turing 世代以降の GPU を対象とした Rust 製ドライバ Nova は、2025年5月に Linux 6.15 へマージされ、mainline 初の Rust 製 DRM ドライバとなった（ただし開発はまだ初期段階にある）。4 Greg Kroah-Hartman がサミットで述べたように、Rust で書かれたドライバは C で書かれたものより安全であることが実証されつつある。1

概念実証ではない。実際のハードウェアで動作し、実際のメンテナにレビューされた本番コードだ。

保守主義のジレンマ

この話で興味深いのは Rust の技術的メリットではない。それはすでに十分に議論されてきた。興味深いのは、根本的に新しいものを採用するに至った、深く保守的なコミュニティの意思決定プロセスだ。

Linux kernel コミュニティが保守的であるのには正当な理由がある。安定性は好みの問題ではない。医療機器、金融システム、重要インフラ上で動くコードにおいて、それは道義的責任だ。kernel のバグの代償は、不便さではなく潜在的な被害で測られる。新しい抽象化レイヤーはバグの温床になりうる。馴染みのないパターンは保守の負担になる。新しい言語はコントリビュータベースの分裂を招きうる。

この保守主義がパラドックスを生む。メモリ安全性を最も必要とするコミュニティが、それを実現するための変革に最も抵抗するコミュニティでもある。

それでも、データは蓄積され続けた。ある時点で、保守的な選択は変化そのものになる。現状維持が代替案より明確に危険だからだ。主要な C コードベースのセキュリティ脆弱性の70%が、別の言語が構造的に防止するカテゴリに該当するとき、現状維持はもはや慎重な選択ではない。リスクの高い選択だ。

何が人々の考えを変えたのか

布教活動ではなかった。Rust-for-Linux コミュニティは早い段階で、本番コードを伴わない熱意はノイズでしかないと学んだ。考えを変えたのは出荷だった——本物のサブシステムの、確立されたメンテナによってレビューされた、本物のコード。

ここにはシステムプログラミングを超えて適用できる教訓がある。確立されたコミュニティにおけるパラダイムシフトは、議論によってではなく実証によって起こる。誰かが仕事をし、結果に語らせることによって。

Rust-for-Linux のコントリビュータたちは、Rust が kernel に属すると主張しただけではない。ドライバを書き、パッチを提出し、敵対的なメーリングリストのスレッドに耐え、動くコードを出荷し続けた。コードそのものが議論になった。

インフラ保守の倫理

ここにはインフラ保守の道義的責任に関する、より深い問いがある。ある種の脆弱性が構造的に防止可能であると分かっていて、それを防止するツールが存在し本番環境で実証されているとき、その脆弱性が悪用された場合の責任はどうなるのか。

仮定の話ではない。kernel のメモリ安全性バグは、実際の攻撃で使用された権限昇格エクスプロイトにつながってきた。kernel コミュニティが Rust を正式採用した時、そこには暗黙の認識があった。今分かっていることを踏まえれば、C のみへの継続的な依存には道義的な重みがある。

C が「悪い」ということでも、すべての kernel 開発者が Rust を学ばなければならないということでもない。コミュニティ全体として、証拠が要求するときにツールを進化させる責任を認識したということだ。その認識——データに伝統を覆すことを許す意志——こそが、この決断を注目に値するものにしている。

波及効果

影響は kernel を超えて広がっている。Debian は2026年5月以降、APT の依存関係として Rust ツールチェーンを必須にする。Rust をサポートしないレガシーアーキテクチャのポートに影響が及ぶ。5 もはや「するかどうか」ではなく「どれだけ速く」の問題だ。

興味深い未解決の問いは、このパターン——保守的なコミュニティ、蓄積される安全性の証拠、段階的な実証、最終的な採用——が他のパラダイムシフトでも繰り返されるかどうかだ。形式検証？Rust 以外のメモリ安全な後継言語？kernel の歩みは、重要インフラがどう進化するかのテンプレートになるかもしれない。

実験のラベルは外された。実験は終わった。仕事は続く。

References

  1. DevClass. “Rust boosted by permanent adoption for Linux kernel code.” Accessed 2026-03-27. ↩ ↩2

  2. Microsoft Security Response Center. “A proactive approach to more secure code.” Accessed 2026-03-27. ↩

  3. Rust for Linux. “Android ashmem.” Accessed 2026-03-27. ↩

  4. Phoronix. “Rust-Written NOVA Open-Source NVIDIA Driver Being Further Built Out In Linux 6.17.” Accessed 2026-03-27. ↩

  5. LWN.net. “Debian to require Rust as of May 2026.” Accessed 2026-03-27. ↩