監査担当者に手渡せるコンプライアンス

Spec: ISO 19005-4 (PDF/A-4)Spec: ISO 32000-2Spec: ETSI EN 319 142-1Spec: EN 16931-1

概要

監査担当者は、文書が準拠していると口頭で聞きたいわけではありません。彼らが手渡してほしいのは二つのもの、すなわち文書そのものと、それが準拠していると述べるチェックの結果です。このページは、NextPDF でその両方を生成すること、つまり準拠した出力と、求めてきた相手の前に提示できる検証結果について扱います。

オープンソースのコアは、アーカイブ用の PDF/A 出力と PAdES ベースライン署名を生成し、さらに準拠（PDF/A、PDF/UA、署名）を検証します。上位エディションは、その範囲を長期検証と電子請求へと拡張します。全体を通じて一つのルールが貫かれています。すなわち、準拠とはチェッカーの評決であって、プロデューサーが下せる約束ではありません。

なぜ重要か

コンプライアンス業務には特有の兆候があります。誰かが「はい、準拠しています」と言い、それから部屋が静まり返ります。なぜなら、それを証明するものを誰も提示できないからです。文書は正しく見えます。ライブラリは評判が良いものです。しかし、そのいずれもがエビデンスではありません。

そのギャップが生むコストは非対称です。一見準拠しているだけのファイルは、今日のレビューは通過しても、数か月後に外部のチェックで失敗します。税務当局で、長期アーカイブで、あるいは法廷で――そのときには元の文脈は失われ、失敗を説明するコストは高くつきます。標準はまさにこの事態を予期していました。PDF/A ファイルは対象プロファイルをメタデータに記録しますが、その識別情報が述べるのはプロデューサーの意図です。準拠の判定は、生成側ソフトウェアの外にある検証プロセスによって下されます（Spec: ISO 19005-4 (PDF/A-4), §6.7.3）。形式そのものが、プロデューサーには最終的な発言権がないと告げているのです。

手短に言うと

準拠した出力と、それが準拠していると述べる結果の両方を生成できます。 主張ではなく、成果物に加えてチェックです。
コアは一般的なケースをカバーします。 PDF/A アーカイブ出力と PAdES B-B / B-T 署名を生成し、PDF/A、PDF/UA、署名の準拠を検証します。
準拠とは、標準・条項・レベルに紐づけられたバリデーターの評決です。 NextPDF は対象とするプロファイルとレベルを明示し、条件を伴わない「準拠」とは決して言いません（Spec: ETSI EN 319 142-1, §6.1）。
上位エディションはその範囲を拡張します。 長期検証（PAdES B-LT / B-LTA）と電子請求（ZUGFeRD / Factur-X、EN 16931 に対する検証）は商用ティアの機能です。
エンジンは評決を捏造することを拒否します。 候補を生成してチェックを実行するのであって、自らの権限でファイルを準拠と認定することは決してありません。

NextPDF のアプローチ

このアプローチは、あらゆる場面に適用される一つの明快な分離です。すなわち、標準が定義する成果物を生成することは能力であり、その成果物が準拠していると判定することは評決です。NextPDF は前者を提供し、後者はチェッカーから得られるようにします。両者を混同することは決してありません。

その分離こそが、出力を手渡し可能なものにします。署名はその最も明快な例です。署名値は、署名そのものを意図的に除外した宣言済みのバイト範囲に対して計算されます（Spec: ISO 32000-2, §12.8）。だからこそ有効性は、信用に頼るのではなく、第三者がファイルから 再計算できるものになります。プロデューサーの仕事は、その構造を正しく書くことです。バリデーターの仕事は、それを確認することです。二つの仕事、二つの当事者、そして監査担当者が信頼するのは後者です。

つまり、あなたが手渡すワークフローには四つの手順があり、三つ目こそが「準拠するはず」を「準拠している」へと変える手順です。

