WPP環境下でも、macOSとLinuxのクライアントはWindowsプリントサーバー経由で印刷できますか？

要約

はい、可能です。プリントサーバーがIPPまたはIPPSでキューを公開している限り、MacおよびLinuxクライアントは、Windows Ready Print (WRP)とWindows Protected Print Mode (WPP)の両方の環境で、引き続きMicrosoftプリントサーバー経由で印刷できます。macOSとLinuxはどちらも印刷にCUPSを使用しており、CUPSはネイティブでIPPに対応しています。基本的な印刷は、クライアント側のドライバーを変更することなく機能します。ただし、高度な仕上げ機能は、標準のIPP属性でサポートされる範囲に限定されます。以前はクライアントにメーカー製ドライバーのインストールが必要だったベンダー固有の仕上げ制御機能は、この方法では利用できません。

現在のMac/LinuxからWindowsプリントサーバーへの印刷方法

Windows以外のクライアントがMicrosoftプリントサーバーに接続するには、常に2つの方法がありました。 SMBベース （印刷キューをSMB共有としてマウントし、SMB経由でジョブを送信し、サーバーが転送を処理する方法。AD認証と使い慣れたネットワークプリンターのUXにより、これまで複数のOSが混在する環境で主流でした）、そして IPPベース （IPP経由でキューに直接接続する方法。macOSの「プリンタとスキャナ」では「IPP」として表示され、LinuxのCUPSでは他のキューと同様に扱われます）。どちらも長年にわたって利用可能でした。WRPとWPPに関して問題となるのは、それぞれにどのような変更が生じるかです。

WRPとWPPによる変更点・変更されない点

ここで、両者を明確に区別しておくことが重要です。 Windows Ready Print (WRP) は、Microsoftが提唱する最新の印刷プラットフォームの名称です。デフォルトでIPPベースのドライバーレス印刷に対応し、フォールバックとして従来のサードパーティ製ドライバーも引き続き利用できます。 Windows Protected Print Mode (WPP) は、その上に構築された厳格な強制レイヤーです。WPPが有効になると、フォールバック機能は利用できなくなり、従来のドライバーは完全にブロックされ、Mopria認定プリンターのみが動作します。Microsoftは2026年5月にWRPという名称を発表しました。基盤となるプラットフォームは同じですが、従来機能へのフォールバックが存在するかどうかが異なります。

ただし、 Mac やLinuxクライアントにとっては、WRPとWPPの区別はWindowsクライアントほど重要ではありません。なぜなら、これらの機能が強制されるのはWindowsクライアント側であり、サーバー側ではないからです。

WPPとWRPが強制されるのはWindowsサーバー上ではなく、Windowsクライアント上です。Windowsプリントサーバー自体は、MacやLinuxクライアントを制御するという意味でWPPやWRPを実装しているわけではありません。サーバーが実装しているのは、これまで通り（IPPキュー、SMB共有、GPOによる構成、スプーラーサービスなど）の機能です。Windows Server 2025には機能としてWPPが含まれていますが、意味のある強制措置が行われるのは、接続におけるWindowsクライアント側です。

MacやLinuxクライアントには、こうした強制措置は一切適用されません。macOSとLinuxには、WPPが対象とするWindowsの印刷スプーラーやサードパーティ製ドライバーモデルが存在しません。これらは当初からIPPを中心に構築されたCUPSを使用しています。そのため、クライアント側はWRPのデフォルト設定やWPPの強制措置による影響を受けません。

変更されるのは、Windowsプリントサーバーがそのキューを通じて提供できる内容です。具体的には次の通りです。

• IPPキューは引き続き機能します。 IPPキューをホストしているWindowsプリントサーバーは、引き続きIPP/IPPS経由でキューを公開します。MacおよびLinuxクライアントは接続し、IPP形式の印刷ジョブを送信すると、サーバーがそれをプリンターに転送します。この方法は、WRPとWPPの両方の環境で機能し続けます。
• Windows Server 2025へのSMBベースの印刷には既知の問題があります。 macOSクライアントからのSMB印刷キューへのアクセスには、Windows Server 2025との間でドキュメント化された互換性の問題が特に報告されています。これは、ジョブがキューに入った後、通知なく失敗するというもので、WPPやWRPの強制とは無関係です。これはWPP/WRPの問題ではなく、Microsoftが認識しているものの、まだ解決されていないServer 2025固有の挙動です。CUPSベースのSMB接続を使用するLinuxクライアントは、異なる影響を受ける可能性があります。お使いの環境でMacクライアントがSMB経由でWindows Server 2025プリントサーバーに接続している場合、IPPが推奨される方法であり、問題なく動作します。

• SMB経由でのクライアントへのドライバーダウンロードは、いずれにせよWindows以外のクライアントには適用されません。 これはWPPの影響を受けるWindowsクライアント向けのパスですが、Windows固有の仕組みです。MacおよびLinuxクライアントは、WPP/WRP導入前の環境であっても、プリントサーバーからWindowsドライバーを取得することはありません。これらはCUPSで解決可能なパスを使用するか、ローカルにインストールしたPostScript/PCLドライバーを使用します。

WRPとWPPで利用できる機能と制限される機能

基本的な印刷と認証：影響なし。

ページ出力、カラー/白黒、両面印刷、Nアップ印刷、その他IPP標準の属性は、これまでと同様に機能します。Active Directoryベースのプリンターアクセス許可は、接続方法が選択された認証メカニズム（AD認証SMB接続の場合はKerberos、IPPベース接続の場合はIPP-AUTHまたはNegotiate）をサポートしている限り、MacおよびLinuxクライアントにも引き続き適用されます。

