gPdf
ブログ

gPdf vs DocRaptor: Edge レンダリングがHTMLからPDFに勝る理由

DocRaptor はホスト型バックエンドで Prince を使い、HTML を PDF に変換します。gPdf は Cloudflare の Edge で構造化 JSON を直接レンダリングします。価格差は 18 倍です。これは一時的な客寄せ価格ではありません。

gPdf Engineering
#比較#docraptor#価格

DocRaptorは堅実なプロダクトです。HTMLからPDFへの変換で定評のある Prince をホスト型 REST API として提供し、リトライ、非同期ジョブ、読みやすいドキュメントも備えています。10年以上続いており、多くのチームにとっては「Prince を自社で運用したくない」場合の自然な選択肢です。

gPdfは性格の違うツールです。HTMLは一切受け取らず、構造化 JSON を受け取って Cloudflare の Edge で直接 PDF にレンダリングします。月10万ページ時点の定価差は 5米ドル/月（gPdf Basic）vs 89米ドル/月（DocRaptor Basic）、約18倍です。この差は初回限定のプロモーションではありません。構造から来ています。この記事では、その構造がなぜこの価格を生むのか、そしてそれぞれのツールが実際にどこで合うのかを説明します。

2 つのアーキテクチャを並べて

レイヤー DocRaptor (HTMLからPDF) gPdf (JSON-to-PDF)
入力 HTML + CSS（Prince の Paged Media 拡張を含む） DocumentRequest JSON
レンダラー Prince（コンパイル済み C++ エンジン） 自社 Rust エンジン、WebAssembly にコンパイル
ホスティング DocRaptor の中央集約サーバー（米国データセンターリージョン） Cloudflare Workers、すべての CF colo（300都市超）
コールドスタート サーバー側のワーカープール V8 isolate の起動、1 桁ミリ秒
レンダリングごとの計算 HTML/CSS のレイアウト処理、その後 Prince がページ分割 直接組版、レイアウト解釈処理なし
レンダリングごとの p50 約250–800 msの実時間（ネットワーク + レンダリング） 約3–8 ms（ネットワーク + レンダリング）
出力の決定性 高い（Prince は成熟） バイト単位で同一（同じ JSON → 同じバイト）

この2列を「汎用 HTML プリンター」と「用途を絞った文書レンダラー」の違いとして読めるなら、アーキテクチャ判断の本質はすでに見えています。レイテンシ、コスト、機能一覧でさえ、その1つの選択から下流に生まれます。

Prince 税

Princeは優れています。同時に、多くの請求書、領収書、配送ラベルの処理には不要な仕事も担っています。ユーザーが渡してくるかもしれない任意の HTML に対して、CSS Paged Media、つまり改ページルール、継続ヘッダー、脚注、相互参照、生成コンテンツボックスを実装する仕事です。

その汎用性には実行時コストがあります。任意の HTML をページ分割するには、エンジンは次の処理を行う必要があります。

  1. HTML をパース、検証
  2. CSS カスケードを解析、解決（場合によっては Prince 独自の拡張も含む）
  3. レンダーツリーを構築
  4. 複数回のレイアウト処理を実行（特にページをまたぐテーブル、バランス調整が必要な段組）
  5. ページ間の相互参照を解決
  6. PDF オブジェクトを発行

これらの処理の多くは、HTML を入力として受け入れるためのコストです。入力がすでに構造化データであるなら、そして実務ではほとんどの場合そうです。請求書は HTML で包む前から、どこかの時点で JSON オブジェクトとして存在しています。その処理を毎回のレンダリングで計算時間とレイテンシとして払い続けても、出力に価値は加わりません。

gPdfはレイアウト解釈の段階を完全にスキップします。JSON の DocumentRequest は、{ pages: [{ size, elements: [...] }] } のように、ページレイアウトを最初から構造として指定します。レンダラーは要素を組版し、テーブルやリストを決定的にページ分割し、PDFを出力します。解決すべき CSS カスケードも、計算すべき float レイアウトも、相互参照を解決するための追加処理もありません。

結果として、DocRaptorで約300 msかかる同じ1ページの請求書PDFが、gPdfでは約3 msで生成されます。gPdfが速いのは、より速い Prince を書いたからではありません。Prince が行う処理の多くを、そもそも行わないからです。

「安すぎて怪しい」は本物の調達異論です

これはすべての B2B 商談で出てくるので、正面から答えます。

「10万回のレンダリングで5米ドル/月。DocRaptorは89米ドル。Anvilは1 PDFあたり0.10米ドルなので、同じ量なら1万米ドル。何かおかしくないですか？」

この価格で提供できる正直な理由は 3 つあります。

1. ブラウザを動かしていない

DocRaptorは Prince インフラのコストを顧客全体でならします。gPdfがならすのは1つの Cloudflare Worker で、Workers Bundled では100万リクエストあたり約0.50米ドルです。JSON 形式の入力なら、gPdfのレンダラーが使う CPU は1回のレンダリングあたり約1.5 msです。50%のマージンを乗せても、1,000回あたり数セントの範囲に収まります。計算式そのものが価格です。

2. コントロールプレーンを動かしていない

