【ITニュース解説】Compute and Retention Costs of PDF Print Layout Rendering for 180,000 Watermarked Copies

多くの企業では、機密性の高い文書をPDF形式で共有する際、誰に配布されたか追跡できるように、個別の透かし（ウォーターマーク）を文書に挿入するケースがある。例えば、ある企業が3万件の文書を月に平均6人の異なる受信者に送る場合、合計で18万個のウォーターマーク付きPDFファイルを作成する必要が生じる。この大量のPDFファイルを生成し、さらに長期間保存する作業には、予想以上に大きな計算リソースとストレージコストがかかることが課題となっている。

PDFの生成プロセスは、大きく分けて二つの主要な作業に分けられる。一つは「レイアウトCPU」と呼ばれる作業で、これはHTMLのような文書の元データ（マークアップ）を解析し、それを決められたサイズのページ（例：A4用紙）にどのように配置するか、という見た目（レイアウト）を決定するプロセスである。どのテキストをどこに、どの画像をどの位置に表示し、どこでページを区切るかといった、文書全体の構造と見た目を決定する、非常に複雑で計算負荷の高い作業だ。もう一つは「スタンピングCPU」という作業で、これはすでにレイアウトが決定され、ページの形ができあがっているPDFファイルに対して、後からウォーターマークのような要素を追加で描画するプロセスを指す。このスタンピング作業は、すでにページの構造が確定しているため、新たにレイアウトを計算し直す必要がなく、比較的少ない計算量で済む。

従来のPDF生成システムでは、各受信者向けのPDFに異なるウォーターマークを入れる際、それぞれのPDFごとに文書全体のレイアウトを最初から再実行してしまうことが多い。これは、ウォーターマークの内容が少しでも変わると、システムが文書全体を新しいものとして扱い、レイアウト計算も一からやり直すためである。先の例のように18万個のPDFを作成する際、もし一つのPDFのレイアウトに1.8秒かかるとすると、合計で約90CPU時間もの計算コストが発生してしまう。しかし、スタンピング方式でウォーターマークを入れるだけであれば、同じ18万個のPDF作成にかかる時間はわずか約2CPU時間で済む。その差は実に45倍にも達し、従来の方式が計算リソースにとって大きな負担（CPUバウンド）となっていることがわかる。

PDFのレイアウト生成がこれほど難しいのには、いくつかの理由がある。第一に、ウェブブラウザの画面は必要に応じてスクロールすることで無限に情報を表示できるが、PDFは限られた枚数の有限なページにすべての情報を収める必要があるという制約がある。このページ分割（Pagination）のプロセスは非常に複雑で、例えばフォントが少し変わるだけで文字の幅が変わり、それによって改行位置がずれて、最終的に文書全体のページ数が変わってしまうことがある。このような連鎖的な変化を正確に調整するためには、何度も計算を繰り返す（マルチパス処理）必要がある。第二に、HTMLの見た目を定義するCSSには印刷用の特殊な指定（@pageなど）があるが、PDF生成エンジンによってこれらのサポート状況が異なり、予期せぬレイアウトの崩れが発生することがある。第三に、フォントの問題がある。画面表示では代替フォントが使われても見た目が少し変わる程度だが、PDFではフォントが変わると文字の幅が変化し、改行やページ分割に影響を与える。このため、PDFには使用するフォントを埋め込み、さらに使われている文字だけを抜き出す（サブセット化）のが一般的だが、この処理が「完全に同一のPDFを再現する」という要件を満たすことを難しくする原因にもなる。第四に、CSSとPDFで座標系の考え方が異なるため、正確な印刷結果を得るための細かい調整が難しいという点も挙げられる。