Produce a candidateGenerate PDF/A archival output or a PAdES signature with the conformance-relevant structure in place — embedded fonts, declared profile, a signature over a correct byte range.
Refuse the impossibleThe engine rejects conformance-breaking combinations (an encrypted PDF/A, a signature level it cannot honor) rather than emitting a file that silently does not conform.
Validate independentlyRun a conformance checker — PDF/A, PDF/UA, signature. A passing report is the evidence; the producing library is not.
Hand over bothGive the auditor the document and the validation result together. The verdict travels with the artifact.

義務からエビデンスへ。NextPDF は準拠候補を生成し、準拠を破壊する操作を拒否します。独立したバリデーターが評決を下し、そのレポート――生成側ライブラリではなく――が、監査担当者に手渡すものです。

真ん中の手順は飾りではありません。アーカイブモードが有効な状態で、非互換な操作――たとえば暗号化の有効化――が試みられると、エンジンはファイルを非準拠の「アーカイブ」文書へと劣化させる代わりに、型付きのエラーを送出します。声を上げて拒否することこそが、候補を、後続のチェックに合格できるだけの誠実さに保つのです。

そしてチェックは段階的なものであり、単一のビットでは決してありません。PAdES は設計上レベル分けされています。B-B、B-T、B-LT、B-LTA はそれぞれ前のレベルに積み重なります（Spec: ETSI EN 319 142-1, §6.1）。B-T 署名は、B-B が持たない信頼できるタイムスタンプを伴います。レベルを名指す主張は誠実な主張であり、単なる「署名済み」はそうではありません。NextPDF はレベルを名指すことを求めるため、あなたが手渡す結果は、何が達成されたのかを正確に述べます。

実践例

短く、完結した形です。候補を生成し、それを検証し、エビデンスとして扱うのは バリデーターの答えであって、生成側の呼び出しでは決してありません。

<?php

declare(strict_types=1);

use NextPDF\Contracts\PdfDocumentInterface;
use NextPDF\Conformance\ConformanceValidator;
use NextPDF\Conformance\ConformanceTarget;
use NextPDF\Conformance\ValidationReport;

/**
 * Produce a candidate, then prove it with an independent check.
 *
 * The producing call returns bytes that SHOULD conform. Only the
 * validator's report turns "should" into something an auditor accepts.
 *
 * @param PdfDocumentInterface $candidate A document composed for archival
 *                                        (fonts embedded, profile declared)
 */
function archivalEvidence(
    PdfDocumentInterface $candidate,
    ConformanceValidator $validator,
): ValidationReport {
    // 1. The producing call states intent; it does not certify.
    $bytes = $candidate->getPdfData();

    // 2. The check is the verdict. Conformance is decided here, by the
    //    validator, against the named target — not by the line above.
    $report = $validator->validate($bytes, ConformanceTarget::PdfA);

    // 3. Hand BOTH over: the bytes plus the report. The report names the
    //    target, the level, and every requirement that was checked.
    return $report;
}

変数が $candidate と名付けられているのは意図的であり、レポートが戻り値であるのも意図的です。文書はあなたが生成したものであり、レポートはそれを証明するものです。監査担当者はあなたに準拠の実証を求めました。だからあなたは、プロデューサーの言葉ではなく、その実証を渡すのです。

よくある誤解

アーカイブを保存されていないファイルで、受信箱を却下された請求書で埋め尽くす誤解は単純です。すなわち *「ライブラリが PDF/A だと言っているのだから、このファイルは PDF/A である」*というものです。それはライブラリが下せる評決ではありません。プロデューサーは、準拠を 意図してファイルを出力しても、なお規範的要件を満たし損ねることがあります。意図を判定へと変えられるのは、検証プロセスだけです。生成側の呼び出しを証明として扱うことが根本的な誤りであり、それはまさに監査担当者が捕捉するよう訓練されている誤りです。

