物流ラベル向け gPdf vs iText

製品にPDF SDKが必要ならiTextは優れています

iTextは成熟したPDF SDKです。これは重要です。既存PDFの操作、文書署名、フォーム入力、ファイル結合、ニッチなPDF作業フロー、低レベルPDFオブジェクトに対するJava/.NETでの深い制御が必要なら、iTextは多くの場合正しい管理レベルです。

物流チームにとっての製品上の問いは別です。PDF SDKが必要なのか、それとも毎日確実に生成されるラベル、請求書、領収書、業務文書が必要なのかです。構造化文書生成では、ライブラリを買う、または導入することは最初の項目にすぎません。その周りにサービスを構築する必要があります。

同じ文書領域、違うプロダクトの担い方

iTextでは、アプリケーションがSDK連携を担います。通常はJavaまたは.NETサービス、フォント設定、バーコード設定、PDF/A設定、デプロイ、監視、キャパシティ計画、レンダー失敗時のオンコール経路を持つことになります。

gPdfでは、アプリケーションはJSONまたは template_id + data をHTTPSで送ります。レンダラー、エッジ展開、同梱フォント、バーコードプリミティブ、パスワード付き出力、メタデータ制御、PDF/Aプロファイル、Factur-X/ZUGFeRDパッケージ、ビジュアル設計フローがサービス側の責任範囲に含まれます。

向いている用途: 低レベルPDF制御か生成業務文書か

PDF層が製品の核である場合はiTextを選びます。リーガルテックのアーカイブ、電子署名プラットフォーム、文書管理システム、PDF修復/操作ツール、外部APIを呼べない組み込みJava/.NETシステムなどです。

製品がPDFエディターではない場合はgPdfを選びます。物流、EC、ERP、フィンテック、チケット、バックオフィスシステムは、多くの場合、構造化データから予測可能なPDFを必要とします。その場合、最良の製品は最もプログラム可能なSDKではなく、データから完成文書までの最短で信頼できる経路であることが多いです。

開発時間: SDK実装かAPIテンプレートか

「ゼロからZebra ZT411で実際にスキャンできる感熱ラベルまで」の典型的な測定です。

iTextの経路 — Java。以下は簡略化した例で、実際のコードにはビルド設定、フォント登録、スキャン率テストハーネス、それを実行するCIパイプラインが加わります。

PdfWriter writer = new PdfWriter("label.pdf");
PdfDocument pdf = new PdfDocument(writer);
PageSize labelSize = new PageSize(288, 432);     // 4×6 in @ 72 dpi
Document doc = new Document(pdf, labelSize);
// Address block, sender block, carton ID, service code…
// (15–25 more lines positioning text and configuring Barcode128 with
// GS1 Application Identifiers, fonts, FNC1 framing, then a JUnit test
// that loads the PDF and validates the barcode renders at 203 dpi)
Barcode128 code = new Barcode128(pdf);
code.setCode("(01)00012345678905(21)SN12345");
code.setCodeType(Barcode128.CODE128);
// … position, sizing, human-readable interpretation line …
doc.close();

mvn init からきれいにスキャンできるラベルまでの典型的な初回成功時間は 2〜5エンジニア日 です。

gPdfの経路 — 任意の言語。下の例はcurlです。

curl -X POST https://api.gpdf.com/api/v1/pdf/render \
  -H "Authorization: Bearer $GPDF_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "pages": [{
      "size": "label_4_6_in",
      "elements": [
        { "type": "text", "x": 4, "y": 12,
          "content": "Acme Distribution Centre\n1200 Logistics Pkwy\nMemphis TN 38116" },
        { "type": "barcode", "format": "gs1_128",
          "content": "(01)00012345678905(21)SN12345",
          "x": 4, "y": 60, "width": 92, "height": 22,
          "barcode_text": { "enabled": true, "position": "bottom" }
        }
      ]
    }]
  }' -o label.pdf

典型的な初回成功時間は、JSONサンプルを読み、同じZebra ZT411でPDFを印刷するところまで含めて 約5分 です。

