Windowsのプリンタードライバー終了 ── 業務アプリの帳票・ラベル印刷はどう備えるか

「新しいPCに入れ替えたら、同じプリンターなのに用紙やトレイの選択肢が違う」「保存していた印刷設定が戻らない」「ラベルプリンターが一覧から消えた」。プリンタードライバーの提供終了に備えるとは、こうした変化が起きても業務を止めないようにすることです。

まず押さえたいのは、ドライバーの提供終了計画と、Windows protected print modeの有効化は別の話だという点です。計画の日付を過ぎたから既存の印刷が一斉に止まるわけではありません。一方、ドライバーの選ばれ方が変わる場面や、Windows protected print modeを有効にする場面では、アプリが依存していた設定や印刷先が失われます。¹²

本記事では、WinForms・WPFなどのWindows業務アプリを保守する開発者と、プリンターを配備する管理者に向けて、何が変わるか、何を調べるか、どこを直し、どう検証するかの順に整理します。印刷APIやPDF出力方式そのものの選び方は、前回のWindows業務アプリの印刷とPDF出力を参照してください。

前提環境はWindows 11(WPPの検証は24H2以降)、PowerShell 5.1以降(PrintManagementモジュール)、C#(.NET 6以降または.NET Framework 4.x、System.Drawing.Printing / System.Printing)です。難易度は中級です。

1. まず結論

印刷コードを一律に書き直すのではなく、先に「印刷先が残るか」を確認し、その後でドライバーに依存している箇所を直します。

判断の順序は、次の3段階です。

PrintDocumentやFixedDocumentで描画しているだけなら、基本的には改修ではなく検証の対象です。ただし、印刷先のキュー自体がWPPで消えて再登録もできない場合は、描画コードに問題がなくても印刷できません。先に別経路が必要です。

作業から始める場合は、5.1の一覧取得 → 4章・5.1の表で印刷先を判定 → 5.2〜5.5の依存確認 → 6章の経路選択 → 7章の検証と進めてください。判断に迷う点の背景を、2〜4章で説明します。

以降では、Windows protected print modeを WPP と略します。「キュー」はWindowsに登録された印刷先、「スプーラー」は印刷ジョブを受け取り、出力先へ渡す仕組みを指します。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全39件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 何が決まったのか ── 3段階のタイムライン

2.1 終わるのは供給・更新であり、既存ドライバーの一斉停止ではない

一次ソースは、Microsoft Learnの「End of servicing plan for third-party printer drivers on Windows」です。2023年9月に計画が発表され、2025年5月に日付が見直されました。執筆時点の計画は次のとおりです。¹

既存ドライバーは引き続きWindows Updateやメーカー提供のインストーラーからインストールでき、Microsoftはv3/v4ドライバーの機能を無効化する計画はないとしています。つまり、これはドライバーの供給・更新を段階的に終える計画であって、現場のPCに入っているドライバーを、その日に無効にする計画ではありません。¹

flowchart TB
    accTitle: ドライバー終了で変わるものと変わらないもの
    accDescr: プリンタードライバーの提供終了そのものではアプリの描画APIの入口と既存ドライバーは変わらず、新規導入や再検出で別のドライバーが選ばれたときに初めてドライバーが返す用紙一覧や独自機能、キュー名が置き換わり、仮想プリンターの削除を含むWindows protected print modeの有効化による変化は別の仕組みとして4章で扱う
    eos["プリンタードライバーの提供終了"]
    eos --> keep["変わらないもの"]
    eos --> cond["新規導入・再検出で別ドライバーが選ばれたとき"]
    cond --> change["置き換わるもの"]
    keep --> api["描画APIの入口"]
    keep --> drv["既存ドライバー"]
    change --> caps["用紙・トレイ・独自機能"]
    change --> qname["キュー名"]

図1: 提供終了だけでは何も変わらず、別のドライバーが選ばれたときにドライバーが提供していた情報と名前が置き換わる。仮想プリンターの削除を含むWPPの有効化による変化は別の仕組みである(4章)。

2.2 現場でドライバーが変わるのは、主に2つの場面

計画が既存ドライバーを止めなくても、次の場面ではアプリから見える環境が変わります。

Windowsは、同じデバイスに複数のドライバーパッケージが合致すると、それぞれに順位(rank)を付けて最も良いものを選びます。2026年7月1日の変更は、この選択でIPPクラスドライバーを優先するものです。IPPクラスドライバーが候補にならない機器では、メーカー製パッケージが引き続き選ばれ得ます。³¹

flowchart TB
    accTitle: 現場でドライバーが入れ替わる2つの経路
    accDescr: IPPクラスドライバーが合致する機器では、PCの入れ替え・OS再インストール・プリンター再検出のときに順位付けでIPPクラスドライバーが選ばれてドライバーが入れ替わり、Windows protected print modeを有効化したときは第三者ドライバーのプリンターが削除され、Windows Ready Printで再登録できる機種ならドライバーが入れ替わり、再登録できない機種では印刷先が消失する
    site["現場のPC"]
    site --> r1["PC入替・OS再インストール・再検出"]
    site --> r2["Windows protected print mode有効化"]
    r1 --> rank["IPPクラスドライバーが合致する機器で優先"]
    r2 --> del["第三者ドライバーのプリンターを削除"]
    rank --> swap["ドライバーが入れ替わる"]
    del --> re{"Ready Printで再登録できるか"}
    re -->|"はい"| swap
    re -->|"いいえ"| lost["印刷先が消失する"]

図2: 提供終了計画とWPPを分けて考えると、ドライバーが変わる場面と、印刷先そのものが失われる場面を切り分けられる。

ここでは、IPP対応とMopria認証を同じ条件として扱わないことも重要です。

Mopria非認証でもIPPに対応している機器では、WPPを使わなくても、順位付けの変更によってドライバーが入れ替わることがあります。逆に、ドライバー名が「Microsoft IPP Class Driver」であるだけでは、WPPで使えることまで確認したことにはなりません。¹⁴

flowchart TB
    accTitle: IPPクラスドライバーへの適合とMopria認証は別の条件
    accDescr: プリンターがIPPに対応していれば順位付けの変更でIPPクラスドライバーが選ばれてドライバーが入れ替わり得る一方、Mopria認証済みかどうかは別の条件としてWindows protected print modeで再登録できるかを決め、ネットワーク接続機ではIPPが有効で到達できること、USB接続機ではIPP over USBモードであることが要る
    printer["プリンター"]
    printer --> q1{"IPP対応か"}
    q1 -->|"はい"| rank["入れ替わり得る"]
    q1 -->|"いいえ"| keep["メーカー製のまま"]
    printer --> q2{"Mopria認証済みか"}
    q2 -->|"いいえ"| ng["WPPで再登録できない"]
    q2 -->|"はい"| q3{"USB接続か"}
    q3 -->|"いいえ"| q5{"IPPが有効で届くか"}
    q5 -->|"はい"| ok["WPPで再登録できる"]
    q5 -->|"いいえ"| ng
    q3 -->|"はい"| q4{"IPP over USBモードか"}
    q4 -->|"はい"| ok
    q4 -->|"いいえ"| ng

図3: 順位付けの影響はIPP対応で、WPPで残れるかはMopria認証に加えてIPPが有効で到達できること(USB接続ならIPP over USBモード)で決まる。

2.3 ドライバー署名には例外があるが、継続は保証されない

2026年1月15日以降も、次のいずれかに当てはまるドライバーは署名の例外申請を個別審査に載せられます。¹

• Mopria認証を取れないプリンター向け。
• Windows 10以下を対象OSの上限にしたパッケージ。
• ネイティブARM64ドライバー。

