Proxmox VE GPUパススルー完全ガイド｜仮想マシンでGPU性能を活用

GPU パススルーの基礎知識と Proxmox VE における重要性

Proxmox Virtual Environment（以下、Proxmox VE）は、軽量なオープンソースのハイパーバイザーとして、サーバー環境からデスクトップ仮想化まで幅広く利用されています。2026 年現在、単なるサーバー用 OS としての役割を超え、家庭内メディアサーバーや開発環境、そして高性能なゲーミング VM として機能するケースが急増しています。特に GPU パススルー技術の成熟により、仮想マシン（VM）内でネイティブに近いグラフィックス性能を得ることが可能になり、用途は大きく広がりました。しかし、この設定は初心者にとってハードルが高く、失敗するとシステム起動や再起動時にエラーが発生しやすいため、慎重な手順が必要です。

GPU パススルーとは、物理的な GPU を仮想マシンに直接割り当てる技術です。従来の CPU エミュレーションによるグラフィックス処理と異なり、ホスト OS からゲスト OS がデバイスに直接アクセスできるため、ほぼネイティブ性能を発揮します。これにより、3D ゲームのプレイや AI 推論モデルの実行、高負荷な動画編集など、GPU パワーを必要とするタスクを隔離された環境で安全に行うことが可能になります。例えば、メイン OS でサーバー運用を行いながら、別 VM で Windows を起動してゲームを楽しむといったハイブリッド利用が実現します。

本ガイドでは、2026 年時点の最新情報を反映させつつ、Proxmox VE での GPU パススルー設定を網羅的に解説します。Intel VT-d や AMD-Vi に対応した CPU の確認から、BIOS 設定、GRUB パラメータの変更、VFIO モジュールの有効化、そしてトラブルシューティングまでをステップバイステップで説明します。特に Windows VM を構築する場合のドライバー問題や、NVIDIA GPU 特有の Code 43 エラー対策など、実務で遭遇する課題に焦点を当てています。正しい設定により、安全かつ高性能なマルチ用途サーバー環境を構築できることを目指します。

ハードウェアと BIOS の前提条件確認

GPU パススルーを成功させるためには、まずハードウェアレベルでの対応状況を確認することが最優先です。現代の CPU には仮想化関連機能として Intel VT-d（Intel Virtualization Technology for Directed I/O）や AMD-Vi（AMD Virtualization for I/O Devices）が標準搭載されています。これらは直接入出力デバイスへの割り当てを管理する技術であり、これが無効な状態では GPU パススルーは不可能です。2026 年時点の主流 CPU である Intel Core 12/13/14 シリーズや Xeon スキャラプロセッサ、AMD Ryzen 7000/9000 シリーズおよび EPYC 7000/8000 シリーズでは標準で対応していますが、BIOS/UEFI ファームウェア上で正しく有効化されている必要があります。

BIOS/UEFI 設定においては、「IOMMU」または「VT-d / AMD-Vi」という項目を探し出し、「Enabled（有効）」に切り替える作業が必要です。メーカーによっては名称が異なり、ASUS マザーボードでは「Advanced Mode」→「Ai Tweaker」内の IOMMU セクションや、「CPU Configuration」内にある場合があります。Gigabyte や MSI の場合も同様に BIOS 設定メニューの「Chipset Configuration」や「Integrated Peripherals」内に存在することが多いです。また、重要なのは「VT-d」の他に「I/O MMU Protection」や「ACS Override」といった項目の有無です。特に ACS（Access Control Services）オーバーライドは、複数の PCIe デバイスが同じ IOMMU グループに属している場合に、強制的に分離を行うための機能ですが、これは設定次第で安定性を損なう可能性があるため、まずは標準機能での動作確認が推奨されます。

BIOS 設定を確認する際、CPU のステルス機能や電源管理機能が GPU に干渉しないよう注意が必要です。Intel の場合は「SpeedStep」、「C-State」などの省電力機能を VM 内では無効化するか、ホスト側で固定することで安定性を確保します。具体的には、PSE（Power State Events）や ACPI ステートが PCIe リセット時に誤動作するケースがあるため、BIOS で電源管理を制限し、PCIe Power Management を「Off」または「No LPM」と設定することをお勧めします。以下に代表的なマザーボードメーカーの BIOS 設定場所と推奨値をまとめます。

