C#が文書の正本ならQuestPDFは優れています
QuestPDFは敬意を払って比較すべき製品です。C#開発者向けの現代的なPDF生成ライブラリであり、Fluent API、強い型付け、広いドキュメント、プレビューとデバッグ用のCompanion App、そしてPDF SDKとしては非常に明快なライセンスモデルを持っています。
製品上の問いは「どちらがPDFを作れるか」ではありません。どちらも作れます。本当に役に立つ問いは、PDFの境界をどこに置くかです。レイアウト、バイト列、ライフサイクルを管理する.NETアプリケーションの内側に置くのか、それとも複数の製品と言語から呼ぶインフラサービスとして外に出すのかです。
すぐ決めるための目安
- C#が文書レイアウトの正本であり、アプリをオフラインで動かす必要がある、または既存PDFのローカル操作が必要ならQuestPDF。
- Node、Python、Go、.NET、ジョブ、地域ごとのシステムが同じHTTP APIで1つのPDF層を使うべきならgPdf。
- レイアウト変更をC#の再ビルドやサービス再デプロイではなく、テンプレート改訂として扱いたいならgPdf。
同じ文書領域、違う責任の持ち方
QuestPDFでは、アプリケーションがPDF生成を担います。これは本物の強みです。C#をドメインモデルの近くに置き、ローカルで実行・デバッグでき、実行時に外部APIを呼びません。
その代わり、本番で必要な面もチームが担います。
- レンダリング用のCPUとメモリ。
- 各デプロイ環境でのフォント検出とフォールバック。
- バーコードライブラリ連携と印刷QA。
- チャートやカスタムグラフィックス連携のためのネイティブパッケージとデプロイ上の考慮。
- 監視、リトライ、障害処理。
- ユーザーや倉庫がグローバルな場合の地域別デプロイ。
- 文書レイアウトが変わるたびのロールアウト。
gPdfでは、その面を外側に移します。アプリケーションは DocumentRequest または template_id + data を送り、サービスがレンダラー、エッジ実行環境、フォント、バーコードプリミティブ、PDF/A出力、電子インボイスパッケージを持ちます。すべてをC#で握りたい場合には魅力が下がりますが、PDF生成をどのスタックからも呼べる共通ユーティリティ層にしたい場合には魅力が増します。
ホステッドAPIが正直に答えるべき3つのトレードオフ
多くの「ライブラリ vs API」の説明は、.NETアーキテクトが最初に聞く3つの質問を飛ばします。公平な比較では、ここをはっきり書くべきです。
1. 文書データはどこへ行くのか。 この比較の多くは、氏名、住所、税ID、金額を含む請求書、明細書、電子インボイスの話です。QuestPDFでは、そのバイト列はプロセス内で作られ、外に出ません。公開gPdf APIでは送信データをレンダラーへ渡します。ただしレンダラーはゼロ保持です。リクエストJSONはCloudflare WorkersのV8 isolate内で生成中(通常約4 ms)だけ保持され、レスポンス完了時に解放されます。保存、ログ記録、サンプリング、学習利用はなく、運用ログはHTTPステータスと所要時間に限られます(セキュリティポリシー、DPA)。EU / グローバルのデータレジデンシー選択と、Enterpriseのオンプレ / プライベートデプロイにより、露出をさらに狭める、または閉じることができます。それでも、追加設定なしで生成をプロセス内に保てることは、金融や公共セクターのチームがQuestPDFを選ぶ正当で、ときには決定的な理由です。
2. 障害モード。 ライブラリには停止する第三者がいません。生成が失敗するなら、それは自分たちがすでに運用しているインフラ上の問題です。ホステッドAPIは、自分では制御できない可用性依存を追加します。gPdfを採用するなら、レンダー呼び出しを他の外部呼び出しと同じように扱うべきです。タイムアウト、リトライ、キュー、理想的には縮退時の代替経路です。文書生成が重要な同期経路にあるなら、「自分たちで運用する」ことと「ベンダーの稼働率に依存する」ことを比較してください。
3. レイテンシの形。 プロセス内生成はネットワークのない関数呼び出しです。ホステッド呼び出しはネットワーク往復です。バッチや非同期ジョブでは多くの場合ノイズです。ユーザーがクリックしてすぐPDFが必要な場合、プロセス内生成は構造的に速いです。gPdfのエッジPoPはホップを小さくしますが、それでもTLSと往復は残ります。QuestPDFはメソッド呼び出しです。
これらはgPdfを間違った選択にするものではありません。むしろ、gPdfが正しい場面を定義します。文書データをプロセス外へ出せる、ネットワークホップを許容できる、自分たちでレンダーフリートを運用するよりベンダーの稼働率に依存したい、というチームです。
ライセンスと料金モデル
QuestPDFの公開ライセンスページでは、年間総収入100万米ドルを超える企業にのみ商用ライセンスが必要だとされています。Communityティアは、対象となる個人、オープンソースプロジェクト、非営利団体、その収入閾値未満の企業にMIT条件で無料提供されます。同じ公開ページでは、2つの買い切り型商用ティアが掲載されています。Professionalは999米ドル + ローカル税で最大10名の開発者、Enterpriseは2,999米ドル + ローカル税で組織全体をカバーし、開発者数を数えません。どちらも1年分のアップデートと、無制限のプロジェクト、サーバー、デプロイを含み、受け取った最終バージョンについてライセンスは失効しません。
執行モデルもかなり軽いです。ライセンスは QuestPDF.Settings.License = LicenseType.Community; という1行で設定します。ライセンスキー、アクティベーションサーバーはなく、QuestPDF自身の設定ページによれば、ネットワーク呼び出しも機械外へのデータ送信もありません。利用資格のあるティアを自分で選ぶ信頼ベースのモデルです。文書単位のベンダー請求はなく、有料ライセンスは完全オフラインを含む任意の場所で動きます。
gPdfはレンダリングサービスそのものに価格を付けます。公開Basicプランは月5米ドルで10万ページから始まり、超過は1ページ0.00005米ドルからです。これはベンダー請求ですが、PDF生成を運用する別プロジェクトをなくします。レンダークラスター、NuGetデプロイ経路、地域別ウォームプール、アプリごとのフォントパッケージ、パッチ対象のPDFサービスが不要になります。
したがってコスト比較は「999米ドル vs 5米ドル」ではありません。ライセンスは小さな費用項目です。本当の比較は次の形です。
QuestPDF total = license (one-time) + your hosting + your engineer-time + on-call
gPdf total = page bill (infrastructure, fonts, scaling, and edge included)
公開ページ単価で見ると、gPdfの超過は1,000ページあたり0.05米ドル(100万ページで50米ドル、1,000万ページで500米ドル)です。2,999米ドルのEnterprise買い切りライセンスは、このページ請求だけと比べると約6,000万ページ付近で損益分岐します。ただしこの計算はQuestPDF側のホスティングとエンジニア月数を無視しています。自社がすでに安価にレンダー基盤を運用していない限り、実際の分岐点はさらにgPdf側へ寄ります。目安として、ライブラリを使うためにレンダーサービスを構築し人を張り付ける必要があるなら、ページ請求がライセンスを上回るずっと前にgPdfが総コストで勝ちやすいです。すでにそのインフラがあり、ほぼ追加コストなしに使えるなら、規模が大きくなるほど永久ライセンスが有利になります。
開発フロー: Fluent C#かテンプレートか
QuestPDFのFluent APIは、開発者が文書の形を管理する場合によく合います。強い型付け、メソッドチェーン、再利用可能なC#コンポーネント、IDEリファクタリング、Companion Appは、PDFがアプリケーションコードベースの一部である場合に自然です。
gPdfは別の作業フローに合います。開発者がJSONを直接書くこともできますが、本番システムは通常テンプレートへ寄っていきます。デザイナー、運用担当、エンジニアが gPdf Studio でレイアウトを調整します。承認済みレイアウトはテンプレートになり、バックエンドは template_id + data で生成を続けます。
この違いは文書が頻繁に変わる場合に重要です。配送業者のラベル、請求書、梱包明細、明細書のレイアウトが変わる場合、gPdfでは実行時を安定させたままテンプレートだけを動かせます。QuestPDFではレイアウトがC#コードなので、通常はコード変更、テスト、ビルド、デプロイ、ロールバック計画になります。
どちらの作業フローも万能ではありません。QuestPDFは文書をコードとして持ちたいC#開発者に最適化されています。gPdfは複数システムで共有する運用テンプレートに最適化されています。
コンプライアンス: どちらも本気です
これは、競合にコンプライアンス機能がないと言ってgPdfが勝つ比較ではありません。QuestPDFの現行公開資料には、PDF/A、PDF/UA-1、UN/CEFACT Cross Industry Invoice (CII) 標準に基づくZUGFeRD 2.1 / Factur-X例など、強い標準対応が掲載されています。その例では PdfA = true を設定し、factur-x.xml を AddAttachment() で埋め込み、XMPメタデータで文書を拡張し、veraPDF(PDF/A-3b)とMustang Project(ZUGFeRD)で結果を検証します。完全で誠実なレシピです。そして、そのパイプラインの各ステップは自社で担います。
gPdfは同じ標準をAPI契約としてパッケージします。JSON Renderは settings.profile を通じて6つのPDF/Aプロファイル(1b、2b、3b、4、2u、3u)とPDF/UA-1を公開し、Template Renderは同じ文書モデルを再利用します。E-Invoice Renderは専用の POST /api/v1/e-invoice/render エンドポイントとして、EN 16931 CII XMLを埋め込んだFactur-X / ZUGFeRD PDF/A-3bパッケージを生成します。QuestPDFのレシピとの差は、サービスが何を代行するかです。gPdfはPDF/A-3bと電子インボイスの検証をサーバー側で実行し、同期インラインまたはポーリング型オブジェクト配信に対応し、EUまたはグローバルのデータレジデンシーをリクエスト設定として提供します。検証を自社.NETパイプライン内に置きたいならQuestPDF。多くのシステムが共有するホステッド契約にしたいならgPdfです。
フォントとバーコード: 本当の比較は組み込み工数です
QuestPDFには有能なフォントモデルがあります。標準でLato 2.015を同梱し、システムフォントとデプロイディレクトリのフォントを自動読み込みし、FontManager でカスタムフォントを登録でき、フォールバックチェーンも使えます。これは開発者に制御を与えます。ただし同じドキュメントは、注意点も率直に書いています。「ほとんどのクラウドデプロイではフォントがほとんど、またはまったく使えないため、予期しない結果につながる可能性がある」とし、環境フォントを無効化して必要なものを明示的に登録することを推奨しています。つまり、コンテナやサーバーレス環境では、フォント環境を計画し、同梱し、テストする責任は自分たちにあります。欠けたグリフは置換文字になるか、CheckIfAllTextGlyphsAreAvailable を有効にしていれば例外になります。
gPdfはフォントをサービス側の責任範囲に含めます。レンダラーはラテン文字、ギリシャ文字、キリル文字、アラビア文字、ヘブライ文字、ベンガル文字、タミル文字、タイ文字、ベトナム語、等幅テキスト、CJK(Noto KR / JP / SCへのスクリプト別フォールバック)を含む複数スクリプト対応セットを持ちます。暗黙の自動選択でフォントを解決し、明示指定は prefer または strict で扱います。呼び出し側はCJKフォントを同梱したり、.NETアプリにNotoアセットを登録したり、デプロイ先ごとにフォールバックを調整したりしません。データを送り、レンダラーが全地域で同じフォント環境を持ちます。
バーコード比較も同じ形です。QuestPDFのバーコードドキュメントは、ZXing.NetでベクターSVGを生成する堅実な方法を示しています。同時に、ZXing.NetはQuestPDFパッケージに含まれず、NuGetから導入して接続すると明記しています。
// QuestPDF: add the separate ZXing.Net package, encode, render to SVG, embed.
// dotnet add package ZXing.Net
var writer = new ZXing.BarcodeWriterSvg {
Format = ZXing.BarcodeFormat.CODE_128,
Options = new ZXing.Common.EncodingOptions { Width = 320, Height = 80 }
};
string svg = writer.Write("INV-2026-001").Content;
container.Svg(svg);
// GS1-128 with Application Identifiers and FNC1 framing is hand-wired on top.
gPdfでは、バーコード生成はスキーマ上の第一級要素です。リクエストで形式、内容、物理サイズ、任意の人間可読行を宣言します。GS1形式もネイティブなので、アプリケーション識別子(AI)はそのまま content に入れます。
{
"type": "barcode",
"format": "gs1_128",
"content": "(01)00012345678905(21)SN12345",
"x": 12, "y": 60, "width": 80, "height": 18,
"barcode_text": { "enabled": true, "position": "bottom" }
}
1つの.NETアプリなら、ZXing.Netを導入して出力をテストするのは簡単かもしれません。多くのサービスとテンプレート、特にGS1-128、SSCC、GTIN、GS1 DataMatrix、GS1 QRと人間可読行を必要とする物流や小売の用途では、同じZXingの接続を各サービスで再実装するより、バーコード動作を文書API側に寄せるほうが保守しやすくなります。
QuestPDFが明確に勝つところ
オフライン実行と文書データを自社境界内に保てる点(上で説明済み)、さらにPDFコード自体が製品の一部でありレンダリング経路を調査、拡張、管理したい場合に加えて、QuestPDFにはgPdfの範囲外で明確に勝つ2つの領域があります。
- 既存PDFの操作。 QuestPDFは既存ファイルを読み込み、結合、ページ選択 / 並べ替え / 反転 / フィルター、オーバーレイ、添付、XMPメタデータ設定、Web配信用リニアライズ、40/128/256-bitの暗号化と復号を行えます。gPdfは自分が生成するPDFにパスワード保護と権限制御を適用できますが、作成していないファイルを開いたり、結合したり、復号したりはしません。
- チャート、地図、カスタムグラフィックス。 QuestPDFはScottPlot、LiveCharts、Microchartsなどのチャートライブラリと連携し、Mapbox地図を埋め込み、任意の2D描画向けにSkiaSharp Canvasを公開します。gPdfは
path要素(SVG path data)でベクターアートを描いたり、上流で生成したSVG / PNGチャートを埋め込んだりできますが、内蔵チャートエンジン、地図、Canvasはありません。データ駆動のチャートが文書の中心なら、その道具立てはQuestPDF側にあります。
gPdfが明確に勝つところ
gPdfが勝つのは、組織が各プロダクトチームに自前のPDFサービスを持たせたくない場合です。多言語スタック、グローバルな作業フロー、ERP / OMS / WMS / EC / フィンテック / チケットシステムが構造化データから文書を生成し、テンプレートがコードと独立して変わる環境です。そのような環境では、ローカルライブラリは最初は安く見えて、やがてフリートになります。言語ごとにサービス、地域ごとにデプロイ経路、コンテナごとにフォント計画、チームごとにバーコード回帰テストが生まれます。gPdfはそのフリートを1つのHTTP契約にします。
サーバーレスでは境界が最も明確です。AWS Lambda、Cloud Run、Azure Functions上でも、QuestPDFはアプリケーション内で実行されます。チームは.NETランタイム、フォント、ネイティブ依存、ピーク時のPDF処理に必要なCPU / メモリをパッケージし、コールドスタートを引き受けます。gPdfはすでにレンダーサービスです。関数は小さな template_id + data リクエストをエッジへPOSTし、PDFバイト列を受け取ります。温めるレンダラーも、地域ごとにスケールするワーカーもありません。
移行の形
QuestPDFからgPdfへの移行は、行単位の書き換えではありません。境界変更です。PDFを組み立てていたC#コードは、JSON文書リクエストまたは公開済みテンプレートになります。
Before / after — C#の文書生成呼び出しを1回のHTTP POSTへ寄せる例(クリックして展開)
- // Before: generate the PDF inside a .NET application.
- Document.Create(container =>
- {
- container.Page(page =>
- {
- page.Size(PageSizes.A4);
- page.Margin(30);
- page.Header().Text("Invoice").FontSize(24).SemiBold();
- page.Content().Column(column =>
- {
- column.Item().Text($"Invoice number: {invoice.Number}");
- column.Item().Text($"Total: {invoice.Total:C}");
- });
- });
- })
- .GeneratePdf("invoice.pdf");
+
+ // After: render through the shared gPdf template from C#.
+ using System.Net.Http.Headers;
+ using System.Net.Http.Json;
+
+ using var client = new HttpClient();
+ client.DefaultRequestHeaders.Authorization =
+ new AuthenticationHeaderValue("Bearer", key);
+
+ var response = await client.PostAsJsonAsync(
+ "https://api.gpdf.com/api/v1/template-render",
+ new {
+ template_id = "invoice-v2",
+ data = new {
+ invoice_number = invoice.Number,
+ total = invoice.Total,
+ currency = invoice.Currency
+ }
+ });
+
+ response.EnsureSuccessStatusCode();
+ byte[] pdfBytes = await response.Content.ReadAsByteArrayAsync();
この境界を動かした後、レイアウト変更はアプリケーションデプロイではなくテンプレート改訂になります。アプリケーションは引き続き業務データと作業フローの判断を担い、gPdfはレンダリングを担います。
料金と出典メモ
このページのQuestPDF情報は、2026-06-02に公式QuestPDFソースで確認しました。License and Pricing、License configuration、Features Overview、Companion App features、Barcodes、Font management、ZUGFeRD example です。料金や機能ページは変更される可能性があるため、調達担当は購入判断の前にベンダーページを再確認してください。QuestPDFおよび関連する商標は各所有者に帰属し、この比較はそれらの承認を受けたものではありません。
関連するPDF生成シナリオ
QuestPDFとgPdfを比較するチームは、C#でPDF生成を担い続けるべきか、複数言語から呼べるPDF生成APIに寄せるべきかを見ています。.NETアプリからHTTPで生成する前提なら JSON-to-PDF API と テンプレートPDF API を、請求書や物流ラベルなら 請求書PDF生成、配送ラベルAPI、GS1バーコードAPI を確認してください。PDF/A、ZUGFeRD、Factur-X が判断軸なら PDF/A API、ZUGFeRD API、Factur-X API も関連します。
FAQ
gPdfはQuestPDFを置き換えますか?
いいえ。gPdfが置き換えるのは、構造化業務文書向けのPDF生成サービスを自分たちで運用する必要です。PDFをアプリケーション内で生成すべき場合、QuestPDFは引き続き強いローカルC#ライブラリです。
QuestPDFは無料ですか?
QuestPDFの公開ライセンスページでは、Communityティアは対象となる個人、オープンソースプロジェクト、非営利団体、年間総収入100万米ドル未満の企業にMIT条件で無料とされています。その閾値を超える企業には永久商用ライセンスが必要です。Professionalは999米ドル + ローカル税で最大10名の開発者、Enterpriseは2,999米ドル + ローカル税で組織全体をカバーし、それぞれ1年分のアップデートを含みます。
gPdfはQuestPDFのようにチャートや地図を生成できますか?
内蔵エンジンとしてはできません。QuestPDFはScottPlot、LiveCharts、Microcharts、Mapbox地図、SkiaSharp Canvasを文書内に描画できます。gPdfは path 要素(SVG path dataを受け取る)や図形でベクターチャートを描くこと、また任意のチャートライブラリが作ったSVG / PNGを image として埋め込むことはできます。違いは、QuestPDFがチャートをプロセス内で計算・描画し、gPdfではチャート画像を作ってから配置する点です。データ駆動チャートや地図が文書の中心ならQuestPDFが適しています。
どちらが安いですか?
境界次第です。Community条件の対象である、またはすでにレンダー基盤を運用している.NETチームではQuestPDFが安くなることがあります。複数の製品や地域にまたがってPDFサービスを構築、ホスト、保守することが代替案なら、gPdfのほうが安くなることがあります。
gPdfは文書データを保存またはログ記録しますか?
いいえ。送信されたJSONと返却されるPDFは保存されません。各リクエストは単一のCloudflare Workers V8 isolate内で生成され、生成中のみメモリに保持されます。通常約4 msで、レスポンスストリーム完了時に解放されます。gPdfは DocumentRequest の内容を保持、ログ記録、サンプリング、学習利用しません。運用ログは30日間のHTTPステータスと所要時間のみで、リクエスト本文を含みません。セキュリティポリシー、プライバシーポリシー、DPA を参照してください。データを一切送信できないワークロードでは、オンプレ / プライベートデプロイにより自社境界内に保てます。
QuestPDFはインターネットなしで動きますか?
はい。QuestPDFのライセンス設定ページでは、ライセンスキーやアクティベーションサーバーはなく、計算はローカルで実行されると説明されています。これはQuestPDFを選ぶ最も明確な理由の1つです。
gPdfは任意のC# QuestPDFレイアウトを描画できますか?
いいえ。gPdfはC#レイアウトコードを実行しません。移行とは、文書の形をgPdf JSONリクエストまたは保存済みgPdfテンプレートへ変換することです。