NVIDIAドライバのオープンソース化はどこまで進んだか｜Arch Linuxのデフォルト切替を機に整理

Arch Linuxのデフォルト変更が注目された理由

2024年後半、Arch Linuxのパッケージリポジトリで静かな注目を集める変更が行われました。NVIDIAのGPUを利用するユーザー向けのドライバパッケージが、従来のクローズドソース版カーネルモジュールから、オープンソース版（nvidia-open）を標準として採用する方向へと移行したのです。この変更は「NVIDIAがドライバをすべてオープンにした」という誤解を招きがちですが、実際にはもう少し層を分けて考える必要があります。現場での混乱を避けるために、何が変わり、何が変わっていないのかを改めて整理しておきましょう。

「オープンソース化」の範囲――何が公開され、何が非公開か

NVIDIAがオープンソース化したのは、Linuxカーネルと直接やりとりするカーネルモジュール部分です。具体的にはnvidia.ko、nvidia-modeset.ko、nvidia-drm.ko、nvidia-uvm.koといったモジュール群のソースコードがGitHubで公開されており、ライセンスはMIT/GPLv2のデュアルライセンスとなっています。

一方、ユーザー空間で動作するコンポーネント――OpenGLライブラリ（libGL）、CUDAランタイム、Vulkan ICD、NVENC/NVDEC関連ライブラリ――はこれまでどおりプロプライエタリなバイナリのままです。GPU System Processor（GSP）のファームウェアについても公開されていません。「オープンソースドライバに切り替えた」と表現しても、NVIDIAのユーザー空間スタックをそのまま使い続けている点は変わらず、完全なオープンソース実装としては別にnouveauが存在します。現行のオープンモジュールはあくまでカーネルとユーザー空間の橋渡し部分のみを公開したという位置づけです。この区別を理解しておくと、サポート範囲や問題切り分けの際に判断軸が定まります。

2022年の発表から2026年現在までの経緯

NVIDIAがオープンソースカーネルモジュールを初めてリリースしたのは2022年5月、ドライババージョンR515のタイミングです。当初の対象は主にデータセンター向けのAmpere世代以降のGPUで、コンシューマー向けGeForceは「アルファ品質」という扱いでした。その後のリリースサイクルでTuring世代（RTX 20xx / GTX 16xx）へのサポートが段階的に拡張され、R545前後でAmpere以降については本番利用が推奨レベルに達しています。

R560前後（2024年後半）には、Turing以降のGPUに対してオープンモジュールがデフォルト推奨となり、NVIDIAの公式ドキュメントでもクローズドソース版よりオープン版を選ぶよう案内が切り替わりました。Arch Linuxはこの方針転換を受けて、ローリングリリースの特性を活かしいち早くオープンモジュールをデフォルトとして採用した形です。2026年現在、Debian・Ubuntu系の安定版ディストリビューションではまだ旧来の非公開モジュールが主流の場合もありますが、ローリング系や最新LTSリリースでは切り替えが着実に進んでいます。

対応GPU世代の見極め方

オープンカーネルモジュールが動作するかどうかは、搭載GPUの世代に依存します。GSPファームウェアに対応しているかどうかが実質的な分岐点です。

• Turing（RTX 20xx / GTX 16xx）以降：オープンモジュール対応。2024年以降のドライバで本番品質とされています。
• Ampere（RTX 30xx）以降：対応が最も成熟しており、データセンター用途でも実績があります。
• Ada Lovelace（RTX 40xx）・Blackwell（RTX 50xx）：オープンモジュールのみを公式サポートする方向で整備が進んでいます。クローズドソース版のサポートは後退しつつあります。
• Pascal（GTX 10xx）以前：GSP非対応のためオープンモジュールは使えません。クローズドソース版かnouveauが選択肢となりますが、最新ドライバではPascal以前のサポート自体が段階的に終了しています。

GPUのアーキテクチャを確認するには、次のコマンドで搭載カードのPCI IDを調べ、NVIDIAの公式サポートマトリクスと照合するのが確実です。

lspci -nn | grep -i nvidia

Arch Linuxでの現状確認と切り替え手順