また、マザーボードの BIOS バージョンも重要です。古いバージョンでは IOMMU グループの分離が不十分で、GPU を VM に割り当ててもホスト側から検知され続けるためエラーが発生します。2026 年現在でも利用可能なマザーボードについては、必ず最新の安定版 BIOS（非 Beta）に更新しておくことを強く推奨します。特に GPU の PCIe スロットと CPU が直結しているか、チップセット経由で接続されているかによっても IOMMU グループ構成が異なるため、BIOS メニュー内の「PCIe Switch」や「Lane Configuration」を確認し、GPU が独立したルートを確保していることを確認しましょう。

Proxmox ホスト OS 側の基本設定（GRUB/Systemd-boot）

ハードウェア準備が整った後、次はホスト OS のカーネルパラメータを設定して IOMMU を有効化する必要があります。Proxmox VE は Debian ベースの Linux ディストリビューションを使用しており、起動時に GRUB（または systemd-boot）によってカーネル引数が読み込まれます。ここでの設定が間違っていると、後続の VFIO モジュールロードやデバイス検出に致命的な影響を与えます。Intel CPU を使用する場合、GRUB 設定には intel_iommu=on と iommu=pt の追加が必要です。AMD CPU の場合は amd_iommu=on が必須となります。

具体的には、ホスト OS で SSH またはコンソールから nano /etc/default/grub を実行し、GRUB_CMDLINE_LINUX_DEFAULT 行にパラメータを追加します。例えば、Intel CPU の場合： GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt" AMD CPU の場合： GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

ここで重要なパラメータ「iommu=pt」は、IOMMU をパッシブモード（Passthrough mode）に設定するためのものです。これにより、VM 内で使わないデバイスのメモリアクセスを IOMMU が遮断し、セキュリティと安定性を向上させます。ただし、この設定を行う前に、必ず dmesg | grep -i iommu コマンドを実行し、システム起動時に IOMMU サブシステムが正常に初期化されているか確認してください。ログに「Intel VT-d: Enabled」といったメッセージが表示されれば準備は OK です。

設定変更後には update-grub を実行して GRUB を更新し、再起動する必要があります。また、Proxmox VE のバージョンによっては systemd-boot がデフォルトになっている場合があり、その場合は /etc/systemd/boot/loader/entries/proxmox.conf などのファイルへパラメータを追加する必要があります。2026 年時点では PVE 8.x シリーズの多くで systemd-boot が採用される傾向にありますが、GRUB を使用しているホストの方が設定の自由度が高いため、多くのユーザーが GRUB を維持しています。また、GPU の ROM ダンプや特定の PCI デバイスIDを指定する必要がある場合のために、vfio-pci.ids= パラメータを使うことも可能ですが、通常は自動検出で十分です。

GPU の VFIO モジュールバインドとブラックリスト化

IOMMU が有効になった状態では、GPU に装着されたホスト OS 側のドライバー（NVIDIA や AMD のコアドライバー）がデバイスにロックをかけ続けており、VFIO（Virtual Function I/O）による仮想マシンへの割り当てができなくなります。このため、VFIO モジュールをロードする前に、既存の GPU ドライバーを解除し、VFIO に手渡す必要があります。これは「ブラックリスト化」と「モジュールバインド」の 2 段階のプロセスで行います。

まず、/etc/modprobe.d/vfio.conf という設定ファイルを作成し、ホスト OS で使用しないドライバー（例：nouveau, nvidia）を VFIO に強制するよう指示を出します。具体的には blacklist nouveau や blacklist nvidia を記述した後、その下に options vfio-pci ids=0000:01:00.0,0000:01:00.1 という行を追加して該当 GPU の PCI ID を指定します。ここで重要なのは、GPU はビデオ出力機能（01:00）とオーディオ機能（01:00.1 のように連続する ID）の両方が PCIe デバイスとして認識されるため、両方の ID を指定しなくてはいけない点です。

