デジタル署名が重要な理由

デジタル署名は、電子取引の法的基盤となっています。契約書、請求書、規制当局への提出書類であれ、署名は署名者を内容に結び付け、否認防止、完全性、タイムスタンプの証拠を提供します。裁判所やコンプライアンス監査人は、正しく署名されたPDFやXML文書を、紙に書かれたインク署名と同等に扱うケースが増えています。そのため、署名が失われる、あるいは適切に再署名せずに署名済みデータを変更すると、文書全体が無効となり、組織は法的リスクにさらされ、コストのかかる再作業を余儀なくされます。金融、医療、政府といった分野では、電子記録への信頼が必須であるため、リスクは特に高くなります。

変換が署名を壊す可能性

ファイルの変換はほとんど中立的な操作ではありません。埋め込みPKCS#7署名を含むPDFを画像にフラット化すると、暗号的なシールが失われます。変換ツールの中にはXML‑DSig要素を除去したり、証明書参照を削除したり、ファイルのバイト構造を書き換えたりするものがあり、署名が保護しているハッシュが変わってしまいます。画像の再圧縮、改行コードの変更、PDFバージョンの変更といった一見無害な操作でも、ツールが署名済みバイト範囲を保持しないと署名が無効になることがあります。その結果、見た目は元と同じでも検証に失敗する文書となります。

出会う可能性のあるデジタル署名の種類

署名形式を理解することで、変換手法の選択が導かれます。

  • PDF署名 – PDFカタログに埋め込まれ、定義されたバイト範囲をカバーします。PDF/A‑3やPDF/Eは署名を保持できますが、PDF/A‑1は署名を除去します。
  • XMLデジタル署名 (XML‑DSig) – 電子インボイス(PEPPOL)やe‑調達、政府の多くのフォームで使用されます。<Signature>要素はそのまま保持する必要があり、空白文字の変更でもハッシュが無効になることがあります。
  • CMS/PKCS#7コンテナ – Office Open XMLファイル(.docx、.xlsx)に別個のSignatureパートとして付与されることが多いです。パートの階層が保持されれば、フォーマット変更後もコンテナは生き残ります。
  • 分離署名 – 元文書を参照する別ファイル(例:.p7s)です。元ファイルの名前変更や移動を伴う変換は、署名ファイルが更新されない限りリンクが切れます。

変換前チェックリスト

バッチ変換または単一ファイル変換を開始する前に、以下の手順を確認してください:

  1. 署名タイプの特定 – 署名の詳細を表示できるビューア(Adobe Acrobat、XMLSec、OpenSSLなど)を使用します。ハッシュアルゴリズム、署名証明書、範囲(文書全体か選択フィールドか)を確認してください。
  2. 署名の有効性確認 – 現在署名が有効かどうか検証します。変換前に壊れた署名が、変換後に自動的に有効になることはありません。
  3. 変換先フォーマットの決定 – すべてのフォーマットが署名を保持できるわけではありません。対象フォーマットが署名に対応していない場合は、アーカイブ用に元の署名付きコピーを残すことを検討してください。
  4. 読み取り専用バックアップの作成 – 署名済みファイルのコピーを安全な場所に保存します。これにより、変換中の偶発的なデータ損失から保護できます。

署名に優しい変換先フォーマットの選択

変換が不可避な場合は、署名タイプを明示的にサポートするフォーマットを選びます。

  • PDF → PDF/A‑3 – PDF/A‑3は任意のファイル(署名コンテナを含む)を埋め込めるため、視覚的な忠実性を保ちつつ署名を保持できます。
  • DOCX → DOCX – 同じOOXMLコンテナにWord文書を再エクスポートすれば、変換エンジンがSignatureパートを書き換えない限りCMS署名が保持されます。
  • XML → XML – 空白文字を再整形しないXSLT対応の変換を使用します。元のXML宣言と名前空間プレフィックスを保持してください。
  • 画像ベースのスキャン → PDF(署名レイヤあり) – 元の文書がデジタルシール付きのスキャン画像として署名されている場合、画像をPDFに埋め込み、署名を注釈として保持し、フラット化しないようにします。

署名を保持する変換ワークフロー

以下は、手動でもスクリプトで自動化しても実装可能な、実践的なステップバイステップのワークフローです。

  1. 署名の抽出(オプション) – 署名を保持できないフォーマットの場合、openssl cms -verify -inform DER -in sig.p7s -noout のようなツールでCMS/PKCS#7ブロブを抽出します。別ファイルとして保存してください。
  2. コアコンテンツの変換 – 「メタデータ保持」フラグを提供する変換エンジンを使用します。多くのクラウドサービスはAPIパラメータでこれを指定できます。たとえば、convertise.app を使う場合は、"keep original signatures"(元の署名を保持)オプションを選択できます。
  3. 署名の再埋め込み – 変換先フォーマットが埋め込みをサポートしている場合、署名ブロブを適切なコンテナに戻します(例:XML文書に<Signature>要素を追加、またはDOCXのzipアーカイブにCMSパートを埋め込む)。
  4. 署名バイト範囲の再計算 – PDF署名の場合、バイト範囲は/ByteRange配列で定義されています。再埋め込み後に追加されたオブジェクトを反映するよう配列を更新します。iText 7 や PDFBox といったライブラリは、暗号シールを無効にせずに署名ディクショナリを再構築するAPIを提供しています。
  5. 結果の検証 – 信頼できるビューアで変換後のファイルを開き、検証チェックを実行します。PDFの場合、Acrobat が緑のチェックマークで署名が有効であることを示します。XMLの場合、適切なスキーマと署名ファイルを指定して xmllint --verify を実行します。
  6. 最終ファイルのハッシュ記録 – 変換後の文書の SHA‑256 ハッシュを改ざん検知可能なログに保存します。これにより、変換後も署名が保持されたことを示す監査証跡が残ります。

