PDF/Aとは

AIIMのECMモデルは、ビジネス情報の管理のプロセス（文書の獲得、管理、提供、維持、保管）を区分します。 これらのプロセスは、簡単に以下のPDF/Aの機能に割り当てることができます。

さまざまな方法では、次に説明するが、デジタル文書が挙げプロセスおよびPDF /これらのプロセスのすべてにおいても重要である全ての内に作成される。 ディジタル文書は、前述のすべてのプロセスで作成されています。以下で説明するとおり、PDF/Aもまたすべてのプロセス（その方法は違いますが）で重要です。

後にアーカイブされるディジタル文書とは以下のようなプロセス（アプリケーションで）使われるデータなどが揚げられます。

ディジタル文書は、アナログやディジタルソースから作成されます。以下のように、いくつかのパラメータはデジタル文書の長期的保存に関連しています。

このような違いがありますので、それぞれのソース（アウトラインと詳細の双方）の取り扱いにそれぞれに適した戦略が必要なことは明らかです。 このような戦略は、IT部門での作業者や記録の管理者そしてそれぞれのデータを変換できる製品の作成者それぞれに必要です。 ここでの課題は、PDF/A規格に準拠した文書の生成だけではなく、変換の作業においてオリジナル文書の外観を変換後の文書でも保持できることも必要です。 以下にはPDF/Aへの変換後の図を示しています。それぞれの結果フォームはPDF/A規格に準拠していますが、その外観はオリジナルに対応しているとはいえません。

長期保存用のディジタルデータは大きなアドバンテージを提供します。

さらなる利点として、けして過小評価してはならない経済的な利益を伴います。

もちろん、オリジナルのデータ形式と比較した場合には、アーカイブされたPDF/A文書は少しばかりの短所があります。 例えば、オリジナルのデータ形式にあるインタラクティビティや組込み済みの機能が無くなってしまうことです。 MS Excelを例にとってみます。 MS Excelは、そのデータに式による計算処理を提供しますが、これは変換時に無くなってしまいます。 したがって、それらの形式において、 常にオリジナル文書を保存するということと、保存形式であるPDF/Aの亜種を容認しないという点において理にかなっています。 “インタラクティブな”ファイルにおいは、そのデータが更なる変更を必要としない期間をそのデータの保存時間とするように設定できます（文書のライフサイクル管理）。 特定の形式（たとえば税務上の帳票類など）では、法律上の理由により保存する必要があります。

独自形式のデータ（Office文書、CAD図面など）から最も簡単にPDF/Aを生成するには、プリンタードライバーやよく知られたPDF Producer、PDF Creator、PDF Converter （例えば、Adobe Distillerなど）を使います。 これまでのところ、ほとんどのアプリケーションは「PDF形式で保存する」という機能（メニュー）を持っていませんので、プリンタドライバを経由してPDF/Aを生成するこの"回り道"が必要です。 MS Office 2007以降では、この機能が利用できますが、その機能を別のアドインとしてダウンロードしなければなりません。 電子メール（MS Outlookなど）の本文および添付データをPDF/Aでアーカイビングする場合はさらに複雑です。 現在は、この機能が使えるのは、極わずかの提供者によるものだけです。 PDF Tools AG社は、すでに電子メールとその添付データを単一のPDF/A文書に変換する「3-Heights™ Document Converter Service」を開発し提供しています。 株式会社トラスト・ソフトウェア・システムは、これらPDF関連製品を販売すると共に、日本語でサポートしています。

データベース、ERPシステムなどにおいては、通常PDF/Aの出力関数（“PDFに保存”メニュー）が使われています。 もうひとつのオプションでは、PDFやPDF/Aを直接またはプログラムで生成します。 このプロセス（例えば個人向けの印刷物を作成する場合など）においては、たくさんのデータソースを併合（マージ）できます。 PDFlib GmbH社は、このようなツールのリーディングプロバイダーです。

画像を変換するような特定のツールでは、その変換プロセスにおいて、メタデータ情報やテキスト検索のための情報生成でOCR機能が重要となります。 そうであるにもかかわらず、 スキャンされた文書では、アプリケーションの複雑さを過小評価できません、特に複数の形式を持つ場合（例えば、たくさんのバリエーションの形式をもつTIFF）、 色・フォント・圧縮方法・セグメント化の手順または、複数のラスターコンテント（MRC,Mixed Raster Content）が格納された形式で顕著です。

これらのソフトウェアは、フォントやカラープロファイルやメタデータを埋め込まなければならないなど、PDF/Aで実施しなければならないことと、してはならないことを考慮しなければなりません。

ディジタルソースからPDF/Aを生成する場合に、一般的に期待されることから、次のような課題に直面します。

電子メールには、すべてのドキュメントの種類、インターレースアーカイブばかりではなく、さらに多くの種類（実行ファイルなど）を含められます。 さらに、電子メールはその内容に内部または外部参照（例えば、HTMLメール）や異なるシステム、インターフェース、ファイルシステムおよび、データ·ストリームをも含めるられます。 添付ファイルを含む電子メールのアーカイブプロセスでは、 元々アナログだったデータまたはディジタルデータをひとつの製品でPDF/Aに効果的に変換することに関するすべての課題のなかで“至高の規律”と言えます。

これを解決するために、個々の電子メール要素を変換するための違った戦略を選択しなければなりません。 それは、電子メール本体と添付データを個々に変換し、しかる後にひとつの文書に併合するということです。 このようにして変換されたPDF/A文書に変換された電子メールの各添付データは、いわゆるブックマーク（Bookmark）のエントリを使用して識別できます。 この処理で電子メールにオリジナルの構造は、変換の後においても追跡できるようになります。 さらに、Word文書の目次（Table of Contents）のような情報も欠落しません。それは、目次がブックマークの階層の第二レベルにマッピングされPDF/Aにしたがってリンクされるためです。

