LinuxカーネルはなぜRustを受け入れ始めたのか——Rust for Linuxの現在地とドライバ開発の変化

はじめに——カーネル開発に起きている静かな転換

「LinuxカーネルにRustコードが入る」と初めて報じられたのは2022年のことです。Linux 6.1で初めてRustサポートがメインラインにマージされて以来、3年あまり。この間、Rust for Linuxプロジェクトは地味ながら着実に前進し、いまやNVIDIAのGPUドライバやAndroidのBinderドライバといった「実際に動くコード」がメインラインに存在する段階まで来ています。

しかし一方で、カーネルのRust対応には未解決の課題も残されています。カーネルはまだRustの安定版機能だけでビルドできず、コンパイラ側との綱引きが続いています。2026年には最小Rustバージョンが1.78.0から1.85.0へと大きく引き上げられ、その背後では「Debian Stableに追従する」という新しいポリシーが採用されました。

この記事では、Rust for Linuxの現在地を次の観点から整理します。

• なぜカーネルにRustが必要とされたのか（技術的動機）
• メインラインに入ったRustコードの実採用状況
• Rustバージョン要件をめぐる問題と新しいポリシー
• 開発者が実際にRustカーネル開発を始める方法

カーネル開発者の視点だけでなく、「組込みやドライバ開発に携わるエンジニアがこの変化をどう捉えるべきか」を含めて解説します。

なぜカーネルにRustなのか——メモリ安全性という動機

カーネル脆弱性の多くはメモリ安全性に起因

Linuxカーネルは世界で最も広く使われているソフトウェアの一つですが、そのセキュリティ脆弱性の相当部分がメモリ安全性の欠陥（use-after-free、バッファオーバーフロー、ダングリングポインタ、データ競合など）に起因するとされています。MicrosoftやGoogleが自社コードの脆弱性分析で「メモリ安全性の問題が脆弱性の約7割を占める」と報告して以降、この知見は業界で広く共有されています。

カーネルは特権モードで動作するため、ユーザーランドのプログラムよりもメモリ安全性のバグの影響が深刻です。1つのuse-after-freeが、そのままシステム全体の乗っ取りにつながり得ます。

Rustがコンパイル時に防ぐもの

Rustは「所有権（ownership）」と「借用（borrowing）」という仕組みにより、ガベージコレクタなしでメモリ安全性をコンパイル時に検証します。具体的には次のバグをコンパイルエラーとして弾きます。

• use-after-free（解放後のメモリアクセス）
• ダングリングポインタ
• 二重解放
• 初期化忘れ
• データ競合（マルチスレッドでの安全性）

これらはまさにカーネルで頻発するバグのパターンと一致します。

「置き換え」ではなく「共存」という設計思想

重要なのは、Rust for Linuxが既存のCコードを全面的に置き換えるプロジェクトではないという点です。数千万行にあるカーネルのCコードを一括でRust化するのは現実的ではありません。

採用されているのは共存モデルです。カーネルの核心部分はCのまま、新規に書くドライバや周辺コードをRustで書く。CとRustの境界は、ビルド時にbindgenというツールがCのヘッダからバインディングを自動生成することで繋がれます。Rust側からCの関数や構造体を型安全に呼び出せるため、段階的な移行が可能になっています。

メインラインに入ったRustコード——実採用ドライバの現在地

メインライン（カーネル本流）に入ったRustコード

Rust for Linuxプロジェクトの公式サイトが掲載する「メインライン内のユーザー」は次の通りです。

特筆すべきはGPUまわりです。NVIDIAは新しいRustベースのNovaドライバをメインラインで進めています。また、DRM PanicのQRコード生成機能は、カーネルパニック時に画面へQRコードでクラッシュ情報を表示するという、エンドユーザーにも見える形でRustが使われた例です。

メインライン外（アウトオブツリー）での採用

Apple Silicon（M1/M2/M3）のGPUドライバを手がけるAsahi Linuxは、Rustでドライバを書く先駆的なプロジェクトとして知られています。

何が読み取れるか