WHQL・Attestationのどちらでも提出は既定でブロックされ、正当化文書を添えた手動審査になります。条件に当てはまっても、メーカーが提出することやMicrosoftが承認することは保証されません。⁵ また、署名済みドライバーを入手できることと、WPPを有効にした環境で使えることは別です。ラベル・レシートプリンターの備えは6章で扱います。

flowchart TB
    accTitle: 2026年1月15日以降もドライバー署名が認められる条件
    accDescr: メーカーからのドライバー提出は既定でブロックされ、Mopria認証を取れないプリンター、Windows 10以下を上限にしたパッケージ、ネイティブARM64ドライバーの3条件のいずれかに当てはまるものだけが例外申請を個別審査に載せられるが、審査を経て承認される場合があるだけで署名されることは保証されない
    submit["メーカーのドライバー提出"]
    submit --> block["既定でブロック"]
    block --> c1["Mopria認証を取れない機種"]
    block --> c2["Windows 10以下が上限"]
    block --> c3["ネイティブARM64"]
    c1 --> apply["例外申請が可能"]
    c2 --> apply
    c3 --> apply
    apply --> review["個別審査"]
    review --> maybe["承認される場合がある（保証はない）"]

図4: 条件に当てはまっても審査に載せられるだけで、署名されるかどうかは保証されない。

3. 仕組み ── 従来のドライバー経路とWindows Ready Print

3.1 変わるのは描画APIの先にある印刷経路

従来のWindows印刷では、アプリがGDIやXPSの描画命令を出し、スプーラーがジョブを受け取り、プリンタードライバーがプリンターの言語(PDL)へ変換して送っていました。GDI印刷パスとXPS印刷パスは、どちらもこの構造の上にあります。⁶

flowchart TB
    accTitle: 従来のドライバー経路
    accDescr: 業務アプリのGDIまたはXPSの描画命令をSYSTEM権限のスプーラーがスプールし、第三者製のv3またはv4ドライバーが、ドライバー分離なしならスプーラー本体の中で、共有または分離ならスプーラーとは別のプロセスで独自のPDLへ変換してプリンターへ送る
    app["業務アプリ（GDI / XPS）"] --> spooler["スプーラー（SYSTEM権限）"]
    spooler --> iso{"ドライバー分離は"}
    iso -->|"なし"| inproc["スプーラー本体の中で第三者ドライバー"]
    iso -->|"共有 / 分離"| host["別プロセスで第三者ドライバー"]
    inproc --> pdl["独自PDLへ変換"]
    host --> pdl
    pdl --> printer["プリンター"]

図5: 従来の経路では、分離の有無でプロセスは変わるが、印刷スタックの中で第三者のコードがPDLへの変換を担う構造は同じである。

その後継として用意されたのがWindows Ready Printです。IPP(Internet Printing Protocol)による印刷、eSCLによるスキャン、Universal Printを束ねた呼び名で、第三者ドライバーを必要としません。Mopria認証済みプリンター向けに設計され、CPUアーキテクチャに依存しないことも利点です。⁷

Windows 10 21H2以降には、Mopria準拠のプリンターをネットワークとUSBで扱う Microsoft IPP Class Driver が同梱されています。¹ Universal Printのクラウドキューは、同梱の Universal Print Class Driver を使います。⁸

flowchart TB
    accTitle: Windows Ready Printの経路
    accDescr: 業務アプリの描画命令をスプーラーが受け、同梱のMicrosoft IPP Class DriverがクライアントでPWG RasterまたはPDFへレンダリングしてIPPでMopria認証済みプリンターへ送るか、同梱のUniversal Print Class DriverがIPP over HTTPSでUniversal Printサービスへ送り、Windows protected print modeはこのWindows Ready Printの経路だけを許す
    app["業務アプリ（GDI / XPS）"] --> spooler["スプーラー"]
    spooler --> ipp["Microsoft IPP Class Driver"]
    ipp --> render["PWG Raster / PDFへレンダリング"]
    render --> printer["Mopria認証済みプリンター（IPP）"]
    spooler --> up["Universal Print Class Driver"]
    up --> cloud["Universal Printサービス（IPP over HTTPS）"]
    wpp["Windows protected print mode"] -.->|"Ready Printの経路だけを許す"| ipp
    wpp -.-> up

図6: Windows Ready Printもスプーラーを通る。変換と送信を担うのが、第三者ドライバーから同梱のクラスドライバーへ変わる。

IPPはHTTPベースのプロトコルで、プリンターをipps://printer.example.com/ipp/printのようなURIで識別します。ドライバーレス印刷で使うPDLは、PWG RasterやPDFなどの公開標準に基づく少数の形式に限られ、最終的な文書はクライアント側でレンダリングされます。⁹ Universal Printでは、スプーラーがIPP over HTTPSでジョブをサービスへ送ります。⁸

アプリから見た入口は変わりません。 GDIやXPSで描画するアプリは同じAPIを呼びます。変わるのは、その先で用紙やトレイの一覧を返し、独自機能を提供し、PDLへ変換する仕組みです。このため、描画だけのアプリよりも、ドライバーの返す情報や独自設定に依存するアプリのほうが影響を受けます。メーカー独自機能については、Print Support App(PSA)による提供も確認します。¹⁰

3.2 複合機は、印刷・FAX・スキャンを別々に確認する

Windows Ready Printへ移せるかは、機器がその機能を搭載し、対応するプロトコルを実装していることが前提です。¹

Mopriaの印刷対応だけを見て、FAXやスキャンも移行できるとは判断しないでください。

flowchart TB
    accTitle: 複合機の各機能を別々に確認する順序
    accDescr: 使用する機能を一つずつ選び、機器への搭載、表の対応プロトコル、USB接続時のIPP over USBモードを順に確認し、印刷機能の結果をFAXやスキャンへ流用せず残りの機能も別々に確認する
    start["使用する機能を一つ選ぶ"]
    start --> feature{"機器がその機能を搭載？"}
    feature -->|"はい"| protocol{"表のプロトコルに対応？"}
    feature -->|"いいえ"| unmet["この機能の条件は未充足"]
    protocol -->|"はい"| usb{"USB接続？"}
    protocol -->|"いいえ"| unmet
    usb -->|"はい"| mode{"IPP over USBモード？"}
    usb -->|"いいえ"| checked["この機能の条件を確認済み"]
    mode -->|"はい"| checked
    mode -->|"いいえ"| unmet
    checked --> next["残りの機能を別々に確認"]
    unmet --> next

図7: 機能の搭載、対応プロトコル、接続時の追加条件の順に確認する。印刷の確認結果をFAXやスキャンへ流用しない。

3.3 背景にあるのは、印刷スタックのセキュリティ

Microsoft Learnの解説では、印刷まわりの不具合が、その解説で集計した過去3年間のMSRC(Microsoft Security Response Center)報告事例の9%を占めるとされています。スプーラーはSYSTEM権限で動き、標準ユーザーからも広く到達でき、第三者のコードをオンデマンドで読み込みます。古いドライバーにはCFGやCETなどの現代の緩和策と互換性がないものがあり、参加するコード全体の対応が必要な緩和策を適用しにくい構造です。⁹

flowchart TB
    accTitle: 第三者ドライバーを読み込む限り緩和策が効かない理由
    accDescr: SYSTEM権限のスプーラーが第三者コードを読み込み、古いドライバーがCFGやCETなどの緩和策と互換性がないため、全参加者の対応が必要な緩和策をスプーラーに適用できず、脆弱性が悪用されやすくなる
    sys["スプーラーはSYSTEM権限"]
    load["第三者コードをオンデマンドで読み込む"]
    old["古いドライバーは緩和策と非互換"]
    sys --> risk["脆弱性が悪用されやすい"]
    load --> nomit["緩和策（CFG / CET / ACG）を適用できない"]
    old --> nomit
    nomit --> risk

