オフィスプリンターできれいに印刷され、社内テストでは問題なくスキャンできたバーコードが、約8,000 km離れた 3PL の感熱プリンターでは失敗することがあります。その失敗パターンは、どのテスト環境にも出ません。CI では落ちず、Adobe Acrobat の QA でも失敗せず、4K モニターでは完璧に見えます。それでもサプライチェーンチームには、Amazon FBA 入庫で1点あたり0.25米ドル、Walmart で非準拠カートン1箱あたり5〜10米ドル、場合によっては受け入れドックでパレット丸ごと拒否される形で、静かにコストが発生します。バグの正体は、PDF 内のバーコードが実際のバーコード描画命令ではなく、バーコードの画像であることです。その画像が印刷工程でリサイズされる頃には、バー幅がスキャナーに必要な精度を失っています。

この記事は 3 種類の読者に向けています。誰でも最初のセクションを読めば、何が問題で、PDF ベンダーに何を聞くべきか分かります。QA と運用責任者には、印刷品質グレードがどう崩れるかを扱う 2 つ目のセクションが役立ちます。エンジニアには、PDF の中身が実際にどうなっていて、任意のファイルを 3 分で検証する方法を扱う 3 つ目のセクションが役立ちます。各層の最後に要点を置いているので、必要な情報を得たところで読むのを止められます。

1つの表で見る

質問	バーコードが描画命令（ベクター）の場合	バーコードが画像（ラスターPNG）の場合
PDF内のサイズ	約1 KB	約50〜300 KB
どのプリンター向けのリサイズにも耐えるか	はい。プリンターが数式から再描画します	いいえ。リサイズのたびにシャープさを失います
ISO 15416の印刷品質グレード	Aを維持	本番でAからC/Dへ落ちます
Walmart SSCC-18のチャージバックリスク	低い	高い
Amazon FBAの1点0.25米ドル貼り替え	まれ	悪いテンプレートでは日常的
切り替えの手間	パスを出力するレンダラーを選ぶ	エンジニアリングプロジェクト

スキャンで終わるワークフロー向けに PDF 生成サービスを評価するなら、最も診断力のある質問はこの表の中心にあります。描画命令を生成するのか、画像を生成するのか。 この記事の残りは、その質問を詳しく説明したものです。

全員向け：実際に何が起き、何にコストがかかるのか

ストーリー1 — 誰も読めなかったWalmartパレット

あるサプライヤーのプロダクトマネージャーが、新しい配送ラベルテンプレートを承認します。Adobe Acrobatでは見栄えがよく、オフィスプリンターでも問題なく印刷できます。最初の積み荷、50パレット、200カートンがWalmartの配送センターへ出荷されます。

受け入れドックでは、荷卸し委託チーム（lumper team） が各パレットの SSCC-18 をスキャンします。SSCC-18は、その物理パレットを一意に識別する18桁のシリアル番号です。50パレットのうち3つが、1回目または2回目のスキャンで読めません。荷卸しチームは受け入れ責任者にエスカレーションします。責任者は、サプライヤーが事前送信した電子マニフェストである EDI 856 ASN を開き、この積み荷に載っているはずの全SSCCを確認します。WMSから見ると、マニフェスト上の3つのSSCCは物理的には存在しているのに読めない状態です。これは不一致です。

その後に起きることは劇的ではなく、手順どおりです。EDI 824 application advice がサプライヤーへ返され、積み荷にフラグが立ちます。受け入れ側は、バーコード下の人間可読テキストから読めないSSCCを手入力しなければなりません。積み荷は受け入れ枠から遅れます。「ラベリング違反」によるコンプライアンスチャージバックがサプライヤーのアカウントに入ります。2026年時点では、多くの大手小売が非準拠カートン1箱あたり5〜10米ドル、場合によってはパレット単位で請求します。この積み荷では直接費は30〜60米ドル程度で、端数のように見えます。

本当のコストはその次です。ラベリング違反が繰り返されると、サプライヤーはバイヤーレビュー対象になり、将来の発注（PO）がより厳しいコンプライアンス監査を通るようになり、優先度の低いルーティング階層へ押し下げられます。四半期に数個の悪いパレットだけなら発動しません。しかし、PDF 生成基盤の設定ミスから生じる体系的な問題なら発動します。同じテンプレートが毎回出荷されるからです。