二つ目の、より見えにくい罠は、「NextPDF は標準準拠である」を一つの全面的な保証として受け取ることです。そのようなものは存在せず、誠実なエンジンは一つもそれを提供しません。準拠は標準ごと、条項ごと、レベルごとに決まります。正しい主張は、どのプロファイルか、どのレベルかを名指し、そしてチェックを示します。それらを欠いた主張はマーケティングであり、Insider_ はそれを書きません。

限界と境界

NextPDF は準拠候補を生成しそれを検証しますが、準拠を認定するものではありません。 エビデンスとなるのはバリデーターのレポートです。生成側ライブラリが自らの証明書を発行することは決してありません。
検証はチェッカーの結果であって、絶対的な保証ではありません。 クリーンな実行が意味するのは、バリデーターが実装する標準の版に照らし、それがチェックした要件をファイルが満たしたということです。それは入手可能な最も強いエビデンスであって、形而上学的な証明ではありません。
コアの範囲は、PDF/A アーカイブ出力と PAdES B-B / B-T 署名、加えて PDF/A、PDF/UA、署名の準拠検証です。 上位エディションの機能を黙って提供することはありません。
長期検証（B-LT / B-LTA）と電子請求（ZUGFeRD / Factur-X、EN 16931 に対する検証）は上位エディションの機能です。 EN 16931-1 は、ペイロードが検証される対象となる意味論的な請求書モデルを定義します（Spec: EN 16931-1, Scope）。それを満たすことは商用ティアであって、コアではありません。
法的効力は、技術的な準拠とは別個の問題です。 ある署名がある法域で法的に十分かどうかは、バリデーターではなく、法律と受け取る側の当局によって判定されます。NextPDF は技術的な結果について語り、その法的な重みについてはあなたのコンプライアンスチームが語ります。

Conformance reach across editions — edition availability
Edition	Availability
Core	PDF/A アーカイブ出力と PAdES B-B / B-T 署名を生成し、 PDF/A、PDF/UA、署名の準拠を検証します。出力と検証結果はどちらも手渡しのために利用できます。
Pro	長期検証――PAdES B-LT / B-LTA――を追加し、証明書の失効後も署名を検証可能に保つ失効エビデンスと文書タイムスタンプを埋め込みます。
Enterprise	電子請求（ZUGFeRD / Factur-X、EN 16931 に対する）と、構造的な準拠ポリシーおよびレポートを追加します――それでも構造チェックであり、最終的な判定はバリデーターとあなたのコンプライアンスチームに委ねられます。

より深いコンプライアンスツール、および上位エディションの各機能について引用された準拠の境界は、コンプライアンスと準拠のページにあります。チェックを実際に 実行する必要があるときは、PDF/A および PDF/UA 検証のトラブルシューティングガイドが、失敗したレポートの読み方と修正の手順を案内します。

用語集

準拠 ――ファイルが標準の規範的要件と一致していること。検証プロセスによって判定され、特定の標準・条項・レベルに紐づけられます。
候補 ――準拠を 意図して生成されたファイルで、独立したバリデーターが実際に準拠していることを確認する前の段階にあるもの。
バリデーター / 準拠チェッカー ――標準の要件に照らしてファイルを判定し、監査担当者が頼りにする結果を生成する独立したソフトウェア。
PDF/A ――ISO 19005 ファミリー。長期保存のための制約付き PDF プロファイルであり、文書の静的な外観を時を超えて再現するよう設計されています。
PDF/UA ――ISO 14289 ファミリー。タグ付き PDF が支援技術へ構造をどう伝えるかを定義するアクセシビリティプロファイルです。
PAdES ――PDF Advanced Electronic Signatures。ISO 32000-2 が PDF 署名のために参照する、ETSI EN 319 142 ファミリーの署名プロファイル（B-B、B-T、B-LT、B-LTA）です。
EN 16931 ――コア電子請求書の意味論的なデータモデルを定義する欧州標準であり、ハイブリッド電子請求のペイロードが照合される対象となる義務です。