PDF/A は PDF のアーカイブ向けバージョンです。2026 年に見える文書が、2050 年にも同じように表示されることを保証するための profile です。主な profile は PDF/A-1、2、3、4 で、それぞれに conformance level があります。その中で PDF/A-3 は EU 電子インボイスを支える profile であり、広く使われる PDF/A の中で唯一、アーカイブ wrapper 内に任意の添付ファイルを持てます。

請求書、規制提出物、または “PDF + structured data” の workflow を扱うなら、PDF/A-3 は避けて通れません。ここでは何が違うのか、どこを検証すべきかを実務目線でまとめます。

PDF/A ファミリーの概要

Profile	ISO part	Year	特徴
PDF/A-1	19005-1	2005	最初のアーカイブ profile。透明度なし、JavaScript なし、フォント埋め込み。
PDF/A-2	19005-2	2011	JPEG2000、透明度、レイヤーを追加。印刷再現性が向上。
PDF/A-3	19005-3	2012	embedded file attachments を追加。Factur-X / ZUGFeRD の wrapper。
PDF/A-4	19005-4	2020	現代的な改訂。conformance model が整理され、`b` と `a` の分割なし。

Sub-level は次の通りです。

b (basic): 視覚的な再現性を保持。意味構造は保証しません。
a (accessible): 構造タグと Unicode mapping。Screen reader が正しい順序でテキストを抽出できます。
u (Unicode): Unicode mapping はあるが、完全な構造タグはありません。
e / f（PDF/A-4 のみ）: エンジニアリング 3D コンテンツと完全なフォーム。

つまり “PDF/A-3b” は、添付ファイルを許可する profile 3 と、accessibility tagging を要求しない basic level の組み合わせです。請求書では最も一般的です。

PDF/A-3 の何が特別か

PDF/A-1 と PDF/A-2 は任意の embedded files を禁止します。アーカイブ PDF は self-contained であるべきだからです。data.xlsx のような添付が PDF と別に劣化すれば、アーカイブ保証は崩れます。

PDF/A-3 は厳密な条件付きでこのルールを緩めます。各 embedded file は AFRelationship attribute を持ち、visible PDF content との関係を示す必要があります。有効値は Source、Data、Alternative、Supplement、Unspecified。さらに PDF は添付を /AF array に列挙し、添付ファイルを説明する XMP metadata を出力しなければなりません。

言い換えると、PDF/A-3 は「添付してよい。ただしそれが何で、人間が見る PDF とどう関係するかを明記せよ」と言っています。この宣言が電子インボイスの基礎になりました。人間が読む invoice は PDF に、機械が読む EN 16931 CII XML は添付に入り、AFRelationship="Alternative" が両者を同じ invoice の別表現として結びます。

本番での PDF/A-3 の使われ方

Factur-X（フランス、2026 年以降 B2B で段階的に必須）: PDF/A-3 + CII XML、XMP namespace は urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#。
ZUGFeRD 2.x（ドイツ、2025 年から受領必須）: PDF/A-3 + CII XML、XMP namespace は urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#。
エンジニアリング CAD アーカイブ: ネイティブ CAD ファイルを添付した PDF/A-3。PDF は rendering、CAD は source。
規制提出物: FDA submissions や EU 上場企業の ESEF financial reports など、XML payloads を添付した PDF/A-3。

ここで wrapper は単なるコンテナではありません。PDF と添付ファイルが同じ文書であり、両方が validate されるべきだという contract です。

PDF/A-3 準拠を検証する方法

公式 checker は PDF Association が管理する veraPDF（verapdf.org）です。ISO 19005-3 rule set を実装しており、veraPDF が “Pass — PDF/A-3b” と返すなら、単一 engine から得られる最も強い signal です。

ただし単一 engine の “Pass” は audit-grade standard ではありません（Why two PDF/A validators are better than one を参照）。実務上は 2 つの independent engines を走らせ、両方 pass した場合だけ compliant と見なします。

E-invoice ではもう一つ必要です。Mustang（mustangproject.org）は Factur-X / ZUGFeRD の de-facto checker で、embedded CII XML を EN 16931 Schematron に対して validate します。PDF/A-3 conformance だけでは足りません。添付 XML が EN 16931 として正しくなければ、受信側の AP system は invoice を reject します。

多くのチームは Java、veraPDF CLI、Mustang をインストールし、shell script で結果をまとめます。動きますが、手間はあります。

validator は 3 つをブラウザーで実行します。

veraPDF: 公式 reference、PDF/A-3 conformance。
gPdf Rust+WASM edge engine: 独立実装による second opinion。
Mustang: embedded e-invoice payloads 用の EN 16931 CII XML Schematron。

ファイルを drop すると 3 engine が parallel に走り、report が side-by-side で返ります。QA evidence 用 JSON も download 可能です。Login も quota もありません。

Report で見るべき点

Failure は多くの場合、次に集中します。

Embedded file metadata missing: /AF array がない、または embedded file がそこに listed されていない。
AFRelationship missing or wrong: e-invoice では Alternative が必要。多くの PDF libraries は Source や Data を default にします。
XMP namespace missing or wrong: Factur-X と ZUGFeRD には固有の namespace URI があり、1 文字の typo でも fail します。
Fonts not subsetted or not embedded: PDF/A は使用 glyph をすべて font とともに埋め込む必要があります。
Output intent missing: 白黒テキストだけでも、PDF/A では sRGB などの ICC profile による colour intent が必要です。
Document metadata incomplete: information dictionary に /Title、/Producer、/CreationDate が必要です。

Report は通常、該当する spec section を示します。生成元で直してください。gPdf で生成する場合、API がこれらを自動処理し、validator が public receipt になります。

TL;DR

PDF/A-3 = PDF/A-2 + 任意ファイルを合法的に embed できる能力。この能力が EU e-invoicing を実用化します。人間が読む invoice と structured EN 16931 CII XML を 1 つの archival wrapper に入れるためです。PDF/A-3 wrapper と attached XML の両方が pass して初めて出荷できます。

POST /api/v1/e-invoice/render で生成し、validator で検証してください。3 engines（veraPDF + gPdf edge + Mustang）、1 upload、無料です。