PDF は PDF/A-3 に適合しているか、していないかのどちらかです。それなら、なぜ同じファイルを 2 つ のバリデーターで検証するのでしょうか。

理由は実務的です。PDF/A の仕様は大きく、正しく実装された 2 つのエンジンでも境界条件で判断が分かれることがあるからです。監査に耐えるワークフローでは、単一エンジンの “Pass” は青信号ではなく黄信号として扱うべきです。

PDF/A は単一のアルゴリズムではない

PDF/A は ISO 19005 の複数パートにまたがります。PDF/A-1、PDF/A-2、PDF/A-3、PDF/A-4 があり、それぞれ b、a、u、e、f などの準拠レベルを持ちます。さらに、その下には PDF 本体仕様である ISO 32000 があります。解釈すべき規範文書は数千ページ規模です。

差が出やすい領域は次の通りです。

PDF/A-2/3 の透明効果: 条件付きで許可されますが、条件の境界解釈に差が出ます。
ICC カラープロファイル: 必須なのか推奨なのか、エンジンごとに厳しさが異なります。
PDF/A-3 の添付ファイル metadata: AFRelationship、/AF 参照、XMP の整合が必要です。
フォント subset: CID フォントや部分 subset は検証差分が出やすい箇所です。

これは必ずしもバグではありません。複雑な標準を別チームが独立実装すると、境界で差が出るのは自然です。規制業界が独立した二重確認を求める理由もそこにあります。

参照実装とセカンドオピニオン

veraPDF は PDF Association が管理する参照実装です。veraPDF が “Pass” と言えば、PDF/A における最も強い単一エンジンのシグナルです。

ただし、最強の単一シグナルでも監査証跡そのものではありません。銀行、医療記録アーカイブ、行政記録、長期保存システムでは、次の理由から第二のエンジンが求められます。

受け取り側が別のバリデーターを使って拒否する可能性がある。
単一エンジンのバグは、同じエンジンを再実行しても検出できない。
compliance では「独立した 2 つの確認」が一般的な考え方である。

gPdf では veraPDF に加えて、Rust + WebAssembly で書いた独自エンジンを実行します。同じ仕様を別実装で検証するため、両方が pass した場合の信頼度は大きく上がります。結果が割れた場合も、調査すべき箇所が明確になります。

1 つの URL で 2 つの report

gpdf.com/validator/ で無料提供しています。ログイン不要でファイルをアップロードすると、veraPDF と gPdf edge engine が並列に走り、2 つの report が横並びで返ります。

よくある使い方:

PDF/A を出荷する前: アップロードして二重 pass を確認し、JSON report を QA 証跡に保存する。
片方だけ失敗する: report を比較し、XMP、/AF 参照、添付 metadata を確認する。
両方失敗する: 生成元を修正する。
アーカイブ batch の監査: サンプルを検証し、結果を監査資料に添付する。

アップロードされたファイルは保存されません。Cloudflare Workers 上でメモリ内処理され、report 生成後に破棄されます。

電子請求書にも同じ考え方が使える

Factur-X / ZUGFeRD では PDF/A-3 の外形だけでなく、埋め込まれた EN 16931 CII XML も検証が必要です。gPdf validator は XML 側に Mustang を使い、PDF/A report と一緒に結果を表示します。

これは特定ツールを疑う話ではなく、独立実装によって証拠を強くする実務パターンです。

TL;DR

単一エンジンの “Pass” は黄信号です。独立した 2 つの “Pass” ははるかに強い証拠になります。validator にファイルを投げ、2 つの report を QA や監査に添付してください。gPdf API で生成した PDF なら、その compliance claim を外部から確認する公開レシートになります。