By Karen Thulmann on 8月 26, 2026
Windowsには現在、3種類のプリンタードライバーモデルが存在します。V3はWindows 2000で導入されたレガシーモデルで、デバイス固有のドライバーパッケージをプリントサーバーとクライアントの両方にインストールし、スプーラープロセス内で読み込まれる追加コンポーネントを含むことがあります。V4はWindows 8およびWindows Server 2012で導入されました。これも製造元提供のドライバーですが、スプーラーから分離され、アーキテクチャに依存せず、サーバーからクライアントへコピーされることはありません。IPPクラスドライバーはMicrosoftの組み込みのドライバーレスオプションで、プリンターが Internet Printing Protocol を介して自身の機能を通知し、Windowsが製造元のコードを使わずにキューを構築します。
多くのITチームが誤っているのは、V4が安全で現代的な選択だと考えている点です。MicrosoftはV3とV4を同時に非推奨にしています。この記事では各モデルの仕組み、V4が本来解決するはずだった問題をなぜ解決できなかったのか、そしてIPPへの移行が実運用にどんな影響を及ぼすのかを解説します。
V3プリンタードライバーとは？
V3プリンタードライバーは、Windows 2000で導入された従来型のプリンタードライバーモデルで、企業環境で今も最も一般的です。デバイス固有で、プリントサーバーとそのプリンターで印刷するすべてのクライアントにインストールされます。ポートモニター、印刷プロセッサ、言語モニターなどを含み、これらはスプーラープロセス内で読み込まれます。
MicrosoftがV3を廃止対象にしたい理由は、大きく分けて2つあります。
-
導入の仕組み。 Point and Printでは、V3の共有プリンターに接続するクライアントがプリントサーバーからドライバーパッケージをダウンロードしてインストールします。これは、あるマシンがネットワーク経由で別のマシンから取得したコードを実行することを意味し、まさにPrintNightmareが悪用した経路です。
- アーキテクチャの結合。 V3ドライバーは特定のプロセッサアーキテクチャ向けに作られています。プリントサーバーが32ビットと64ビット両方のクライアントにプリンターを共有する場合、それぞれのドライバーパッケージをホストする必要があります。これがプリントサーバーのドライバーストアに数百のドライバーが蓄積される理由であり、あるドライバーを削除すると半年後に何かが壊れる、という状況を招きます。
V4プリンタードライバーとは？
V4プリンタードライバーは、Windows 8およびWindows Server 2012で導入された、共有と分離を目的に設計された製造元ドライバーです。アーキテクチャ非依存のため、1つのドライバーで32ビット／64ビット両方のクライアントに対応できます。スプーラープロセスから分離されているので、ドライバーのクラッシュがスプーラー全体を落とすことはありません。拡張されたPoint and Printでは、クライアントがサーバーからドライバーをコピーする代わりに、互換性のあるインボックスクラスドライバーを使うか、Windows UpdateからV4パッケージを取得します。
V4は実際にいくつかの問題を解決しました。アーキテクチャの組み合わせ問題は整理され、ドライバーのクラッシュがスプーラーのクラッシュにつながることはなくなりました。PrintNightmareが悪用した具体的なメカニズムである、サーバーからクライアントへのドライバーコピーは、共有プリンターのフローから除外されました。
V4が解決できなかったのは、その根本的な前提です。V4ドライバーも依然としてメーカー提供のコードであり、エンドポイント上で印刷経路の一部として実行されます。設定は引き続きメーカーが作成するプリンター拡張アプリで行われます。コードの隔離は以前より強化されましたが、端末上にメーカーのコードが存在する点は変わりません。
だからこそ、Microsoftは非推奨の通知で両モデルを同列に挙げているのです。2026年1月15日以降、新しいサードパーティ製のV3 および V4プリンタードライバーは、Windows 11およびWindows Server 2025以降向けに、個別承認がない限りWindows Updateで公開されなくなります。V4は最終目的地ではなく、約12年間続いた通過点にすぎません。
IPPクラスドライバーとは？
IPPクラスドライバーはMicrosoftに組み込まれているプリンタードライバーで、メーカー製のコードを含みません。プリンターを追加すると、WindowsはInternet Printing Protocol（IPP）を使ってデバイスに問い合わせ、プリンターが対応する機能（用紙サイズ、両面印刷、カラーモード、仕上げオプションなど）を報告します。Windowsはその応答を基に組み込みドライバーで印刷キューを構築します。
プリンター自身が機能を説明するため、追加で何かをインストールして説明する必要はありません。これが基本的な考え方であり、いわゆる「ドライバーレス印刷」がこの文脈で実際に意味することです。
要件は、プリンターがIPPに正しく対応していることです。実務上は、これはMopria認証を取得していることを意味します。Mopria認証はMopria Allianceがデバイスの標準実装を検証するプログラムで、同アライアンスは24ブランド、9,000機種以上を認証しています。認証前の古い機種は、メーカーがファームウェアを出してモデルを再提出しない限り認証されません。サポート終了したハードウェアでそれが行われることはほとんどないでしょう。
MicrosoftはなぜIPPに移行するのか？
サードパーティ製ドライバー自体が脆弱性だからです。 Microsoftは、Microsoft Security Response Centerに報告されたWindowsのセキュリティ問題のうち9%がプリントスタックに起因するとしています。2021年のPrintNightmare以降、約53件のPrint Spoolerの脆弱性が公表されています。
公表されたタイムラインは次のとおりです。
既存のドライバーは引き続き動作します。メーカーは自社サイトでインストーラーを配布し続けることが可能です。終了するのは、メンテナンスチャネルとしてのWindows Updateの役割で、それにより「ドライバーが自動的に保守される」という前提がなくなります。
これに加えて、 Windows Protected Print modeはWindows 11 24H2およびWindows Server 2025で導入されました。Windows Protected Print mode（WPP）が有効化されると、サードパーティ製ドライバーは完全にブロックされ、 Mopria認定プリンター のみが動作します。MicrosoftはWPPをデフォルトにする意向を示していますが、具体的な時期は発表していません。
では、ベンダー混在のプリンター環境にとってこれは何を意味するのでしょうか？
多くのプリンター環境は単一機種でそろっていません。典型的な中規模企業では、最近のMopria認定の複合機が数台、V3ドライバーで動作する旧型ネットワークプリンターが多数、そしてラベルプリンターやプロッター、レシートプリンターなど標準では十分にカバーできない特殊デバイスが混在しています。
IPP経路は最初のグループには問題なく対応します。2番目のグループはメーカーがファームウェアを提供した場合にのみ対応します。3番目のグループには多くの場合まったく対応できません。WPPテストに関する最初の不満がZebraやDymoのハードウェアを扱うチームから上がったのは、このためです。
Cloud rendering は同じ問題に対して別の経路を取ります。プリンター側でWindowsとIPPをやり取りさせる代わりに、ezeepは6,000以上のメーカー製ドライバーを揃えたライブラリを使ってクラウド上でジョブをレンダリングし、印刷可能なデータをデバイスに届ける際には the ezeep Hubを使います。ドライバー自体は存在しますが、エンドポイントではなくクラウド上で実行されます。つまり、WPPが保護するマシン上にも、誰かがパッチを当てる必要のあるPrint server上にもドライバーは存在しません。
Mopriaのチェックで赤い列が長く並ぶようなフリートでは、それが「ハードウェア刷新の予算を組む必要があるか」か「火曜の午後の作業で片付くか」の差になります。