図8: 緩和策は全参加者が対応して初めて効くため、ドライバーを外さない限りスプーラーを守り切れない。

第三者ドライバーが動く場所は、プリンタードライバー分離の設定で変わります。¹¹

INFでDriverIsolation=2を宣言したドライバーは既定で共有プロセスを使い、宣言していないドライバーは既定でスプーラー本体の中で動きます。管理者は印刷の管理コンソールやグループポリシーで上書きできます。ただし、どのモードでも印刷スタックの中で第三者コードが動く点は変わりません。¹¹ WPPは、この第三者コードへの依存を外す動作モードです。

flowchart TB
    accTitle: 第三者ドライバーが動くプロセスの決まり方
    accDescr: INFでDriverIsolation=2を宣言したドライバーは既定でスプーラーとは別の共有プロセスで動き、宣言の無いドライバーは既定でスプーラー本体の中で動き、管理者は印刷の管理コンソールやグループポリシーで、共有・スプーラー本体の中・ドライバー専用の別プロセス（分離）のいずれかへ上書きできる
    inf{"INFでDriverIsolation=2を宣言"}
    inf -->|"はい"| shared["別の共有プロセスで動く（既定）"]
    inf -->|"いいえ"| inproc["スプーラー本体の中で動く（既定）"]
    admin["管理者の設定やポリシーで上書き"] -.-> shared
    admin -.-> inproc
    admin -.-> isolated["専用の別プロセスで動く（分離）"]

図9: 分離モードはINFの宣言と管理者の設定で決まり、宣言の無い古いドライバーは既定でスプーラー本体の中で動く。

4. Windows protected print modeで何が消えるか

4.1 WPPは「Windows Ready Printだけを使う」動作モード

WPPはWindows 11 24H2で導入されました。本記事執筆時点では既定で無効で、無効のあいだはドライバーのインストールや印刷機能に制限はありません。¹²¹³ 有効化の方法と、元に戻せる人を分けておきます。

グループポリシーで有効化した場合、利用者は管理者に連絡しないと解除できません。IntuneのOMA-URIも同じADMXベースのデバイスポリシーを適用する経路です。本人が設定画面から戻せるのは、本人が設定画面で有効化した場合と考えておきます。¹⁴²¹³

flowchart TB
    accTitle: Windows protected print modeを有効化する3つの経路
    accDescr: 設定アプリ、グループポリシー、IntuneのOMA-URIのいずれかでWindows protected print modeを有効化でき、本人が設定アプリから戻せるのは本人が設定アプリで有効化した場合だけで、グループポリシーやIntuneのポリシーで配った場合は管理者側でポリシーを変えないと解除できない
    s["設定アプリ（本人が有効化）"] --> wpp["Windows protected print mode有効"]
    g["グループポリシー"] --> wpp
    i["Intune（OMA-URI）"] --> wpp
    s -.->|"本人が設定アプリから戻せる"| off["解除"]
    g -.->|"本人では戻せない"| adm["解除は管理者側のポリシー変更"]
    i -.->|"本人では戻せない"| adm

図10: 有効化の経路は3つあり、本人が戻せるのは設定アプリから本人が有効化した場合だけである。

4.2 残るキュー、消えるキュー、再登録が必要なキュー

有効化時の影響は、プリンター本体だけでなく、今どのドライバーで登録されているかでも変わります。²

flowchart TB
    accTitle: Windows protected print mode有効化時にプリンターに起きること
    accDescr: 有効化すると第三者ドライバーで導入されたプリンターと、サポートされない仮想プリンター・XPS Document Writer・FAXの仮想プリンターは削除され、Mopria認証済みで、ネットワーク接続ならIPPが有効で到達でき、USB接続ならIPP over USBモードの機種はWindows Ready Printで再登録でき、非対応機は有効なあいだ使えない
    on["WPPを有効化"]
    on --> third["第三者ドライバーのプリンターを削除"]
    on --> soft["非対応の仮想プリンターを削除"]
    soft --> xps["XPS Document Writer・FAXも削除"]
    third --> mopria{"Mopria認証済みか"}
    mopria -->|"はい"| conn{"接続は"}
    conn -->|"ネットワーク"| ipp{"IPPが有効で到達できるか"}
    conn -->|"USB"| usb{"IPP over USBモードか"}
    ipp -->|"はい"| re["Windows Ready Printで再登録"]
    usb -->|"はい"| re
    ipp -->|"いいえ"| no["有効なあいだ使えない"]
    usb -->|"いいえ"| no
    mopria -->|"いいえ"| no

図11: メーカー製ドライバーのキューは、Mopria認証済みでも一度消える。再登録できる条件を別に確認する。

WPPが有効なあいだ、削除された第三者ドライバーは使えません。また、WPPを無効に戻しても、Windows Ready Printで入れ直したプリンターが元のドライバーへ自動的に戻るわけではありません。²¹⁰

アプリ側では、メーカー製ドライバーが返す用紙・トレイ・独自機能、ポートモニターDLL型の仮想プリンター、XPS Document Writerを前提にする処理が確認対象です。XpsDocumentなどでXPSファイルを直接生成する処理は、XPS Document Writerという仮想キューへの印刷とは別であり、この削除の対象ではありません。

4.3 管理とスプーラー内部にも変更がある

WPPでは、ポートモニターDLLなどの第三者バイナリを読み込まなくなります。AddPrintProvidorWのようなモジュール読み込みAPIも新しいモジュールを読み込めず、IPPに必要なMicrosoft署名のバイナリだけが読み込まれます。AddPrintProvidorWはwinspool.hの歴史的な綴りで、Microsoft Learnの解説ではAddPrintProviderWと表記されています。⁹

この制限によって、XPSのレンダリングはSYSTEMではなくユーザー権限で動き、新しいスプーラーワーカープロセスにはSeTcbPrivilegeなどを外した制限トークンが使われます。子プロセスの生成が禁止され、CFG・CET・ACGも有効になります。⁹

flowchart TB
    accTitle: Windows protected print modeでのスプーラーの変化
    accDescr: 第三者バイナリを読み込まなくなることで、モジュール読み込みの制限、ユーザー権限でのXPSレンダリング、制限トークンのワーカープロセス、子プロセス生成の禁止、CFG・CET・ACGの有効化が可能になる
    nodrv["第三者バイナリを読み込まない"]
    nodrv --> r["読み込みの制限"]
    nodrv --> l["権限の縮小"]
    nodrv --> m["緩和策の有効化"]
    r --> r2["Microsoft署名バイナリだけ"]
    l --> l2["ユーザー権限XPS・制限トークン"]
    m --> m2["子プロセス禁止・CFG / CET / ACG"]

図12: 図8で効かなかった緩和策は、第三者バイナリを外すことで初めて有効にできる。

Point and Printは、IPP構成は残るものの、第三者ドライバーのインストールを行わなくなります。「プリントサーバーへ接続すればドライバーが配布される」前提のキッティング手順も見直しが必要です。⁹

WPPが現在有効かどうかは、Windows 11 24H2以降のWinRT API Windows.Graphics.Printing.ProtectedPrint.WindowsProtectedPrintInfo.IsProtectedPrintEnabledで確認できます。¹⁵ グループポリシーの設定値は、HKLM\Software\Policies\Microsoft\Windows NT\Printers\WPP配下のWindowsProtectedPrintGroupPolicyStateです。¹³

なお、WPPが有効なクライアントからは、WPPが無効なプリントサーバーを印刷管理で管理できません。管理担当者には、WPPを無効にした管理用クライアントを別に用意します。¹⁴

