アーカイブと電子請求書ワークフロー向け PDF/A-3b API
gPdf で PDF/A-3b 出力を生成し、PDF/A-3b がアーカイブ用プロファイルにとどまる場合と、電子請求書のラッパーになる場合の違いを明確にします。
/api/v1/pdf/render アーカイブワークフロー向けに PDF/A-3b 文書を生成し、PDF/A-3b が埋め込み Factur-X または ZUGFeRD の EN 16931 XML を含む必要がある場合は、電子請求書用エンドポイントを選択します。
この API が合う場合
- レンダリング済み文書に PDF/A-3b アーカイブプロファイルが必要な場合。
- 通常の PDF/A と電子請求書パッケージングの境界を説明する必要がある場合。
- コンプライアンスワークフローで、生成された PDF を veraPDF または別の参照エンジンで検証する場合。
- PDF/A-3b の検索意図を正しいエンドポイントへ案内する公開ページが必要な場合。
置き換えないもの
- 公開 API に記載されていない任意ファイル添付ワークフローが必要な場合。
- JSON Render 経由で Factur-X または ZUGFeRD 電子請求書が必要な場合。E-Invoice Render を使います。
- validator API が必要な場合。現在公開されている validator の入口は /validator/ ページです。
呼び出す endpoint
/api/v1/pdf/render
JSON Render がこのワークフローの標準パスです。
/api/v1/e-invoice/render
関連 API パス、テンプレート契約、または機能確認が必要な場合に使います。
最小リクエスト
POST /api/v1/pdf/render - レンダリング文書に PDF/A-3b 出力を要求。
{
"settings": {
"profile": "pdfa-3b"
},
"pages": [
{
"size": "a4",
"elements": [
{
"type": "text",
"x": 20,
"y": 24,
"content": "Archive copy",
"style": { "font_size": 16, "font_family": "NotoSans-Regular" }
}
]
}
]
}
gPdf が担当すること
- JSON Render の設定による PDF/A プロファイル選択。
- POST /api/v1/e-invoice/render を使う場合の PDF/A-3b 電子請求書パッケージング。
- 外部参照エンジンで検証できるレンダリング済み PDF 出力。
- アーカイブプロファイルと法的な電子請求書ワークフローの明確な分離。
自社システムが担当すること
- 保持ポリシーと PDF/A-3b が必要な理由。
- 業務データ、XML の意味づけ、外部コンプライアンスの受け入れ基準。
- 検証証跡、監査記録、レンダリング後の長期保存。
本番前チェックリスト
- 通常の PDF/A-3b 出力には JSON Render を選ぶ。
- 埋め込み EN 16931 XML が必要な場合は E-Invoice Render を選ぶ。
- PDF/A 出力を /validator/ または自社の veraPDF ワークフローで検証する。
- 要求したプロファイルとリクエスト ID を保存文書と一緒に記録する。
- 公開ドキュメントに記載がない限り、任意添付ファイル対応を主張しない。
対応範囲の境界
- PDF/A-3b はアーカイブプロファイルです。電子請求書パッケージングは、その上に成り立つ、より限定されたワークフローです。
- 任意の埋め込みファイルワークフローがすべて対応済みであるとは示唆しないでください。
- Factur-X と ZUGFeRD の PDF/A-3b パッケージには E-Invoice Render 経路が必要です。
PDF/A-3b はラッパーであり、ワークフロー全体ではない
PDF/A-3b は PDF のアーカイブプロファイルです。ハイブリッド電子請求書のラッパーとして使えるため重要ですが、プロファイルだけで文書が法的な電子請求書になるわけではありません。通常のアーカイブ文書でも、請求書 XML を埋め込まずに PDF/A-3b を使えます。
Factur-X と ZUGFeRD では、POST /api/v1/e-invoice/render を使います。そのエンドポイントが、電子請求書固有のメタデータと関連ファイルの接続を担います。
意図でエンドポイントを選ぶ
目的が「この文書を PDF/A-3b としてレンダリングする」なら JSON Render を使います。目的が「この請求書を EN 16931 CII XML 付きの Factur-X または ZUGFeRD としてパッケージする」なら E-Invoice Render を使います。この区別によりコードが明確になり、通常のアーカイブジョブが誤って電子請求書の前提を持つことを防げます。
外部で検証する
PDF/A はマーケティング上の主張ではなく、参照エンジンで検証すべきものです。公開 validator または自社の検証パイプラインを使い、レポートを監査証跡と一緒に保存してください。
FAQ
- PDF/A-3b は常に電子請求書ですか？
- いいえ。PDF/A-3b はアーカイブ用 PDF プロファイルです。Factur-X と ZUGFeRD の電子請求書では、埋め込み EN 16931 XML のラッパーとして PDF/A-3b を使います。
- PDF/A-3b はどのエンドポイントで作成しますか？
- 通常の PDF/A-3b には settings.profile を指定して POST /api/v1/pdf/render を使います。出力が Factur-X または ZUGFeRD 電子請求書である必要がある場合は POST /api/v1/e-invoice/render を使います。
- このページから任意ファイルを添付できますか？
- 公開 API ドキュメントにそのワークフローが記載されていない限り、任意添付ファイルへの対応を前提にしないでください。このページは、ドキュメント化された PDF/A-3b と電子請求書用途に焦点を当てています。
- PDF/A 出力はどう検証しますか？
- /validator/ または自社の参照エンジンパイプラインを使います。電子請求書では、PDF/A レイヤーと埋め込み XML レイヤーの両方を検証してください。