Linux カーネルモジュール管理ガイド｜lsmod/modprobeの使い方

Linux カーネルモジュール管理の基礎と重要性

2026 年 4 月時点における PC 自作環境やサーバー運用において、Linux オペレーティングシステムは不可欠な要素となっています。特に Ubuntu 24.04 LTS や Fedora 41 のような最新リリースでは、カーネルバージョンが 6.8 または 6.11 を超える次世代の機能を採用しており、ハードウェアとの親和性が極めて高くなっています。しかし、OS の内部構造にある「カーネルモジュール」と呼ばれる拡張機能の管理を適切に行うことは、システム全体の安定性とパフォーマンス維持のために不可欠です。多くのユーザーが OS 上のアプリケーションやデスクトップ環境には精通していても、その基盤を支えるカーネルレベルの制御については理解が浅いケースが多く見られます。

Linux カーネルモジュールとは、不要なタイミングではメモリから解放され、必要な時にのみ読み込まれて動作する機能ブロックです。Windows のドライバー管理と比較すると、より細粒度で柔軟に制御できる点が特徴的です。例えば、ネットワークカードやグラフィックボードのドライバー、ファイルシステムサポートなどは、基本的にはコンパイル済みのオブジェクトファイルとして /lib/modules ディレクトリ内に保存されています。これらのモジュールを動的に読み込み、書き込み、削除する管理作業は、システムのセキュリティ強化やトラブルシューティングにおいて頻繁に行われます。

本ガイドでは、PC 自作コミュニティの中高級者向けに、Linux カーネルモジュールの管理方法を包括的に解説します。具体的には、lsmod や modprobe といった基本コマンドの深い使い方、パラメータの指定方法、ブラックリストによる制御、そして DKMS（Dynamic Kernel Module Support）を利用した NVIDIA 560 ドライバーのようなサードパーティ製モジュールの管理までを網羅します。2026 年現在の最新環境である Ubuntu 24.04 (Kernel 6.8+)、Fedora 41 (Kernel 6.11+)、Arch Linux のローリングリリース環境を想定し、実際のコマンドライン操作に基づいた実践的な知見を提供します。

カーネルモジュールの設計思想とアーキテクチャ

Linux カーネルの設計には、大きく分けて「モノリシックカーネル」と「マイクロカーネル」の二つのアプローチがあります。現在主流となっている Linux はモノリシックカーネルに分類されますが、その内部ではモジュールシステムによって拡張性を担保しています。これは、OS のコア機能（ファイルシステム、プロセス管理、メモリ管理など）を常時メモリに保持する一方で、周辺機器や特殊な機能を必要な時にのみロードする仕組みです。2026 年時点のカーネル 6.11 系以降では、このモジュールシステムのオーバーヘッドがさらに低減されており、読み込みと書き込みの速度はミリ秒単位で動作します。

モノリシックカーネルにおいてモジュールが果たす役割は非常に重要です。例えば、NVIDIA の GPU ドライバーである nvidia.ko は、ユーザー空間から直接アクセスできませんが、カーネルモジュールとしてロードされることで、GPU と OS の間の通信チャネルを確立します。もし全ての機能をモノリシックにコンパイルすると、OS のサイズは膨大になり、メモリ効率が悪化します。また、あるハードウェア用のドライバーが含まれていないためにシステムが起動しないというリスクも生じます。モジュール構造こそが、多様な PC 構成に対して柔軟に対応する基盤となっています。

ユーザー空間とカーネル空間の境界線においても、モジュール管理は重要な意味を持ちます。Linux のセキュリティモデルでは、特権レベルの高いカーネル空間にアクセスするためのインターフェースを厳格に制御しています。insmod や rmmod といったコマンドを実行する際にも、root ユーザー（UID 0）の権限が必要です。これは、悪意のあるモジュールがシステムカーネルを改変し、バックドアを開けるリスクを防ぐためです。また、Secure Boot が有効な環境では、デジタル署名されていないモジュールはロードされません。この仕組みを理解していないと、最新の Ubuntu 24.04 や Fedora 41 のアップデート後にシステム起動エラーが発生する可能性があります。

