PDF を政府ポータルにアップロードします。システムはそれを処理し、検証し、受け入れを確認します。まったく同じファイルを別の政府ポータルにアップロードすると、システムは「ドキュメントが検証要件を満たしていません」という不可解なエラーでファイルを拒否します。ファイルも内容も同一であり、PDF は試したすべてのデスクトップ リーダーで正しく開きます。しかし、一方のポータルはそれを受け入れますが、もう一方のポータルは受け入れません。説明は、PDF の目に見えるコンテンツではなく、目に見えないメタデータ、特定の PDF サブ標準への構造的準拠、および各ポータルのソフトウェアが強制する検証ルールにあります。
政府ポータルは、単一の普遍的な標準に照らして PDF を検証しません。各ポータルは、特定のルール セットをチェックするように構成された検証エンジンを使用し、機関ごとに検証エンジンの構成が異なります。 IRS の最新化ポータルを満たす PDF は、SEC の EDGAR システムで不合格になる可能性があります。これは、2 つのシステムが異なるバージョンの PDF 仕様、異なる必須メタデータ フィールド、および異なるフォント埋め込みポリシーをチェックするためです。この現象は十分に文書化されていますが、書類を提出して拒否通知を受け取る人々にはほとんど理解されていません。 2025 年の米国連邦政府機関の文書提出ポータルの分析では、最初に拒否された PDF の 22% が、PDF が技術的に無効であるためではなく、機関によって異なる検証ルールのために拒否されたことがわかりました (国立公文書記録管理局、「連邦電子文書提出コンプライアンス」、2025 年)。拒否は事実ですが、そこで特定される PDF の問題は、多くの場合、ファイルの一般的な欠陥ではなく、そのポータルのルール セットに固有のものです。 WukongPDF の文書準備ツールは、複数の PDF/A 準拠レベルへのエクスポートをサポートしており、送信前にポータル固有の書式設定の問題を検出するのに役立つメタデータ検証チェックが含まれているため、拒否、再修正、再送信のサイクルで発生するやり取りが軽減されます。
PDF/A 準拠: クロスポータル検証失敗の最も一般的な原因
PDF/A は、長期アーカイブ用に設計された PDF の ISO 標準化バージョンです。これは、JavaScript の使用禁止、外部ファイル参照の使用禁止、音声やビデオの使用禁止、暗号化の禁止、フォントの埋め込みの必須など、数十年先まで PDF の確実なレンダリングを妨げる可能性のある機能を禁止しています。多くの政府ポータルでは、提出された文書に PDF/A への準拠が必要ですが、必要な PDF/A のバージョンとレベルは異なります。
2005 年に発行された PDF/A-1 は最も厳密なバージョンです。透明度、レイヤー、および JPEG2000 圧縮が禁止されます。 2011 年に発行された PDF/A-2 では、一部の制限が緩和され、透明性とレイヤーが許可されています。 2012 年に公開された PDF/A-3 では、PDF/A だけでなく、あらゆる形式の埋め込みファイルがさらに許可されます。各バージョンには 3 つの適合レベルがあります。基本的な外観のレベル B、Unicode テキストのアクセシビリティのレベル U、および完全なアクセシビリティのタグ付けのレベル A です。
| 代理店/システム | 必要な PDF/A バージョン | 主要な追加要件 |
|---|---|---|
| 米国の裁判所 (PACER / CM/ECF) | PDF/A-1b | テキスト検索可能、セキュリティ設定なし、フォント埋め込み |
| エドガーSEC | PDF/A-1b または PDF/A-2b | セキュリティなし、特定のマージン要件、すべてのフォントが埋め込まれている |
| IRS の最新化された電子ファイル | PDF/A-2b | XFA フォームは特に禁止されており、特定のメタデータ フィールドが必要です |
| NIH eRA コモンズ | PDF/A-1b | 特定の許可メタデータ、一部のサブシステムにアクティブなハイパーリンクがない |
| EU 電子司法ポータル | PDF/A-2u | Unicode テキスト レイヤーが必要、2025 年以降はアクセシビリティ メタデータが必要 |
Microsoft Word から PDF/A-2b として保存された PDF は、IRS ポータルを通過する可能性がありますが、PACER システムには合格しません。これは、PACER には PDF/A-1b が必要であり、PDF/A-2b で許可されている透明効果が禁止されているためです。修正するには、ターゲット ポータルが必要とする特定の PDF/A バージョンにドキュメントを再エクスポートします。 Word、LibreOffice、Adobe Acrobat などのほとんどのドキュメント オーサリング ツールは、複数の PDF/A バージョンへのエクスポートをサポートしています。ポータルのドキュメントでバージョン番号なしで PDF/A が指定されている場合は、PDF/A-1b が最も広く認識されているサブセットであるため、最初に PDF/A-1b でテストし、コンテンツが PDF/A-1b で禁止されている機能を必要とする場合にのみ新しいバージョンにエスカレーションします (Adobe、「PDF/A Compliance Levels」、2025)。
フォント埋め込み要件とポータル間で要件が異なる理由
フォントの埋め込みは、ポータル間の検証の不一致の主な原因です。 1 つのポータルでは、すべてのフォントを完全に埋め込む必要があります。つまり、ドキュメントで使用されているすべてのフォントの文字セット全体が PDF に含まれている必要があります。別のポータルではサブセットの埋め込みのみが必要で、PDF にはドキュメント内で実際に使用されている文字のみが含まれます。 3 番目のポータルでは、まったく埋め込まずにフォントを参照し、閲覧者のコンピュータ上のシステム フォントにフォールバックすることができます。
ポータルで完全なフォントの埋め込みが必要で、サブセットが埋め込まれたフォントを含む PDF を受信すると、検証エンジンがフォント関連のエラーでドキュメントを拒否する場合があります。拒否は、PDF が無効であるためではなく、どのリーダーでも正しく開いて表示されるためではなく、ポータルの特定のルールが完全な埋め込みを必要としているために発生します。完全な埋め込みとサブセットの埋め込みの区別は PDF のフォント記述子に文書化されており、検証エンジンがプログラム的に検査します。
PDF にどのフォントがどのレベルで埋め込まれているかを確認するには、Adobe Acrobat で PDF を開き、「ファイル」、「プロパティ」、「フォント」タブに移動します。各フォントは、埋め込みステータス (埋め込み、埋め込みサブセット、または埋め込まれていない) とともにリストされます。完全な埋め込みが必要なポータルの場合は、サブセットに埋め込まれたすべてのフォントを送信前に完全に埋め込まれたフォントに変換します。この変換には、システム上で完全なフォント ファイルが利用可能である必要があります。ドキュメント作成アプリケーションの PDF エクスポート設定で、サブセットだけでなく完全なフォント セットを埋め込むオプションが選択されていることを確認してください。 Microsoft Word の場合、この設定は [ファイル]、[オプション]、[保存]、および [ファイルにフォントを埋め込む] の下にあり、[文書で使用されている文字のみを埋め込む] チェックボックスはオフになっています。
メタデータ フィールドの要件と隠れた検証ゲート
政府の文書提出ポータルでは、多くの場合、PDF に特定の XMP メタデータ フィールドを入力する必要があります。 dc:title、dc:creator、dc:subject、xmp:CreateDate、カスタム機関固有フィールドなどのフィールドは PDF のメタデータ ストリームに保存され、ドキュメントを通常に表示するときには表示されません。ポータルの検証エンジンはこれらのフィールドを抽出し、その存在、形式、コンテンツをチェックします。
たとえば、SEC EDGAR システムでは、出願タイプ、登録者の CIK 番号、出願日を識別する特定のメタデータ フィールドが必要です。完全にフォーマットされているように見えても、dc:title フィールドがないか、Microsoft Word - Document1 のような一般的な値に設定されている PDF は拒否されます。同様に、米国裁判所の CM/ECF システムはメタデータを抽出してドケット記入項目に入力しますが、メタデータが欠落しているか正しくフォーマットされていない PDF があると、提出が拒否されるか、場合によっては、後で申し立てを通じて修正する必要がある不正確なドケット テキストで受理されます。
特定のポータル送信用に PDF メタデータを準備するには、Adobe Acrobat の「ドキュメント プロパティ」ダイアログなどの PDF メタデータ エディター、XMP メタデータ編集ツール、またはドキュメント オーサリング アプリケーションのメタデータ機能を使用して、各必須フィールドをポータルが必要とする正確な値に設定します。ポータルの送信ガイドラインには、必要なメタデータ フィールドとその許容可能な形式がリストされている必要があります。ガイドラインにメタデータ要件が明示的に記載されていない場合は、ポータルのヘルプ デスクに問い合わせるか、ポータルの開発者ドキュメントを確認してください。多くの場合、このドキュメントには、ユーザー向けドキュメントでは省略されているメタデータ仕様が含まれています。メタデータ要件は、ポータル固有の PDF 準備で最も見落とされがちな側面であり、最初の送信試行の前にメタデータの検証に 1 時間を費やすことで、拒否、修正、再送信のサイクルにかかる数日の所要時間を回避できます。
構造の検証: 外部参照テーブルの整合性と PDF 構文の癖
PDF/A への準拠、フォントの埋め込み、メタデータに加えて、政府ポータルは PDF の内部構造の整合性を構文レベルで検証する場合があります。デスクトップ リーダーで正しく開く PDF には、誤った相互参照テーブルのオフセット、ファイルの終わりのマーカーの欠落、PDF 仕様に厳密に準拠していないオブジェクト ストリームなど、構文の小さな逸脱がある可能性があります。デスクトップ PDF リーダーは、コンテンツを正しく表示することが主な目的であるため、構文の多少の逸脱を許容できるように設計されています。ポータル検証エンジンは、ドキュメントが自動システムによって確実に処理されることを保証することが主な目的であるため、多くの場合、より厳格になります。
典型的な例は、%%EOF マーカーです。 PDF 仕様では、すべての PDF ファイルがバイト %%EOF で終わる必要があり、オプションでその前に空白が続く必要があります。切り捨てられた保存操作または非標準の PDF ジェネレーターが原因でこのマーカーが欠落している PDF は、欠落しているマーカーを黙って無視する Adobe Acrobat で正しく開きます。厳密な構造チェックを実行するポータル検証エンジンは、ファイルの終わりエラーでファイルを拒否します。その他の一般的な構造上の問題には、以前の編集セッションで残された存在しないオブジェクトを指すエントリが含まれる相互参照テーブル、単一の線形構造に完全に統合されていない増分保存チェーン、ドキュメントで実際に使用されている機能と一致しないヘッダー内の PDF バージョン番号などがあります。
構造的な問題を修正するには、完全な構造の再構築を実行するPDF Standard修復ツールが必要です。これらのツールは、PDF の内部オブジェクト構造を解析し、異常を特定し、仕様に準拠したクリーンなファイルを生成します。 The structural repair does not change the visible content of the PDF, but it can dramatically change whether a portal validation engine accepts the file. Running a structural repair on a PDF before submitting it to any government portal is a low-cost insurance step that prevents a significant fraction of technical rejections.
初回試行ポータルの受け入れを増やすための提出前チェックリスト
PDF を政府ポータルに送信する前に、最も一般的なクロスポータル検証の失敗点に対処する体系的なチェックリストを実行してください。このチェックリストにかかる 10 分は、拒否の診断、問題の修正、再提出に必要な時間に比べればほんのわずかです。
ポータルの文書化された要件に照らして PDF/A バージョンを検証し、必要に応じて再エクスポートします。すべてのフォントがポータルで必要なレベルで埋め込まれていることを確認します。これは、ほとんどの政府ポータルでは完全に埋め込まれています。指定された正確な形式を使用して、ポータルのドキュメントにリストされているすべてのメタデータ フィールドを必要に応じて入力します。 PDF 構文検証ツールまたは構造修復ツールを実行して、内部構造の問題を見つけて修正します。ほとんどの政府ポータルは暗号化またはパスワードで保護された PDF を拒否するため、PDF にセキュリティ設定が含まれていないことを確認します。ファイル サイズがポータルの制限内であること、およびページのサイズがポータルの要件と一致していることを確認します。少なくとも 2 つの異なる PDF リーダーで PDF を開き、PDF が正しくレンダリングされ、コンテンツが切り取られていないことを確認します。クロスリーダー チェックは、シングルリーダー テストでは見逃される可能性のあるレンダリングの問題を検出します。特定のポータルの検証ルールで PDF 準拠 を達成するには、運ではなく準備が必要です。系統的な提出前プロセスにより、適切に準備されたドキュメントの大部分について、初回の拒否が初回の承認に変換されます。