gPdf
ユースケース · 物流・配送

配送業者レベルの規模に対応する配送ラベルPDF

ベクター形式のGS1-128バーコード、ITF-14の梱包箱コード、SSCC-18のパレットIDを含む4×6インチ感熱配送ラベルを生成します。Edgeレンダリングにより、Black Fridayのピーク時でもp99を15 ms未満に保ちます。

解決する業務課題

配送業者に提出できる4×6インチ感熱配送ラベルを、注文JSONから直接生成します。ベクター形式のGS1-128、ITF-14、SSCC-18バーコードを含み、リクエストごとにヘッドレスブラウザーを起動する必要はありません。Zebra、SATO、Honeywellのプリンターで203 dpiでも安定してスキャンでき、リテールのピーク時にもp99を15 ms未満に抑える必要があります。

この用途に gPdf が合う理由

  • ベクター形式のCode 128、QR、DataMatrix、PDF417、GS1-128 / ITF-14 / SSCC-18: 203 dpi、300 dpi、600 dpiでサブピクセル精度を保ちます。
  • 0.1 mmの座標精度: 人が読める解釈行の全長について、配送業者が求める許容差に合わせやすくなります。
  • ページサイズ `label_4_6_in`、`label_4_8_in`、`label_a6` は、主要な感熱プリンター形式向けに事前設定されています。
  • 決定性: 同じ注文JSONはバイト単位で同一のPDFになります。倉庫で再印刷しても別物のラベルになりません。
  • Edgeレンダリング: 集荷前の同じ1分間に5万枚のラベルを印刷する状況でも、p50は3 ms、p99は8 msです。
  • ステートレス: ラベルはCloudflare Worker isolate内のメモリに約4 msだけ存在し、その後解放されます。文書ストアも、配送業者データが残る追加の漏えい面もありません。

サンプルリクエスト

POST /api/v1/pdf/render: 配送業者の追跡番号をCode 128バーコードで出力する最小構成の4×6インチ感熱ラベル。

{
  "pages": [{
    "size": "label_4_6_in",
    "elements": [
      {
        "type": "text",
        "x": 4, "y": 6,
        "content": "SHIP TO",
        "style": { "font_size": 8, "font_family": "NotoSans-Regular" }
      },
      {
        "type": "text",
        "x": 4, "y": 12,
        "content": "Acme Distribution Centre\n1200 Logistics Pkwy\nMemphis TN 38116",
        "style": { "font_size": 11, "font_family": "NotoSans-Regular" }
      },
      {
        "type": "barcode",
        "format": "code128",
        "content": "1Z999AA10123456784",
        "x": 4, "y": 60,
        "width": 92, "height": 22,
        "barcode_text": { "enabled": true, "position": "bottom" }
      }
    ]
  }]
}

コンプライアンスと適合性

  • GS1 General Specifications: モジュール幅（X-dimension）、クワイエットゾーン、全長が、203 dpiにおけるGS1 Section 5.4の許容差に合います。
  • 配送業者の要件: UPS、FedEx、DHL、USPSは、生成された出力をスキャン可能なラベルとして受け入れます。配送業者ごとの後処理は不要です。
  • 税務や監査の理由でラベルPDFを保存する必要がある場合は、`settings.profile = "pdfa-2b"` により PDF/A-2b でアーカイブできます。

配送ラベルというワークロードを一段落で見る

注文ごとに1つのPDFが作られ、そのPDFは感熱プリンターで一度印刷されます。処理が遅いときの失敗は「ページ表示が遅い」ではありません。「倉庫の集荷作業が、ラベル生成APIの待ち行列に詰まる」です。配送ラベルでは、p99レイテンシがそのままプロダクト指標になります。再印刷は日常的に起こるため、出力の決定性も重要です。バーコード品質も、ピクセルではなくGS1のX-dimension許容差で測られ、スキャナーが一度でラベルを読めるかどうかを左右します。

ヘッドレスブラウザーを使うPDFスタックは、この3つを同時に満たすのが苦手です。ピーク時にはコールドスタートのコストが積み上がり、小さな感熱ラベルではラスターバーコードの品質が落ち、Chromiumのバージョン差でフォントのラスタライズも揺れます。そのため「バイト単位で同一の再印刷」は実現しにくくなります。

gPdfがこの用途に合う理由

4×6インチの感熱ラベルは小さく（203 dpiで576 × 864ピクセル）、要素数も少なく（テキストブロック、1〜2個のバーコード、必要に応じて配送業者ロゴ）、しかも大量に生成されます。中規模の3PLでも1日に5万〜50万枚を生成します。gPdfはこの種の負荷を前提に設計されています。レンダラーは次のように動きます。

  1. レイアウトを一度だけコンパイルします。ページ座標、フォントカスケード、バーコード形状はリクエスト時に解決され、ブラウザーのレイアウトエンジンには渡しません。
  2. すべてのバーコードをベクター化します。モジュールをPDFストリームに直接描画するため、幅30 mmのGS1-128でも、203 dpiや600 dpiで鮮明に読めます。呼び出し側でDPIを意識したラスタライズ処理を書く必要はありません。
  3. NotoSans CJK + Latinを埋め込みます。同じ入力データで中国語の配送業者名も正しく描画でき、レンダリング用コンテナーにフォントを用意する必要がありません。

p99は、EU-WESTで上記サンプルを1,000回実行した参照ワークロードで8 msのままです。1つのisolateが1枚だけラベルを生成した場合でも、1万枚生成した後でも変わりません。

ボリュームとコストの計算

一般的な中規模3PLでは、1日あたり約5万枚、つまり月間約150万枚のラベルを扱います。**Basicプラン（月額5 USDで10万ページ、超過分は1ページあたり0.00005 USD）**では、次の計算になります。

150万ページ × 0.00005 USD       = 75.00 USDの超過料金
+ Basicプラン基本料金           =  5.00 USD
─────────────────────────────────────
合計                              = 80.00 USD/月

同じワークロードをPuppeteer-on-Lambdaで動かすと、一般的なLambda同時実行設定では月額200〜400 USD程度になります。ピーク時のコールドスタートによる運用コストは、この金額にはまだ含まれていません。

Black Friday: 具体例

ピーク時こそ、Edgeレンダリングの価値がもっともはっきり出る負荷です。ある小売業者がBlack Fridayの最初の1時間に通常の200%のラベル量に達したとします。60分で10万枚、平均で毎分1,700枚、バースト時は毎分5,000枚です。この負荷は、単一のCloudflare Workersリージョンプール内で完了し、コールドスタートの税金は発生しません。同じ負荷を平均トラフィックに合わせてサイズ調整したPuppeteerのウォームプールで処理すると、バースト時に追加起動されたコンテナーで1.5〜2.5秒のコールドスタートが発生し、倉庫の集荷カウンターはその遅延を1枚ごとに感じることになります。

次に読むべきもの

続けて読む