エンジニアで「請求書は次の四半期までに PDF/A-3 と Factur-X にする必要がある」と言われたばかりで、唯一のコンテキストが法務の誰かがその言葉を発したことだけなら、この記事はあなた向けです。

標準化文書のトーンを切り捨て、これらのプロファイルが実際に何を制約するのか、なぜ政府が義務化を始めたのか、構造化データレンダラーから準拠 PDF を発行する最小の実用パイプラインを説明します。

PDF/A を 2 段落で

PDF は柔軟なフォーマットです。過度に柔軟 — 同じ PDF 仕様で JavaScript の埋め込み、50 年後に存在しないかもしれない外部リソースへのリンク、可逆暗号化によるコンテンツの暗号化、外部フォントの参照、その他百ものドキュメントを自己完結しなくする機能ができます。

PDF/A（「A」は Archival）は、50 年後に同一にレンダリングすることを妨げる部分を禁止する PDF のプロファイルです。高レベルルール:

すべてのフォントは埋め込まれている必要がある。
JavaScript なし、外部リンクなし、音声/動画なし。
暗号化なし。
すべての透明度はフラット化されているか、プロファイルバージョンでサポートされている必要がある。
色はデバイス独立（ICC プロファイル必須）。
すべてのコンテンツがファイル内 — ネットワークに依存する参照なし。

複数のバージョンがあり、それぞれ新しい機能への許容度を加えます:

プロファイル	年	追加内容
PDF/A-1b	2005	元のベースライン — 最も厳格
PDF/A-2b	2011	JPEG2000、透明度、レイヤーを許可
PDF/A-3b	2012	任意のファイル添付を許可（Factur-X の基盤）
PDF/A-4	2020	ISO 32000-2（PDF 2.0）ベース、簡略化された準拠レベル

「b」サフィックスは「basic」準拠（視覚的忠実度）を意味します。「u」（Unicode マップ済み）と「a」（アクセシビリティタグ付き）バリアントもありますが、ほとんどの請求書/領収書ワークフローでは「b」が欲しいものです。税務アーカイブは視覚的再現性を気にし、スクリーンリーダーセマンティクスは気にしません。

実用的な結論: レンダラーが PDF/A-3b をサポートすると言うなら、それは単一の設定フラグ（{ profile: "PDF/A-3b" } または同等）であるべきです。後で変換するために 2 つ目のツール（Ghostscript、qpdf、Acrobat）を実行する必要があるなら、それは ops に組み込むワークフローのギャップです。

なぜ PDF/A-3 が特に重要か: 電子インボイスのキャリアだから

PDF/A-3 は世界を変える機能を 1 つ追加しました: PDF 内の任意のファイル添付。

退屈に聞こえます。違います。それは今ヨーロッパで展開されている電子インボイス義務の技術的基盤全体です。

アーキテクチャ: 単一の PDF ファイルが両方

人間可読の請求書（視覚レイアウト、合計、ブランディング） — 人間が読む部分。
機械可読の XML 請求書 — 税務当局のソフトウェアがパースする部分。

両方が 1 つのファイル内、両方が同じ請求書を表し、PDF/A-3 ラッパーがファイルが何十年もパース可能であり続けることを保証します。

2 つの主な XML フォーマット:

Factur-X（フランス） — UN/CEFACT Cross Industry Invoice ベースの XML プロファイル
ZUGFeRD（ドイツ） — 実質的に Factur-X と同一（2 つの規格は 2018 年に技術的に統合）
EN 16931 — 両実装が準拠する欧州規範

ほとんどのワークフローでは、「Factur-X」と「ZUGFeRD」は互換的な用語です — スキーマを共有し、埋め込みメカニズムを共有し、一方に準拠する単一の PDF は通常もう一方にも準拠します。

何が必須か、どこで、いつ

2026 年 Q2/Q3 ロールアウトを計画するエンジニア向けの非網羅的スナップショット:

国	ステータス	必須フォーマット
ドイツ	B2B 受信は 2025-01-01 から義務付け; 発行は 2027 年から	EN 16931（ZUGFeRD / Factur-X / XRechnung）
フランス	大企業向け発行義務は 2026-09; 中小企業は 2027-09	Chorus Pro 経由 Factur-X
イタリア	B2B 義務は 2019 年から	SDI 経由 FatturaPA
ポーランド	義務は 2024-07 から	KSeF
スペイン	2026 年から義務（B2B）	FACe 経由 Facturae
ベルギー	2026-01 から義務	Peppol BIS 3

パターン: すべての EU 加盟国が EN 16931 準拠の電子請求の何らかのバリアントを 2024–2027 のタイムラインで実装しています。顧客がこれらの市場のいずれかで運営しているなら、PDF ジェネレーターは視覚的請求書とともに添付 XML を発行する必要があります。