設定ファイルの作成後、update-initramfs -u を実行して initramfs を再構築し、再起動が必要です。これにより、システム起動時に VFIO モジュールが優先され、GPU がホスト OS から解放されます。ここで注意すべきは、NVIDIA の場合、プロプライエタリドライバー（nvidia）をブラックリストにした後に、ホスト側で X Server を立ち上げると画面がクラッシュする可能性がある点です。そのため、VM 起動中は必ず仮想コンソールや SSH で操作を行うか、別の GPU をホスト用として用意しておく必要があります。

また、AMD GPU の場合、amdgpu ドライバーも同様にブラックリスト化する必要があるケースがあります。ただし、2026 年時点では AMD 側のドライバーが VFIO との親和性が高いため、NVIDIA に比べてトラブルが少ないのが特徴です。特に、GPU が PCIe スロットに物理的に挿入されている状態であれば、ホスト OS から検知されないようにするためには、VFIO モジュールのロードタイミングを早めるために modprobe コマンドを手動で実行するか、設定ファイル内で明示的な依存関係の記述を行うことが推奨されます。

Windows VM の作成と PCI デバイス割り当て手順

設定が整った後、実際の仮想マシンを作成します。Proxmox VE 管理画面で「Create VM」をクリックし、Windows 用のテンプレートを選択するか、ディスクイメージをアップロードして新規作成を行います。この段階での重要な設定は「Machine Type」と「BIOS/UEFI Type」です。GPU パススルーを行う場合、Machine Type は必ず q35 を選択してください。i440fx では PCIe スロットの割り当てが制限されるため、パススルーデバイスが認識されない可能性があります。また、BIOS 設定は UEFI 対応のものを選択し、OVMF (UEFI) または SeaBIOS のどちらを使うか考慮します。

GPU を使用して Direct3D や Vulkan アプリケーションを起動する場合、UEFI ブート（OVMF）が必須となります。SeaBIOS は古い Legacy ブートをシミュレートするため、現代の OS 環境や GPU ドライバーとの相性が劣るからです。したがって、Windows VM の BIOS セクションでは UEFI を選択し、Pre-Enrolled Keys や Secure Boot はドライバーが正常に起動できるか確認した上で調整します。また、CPU タイプも重要で、ホストの性能を活かすために host または qemu64 ではなく、可能な限り x86-64-v2 や Haswell-noTSX など、ホスト CPU の機能に合わせた設定を行います。

PCI デバイスの追加手順は以下の通りです。「Hardware」タブから「Add」→「PCI Device」を選択し、リストから GPU を選択します。ここで表示されるデバイス名の横にある「Host Address」が正しいか確認してください。また、GPU のオーディオコントローラー（例：NVIDIA High Definition Audio）も同様に追加することで、Windows 側で音声出力が可能になります。「Graphics」タブでは、ディスプレイを None に設定し、代わりに PCI デバイスとして割り当てた GPU を使用します。もしホスト OS で GUI を利用している場合、VM の描画に CPU を使用しないよう「Display」設定を「Standard VGA」から外すか、CPU リソースを VM 用に確保するための QEMU コマンドライン引数を追加する必要があります。

作成後、VM を起動し、Windows の「デバイスマネージャー」を確認します。ここで「NVIDIA GeForce RTX 4090」や「AMD Radeon RX 7900 XTX」といった名前で正常に表示されれば設定は成功です。ただし、ドライバーが未インストールの状態では画面解像度が低く動作するため、VM 内に適切な GPU ドライバーのインストーラーをマウントしてインストールする必要があります。

Linux ゲスト OS でのドライバインストールと最適化

Windows VM と同様、Linux をゲスト OS として使用する場合も GPU パススルーは有効に機能します。しかし、Linux の場合、カーネルモジュールやデスクトップ環境の統合が異なるため、設定手順が若干異なります。Ubuntu、Debian、Fedora などのディストリビューションを使用する際、まず lspci コマンドで GPU が認識されているか確認し、その後、適切なオープンソースドライバー（AMDGPU や Nouveau）またはプロプライエタリドライバーをインストールします。