この差はエンジニアの能力差ではありません。プロダクトがどこまで担うかの違いです。iTextではチームがラベルサービスを作ります。gPdfでは、そのラベルサービスが呼び出す製品になっています。

Studioとテンプレート変更

物流は、文書仕様が自社の外から変わる珍しい領域です。UPSがSSCCのエンコード規則を改訂する。SF Expressがチェックディジットを追加する。FedExが新しいHAZMATブロックレイアウトを公開する。どのレンダリングスタックを選んでも、その変更を吸収しなければなりません。

iTextの場合: 開発者が配送業者の告知を読み、Java/.NETコードを変更し、ユニットテストと結合テストを実行し、サービスをビルドし、ステージングへデプロイし、本番へ展開し、リージョンごとにロールします。ロールアウト中、倉庫では古い形式がまだ印刷される可能性があります。

gPdfの場合: コード内のテンプレートJSONを編集するか、gPdf Studio で要素を追加・ドラッグして視覚的にレイアウトを調整します。レンダラー自体は動きません。変わるのはテンプレートだけです。配送業者の変更がgPdfがすでにサポートするバーコード形式内に収まるなら、本番連携は template_id + data のままでいられます。

料金モデル: ライセンス経路かインフラ型ページ料金か

iTextの料金判断は、単なる「ライブラリ費用」ではありません。iTextはAGPL経路と商用ライセンス経路を公開しています。AGPL経路は互換性のあるオープンソース利用では無償になり得ますが、ソース公開義務を伴います。商用ライセンスはチームをそのAGPL制約から解放し、iTextはサブスクリプションやOEMの選択肢を見積もりベースまたはボリュームベースと説明しています。

gPdfは生成サービスに直接価格を付けます。公開価格はBasicで月5米ドル、10万ページから始まり、同じページ単価の考え方が料金ページと機械可読な料金エンドポイントで使われます。

物流チームがよく尋ねるボリュームでは次の通りです。

公開価格の列は簡単です。難しいのは、それ以外の請求です。ライセンス/コンプライアンス経路、サービス実行環境、HA構成、エンジニア時間、地域別デプロイ、配送業者仕様の保守、サポートです。

その完全なTCO内訳、つまりボリューム階層ごとのエンジニア月数、インフラ費用レンジ、SDKベースのサービスが量に応じて運用コストをどう吸収するかは、長文分析で扱っています。

→ 2026年 配送ラベルのTCO: iText vs Puppeteer vs gPdf Edge API

エッジ生成と運用コスト

iTextはプロセス内では非常に高速になり得ます。運用コストは、そのレンダラーがどこにあるかで決まります。欧州の倉庫が米国1リージョンのラベルサービスを呼ぶ場合、JVM内のラベルレンダーが速くても、ユーザー体感では遅くなります。複数リージョン展開で解決できますが、その場合チームは各リージョンのデプロイ、監視、キャパシティ、ロールアウトを担います。

gPdfは生成サービスをCloudflareのエッジへ移します。ラベルや請求書PDFのワークロードでは、価値はp50のレンダー時間だけではありません。各倉庫、配送業者連携、地域バックエンドのそばにPDFサービスを動かさなくてよいことです。

コンプライアンスと文書品質のコスト

iTextには深いPDF機能があり、gPdfが置き換えようとしない作業フローも含まれます。だからこそ、低レベル制御が必要なチームにとってiTextは強いのです。

業務文書生成では、gPdfがよくある出力要件を製品化します。CJKフォント、ベクターバーコード、PDF/Aプロファイル、Factur-X/ZUGFeRDパッケージ、メタデータ、パスワード付き出力、テンプレート駆動生成です。コスト比較には、そのうちどれだけを自社サービス内で組み立て、テストしたいのかを含めるべきです。

それでもiTextが正しい答えになる場合

競合が絶対に勝たないように見せる比較は、ただの宣伝です。iTextがより良い選択であり続ける場面があります。