このように、Linux のモジュール管理は単なるドライバーの切り替えではなく、システム全体のアーキテクチャとセキュリティに直結する重要な要素です。PC 自作において高機能なハードウェアを選定した後も、その性能を最大限引き出すためには、カーネルレベルでの適切な設定が求められます。特に Linux カーネルのバージョンアップに伴い、旧来のモジュール互換性が失われるケースがあるため、この仕組みの理解は必須となります。

基本コマンド集：lsmod と modinfo の深掘り

システム上で現在ロードされているモジュールを確認する際、最も基本的かつ頻繁に使用されるのが lsmod コマンドです。Ubuntu 24.04 LTS や Fedora 41 のターミナルで実行すると、現在のカーネルスペースにおけるモジュールのリストが表示されます。出力結果は主に三つの列で構成されており、左から順に「Module」（モジュール名）、「Size」（サイズ）、そして「Used by」（使用している他のモジュールまたはプロセス）となっています。例えば、lsmod | grep nvidia と実行することで、NVIDIA ドライバーが現在ロードされているかどうかを即座に確認できます。

出力されるサイズはバイト単位で表示され、モジュール本体のメモリ消費量を示します。2026 年現在の NVIDIA 560 ドライバーのような大型グラフィックドライバーでは数百 KB から数 MB の領域を使用しますが、小さなネットワークコントローラー用モジュールであれば数 KB で済みます。「Used by」カラムは、そのモジュールが他のモジュールから参照されているかどうかを示し、依存関係の確認に役立ちます。もしここで 0 が表示されていれば、そのモジュールを安全に削除できる可能性がありますが、依存するモジュールがある場合はエラーが発生するため注意が必要です。

もう一つの重要なコマンドが modinfo です。これは特定のモジュールファイルに関するメタデータを取得するためのツールです。modinfo nvidia と実行すると、ライセンス情報（License）、バージョン（Version）、作者（Author）、およびパラメータのリスト（Parm）などが表示されます。特に重要なのが vermagic フィールドであり、これはカーネルのバージョンと設定オプションが一致しているかどうかを示すチェックサムです。もしモジュールをコンパイルした環境と現在の OS のカーネルバージョンが異なると、この値が不一致となり、ロード時にエラーが発生します。

modinfo の出力には depends フィールドも含まれており、このモジュールを読み込むために他のどのモジュールが必要かを明記しています。例えば i915.ko（Intel グラフィックスドライバー）は drm.ko や ttm.ko などの依存関係を持つことが一般的です。また、alias フィールドには、システムがハードウェアを検出した際に自動で読み込むべきモジュール名が登録されています。これらの情報を正しく解釈できることは、トラブルシューティング時に「なぜドライバーがロードされないのか」を特定する鍵となります。

モジュールの読み込みと削除：insmod, rmmod, depmod

insmod コマンドは、指定されたファイルパスにあるモジュールを直接カーネルにロードするための低レベルなツールです。ただし、現代の Linux 運用では推奨されません。その理由は、insmod が依存関係の解決を行わないためです。もし nvidia.ko を手動で読み込もうとした場合、前提となる kvm.ko や他のサブシステムモジュールがロードされていないとエラーになります。また、依存するモジュールがある場合は、それらを先に読み込む処理もユーザーが行う必要があります。

対照的に rmmod コマンドは、現在カーネルにロードされているモジュールを削除します。しかし、このコマンドにも制約があります。もしそのモジュールが他のプロセスやモジュールによって使用されている場合（「module is in use」エラー）、強制的に停止することはできず、システムクラッシュの原因となるため禁止されています。したがって、rmmod を実行する前には必ず lsmod で依存関係を確認し、必要に応じて関連プロセスを停止させる手順が必要です。

