S3 や Azure Blob の ZPL を印刷し、印刷済みラベルをそこにアーカイブする

オブジェクトストレージは、印刷ファイルがすでに置かれている場所です。配送業者から届く配送ラベル、ERP で事前にレンダリングされたバッチ、保存義務のために残すアーカイブなどがそうです。このガイドでは両方向を扱います。バケットから ZPL を印刷する方向と、印刷した ZPL をバケットに書き戻す方向です。

内容はすべて Amazon S3 と Azure Blob Storage に当てはまります。S3 のインターフェースは標準化されているため、MinIO、Cloudflare R2、Wasabi、Backblaze B2、Ceph でも動作します。

ストレージ接続を作成する

データストリーミング → ストレージ → 接続を追加 で、接続を一度だけ作成します。重要なのは名前です。後でメッセージは、この名前で接続を指定します。

項目	S3	Azure Blob
バケット / コンテナー	バケット名	コンテナー名
リージョン	例: eu-central-1	使用しない
エンドポイント	AWS なら空欄、それ以外は例: https://minio.example.com	使用しない
パススタイル	MinIO と Ceph ではオンにする	使用しない
プレフィックス	任意。例: zpl/	任意
認証情報	AccessKey=…;SecretKey=…	接続文字列またはコンテナーの SAS URL

認証情報はプラットフォームのデータベースに AES で暗号化して保存されます。ブラウザーに送り返されることはなく、フォームには認証情報が登録済みであることだけが表示されます。S3 では認証情報を完全に省略することもできます。その場合は通常の AWS の認証情報チェーンが適用され、たとえば実行環境の IAM ロールが使われます。

テスト で、何かを印刷する前にバケットと権限が正しいことを確認できます。

方向 1: バケットの ZPL を印刷する

バスのメッセージには、完成した ZPL を載せることができます。ただし大きなファイルでは扱いにくくなります。多くのブローカーはメッセージサイズに上限を設けていますし、グラフィックを埋め込んだラベルはすぐに大きくなります。より良いのは、メッセージには参照先だけを載せる方法です。

{
  "schemaVersion": 1,
  "printer": "rp:7",
  "zplRef": { "storage": "archive", "key": "orders/4711.zpl" }
}

storage は接続の名前、key はその中のオブジェクトキーです。プレフィックスを設定している場合は先頭に付加されます。プレフィックスが zpl/ なら、上の例は zpl/orders/4711.zpl になります。

ファイルは受信時ではなく、印刷時に取得されます。名前が解決されるのは、ご自身または自社のスコープ内だけです。他者の接続には、たとえその名前を知っている人であっても、メッセージ経由でアクセスすることはできません。

方向 2: 印刷した ZPL を保存して通知する

逆方向は出力先と呼びます。印刷が成功した後に実行される 3 つのステップをまとめたもので、それぞれ個別にオンにします。

1. 保存 - 印刷した ZPL を、ファイルとしてストレージ接続に書き込みます。

2. 通知 - 7 種類のバスのいずれかにメッセージを送ります。

3. トリガー - 自社の URL に、HMAC-SHA256 で署名した HTTP POST を送ります。

ファイル名はテンプレートから生成されます。時刻はすべて UTC です。

テンプレート: {yyyy}/{MM}/{dd}/{subscription}/{id}.zpl
結果:         2026/09/09/Outbound/8f3c1e2a9b7d4c0e.zpl

使用できるのは {yyyy} {MM} {dd} {HH} {mm} {ss}、{subscription}、{printer}、{key} (バスメッセージのキー)、そしてラベルごとの一意の ID を表す {id} です。

通知と Webhook は、同じペイロードを受け取ります。

{
  "schemaVersion": 1,
  "event": "label.printed",
  "utc": "2026-09-09T12:34:56.7890000Z",
  "subscription": "Outbound",
  "printer": "rp:7",
  "storageKey": "zpl/2026/09/09/Outbound/8f3c1e2a.zpl",
  "storageUrl": "https://archive.s3.eu-central-1.amazonaws.com/zpl/2026/09/09/...",
  "zplBytes": 812,
  "zpl": null
}

ZPL 自体は、明示的に指定した場合にだけ含まれます。それ以外の場合、このフィールドは null で、URL だけで十分です。これによってメッセージが小さく保たれます。

活用できる場面

• 保存義務。 配送ラベルは記録文書です。自社のバケットに、プロバイダーのライフサイクルルールのもとでアーカイブすれば、別のシステムを用意せずにその義務を満たせます。
• 再レンダリングなしの再印刷。 一度印刷したものは、バイト単位で同一のまま残っています。再印刷は同じファイルを使うもので、新たなレンダリングではありません。
• 後続システムへの引き渡し。 Webhook が ERP に「カートン 12 のラベル貼付が完了した」ことを伝え、同時に記録へのリンクも渡します。

ストレージの障害で印刷が止まることはない

保存、通知、Webhook はすべて印刷の後に実行されます。バケットに一時的に到達できなくても、ラベルは通常どおり印刷され、エラーはテキストとしてサブスクリプションのログに記録されます。アーカイブが業務を止めるべきではないからです。

出力先は テスト でいつでも試せます。サンプルの ZPL を保存し、通知と Webhook を送信しますが、何も印刷しません。