監査に強い記録（Audit-Ready Record）とは？改ざん検証・タイムスタンプで"証拠になる"データの作り方
製造記録や検査成績書（CoA）をPDFにしてサーバーに保存し、システムの操作ログを残していれば「ペーパーレス化も監査準備も完了」——多くの現場はそう考えます。しかし、ISO 9001／IATF 16949 が求める「証拠の確実性」や、製造物責任法（PL法）の「立証責任」の観点では、それだけでは法的に脆いことがあります。この記事では、"本当に証拠になる記録（Audit-Ready Record）"とは何か、その技術的要件を、日本の制度も含めて整理します。
なぜ「PDF保存＋操作ログ」では不十分なのか
通常のファイルシステム上のPDFは、管理者権限（root／Admin）を持つ人であれば、ファイルのタイムスタンプ（作成・更新日時）の変更やバイナリの直接編集が技術的に容易です。訴訟や厳格な監査で「この記録は、事故の後にバックデート（日付を遡らせて）作り直したものではないと、第三者の技術的根拠をもって証明できるか？」と問われたとき、暗号学的な裏づけのないファイルは反論しにくいのです。PL法ではメーカー側が「出荷時点で品質規格を満たしていた」等を立証する必要があり、書き換え可能なデータは「自社に都合よく後から変えられる」とみなされ、証拠能力を否定されるリスクがあります。
「監査に強い記録」の3要件
- 存在証明と非改ざん性（Integrity）：その時刻に、その内容で存在し、以降1バイトも変わっていないことを示せる
- 時刻の第三者証明：作成時刻を、自社ではなく信頼できる第三者（時刻認証局）が保証する
- 変更の完全な追跡（オーディットトレイル）：誰が・いつ・何を変えたかが、後から消せない形で残る
改ざん検証を支える技術
| 技術 | 役割 |
|---|---|
| ハッシュ関数（SHA-256） | ファイルから固定長の"指紋"を計算。1バイト変わると指紋が全く変わるので、改ざんを検知できる |
| 電子署名（PKI：公開鍵基盤） | 秘密鍵で署名し、公開鍵で検証。作成者の証明と非改ざんを担保する |
| タイムスタンプ（TSA／RFC 3161） | 時刻認証局が「その時刻に存在した」ことを証明する |
| PAdES／PDF/A-3 | PDFに長期署名・タイムスタンプを埋め込み、長期保存する国際規格 |
| WORM（Write Once Read Many） | 一度書いたら書き換え・削除ができないストレージ |
これらを組み合わせると、検査完了や出荷判定が確定した瞬間に、次の流れで「改ざん検証付きPDF」が自動生成されます。以降、1バイトでも書き換えるとビューアや検証プログラム上で「改ざんあり」が検知される構造になります。
検査完了／出荷判定が確定
PDFを生成（長期保存用 PDF/A-3）
ドキュメントのハッシュ（SHA-256）を算出
時刻認証局（TSA）でタイムスタンプ付与（RFC 3161／PAdES）
改ざん検証付きPDFとして保存（WORM）
日本の制度 ― タイムスタンプ認定制度と電子署名法
日本では2021年7月から、総務大臣による「時刻認証業務の認定制度（タイムスタンプ認定制度）」が始まりました（タイムスタンプについて／総務省）。認定タイムスタンプは、情報通信研究機構（NICT）が管理する国家標準時（UTC(NICT)）を時刻源とし、RFC 3161準拠で「その時刻に存在し、以降改ざんされていない」ことを証明します。あわせて、電子署名の法的効力の土台を定める「電子署名法（電子署名及び認証業務に関する法律）」があります。電子証明書には有効期限があるため、長期に証拠性を保つには、期限が切れる前にタイムスタンプを施し続ける「長期署名（PAdES 等）」が用いられます。
ハッシュチェーンで守る「監査ログ」
記録の変更履歴（監査ログ）そのものが改ざんされては意味がありません。そこで、各ログレコードに「直前のログのハッシュ値」を組み込む"ハッシュチェーン（ブロックチェーン型）"を使うと、過去のログを1件でも書き換えたり削除したりした瞬間、以降のチェーンの整合性が崩れ、改ざんが一発で検知されます。データベース管理者が直接SQLで書き換えても検知できる——これが「アクセス権限管理だけに頼らない」強さです。
【参考】規格を横断する「ハブ・データモデル」（理想モデル）
以下は、あらゆる製造履歴・検査結果と改ざん検証メタデータを1対1で結びつけ、監査要求に即応するための理想的な参照データモデルです（特定製品の実装ではありません）。
PDF改ざん検証マスター（pdf_verifications）
| 論理名 | 物理カラム名 | 型 | 説明 |
|---|---|---|---|
| 検証ID | verification_id | VARCHAR(64) | 一意に発番するID |
| 紐付け対象 | target_entity / _id | VARCHAR | 検査成績書・バッチ記録・出荷など、対象と対象ID |
| PDFハッシュ | pdf_sha256_hash | VARCHAR(64) | 生成直後のPDFのSHA-256値 |
| TSA時刻 | tsa_timestamp | TIMESTAMP | 時刻認証局が保証した絶対時刻 |
| TSトークン | tsa_token_blob | BLOB | RFC 3161準拠の暗号トークン |
| 保管URI | storage_uri | VARCHAR(255) | WORMストレージのパス |
不可逆型監査ログ（audit_logs）
| 論理名 | 物理カラム名 | 型 | 説明 |
|---|---|---|---|
| ログID | log_id | BIGINT | 自動採番 |
| 発生日時 | event_timestamp | TIMESTAMP | サーバーの高精度時刻 |
| 実行ユーザー | actor_user_id | VARCHAR(32) | 操作を行った人 |
| 操作種別 | action_type | VARCHAR(16) | CREATE／UPDATE／APPROVE／VOID |
| 対象キー | resource_key | VARCHAR(128) | 例：material_lots:LOT123 |
| 変更差分 | payload_json | JSONB | 変更前後の完全なDiff |
| 前ログのハッシュ | previous_log_hash | VARCHAR(64) | ハッシュチェーン用 |
| 自ログのハッシュ | current_log_hash | VARCHAR(64) | 本レコード全体のSHA-256値 |
規格・法との対応
- ISO 9001／IATF 16949（7.5 文書化された情報 ほか）：記録の保持・改ざん防止・必要時の検索性が求められる（ISO9001／IATF 16949）
- PL法：出荷時点の品質を客観的に立証する証拠になる（PL法、初動はリコールに備えるトレーサビリティ）
- FDA 21 CFR Part 11（米国）：医薬・医療機器などで、電子記録・電子署名の信頼性要件を定める
よくある誤解
- 「PDFにして保存すれば証拠になる」：改ざん検証がなければ、後から作り直した疑いを晴らせません
- 「アクセス権限を厳しくすれば十分」：管理者権限があれば改ざん可能。ハッシュ・署名・チェーンという技術で担保します
- 「自社サーバーの時刻でOK」：時刻は第三者（認定タイムスタンプ）が証明してこそ、バックデート疑惑に反論できます
まとめ
- "証拠になる記録"とは、画面を印刷したPDFやCSVの保管ではなく、改ざんを技術的に検証できる記録
- 要件は「非改ざん性・時刻の第三者証明・変更の追跡」。SHA-256・電子署名・タイムスタンプ・ハッシュチェーンで担保する
- 日本には総務省のタイムスタンプ認定制度（2021年〜）があり、NICTの標準時を時刻源に証明できる
- ISO/IATFの記録要求やPL法の立証、FDA 21 CFR Part 11 まで、記録の"確実性"が問われる時代
この分野を扱うなら ― QUALIKEEP でできること
ここまでは「監査に強い記録」そのもの（技術要件・日本の制度・データモデル）を解説してきました。最後に、現場レベルでこれを実践する一例として QUALIKEEP に触れておきます。QUALIKEEP は、出力するPDFに固有のQRを付け、第三者がデータベースと直接照合して「発行後に書き換えられていないか」を検証できる改ざん検証付きPDFと、誰が・いつ・何を変えたかを残す監査ログを備えています。ただし、RFC 3161準拠の認定タイムスタンプやPAdES長期署名そのものを実装するものではなく、それらが必要な場合は専用のTSA・署名基盤と併用してください。原材料まわりの受入・期限・ロットの記録を、後から書き換えにくい形で残したい場合の選択肢になります。
監査やPL対応に耐える記録を、現場のスキャンと改ざん検証付きPDFで残しませんか。
QUALIKEEP の機能や料金を詳しく見る →ご注意
本記事は一般的な考え方と公開情報を整理したものです。タイムスタンプ・電子署名・長期署名や各規格・法令の正確な要件は、総務省・NICT・所管省庁や各規格の最新情報をご確認のうえ、具体的な対応は専門家にご相談ください。
参考・出典
※ 外部サイトの内容・URLは変更される場合があります。最新の情報は各機関の公式ページをご確認ください。