5. 既存アプリの棚卸し ── 見るべき4か所

flowchart TB
    accTitle: 業務アプリで棚卸しする4か所
    accDescr: 業務アプリの印刷コードのうち、ドライバー固有設定の保存、キュー名依存（SDKやライブラリ内部のものを含む）、WPPでサポートされない仮想プリンターへの依存、WPPで残らないキューへのRAW送信の4か所は改修対象で、描画しているだけのコードは検証対象になる
    app["業務アプリの印刷コード"]
    app --> deps["4つの依存を棚卸し"]
    app --> d0["描画だけ"]
    deps --> d1["固有設定の保存"]
    deps --> d2["キュー名への依存"]
    deps --> d3["仮想プリンター依存"]
    deps --> d4["RAW送信"]
    d2 -.-> d2n["SDK内部も含む"]
    d3 -.-> d3n["WPP非対応のもの"]
    d4 -.-> d4n["残らないキュー向け"]
    d1 --> fix["改修する"]
    d2 --> fix
    d3 --> fix
    d4 --> fix
    d0 --> verify["検証する"]

図13: 4つの依存だけが改修対象で、描画しかしていないコードは検証に回す。

5.1 まず現場のドライバー一覧を取り、印刷先を判定する

改修の要否は、現場に何が入っているかを見てから決めます。PowerShellのPrintManagementモジュールで、キューとドライバーの一覧を取得します。Get-PrinterとGet-PrinterDriverによる一覧取得には管理者権限は不要ですが、後半のpnputilには管理者権限が必要です。¹⁶¹⁷

# キューごとに、ドライバー名・メジャーバージョン(3 = v3, 4 = v4)・提供元・INFファイル名を並べる
Get-Printer |
    Select-Object Name, DriverName, PortName,
        @{ Name = "DriverMajorVersion"; Expression = { (Get-PrinterDriver -Name $_.DriverName).MajorVersion } },
        @{ Name = "Manufacturer"; Expression = { (Get-PrinterDriver -Name $_.DriverName).Manufacturer } },
        @{ Name = "InfName"; Expression = { Split-Path -Leaf (Get-PrinterDriver -Name $_.DriverName).InfPath } } |
    Sort-Object DriverName |
    Format-Table -AutoSize

# 第三者のドライバーパッケージだけを、公開名(oemN.inf)・元のINF名・提供元とともに列挙する(管理者権限が要る)
pnputil /enum-drivers /class Printer

MajorVersionでv3とv4を見分けられます。¹⁸ ただし、v3/v4の区別と、同梱/第三者製の区別は別です。次のように分類します。

Get-PrinterDriverのInfPathはドライバーストア内のINFへのパスであり、公開名のoemN.infを返す保証はありません。pnputil /enum-driversが返す公開名・元のINF名・提供元と、InfPathのファイル名やManufacturerを突き合わせます。pnputil /enum-driversは第三者パッケージだけを列挙し、同梱パッケージは一覧に出ません。¹⁹¹⁷

flowchart TB
    accTitle: 現場のプリンター一覧を棚卸しする手順
    accDescr: PowerShellでキューとドライバーの一覧を取り、DriverNameと、Manufacturerおよびpnputilの第三者パッケージ一覧との突き合わせでIPPクラスドライバーのキュー、Universal Printのキュー（WPP互換）、それ以外の同梱ドライバーのキュー（XPS・FAXは削除、Generic / Text Onlyは残る前提にできず、Microsoft Print to PDFは削除対象に挙げられていないため個別に判定）、メーカー製ドライバーのキュー（入れ替わる候補）に分け、IPPクラスドライバーのキューはMopria認証・ネットワーク接続ならIPPが有効で到達できること・USB接続ならIPP over USBモードを別に確認したうえで、どちらのキューもアプリの設定や印刷コードが指しているキューと突き合わせて判定する
    list["Get-Printer / Get-PrinterDriverで一覧を取る"]
    list --> cls{"DriverNameと提供元は"}
    cls -->|"IPP Class"| ipp["IPPクラスドライバーのキュー"]
    cls -->|"Universal Print Class"| up["Universal Printのキュー"]
    cls -->|"その他の同梱"| inbox["残るかを4章の表で個別に判定"]
    cls -->|"メーカー製"| vendor["入れ替わる候補"]
    ipp --> mop["Mopria・IPP到達・USBを確認"]
    mop --> match["アプリの設定・コードと突き合わせる"]
    up --> match
    inbox --> match
    vendor --> match
    match --> judge["判断表で振り分ける"]

図14: 一覧を取って名前で分けるところまでは管理者権限なしで済み、提供元の突き合わせにはpnputilの管理者権限が要る。

この一覧と、アプリの設定・印刷コード・利用SDKが参照しているキューを照合します。納品先ごとに、ドライバー、Mopria認証、接続方式、IPPの到達性、USBの動作モードまで記録しておくと、4章の表で判定できます。

WPPで印刷先が残らず再登録もできない場合は、コードの棚卸しより先に、6章の別経路を用意するか、WPPを使わない判断をします。 WPPを使わなくてもIPPの順位変更を受け得る機器なら、続けて5.2以降を確認してください。WPPを使わず、ドライバー入れ替わりの影響もない場合は、現在の経路のまま運用する判断になります。

アプリ内からドライバー名を確認する場合は、WPFのSystem.PrintingでPrintQueue.QueueDriver.Nameを読めます。²⁰

using System.Printing;

// 管理ツールやデスクトップアプリから、各キューのドライバー名を列挙する
using var server = new LocalPrintServer();
foreach (PrintQueue queue in server.GetPrintQueues(
    new[] { EnumeratedPrintQueueTypes.Local, EnumeratedPrintQueueTypes.Connections }))
{
    Console.WriteLine($"{queue.Name}\t{queue.QueueDriver?.Name}\t{queue.QueuePort?.Name}");
}

ただし、System.Printing名前空間はWindowsサービス内での利用をサポートしていません。常駐サービスで印刷している場合、この診断処理は管理ツール側に置いてください。²¹ サービスからの印刷の制約は、Windowsサービスの作り方と運用と前回記事の7章を参照してください。

5.2 確認1: ドライバー固有の設定を保存・復元していないか

最も見つけにくいのが、印刷設定の保存です。保存方法によって、壊れる理由が異なります。

DEVMODEは、公開メンバーの後ろにdmDriverExtraでサイズを示す非公開データを持てます。Windowsが検証するのは公開部分だけであり、壊れた非公開データはアプリやスプーラーのプロセスでドライバーをクラッシュさせ得ます。²²

flowchart TB
    accTitle: DEVMODEの公開部分と非公開部分
    accDescr: DEVMODE構造体は公開メンバーの後ろにdmDriverExtraで示されるドライバー定義の非公開データを持ち、公開部分だけがWindowsに検証され、非公開部分はそのドライバーだけが解釈できるため、丸ごと保存するとドライバーが変わったときに意味を失う
    dm["DEVMODE構造体"]
    dm --> pub["公開部分（dmSize）"]
    dm --> priv["非公開部分（dmDriverExtra）"]
    pub --> chk["Windowsが検証する"]
    priv --> only["そのドライバーだけが解釈できる"]
    only --> lost["ドライバーが変わると意味を失う"]

図15: 丸ごと保存した設定のうち、壊れるのは非公開部分である。

SetHdevmodeで設定を受け取ったPrinterSettingsは、この非公開領域を内部にコピーします。²³ .NET Framework版のPrinterSettingsにはSerializable属性があり、バイナリシリアライズは既定でprivateフィールドも含むため、オブジェクト全体の保存にも同じ依存が潜みます。²⁴²⁵

