会社情報
採用情報
お問い合わせ
Article

30分で設定！クラウドプリントで印刷効率化

高田晃太郎
30分で設定！クラウドプリントで印刷効率化

クラウド移行が加速する一方で、社内の印刷はレガシーのままという声は少なくありません。業界の公開情報や各種ベンダー資料を見ても、印刷は依然として無視できない運用負担とコスト要因であり、ヘルプデスク工数や間接時間に効いてきます[1][7]。ハイブリッドワークで拠点をまたぐ印刷要求が増えた結果、VPNやオンプレサーバを迂回するレイテンシが積み上がり、ユーザー体験を損ねる状況も散見されます。クラウドを前提にした印刷自動化は、この遅さと運用負債を同時に削る現実的な打ち手です。ここでは30分で最初のジョブが出るまでを目標に、CTOやエンジニアリーダーが判断と実装に必要な具体的なアーキテクチャ、手順、コード例を示します。

クラウドプリントの現在地と選択肢

Google Cloud Printの終了以降、実質的な選択肢は二極化しました。Microsoft Entra ID（旧Azure AD）と統合されたMicrosoft Universal PrintのようなID一体型SaaSを採用するか[3]、CUPS（Common UNIX Printing System）とIPP Everywhere（ドライバレス印刷の標準）を土台に軽量なエージェントを配置して自社のキュー制御を維持するかです[4][6]。どちらも IPP over TLS（暗号化した印刷プロトコル）と証明書検証を前提にできます[4][5]。SaaSはポリシー配布やゼロタッチ展開で有利で、DIYはデータ経路とコストのコントロールに強みがあります。印刷のQoSは、プリントサーバの有無よりもスプール（ジョブの一時保管）の近接性とジョブ転送方式の影響が大きく、PDF直送かPCL/PSのラスタライズをどこで行うかがレイテンシを左右します。Universal Printはクラウドスプールとコネクタでドライバを抽象化し[3]、DIYではCUPSフィルタでサーバ側レンダリングを選べます。トレードオフは明瞭で、管理の自動化と可観測性を優先するならSaaS、データ所在とコスト最適化を優先するならDIYが適合します。

30分クイックスタートの全体像

短時間で立ち上げる鍵は、既存のID基盤を流用しながら、既存プリンタのIPP対応を活かすことです。Entra ID環境があるならUniversal Printでライセンス割り当てとコネクタ登録を済ませ、クラウドスプールにキューを公開します[8]。オンプレ中心ならUbuntu上のCUPSを用意し、プリンタをIPP Everywhereまたはベンダドライバで追加し[6]、外部からはHTTPSのリバースプロキシ経由で到達させます[5]。ユーザー端末にはネイティブのAirPrint/IPPクライアントやユニバーサルドライバを使い[6]、PDFをダイレクト送信します。必要な前提（テナントとライセンス、プリンタ管理UIへのアクセス、TLS証明書配備など）が揃っていれば、最小構成で「数十分程度」で初回排紙に到達できるケースがあります。いずれも、証明書の準備とネットワーク到達性がクリティカルパスです[5]。

アーキテクチャの考え方

ボトルネックは三つに整理できます。ジョブのアップロード時間、レンダリング時間、プリンタとのラストワンマイルの遅延です。クラウドプリントではアップロードとレンダリングをクラウドまたはエージェント側で非同期化し、プリンタ近接での最終転送を確保すると待ち時間を圧縮できます。可観測性の観点では、キューの深さ、アップロード完了からプリンタ受信までの区間、受信から排紙までの区間を分けてメトリクス化します。Universal PrintはGraph API経由でジョブ状態を取得でき[3]、DIYの場合はCUPSのaccess_logとpage_logから時刻差分を取ることで同等の可視化が可能です。

実装ガイド：30分で動かす最短ルート

ここからは実装に踏み込みます。SaaS型としてMicrosoft Universal Print、DIY型としてCUPS+IPPの双方に触れます。どちらも実行可能なコード例を複数含め、エラーハンドリングと計測の勘所を明確にします。

Universal Print（Microsoft Graph API）での送信例（Python）

Microsoft Entra IDでアプリ登録し、適切な権限（例：PrintJob.Create、Printer.ReadWrite.All など）を付与してMSALでトークンを取得後、Graph APIのアップロードセッションを開始します。大きなファイルはチャンクアップロードに切り替えます[3]。

import os
import msal
import requests
from pathlib import Path