より高度な管理を行うのが depmod コマンドです。これはモジュールの依存関係を再構築・解析するためのツールであり、通常はシステム起動時やカーネルアップデート時に自動で実行されますが、手動で /lib/modules/$(uname -r)/modules.dep ファイルを更新したい場合に使用します。例えば、新しいモジュールを直接コピーした後に depmod -a を実行することで、システム全体にその依存関係の情報を反映させることができます。

Ubuntu 24.04 の場合、ディストリビューション固有の管理ツールが modprobe に統合されています。insmod や rmmod はあくまで開発者向けの低レベル機能であり、一般ユーザーやシステム管理者は modprobe を使用すべきです。ただし、カーネル 6.11+ の Fedora 41 では、モジュール署名検証の厳格化に伴い、insmod で署名なしのモジュールを読み込もうとすると拒否される設定がデフォルトであるケースが増えています。

依存関係の解決と modprobe の高度な利用法

Linux カーネルモジュール管理の核心は modprobe コマンドにあります。このコマンドは、単にファイルを読み込むだけでなく、依存関係グラフを解析し、必要なすべての親モ子を自動的にロードします。例えば、無線 LAN カード（iwlwifi）のドライバーを使用する際、その前にベースとなる PCI ドライバーやネットワークサブシステムがロードされていないと動作しません。modprobe iwlwifi と実行すれば、必要に応じて関連する cfg80211 や mac80211 などのモジュールも一緒に読み込まれます。

modprobe の設定ファイルは /etc/modprobe.d/ ディレクトリ内に配置されます。このディレクトリ内の .conf ファイルが、システム起動時に自動的に評価されるルール定義です。例えば、特定の無線 LAN モジュールの動作を調整したい場合、/etc/modprobe.d/wifi.conf を作成し、そこに options iwlwifi 11n_disable=8 のようなパラメータ記述を行うことができます。この設定は /lib/modules/.../modules.dep と同じく依存関係解析に組み込まれて処理されます。

さらに、モジュールのロード順序を強制的に変更する機能も提供されています。install <module_name> ディレクティブを使用することで、特定のモジュールがロードされる際に別のコマンドを実行させることができます。これは、カーネルの初期化時にネットワークインターフェースの名前を固定したい場合や、セキュリティのために特定のドライバーを遅延ロードさせたい場合に有用です。

2026 年時点の Arch Linux では、カーネルバージョンが頻繁に更新されるため、modprobe のキャッシュ管理も重要です。/lib/modules/$(uname -r)/modules.dep.bin ファイルはバイナリ形式で高速化されていますが、手動でモジュールを追加・削除した場合は depmod -a で再構築を怠らないことが不可欠です。また、Fedora 41 では dnf install kmod パッケージを通じてモジュール管理ツールが強化されており、パッケージマネージャーと連携して依存関係を解決する仕組みが標準化されています。

モジュールパラメータの設定方法：/etc/modprobe.d/

カーネルモジュールの動作を調整するために使用するのがパラメータ設定です。これはコンパイル時のハードコーディングではなく、実行時に動的に変更可能なオプションです。modinfo で確認できる Parm フィールドには、各ドライバーが受け付けるパラメータ名と説明が記載されています。例えば、Intel の i915 グラフィックスドライバーでは enable_dc=1 などの電源管理設定や、NVIDIA ドライバーでは NVreg_EnablePCIeGen2=1 といったパフォーマンス調整オプションが存在します。

これらのパラメータを設定するには、 /etc/modprobe.d/ ディレクトリ内に専用の設定ファイルを作成します。命名規則は任意ですが、通常 nvidia.conf や custom-modules.conf のような形式で管理されます。ファイル内には options <モジュール名> <パラメータ名>=<値> という形式で記述します。この設定はカーネル起動時に読み込まれるため、システム全体で効果が発揮されます。

より高度な制御としては /sys/module/ ディレクトリを使用する方法もあります。これはランタイムでの設定変更を可能にし、再起動なしでパラメータを変更できますが、永続性は保証されません。例えば echo 1 > /sys/module/nvidia/parameters/NVreg_EnablePCIeGen2 と実行することで即座に反映されますが、これは root ユーザー権限が必要です。ただし、この方法での設定は再起動後にリセットされるため、 /etc/modprobe.d/ を使用して永続化させるのが推奨されます。