サプライヤー側のエンジニアリング事後分析には、何週間もかかることがあります。チームの誰も「PDF内のバーコード」に意味のある内部構造があるとは考えていないからです。単に「バーコード」だと思っています。実際にはPDFに300 dpiのPNGビットマップが入っていて、配送センターの感熱プリンターがそれを203 dpiへ再サンプリングし、バー幅が許容範囲を超えてにじんでいた。この発見は、最初のチャージバック集計が深掘りを強制して初めて出てくることが多いです。

ストーリー2 — Amazon FBA出荷でじわじわ効くチャージバック

こちらはより静かで、規模が大きく、見つけにくいケースです。

Fulfilled-by-Amazon の出品者が、ある SKU を5万点 FBA 入庫へ出荷します。各商品には、Amazon の SKU 別識別子である FNSKU がバーコードとして印刷されたラベルが貼られています。悪いテンプレートの典型例では、2〜5%の商品が FBA 倉庫に到着した時点でスキャン不能なバーコードになっています。バーがにじみ、入庫スキャンの1回目で読めないのです。Amazon は出荷を拒否しません。該当商品を手作業の貼り替えに回し、出品者へ貼り替え1点ごとの固定手数料を請求します。2026年時点で、その手数料は1点あたり0.25米ドルです。

5万点の出荷で失敗率が5%なら、直接チャージバックは625米ドルです。これを毎月行う出品者なら、年間7,500米ドルの純粋な無駄になります。しかもこれは明示的なチャージバック行だけです。さらに大きな隠れコストは、貼り替えられた商品はFBAへの受け入れが遅れ、buy boxで販売可能になるまで時間がかかり、プロモーション流入がずれ、ローンチサイクルの最悪のタイミングで売上が落ちることです。

出品者は、Amazon Seller Central の FBA inbound defect & reimbursement レポートを掘り下げて初めて気づくことがよくあります。それまでは、その行項目は「Amazon のよく分からない費用」として処理されます。実際の根本原因、つまり300 dpi の PNG を出すバーコード生成器で、ベクターバーコードを出していなかったことは、数か月前の上流にあり、この調査を経験した人以外はチャージバックレポートと結びつけません。

ストーリー3 — UPS / FedExの例外処理ライン

3つ目は直接チャージバックがありません。だからこそ、最も見えにくいケースです。

荷物がUPSまたはFedExの仕分け施設に入ると、コンベヤースキャナーがキャリア追跡バーコードをミリ秒単位で読み取ります。読み取りに失敗した場合、つまりバーが許容範囲を超えてにじみ、クワイエットゾーンが切られ、モジュレーショングレードがDまで落ちている場合でも、荷物は拒否されません。メインベルトから外され、例外処理ラインへ送られます。そこで人が人間可読テキストから追跡番号を入力します。荷物は12〜24時間遅れてネットワークへ戻ります。

キャリアは通常、これを直接チャージバックしません。コストは別の場所に現れます。

「発送済みと言われたのに、どこにあるのか」というカスタマーサポートチケットが増えます。
本来は時間どおりだった荷物でも、手作業経由になったことで顧客NPSが下がります。
時間がたつと、キャリアのアカウント監査でサプライヤーがラベリング上の懸念先として記録されます。将来の集荷はより厳しく見られ、契約更新は難しくなり、料率交渉も悪化します。

悪い荷物が1個なら、測定できるコストはありません。1か月に1万個、それが1年続くと、関係性のコストになります。

3つの話に共通すること

どの話でも、バグはデータ、デザイン、プリンター、スキャナーの中にありません。上流の1つの選択にあります。バーコードがプリンターへ画像として届いたのであって、描画命令として届いていないのです。画像は未知のプリンター向けにリサイズされても生き残れません。描画命令なら生き残ります。

なぜこれほど多いのか

難しいのは、ベクターバーコードを単体で作ることではありません。現在のバーコードライブラリは精密な SVG 出力を生成できます。難しいのは、そのベクターバーコードを埋め込み画像ではなく、ネイティブ PDF パス演算子として PDF へ埋め込むことです。SVG パスを PDF パス演算子へ変換するには、PDF 生成器とバーコードエンジンが一緒に設計されている必要があります。近道としては、バーコードライブラリを呼び、PNG 出力を受け取り、その PNG を Image XObject として埋め込むほうが、フレームワークレベルでははるかに簡単です。だから多くの PDF 生成基盤はその近道を選びます。倉庫から見ると、その1つのアーキテクチャ上の近道が感熱プリンターに届き、チャージバックを生みます。

