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

短い答えは、仕様が十分に大きいため、正しく実装された 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 プロファイルはいつ「必須」で、いつ「推奨」なのか。同じファイルを、ある検証ツールが “Pass”、別の検証ツールが “Fail” と呼んだことがあります。
PDF/A-3 の埋め込みファイルメタデータ: AFRelationship、/AF 参照、埋め込み XMP。ルール自体は明確に規定されていますが、強制の厳しさは変わります。
フォントのサブセット化: PDF/A は、すべてのフォントが実際のエンコーディングとともに埋め込まれることを要求します。部分サブセットの CID-keyed fonts などの例外ケースでは、検証ツール間の不一致が起きてきました。

これはバグではありません。複雑な仕様を、独立したチームが規範テキストから実装すれば自然に起きることです。保守的な立場、そして多くの規制産業が取る立場は、複数の独立確認を要求することです。

リファレンスエンジンとセカンドオピニオン

veraPDF は、PDF/A を公開する標準化団体 PDF Association が管理するリファレンス実装です。オープンソースで、業界ワーキンググループによる監査を受けており、そのルールセットは ISO 19005 文書の標準的な解釈です。veraPDF が “Pass” と言うなら、単一エンジンから得られる最も強い判断材料です。

しかし、「最も強い単一エンジンのシグナル」は、「監査に通る証拠」と同じではありません。銀行、医療記録アーカイブ、政府記録機関など、規制対象の組織では、第二の独立確認を頻繁に求めます。理由は次です。

veraPDF のルール解釈が、被監査側が内部で使う別の検証ツールと異なり、下流で拒否される可能性がある。
単一エンジンのバグは、それがリファレンスであっても、同じエンジンを 2 回走らせても検出できない。
「2 つの独立確認」という調達原則は、コンプライアンス領域で広く使われている。PDF/A は、アーカイブ用途からその期待を引き継いでいる。

第二エンジンの選択は、何が使えるかで決まります。

Adobe Acrobat Preflight は有償でクローズドソースです。確認用エンジンとしては問題ありませんが、誰が再検証できるかを制限します。
callas pdfaPilot は有償で、エンタープライズ領域では事実上の定番です。ただし、これも独立した再検証を制限します。
第二のオープンソースエンジンもいくつかありますが、多くは veraPDF ほど完全ではありません。

gPdf で行ったのは、Rust + WebAssembly による自社エンジンを、意図的な「独立再実装」として作ることでした。同じ仕様、同じルールを、別チームがゼロから書いたものです。両方のエンジンが同じファイルを “Pass” したとき、結論はどちらか一方だけの場合よりはるかに強くなります。判断が割れたときは、調査すべき明確な不具合があります。エンジンのどちらか、またはファイル側です。

2 つを 1 つの URL で使える検証ツール

gpdf.com/validator/ で両方をホストしています。無料、ログイン不要で、ファイルを veraPDF と gPdf の Edge エンジンに並列で通し、両方のレポートを横並びで返します。使い方は次のようなものです。

PDF/A を生成し、出荷したい: 検証ツールにドロップし、両方が “Pass” したら、JSON レポートを QA 証拠として添付する。完了です。
片方のエンジンだけが失敗する: 特定できる不具合があります。レポートを比較し、問題のフィールドを見つけます。XMP タイムスタンプのずれや、PDF/A-3 の /AF 参照欠落のような微妙なものが多いです。
両方が失敗する: ファイルは本当に壊れています。生成元で修正します。
受け入れ済みアーカイブのバッチを監査する: ランダムサンプル PDF を投入し、レポート URL を記録し、監査ワークペーパーに添付します。「veraPDF と独立エンジンで検証しました」は、「ベンダーの検証ツールを走らせました」より強い主張です。

アップロードされたファイルは、リクエスト処理の外へ出ません。エンジンは Cloudflare Workers 上のメモリ内で実行され、レポート生成後にファイルは破棄されます。ログインなし、永続化なし、クォータなしです。

同じパターンの一般化

これは PDF/A だけの話ではありません。「2 つの独立確認」というパターンは次にも広がります。

Factur-X / ZUGFeRD 電子インボイス: gpdf.com/validator/ は、上記の PDF/A チェックと並行して、埋め込まれた EN 16931 CII XML に対して Mustang（mustangproject.org）を実行します。（その業務フローは Mustang で ZUGFeRD を検証する：何が通り、何が落ちるのかで扱っています。）
TLS 証明書: 現代の CA ログはすべて、複数の監視ツールで相互確認されます。
ビルド再現性: 同じソースからの独立した 2 回の再ビルドは、バイト単位で同一の出力になるべきです。

コンプライアンスの世界では、このやり方を何十年も続けています。PDF/A がようやく追いついてきただけです。

TL;DR

単一エンジンの “Pass” は黄信号です。2 エンジンの “Pass” は青信号です。両方のエンジンは validator で無料で使えます。ファイルをドロップし、2 つのレポートを受け取り、QA 証跡に添付してください。gPdf が生成したファイルなら、その検証ツールは API がコンプライアンス主張どおりに出力したことを外部に示せる検証証跡になります。

gPdf API 上で構築しているなら、E-invoice API reference (§5) が Factur-X / ZUGFeRD PDF/A-3 を直接出力する方法を示しています。その後、この検証ツールが外部から確認します。2 つのエンジン、1 回のアップロード。これが監査水準のやり方です。