Linuxカーネルへのrust導入の進捗まとめ

LinuxカーネルにRustが採用されるという動きは、2022年末のLinux 6.1リリース以降、現実のものとなりました。当初は「実験的なサポート」と位置づけられていたものの、その後のカーネルリリースを重ねるごとに着実に前進しています。本記事では、Rust導入の背景から現在の進捗・課題・今後の方向性まで、運用担当者が把握しておくべき範囲でまとめます。

なぜカーネルにRustなのか――C言語との棲み分けという視点

Linuxカーネルは長年Cで書かれてきました。Cは低レベル操作と高い移植性を両立できる言語ですが、メモリ安全性の担保は開発者の規律に委ねられています。use-after-free・バッファオーバーフロー・レースコンディションといった脆弱性の多くは、いまもCコードのメモリ操作ミスに起因しています。

Rustはコンパイル時に所有権・借用・ライフタイムを検査することで、ガベージコレクタなしにメモリ安全性を静的に保証します。カーネルのような環境――ランタイムが使えず、メモリ管理を自ら行う必要がある――でも動作する数少ない言語です。Googleがカーネルドライバの新規実装にRustを採用すると2021年に表明したことも、議論を加速させました。

ただし、Rust導入はCを置き換えるものではありません。カーネルの膨大なCコードをそのまま移植する計画は存在せず、新規コンポーネント・ドライバ・抽象化レイヤーをRustで書く選択肢を増やす、という方針が一貫して維持されています。

Linux 6.1からの歩み――マージされたものの概要

2022年12月にリリースされたLinux 6.1で、Rustのビルドインフラとコアサポートが初めてメインラインにマージされました。この時点では、Rustでカーネルコードを書くための骨格（アロケータ統合・コアライブラリの最小サブセット・ドキュメント）が整備されたにとどまりますが、「実験的サポート」という段階を超えた意義は大きいと評価されています。

6.2以降は、カーネル内部のC APIをRustから安全に呼び出すための「抽象化レイヤー」が順次追加されていきます。ファイル・タスク・ネットワークソケット・クロック・IRQといった各種カーネルサブシステムへの安全なバインディングが、マージ候補として提案・議論・取り込まれるサイクルが続きます。

Linux 6.6前後からは、PHY（物理層）ドライバの抽象化がRustで実装されたものがメインラインに入り始め、「実際のドライバ」という意味での前進が確認されました。Rust Abstractions for PHY drivers（rust-for-linux における代表的な成果のひとつ）は、既存のCドライバと共存しながら動作することを示した実例として注目されています。

2025年時点で進行中の主なサブシステムと取り組み

2025年に入ると、複数のサブシステムで並行してRust化の試みが進んでいます。

GPUドライバ領域

最も注目を集めているのはGPUドライバです。Apple SiliconのGPUをターゲットにしたApple AGXドライバ（Asahi Linux由来）はRustで実装されており、メインラインへの統合を目指した作業が続いています。またNVIDIAのオープンソースドライバに関連して、Novaと呼ばれるGPUドライバをRustで開発する動きも2024年に本格化しました。GPUドライバはステートマシンが複雑で並行性の罠が生じやすく、Rustの型システムが持つ「状態のエンコード」の恩恵を受けやすい領域とされています。

ネットワークサブシステム

ネットワーク層では、ソケット・ネットワークデバイス・フィルタリングに関するRust抽象化が段階的にレビューされています。この領域はカーネル内で最もセキュリティ上の注目を集める箇所のひとつであり、Rustによるメモリ安全性の保証が直接的な価値を持ちます。ただし既存のCコードとの相互運用部分（FFIバウンダリ）の設計が難しく、議論が長期化しているケースも見られます。

rust-nextブランチの役割

カーネルのGitリポジトリにはrust-nextというブランチが存在し、次期マージウィンドウに向けたRust関連パッチが集積されています。メンテナーのMiguel Ojeda氏を中心に、各サイクルでのレビューとメインラインへの取り込みが管理されており、進捗をトラッキングする際の基準点として機能しています。

コミュニティの反応と残る技術的課題

Rust導入に対するカーネル開発者コミュニティの反応は一枚岩ではありません。Linus Torvalds自身はRust採用に対して前向きな立場を取りつつも、「品質が伴わなければマージしない」という一貫した姿勢を保っています。特定のコアサブシステムのメンテナーの中には、Rustによる変更を自分たちのツリーに受け入れることへの懸念を表明する声もあります。

技術的な課題としては、以下の点が繰り返し議論されています。

• CとRustのFFIバウンダリの安全性設計：unsafeブロックをどこに集約し、どう審査するか
• Rustコンパイラのバージョン依存：カーネルがサポートするコンパイラの最小バージョン管理
• ビルドシステムとの統合：KbuildへのRustツールチェーン統合の複雑さ
• デバッグ・プロファイリング：既存のkernelデバッグツール（kdump・ftrace等）とのRustコード統合
• レビュー負担：RustとCの両方を読めるレビュアーの不足

これらは短期間で解決できる問題ではなく、コミュニティ全体の慣熟とドキュメント整備が必要です。現場でカーネルを運用・ビルドする立場からすると、Rustツールチェーンのインストールがカーネルビルドの前提として加わる点は、CI/CDパイプラインや自動化スクリプトへの影響として意識しておく必要があります。

運用担当者が知っておくべき2026年時点の現状

2026年7月時点で、Linuxカーネルへの本番的なRustコードは着実に増えていますが、大半のディストリビューションにおいてRustで書かれたコードが直接動作に関わる場面はまだ限定的です。ディストリビューション側がRustサポート付きカーネルをデフォルトでリリースするケースは増えてきていますが、運用上の注意点として以下が挙げられます。

• ディストリビューションのカーネルビルドでRustが有効（CONFIG_RUST=y）かどうかはgrep CONFIG_RUST /boot/config-$(uname -r)で確認できます
• カスタムカーネルをビルドする環境では、Rustツールチェーン（rustup経由のインストールが一般的）が追加の依存として必要になります
• Rustで実装されたコンポーネントが含まれていても、ユーザー空間から見た挙動の差異は原則ありません。ABIは変わらず、既存ツールでのデバッグも継続できます

長期的な視点では、GPUドライバやネットワークサブシステムでの採用が進むにつれ、カーネルモジュールの開発にRustが現実的な選択肢になる局面が近づいています。これは組み込みLinuxや特定用途向けドライバを開発・維持する立場の運用者にとって、スキルセットの広がりを求められる変化でもあります。

まとめにかえて――現時点での評価軸

LinuxカーネルへのRust導入は、2022年のメインラインマージから現在にかけて、「実験」から「継続的な拡張」の段階に移行しました。C言語を一掃するような急進的な変化ではなく、新規コンポーネントから段階的に安全性を高めるという現実的なアプローチが選ばれています。

コミュニティ内の摩擦やビルドシステムへの影響といった課題は依然として存在しますが、GPUドライバやネットワーク層での具体的な成果が積み上がっていることは、この取り組みの継続性を裏付けています。カーネルの動向を追う立場では、rust-nextブランチとカーネルの変更履歴（MAINTAINERS・Documentation/rust/）を定期的に参照することが、最も確実な情報収集の手段となります。