非同期ジョブなし、コールバックなし、リトライキューなし、文書ストレージなし、プレビューリンク UI なし、マルチテナント DB なし。各レンダリングはステートレス関数への1回の往復で完結します。これにより、多くの「PDF API」企業が予算を割く運用領域がまるごとなくなります。同時に、その運用領域こそが彼らの価格を正当化している部分でもあります。

3. 赤字になる用途はモデル上ほぼ自然に外れる

文書が本当に HTML から PDF を必要とするなら、たとえば60ページの法律契約や複雑な CSS Grid レポートなら、最初の1時間で JSON モデルは合わないと分かり、結局 DocRaptor に向かいます。そうした用途を前提に、防御的な価格設定をする必要はありません。自然に振り分けられるからです。gPdfが価格を付ける必要があるのは、「構造化データから文書へ」という長く狭い裾野の用途で、そこでは1回あたりのレンダリングコストが本当に小さいのです。

合わせると、10万ページ5米ドルは赤字覚悟の客寄せではありません。実際の売上原価にマージンを足した価格です。ブラウザーを動かさない場合、基盤の計算コストが本当にそれだけ安いので、この価格を長く維持できます。

DocRaptor が正解の場合

自分たちに都合のよい比較だけを書くつもりはありません。DocRaptorが本当に勝つケースは次の通りです。

  • 入力が完全には制御できないHTMLである。 ユーザー生成レポート、サードパーティテンプレート、CMS 由来の Markdown を HTML にレンダリングしたもの。任意の入力に対して JSON への変換処理を書きたくない場合です。
  • PrinceがサポートするCSS Paged Media機能が必要。 章ごとの継続ヘッダー/フッター、複雑な脚注の再配置、名前付きページセレクター、生成された目次、索引などです。gPdfにも一般的な範囲には構造化された同等機能がありますが、@page :left セレクターを日常的に使うなら Prince が合います。
  • コンテンツチームがHTML/CSSを書き、JSONを書かない。 非エンジニアのチームに JSON で文書を組み立てる作業を強制しないでください。反発されます。
  • 非同期 + コールバック + 文書ストレージをサービスとして使いたい。 DocRaptorは生成済みPDFを保存し、配信用の署名付き URL を提供します。gPdfは厳密にステートレスで、結果の保存は自社コードが担います。

これらのどれかに当てはまるなら、DocRaptorのままで問題ありません。 それが正しいツールです。

gPdf が正解の場合

鏡像:

  • 入力がすでに構造化データである（DB 行、JSON API の送信データ、キューメッセージ）。
  • レイテンシが重要である。インタラクティブなチェックアウト、リアルタイムの配送ラベル印刷、オンデマンドの明細生成など。
  • テスト、監査証跡、電子インボイス保管のためにバイト単位で同一の再現性を重視している。
  • 月数千回以上のレンダリング量でコストに敏感である。
  • バーコード（GS1-128、QR、Data Matrix、PDF417、Aztec、MaxiCode）をサブミリ精度で必要としている。Prince は SVG バーコードを技術的にはサポートしますが、HTML/CSS 越しに全長0.1 mm精度でレンダリングするのは簡単ではありません。
  • PDF/A（1b/2b/3b/4）または Factur-X / ZUGFeRD 添付がコンプライアンスのために必要である。
  • JSONからHTML、さらにPDFへ進む処理ではなく、JSONから直接PDFへ進む処理にしたい。

移行は機械的、戦略的ではない

よくある懸念は「切り替えるなら、すべてのテンプレートを書き直す必要があるのでは」というものです。通常はそうではありません。ほとんどの HTML から PDF へのテンプレートは、20%がレイアウトで、それは一度 JSON 構造に置き換えれば済みます。残り80%はデータ差し込みで、レンダラーが何を受け取るかに関係なく同じです。

実用的な道筋:

  1. 移行する1つの文書タイプを選びます。最も量が多いものから始めます。節約幅が最大で、影響範囲は最小です。
  2. HTMLテンプレートのデータインターフェイス、つまり差し込む変数を取り出し、小さな mapToDocumentRequest(data) 関数を書きます。
  3. 出力が一致するまで Playground で反復します。
  4. 本番で A/B テストします。トラフィックの5%を2週間 gPdf へ流し、PDF の差分を確認し、請求額を比較します。
  5. 勘ではなくデータに基づいて、進めるか戻すかを決めます。

あるチームはこれを1スプリントで終え、翌月にPDF請求額の90%を削減しました。一方で、自分たちの用途が実は HTML から PDF のケースだったと気づき、DocRaptorに留まったチームもあります。gPdfとしては、それも正しい判断だと考えています。

TL;DR

DocRaptor gPdf
最適 任意コンテンツのHTMLからPDF 構造化文書のJSON-to-PDF
価格（月10万ページ） 89米ドル 5米ドル
レンダー p50 250–800 ms 3–8 ms
Edge 配備 ❌ 中央集約 ✅ 300+ Cloudflare colos
非同期 + ストレージ ✅ 含む ❌ 設計上ステートレス
PDF/A + Factur-X / ZUGFeRD ⚠️ Prince 拡張経由 ✅ 内蔵

文書がレンダラー向けに HTML をまとった構造化データであるなら、本来なくてもよい変換ステップに支払っています。Playground を試してください。請求書の1つを JSON で記述し、ブラウザー上で5 ms未満でレンダリングし、その差が直感と合うか確認できます。