EC、倉庫、物流システムでは、地味ですがかなり現実的な問題があります。システムが生成するのは ZPL や EPL のようなサーマルラベル用言語なのに、開発者、テスター、サポート担当者が確認したいのは画像や PDF です。実機の Zebra プリンターにつなげば確認はできますが、CI、リモートデバッグ、バッチ検証には向いていません。

今日紹介する GOODBOY008/labelize は、この問題に向き合う小さなプロジェクトです。Rust で書かれたオープンソースのラベルレンダラーで、ZPL と EPL を解析し、ラベルを PNG または PDF に描画できます。CLI ツール、HTTP microservice、Rust library の三つの形で使えるのも特徴です。GitHub では現在およそ 27 stars。かなり小規模ですが、解いている課題は明確です。

プロジェクト概要

項目内容
リポジトリGOODBOY008/labelize
Stars約 27
Forks11
主な言語Rust
ライセンスMIT
Crates.io 最新バージョン0.5.0
作成日2026 年 3 月 18 日

何を解決するのか

ZPL は Zebra プリンターでよく使われるラベル言語で、EPL は Eltron 系のデバイスで使われてきた形式です。多くの業務システムは、これらのテキストを生成してプリンターへ送ります。しかし開発中には、もっと素朴な確認が必要になります。

  • 送り状の住所が正しく改行されているか。
  • バーコードが描画されているか。
  • 倉庫システムが生成した EPL テンプレートをプレビューできるか。
  • CI でラベル出力を golden-file テストできるか。
  • 外部 SaaS を使わず、社内ネットワーク内でプレビューしたい。

Labelize の価値はここにあります。プリンター用言語を、通常の開発ツールチェーンで扱いやすい PNG や PDF に変換します。ローカルで変換してもよいですし、HTTP サービスとして動かし、業務システムから ZPL/EPL を POST してレンダリング結果を受け取ることもできます。

三つの使い方

README では、使い方が三つの層に分かれています。

一つ目は CLI です。ローカルでのデバッグに向いています。

labelize convert label.zpl
labelize convert label.epl
labelize convert label.zpl -t pdf
labelize convert label.zpl --width 100 --height 62 --dpmm 12

二つ目は HTTP サービスです。

labelize serve --port 8080
curl -X POST http://localhost:8080/convert \
  -H "Content-Type: application/zpl" \
  -d '^XA^FO50,50^A0N,40,40^FDHello World^FS^XZ' \
  -o label.png

これは社内ツールと相性がよい使い方です。注文システム、WMS、テスト基盤がそれぞれ Rust crate を組み込む必要はなく、共通の変換サービスにラベル文字列を送れば済みます。

三つ目は Rust library としての利用です。Rust でサービスを書いている場合は、パーサーとレンダラーを直接呼び出し、メモリ buffer やファイルへ出力できます。

対応範囲

README によると、Labelize は現在 30 以上の ZPL コマンドをサポートしています。文字、フォント、図形、保存形式、ラベル制御、複数のバーコードが対象です。バーコードは Code 128、Code 39、EAN-13、Interleaved 2-of-5、PDF417、Aztec、DataMatrix、QR Code、MaxiCode などに対応しています。

EPL の対応範囲は ZPL より小さめですが、新規ラベル、文字、バーコード、線描画、参照点、印刷コマンドを扱えます。多くの基本的な送り状や倉庫ラベルであれば、試す価値のある範囲には入っているはずです。ただし複雑なテンプレートは、実データでの検証が必要です。

出力形式は、モノクロの 1-bit PNG と単一ページ PDF です。Helvetica Bold Condensed、DejaVu Sans Mono、ZPL GS fonts を内蔵しているため、デプロイ時のフォント依存も少なくできます。

オフライン描画が重要な理由

この分野の分かりやすい代替は、Labelary のようなオンラインサービスです。便利ではありますが、業務システムに組み込む場合はいくつか制約があります。

  • ラベルには宛名、住所、電話番号、注文番号などの機密情報が含まれます。
  • バッチテストや CI から外部サービスを呼ぶと、速度、安定性、レート制限を制御しづらくなります。
  • 社内ネットワークから外部サービスへ直接アクセスできない場合があります。
  • レンダリング結果を自動テストに組み込みたい場合、手動プレビューでは足りません。

Labelize は、きれいなラベルデザイナーを目指しているわけではありません。レンダリング能力を、組み込み可能で、自前運用でき、自動化しやすい基盤部品として提供するプロジェクトです。

テストと描画品質

README では、Labelary の参照レンダラーで生成した PNG を使った golden-file e2e テストと、差分レポートが紹介されています。現時点でプロジェクトが示している結果は、83 個のラベルサンプルに対して、perfect が 6、good が 27、minor が 39、moderate が 11、high が 0 です。

これらの数字は独立した第三者ベンチマークではなく、プロジェクト自身の回帰基準として見るのがよさそうです。それでも、単なる parser demo ではなく、サンプルセットを使って描画結果を継続的に比較していることは分かります。

README には性能比較も載っています。同じラベル群で、Labelize の平均描画時間は約 5 ms、Labelary API は約 388 ms とされています。これもプロジェクト文書上の結果なので、実際の業務ではラベルの複雑さ、マシン構成、サービス構成に合わせて測り直すべきです。

どこに置くとよいか

Labelize が合いそうな場所は、いくつかあります。

  • 開発プレビュー：ZPL/EPL の出力をローカルですぐ確認する。
  • CI 検証：重要なラベルテンプレートを画像化し、基準ファイルと比較する。
  • 社内 microservice：複数の業務システムへ共通のラベル変換 API を提供する。
  • サポート・運用ツール：プリンターなしで、顧客が受け取る送り状を確認する。
  • アーカイブ処理：ラベル文字列を PDF に変換し、注文記録と一緒に保存する。

すでにプリンターメーカーの SDK に強く依存しているシステムでは、すぐに全機能を置き換えるものではないかもしれません。それでも、「ラベル文字列を確実に見える形にしたい」という用途なら、導入コストはかなり低そうです。

注意点

プロジェクトはまだ新しく、star 数も多くありません。実運用に入れる前には、自分たちの実際のラベルサンプルで検証したほうがよいです。

  • よく使う ZPL/EPL コマンドがすべて対応しているか。
  • バーコード、日本語フォント、回転、反転、画像フィールドが期待通りか。
  • PDF と PNG のサイズ、DPI、余白が印刷フローと合うか。
  • HTTP サービスで大量変換したときのスループットとメモリ使用量が安定するか。
  • ライセンスと依存関係がチームのルールに合うか。

ラベル印刷では、見た目が数ミリずれるだけでスキャンや貼付位置に影響することがあります。まずはプレビュー、テスト、アーカイブ用途から使い始め、より重要な印刷経路へ入れられるかを段階的に評価するのが現実的です。

まとめ

Labelize が面白いのは、とても垂直で実務的な問題を、普通の開発者ツールとして扱える形にしているところです。ZPL/EPL レンダリングは毎日話題になるテーマではありませんが、物流、倉庫、EC、ハードウェア連携のシステムを触ったことがあるなら、この種のツールがどれだけ手作業と外部依存を減らせるかは想像しやすいはずです。

サーマルラベル、送り状テンプレート、倉庫印刷、関連する自動テストを扱っているなら、GOODBOY008/labelize は試す価値のあるプロジェクトです。

リポジトリ：https://github.com/GOODBOY008/labelize