デジタル署名の場合でも、メールをアーカイブする際にはその取り扱いが課題となります

ウェブサイトのアーカイブに冠するトピックは、比較的新しいものです。 これは基本的に必要な証拠が法的または他の手順で提供することができるように、合法的に信頼できる方法で、自分のウェブサイトの内容と状態を保持したが含まれます。 企業の公告情報が記載されたようなWebサイトでは、その情報またはその状態が法的に保持されている必要があります。さらに、法的には、保持されていることが証明できる証拠（法的やその他の手段で作成されたもの）が要求されるようなものがあります。

ウェブサイトをアーカイブする難しさは、 その出力は印刷（または表示）ドライバーによるもので、通常は、Webサイトの本当の外観を表すものではないことです。 それは、Webサイトは通常印刷（または表示）のために特別に準備されたものであるためです。 前述の信頼できる証拠において、この「オリジナルと同じ」ということが決定的に重要なことです。

そのために、ウェブサイトを“キャプチャ”機能によってイメージ画像に変換します。イメージ画像は、関連のテキストやその他の情報（フォントや色空間など）をマージされて、効果的に作成された“ベクトル化され、検索可能なスクリーンショット”データです。 別の複雑な問題は、外部のリンクやサイトの内部リンク構造の取り扱いです。 その上に、ひとつのブラウザとひとつのブラウザのバージョンを決定する必要があります。それは、異なるブラウザやバージョンの異なるブラウザではWebサイトを違うように表示するためです。

変換用のソフトウェアを個々のクライアントまたはサーバーにインストールする場合は、以下の点に注意して実施しなければなりません。

単一の個々のPDF/A文書は直接アーカイブ（保存）できます。 大量の類似したPDF/A文書（例えば、サービス利用料金の請求書など）をアーカイブ（保存）する場合、 それぞれの文書が同じフォントやロゴ（またはコーポレートアイデンティティ要素）などを含み、それらをそれぞれの文書に含めてアーカイブしなければなりません。 このように、重複したリソース（フォントや画像など）を繰り返してはアーカイブすることは望ましくなく、PDF/Aの長所を損なってしまいます。

これを解決するには、 大量のPDF/A文書でアーカイブする場合において、アドインを使って共通のリソースを分離しそれだけで構成されたひとつのインスタンスとして格納するようにアーカイブシステムをアップグレードできます。 この共通のリソースは、必要な文書を参照する時にマージされ完全なPDF/A文書となります。 この処理においても文書に電子署名を適用できます。ただし、署名プロセスでは、文書を分離するための準備を先に行わなければなりません。

ディジタル文書から生成したPDF/A文書の電子署名プロセスは、法的なセキュリティをもたらします。 アプリケーションに応じてユーザーは、電子署名が本当に提供するものを見定めなければなりません。 いずれの場合でも、適格な電子署名は、いつの時点で変換され電子署名がなされたか、そしてその文書が電子署名後に変更されたか否か、を強力に明確にします。 それはまた、どこの誰がその電子署名を適用したかを明確にします。

しかしながら、“ダイナミック”なソース・データ（データベースのような）PDF/A文書の不確実性は払拭できません。 またそれを検証することが可能であるかどうか というのは、 実際に作成されたPDF/A文書がオリジナル文書の外観（Word文書のように）に対応しているかや、 そのPDF/Aファイルにオリジナル文書に含まれていた情報（電子メール本文と添付ファイルのように）のすべてが存在するかどうか、を検証できるかということです。 そのような場合では、PDF/A文書の信頼性を高めるためにプロセス全体が認定されなければなりません。 この問題は、デジタル署名の簡単な使用を超えたトピックです。 しかし、このような資格（認定されること）は特定のデータ量が存在した場合に、サービスプロバイダーやソフトウェアやシステムのベンダーのような大きな企業にとって価値があります。

ご注意ください：
ここでの「法的なセキュリティ」は、国内法全般での一般的な見解です。実際に法律で保護される（PDF/A）文書は、それぞれの関連する法律によります。本文書は、PDF/A文書が法律で必ずしも保護される（法的にセキュアである）ことを保証するものではありません。

「信頼性はグッド、コントロールはベター」　これはもちろん、PDF/A文書やPDF/A文書を生成する製品に適用されます。 このことは、PDF/A文書を生成することでもあります。 ところが、PDF/Aというラベルがつけられた製品がすべてのPDF/A製品ではありません。 極端な場合は、企業データのアーカイブが会社の存在を決定的なものとしますので注意が必要です。

たとえば、会社の重要なデータが正しく準備されているか否かで訴訟が起こされることがあります。 このような場合は、最高の品質水準を確保するツールを使用することが重要です。 バリデータは、ツールがPDF規格の前提条件を満たしているかどうかを判断するためのものです。 このバリデータもまたチェックする必要があります。 このような作業のために、 PDF協会は、自由に利用できるテストスイートを作成しました。このテストスイートは、体系的な規格違反を見つけることすなわちバリデータがすべての違反を識別できることをチェックます。

ツールを評価する際にバリデータの使用はもちろん重要ですが、そればかりではなく、それらを運用するプロセスも重要です。 そのため、バリデータは作成したPDF/文書の適合性をチェックするために定期的に（恒久的な品質のチェックとして）使用されるべきです。 なぜならそれは、異なるソース（オリジナルのデータ）は違った変換結果を招く場合があるためです。