ここまでが一般読者向けの要点です。ここで読むのを止めても、PDFベンダーに正しい質問をでき、エンジニアリングチームにこの記事末尾の3分検証を依頼するには十分です。

QAと運用責任者向け：グレードはどう崩れるのか

倉庫スキャナーがすでに使っている標準

受け入れドックで「良いバーコード」とは何かを定義するISO標準は2つあります。

ISO/IEC 15416 — 1Dリニアコード向け（Code 128、GS1-128、ITF-14、EAN、UPC）。
ISO/IEC 15415 — 2Dマトリクスコード向け（QR、DataMatrix、PDF417、Aztec）。

ラボ用の検証機は印刷されたシンボル全体で7つのパラメーターを測り、A（4.0） から F（0.0） までの総合グレードを出します。ANSIスケールは同じものを別の文字で表したものです。Walmart、Amazon、Target、Costco、大手キャリアのベンダーマニュアルはこれらの標準を参照しており、通常はグレードC以上を要求します。C未満は仕様外として扱われ、D未満は上で読んだチャージバックの仕組みを起動させます。

7つのパラメーターと、ラスターPNGがそれぞれに与える影響は次の通りです。

パラメーター	検証機が見るもの	ラスターPNGが悪化させる理由
Decodability	バー幅が仕様の許容範囲内か	再サンプリングで幅が仕様外へずれる。最初に落ちることが多い
Edge contrast	バーとスペースの遷移が鋭いか	リサイズ時のアンチエイリアスが灰色の遷移ピクセルを作る
Modulation	シンボル全体で明暗コントラストが均一か	プリントドライバーのディザリングで黒ベタがドットパターンになる
Defects	余計な点や抜けがないか	再サンプル由来のアーティファクトがラベル上の実インク点になる
Min reflectance	バーが十分に暗いか	再サンプリングで細いバー内部に抜けが残る
Symbol contrast	バーと背景の全体コントラストは十分か	非可逆PDF圧縮がコントラストを平坦化する
Quiet zone	シンボル周囲に必要な白い余白があるか	自動クロップ系ツールが食い込む

ベクターバーコードは、再サンプリングされる元ピクセルグリッドを持たないため、各パラメーターをA付近に保ちます。ラスターのバーコードは、パラメーターごとに半グレードほど落ちやすく、それが5つ、6つ積み上がると平均はCやDに着地します。データは同じです。符号化も同じです。画面上の見た目も同じです。違うのは印刷されたシンボルだけであり、検証機と倉庫スキャナーが測るのは、AcrobatでQAチームが見るものではなく印刷されたシンボルです。

プリンターが損傷を重ねる理由

PDF に埋め込まれたラスター PNG は、「印刷」をクリックしてからラベルがプリンターから出るまでに6つの再サンプリング段階を通ります。各段階で、おおよそ半グレードを失います。

ビューアーが画面用にラスタライズする。 AcrobatやPDFリーダーが、元PNGをモニターのピクセルグリッドへ補間します。見た目は問題ありません。これがQAを欺きます。
プリントドライバーが紙用にラスタライズする。 ドライバーは、元ピクセルをプリンターのグリッドに合わせるためにバイリニアまたはバイキュービック補間を選びます。Edge contrastが崩れます。
色変換。 CMYKまたはグレースケール変換を通る工程では、別の再サンプルが入り、多くの場合ハーフトーンディザリングも組み合わさります。Modulationが崩れます。
「印刷可能領域に合わせる」。 多くのドライバーは端のクリッピングを避けるため、デフォルトで99%のページスケーリングを行います。Decodabilityがわずかにずれます。
PDF/A flattening。 アーカイブPDFへの変換では、透明を含む領域が再ラスタライズされることがあります。さらに半グレード失われます。
サーマルヘッドのにじみ。 リボンと直接感熱メディアは、熱で2〜4 milにじみます。ベクターレンダラーは補正できますが、ラスターソースはできません。