一方、.NET版のPrinterSettingsにはSerializable属性がなく、公開プロパティを個別に独自形式で保存する実装では、ネイティブのDEVMODEバッファやdmDriverExtra領域まで保存するわけではありません。²⁴ この場合に注意するのはドライバー依存の値です。

flowchart TB
    accTitle: DEVMODEの保存とマネージド値の保存は壊れ方が違う
    accDescr: DEVMODEバッファを丸ごと保存する実装と、SetHdevmodeで非公開領域を受け取った後のPrinterSettingsを丸ごとシリアライズする実装は、非公開部分ごと持ち歩くためドライバーが変わると意味を失い、公開プロパティの値を保存する実装はCustomやメーカー固有の用紙・トレイの番号がメーカー製ドライバーの一覧に対する値のためIPPクラスドライバーで同じ意味になる保証がなく、どちらも意図だけを保存する設計へ置き換える
    a["DEVMODEを丸ごと保存"]
    a --> a1["非公開部分ごと持ち歩く"]
    s["SetHdevmode後の丸ごと保存"] --> a1
    a1 --> a2["ドライバーが変わると意味を失う"]
    b["公開プロパティの値を保存"]
    b --> b1["カスタム用紙・トレイの番号を持ち歩く"]
    b1 --> b2["新ドライバーで同じ意味の保証がない"]
    a2 --> c["どちらも意図だけの保存へ"]
    b2 --> c

図16: SetHdevmode後のオブジェクトの丸ごと保存は非公開部分の側に入り、壊れ方は違ってもどちらもドライバーの状態を持ち歩いている。

RawKindが標準のPaperKindやPaperSourceKindを表していれば、ドライバーが変わっても意味を保ちます。保証がないのは、Customやメーカー固有の番号が、別のドライバーでも同じ用紙・トレイを指すことです。標準値まで一律に壊れるものとして扱わないでください。²⁶²⁷

flowchart TB
    accTitle: 保存した用紙・トレイの値のうち壊れるもの
    accDescr: RawKindのうちA4などの標準用紙（PaperKind）やUpper・Lowerなどの標準給紙元（PaperSourceKind）に対応する値はドライバーが変わっても意味を保ち、Customやメーカー固有の値はメーカー製ドライバーの一覧に対する番号なのでIPPクラスドライバーが同じ用紙・トレイと解釈する保証がない
    raw["保存したRawKind"]
    raw --> std["標準値（PaperKind等）"]
    raw --> cus["Custom・メーカー固有の値"]
    std --> keep["ドライバーが変わっても意味を保つ"]
    cus --> lost["同じ用紙・トレイと解釈される保証がない"]

図17: 壊れるのは標準値ではなく、メーカー製ドライバーの一覧に対するカスタム値である。

PrintTicketも、公開キーワードはpsk名前空間で定義されますが、デバイス固有の私的拡張を含められます。第三者の要素は、その第三者に明確に関連付けられた名前空間に置く規定です。保存XMLにメーカーの名前空間が混ざっていれば、ドライバー固有設定として確認します。²⁸²⁹

対処: 保存するのは「意図」だけにする

用紙サイズ・向き・両面・部数・トレイの選択という意図を、自分の設定ファイルに公開キーワードで持ちます。ドライバーの内部状態を持ち越すのではなく、印刷直前に現在の能力と突き合わせます。

WPFでは、PrintQueue.GetPrintCapabilitiesで能力を取得し、要求をPrintTicketにしてMergeAndValidatePrintTicketへ渡します。³⁰ ここで注意すべきなのは、非対応の要求が、必ずエラーになるわけではないことです。ドライバーが競合を解決し、通常は既定値などへ置き換えた有効なチケットを返すことがあります。

ValidationResult.ConflictStatusがConflictResolvedなら、ValidatedPrintTicketの両面やトレイを要求と比較し、差分をログに残して利用者へ通知します。³¹

flowchart TB
    accTitle: 意図だけを保存して印刷直前に能力と突き合わせる設計
    accDescr: 設定ファイルには用紙・向き・両面・部数・トレイの意図だけを公開キーワードで持ち、印刷直前にGetPrintCapabilitiesで現在のプリンターの能力を取り、MergeAndValidatePrintTicketに通し、ConflictStatusがNoConflictならそのまま印刷し、ConflictResolvedなら置き換えられた項目を要求と突き合わせてログと通知に回す
    cfg["設定ファイル：意図だけ（用紙・向き・両面・部数）"]
    cfg --> caps["印刷直前にGetPrintCapabilities"]
    caps --> merge["MergeAndValidatePrintTicket"]
    merge --> st{"ConflictStatusは"}
    st -->|"NoConflict"| print["印刷"]
    st -->|"ConflictResolved"| tell["要求との差分をログと通知"]

図18: 設定の意図を保存し、印刷時に現在の能力で検証する。置き換わった設定は黙って使わず、差分を確認する。

WinFormsでは、PrinterSettings.PaperSizesから名前ではなくKindや寸法で用紙を選び直します。給紙元のPaperSourcesは、UpperやLowerのように一意な標準値なら再利用できますが、複数の独自トレイがまとめてPaperSourceKind.Customとして返ることがあります。しかもPaperSourceには用紙寸法がありません。独自トレイをKindだけで特定せず、現在の能力へ明示的に再マッピングするか、利用者に選び直してもらいます。²⁷

5.3 確認2: プリンター名・キュー名に依存していないか

前回記事ではプリンター名を設定ファイルに持つことを勧めました。ここで加えるのは、ドライバーの入れ替えや再検出後に、同じ名前のキューが作られる保証はないという前提です。旧キュー名を指した設定は、そのままでは印刷先を見失います。

確認する場所は、設定ファイル、コードに直書きした名前、SDK・帳票ライブラリ内部の3つです。自分のコードに固定名がなくても、メーカーSDKが内部で特定のキューやドライバーを呼ぶ場合があります。SDKのドキュメントと5.1の一覧を突き合わせてください。

flowchart TB
    accTitle: キュー名への依存が潜む3つの場所
    accDescr: キュー名への依存は設定ファイルの固定名、コードに直書きした固定名、メーカーSDKや帳票ライブラリが内部で呼ぶキュー・ドライバーの3か所に潜み、前二者はコードと設定の検索で、後者はSDKのドキュメントと5.1の一覧で確かめる
    dep["キュー名への依存"]
    dep --> cfg["設定ファイルの固定名"]
    dep --> code["コードに直書きした固定名"]
    dep --> sdk["SDK・ライブラリ内部の固定"]
    cfg --> grep["コードと設定を検索して見つける"]
    code --> grep
    sdk --> doc["SDKのドキュメントと5.1の一覧で確かめる"]

図19: 自分のコードにキュー名が無くても、SDKやライブラリの内部に依存が残っていることがある。

対処は、起動時に設定された名前がPrinterSettings.InstalledPrintersに存在するかを確認し、見つからなければログを残して利用者に通知することです。設定画面から印刷先を選び直せるようにもしておきます。

既定プリンターへ無言でフォールバックしてはいけません。 伝票が別の部署のプリンターから出る事故を、正常な印刷として隠してしまうためです。

flowchart TB
    accTitle: 起動時のプリンター名の検証
    accDescr: 起動時に設定ファイルのプリンター名がInstalledPrintersに存在するかを確認し、あれば印刷し、なければログを残してユーザーに通知して選び直させ、既定プリンターへ黙ってフォールバックしない
    start["起動時：設定のプリンター名"]
    start --> exists{"InstalledPrintersにあるか"}
    exists -->|"はい"| print["そのキューへ印刷"]
    exists -->|"いいえ"| log["ログを残してユーザーに通知"]
    log --> pick["設定画面で選び直す"]
    exists -.->|"やってはいけない"| silent["既定プリンターへ黙ってフォールバック"]