Fedora 41 では、systemd の initramfs 生成プロセスにおいて、これらのパラメータを統合してブートイメージを作成します。Ubuntu 24.04 LTS でも同様に /etc/initramfs-tools/conf.d/ を介して設定が反映されます。特にセキュアな環境では、パスワード入力や暗号化解除のタイミングでモジュールのパラメータを変更する必要が生じることがあります。この場合、パラメータを誤って設定するとシステム起動に失敗するため、テスト環境での検証が重要です。

モジュールのブラックリスト化と保守的設定

特定のモジュールの自動ロードを禁止する場合、ブラックリスト機能を使用します。これは、ハードウェアの衝突を防いだり、セキュリティ上の理由で不要なドライバーを無効化したりするために有効です。 /etc/modprobe.d/blacklist.conf ファイルに blacklist <module_name> と記述することで、そのモジュールが自動ロードされるのを防止できます。ただし、ブラックリスト設定はシステム起動時のみ有効であり、手動で insmod を実行すればロードは可能になります。

より強力な制御を行うのが install <module> /bin/false 構文です。これは、特定のモジュールをロードしようとする試行自体を拒否する仕組みです。例えば、仮想化環境においてホスト側のネットワークドライバーがゲスト側の仮想 NIC と競合する場合などに使用されます。この設定が行われると、システムはモジュールの依存関係が存在していても、そのモジュールの実体を読み込もうとしません。

ブラックリストの設定には注意が必要です。誤って重要なシステムモジュール（例：ext4, e1000, i915 など）をブラックリスト化すると、ファイルシステムの読み込みやネットワーク接続が不可能になり、システム起動に失敗します。Ubuntu 24.04 の場合、/etc/modprobe.d/blacklist.conf を編集した後には必ず update-initramfs -u を実行して初期イメージを更新する必要があります。これを怠ると再起動後に設定が反映されません。

Fedora 41 や Arch Linux では、モジュールのロード順序を制御する際にブラックリストとセットで install ディレクティブを使用することがあります。例えば、install i915 /bin/true のような設定を行うことで、依存関係がある場合でも強制的に読み込ませつつ、特定の動作を抑制できます。また、セキュリティ強化のため、特定のデバイスドライバーをシステムから分離する際にもブラックリスト化が有効な手段となります。

2026 年時点のセキュリティベストプラクティスでは、不要なモジュールをブラックリストに追加することは、攻撃対象領域（Attack Surface）を縮小する重要な施策の一つとされています。特にサーバー運用において、無線 LAN ドライバーや特定の USB コントローラーを使わない場合、それらをブラックリスト化することで、マルウェアによるドライバーの悪用リスクを低下させることができます。

DKMS によるカスタムモジュール管理の実践

DKMS（Dynamic Kernel Module Support）は、カーネルアップデート後にサードパーティ製のモジュールを自動的に再コンパイル・インストールするシステムです。PC 自作環境において最も頻繁に使用されるのが NVIDIA ドライバーや VirtualBox の拡張機能など、ソースコードからビルドされるドライバーです。Ubuntu 24.04 LTS や Fedora 41 では dkms パッケージが標準で提供されており、最新のカーネル（6.8+ / 6.11+）への対応を容易にします。

NVIDIA ドライバーの例として、バージョン 560 のモジュールを DKMS で管理する場合の手順を示します。まず dkms add -m <module_name> -v <version> コマンドでモジュールを登録し、dkms build で現在のカーネルに対してビルドを行います。その後 dkms install でインストールを完了させます。これにより、次回以降のシステム起動時に自動的にロードされる設定が保存されます。

DKMS の最大の利点は、カーネルのバージョンが変わっても自動的にモジュールを再構築することです。ユーザーは手動でソースコードを取得してビルドする必要がなく、パッケージマネージャー（apt, dnf）を通じて管理可能です。ただし、DKMS を利用するにはgccやmakeなどのビルドツールがシステムにインストールされていることが前提となります。

