gPdf
ブログ

2026年にPDF APIを選ぶなら：確認すべき8つの質問

PDF生成APIを選ぶための、ベンダーに依存しない判断フレームワーク。12か月後も満足できるかを実際に左右する8つの質問です。

gPdf Engineering
#decision-framework#evaluation

PDF生成APIを選ぶのは、着手するまでは簡単に見えます。市場には約40社のベンダーがあり、どのマーケティングページも似たことを語ります。本当のトレードオフが見えるのは、本番環境で数千件の文書を生成した後です。

これは、ベンダー評価にそのまま持ち込めるチェックリストです。特定のベンダーに寄せたものではありません。調達の途中や本番障害の振り返りで、実際にチームが直面した問題から引き出したものです。質問は8つ。すべてに明確な答えが返ってこないなら、まだ選定に必要な情報がそろっていません。

1. 入力形式は何ですか。HTML、JSON、それともテンプレートDSLですか

最も重要な質問です。答えによって、チームが実際に何を書くのか、そして午前2時に何をデバッグすることになるのかが決まります。

  • HTML/CSS（Puppeteer、DocRaptor、Prince）：なじみがあり、ほぼ無制限に柔軟です。その一方で、実行時コストが高く、出力を決定的にするのが難しくなります。
  • JSON / 構造化データ（gPdf）：生成コストが低く、同じ入力から同じバイト列を出しやすい方式です。ただし、自社のデータモデルから文書モデルへ変換する小さなマッパーを書く必要があります。
  • テンプレートDSL（PDFKit、ReportLab、Apache PDFBox）：完全に制御できますが、その分すべての責任も引き受けます。ページネーション、レイアウト、フォントの代替処理を自分たちで書くことになります。

絶対的に間違った答えがあるわけではありません。ただし、自分たちのチームに合わない答えはあります。3時間かかるページネーションの不具合をどのモデルで追いたいか、エンジニアに聞いてください。

2. コールドスタートのレイテンシはどれくらいですか。予測できますか

一部のPDF生成エンジンはマイクロ秒単位で起動します。WASMやネイティブバイナリ系がこれに当たります。一方、Chromium系のように秒単位で起動するものもあります。この差は、トラフィックが急増するまで表面化しません。

ベンダーに聞くべきことは次の通りです。

  • 「コールド状態のワーカーへの初回リクエストのp99レイテンシはいくつですか」
  • 「最後のリクエストからどれくらい経つと、ワーカーは再びコールド状態になりますか」
  • 「コールドスタートデータを含むステータスページを公開していますか」

最初の質問に数字で答えられないなら、悪い前提で見積もってください。

3. 1回の生成コストはどうモデル化されていますか

後から問題になりやすいモデルは、よくある順に3種類あります。

  • ページ単価（Anvilは1PDFあたり0.10米ドル、DocRaptorは10万ページ89米ドル）：予測しやすく、予算化しやすい。ただし規模が大きいと高い。
  • サブスクリプション階層 + 超過課金（gPdfは月5〜12米ドル + 超過1ページ0.00005米ドル）：どの量でも安いが、まだ試したことのない利用量は見積もりにくい。
  • 計算資源ベースの料金（Lambda上の自前Puppeteerなど）：コールドスタートとChromiumのメモリ使用量を含め、計算資源の請求を直接引き受ける。

契約前に、現在、5倍、50倍の3つのトラフィック水準で実際の請求額を計算してください。見出しの数字よりも、コスト曲線の形のほうが重要です。

4. 出力は決定的ですか

決定性、つまり同じ入力から同じバイト列が出ることは、必要になるまでは学術的な話に見えます。

必要になるのは次のような場合です。

  • CIでPDFをdiffし、意図しないテンプレート変更を検出する。
  • e-invoiceや税法の要件に従って文書を保持する。保存したPDFと再生成したPDFが一致する必要がある。
  • アーカイブの完全性を確認するためにPDFのハッシュを取る。
  • 法務レビュー向けに生成済みの出力をバージョン管理する。

ブラウザーを使う生成エンジン、つまりPuppeteerやChromium系は、パッチバージョンをまたぐと決定的ではありません。PrinceやgPdfのようなネイティブバイナリ系の生成エンジンは、通常は決定性を保ちやすい方式です。明示的に聞いてください。「生成エンジンの更新が配信されたら、出力バイトは変わりますか」

5. フォント、とくにCJKとRTLをどう扱いますか

PDFの世界で、これほど多くのチームを苦しめてきた質問はありません。

失敗の形はいつも似ています。自国市場でローンチしたときはフォントに問題がありません。6か月後、生成エンジンがグリフを持っていない文字体系の市場へ展開します。PDFに ▢▢▢▢ の箱が出始めます。顧客からエスカレーションが来ます。チームはDockerfileへフォントを追加するために2スプリントを費やします。

聞くべき質問は次の通りです。

  • 「追加設定なしでどの文字体系が同梱されていますか。Latin、CJK、Cyrillic、Devanagari、Arabic、Hebrewはありますか」
  • 「未知のグリフに遭遇したときはどうなりますか。代替フォントに落ちますか、それとも豆腐になりますか」
  • 「リクエスト時にカスタムフォントを追加できますか。それとも事前にデプロイする必要がありますか」
  • 「RTLテキストシェーピングに対応していますか」