クラウド変換とプライバシーの懸念

変換をSaaSプラットフォームに委託すると、利便性と管理性のトレードオフになります。ファイルをメモリ上だけで処理し、セッション終了後に削除するプライバシー重視のサービスはリスクを低減しますが、サニタイズパイプラインで署名が除去されないことを確認する必要があります。プロバイダーのプライバシーポリシーを確認し、データ処理契約を求め、可能であれば機密でない署名済み文書で試験変換を行い、署名が保持されることを確認してください。

変換後の署名検証

変換は表面的に成功しても、裏で署名が破損していることがあります。系統的な検証によりこのリスクを軽減できます:

  • 自動バッチ検証 – PDF には pdfsig(Poppler)、XML には xmlsec1、CMS ファイルには openssl cms を用いたスクリプトで、変換後のフォルダー内のファイルを走査し、合否レポートを生成できます。
  • 目視確認 – 変換後のファイルのサンプルを元の署名アプリケーションで開き、署名パネルを確認し、署名者名とタイムスタンプをチェックします。
  • 証明書失効チェック – 署名に使用された証明書が有効で失効していないことを確認します。変換サービスによっては CRL や OCSP 情報が除去されることがあるため、必要に応じて再添付してください。

よくある落とし穴と回避策

落とし穴署名が壊れる理由対策
PDF を画像 (PNG/JPEG) に変換するファイルがラスタ画像になるため、署名済みバイト範囲が失われます。法的目的のために PDF コピーを保持し、画像は新しい PDF に埋め込んで再署名は行わない。
XML を異なる文字セットで再エンコードする正準形が変わり、ハッシュが破壊されます。元の UTF‑8 エンコーディングを保持し、空白文字を変える整形は避ける。
PDF オブジェクトを “最適化” する変換器を使用するオブジェクトストリームが書き換えられ、署名が参照するオブジェクト ID が変わります。最適化フラグをオフにし、構造保持モードがある変換器を選択する。
変換前にフォームフィールドをフラット化するフィールドの値がビジュアル層に組み込まれ、フィールドレベルの署名が無効になる。フィールドは編集可能なままにするか、フラット化が必要な場合は新たに署名を作成する。
分離署名ファイルを削除または名前変更する文書と .p7s のリンクが失われる。文書メタデータの参照を更新するか、署名をコンテナ内部にバンドルする。

実務シナリオ

法的契約書

法律事務所は Adobe Sign で署名された契約書を受領することが多いです。契約書を企業の DMS(文書管理システム)に保存する際に、PDF/A‑1 のみを受け付ける場合、元の署名を保持したまま変換しなければなりません。上記のワークフロー—PDF をまず PDF/A‑3 に変換し、署名ディクショナリを保持したまま PDF/A‑1 変換ツールを使用する—により、契約書は法的に有効なまま保存できます。

電子インボイス(PEPPOL)

欧州の電子インボイスでは、XML‑DSig によって請求書が認証されます。サプライヤは、独自の XML スキーマから PEPPOL BIS 形式へ請求書を変換する必要がある場合があります。<Signature> 要素を保持し、名前空間プレフィックスを正しくマッピングすれば、請求書は PEPPOL バリデータを通過し、買い手側で再署名せずに処理できます。

政府フォーム

多くの公共部門のフォームは、分離型 CMS ファイルで署名されています。部門が古い提出物を DOCX 形式で保存する新しい記録管理システムに移行する際、変換スクリプトは CMS 署名を抽出し、DOCX パッケージに埋め込み、参照テーブルを更新します。監査人は後に元の文書と比較して署名を検証できるようになります。

まとめ

ファイル変換時にデジタル署名を保持することは後付けの作業ではなく、暗号への理解、フォーマット知識、慎重なツール選択が交錯する体系的なプロセスです。署名タイプを特定し、互換性のある変換先を選択し、署名データを抽出・保持・再埋め込みする変換ワークフローを実施し、かつ自動化された検証で結果を確認すれば、組織は法的完全性を維持しつつ、現代的なファイルフォーマットの柔軟性を享受できます。convertise.app などのクラウド変換サービスをパイプラインに組み込む場合は、プロバイダーが署名コンテナを尊重し、プライバシー・バイ・デザインの方針を取っていることを確認することで、さらなる安心感が得られます。最終的に、検証を最優先とした体系的なアプローチは、コストのかかる再署名サイクルを防ぎ、すべての電子署名に込められた信頼を守ります。