Linux VM で GPU を使用する場合、最も重要な点は「X Server」や「Wayland」の設定です。ホスト OS とは異なり、VM 内でのグラフィックス環境構築には、mesa パッケージの最新版や nvidia-driver のインストールが必須となります。特に NVIDIA の場合、ホスト側でブラックリスト化したドライバーを VM 内で再インストールする必要があるため、パッケージマネージャー（apt や dnf）を使用して最新バージョンを適用します。また、Linux カーネルも VM 内では独立した環境となるため、最新のカーネルパッチを反映させることで、VFIO との親和性を高めます。

パフォーマンス最適化のために、VM の CPU モデル設定で kvm64 を使用せず、ホスト CPU の機能を反映させた host モデルを指定します。これにより、AVX2 や AVX-512 などのベクトル命令セットが VM 内でも利用可能になり、AI 推論やレンダリング処理の速度が向上します。また、メモリ割り当てについては、GPU に VRAM を確保するためではなく、VM のリソースとして割り当てる必要があるため、十分な RAM（例：16GB〜32GB）を割り当てることを推奨します。

また、Linux VM 内では、nvidia-smi コマンドを実行して GPU の状態や温度を監視できます。これにより、ホスト側での管理が容易になります。さらに、コンテナベースの環境（Docker）を利用する場合も、Proxmox VE で VM を作成し、その中で Docker を実行することで、GPU アクセラレーション付きのコンテナ運用が可能です。

NVIDIA と AMD の違いと 2026 年時点の推奨構成

NVIDIA と AMD では GPU パススルーの実装に明らかな違いがあります。2026 年現在、両社のドライバースタックやハードウェアアーキテクチャの違いにより、AMD GPU の方が設定が容易で安定する傾向にあります。NVIDIA はプロプライエタリドライバーを厳格に管理しているため、Code 43 エラーなどのトラブルが発生しやすく、VM 内での起動確認には追加のワークアラウンドが必要な場合があります。一方、AMD はオープンソースの amdgpu ドライバーが標準で提供されており、Linux VM との親和性が極めて高いです。

NVIDIA GPU を使用する場合、特に RTX 30/40 シリーズでは BIOS ダンプや特定のパッチ適用が必要になるケースがあります。これは NVIDIA が「KMS (Kernel Mode Setting)」を強化しているため、VM 側でドライバーが正常に初期化できないことが原因です。Code 43 エラーが表示される場合の対処法としては、vbiosdump.py スクリプトを使用して GPU の VBIOS をダンプし、それを VM にマウントすることで回避する方法がありますが、これはユーザーごとの対応が必要となります。また、NVIDIA の vGPU（仮想化 GPU）機能は企業向けライセンスが必要なため、一般ユーザーが安価に利用するには物理パススルーが唯一の選択肢となります。

AMD GPU の場合、RX 5000 シリーズ以降であれば基本的に Plug-and-Play で動作します。ただし、2026 年時点では RDNA4 アーキテクチャを採用した最新モデル（例：RX 9000 シリーズ等）も登場しており、これらへの対応はカーネルバージョンに依存します。Proxmox ホストのカーネルが古い場合、新しい GPU を認識できない可能性があるため、ホスト OS のカーネル更新を定期的に実施する必要があります。

NVIDIA GPU を使用する場合は、ホスト OS の X Server が GPU を使用しないようにする「X Server Offloading」の設定を徹底することが重要です。AMD GPU の場合も同様ですが、設定が複雑になることは少ないため、初心者は AMD からの導入をお勧めします。また、2026 年時点では NPU（Neural Processing Unit）搭載の CPU やアクセラレータが増加しており、GPU パススルーと併用して AI 処理を分散させる構成も注目されていますが、まずは GPU のパススルー設定に慣れることが優先されます。

トラブルシューティング：Code 43 と ROM バグ対策