コストを積み上げると、レンダラーをグレード A で出たバーコードが、スキャナーにはグレード C〜D で届きます。これが運用上の算術です。ベクターのパス演算子は段階2〜4を完全にスキップします。 再サンプリングする元ピクセルグリッドがないため、プリンター自身のラスタライザーが数学的な仕様からネイティブ DPI でバーを計算します。

QA責任者としてここで読むのを止めるなら、アクション項目は1つです。ISO 15416検証機を借ります（Cognex、Keyence、REA VeriCubeなど。相場は週1,000〜2,000米ドル）。最も量が多い小売フローから本番ラベルを50枚サンプリングします。平均グレードがB未満なら、ラスター式バーコードの問題を抱えています。

エンジニア向け：PDF の中身は実際どうなっているか

バーコードがページ上に存在する2つの方法

PDFが定義する可視オブジェクトは、実質的に2種類です。

path — 浮動小数点座標上の描画演算子の列です。re rectangle、f fill、m/l move/line、S strokeなどがあります。プリンター自身のラスタライザーが、デバイスのネイティブ解像度でこれを評価します。
Image XObject — ピクセル単位の幅と高さを持つ埋め込みビットマップです。PNG、JPEG、raw streamとして符号化されます。レンダラーは元ピクセルグリッドをデバイスピクセルグリッドへ対応付ける必要があり、必ず再サンプリングが発生します。

60本のバーを持つベクター Code 128 は、コンテンツストリーム内で約60個の re/f ペアになります。合計でも1 KB未満です。浮動小数点座標は0.001 mm精度です。ラスター Code 128 は、埋め込み PNG を指す1つの Do /Im0 演算子になり、300 dpi では通常270 KBほどです。

% Vector — what the renderer should produce
0 0 0.40 22 re f       % bar 1: 0.40mm wide, 22mm tall
0.99 0 0.40 22 re f    % bar 2 ...
1.97 0 0.40 22 re f    % ~60 lines like this, ~1 KB total

% Raster — what most stacks actually produce
348 0 0 84 0 0 cm      % scale a 348×84 pixel image to 92mm × 22mm
/Im0 Do                % insert the embedded PNG (~270 KB)

ベクターは元の仕様をプリンターまで保ちます。ラスターはバーを元 DPI で固定し、下流のすべてのプリンターに推測を強います。

任意のPDFを3分で検証する

poppler-utils と qpdf 以外に特別なツールは不要です。どちらもLinux、Mac、WSLで無料で使えます。確認は3つです。

1. 800%に拡大する。 ベクターバーコードはどの倍率でもシャープです。ラスターは大きくピクセル化し、元ピクセルを数えられるようになります。最速の非公式チェックです。

2. 埋め込み画像を一覧する。

$ pdfimages -list shipping-label.pdf
page  num  type    width  height color comp bpc enc      object  x-ppi  size
─────────────────────────────────────────────────────────────────────────────
   1    0  image     348      84  gray    1   1 ccitt     8 0     300   270K

幅広い1Dコードなら348 × 84、2Dなら正方形のように、バーコードの縦横比に一致する行が見えたら、そのバーコードはラスター画像です。ベクターバーコードはこの出力に一切出ません。

3. コンテンツストリームを調べる。

$ qpdf --qdf shipping-label.pdf - | grep -A2 -B2 ' re$'

60本のバーを持つベクター Code 128 なら、re/f 演算子の密な塊が出ます。バーコードがあるはずの場所に近い矩形がなく、1つの Do /Im0 演算子だけが見えるなら、それはラスター画像です。

プロ向け検証機（Cognex、Keyence、REA VeriCube）は5,000米ドル以上で、正式なISO 15416レポートを出します。多くのチームは、すでにチャージバックが発生して調査が始まるまでそこまで進みません。上の3つの無料チェックだけでも、自分たちが問題のどちら側にいるのかは分かります。

gPdfが行うこと

gPdf のバーコードレンダリングは、同じチームが作った姉妹プロダクト xBarcode に由来します。xBarcode は Rust 製のバーコードエンジンです。完全に自社開発であり、第三者ライブラリのラッパーではありません。gPdf レンダラーはこれを直接呼び出します。Code 128、GS1-128、QR、Data Matrix、PDF417、Aztec、ITF、EAN、UPC、その他30種類以上の対応形式のようなマトリクス型・リニア型シンボロジーについて、xBarcode がバー/セルパターンを計算し、gPdf がそれを浮動小数点座標の re/f 矩形演算子として PDF コンテンツストリームへ出力します。中間 PNG も、元 DPI も、ラスター面もありません。

