zplCloud Blog
オンラインビューアーか、デスクトップツールか、ローカルスクリプトか: 本当に問うべきは、ラベルパイプラインをどこで動かすか
デザイン、レンダリング、ストリーミング、印刷が 1 つのコンテナーにまとまれば、「オンラインかデスクトップかローカルか」という議論は終わります。クラウドでも、オンプレミスでも、自社のデータセンターでも、git push 1 つでデプロイできます。
オンラインか、デスクトップか、ローカルか - そもそも問いが違う
Zebra のラベルを扱う人なら、誰もが経験する瞬間があります。コード上ではラベルは正しく見えるのに、印刷するとずれている、回転している、切れている、あるいはバーコードが読み取れない。よくある答えは、ツールの種類についての問いです。スピードと共同作業を重視するならオンラインビューアー、オフラインや制約の厳しいネットワークならデスクトップツール、コードの近くで作業する開発者ならローカルの開発用スクリプト。そこにセキュリティ、共同作業、デバッグの速さ、IT の制約、処理量といった基準をいくつか加えれば、結論が出ます。
それはそれで使える枠組みです。ビューアーを選ぶのであれば。
zplCloud は、同じ問いに別の答え方をします。「どのウィンドウでラベルを見るか」を比べるのではなく、「データイベントから物理的なラベルまでの経路全体が、どこで動くのか」を問います。そう問うと、二者択一は「両方とも」に変わります。zplCloud は、クラウドのビューアー、デスクトップツール、そしてローカルツールを同時に兼ねています。デザイン、レンダリング、ストリーミング、印刷が 1 つのコンテナーにまとまっていて、データとプリンターがある場所ならどこでも起動できるからです。問いはもはや「どの種類のツールか」ではなく、「パイプラインをどの環境にデプロイするか」です。
発想の転換を一覧で
| よくある分類 | zplCloud の答え |
|---|---|
| オンライン / クラウドビューアー | SaaS としての zplCloud.com - インストール不要。ブラウザーを開けば、ラベルをレンダリングして共有できます |
| デスクトップビューアー (オフライン、制約のある環境) | 同じコンテナーをオンプレミスで - 自社のデータセンター、自社のファイアウォール、完全な管理 |
| ローカルの開発ツール (コードの近く) | API + CLI + コードビュー - 自社の CI で、git パイプライン経由で、curl や zplcloud send でレンダリング |
3 つの製品ではありません。1 つのコードベースに、3 つの実行環境。 だからこそ、従来の判断ロジックをひっくり返せます。「自分の制約に合うのはどの種類のツールか」ではなく、「自分にはどんな制約があり、そのためにコンテナーをどのホストで動かすか」になるのです。
まずレンダリング、次に印刷 - 本物のエンジンで
ラベルプロジェクトで最もよくある間違いは、「レンダリングできた」を「正しく印刷できる」と同じだと考えることです。zplCloud は、プレビューと印刷に同じエンジンを使うことで、このギャップを埋めます。
- デザイナーは PNG/PDF/SVG/ZPL のプレビューを自前のバックエンドでレンダリングします。外部のレンダリングサービスも、実行時の外部 CDN 呼び出しもありません (当社にとっては、コンプライアンスと可用性の両面から譲れないルールです)。
- プレビューで見えているものは、後で ZPL (
^XA…^XZ) としてプリンターに送られるものとバイト単位で同じです。203 dpi のレンダリングは、あくまで 203 dpi のレンダリングです。バーコードも QR も TrueType フォントも、すべて同じソースから生成されます。 - エンジンはバッチ処理に対応した API として作られています:
POST /api/zpl、/api/render/png、/api/render/pdf、/api/export/console。1 つのデザインと N 件のレコードで、N 枚のラベル。ラベルごとにクリックする必要はありません。 - パフォーマンスは機能ではなく設計原則です。レンダリングはコンテナーのプロセス内で実行され、水平方向にスケールし (レプリカが増えれば、レンダリングのスループットも増えます)、同梱の perftest イメージ (
scripts/perftest.sh、モードzpl/pdf/png/zpl-api) を使って任意のステージに対して測定できます。本番稼働の後で祈るのではなく、稼働前に負荷テストを行えます。
これが「処理量と回帰テスト」への答えです。テンプレート、動的な項目、多数の SKU などで多くのラベルバリエーションをプログラムから生成する場合、必要なのはビューアーのウィンドウではなく、再現可能なレンダリング経路です。そしてここでは、それはスクリーンショットではなく API 呼び出しです。
ボタンではなくイベントで: データとイベントのストリーミング
ビューアーは、何よりもまず印刷前の品質ゲートです。しかし実際の物流では、印刷はたいていイベントの結果として行われます。受注イベント、ピッキング作業、MES からのシリアル番号、ERP の 1 行などです。
zplCloud は、イベントをそのまま印刷のトリガーに変えます。データを供給するメッセージバスは 7 種類です。
- Apache Kafka - トピックを購読すると、各メッセージがラベルデザインでレンダリングされ、プリンターに送られます。クラウドモード (たとえば Confluent や MSK など、インターネット上のブローカー) と、オンプレミスモード (ファイアウォールの内側にあるブローカーを CLI エージェントが消費します。ブローカーの認証情報がネットワークの外に出ることはありません) があります。
- Azure Service Bus、MQTT、AMQP 1.0、RabbitMQ、Amazon SQS、Google Pub/Sub - その他のあらゆる環境に、同じ仕組みで対応します。工場の現場で重要になるのは MQTT です。はかり、スキャナー、PLC がすでにブローカーにつながっているからです。
- データハブのソース - SQL Server、MongoDB、PostgreSQL、MySQL、MariaDB。CLI エージェントを通じたプッシュダウンで検索します。クエリはオンプレミスで実行され、結果だけがプラットフォームに届きます。到達可能なクラウドデータベースなら、エージェントを使わずに直接接続することもできます。
そして、多くのストリーミング連携の説明が曖昧になるのがここからです。正確に書いておきます。
- コンシューマーが確認応答するのは、印刷が成功した後だけです。印刷に失敗したら? Kafka ではオフセットがその場にとどまります。Service Bus ではメッセージを放棄 (abandon) して再配信させ、3 回配信された後にデッドレターへ移します。MQTT では単に確認応答を返さず、QoS 1 または 2 であればブローカーが再配信します。黙って読み飛ばすことも、無限の再試行ループに陥ることもありません。
- ブローカーのエラー (到達不能、認証の拒否、トピックの消失) は印刷エラーではありません。そのため指数バックオフ (5 秒から 60 秒) で再試行し、その状態は UI に表示されます。
- キープアライブが Link-OS プリンターをスタンバイから起こすため、休止の後の最初のラベルが復帰の待ち時間で遅れることはありません。
印刷されなかったラベルは、誰かが気付かなければならない物理的な事実です。それを確実にするのがこのセマンティクスであり、それこそがビューアーとパイプラインの違いです。
双方向に、バケットまで含めて
印刷ファイルは、すでにオブジェクトストレージに置かれていることがよくあります。配送業者のラベル、事前にレンダリングされたバッチ、保存義務のためのアーカイブなどです。ですから、バスのメッセージが ZPL そのものを運ぶ必要はありません。参照先を指すだけで済みます。
{ "schemaVersion": 1, "printer": "*", "zplRef": { "storage": "archive", "key": "orders/4711.zpl" } }
ファイルは印刷時に S3 または Azure Blob から取得されます。逆方向もあります。出力先は、印刷したすべてのラベルをバケットに書き戻し、7 種類のいずれかのバスにメッセージを送り、HMAC で署名した Webhook を送信します。各ステップは個別にオンにでき、いずれも印刷の後に実行されるため、バケットの応答が遅くてもラインが止まることはありません。
現場のための専用インターフェース: プリントビュー
同じコインのもう一方の面です。すべてのラベルがイベントから生まれるわけではありません。梱包台に、出荷場に、倉庫に人が立っていて、ターミナルではなくすぐに使えるものを必要としていることもよくあります。
プリントビューがまさにそれです。保存済みのデザインから、プラットフォームが専用のレスポンシブなフォームを生成し、専用のリンクを発行します。
https://print.zplcloud.com/d/{designKey}/{viewSlug}
これがワークフローにとって何を意味し、なぜ移動しながらでも使えるのかを見ていきます。
- モバイルファーストで PWA: どのビューも専用の
manifest.jsonとアプリアイコンを持っています。「ホーム画面に追加」すると、リンクが Android や iOS のアプリアイコンになり、タップするとフォームが直接開きます。アプリストアもインストールもドライバーも要らないアプリです。 - デザイナーではなくフォーム: 入力検証付きのテキスト項目、データソースから選べるドロップダウン、チェックボックス。作業者が入力するのは値であって、ZPL ではありません。編集できるのは、表示対象として印を付けた項目だけです。
- すべての項目の横にスキャナーボタン: カメラをタップして、バーコードや QR をそのまま項目に読み取れます。プリントビューが現実の運用に耐えられるかどうかを決めるのはこの機能です。梱包台でスマートフォンに 13 桁の EAN を打ち込む運用は長続きしません。
- ライブプレビュー: 入力するたびに PDF プレビューが再描画されます。ZPL を生成するのと同じサーバー側のエンジンを使っています。画面に見えているものが、そのままプリンターから出てきます。
- 共有リンクではなく投影: 値はサーバー側で検証され、ロックした項目はペイロードにすら含まれず、デザイン本体がブラウザーに届くことはありません。URL を持っている人が印刷できるのはこの 1 種類のラベルだけで、アカウントにはアクセスできません。
印刷先は Weblink プリンター、CLI エージェント上のリモートプリンター、またはローカルの印刷ダイアログ用の PDF です。ビューをデータハブのソースに紐付ければ、パラメーター化されたクエリが ERP から行を取り出してフォームに事前入力します。DHL 版ではさらに、受注 ID をもとに本物の郵便料金を購入し、切手を印刷します。
これで全範囲をカバーできます。イベントは印刷を自動でトリガーし、プリントビューは移動しながら働く人に安全で最小限のインターフェースを提供します。そしてどちらも、同じコンテナー内の同じレンダリングエンジンで動きます。
本題: git パイプラインでデプロイする
ここからが、「オンラインかデスクトップかローカルか」という問いに、まったく別の次元で答える部分です。つまりデプロイです。
ビューアーはインストールするものです。印刷プラットフォームはデプロイするものです。それも、開発者がすでにコードを出荷するのに使っているのと同じツール、git で。
手順は、毎回確実に成功するよう意図的に組み立てられています。
1. ブランチへの push が、そのままステージへのデプロイ。 dev はテストステージ (zplcloud_test) へ、main は本番 (zplcloud) へ。Azure パイプライン (backend/azure-pipelines-backend.yml、weblink/azure-pipelines-weblink.yml) は、ブランチへの push でトリガーされます。
2. リポジトリからの Docker ビルド - イメージは 1 つです (Angular のフロントエンドと ASP.NET Core の API。aspnet:10 azurelinux3 ベース、amd64、約 260 MB)。
3. ヘルスゲート付きのブルーグリーンデプロイ: 新しいコンテナーはホストポートなしで起動し、ヘルスチェック (/api/health) で検証されます。正常と確認されてから初めて古いコンテナーが削除されます。チェックに失敗した場合はロールバックされ、古いコンテナーは手付かずのまま動き続けます。ダウンタイムの時間帯も、祈るような気持ちも要りません。
4. ロールバックは、直前の正常な状態に戻すだけ。 イメージのタグはビルド ID なので、戻すには前のタグで docker run を 1 回実行するか、直前のコミットでパイプラインを再実行するだけです。
なぜ「常に成功する」のか。データベースのマイグレーションが追加的かつ冪等だからです (新しいテーブル、NULL 許容の新しい列、backend/scripts/*.sql にある IF NOT EXISTS スクリプト)。そのため、データベースはコードのデプロイより前にマイグレーションでき、古いコードも新しいコードも新しいスキーマで動作します。順序は常に同じです: バックアップ、マイグレーション、検証、EF の再生成、マージ、デプロイ、スモークテスト。
そして、すべてが 1 つのコンテナーに収まっているので、デプロイ先の環境は問いません。
- 自社のクラウドまたはデータセンター: 任意の Docker ホストや Kubernetes クラスターでコンテナーを実行します。
- オンプレミス: CLI エージェント (
zplcloud proxy --agent。これ自体も Docker コンテナーとして提供されています) が、TeamViewer と同じ方式でプラットフォームへ送信方向の接続を張ります。プリンターとブローカーはファイアウォールの内側にとどまり、受信接続も VPN も必要ありません。 - Weblink コンテナー: WebSocket リレー (mTLS クライアント証明書) を介した Zebra プリンター、TCP 9100。個別にデプロイでき、専用のパイプラインを持っています。
git パイプラインで自社の環境に展開するシステムは、git パイプラインで監査し、バージョン管理し、再現することもできます。ここで言う「スケールする」とは、まさにそういう意味です。レンダリングのスループットを上げるにはレプリカを増やし、拠点を増やすにはエージェントを増やし、安全性を高めるにはステージを増やします。
ドライバーはどこにも不要
ドライバーは、昔から障害が起きやすいポイントです。Windows のプリンタードライバー、ベンダーの DLL、OS への依存。zplCloud はそのすべてを回避します。ZPL はテキストだからです。
- 印刷経路は、生の TCP 9100 ストリーム、WebSocket、または USB です。プリンタードライバーは不要で、クライアントにベンダーのソフトウェアも要りません。
- プラットフォームに依存しない: クライアントはブラウザー (Angular)、エンジンは Linux コンテナー上の .NET です。Windows、macOS、Linux、タブレット、Raspberry Pi のどれでも構いません。ブラウザーかエージェントが動きさえすれば十分です。
- 実行時に外部 CDN に依存しない: すべてのアセット (Tailwind CSS、フォント、スキャナーの WASM) はセルフホストされています。インターネットに接続できないファイアウォールの内側でも、システムは完全に動作します。
つまり「オフライン / 制約の厳しい IT 環境」というシナリオを、デスクトップビューアーではなく、プラットフォームそのものをローカルで動かすことで解決するわけです。
開発者からメーカーまで、あらゆるワークフローに対応
「ツールの種類を制約に合わせる」代わりに、zplCloud はあらゆる規模に対応する 1 つのプラットフォームを提供します。その範囲は次のすべてに及びます。
- 開発者: コードビュー付きのデザイナー (C# コード生成、デザインとコードの往復)、API (
/api/zpl、/api/render/*、/api/export/console)、CLI (zplcloud send、proxy、firmware)。CI でプレビューをレンダリングし、git でデプロイする。他のサービスとまったく同じ流れです。 - 切手を使う小さなオフィス: DHL Internetmarke の郵便料金を直接購入し、Zebra で ZPL として印刷します。差出人と宛先を入力すると郵便料金のアカウントから引き落とされ、切手がプリンターから出てきます。郵便料金計器は必要ありません。
- デスクトッププリンター / 単独の作業場所: USB プリンターやネットワークプリンターをエージェント経由で接続し、ローカルでレンダリングして印刷します。それが要件であれば、クラウドなしでも可能です。
- 起業家や個人事業主: デザイン 1 つ、プリントビュー 1 つ、プリンター 1 台。フォームベースのプリントビューをモバイル PWA として使い、作業台や外出先で毎日 1 枚ずつラベルを印刷できます。
- 中小企業: チームアカウント、共有デザイン、データハブ (5 種類のデータベースとスプレッドシート)、3PL 向けのクライアントワークスペース、スコープ単位の権限。
- 物流: CSV から作る Amazon FBA ラベル (FNSKU、カートン、パレット)、受注 ID で検索できる DHL 専用のプリントビュー、バッチ実行。
- メーカー: ERP や MES のイベントを、Kafka、MQTT、Service Bus 経由で製造ラインのプリンターへ直接送ります。確認応答は印刷の後にだけ行われるので、ラベルが失われることはありません。
共通しているのは、常に同じプラットフォームであるということです。小さく始めても、後でツールのカテゴリーを乗り換える必要はありません。同じパイプラインの次のステージをオンにするだけです。
うまくいっている 3 つのサイン
ラベルの経路が本当に合っているかは、どうすればわかるでしょうか。3 つのシグナルがあります。
1. テスト印刷が減る - プレビューが印刷エンジンと同一なので、物理的なラベルより先にエラーが見つかるからです。
2. 開発と運用が同じ出力について話すようになる - ラベルはデザイン JSON とレンダリング済みの ZPL であり、スクリーンショットではなく、共有もバージョン管理もできる取り決めだからです。
3. テンプレートの変更で驚かされなくなる - レビューが再現可能で (同じレンダリング、同じエンジン、同じステージ)、パイプラインを通じたデプロイが追跡可能でロールバックもできる手順だからです。
ビューアーはミスを防ぎます。パイプラインは、イベントからラベルまでの経路を決定論的にします。そしてそれこそが、この分類全体が結局のところ言い表そうとしていた違いです。