GPU パススルー設定において最も頻繁に遭遇するエラーの一つが「Code 43」です。これは Windows デバイスマネージャーでデバイスが無効化されたことを示すコードであり、NVIDIA ドライバーが仮想環境を検知して起動を拒否する場合に表示されます。2026 年時点では、一部の NVIDIA GPU（特に RTX 30/40 シリーズの一部）でもこのエラーが発生し続けており、回避策として「ROM ダンプ」や「PCI バスマスクの変更」が必要になることがあります。

Code 43 対策の第一歩は、ホスト OS で dmesg コマンドを実行して、VFIO モジュールのエラーログを確認することです。「vfio-pci: failed to bind device」などが表示されないか確認し、デバイス ID が正しく VFIO にバインドされているか再確認します。また、Windows 起動時に BIOS の「Secure Boot」を無効にすることで、ドライバーの署名検証エラーが原因で Code 43 を発生しているケースも解消されます。さらに、NVIDIA の場合、VM 用の VBIOS（ROM）をダンプし、VM にマウントする手法が確立されています。これにより、ホスト OS への干渉を防ぎつつ、GPU ドライバーが正常に初期化されるように動作します。

「ROM バグ」とは、特定の GPU モデルの BIOS フォームウェアが PCIe リセット処理時に誤動作し、VM からデバイスが切断されてしまう現象を指します。これは特に AMD の一部のモデルや、NVIDIA の旧型モデルで発生しやすい問題です。対策として、ホスト OS の GRUB パラメータに pcie_acs_override=downstream を追加して、IOMMU グループの分離を強制したり、PCIe デバイスのリセット機能を無効化する設定を行ったりします。ただし、これらはシステム安定性への影響があるため、自己責任での実施となります。

また、物理的な接続ミスもトラブルの原因になり得ます。GPU を VM に割り当てた後、ホスト OS から GPU が認識されなくなっている場合、PCIe スロットの接触不良や、BIOS 設定での PCIe 帯域幅制限が原因である可能性があります。この場合は、マザーボードのスロットを交換するか、BIOS バージョンを見直す必要があります。

NPU と次世代アクセラレータへの対応と将来展望

2026 年現在、GPU パススルーは単なるグラフィックス処理だけでなく、AI 推論や機械学習モデルの実行において不可欠な技術となっています。特に、Intel の Core Ultra シリーズや AMD の Ryzen AI セクションに搭載される NPU（Neural Processing Unit）の活用も増加しています。しかし、Proxmox VE での GPU パススルーは主に PCIe デバイスとしての GPU に焦点が当てられており、NPU は CPU 内部にあるため、同じ手法では割り当てられません。

NPU の活用には、ホスト OS から VM へ API を介してアクセスする形式や、コンテナベースの仮想化技術（Docker + OCI runtime）の利用が主流です。しかし、高性能な AI アセンブラとして GPU パススルーを使用する場合、2026 年時点では NVIDIA の H100 や RTX 5090 などの最新モデルも登場しており、これらを VM で使用する際の帯域制限や冷却問題への対策が必要です。

将来展望としては、GPU パススルーの管理機能自体が Proxmox の Web UI に統合されることで、設定がより簡素化されると予想されます。現在はコマンドライン操作が必要となる部分が多いですが、将来的には「GPU パススルー」ボタン一つで設定が完了するインターフェースが登場する可能性があります。また、仮想 GPU（vGPU）機能のオープンソース化や、クラウド事業者との連携強化も進んでおり、家庭内サーバーからデータセンターでの運用までシームレスに接続される環境が整備されつつあります。

よくある質問（FAQ）

Q1. GPU パススルーはすべてのマザーボードで可能でしょうか？

結論：できません。 IOMMU グループ分離が正しく機能する CPU と BIOS 設定が必要です。古いマザーボードや安価なモデルでは、IOMMU が無効になっているか、グループ分けが不十分なためエラーが発生します。最新の CPU を使用し、BIOS を最新に更新することが必須です。

Q2. Code 43 エラーが出た場合どうすればよいですか？

結論：VBIOS のダンプと VM へのマウントが必要になる場合があります。 特に NVIDIA RTX 30/40 シリーズで発生しやすいエラーです。ホスト OS で vbiosdump.py を使用し、GPU の VBIOS ファイルをダンプして、VM に ISO としてマウントすることで回避できるケースがあります。