Secure Boot が有効な環境では、DKMS でビルドされたモジュールの署名も重要です。Ubuntu 24.04 では MOK（Machine Owner Key）管理ツールが標準装備されており、カスタムドライバーを署名してロードさせる手順が用意されています。Fedora 41 でも同様に mokutil コマンドを使用してキー登録を行えます。この処理を怠ると、NVIDIA ドライバーのような重要なモジュールがロードされず、ディスプレイ出力が制限される可能性があります。

カーネルアップデート時の互換性とトラブル対応

Linux のカーネルは頻繁に更新されますが、そのたびにサードパーティ製のモジュールとの互換性が失われるリスクがあります。特に Ubuntu 24.04 から最新の HWE カーネルへ移行する際や、Fedora 41 の次期リリースへのアップグレード時には注意が必要です。uname -r コマンドで現在のカーネルバージョンを確認し、DKMS が対応しているかを確認することが重要です。

トラブルの代表例が「Module version mismatch」エラーです。これは、モジュールがビルドされたカーネルバージョンと、現在ロードされているカーネルバージョンが一致していない場合に発生します。この場合、modprobe はモジュールをロードしようとせず、システム起動時にドライバーが初期化されません。解決策は DKMS を使用して再ビルドするか、またはカーネルアップデート後に手動で dkms autoinstall を実行することです。

また、Secure Boot による署名検証もトラブルの要因となります。カーネル更新後、以前に MOK キーで署名されたモジュールが有効な状態にあるか確認が必要です。システム起動時に「MOK management」画面が表示されれば、キーを登録する必要があります。これが失敗すると、NVIDIA ドライバーなどのカスタムドライバーはロードされず、GPU アクセラレーションが使えない状態になります。

トラブルシューティングには dmesg コマンドが不可欠です。カーネルメッセージログを確認することで、モジュールの読み込み失敗の詳細な理由（例えば権限エラーや署名エラー）を特定できます。また、journalctl -k を使用して systemd のシステムログからカーネルレベルのエラーもフィルタリングして確認可能です。

トラブルシューティングとデバッグ手法

Linux カーネルモジュールの管理において、問題が発生した際の対処法を知っておくことは極めて重要です。特に modprobe がエラーを返す場合や、システム起動時にドライバーがロードされない場合は、ログの解析から始めるのが定石です。2026 年時点の Linux 環境では、journalctl と dmesg の連携が標準的に行われています。

まず dmesg | grep -i error を実行し、カーネルレベルでのエラーメッセージを抽出します。ここで「unknown symbol」という表示が出た場合、モジュールの依存関係が不足しているか、またはコンパイル時の設定が異なっている可能性があります。逆に、「permission denied」や「signature verification failed」の場合は、Secure Boot の設定や権限の問題を疑います。

さらに、modinfo -a <module_name> により、システムにインストールされているすべてのモジュールバージョンを確認することも有効です。複数バージョンのモジュールが存在する場合、デフォルトでロードされるものが古いまたは不適切な場合があるため、ls -l /lib/modules/$(uname -r)/kernel/drivers ディレクトリの内容を精査することが推奨されます。

また、lsmod | grep <module> で確認した「Used by」フィールドがゼロでない場合、そのモジュールがプロセスにロックされている可能性があります。この時は fuser -v <dev_name> 等で、どのプロセスがデバイスを使用しているかを特定し、必要に応じてプロセスを停止させる必要があります。

よくある質問（FAQ）

1. なぜ insmod よりも modprobe を使用すべきですか？ insmod はモジュールの依存関係を確認せず、直接読み込もうとするため、必要な前提モジュールがロードされていない場合にエラーが発生します。一方 modprobe は依存関係を自動的に解決し、必要なモジュールを先にロードするため、システム全体の安定性を保つために推奨されます。