図20: 見つからないときに黙って別のプリンターへ出す実装が、いちばん発見の遅い事故を作る。

5.4 確認3: 仮想プリンターをファイル生成に使っていないか

第三者製PDFプリンターに印刷して出力フォルダーを監視する帳票アーカイブや、XPS Document Writerで中間ファイルを作る処理は、使っているキューがWPPで削除されると動かなくなります。

ただし、削除されるのはWPPでサポートされないソフトウェアプリンターです。ポートモニターDLL型などの非対応製品と、OneNoteのようにWPP対応へ更新済みの製品を混同しないでください。7章の手順3で、実際に使うキューが削除対象かを確認します。²

PDFが欲しいなら、前回記事の5章で説明したとおり、PDFライブラリで直接生成する構成へ寄せるのが、印刷スタックの変化に依存しにくい設計です。

5.5 確認4: RAW送信が、WPPで消えるキューを通っていないか

RAW送信は、OpenPrinter → StartDocPrinter(データ種別「RAW」) → WritePrinter → EndDocPrinterで、プリンター言語のデータをスプーラー経由で流す方式です。文書側がハードウェアの言語で印刷設定を完全に記述する必要があり、DEVMODEの設定は使われません。³²³³

ラベル・レシートでは定番ですが、RAW送信は「スプーラーを通らない直接通信」ではありません。ドライバーを実質的にポートへの通り道として使っていても、そのキューがWPPで消えれば通り道を失います。

flowchart TB
    accTitle: RAW送信の経路とWPPで消える箇所
    accDescr: アプリがOpenPrinter・StartDocPrinter・WritePrinterでプリンター言語のデータをスプーラーへ流し、WPPで残らないキュー（メーカー製ドライバーのキューなど）が通り道になってポートからプリンターへ届くため、WPPでそのキューが消えると通り道がなくなる
    app["アプリ：StartDocPrinter（RAW）・WritePrinter"]
    app --> spooler["スプーラー"]
    spooler --> queue["WPPで残らないキュー（通り道）"]
    queue --> port["ポート"]
    port --> printer["ラベル・レシートプリンター"]
    wpp["WPP有効化"] -.->|"キューが消える"| queue

図21: RAW送信はドライバーを通り道としてしか使っていないが、通り道そのものが消える。

確認すべきなのは、どのキュー・ドライバー・ポートの組み合わせへ送っているかです。メーカー製ドライバーのキューだけでなく、Generic / Text OnlyなどIPPクラスドライバー以外の物理プリンター向け同梱ドライバーも、残る前提にはできません。7章の削除一覧で消えると確認できたものは、同じように別経路が必要です。¹³

また、IPPクラスドライバーのキューへ独自PDLをRAWで流せるとは、Microsoft Learnには記述されていません。プリンター側のIPP実装が受け付けるPDLに依存するため、「IPPへ入れ替えれば同じRAWデータが通る」とは判断しないでください。

6. ラベル・レシートプリンターの逃げ道

ラベル・レシートには、スプーラーに依存しない出力経路を少なくとも一つ持つことを、小村ソフトは勧めています。

2章の署名例外に該当しても、メーカー製ドライバーの継続提供やWPPでの利用は保証されません。¹ Microsoftのトラブルシューティングにも、2021年の更新後にUSB接続のレシート・ラベルプリンターで印刷できなくなり、Known Issue Rollbackで解消した事例があります。³⁴ 出力経路を分けて把握しておくことが備えになります。

TCPの再接続設計にはシリアル通信アプリの落とし穴の考え方を使えます。USBの方式選択はWindowsアプリでUSB機器を扱う方法を参照してください。IPPはプリンターによって既定で無効なことがあり、有効化が必要です。⁴

SDKという名前だけでは独立した経路かどうかは分かりません。 SDKのドキュメントと5.1の一覧で、装置へ直接通信するのか、最後はWindowsのキューを呼ぶのかを確かめます。

Windowsのキューを使う場合、Universal PrintはWPP互換側ですが、これもスプーラーを通ります。IPPクラスドライバーでもUniversal Printでもないキューは、第三者ドライバーやXPS・FAXならWPPで止まり、Microsoft Print to PDFのように削除対象に挙げられていない同梱キューは個別に判定します。「WPP互換」と「スプーラー非依存」は別の分類です。

flowchart TB
    accTitle: 出力経路がスプーラーに依存するかを判定する流れ
    accDescr: 候補の経路がWindowsの印刷キューへ送る場合は、IPPクラスドライバーのキューでプリンターがMopria認証済みかつネットワーク接続ならIPPが有効で到達でき、USB接続ならIPP over USBモードのものと、Windows Ready Printの一部であるUniversal Printのキューはスプーラー依存でもWPP互換、Mopria非認証機や第三者ドライバーのキュー、XPS Document Writer・FAXのように4章の表で削除されるキューはWPPで止まり得て、Microsoft Print to PDFのように削除対象に挙げられていない同梱キューは5.1のとおり個別に判定し、キューへ送らない場合はSDKが内部でキューやドライバーを呼ぶなら同じ判定に戻り、呼ばないSDKや装置へ直接送る経路はスプーラーに依存しない逃げ道になる
    route["候補の出力経路"]
    route --> q1{"Windowsの印刷キューへ送るか"}
    q1 -->|"はい"| q4{"IPPクラスドライバーのキューか"}
    q4 -->|"はい"| q5{"Mopria認証済みか"}
    q5 -->|"はい"| q9{"IPP到達か（USBはover USB）"}
    q9 -->|"はい"| depok["依存するがWPP互換"]
    q9 -->|"いいえ"| dep["依存し、WPPで止まり得る"]
    q5 -->|"いいえ"| dep
    q4 -->|"いいえ"| q6{"Universal Printのキューか"}
    q6 -->|"はい"| depok
    q6 -->|"いいえ"| q7{"4章の表で削除されるか"}
    q7 -->|"はい（第三者ドライバー・XPS・FAX）"| dep
    q7 -->|"いいえ（Print to PDFなど）"| indiv["個別に判定（5.1）"]
    q1 -->|"いいえ"| q2{"メーカーSDKを介するか"}
    q2 -->|"はい"| q3{"内部でキュー・ドライバーを呼ぶか"}
    chk["確認：SDK文書と5.1の一覧"] -.-> q3
    q3 -->|"はい"| q4
    q3 -->|"いいえ"| indep["依存しない逃げ道"]
    q2 -->|"いいえ"| indep

図22: 最終的にどのキューを通るかで決まり、Mopria認証済み機のIPPクラスドライバーのキューとUniversal Printのキュー以外は、削除対象に挙げられていない同梱キューを除いてWPPで止まり得る。

7. 検証手順 ── WPPを使う場合・使わない場合

WPPを使う場合と使わない場合で、検証の分岐を先に確認します。どちらも変更前の出力を残し、実際に使う印刷先で確かめます。

flowchart TB
    accTitle: WPPの使用有無で分ける印刷の検証手順
    accDescr: 検証機に全キューを再現して変更前の出力を保存し、WPPを使う場合は有効化して削除されたキューを記録し互換機の再登録後の出力を比較するとともに非互換機の別経路を確認し、使わない場合は物理のIPP順位変更対象機を無効のまま再検出して出力を比較し、それ以外は実際のキューで印刷を確認する
    prepare["全キューを再現して記録"]
    prepare --> baseline["変更前の印刷結果を保存"]
    baseline --> use{"WPPを使うか"}
    use -->|"使う"| enable["有効化し削除キューを記録"]
    enable --> compatible["互換機は必要に応じ再登録"]
    compatible --> compare["変更前と同じ印刷で比較"]
    enable --> alternate["非互換機は別経路で確認"]
    use -->|"使わない"| physical{"物理のIPP順位変更対象か"}
    physical -->|"はい"| redetect["無効のまま削除・再検出"]
    redetect --> compare
    physical -->|"いいえ"| existing["実際のキューで印刷確認"]
    compare --> finish["結果を記録し検証機を復旧"]
    alternate --> finish
    existing --> finish