仕上げ機能：標準IPPは利用可能、ベンダー固有の機能は制限あり。

IPPは、仕上げオプションに関する標準の語彙を定義しています。8つの標準ステープル位置、2種類の綴じ方（エッジステッチ と 中とじ）、整数オフセット属性で指定されるパンチ穴の位置、IPP Finishings 3.0で定義された12の標準的な折り方、そして排紙ビンの選択です。プリンターのファームウェアがこれらの機能を公開し、プリントサーバーがIPP属性を正しく転送すれば、MacおよびLinuxクライアントは、 Windows上のIPPクラスドライバーと同様にこれらを要求できます。制限されるのは、Windows のPSAモデルに依存するベンダー固有の仕上げ制御機能です。MacおよびLinuxクライアントにはPSAに相当する機能がありません。そのため、IPP標準属性で記述される機能に加え、ローカルにベンダー独自のMacドライバーがインストールされている場合は、そのドライバーが公開する機能のみを利用できます。

Mopria非対応プリンターの高度なレンダリング：Windowsプリントサーバーの役割ではない。

プリントサーバーの従来のドライバープールが、Windows以外のクライアントからのジョブをレンダリングし、Mopria非対応のプリンターに転送できるという誤解がよくあります。Windowsの印刷キュー/ドライバーモデルは、そのような変換パターンをサポートしていません。各キューは1つのドライバーとペアになり、そのドライバーの形式でジョブを受け取ることを想定しています。Mac/Linux/Windowsが混在する環境でMopria非対応デバイスを使用する場合、有効な方法は、各クライアントからIPP対応プリンターへの直接IPP接続、可能な範囲でのハードウェア更新、またはWindowsの印刷パス外で変換を処理するクラウドレンダリングアーキテクチャの導入です。

お使いの環境がこの方法に依存している場合の対策

どのクライアントがどのパスで接続しているかを監査する。 MacおよびLinuxクライアントがSMB経由で接続するかIPP経由で接続するかによって、Windows Server 2025に対する印刷体験は異なります。これは仕上げ機能の制御だけでなく、ジョブがそもそも完了するかどうかにも関わります。この内訳を把握することが第一歩です。

WRPまたはWPPの設定を変更する前に、MacクライアントをIPPに移行する。 Windows Server 2025のSMBの問題はWPP/WRPとは無関係ですが、WPPへの移行プロジェクト中に表面化する可能性があります。先にMacクライアントをIPPキューに移行させることで、その変動要因を排除できます。

本格展開の前に、WRPを有効にしたWindowsサーバーイメージでクロスプラットフォーム印刷をテストする。 具体的には、印刷ジョブの送信、キューへのアクセス、macOSまたはLinuxの印刷ダイアログに表示される仕上げオプション、そして業務フローで依存しているベンダー固有のオプションをテストしてください。IPP印刷パスは変更なしで機能するはずですが、仕上げ機能の詳細とSMBの挙動には予期せぬ問題が潜んでいる可能性があります。

高度な仕上げ機能のために、IPP属性フォールバックパスを文書化する。 WRPへの移行によってMacやLinuxクライアントがベンダー固有の仕上げ機能にアクセスできなくなった場合でも、通常はIPP標準の属性で同等の操作をカバーできます。ベンダー固有のオプションをIPP標準の同等機能にマッピングした移行ドキュメントを作成しておくと、後々役立ちます。

Windows Ready Print環境でezeepはどのように機能するのか？

ezeepはWindowsプリントサーバーを印刷経路から完全に排除するため、この記事で取り上げたような問題はezeep環境には当てはまりません。Server 2025へのSMB接続の問題、WindowsクライアントでのWPPの強制、サーバー経由のキューで利用できる仕上げ属性など、プリントサーバーが存在しない環境では、これらのいずれも考慮すべき変数にはなりません。

Mac、Linux、Windowsクライアントは、それぞれプラットフォームネイティブの方法でezeepに接続します。クラウドレンダリングによる印刷パスは、サポートされているすべてのOSに同じ体験を提供します。印刷ジョブの送信、キューへのアクセス、IPP標準属性で利用可能な仕上げ機能、そしてMicrosoft Entra IDまたはGoogle WorkspaceとのIDプロバイダー連携による認証などです。

Windowsでは、ezeep Print Appがクライアント側を処理し、現在WPPが有効なマシンでも動作します。MacおよびLinuxクライアントは、それぞれのプラットフォームネイティブのパスで接続します。クロスプラットフォームでの印刷は問題なく機能し、Windowsクライアント上のWPPはMacやLinuxに影響を与えず、Server 2025のSMB問題も気にする必要はありません。

クロスプラットフォーム印刷環境について専門家に相談する

お使いの環境構成（Windows Serverのバージョン、キュー、OS別クライアント、仕上げ機能に依存する業務フロー）をお知らせください。WRPおよび WPP の下で各クライアントクラスにどのような変更が生じるか、またクロスプラットフォームでのギャップがどこにあるかを明らかにします。まずはご自身で始めたいですか？ぜひチェックしていただきたい WPP対応チェックリスト をご用意しています。

複数OSが混在する環境を運用中ですか？

貴社のすべての印刷経路を可視化し、最適な構成をご提案します。

専門家に相談する