gPdf
ブログ

エンジニア向け PDF/A と Factur-X 解説（法律用語抜き）

PDF/A プロファイルが実際に何を制約するのか、2026 年に EU で Factur-X がなぜ必須になるのか、JSON からPDFを生成する仕組みで準拠 PDF を出すための最小実用フローを整理します。

gPdf Engineering
#pdf-a#factur-x#zugferd#電子インボイス#コンプライアンス

エンジニアとして「次の四半期までに請求書を PDF/A-3 + Factur-X にする必要がある」と言われ、背景として知っているのは法務部門からその言葉が出たことだけ、という状態なら、この記事はあなた向けです。

標準文書の硬い言い回しを外して、これらのプロファイルが実際に何を制約するのか、なぜ各国政府が義務化を始めたのか、構造化データからPDFを生成する仕組みで準拠 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 conformance（視覚的な忠実度）を意味します。「u」（Unicode マップ済み）と「a」（アクセシビリティタグ付き）に相当する種類もあります。多くの請求書/領収書業務では、必要になるのは「b」です。税務アーカイブで重視されるのは視覚的な再現性であり、スクリーンリーダー向けの意味づけではないからです。

実務上の要点: PDF生成側が PDF/A-3b をサポートしていると言うなら、それは単一の設定フラグ（{ profile: "PDF/A-3b" } または同等）であるべきです。後処理のために Ghostscript、qpdf、Acrobat のような 2 つ目のツールを走らせる必要があるなら、それは運用に織り込むべき処理フロー上のギャップです。

PDF/A-3 が特に重要な理由：電子インボイスの入れ物になる

PDF/A-3 は、世界を変えることになった 1 つの機能を追加しました。PDF 内に任意のファイルを添付できることです。

退屈に聞こえるかもしれません。そうではありません。これは、現在ヨーロッパで展開されている電子インボイス義務化の技術的な土台そのものです。

アーキテクチャはこうです。1 つの PDF ファイルが、両方を持ちます。

  1. 人間が読める請求書（視覚レイアウト、合計、ブランド表示）— 人間が読む部分。
  2. 機械が読める XML 請求書 — 税務当局のソフトウェアが解析する部分。

両方が 1 つのファイル内にあり、両方が同じ請求書を表し、PDF/A-3 ラッパーがそのファイルを何十年後も解析可能に保ちます。

主な XML 形式と基準は次のとおりです。

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

多くの実務では、「Factur-X」と「ZUGFeRD」はほぼ置き換え可能な用語です。スキーマを共有し、埋め込み方式を共有し、一方に準拠する 1 つの PDF は、通常もう一方にも準拠します。

何が、どこで、いつ必須になるか

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

国 状況 必須フォーマット
ドイツ 請求書の受領は 2025-01-01 から B2B 義務化。2027 年から発行も対象 EN 16931 (Factur-X / ZUGFeRD / XRechnung)
フランス 大企業の発行義務は 2026-09、中小企業は 2027-09 Chorus Pro 経由の Factur-X
イタリア 2019 年から B2B 義務化 SDI 経由の FatturaPA
ポーランド 2024-07 から義務化 KSeF
スペイン 2026 年から義務化（B2B） FACe 経由の Facturae
ベルギー 2026-01 から義務化 Peppol BIS 3

大きな流れとして、EU 加盟国はそれぞれ、EN 16931 に準拠した電子インボイスを 2024〜2027 年の時間軸で実装しています。顧客がこれらの市場のいずれかで事業を行っているなら、PDF生成側は視覚的な請求書と一緒に XML を添付して出力する必要があります。

最小実用フロー

標準文書が何を規定しているかはいったん脇に置きます。エンジニア視点ではこうです。

   ┌─────────────────────┐
   │  Your invoice data  │  (already a JSON object somewhere)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Build EN 16931 XML  │  (deterministic mapping; well-tested libs exist)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Render PDF/A-3b +   │
   │ attach the XML      │  (single API call to gPdf — or two-step elsewhere)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  Hand off to        │
   │  Chorus Pro / SDI / │
   │  Peppol / etc       │
   └─────────────────────┘

手戻りが出やすいのは次の 2 ステップです。

Step 1: XML を作る

これは面倒ですが機械的です。請求書データ（明細行、税、合計、取引当事者）を EN 16931 XML のフィールド名へ写像します。Java/Node/Python には、この処理を行うライブラリが複数あります。自分の言語で “factur-x library” を探してください。XML スキーマ仕様を心から楽しめる人でない限り、ゼロから書かない方がよいです。

Step 2: PDF/A-3 をレンダリングし、XML を添付する

ここでレンダラーの選択が重要になります。

組み込み対応がない場合: まず通常の PDF をレンダリングし、その後 PDF/A-3 へ変換し、さらに XML を埋め込みファイルとして添付するツールで後処理します。よくあるスタックは Ghostscript + qpdf、または Aspose のような有料ツールです。追加ステップが 2 つ、失敗点も 2 つ増え、後処理で視覚レイアウトがずれないことも確認しなければなりません。

組み込み対応がある場合（gPdf のアプローチ）: 1 回の呼び出しです。

curl -X POST https://api.gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "settings": {
      "profile": "pdfa-3b",
      "e_invoice": {
        "standard": "factur_x",
        "profile": "en16931",
        "document_type": "invoice",
        "xml": {
          "format": "cii",
          "encoding": "utf8",
          "content": "<?xml version=\"1.0\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
        }
      }
    },
    "pages": [{ "size": "a4", "elements": [/* invoice layout */] }]
  }' \
  --output invoice-with-einvoice.pdf

これで処理全体です。レンダラーは PDF/A-3b を出力し、XML を factur-x.xml（または zugferd-invoice.xml。どちらもすべての受け取り側に認識されます）として添付し、バイト列を返します。

よくある落とし穴

多くの人が苦労して学ぶ点です。

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

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

視覚表示と XML は一致しなければならない

XML 請求書と視覚的な請求書は、同じ請求書を表すことになっています。税務監査ではそこが比較されます。コードが total: 119.00 の XML を出力し、視覚的な PDF には丸めバグや古いテンプレートのために Total: 120.00 と表示されているなら、保存されたファイル上に税務上の不一致が残ります。両方を同じ正本データから、できれば同じコードパスで生成してください。

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

Factur-X には MINIMUM、BASIC、EN 16931、EXTENDED というプロファイルがあります。違いは、XML にどれだけのデータを含めるかです。顧客が明示的にそれ以上を求めない限り、BASIC を使ってください。税コード、明細行、取引当事者、合計をカバーしており、B2B 請求の約 95% には十分です。EN 16931 プロファイルは、例外ケース向けにさらに詳細を追加します。

提出前の検証

税務当局へ送信する前に、生成された 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 を単一の設定フラグとして扱えるなら、移行は機械的です。そうでなければ、複数ステップの運用フローを作ることになります。gPdf の /api/v1/e-invoice/render は単一設定で扱える実装です。完全なスキーマは API リファレンス にあり、Playground でもサンプルレンダリングを試せます。