良い答えは、「NotoSans CJKとNotoの代替フォントセットを埋め込み、未知のグリフはNoto Symbolsへ落ちます」のような具体的なものです。悪い答えは「はい、フォントに対応しています」です。

6. どのコンプライアンスプロファイルをサポートしていますか

もし事業が将来少しでも次に当てはまる可能性があるなら、確認が必要です。

  • EUで請求書を発行する（Factur-X / ZUGFeRD / EN 16931。2026年までにDE/FR/IT/PLで義務化）
  • SOX、HIPAA、GDPRの保持ルールの下で文書をアーカイブする（PDF/A）
  • 医療記録を提出する（XML添付付きPDF/A-3）
  • 電子署名を埋め込む（PAdES）

その場合は、PDF生成エンジンがどのコンプライアンスプロファイルをネイティブにサポートしているかを聞いてください。悪い答えは「後で別ツールを走らせて変換できます」です。それは、自社で担うことになる複数ステップの処理です。

良い答えは通常、1つのフラグのように見えます。たとえばgPdfなら、settings.profile: "pdfa-3b" と、standard: "factur_x" および埋め込みCII XMLを持つ settings.e_invoice ブロックです。組み込み対応は、後付けより運用負荷が劇的に小さくなります。

7. PDF生成はステートレスですか。生成後の文書はどこへ行きますか

関連する2つの質問です。

ステートレスなPDF生成とは、リクエストを受け取り、PDFを返し、何も保存しないことです。永続化は自分たちで扱います。S3でも、自社DBでも構いません。コンプライアンス要件が重い用途では、この形が望ましいです。PDF生成サービスが自社データの保管者にならないからです。

ステートフルなPDF生成とは、ベンダーがPDFを保存し、多くの場合CDN上に置き、署名付きURLを渡すことです。「顧客にリンクを送る」のような軽い業務では便利です。しかし規制対象の業務では問題になります。これまで生成した全文書のコピーを持つ第三者が増えるからです。

聞くべきことは次の通りです。

  • 「デフォルトでステートレスなPDF生成ですか」
  • 「保存する場合、文書は地理的にどこに保存されますか」
  • 「保持期間はどれくらいですか」
  • 「コンプライアンスレビュー向けに、ステートレスなPDF生成の書面保証をもらえますか」

答えが曖昧なら、9か月後にプライバシー/法務チームが問題にします。

8. PDF生成エンジンが失敗したら何が起きますか。どうやって知りますか

どのPDF生成エンジンも時々失敗します。見るべき点は次の通りです。

  • 失敗はどう表面化するか。 スタックトレース付きの500か、構造化エラー付きの4xxか、空のPDFか。
  • リトライ方針は何か。 冪等か。失敗した生成にも課金されるか。
  • ベンダーはどんな計測情報を提供するか。 ステータスページ、インシデント用Webhook、地域別のp50/p99ダッシュボードはあるか。
  • 合成監視プローブはあるか。 ベンダーは公開エンドポイントに対して自社監視を走らせているのか、それともあなたがチケットを出すのを待っているのか。

簡単なテストがあります。今すぐベンダーのステータスページを開いてください。存在しない、リアルタイムではない、詳細なしで「all systems operational」だけを表示しているなら、購入後に得られる信頼性の透明性もそのレベルです。

参考までに、gPdfは直近7日間の合成監視プローブデータとCloudflare Analyticsを含む /status を公開しています。

8つの質問に対するgPdfの答え

これはgPdfのブログなので、質問を都合よく作っていると思われるかもしれません。そこで、率直なスコアカードを置きます。

# 質問 gPdfの答え
1 入力形式 JSON DocumentRequest（構造化データ）
2 コールドスタート 5〜20 ms（V8 isolate、ブラウザーなし）
3 コストモデル 月額0/5/8/12米ドル。超過は1ページ0.00005米ドル
4 決定性 バイト同一。同じエンジンバージョン内で保証
5 フォント NotoSans CJK + Latin代替フォントを内蔵
6 コンプライアンス PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD添付を内蔵
7 ステートレス はい。契約上、どこにも文書を保存しません
8 失敗と可視性 7日トレンド付きの公開ステータスページ。構造化4xx/5xx。冪等

gPdfが負けるところ：質問1です。入力が本当にHTMLで、リファクタリングできない場合、たとえばユーザー生成レポートやレガシーテンプレートなら、DocRaptorやPrinceが正しい答えです。

TL;DR

「最高のPDF APIはどれか」と聞かないでください。8つの質問を聞き、答えを採点し、自分たちの実際の用途に合うベンダーを選んでください。9か月後に質問5で足をすくわれ、少し安い競合に調達で負けたチームも、同じことを言うはずです。

あなたの用途がgPdfの設計と合うなら、Playground で30秒で評価できます。合わないなら、喜んで適切なツールを案内します。HTML形状の問題ならたいていDocRaptor、セルフホストならPrince、入力が本当に任意のWebページならPuppeteerです。