2. カーネルアップデート後に NVIDIA ドライバーが動かない場合どうすればいいですか？ DKMS を使用してドライバーを再インストールする必要があります。Ubuntu の場合は sudo ubuntu-drivers autoinstall または dkms install nvidia/560.x、Fedora では rpmfusion-repos と akmod-nvidia を利用し、カーネル更新後のビルドを自動実行させる設定を確認してください。

3. モジュールをブラックリスト化しても安全に削除できますか？ はい。blacklist.conf に記述することで起動時の自動ロードを防止できますが、手動で insmod を実行すればロード可能です。完全に無効化するには install <module> /bin/false を使用してください。

4. modinfo で vermagic が不一致と表示されるのはなぜですか？ これはモジュールをコンパイルしたカーネルバージョンと、現在稼働しているカーネルバージョンが異なることを示しています。DKMS で再ビルドするか、ソースコードから正しい環境でコンパイルし直す必要があります。

5. Secure Boot を有効にしてもカスタムドライバーを使えますか？ はい。MOK（Machine Owner Key）ツールを使用して、自身のキーでモジュールに署名する手順が必要です。Ubuntu や Fedora では mokutil コマンドを使用して登録を行います。

6. ** /etc/modprobe.d/ の設定は即座に反映されますか？** いいえ。このディレクトリ内の設定ファイルはカーネル起動時や modprobe 実行時に参照されるため、手動でモジュールをロードしている場合は再起動するか modprobe -r <module> && modprobe <module> を実行する必要があります。

7. DKMS のビルドログはどこにありますか？ /var/lib/dkms/<パッケージ名>/<バージョン>/build/ ディレクトリ内に make.log が保存されています。ここでエラー内容を確認することで、ビルド失敗の原因を特定できます。

8. モジュールのサイズ (lsmod) はどうやって確認しますか？ lsmod の出力結果の二列目がバイト単位でのメモリ使用量です。ただし、この値はカーネル内部で動的に割り当てられるため、正確な実体ファイルサイズとは異なる場合があります。

9. Arch Linux では DKMS を使いますか？ はい。Arch Linux でも dkms パッケージをインストールし、AUR（Arch User Repository）にあるカスタムドライバーパッケージを利用して管理することができます。

10. モジュールのロード順序を変更する方法はありますか？ /etc/modprobe.d/ 内の設定ファイルで install <module> /sbin/modprobe <dependency> のような記述を行うことで、依存関係の解決ロジックをカスタマイズできますが、基本的にはシステムが自動判断します。

まとめ

本記事では、Linux カーネルモジュール管理の基礎から応用まで、2026 年 4 月時点の最新環境（Ubuntu 24.04, Fedora 41）に基づいて詳細に解説しました。PC 自作やサーバー運用において、カーネルレベルでの制御能力を高めることは、システムの安定性向上とパフォーマンス最適化に直結します。

要点を以下にまとめます。

• モジュールの概念: Linux カーネルはモノリシックながらモジュールシステムで拡張性を担保しており、ハードウェアごとのドライバーが動的にロードされます。
• 基本コマンド: lsmod で状態確認、modinfo で詳細取得、insmod/rmmod で低レベル操作、depmod で依存関係再構築を行います。
• モジュール管理: modprobe は依存関係を自動的に解決するため、基本的な読み込み・削除にはこれを使用します。
• パラメータ設定: /etc/modprobe.d/ ディレクトリ内の .conf ファイルで動作を調整し、永続化できます。
• ブラックリスト: 不要なドライバーの自動ロードを防止し、セキュリティや競合対策として有効です。
• DKMS 管理: カスタムドライバー（NVIDIA 560 など）は DKMS で管理することで、カーネル更新後の互換性を維持できます。
• トラブル対応: Secure Boot やバージョンミスマッチに注意し、dmesg と journalctl を活用したデバッグが必要です。

これらの知識を習得することで、Linux ベースの環境をより柔軟かつ堅牢に運用することが可能になります。特にカーネルアップデート後のモジュール再構築手順は、システム管理者として必ず押さえておきたいスキルです。