TENANT_ID = os.environ["AZURE_TENANT_ID"]
CLIENT_ID = os.environ["AZURE_CLIENT_ID"]
CLIENT_SECRET = os.environ["AZURE_CLIENT_SECRET"]
PRINTER_ID = os.environ["UP_PRINTER_ID"]
FILE_PATH = Path("./sample.pdf")
AUTHORITY = f"https://login.microsoftonline.com/{TENANT_ID}"
SCOPE = ["https://graph.microsoft.com/.default"]

app = msal.ConfidentialClientApplication(CLIENT_ID, authority=AUTHORITY, client_credential=CLIENT_SECRET)
result = app.acquire_token_silent(SCOPE, account=None)
if not result:
    result = app.acquire_token_for_client(scopes=SCOPE)
if "access_token" not in result:
    raise RuntimeError(f"Token acquisition failed: {result}")

headers = {"Authorization": f"Bearer {result['access_token']}", "Content-Type": "application/json"}
create_job_url = f"https://graph.microsoft.com/v1.0/print/printers/{PRINTER_ID}/jobs"
job_body = {"documents": [{"displayName": FILE_PATH.name, "contentType": "application/pdf"}]}
job_res = requests.post(create_job_url, json=job_body, headers=headers, timeout=30)
job_res.raise_for_status()
job = job_res.json()

upload_url = job["documents"][0]["uploadSession"]["uploadUrl"]
with FILE_PATH.open("rb") as f:
    data = f.read()
up_headers = {"Content-Length": str(len(data)), "Content-Range": f"bytes 0-{len(data)-1}/{len(data)}"}
up_res = requests.put(upload_url, data=data, headers=up_headers, timeout=120)
if up_res.status_code not in (200, 201, 202):
    raise RuntimeError(f"Upload failed: {up_res.status_code} {up_res.text}")

start_url = f"https://graph.microsoft.com/v1.0/print/printers/{PRINTER_ID}/jobs/{job['id']}"
patch_res = requests.patch(start_url, json={"configuration": {"dpi": 300}}, headers=headers, timeout=30)
patch_res.raise_for_status()
print(f"Job submitted: {job['id']}")

このコードは機密クライアントでの認証から、ジョブ作成、アップロード、開始までを一気通貫で処理します。数十ページ規模のPDFであれば、クラウド側レンダリングと近接コネクタの組み合わせにより、オンプレ共有サーバ経由よりも待ち時間が短くなるケースが一般的に見られます（もちろんネットワークやプリンタ性能に依存します）。

CUPS + IPPでのダイレクト送信（Node.js）

現場に残る既存プリンタの多くはIPP Everywhereに対応しています[6]。サーバ側にCUPSを置き、クライアントからIPP（Internet Printing Protocol）経由でPDFを送る構成はシンプルで保守性が高いです[4]。

import fs from 'fs';
import ipp from 'ipp';

const PRINTER_URI = process.env.PRINTER_URI || 'http://cups.local:631/printers/Office';
const filePath = './sample.pdf';

async function printPdf() {
  const data = await fs.promises.readFile(filePath);
  const printer = new ipp.Printer(PRINTER_URI, { timeout: 15000 });
  const msg = {
    'operation-attributes-tag': {
      'requesting-user-name': process.env.USER || 'ci-bot',
      'job-name': 'NOWH-Cloud-Print',
      'document-format': 'application/pdf'
    },
    data
  };
  return new Promise((resolve, reject) => {
    printer.execute('Print-Job', msg, (err, res) => {
      if (err) return reject(err);
      if (res && res.statusCode && res.statusCode !== 'successful-ok') {
        return reject(new Error(`IPP error: ${res.statusCode}`));
      }
      resolve(res);
    });
  });
}

printPdf()
  .then(() => console.log('Print job submitted'))
  .catch(e => {
    console.error('Print failed', e);
    process.exitCode = 1;
  });

プリンタがPDF処理をネイティブ対応している場合は特に速く、受付からプリンタ受信までが数百ミリ秒〜数秒程度に収まることも珍しくありません。プリンタ側のラスタライズが遅い場合は、CUPSフィルタでサーバ側レンダリングに寄せると安定します。

最小構成のCUPSセットアップ（Linux, Bash）

DIY派の初期構築では、TLS有効化と管理UIの限定公開を最初に済ませます。以下はUbuntuの最短例です[5]。

set -euo pipefail
sudo apt-get update && sudo apt-get install -y cups cups-filters
sudo usermod -aG lpadmin "$USER"

# 最小限のセキュア設定（管理UIは限定公開、TLS必須）
sudo bash -c 'cat >/etc/cups/cupsd.conf <<EOF
LogLevel warn
WebInterface Yes
DefaultEncryption Required
Port 631
Listen 0.0.0.0:631
# 管理UIのアクセス制御（環境に合わせてCIDRを調整）
<Location />
  Order allow,deny
  Allow localhost
  Allow 10.0.0.0/8