図23: 変更前の出力を共通の基準にし、WPPを使う環境だけ有効化する。使わない環境では、IPPの順位変更と実際のキューでの印刷を確かめる。

7.1 共通の準備: 本番ではなく検証機で、すべての印刷先を再現する

検証にはWindows 11 24H2以降のPCを使い、本番PCでは行いません。ネットワーク接続なら、同じプリンターへ到達できるVMで検証できます。USB接続の再登録や直接通信を評価する場合は、同じUSBインターフェースをパススルーできるVMを除き、物理の検証機を使います。

WPPの使用有無にかかわらず、次の手順1・2で変更前の状態を残します。

1. 現場でアプリが使うキューをすべて再現する。 メーカー製ドライバーの物理プリンターだけでなく、第三者製PDF仮想プリンターやGeneric / Text Onlyなどの同梱キューも同じ構成で入れます。5.1のスクリプトでドライバー名とバージョンを記録します。削除差分で判定できるのは、検証機に存在するキューだけです。
2. 印刷機能を一通り動かし、出力を保存する。 用紙・トレイ・両面・部数の設定画面、帳票ごとの印刷、PDF出力、ラベル印刷を確認し、後で比較できる基準を作ります。

flowchart TB
    accTitle: 検証機に再現するキュー
    accDescr: 5.1の棚卸しで分かったアプリが使うキューのうち、メーカー製ドライバーの物理プリンター、第三者製PDFなどの仮想プリンター、Generic / Text Onlyなどの同梱ドライバーのキューをすべて検証機へ現場と同じ構成で再現し、手順3の削除一覧で判定できるのは検証機に存在するキューだけであることを示す
    inv["5.1の棚卸し：アプリが使うキュー"]
    inv --> phys["物理プリンター（メーカー製）"]
    inv --> virt["仮想プリンター（第三者製PDF等）"]
    inv --> inbox["同梱ドライバー（Generic / Text Only等）"]
    phys --> vm["検証機に同じ構成で再現"]
    virt --> vm
    inbox --> vm
    vm --> judge["手順3の削除一覧で残るかを判定"]
    note["無いキューは削除差分に現れない"] -.-> judge

図24: 検証機に無いキューは削除差分に現れないので、棚卸しで分かったキューを先にすべて再現する。

7.2 WPPを使う環境: 有効化し、消えた印刷先も含めて検証する

手順1・2の後、次の順に進めます。

3. WPPを有効にし、削除されるキューを記録する。 設定アプリの「プリンターとスキャナー」から「Windows protected print mode」の「セットアップ」を選ぶと、削除対象がダイアログに表示されます。² グループポリシーで有効にする場合はダイアログが出ないため、適用前のGet-Printer結果を保存し、適用後に検証機を再起動します。IsProtectedPrintEnabledまたは設定画面で有効化を確認してから再度一覧を取り、差分を記録します。¹⁴
4. 削除された互換プリンターを再インストールする。 Windows Ready Printで入り直し、物理プリンターのDriverNameがMicrosoft IPP Class Driverに変わったことを5.1のスクリプトで確認します。
5. 同じ印刷を繰り返し、変更前と比較する。 設定画面の選択肢、保存設定の復元、キュー名の変更による印刷先の消失を確認します。出力の余白・フォント・罫線も、手順2の出力と突き合わせます。
6. 非互換機は、6章の別経路で印刷する。 「プリンターが一覧にない」状態を再現したうえで出力できることを確認します。直したコードだけでなく、用意した経路まで検証対象です。

7.3 WPPを使わない環境: 有効化せず、ドライバー選択の変化を検証する

WPPを使わない判断をした環境では、手順3・4を行いません。WPPを有効にするとキューごと削除され、順位付けだけの影響が見えなくなるためです。

7.4 検証後の復旧と、キッティング手順を整える

ローカルの設定アプリでWPPを有効化した検証機は、「オフにする」で戻せます。グループポリシーやIntuneから適用した場合は管理者側のポリシー変更が必要なので、有効化する経路に合わせて復旧手順も用意します。²¹³

WPPを無効に戻しても、Windows Ready Printで入れ直したプリンターはそのままです。非互換だったプリンターは手動で再インストールします。²¹⁰

キッティングでは、グループポリシーからIntuneへで整理した配布の仕組みに、WPPポリシーとプリンターの再登録手順を組み込みます。Point and Printによる第三者ドライバー配布は、2021年のKB5005652以降は既定で管理者資格情報が必要になっており、³⁴ WPPでは配布自体が行われません。⁹ WPPを使う環境では、ドライバー配布に依存した手順を、このポリシー適用と再登録の手順へ置き換えます。

flowchart TB
    accTitle: キッティング手順の見直し
    accDescr: Point and Printで第三者ドライバーを配っていた手順は、2021年以降は管理者資格情報が要るうえWPPでは配布自体が行われないため外し、代わりにWPPのポリシー(グループポリシーまたはOMA-URI)とプリンターの再登録手順を配布の仕組みに組み込む
    old["Point and Printで第三者ドライバーを配る"]
    old --> why1["2021年以降は管理者資格情報が要る"]
    old --> why2["WPPでは配布自体が行われない"]
    why1 --> drop["手順から外す"]
    why2 --> drop
    drop --> add["WPPのポリシーと再登録手順を組み込む"]

図25: ドライバーを配る手順は、WPPのポリシーとプリンターの再登録を配る手順に置き換わる。

8. まとめ

必要な対応は、「印刷先が残るか」→「コードが何に依存しているか」→「どの条件で検証するか」の順に決まります。

一つ直したら終わりではありません。 設定を直した後も、キュー名、仮想プリンター、RAW送信を続けて確認し、最後に7章で出力を確かめます。WPPを使わなくてもIPPの順位変更があり得る機器では、依存の棚卸しとWPP無効のままの再検出検証が必要です。

flowchart TB
    accTitle: 直すのか確かめるだけでよいのかの決定木
    accDescr: 印刷先のキューがWPPで残るか（Universal PrintのクラウドキューやWPP対応の仮想プリンター）または物理プリンターをWindows Ready Printで再登録できるかを先に判定し、できなければ別経路の用意かWPP不使用を選び、その機器がIPP対応で順位付けの変更により入れ替わり得るならドライバー固有設定の保存・キュー名や仮想プリンターへの依存（SDKやライブラリ内部を含む）・RAW送信の順に確認して該当すれば直したうえで次へ進み、最後はWPPを使う環境なら7章のWPP有効化検証へ、使わない環境なら物理のIPP対応機はWPPを無効にしたままの再検出検証へ、クラウドや仮想のキューは実際の出力確認へ進み、WPPを使わず入れ替わりの影響も無ければ現在の経路のまま運用する
    q0{"キューがWPPで残るか再登録できるか"}
    q0 -->|"いいえ"| alt{"どうするか"}
    alt -->|"別経路を用意"| qi{"IPP対応で入れ替わり得るか"}
    alt -->|"WPPを使わない"| qi2{"IPP対応で入れ替わり得るか"}
    qi -->|"はい"| q1{"ドライバー固有設定を保存しているか"}
    qi -->|"いいえ"| verify["検証だけ（7章）"]
    qi2 -->|"はい"| q1
    qi2 -->|"いいえ"| keep["現在の経路のまま運用"]
    q0 -->|"はい"| q1
    q1 -->|"はい"| fix1["直す（5.2）"]
    fix1 --> q2{"キュー名・仮想プリンターに依存しているか"}
    sdk["SDK・ライブラリ内部の依存も含む"] -.-> q2
    q1 -->|"いいえ"| q2
    q2 -->|"はい"| fix2["直す（5.3・5.4）"]
    fix2 --> q3{"RAW送信をWPPで残らないキューに流しているか"}
    q2 -->|"いいえ"| q3
    q3 -->|"はい"| fix3["通り道を用意（6章）"]
    fix3 --> vq{"WPPを使うか"}
    q3 -->|"いいえ"| vq
    vq -->|"はい"| verify
    vq -->|"いいえ"| pq{"物理のIPP対応機か"}
    pq -->|"はい"| redetect["WPPなしで再検出の検証（7.3）"]
    pq -->|"いいえ"| outchk["実際のキューで出力確認"]