一見すると「まだ7〜10個か」と思うかもしれません。しかし着目すべきは分野の広がりです。GPU・ネットワークPHY・ブロックデバイス・IPC・ファイルシステムと、ドライバの主要分野のほぼ全域でRust実装が出揃いつつあります。抽象化層（GPIO、PCI、DRMなど）が整備されるたびに、次のドライバを書く敷居は下がっていきます。

バージョン問題——「Rust 1.78から1.85へ」の波

根本課題：unstable featuresへの依存

カーネルのRustコードは、実はまだRustの不安定（unstable）機能に依存しています。Rust言語そのものは後方互換性を約束していますが、不安定機能にはその保証がありません。つまり「新しいRustコンパイラが出たら、カーネルがビルドできなくなる可能性がある」という状態が続いてきたのです。

実際、最小バージョンは急速に引き上げられてきました。

• v6.11以降、カーネルは最小Rustバージョンを明示的にサポート開始（当初 Rust 1.78.0）
• Linux v7.1で最小バージョンが Rust 1.85.0 に引き上げ（2026年時点）
• Stable/LTSカーネルは別要件（例: Linux 6.18.yの最小はRust 1.78.0のまま）

新ポリシー：Debian Stableに追従する

2026年初頭以降、プロジェクトは「Debian StableのRustバージョンを最小サポートバージョンとする」方針を採用しました。Debian 13（Trixie）のRustが1.85.0であるため、リリースから数ヶ月の猶予の後、Linux v7.1の最小要件となったわけです。

これは理にかなった妥協点です。「カーネルのビルドに最新Rustが必要」ではディストリビューションのパッケージングが破綻します。Debian Stableのバージョンに固定することで、主要ディストリビューションのツールチェーンで確実にビルドできることを保証できます。

画期的な協調：pre-merge CI

さらに興味深いのが、Rust言語側の取り組みです。現在、Rustコンパイラのリポジトリでは、マージ前のすべての変更に対してLinuxカーネルのビルドテスト（pre-merge CI）が実行されています。つまり、カーネルを壊すようなコンパイラの変更は、Rust側でマージされる前に弾かれる仕組みです。バインディング生成ツールのbindgenも同様にカーネルをビルドテストしています。

graph LR;
  A[Rustコンパイラ変更] -->|pre-merge CI| B{Linuxカーネル<br/>ビルドテスト};
  B -->|成功| C[マージ];
  B -->|失敗| D[差し戻し];
  E[bindgen変更] -->|pre-merge CI| B;

そして「Linuxをstable Rust（安定版機能のみ）でビルド可能にする」ことは、Rustプロジェクトのフラグシップゴールとして2024年後半以降継続的に掲げられ、2026年ロードマップでも進行中です。カーネルが単にRustに「乗った」のではなく、Rust側もカーネルのために動いている——この双方向の協調関係こそが、このプロジェクトの最も重要な構造変化と言えます。

開発者視点——Rustカーネル開発を始める実際

必要なもの

カーネルのRustサポートを使って開発するには、次のツールチェーンが必要です。

• rustc（新しいバージョン。v7.1系では最小1.85.0）
• Rust標準ライブラリのソース（rust-src。ビルド時にcoreをクロスコンパイルするため）
• libclang（LLVM。bindgenがCコードを解析するのに使用）
• bindgen（C側のバインディングをビルド時に自動生成）

要件が満たされているかは、次の1コマンドで確認できます。

make LLVM=1 rustavailable

これはKconfigがRustサポートの有効可否を判断するのと同じロジックで、不足している項目があれば理由を表示してくれます。

ディストリビューション対応状況

カーネルドキュメントのQuick Startガイドによれば、主要ディストリビューションの多くは「そのまま動く」状態です。

• Arch Linux、Debian 13（Trixie）/Testing/Sid、Fedora、Gentoo、Nix、openSUSE Slowroll/Tumbleweed、Ubuntu 26.04 LTS
• Ubuntu 24.04 LTS以前は、バージョン付きパッケージ（rustc-1.85等）を明示的に指定する必要あり
• さらにkernel.orgが、軽量なプリビルドLLVM+Rustツールチェーンを配布しており、rustupの代わりに使える

Cとの共存を支えるbindgen