</Location>
# サーバ証明書（内部PKIやACMEで配備）
ServerKey /etc/cups/ssl/server.key
ServerCertificate /etc/cups/ssl/server.crt
<Policy default>
  Require user @SYSTEM,@OWNER
</Policy>
EOF'

sudo systemctl restart cups

# プリンタ追加（例：IPP Everywhere）
sudo lpadmin -p Office -E -v ipp://printer.local:ipp/print -m everywhere
sudo cupsenable Office && sudo cupsaccept Office

証明書は内部PKIやACMEで自動更新し、管理UIは管理ネットワークのみに限定すると安全です[5]。CUPSのpage_logを監視基盤（例：CloudWatchやLoki）に転送し、ジョブ周期時間をメトリクス化するとキャパシティ計画に役立ちます。

軽量エージェントで“最後の一歩”を自動化（Docker Compose + Node）

クラウドキューから現場プリンタへ橋渡しする軽量エージェントは、拠点数が増えても横展開しやすい形です。SQSを受信してCUPSに投げる例を示します[7]。

version: "3.8"
services:
  print-agent:
    image: node:20-alpine
    working_dir: /app
    environment:
      - AWS_REGION=ap-northeast-1
      - QUEUE_URL=https://sqs.ap-northeast-1.amazonaws.com/123456789012/print
      - PRINTER_URI=http://cups.local:631/printers/Office
    volumes:
      - ./agent:/app
    command: ["node", "agent.js"]
    network_mode: host

import { SQSClient, ReceiveMessageCommand, DeleteMessageCommand } from "@aws-sdk/client-sqs";
import fetch from "node-fetch";
import fs from "fs";
import ipp from "ipp";

const sqs = new SQSClient({});
const queueUrl = process.env.QUEUE_URL;
const printer = new ipp.Printer(process.env.PRINTER_URI, { timeout: 15000 });

async function loop() {
  while (true) {
    const res = await sqs.send(new ReceiveMessageCommand({ QueueUrl: queueUrl, MaxNumberOfMessages: 1, WaitTimeSeconds: 10 }));
    if (!res.Messages || res.Messages.length === 0) continue;
    for (const m of res.Messages) {
      try {
        const payload = JSON.parse(m.Body);
        const pdf = await fetch(payload.url);
        const buf = Buffer.from(await pdf.arrayBuffer());
        await new Promise((resolve, reject) => {
          const msg = { 'operation-attributes-tag': { 'requesting-user-name': payload.user || 'agent', 'job-name': payload.job || 'cloud' , 'document-format': 'application/pdf' }, data: buf };
          printer.execute('Print-Job', msg, (err, r) => err ? reject(err) : resolve(r));
        });
      } catch (e) {
        console.error('Job failed', e);
      } finally {
        await sqs.send(new DeleteMessageCommand({ QueueUrl: queueUrl, ReceiptHandle: m.ReceiptHandle }));
      }
    }
  }
}

loop().catch(e => { console.error(e); process.exit(1); });

この方式は拠点ごとにエージェントを常駐させ、クラウドからの配信を受けてプリンタ近接で出力するため、WANの不安定さを吸収できます。簡易な計測でも、ジョブ投入からプリンタ受信までがサブ秒〜数秒台に収まるケースが確認しやすく、オンプレ共有ディスク経由の従来方式より安定する傾向があります（ネットワーク品質とプリンタ性能に依存）。

運用・セキュリティ・可観測性：落とし穴と対処

セキュリティでは三点を押さえます。まずアイデンティティは端末ではなくユーザー中心で統制し、Entra IDやIdPの条件付きアクセスで印刷権限を絞り込みます。次にデータ経路はIPP over TLSで暗号化し、自己署名ではなく企業CAあるいはACME発行の証明書を用います。可能であればエージェント側での証明書ピンニングや信頼ストアの厳格化も検討します[5]。最後にプリンタ本体のストレージ暗号化とジョブ自動消去を有効化し、装置廃棄時の情報漏えいを防ぎます。運用では、紙詰まりやトナー切れといった物理的障害が依然としてSLAを揺らします。そこで、ジョブ単位の再送制御とデッドレタキューを用意し、失敗時は自動で別プリンタにフェイルオーバーさせると、ユーザーは障害を意識しなくて済みます。Universal Printはジョブ状態がGraphで取得でき[3]、DIYではCUPSのjob-stateやプリンタSNMPの稼働情報を集約して同等の切り替えを実現できます。可観測性は、エンドツーエンドのタイムラインで可視化するのが近道です。クライアント送信時刻、クラウド受付、エージェント受信、プリンタ受信、排紙完了という粒度で計測し、ダッシュボードに中央値とp95を並べると、チューニングの効果が一目で分かります。PDFの圧縮率やレンダリング位置（サーバ側/プリンタ側）を見直すだけでも、アップロード区間や総レイテンシが実用上意味のある幅で改善することは珍しくありません。ログはジョブIDで関連付け、トレースIDをHTTPヘッダに通すと調査コストが下がります。