これらの問題を解決し、コストを大幅に削減するための新しいアプローチは、「レイアウト」と「スタンピング」の作業を完全に分離することである。具体的には、まず文書の元データからPDFのレイアウトを一度だけ実行し、その結果を「変更されないオリジナルPDF」として保存する。このオリジナルPDFは、その内容を表すハッシュ値（SHA-256）で管理される。次に、各受信者向けのウォーターマークを付与する際は、この保存されたオリジナルPDFに、後からウォーターマークを「オーバーレイ」（上書き）として描画する。この方式では、元の文書の文字の幅を再測定したり、改行位置を再計算したりする必要がないため、CPUコストが劇的に削減される。処理の負担は、主にストレージからの読み書き（I/O）にかかる時間（I/Oバウンド）に移り、CPUバウンドよりもはるかに安価に大量のPDFを処理できるようになる。

このアプローチは、ストレージコストの削減にも大きなメリットをもたらす。従来の方式で18万個のPDFを7年間保存する場合、数十テラバイト（21TB）ものストレージが必要になる可能性がある。しかし、新しいアプローチでは、ウォーターマーク付きのPDFファイルは共有期間が過ぎたら削除し、代わりに不変のオリジナルPDFと、ウォーターマークを付与したという「発行記録（レジャー）」だけを保存する。この発行記録は、オリジナルPDFのハッシュ値や受信者情報など、わずか数百バイトのデータで構成されるため、必要なストレージ容量を劇的に減らすことができる。

ただし、この新しいアプローチにはいくつかの重要な注意点がある。一つ目は、オーバーレイ方式ではウォーターマークが文書のレイアウト（文字の配置や改ページ）に影響を与えてはならない。もしウォーターマークが本文のテキストに回り込むように配置されたり、受信者ごとにページ番号が変わるようなカスタマイズされた表紙が必要だったりする場合は、オーバーレイでは対応できず、従来のレイアウトを再実行する方式に戻す必要がある。二つ目は、セキュリティに関する懸念である。オーバーレイ方式で追加されたウォーターマークは、PDF編集ツールを使えば比較的簡単に削除できてしまう可能性があるため、悪意を持った情報漏洩者に対する改ざん防止や漏洩防止のコントロールとしては弱い。これは偶発的な情報漏洩時の追跡には有効だが、より強力なセキュリティ対策が必要な場合は、別の方法を検討する必要がある。

三つ目は、「再現性」と「法規制」の問題である。ウォーターマーク付きPDFを削除し、必要な時にオリジナルPDFと発行記録から再生成する方針は効率的だが、完璧な再生成には、オリジナルPDFだけでなく、ウォーターマークを適用した際のレンダラーの正確なバージョン、使用したフォント、ウォーターマークのポリシーなど、すべての情報が正確に保持され、いつでも利用できる状態である必要がある。これらの情報が欠けていると、元のPDFと寸分違わない「バイトレベルでの完全な再現」は不可能になる。法的な紛争の場で「この文書がその時の正確な実物である」と証明できることは非常に重要であり、再生成では不十分とみなされる場合もある。さらに、金融業界など特定の分野では、記録を「そのままの形で保存する」ことを義務付ける厳しい法規制が存在し、このような場合、再生成は「保存」とはみなされないため、ウォーターマーク付きのPDFファイルそのものを永続的に保存する以外の選択肢はない。

したがって、PDFにウォーターマークを付与する際の最適なアプローチは、目的と要件に応じて慎重に判断する必要がある。もしウォーターマークが文書のレイアウトに影響を与える必要がある場合は、CPUコストが高くても、毎回レイアウト処理を伴うPDF生成方式を採用すべきである。一方、ウォーターマークがレイアウトに影響を与えず、単に既存のページにスタンプするだけで良い場合は、一度だけレイアウトされたオリジナルPDFを保存し、それに対してウォーターマークをオーバーレイ方式で付与し、各受信者向けのコピーは一時的に保存して、共有期間が過ぎたら削除するという方式が、コスト効率の観点から非常に優れている。ただし、規制当局が「発行されたPDFはそのままの形で保存しなければならない」という意見を持っている場合、その法的な要件が最優先されるため、コストがかかってもウォーターマーク付きのPDFファイルを永続的に保存する必要がある。システムエンジニアを目指す者にとって、このような費用、利便性、セキュリティ、法的要件といった多様な要素を考慮し、要件に応じて最適な技術選択を行う能力を養うことは非常に重要である。