日本のチーム向け: インボイス制度（2023 年 10 月開始の適格請求書等保存方式）は厳格な PDF/A-3 + XML を法的に要求していませんが、グローバル展開時のために同じ仕組みで EN 16931 互換のフォーマットを生成できることは強く推奨されます。Peppol も日本で 2024 年から推進されており、将来の B2B 取引で構造化された請求データの交換が一般化する見込みです。

最小の実用パイプライン

標準化文書が処方することは忘れましょう。エンジニアの視点はこうです:

   ┌─────────────────────┐
   │  請求書データ        │  (どこかにすでに JSON オブジェクト)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ EN 16931 XML をビルド │  (決定論的マッピング; 実証済みライブラリあり)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ PDF/A-3b をレンダー + │
   │ XML を添付            │  (gPdf への単一 API コール — または他では 2 ステップ)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  Chorus Pro / SDI / │
   │  Peppol などに引き渡し│
   └─────────────────────┘

非自明な 2 ステップ:

ステップ 1: XML をビルド

これは面倒ですが機械的です。請求書データ（行、税、合計、当事者）を EN 16931 XML フィールド名にマッピングします。複数の Java/Node/Python ライブラリがこれを行ってくれます — 言語で「factur-x library」を検索してください。XML スキーマ仕様を本当に楽しんでいるのでなければ、ゼロから書かないでください。

ステップ 2: PDF/A-3 をレンダーして XML を添付

ここでレンダラー選択が重要です。

組み込みサポートなし: 通常の PDF をレンダリングし、PDF/A-3 に変換し XML を埋め込みファイルとして添付するツールでポスト処理します。一般的なスタック: Ghostscript + qpdf、または Aspose のような有料ツール。2 つの追加ステップ、2 つの追加失敗ポイント、ポスト処理が視覚レイアウトをドリフトさせないことを確認する必要があります。

組み込みサポートあり（gPdf のアプローチ）: 1 コール。

curl -X POST https://gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "document": {
      "pages": [{ "size": "a4", "elements": [...] }]
    },
    "einvoice": {
      "format": "factur-x",
      "profile": "BASIC",
      "xml": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
    }
  }' \
  --output invoice-with-einvoice.pdf

これがパイプライン全体です。レンダラーは PDF/A-3b を発行し、XML を factur-x.xml（または zugferd-invoice.xml、両方ともすべての消費者に認識される）として添付し、バイトを返します。

よくある落とし穴

人々が苦い経験で学ぶこと:

「PDF/A」と「PDF/A 準拠フォントで」は同じではない

PDF/A-3 ファイルは、すべてのフォントが埋め込まれていることを使用するグリフの完全カバレッジで要求します。請求書に外国の顧客名があり、レンダラーが完全に埋め込み可能でないフォントにフォールバックすると、検証ツールはそれを拒否します。レンダラーが PDF/A モードで CJK フォントを埋め込むかどうかを確認してください — 多くはデフォルトで行いません。

視覚 + XML は一致する必要がある

XML 請求書と視覚請求書は同じ請求書を表すことになっています。税務監査人はそれらを diff します。コードが total: 119.00 で XML を発行し、視覚 PDF が 合計: 120.00 を表示する（丸めバグや古いテンプレートのため）と、ファイル上に税の不一致があります。両方を同じ source-of-truth から、理想的には同じコードパスで生成してください。

EN 16931 の「プロファイル」レベル

Factur-X はプロファイルがあります: MINIMUM、BASIC、EN 16931、EXTENDED。XML にどれだけのデータがあるかが異なります。顧客が具体的にもっと要求しない限り、BASIC を使用してください — 税コード、行項目、当事者、合計をカバーし、B2B 請求の ~95% に十分です。

提出前の検証

常に生成された PDF を PDF/A バリデータ（veraPDF がオープンソース標準）に対して検証し、XML を EN 16931 スキーマに対して送信前に検証してください。Chorus Pro / SDI への失敗した提出は規制当局でのあなたの信頼性メトリクスにカウントされます。

TL;DR

PDF/A は自己完結ドキュメントプロファイルです。PDF/A-3 はファイルの添付を可能にします。Factur-X / ZUGFeRD は「PDF/A-3 内に添付された EN 16931 XML」です。EU 全体の電子インボイス義務により、この組み合わせは 2025–2027 年の事実上の B2B 請求書フォーマットになります。

レンダラーが PDF/A-3 + Factur-X を単一の設定フラグとして扱うなら、移行は機械的です。そうでなければ、マルチステップ ops パイプラインを構築することになります。gPdf の /api/v1/e-invoice/render は単一フラグバージョンです — API リファレンスに完全なスキーマがあります、または Playground でサンプルレンダリングを試してください。