【ITニュース解説】Go PDF Decrypt Wrong Password Error Explained — Supplier Invoice Handling

サプライヤーから送られてくるPDF形式の請求書をシステムで自動処理する際、添付されたPDFファイルがパスワードで保護されているケースは少なくない。しかし、そのパスワードを使って復号しようとしたときに「パスワードが間違っている」というエラーが発生することがある。この記事は、このエラーがなぜ発生するのか、そしてシステムエンジニアとしてどのように対処すべきかを解説する。

まず重要なのは、「パスワードが間違っている」というエラーメッセージが、必ずしもサプライヤーが実際に間違ったパスワードを提供したことを意味するわけではないという点だ。このエラーは、現在利用しているパスワードではPDFファイルを開けなかったという事実を伝えているに過ぎない。原因としては、ファイルの一部が転送中に失われ破損している可能性、パスワード自体が途中で改ざんされた可能性、あるいはPDFの暗号化方式がシステムで利用しているPDFリーダーやライブラリではサポートされていない可能性などが考えられる。国際標準であるISO 32000-2でPDF形式が定義されていても、すべてのツールがすべての暗号化されたPDFを開けるわけではない。これらの可能性をただの言い訳とせず、検証すべき仮説として捉える必要がある。

このようなエラーが発生した際の基本的な対処法は、同じパスワードで何度も復号を試みないことだ。問題のあるサプライヤーからの暗号化PDFは、まずは隔離し、元のバイト列をそのままの状態で保存しておくべきである。そして、承認された経路を通じて、サプライヤーに正しいパスワードや別の認証情報を改めて要求する。これは、同じパスワードで何度も試行することでシステムのリソースを無駄に消費したり、無意味なエラーを発生させたりすることを避けるためだ。

さらに、システム設計の観点からは、請求書の処理パイプラインにおいて、サプライヤーからの添付ファイル（PDF）の処理と、注文データに基づいて請求書を生成する処理とを明確に分離することが重要である。たとえば、教育機関の受発注システムのような場合、添付PDFの処理失敗が、信頼できる注文データからの請求書作成全体を妨げてはならない。もし添付ファイルが最終的な請求書に必須であるなら、添付ファイルが処理されるまで請求書の配送を保留にすべきだ。しかし、添付ファイルなしでも請求書が発行できるポリシーなら、添付ファイルは「保留中」として処理を進めるべきである。決して、存在しないページや処理に失敗したページが正常に表示されたかのように見せてはならない。この分離が重要なのは、一つの問題ある添付ファイルが、何度も復号とレンダリングを繰り返すことで、システムの処理能力を不必要に大きく消費してしまうのを防ぐためだ。添付ファイルの検査専用のキューや、同時に処理できる数の上限を設けることで、他の重要な処理が影響を受けるのを防げる。エラーの件数だけでなく、処理待ちの注文がどれくらいの時間滞留しているか（キューの滞留時間）にも注目し、サービスレベル目標（SLO）と比較して監視することが重要だ。エラー率が横ばいでも、キューの滞留時間が伸びていれば、それは問題の兆候である。

入力されたPDFファイルが暗号化されているのか、破損しているのか、それとも単にパスワードが一致しないだけなのかを区別するには、まず受け取ったバイト列を正確に記録することから始める。暗号学的ハッシュ値（例えばSHA256）、バイト数、受信時刻、そして機密性のない相関IDを記録し、再試行の際にはこれらの情報、特にハッシュ値が変更されていないかを確認する。パスワード、抽出されたテキスト、請求書の内容、生のPDFデータそのものはログに記録してはならない。転送が完全であったこと、そして認証情報が正しいサプライヤーとドキュメントバージョンに対応していることを確認する。ハッシュ値が変わっていれば、それは異なる入力と見なし、新たに検査する必要がある。

次に、この入力ファイルを隔離された環境で解析し、構造的な破損、暗号化されていること、サポートされていないセキュリティパラメータの使用、そして認証失敗（パスワード間違い）といった状態を明確に区別する。これらの区分はシステム内部の診断状態であり、エンドユーザーに直接表示するメッセージではない。パスワードが正しく、ファイルが開いたとしても、まだページ抽出やレンダリングに失敗する可能性はあるため、認証成功は処理の途中段階であり、請求書処理が完了したことを意味するものではない。暗号化されたサプライヤー資料へのアクセスは、検査を担当するワーカーに限定し、データの保持ポリシーに従って管理すべきである。

