PDFMonkeyは強いHTMLテンプレート製品です
PDFMonkeyは弱い競合ではありません。テンプレート、動的データ、自動化ツールからPDFを作りたいチームに向いた、完成度の高いホステッド製品です。現在のドキュメントでは、ビジュアルBuilderと、HTML、CSS、Liquidで書くCode Templatesという2つのテンプレート経路が説明されています。REST API、Webhook、ノーコード連携、文書保持、署名付きダウンロードURL、パスワード付きPDFも提供します。
そのため、HTMLテンプレートやノーコードの作業フローで考えるチームにはPDFMonkeyがよく合います。より鋭い問いは、本番PDFをChromiumで描画するHTML文書として扱うのか、それともPDFネイティブなJSON契約から生成する構造化業務文書として扱うのかです。
30秒で決める目安
- 既存のHTML/CSS、Liquidテンプレート、ノーコード自動化が中心ならPDFMonkey。
- 生成した各文書にダッシュボード上の記録と署名付きダウンロードURLが必要ならPDFMonkey。
- 請求書PDF、配送ラベル、領収書、明細書、チケット、電子インボイスを大量に生成するならgPdf。
- 標準では文書を保存せず、1回のAPI呼び出しでPDFバイト列を直接受け取りたいならgPdf。
- PDF/A、Factur-X/ZUGFeRD、ベクターバーコード、文書権限制御が必要ならgPdf。
- ホステッド環境の標準境界としてEU Parisを求めるならPDFMonkey。ただしgPdfのプライベートデプロイを検討範囲に入れる場合は別です。
本当のプロダクトの担い方: 文書アプリかPDFインフラか
PDFMonkeyは、APIを備えた文書生成アプリのように振る舞います。テンプレートを作り、文書レコードを作成し、サービスに生成させ、成功後に署名付きURLを取得します。ダッシュボードでの確認、保持、手動削除、共有リンク、自動化プラットフォームへの受け渡しなど、文書ライフサイクルそのものが重要な場合には便利です。
gPdfはPDF生成インフラのように振る舞います。JSON RenderとTemplate Renderは、成功時にPDFバイト列を直接返します。標準のセキュリティモデルでは文書内容を永続保存しません。リクエストJSONは生成中だけメモリ上にあり、出力PDFはレスポンスとしてストリームされ、リクエスト本文もPDFバイト列も標準では保存されません。
どちらのモデルも正当です。解いている運用上の問題が違います。
HTML/CSSはPDFMonkeyの自然な強みです
PDFMonkeyのCode TemplatesはHTML、CSS、Liquidを使います。これは多くのチームがすでに知っている技術です。請求書テンプレートがWebビューである、メールテンプレートがすでにHTMLである、運用チームがTailwindのクラスやWebフォントを再利用したい、といった場合はPDFMonkeyが自然です。
ビジュアルBuilderも非エンジニアには便利です。公式ドキュメントではドラッグ&ドロップ型で、Code Templatesより学習しやすいと説明されています。BuilderとCode TemplatesはいずれもChromiumでレンダリングされます。ヘッダー、本文、画像、表、繰り返しセクションを持つ素直な業務文書では、実用的な作成体験です。
PDFがWebページに近い場合、HTMLレンダリングは本当に優れています。豊かなCSSを持つマーケティング文書、既存フロントエンド部品を再利用するレポート、JavaScriptで生成するチャートを含む文書、CSSフレームワーク前提のテンプレート、ブラウザーモデルそのものが正本になっている複数ページHTMLなどです。gPdfはその作業フローを置き換えようとはしていません。
一方で、BuilderテンプレートとCode Templatesは別種別です。PDFMonkeyのドキュメントでは相互変換できないとされています。gPdfは別の道を取ります。ビジュアルエディターとAPIが同じJSON基盤を共有します。テンプレートが片方ではHTML、別の場所では別表現になるのではなく、視覚的にもAPI経由でも扱える同じ構造化文書契約になります。
構造化文書ではgPdfが前に出ます
請求書PDF、配送ラベル、領収書、明細書、チケット、証明書、電子インボイスPDFは、通常は任意のWebページではありません。構造化データ、正確な座標、ページサイズ、合計金額、バーコード、メタデータ、コンプライアンス規則の組み合わせです。
その用途では、gPdfのJSONネイティブなモデルのほうが直接的です。呼び出し側は毎回HTMLページ全体を組み立てる代わりに、template_id + data を /api/v1/template-render に送るか、完全な DocumentRequest を /api/v1/pdf/render に送れます。PDF層がページ形状、テキスト、表、画像、バーコード、メタデータ、セキュリティポリシー、出力を扱います。
AI支援の作業では、この違いがさらに大きくなります。AIエージェントは、ブラウザーで描画されるHTMLが正しく改ページされ、印刷され、バーコードとして読み取れるかを推測するより、スキーマに沿ったJSONを生成・修正するほうが安定します。
料金を正直に見る
PDFMonkeyの公開料金は2026-06-04に確認しました。公開プランはFreeからPremiumまであります。Freeは月20文書。Starterは月5ユーロで300文書。Proは月15ユーロで3,000文書。Pro+は月60ユーロで5,000文書。Premiumは月300ユーロで6万文書。Pro+とPremiumでは従量超過が利用でき、Premiumの超過分は追加文書1件あたり0.005ユーロと記載されています。
月10万件の1ページ文書では、VAT前の公開Premium料金でおよそ500ユーロです。6万文書分の300ユーロに、追加4万文書 × 0.005ユーロが加わります。
gPdf Basicは月5米ドルで10万ページ込みです。ここが中心的な違いです。PDFMonkeyは文書生成アプリとして価格を付け、gPdfはPDF生成をインフラのように価格付けします。
複数ページ文書では、必ず計算し直してください。平均PDFが N ページなら、gPdfの利用量はおおよそ documents × N ページです。一方、PDFMonkeyの公開モデルは文書数で数えます。1ページの請求書、ラベル、チケット、領収書ではgPdfの価格差が最も強く出ます。長いレポートや明細書では、実際のページ数に合わせた比較が必要です。
低ボリュームでは、どちらも十分安く、価格よりアーキテクチャのほうが重要になることがあります。大量のラベル、領収書、請求書、明細書では、料金モデル自体がアーキテクチャ判断になります。
データプライバシーと文書保持は同じではありません
PDFMonkeyのドキュメントは、文書が削除されるまで payload と meta フィールドを保存し、生成ファイルをprivate S3に保存し、有効期限の短い署名付きダウンロードURLを使うと明記しています。セキュリティ文書では、転送中の暗号化、暗号化されたデータベース列への動的データ保存、private S3バケット上の生成ファイル、AWS EU Parisリージョンでのインフラホスティングが説明されています。
これは信頼できるホステッド文書ライフサイクルのモデルです。ただし、ステートレスな生成経路とは別物です。
gPdfの標準生成経路は、文書内容を永続化しません。生成済みバイト列だけが必要で、保存、監査ログ、配信はすでに自社システムが担うなら、そのほうが境界はすっきりします。逆に、PDF生成製品に生成済み文書を保持させ、ダウンロードリンクを提供し、後から確認や削除をさせたいなら、PDFMonkeyのモデルのほうが合う場合があります。
障害モードとレイテンシ
どちらもホステッドAPIなので、どちらもベンダー依存を導入します。違いは実行の形です。
PDFMonkeyのAPIは文書を作成し、文書オブジェクトを返します。本番コードでは、通常ステータスをポーリングするか、Webhookで文書の準備完了を知ります。この設計は、非同期処理やダッシュボード中心の運用に合います。
gPdfのJSON RenderとTemplate Renderは、成功時に application/pdf を直接返します。これは「ユーザーが請求書をダウンロードする」ような同期フロー、倉庫業務中の配送ラベル生成、単純なリクエスト/レスポンス契約を望むバックエンドに向いています。
パスワード、権限、コンプライアンス
PDFMonkeyはシンプルなパスワード保護が強いです。文書メタデータに _password を渡すと、生成PDFをAES-256で暗号化できます。ドキュメントでは、全テンプレート、連携、プランで利用できると説明されています。
gPdfのセキュリティモデルは、よりポリシー寄りです。ProではAES-128の開封パスワード付き出力をサポートします。EnterpriseポリシーではAES-256、所有者パスワード、印刷、変更、コピー、注釈、フォーム入力、ページ組み立て、高品質印刷などの権限ビットをサポートします。調達やコンプライアンス担当にはより細かな制御を提供しますが、意図的にティア分けされており、PDF/Aや電子インボイスモードとは排他的です。
アーカイブや電子インボイスの作業フローでは、gPdfのほうが製品化された経路を明確に持っています。PDF/Aプロファイルと専用のFactur-X/ZUGFeRD PDF/A-3ルートです。このレビュー時点のPDFMonkey公開ドキュメントでは、同等の公開PDF/AまたはFactur-X/ZUGFeRD生成ルートは確認できませんでした。
移行の形
PDFMonkeyからgPdfへの移行は、LiquidをJSONへ1行ずつ置き換える作業ではありません。よりよい移行は、安定したレイアウト部分と変動する業務データ部分を切り分けることです。
- // Before: create a PDFMonkey document and poll or wait for a webhook
- const response = await fetch("https://api.pdfmonkey.io/api/v1/documents", {
- method: "POST",
- headers: {
- Authorization: "Bearer PDFMONKEY_SECRET_KEY",
- "Content-Type": "application/json"
- },
- body: JSON.stringify({
- document: {
- document_template_id: "YOUR-TEMPLATE-ID",
- status: "pending",
- payload: {
- invoice_number: "INV-2026-001",
- total: "$240.00"
- }
- }
- })
- });
- const document = await response.json();
- // Later: poll document_cards or receive a webhook, then download the signed URL.
+ // After: render through a shared gPdf template and receive PDF bytes
+ const response = await fetch("https://api.gpdf.com/api/v1/template-render", {
+ method: "POST",
+ headers: {
+ Authorization: `Bearer ${process.env.GPDF_TOKEN}`,
+ "Content-Type": "application/json"
+ },
+ body: JSON.stringify({
+ template_id: "invoice-v2",
+ data: [{
+ invoice_number: "INV-2026-001",
+ total: "$240.00"
+ }]
+ })
+ });
+ const pdfBytes = await response.arrayBuffer();重要な変化は構文ではありません。製品契約です。保存される文書ライフサイクルから、PDF生成インフラへの直接呼び出しに変わります。
最終判断
チームがすでにHTML/CSSテンプレートを持っており、それを維持したいならPDFMonkeyを選びます。ノーコード自動化が購買側の主な作業フローである場合もPDFMonkeyが合います。文書保持、ダッシュボード確認、署名付きダウンロードURL、EU Parisホスティングが第一級の要件ならPDFMonkeyです。また、低レベルのインフラ層ではなく、API付きの扱いやすい文書生成アプリを求める場合にも合います。
PDFが構造化されたバックエンドデータから生成され、呼び出し側がブラウザーレンダリングモデルなしで予測可能な出力を望むならgPdfを選びます。配送ラベル、請求書PDF、領収書、倉庫文書、明細書、チケット、証明書、電子インボイスPDFがgPdfの中心です。
出典メモ
PDFMonkeyの料金とドキュメントは、2026-06-04に公式の 料金ページ、Builder vs Code Templates、API PDF generation、security measures、data storage and retention、password protection ドキュメントで確認しました。競合の料金や機能ページは変更される可能性があるため、調達担当は購入判断の前にPDFMonkey公式ページを再確認してください。
関連するPDF生成シナリオ
次に読むべきページは文書の種類で変わります。構造化データからPDFを作る用途なら、まず JSON-to-PDF API と テンプレートPDF API を確認してください。具体的な業務では、請求書PDF生成、配送ラベル、バッチPDF生成 を比較できます。コンプライアンスが重い文書では、PDF/A API、Factur-X API、ZUGFeRD API を参照してください。
FAQ
gPdfはPDFMonkeyの代替になりますか？
APIで構造化PDFを生成することが目的なら、はい。HTML/CSSテンプレート、Builderテンプレート、ノーコード連携、文書保持、署名付きダウンロードURLが望ましい作業フローなら、PDFMonkeyは引き続き強い選択肢です。
HTMLテンプレートではPDFMonkeyのほうが向いていますか？
はい。正本がHTML/CSSなら、PDFMonkeyのCode Templatesのほうが自然です。gPdfは意図的にJSONネイティブであり、任意のHTMLをPDF化するコンバーターを目指していません。
月10万PDFではどちらが安いですか？
2026-06-04に確認した公開価格では、10万件の1ページPDFならgPdf Basicは月5米ドルで10万ページ込みです。PDFMonkey Premiumは月300ユーロで6万文書、PAYG有効時のPremium超過分は追加1文書あたり0.005ユーロと記載されています。平均ページ数が1ページを超える場合は、gPdfはページ数、PDFMonkeyは文書数で再計算してください。
PDFMonkeyは文書データを保存しますか？
はい。PDFMonkeyのドキュメントでは、文書が削除されるまで payload と meta フィールドを保存し、生成ファイルを削除またはTTL期限までprivate S3に保存すると説明されています。これはダッシュボードやダウンロードリンクの作業フローを支えます。gPdfの標準生成経路は、リクエスト本文やPDFバイト列を永続化しません。
gPdfはPDFMonkeyのようなノーコード連携に対応していますか？
PDFMonkeyと同じ形の製品機能としては対応していません。PDFMonkeyにはZapier、Make、n8n、Bubble、Workatoなどのノーコード連携があります。gPdfは主に、PDF生成をインフラとして扱いたいチーム向けのAPIとStudioの作業フローです。
電子インボイスにはどちらを使うべきですか？
APIからFactur-XまたはZUGFeRD PDF/A-3パッケージを生成する必要があるならgPdfを使います。HTMLから見た目としての請求書PDFを生成し、法定XML、保存、税務上のクリアランスは別システムで扱うならPDFMonkeyを使います。