Rustカーネル開発の核心は、bindgenがビルド時にCヘッダからRustバインディングを自動生成する点にあります。Cで書かれた既存のカーネルAPIを、Rust側から型安全に呼び出せるのです。新規ドライバをRustで書いても、レジスタ操作の定義や既存サブシステムとの連携はC側の資産をそのまま利用できます。

これからドライバ開発を学ぶ人にとっては、「Cのカーネル開発知識が無駄にならず、その上にRustの安全性を重ねられる」というのが大きな魅力です。実際、Rust for Linuxプロジェクトはアウトオブツリー用のモジュールテンプレートを公開しており、小さなモジュールから試すこともできます。

よくある質問（FAQ）

Q: 既存のCドライバはRustに書き換えられるのか？

書き換えは可能ですが、現時点では「新規ドライバをRustで書く」のが基本方針です。既存の膨大なCコードを一括書き換える計画はなく、Rust抽象化層の整備が進む分野から段階的に採用が広がっています。あなたの担当ドライバが書き換えられるかは、そのドライバが依存するサブシステムのRust抽象化層の整備状況次第です。

Q: Rustの学習コストは高いのか？ カーネル開発に必要なものは？

所有権や借用の概念に慣れるまでの学習コストは確かにあります。ただしカーネル開発では、unsafeコードの取り扱いなどカーネル固有のルールも学ぶ必要があるため、Cカーネル開発の知識がある人にとっては「Rustの追加学習」という位置づけになります。公式ドキュメントのQuick Startガイドとアウトオブツリー用テンプレートから始めるのが最短ルートです。

Q: どのカーネルバージョンからRustが使えるのか？

Rustサポートの初マージはLinux 6.1（2022年）です。v6.11以降は最小Rustバージョンが明示され、2026年時点の最新カーネル（v7.1以降）ではRust 1.85.0が最小要件です。Stable/LTSカーネルでは要件が異なる場合があります（例: Linux 6.18.yは最小1.78.0）。

Q: 安定版（stable）のRustだけでビルドできるのか？

現時点では、カーネルのRustコードは一部の不安定（unstable）機能に依存しており、安定版機能だけでのビルドは保証されていません。ただし「stable Rustでビルド可能にする」ことはRustプロジェクトのフラグシップゴールとして継続中で、Rustコンパイラ側のpre-merge CIでカーネルのビルドテストが行われるなど、安定性の向上は着実に進んでいます。実際のところ、これまでの新しいRustバージョンでは動作してきています。

まとめ——静かながら不可逆な変化

LinuxカーネルのRust対応を振り返ると、その歩みは派手な発表よりも「静かな積み重ね」だったことが分かります。

1. 実採用は現実のものに：Android Binder、Nova GPU（NVIDIA）、Tyr GPU、DRM Panic QRなど、メインラインで実際に動くRustコードがGPU・ネットワーク・IPCなど主要分野に出揃いつつある
2. バージョン問題に構造的な解：Debian Stable追従というポリシーと、Rustコンパイラ側のpre-merge CIによるカーネルビルドテストという双方向の協調で、不安定機能依存という根本課題への対処が進んでいる
3. 開発の敷居は下がった：主要ディストリビューションのツールチェーンでそのまま開発でき、make LLVM=1 rustavailable一発で環境を確認できる

今後の注目ポイントは3つです。第一に、stable Rustのみでのビルド実現（Rustプロジェクトの2026年ロードマップで進行中）。第二に、Linux Plumbers Conference 2026のRust Microconferenceで示される次の方向性。第三に、NVIDIA Novaドライバのような大型ドライバの実用化がどこまで進むかです。

カーネルという世界で最も保守的なコミュニティの一つが、10年単位の視野で言語の転換を進めている。この変化は派手ではないけれど、おそらく不可逆です。ドライバ開発や組込み開発に携わるなら、今のうちにRustに触れておくことが、5年後の選択肢を広げるでしょう。

参考文献

• Rust for Linux プロジェクト
• Rust version policy
• カーネルドキュメント Rust Quick Start
• カーネルのRustドキュメント
• Rust プロジェクトゴール: Rust for Linux ロードマップ
• LWN.net Rust index
• Kangrejos カンファレンス

関連記事

• eBPFが変えるLinuxカーネルの常識——雲の上のコンテナ基盤を支える「プログラマブルカーネル」入門