現在どのモジュールが読み込まれているかは、次のコマンドで確認できます。

lsmod | grep '^nvidia'

カーネルモジュールのバージョン情報をより詳しく確認したい場合は以下が参考になります。

modinfo nvidia | grep -E '^(filename|version|description)'

Arch Linuxのextraリポジトリで提供されるパッケージは次のように整理されています。

• nvidia：クローズドソース版カーネルモジュール（デフォルトカーネル向け）
• nvidia-open：オープンソースカーネルモジュール（Turing以降対象、デフォルトカーネル向け）
• nvidia-open-dkms：非デフォルトカーネル（linux-zen、linux-lts等）向けDKMS版
• nvidia-utils：ユーザー空間コンポーネント（両者で共通）

クローズドソース版からオープン版へ切り替える場合の基本手順は以下のとおりです。事前にカーネルのバージョンと対応するパッケージが揃っていることを確認してください。

# 旧パッケージの削除とオープン版のインストール
sudo pacman -R nvidia
sudo pacman -S nvidia-open

# initramfsの再生成
sudo mkinitcpio -P

# 再起動
sudo reboot

linux-zenやlinux-ltsなどの非デフォルトカーネルを使用している場合は、nvidia-open-dkmsを選択してください。インストール後にDKMSのビルドが走るため、完了までしばらく待つ必要があります。

既知の問題と切り戻し手順

オープンモジュールへの切り替えは多くの環境で問題なく動作しますが、一部の構成では次のような事象が報告されています。

• サスペンド／レジューム時の不安定さ：ノートPC環境や、NVIDIAとIntel／AMDのiGPUが混在するハイブリッドグラフィクス構成で報告が多い傾向にあります。nvidia-powerdや電源管理の設定と組み合わせて調整が必要になる場合があります。
• Wayland環境での挙動差：GBM対応の成熟度がXorgと異なる場合があり、コンポジターのバージョンとの組み合わせによって動作が変わることがあります。
• VFIO／SR-IOV用途：仮想化用途での動作確認は必ず事前に行ってください。ワークロードの種類によっては、クローズドソース版の方が実績が多い場面があります。

問題が発生した場合、クローズドソース版へ戻す手順はオープン版導入の逆順です。グラフィクス環境が起動しない場合はttyへ切り替えるか、ライブ環境からchroot作業を行います。

sudo pacman -R nvidia-open
sudo pacman -S nvidia
sudo mkinitcpio -P
sudo reboot

GRUBメニューから旧カーネルや別のカーネルパラメータで起動できる手段を事前に確保しておくと、切り戻し作業の難易度が大きく下がります。本番稼働のデスクトップや作業機に適用する場合は、btrfsスナップショットやsnapperとの組み合わせが実務上の安全網として有効です。

2026年時点での実務上の見通し

2026年現在、RTX 40xx（Ada Lovelace）以降の新しいGPUはオープンモジュール中心で開発が進んでおり、クローズドソース版でのサポートは徐々に後退しています。新規にLinux環境を構築してNVIDIA GPUを使う場合、Turing以降の世代ではオープンモジュールを選ぶのが今後の主流になると見てよいでしょう。

ディストリビューションごとのパッケージ整備状況には引き続き差があります。Arch Linuxのようなローリングリリース系は変化への対応が早い反面、安定版を優先するサーバー用途では、所属ディストリのパッケージが実際にオープンモジュールをデフォルトとして採用するまでに時間差が生じます。どのディストリビューションを使っているかに関わらず、自分の環境のドライババージョンとGPU世代の組み合わせを把握したうえで、NVIDIAの公式リリースノートを随時参照する習慣が求められます。

カーネルモジュールのオープン化によって、コミュニティによるバグ報告や修正の貢献が現実的になりつつあります。ただし、GPU本体の動作を司るファームウェアやユーザー空間スタックがプロプライエタリである現状は変わらないため、「完全なオープンソースドライバスタック」という段階にはまだ至っていません。今回のArch Linuxのデフォルト切替は、その過渡期にある現状の一里塚として位置づけるのが適切です。運用者としては、この限界を正確に把握したうえで、現時点で最も安定した構成を選択することが重要です。