重要な結果が2つあります。

エンジンは公開検証できます。 xBarcode は独立した無料オンラインツールとして xbarcode.ai でも動きます。誰でも送信データを貼り、SVG / PNG / EPS をダウンロードし、gPdf が何を生成するかを仮定する前にパス出力を検査できます。そのパス出力が gPdf の PDF に入ります。「ベクターバーコードを出します」という主張が通常耐えられない信頼性チェックです。
性能は測定できます。 xBarcode は標準的な 1D コードを単一コアで約4 µs（v1.5.4）で生成します。公開ベンチマークでは fast_qr の6倍、rxing の30倍高速です。gPdf の Cloudflare Workers ランタイムを通したエンドツーエンドでは、世界全体で約30 ms p50になります。

パス出力だけでなく、xBarcode は多くの第三者バーコードライブラリが完全に飛ばす GS1 層も扱います。750種類以上のアプリケーション識別子（AI） のレジストリ、strict / lenient 検証モード、自動 FNC1 区切り文字挿入、Application Identifier ごとの長さと文字集合チェックを備えます。(01)09504000059101(17)260315 の要素文字列は、チャージバック後ではなく、符号化前に仕様に照らして検証されます。

PDF/A-1b から PDF/A-4 までは構造上互換で、フラット化処理は不要です。決定性も厳密です。同じ DocumentRequest は、isolate やリリースをまたいでもバイト同一のコンテンツストリームを生成します。

それでもラスターで許容できる場合

実際に2つあります。

内部専用文書で、確実なスキャンが不要なもの。ラスターでも問題になりません。ただし、ベクターも無料なので、ラスターにしても何かを節約できるわけではありません。
マーケティング上の理由でバーコードが写真系ロゴやアートワークに固定されている場合。 この場合、スキャン信頼性は見落としではなく、意識的な技術負債になります。

それ以外、つまり配送ラベル、FNSKUラベル、給与明細、請求書明細のバーコード、バウチャーPDF、チケットQRコード、小売の取引商品ラベル、医薬品シリアライゼーションでは、下流の印刷工程に賭けを押し付けない唯一の選択がベクターです。

結論

スキャンで終わるワークフロー向けに PDF 生成基盤を選ぶとき、聞くべき質問は「QR / Code 128 / GS1-128 をサポートしていますか」ではありません。

バーコードを要求したとき、結果は描画命令ですか、それとも埋め込み画像ですか？

答えが画像なら、スキャン失敗率には下限が残ります。X 寸法の調整、フォント置換への配慮、プリンター保守をどれだけ重ねても、その下限は下がりません。Walmart のチャージバック、Amazon の0.25米ドル行項目、キャリアの例外処理遅延。これらはベンダーの問題でも倉庫の問題でもありません。レンダラーから出ていくバイトの性質です。

今日できる最も安い行動は、直近100件の出荷ラベル PDF に対して pdfimages -list を実行することです。バーコード形状の画像オブジェクトとして返ってくる行を数えてください。その数を、まだ告知されていないコンプライアンス監査の規模として扱うべきです。

xBarcode — the engine, on its own — gPdf のバーコードレンダリングは、独立した無料ツールとしても動く姉妹 Rust エンジン xBarcode によって支えられています。送信データを貼り、SVG をダウンロードし、パスを検査できます。gPdf の PDF に書き込まれるのと同じエンジン、同じ出力です。
JSONで0.1 mm精度のGS1-128バーコードを生成する — ラスターの失敗パターンを取り除いた後に続く、X 寸法の話です。
キャリアグレードの規模で配送ラベルPDFを生成する — 4×6インチ感熱ラベル上の Code 128 キャリア追跡ラベル向けの具体的なリクエスト形状です。
完全なバーコードリファレンス — 対応する全シンボロジー、サイズ指定フィールド、人間可読行向けの barcode_text ブロックです。

PDF のベクターバーコードとラスター画像：見落としがちなチャージバック