PDFの解析機能については、外部のマネージドサービスを利用するか、自社で構築・運用するかという選択がある。外部サービスを利用する場合、認証情報やファイルの内容が外部で処理・保存されることのポリシー的な許容性、サポートされていない暗号化方式の報告方法、サービスの同時実行制限や障害分離の能力、そしてオンコール体制でのエラー分類とエスカレーション手順を明確にする必要がある。一方、自社で構築・運用する場合、認証情報の受け渡し、メモリ上での寿命、削除方法、解析能力の維持とアップグレードテスト、ワーカーの処理能力の確保と飽和アラート、そしてパッチ適用やインシデント対応まで、プラットフォームチームが責任を持つ必要がある。どちらの選択肢も、パスワード間違いそのものを解決するものではないが、どの境界で失敗を分類し、どのようにデータを管理・監査できるかという観点で選択すべきである。

入力処理の境界は、注文データの検証とサプライヤーPDFの処理を独立させるべきだ。Go言語での例では、Inspectorというインターフェースを定義し、これが実際のPDF解析処理を担当するようにしている。これにより、解析処理を隔離し、時間やメモリの使用制限を強制できる。Inspect関数は、元のドキュメントのバイト列からハッシュ値（ダイジェスト）を計算し、その結果と解析ステータス（準備完了、認証情報が必要、未サポート、不正なPDFなど）を返す。この際、認証情報やドキュメントの内容をログに記録することは避ける。各ハッシュ値と認証情報のバージョンに対して、検査処理はべき等であるべきだ。つまり、同じ入力に対しては常に同じ結果を返す。新しいバージョンの認証情報が提供された場合のみ、再検査を行う。

請求書の正確性（Fidelity）は、添付ファイルの処理とは別の検証ゲートとして扱うべきである。正規化された注文データに基づいて請求書をレンダリングし、その結果の金額、ページ数、添付ファイルの有無が注文の配送ポリシーと一致するかを確認する。PDFが開けたからといって、それが常に正確な請求書であるとは限らない。もし添付ファイルが最終的な請求書に含まれる必要がある場合、そのページのレンダリングにかかる時間や容量をキャパシティプランニングで考慮する必要がある。しかし、添付ファイルが単にレビューのための証拠として保持されるだけであれば、請求書の再試行のたびに何度もレンダリングし直す必要はない。

システムの回復力とロールバックの能力を確保するためには、テストが不可欠である。正常に開けるPDF、間違ったパスワードで暗号化されたPDF、同じファイルの正しいパスワード、破損した入力ファイル、そして選択したパーサーがサポートしないファイルなど、様々なテストケースを用意する。ハッシュ値と認証情報のバージョンが変わらない限り、再検査がトリガーされないことを検証する。添付ファイルなしでも請求書が許可されるポリシーと、添付ファイルが必須で保留されるポリシーの両方についてテストを行う。出力される金額が、添付ファイルから抽出されたテキストではなく、正規化された注文データに紐付いていることを確認することも重要だ。

システムをデプロイした後も、継続的な監視が不可欠である。検査キューの滞留時間、各結果の種類ごとのカウント、ワーカーの飽和状態、そして請求書の配送遅延を測定する。メトリクスのラベルは、サプライヤーIDやドキュメントのハッシュ値のような詳細な情報は含まず、低カーディナリティ（種類が少ない）に保ち、診断用の詳細記録とは別に管理する。新しい処理経路（インテークパス）が文書を誤分類するような事態が発生した場合、直ちに新しい検査のディスパッチを停止し、入力を最後に検証された安定した経路に戻す。既存の保留中の文書とその元のバイト列は、再検査のために変更せず保持する。キューをクリアするために、添付ファイルの要件を無効化するような安易な対処は避ける。システムが完全に回復したと言えるのは、修正されたドキュメントが検査に合格し、請求書が独立した正確性チェックをパスし、配送状態がポリシーと一致した時である。堅牢なシステムは、このような多層的な検証と回復の仕組みによって実現される。