図26: キューがWPPで残るかを先に判定し、コードの依存は一つ直しても次の確認へ進み、直した経路も最後は検証する。WPPを使わない場合は7章のWPP有効化ではなく、物理のIPP対応機はWPPを無効にしたままの再検出で、クラウド・仮想のキューは実際の出力で確かめる。

備えの期限は、Microsoftの日付ではなく自社の展開計画に置く

WPPは将来既定で有効になるとされていますが、その時期は示されていません。¹⁰ 備えの期限は、自社でWPPを有効にする前、またはWindows 11 24H2以降の機能更新を現場へ展開する前に置きます。2027年7月1日はドライバー供給側の節目であって、業務アプリ側の締め切りではありません。¹

flowchart TB
    accTitle: 業務アプリ側の備えの期限の置き方
    accDescr: いま一覧取得と棚卸しを行い、経路の変更と検証を、自社でWPPを有効にする前または24H2以降の機能更新を展開する前という自社側の期限までに終え、2027年7月1日のドライバー更新停止は供給側の節目であって備えの期限ではなく、時期未定のWPPの既定有効化がいつ来ても影響を受けない状態を先に作る
    now["いま：一覧取得と棚卸し"]
    now --> prep["経路変更と検証"]
    prep --> deadline["期限：自社でWPPを有効にする前 / 機能更新の展開前"]
    deadline --> fine["WPPの既定有効化（時期未定）が来ても影響を受けない"]
    ms["2027年7月1日：ドライバー更新停止"] -.->|"供給側の節目であって期限ではない"| prep

図27: 期限は自社の展開計画に置き、Microsoftの節目の日付を締め切りにしない。

まずは納品先の一覧を取り、設定・印刷先・出力経路の依存を把握するところからです。PDFは直接生成し、ラベル・レシートには印刷スタックから独立した経路を一つ持ちます。そのうえで、実際の展開条件に合わせて印刷を確かめます。

Windows 10にとどまる環境はこの計画の対象外ですが、通常チャネルのWindows 10(22H2)のサポートは2025年10月に終了しています。Enterprise LTSC・IoT Enterprise LTSCはエディションごとに期限が異なるため、ライフサイクルの確認が必要です。ESUやLTSCを含む判断はWindows 10サポート終了後の現実解、産業用PCは産業用PCにはどのWindowsを入れるべきかを参照してください。移行先のWindows 11で7章の検証をやり直すところまでが、印刷の備えです。

関連記事

• Windows業務アプリの印刷とPDF出力 ── System.Drawing.Printing / WPF / 帳票ライブラリの使い分け
• Excel帳票出力の作り方 - COM/Open XML/テンプレート
• Windowsサービスの作り方と運用 ── タスクスケジューラとの使い分けからBackgroundServiceのサービス化まで
• WindowsアプリでUSB機器を扱う方法 ── 仮想COM・HID・WinUSBの選び方
• シリアル通信アプリの落とし穴 - 再接続とログ設計まで
• グループポリシーからIntuneへ ── 中小企業のデバイス管理移行
• Windows 10サポート終了後の現実解 ── ESU・LTSC・買い替えの判断

関連する相談領域

合同会社小村ソフトでは、帳票・ラベル印刷を持つ業務アプリのプリンタードライバー依存の棚卸し、印刷経路の見直し(PDF直接生成、ラベルプリンターの直接制御)、Windows protected print modeを前提にした検証計画の設計を扱っています。

• 技術相談・設計レビュー
• Windowsアプリ開発
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

今動いているプリンターとアプリは、2026年7月や2027年7月を過ぎると突然印刷できなくなりますか？

なりません。Microsoftの計画は「新しいサードパーティ製ドライバーをWindows Updateに載せない」「順位付けでIPPクラスドライバーを優先する」「更新を受け付けない」という供給側の段階的な打ち切りで、既存のドライバーを無効化するものではないと明記されています。既存ドライバーはメーカー提供のインストーラーからも引き続きインストールできます。危ないのは、IPPクラスドライバーが合致する機器で、PCの入れ替えやOSの再インストールのときにドライバーが自動的にIPPクラスドライバーへ置き換わる場面と、Windows protected print modeが有効化された場面です。

Windows protected print modeは既定で有効になりますか？

本記事執筆時点(2026年9月)では既定で無効で、設定アプリかグループポリシー、Intuneで有効化します。ただしMicrosoftのFAQは「将来の時点で既定で有効になる」と明言しています。時期は示されていないため、有効化されても困らない状態を先に作っておくのが備えです。

ラベルプリンターやレシートプリンターはどうなりますか？

Mopria認証を取れないプリンターについては、2026年1月15日以降もドライバーの署名が例外的に認められる条件に挙げられています。つまりメーカー製ドライバーが当面残る可能性はありますが、Windows protected print modeを有効にした環境では第三者ドライバーを使うプリンターがアンインストールされるため、そのままでは使えません。装置と直接TCP/USB/シリアルで通信するメーカーSDKや、プリンター言語の直接送信で制御する経路を持っておくと、印刷スプーラーの変化から切り離せます。内部でWindowsのキューやドライバーを呼ぶSDKは、第三者ドライバーが消えれば同じように止まるため逃げ道になりません。

アプリの印刷コードはPrintDocumentのままでよいですか？

GDI印刷パスやXPS印刷パスは残り、Microsoftはv3/v4ドライバーの機能を無効化する計画はないと明言しています。PrintDocumentやFixedDocumentで描画しているだけのアプリは、直す対象ではなく確認する対象です。直す対象は、ドライバー固有の設定(DEVMODEの非公開部分やPrintTicketの私的名前空間)を保存・復元しているコード、特定のキュー名や仮想プリンター名に依存しているコード(メーカーSDKや帳票ライブラリが内部で呼ぶものを含む)、WPPで残らないキュー(メーカー製ドライバーのキューなど)へRAWデータをスプーラー経由で流しているコードです。ただし、印刷先のプリンター自体がWindows Ready Printで再登録できない機種なら、コードが描画だけでもWindows protected print modeの下ではキューごと消えるため、別経路の用意が先です。

何から手を付けるべきですか？

納品先のプリンターとドライバーの一覧を取るところからです。PowerShellのGet-PrinterとGet-PrinterDriverで、どのキューがどのドライバー(v3かv4か、IPPクラスドライバーか)を使っているかは管理者権限なしで取れます。次に、その一覧の中でアプリが名前指定・設定保存・RAW送信をしているキューを突き合わせ、本記事の判断表で「そのまま」「検証」「経路を変える」に振り分けます。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。