ezeepが選ばれる理由：ドライバーレスとサーバーレスを解説

ezeepは、多くのプラットフォームが単に場所を移すだけの2つの要素、すなわちエンドポイント上のプリンタードライバーとプリントサーバー自体を、印刷環境から完全に排除します。多くの組織が他のクラウド印刷方式ではなくezeepを選ぶのは、このアーキテクチャという抽象的な考え方のためではなく、これら2つを排除することで得られる実務上の効果が目的です。この記事では、それぞれが日常業務にどのような変化をもたらすかを分かりやすく説明します。

driverless printingは、ITチームに何をもたらしますか？

driverless printingは、ユーザーのデバイスからプリンタードライバーを完全に排除します。その結果、印刷関連のサポートチケットで最も多い原因が根本から消えます。ドライバーの競合、OSと機種間のバージョン不一致、Print Spoolerのクラッシュなどはチケット発行の典型的な理由ですが、そもそもドライバーがインストールされていないデバイスではこれらの問題は発生しません。

もう一つの見落とされがちな利点があります。メーカー製のプリンタードライバーは保守が手薄になりがちです。プリンターベンダーはハードウェア販売を優先するため、ドライバーやファームウェアのセキュリティパッチが脆弱性の発見から大きく遅れることがあります。こうした保守の遅れが、PrintNightmare（CVE-2021-34527）のような深刻な被害を招いた一因です。エンドポイントからドライバーを排除すれば、各メーカーの対応状況に関わらず、その攻撃対象領域を丸ごと取り除けます。

さらに、これはezeepのアーキテクチャがすでに Windows Protected Print (WPP)と整合していることを意味します。Microsoftが推進するより厳格なドライバーレス印刷モデルに対応しており、ezeepを導入している組織はWPP要件を満たすためにドライバー資産の監査や非準拠機器の交換を行う必要がありません。driverlessなアーキテクチャにより、標準で要件を満たします。

OS別・機種別のドライバー管理は不要です 従来は、プリンター機種ごとに専用ドライバーが必要で、それぞれのオペレーティングシステム用に別バージョンを用意する必要がありました。 HP, 、Xerox、Konica Minolta、Brotherといった複数メーカーの機種が混在し、 Windows, 、macOS, 、ChromeOS, 、iOS、および Android のような多様なエンドポイントがある環境では、ITはテスト、パッケージ化、更新を続ける膨大な組み合わせ（マトリクス）を管理しなければなりません。ezeepのcloud renderingエンジンは、6,000種類以上のメーカー固有ドライバーをライブラリとして保持し、デバイスはローカルにドライバーを保持する代わりにドライバー不要の印刷ストリームを送信します。

この利点が最も効いてくるのは、新しい端末やデバイスが導入された瞬間です。 オフィスのWindowsノートPC、, 自宅のMacBook、教室のChromebook のいずれも、同じcloud renderingプロセスを通じてプリンターに接続されるため、「Macユーザーだけ」「モバイルユーザーだけ」といった別ルートでのトラブルシューティングが不要です。プリンターを新たに追加する場合も同様で、新ドライバーをパッケージ化してテストしてから展開する代わりに、 その機種がすでにezeepのクラウドライブラリにあるかを確認 し、なければライブラリへの追加をリクエストするだけで済みます。（※上の行番号に合わせて項目を参照してください）

新規導入で管理者権限がボトルネックになることはありません 2021年のPrintNightmare対策パッチ以降、標準のPoint and Print経路でプリンタードライバーをインストール・更新するにはデフォルトで管理者資格情報が必要になりました。これは意図されたセキュリティ強化ですが、その結果ローカルでのドライバーインストールに依存する新規デバイスや接続はすべて管理者の介入が必要になっています。driverlessなエンドポイントではローカルインストールのステップ自体が存在しないため、この経路はそもそも発生しません。

serverless printingは、ITの予算と保守に何をもたらしますか？

serverless printingは、print serverの役割を単に別の場所に移すのではなく、環境から完全に排除します。これにより、そのサーバーを運用するためにかかるコストやメンテナンスのカテゴリ自体が不要になります。

まずハードウェア面から見てみましょう。従来、オフィスや拠点ごとに設置されることが多かったprint serverは物理インフラであり、購入・ラック設置・電源供給・リプレースといった管理が必要です。ezeepはその役割を ezeep Hub（小型のコネクターデバイス）または既存のマシン上で動作するezeep Connectorソフトウェアで代替します。どちらもサーバーが担っていたキュー管理やドライバーのホスティングは行いません。ローカルにホストするキューもドライバーライブラリも存在しないためです。

ハードウェアが不要になると、関連するライセンス費用も削減されます。専用のprint serverを運用する場合、通常以下のような費用が発生します。

• Windows Serverのライセンス
• ウイルス対策ソフト
• リモート管理ツール
• 本番稼働に必要なその他のソフトウェア

これらはいずれも無償ではありません。サーバーの役割を移転ではなく排除することで、これらのコストはクラウド費用の別項目として残るのではなく、そのまま削減されます。

パッチ適用やフェイルオーバー計画もITの負担から外れます print serverは独自のパッチサイクルを持ち、ダウンすればそれに接続する全ユーザーが復旧するまで印刷できません。サーバーの役割がなくなることで、サーバー固有のパッチスケジュールを維持する必要はなくなり、拠点ごとに1台の機器に依存する単一障害点も解消されます。導入作業も同様です。従来のprint serverを新拠点に追加するには、そのサーバーのプロビジョニング、ドライバーのインストール、キュー設定、ネットワーク接続といった作業が必要でした。ezeepでは、Hubを接続して管理ポータルでプリンターを割り当てるだけで、ある拠点の cloud-based printing を稼働させるまでの所要時間はおおむね30分程度です。

driverlessとserverlessは、ezeepのアーキテクチャでどう連携しているのか？

これらは別々に組み合わせた2つの機能ではなく、同じ根本的な設計判断が生んだ2つの効果です。 ezeepは印刷ジョブを完全にcloud renderingで処理するため、エンドポイントもローカルサーバーもドライバーを保持する必要がありません。従来のprint serverの主な役割は、デバイスが必要とするドライバーをホストして配布することでした。ドライバーをその方程式から取り除けば、print serverが担うべき役割は事実上なくなります。

ezeepは ThinPrintのテクノロジーを基盤としており、日々何百万ページもの印刷を処理する本番環境で使用されています。アーキテクチャは当初からクラウドネイティブで設計されており、だからこそ driverless と serverless は、ezeepが既存製品を移行して実現したものではなく、その基盤そのものなのです。

14日間の無料トライアルを始める driverlessでserverlessな印刷環境が、既存のプリンターインフラと比べてどのように機能するか、ぜひ14日間の無料トライアルでご確認ください。

ITチームの仕事は、印刷管理だけではないはずです

ezeepにお任せください

無料で試す