• PDFを生成するだけでなく操作する。 署名、フォーム入力、分割、ページ単位編集。gPdfはJSONから新しいPDFを生成し、これらの作業フローには入りません。
• スタックがJava/.NET中心。 ほかのサービスがJVM上で動いており、外向きHTTP依存を追加することが後退に感じられるなら、iTextはプロセス内に保てます。
• エアギャップまたは厳格なオフライン環境で動く。 倉庫の現場や政府系デプロイでは、外向きHTTPSが正しい形ではない場合があります。iTextはJVMがある場所なら動きます。
• PDFツールが製品そのもの。 PDFベンダー、電子署名プラットフォーム、リーガルテックのアーカイブなら、SDKまで自社で管理するのが正しい制御レベルです。gPdfは、PDFそのものではなく物流、請求、商取引を製品にしているチーム向けです。
• gPdfが提供しないニッチなPDF仕様対応 が必要。XFAフォーム、高度な電子署名ハンドラー、証明プロファイルなどです。

「荷物に貼るスキャン可能なラベルが必要で、月100万個の荷物がある」なら、gPdfのほうが摩擦は小さいです。「Javaバックエンド内で既存の法務PDFを操作する必要がある」なら、iTextです。

関連するPDF生成シナリオ

iTextとgPdfを比較するチームは、Java/.NETのPDF SDKを自社で持つべきか、PDF生成をAPI化すべきかを見ています。物流ラベルなら 配送ラベルAPI と GS1バーコードAPI を、請求・業務文書なら 請求書PDF生成 と JSON-to-PDF API を確認してください。アーカイブや電子インボイスが絡む場合は PDF/A API、Factur-X API、ZUGFeRD API も判断材料になります。

FAQ

iTextは無料ですか？

iTextには、互換性のあるオープンソース利用向けのAGPL経路と、AGPL義務に従えない、または従いたくないチーム向けの商用ライセンスがあります。

gPdfはiTextを置き換えますか？

いいえ。gPdfは構造化された新規文書向けのPDF生成サービスです。深いPDF操作、署名、フォーム入力、分割、低レベルSDK制御ではiTextのほうが強いままです。

iTextの料金が見積もりベースなのに、なぜ価格を比較するのですか？

購入側にはTCOモデルが必要だからです。比較にはSDKの費用項目だけでなく、ライセンス/コンプライアンス経路、インフラ、エンジニア時間、サポート、地域別運用を含めるべきです。

移行の形

iTextからgPdfへラベルレンダリングを移す場合、差分はおおよそ次の形です。

- // Before: a Java label-rendering service
- PdfWriter writer = new PdfWriter(out);
- PdfDocument pdf = new PdfDocument(writer);
- Document doc = new Document(pdf, new PageSize(288, 432));
- // 20–40 lines wiring fonts, positions, Barcode128 with GS1 AIs
- doc.close();
+ // After: HTTPS POST the structured DocumentRequest from any language
+ const res = await fetch('https://api.gpdf.com/api/v1/pdf/render', {
+   method: 'POST',
+   headers: { Authorization: `Bearer ${KEY}`, 'Content-Type': 'application/json' },
+   body: JSON.stringify(labelDocumentRequest),
+ });
+ const pdf = Buffer.from(await res.arrayBuffer());

切り替え後、Javaのラベルサービスは、注文処理をすでに担っている任意の言語からの1回の fetch 呼び出しに縮小します。ラベル経路からJVMが消え、配送業者仕様の変更はデプロイイベントではなくなり、ラベル生成のOOMでオンコールが呼ばれることもなくなります。

関連ページ

• 2026年 配送ラベルのTCO: iText vs Puppeteer vs gPdf Edge API — コスト計算、エンジニア月数、インフラレンジの長文分析。
• 配送ラベルAPI — 4×6インチ感熱ラベル、配送業者バーコード、ピーク時の生成量を扱うページ。
• JSON Render APIリファレンス — エンドポイント、リクエスト形状、セキュリティモデル。
• JSONで0.1 mm精度のGS1-128バーコードを生成する — バーコード形状の詳細解説。