パフォーマンス指標とSLOの置き方

実務で役立つ指標は四つです。投入から排紙までの総レイテンシ、受付からプリンタ受信までのネットワーク区間、ラスタライズ時間、リトライ率です。SLOは業務の重要度に応じて、例えば「総レイテンシのp95を15秒以内」「リトライ率1％未満」「失敗時の自動リカバリ完了p95を60秒以内」といった水準を起点に検討すると現実的です。業務改善の観点では、ユーザーが印刷完了を待つ時間をどれだけ削れるかが生産性に直結します。

ROIと具体的数値：導入判断の軸

意思決定を速くするには、前提を明確にした試算が有効です。例えば、100人規模の組織で「1人あたり月30ジョブ」「1ジョブあたり平均待機45秒」「障害対応にITが月10時間」「オンプレサーバ維持費が月3万円」といった仮定を置きます。クラウドプリントの自動化で待機が大きく短縮されるケースを想定すると、ユーザー待機の総量は月あたり数十〜百数十時間規模で減らせる可能性があります。IT工数は自動復旧と監視一元化で削減余地があり、サーバ維持費はSaaSに置き換えればサーバ費用をゼロにできる一方、SaaSの席ライセンス費を加味しても総額は同程度か、わずかな増減に収まるケースが一般的です。年間換算では、人的コスト換算で数百万円規模の改善につながる可能性があります。もちろん実数値はジョブ件数、文書サイズ、ネットワーク、プリンタ性能、ライセンス構成で大きく変動します。ハイブリッド構成でも、最初の30分で“1台・1拠点・1ジョブ”を成功させ、計測値に基づいて横展開するのが失敗しない進め方です。より深い設計やゼロトラスト連携の検討には、ID基盤チームやネットワークチームと早めに合流すると後戻りが減ります。関連する深掘りとして、ゼロトラスト設計の基礎、印刷ログの可観測性設計、Entra ID/Graph APIのベストプラクティスなども合わせて参照すると設計の解像度が上がります。

まとめ：30分の成功体験から全社最適へ

印刷は地味に見えて、ユーザー体験とセキュリティ、運用負債が交差する厄介な領域です。しかし、クラウド前提で設計し直すと、待ち時間の短縮と可観測性の獲得、権限管理の一元化が同時に進みます。本稿で示したUniversal PrintとCUPSの二つのルート、そしてコード例を組み合わせれば、最初の30分でジョブを通すところまで到達できます。まずは“1台・1拠点・1ジョブ”を成功させ、そのメトリクスを可視化する。その小さな成功が、展開・標準化・運用自動化の加速剤になります。あなたの組織では最初の30分で何を検証しますか。プリンタ近接のレイテンシ、Graphの権限設計、ログの粒度のどれからでも構いません。今日のうちに小さなパイロットを走らせ、来週のスプリントレビューで結果を共有するところから、業務改善の歯車を回していきましょう。

参考文献

  1. Meridith Levinson, Little Printers, Big Expense: How to Control Imaging Costs. CIO (IDG). https://www.cio.com/article/274010/infrastructure-little-printers-big-expense-how-to-control-imaging-costs.html
  2. UniPrint, Cloud Printing Management: The Secret to Fewer Help Desk Tickets. https://uniprint.net/en/cloud-printing-management-the-secret-to-fewer-help-desk-tickets/
  3. Microsoft Learn, Universal Print in Microsoft 365: Overview and Microsoft Graph integration. https://learn.microsoft.com/en-us/graph/universal-print-concept-overview
  4. CUPS Documentation, Internet Printing Protocol (IPP) Specifications. https://www.cups.org/doc/spec-ipp
  5. CUPS Documentation, Encryption Overview (SSL/TLS). https://www.cups.org/doc/encryption
  6. Printer Working Group (PWG), IPP Everywhere. https://www.pwg.org/ipp/everywhere.html
  7. TechTarget, VPN and cloud-based printing options change with the times. https://www.techtarget.com/searchenterprisedesktop/feature/VPN-and-cloud-based-printing-options-change-with-the-times
  8. Microsoft Learn, Get access to Universal Print. https://learn.microsoft.com/en-us/universal-print/get-access-to-universal-print