Q3. AMD GPU と NVIDIA GPU のどちらがおすすめですか？

結論：初心者は AMD、上級者は NVIDIA がおすすめです。 AMD はドライバーがオープンソースで設定が簡単ですが、NVIDIA は DLSS や CUDA が必要な用途に適しています。ただし、NVIDIA では Code 43 エラー対策の知識が必要になります。

Q4. GPU を VM に割り当てた後、ホスト OS の画面は消えますか？

結論：通常は消えません。 GPU が VM にパススルーされることで、ホスト側のディスプレイ出力が止まる可能性があります。その場合は、別の GPU（例：Intel iGPU）をホスト用として残しておくか、HDMI コネクタを繋ぎっぱなしにせずに物理的に切り替える必要があります。

Q5. 複数の VM で同じ GPU を共有することは可能ですか？

結論：原則できません。 PCIe パススルーは排他アクセスが前提のため、一つの GPU を同時に複数の VM で使用することはできません。NVIDIA の vGPU（ライセンス必須）や AMD の SR-IOV 機能を使用すれば分割利用可能ですが、設定は複雑です。

Q6. プロセッサの種類（Intel/AMD）によって設定は違いますか？

結論：カーネルパラメータが異なります。 Intel CPU の場合は intel_iommu=on、AMD CPU の場合は amd_iommu=on を GRUB に追加する必要があります。これは BIOS 設定ではなく OS 側の起動パラメータとして適用されるため注意が必要です。

Q7. Windows VM でゲームをプレイするために必要な設定はありますか？

結論：OVMF (UEFI) と q35 の選択が必須です。 また、DirectX や Vulkan を使用するためには、GPU ドライバーのインストールと Secure Boot の無効化（または有効なキーの登録）が必要です。

Q8. 再起動時に GPU が認識されない場合どうすればよいですか？

結論：VFIO モジュールのバインド設定を見直します。 update-initramfs を実行してキャッシュを更新し、BIOS の PCIe リセット機能が正しく動作しているか確認してください。また、GRUB パラメータに pcie_acs_override=downstream を追加する試みも有効です。

Q9. GPU パススルーはセキュリティ面でのリスクがありますか？

結論：ホストから VM へのアクセスは制限されますが、完全な分離ではありません。 IOMMU が正しく設定されていれば、VM からホストのメモリに直接アクセスすることはできません。ただし、BIOS やファームウェアレベルの設定ミスがあるとリスクが生じるため、定期的な更新が必要です。

Q10. 2026 年時点での最新 GPU のサポート状況は？

結論：2024〜2025 年モデルは概ね対応しています。 ただし、最新の RTX 50 シリーズや AMD RX 9000 シリーズなど、発売直後はカーネルドライバーが未対応の場合があります。Proxmox ホストのカーネルを最新に保つことでサポート期間を延ばせます。

まとめ

本ガイドでは、Proxmox VE における GPU パススルーの設定方法とトラブルシューティングについて詳しく解説しました。2026 年時点では、仮想環境での高性能なグラフィックス処理が一般的になりつつあり、そのための技術的基盤も確立されています。以下の要点を心に留めておき、安全にシステムを構築してください。

• IOMMU の有効化: BIOS と GRUB パラメータで必ず IOMMU（VT-d / AMD-Vi）を有効にし、グループ分離を確認する。
• VFIO モジュールのバインド: ホスト OS 側のドライバーをブラックリスト化し、GPU を VFIO に手渡す設定を行う。
• VM の設定: Machine Type は q35、BIOS は OVMF (UEFI) を選択し、Display を「None」にする。
• トラブル対応: Code 43 エラーや ROM バグには VBIOS ダンプや GRUB パラメータの調整が有効である。
• ベンダー差: AMD GPU は設定が容易だが、NVIDIA は性能面での優位性があるため用途に合わせて選択する。

これらの手順を丁寧に実施することで、自宅サーバーから AI 推論まで、柔軟で高性能な仮想化環境を実現できます。