lab / notes
監査証跡とは何を残すことなのか — 21 CFR 11.10(e) と ALCOA+ を自分の製品に当てる
条文が要求している5つのことを分解し、自分の電子実験ノートに当てたら「監査証跡」と名乗っていた機能が要件をほとんど満たしていなかった、という話。
電子実験ノートに「監査証跡があります」と書くとき、何を残していれば嘘にならないのか。条文から順に読み直しました。結論を先に書くと、私の製品は嘘に近いことを書いていました。
1. 21 CFR 11.10(e) は5つのことを要求している
米国 FDA の 21 CFR Part 11 §11.10 は、クローズドシステムに対する管理要件を (a) から (k) まで並べた条文です。監査証跡はその (e) にあります。要点を分解するとこうなります。
| # | 要求していること | 一言でいうと |
|---|---|---|
| e-1 | 安全で・コンピュータが生成し・時刻印のついた監査証跡を使う | 人が手で書く記録ではなく、システムが自動で刻む |
| e-2 | 記録を作成・変更・削除した操作者と日時を、独立に記録する | 作成だけでは足りない。操作者自身が消せない形で |
| e-3 | 記録の変更は、以前に記録された情報を隠してはならない | 上書きではなく追記。変更前の値が読めること |
| e-4 | 監査証跡は、対象の記録の保存期間と少なくとも同じ期間保存する | 記録を残す限り証跡も残す＝バックアップの対象 |
| e-5 | レビューとコピーに供せること | 見る手段と、持ち出す手段の両方が要る |
原文は eCFR の §11.10 で読めます。ここで効いてくるのは e-2 の「独立に（independently）」 と e-3 の「隠さない」 です。この2つは、実装としては「追記専用（append-only）」と「変更前の値を残す」に翻訳されます。
(e) だけ読むと落とすもの
監査証跡は (e) に閉じていません。同じ §11.10 の中で、
- (a) バリデーション は「無効な、あるいは改変された記録を識別できること」を求めています。これは「証跡が改ざんされていないと示せるか」という話で、後で出てくるハッシュ連鎖の動機になります
- (d) アクセス制限 は権限のある者だけに使わせることですが、裏を返すと「誰がいつ誰に権限を与えたか」も記録の対象です。権限変更そのものが監査事象になります
- (b) 正確で完全な複製 は人が読める形と電子形式の両方を求めます。証跡も複製の対象です
さらに FDA は 2003 年のガイダンス（Part 11 — Scope and Application）で、Part 11 の適用範囲を狭く解釈し、監査証跡についても「その分野の本則（predicate rule）とリスクに基づいて必要性を判断せよ」としています。ここを「だから要らない」と読むのは誤りで、記録の作成・変更・削除を残すことはGLP など本則の側が求めている、というのが正しい読み方だと理解しています。
2. 日本側は「真正性・見読性・保存性」で言う
日本で医薬品の承認申請に関わる電磁的記録を扱うときは、いわゆる ER/ES 指針（2005年）が基準になります。求めているのは3つです。
| 要件 | 中身 | Part 11 でいうと |
|---|---|---|
| 真正性 | 完全・正確で、故意や過失による書き換え・消去から保護されている。監査証跡・アクセス制限・バックアップ | (e) と (d) |
| 見読性 | 内容を必要に応じて表示・印刷できる | (b) |
| 保存性 | 保存期間中、真正性と見読性が保たれる | (c) |
GMP 下のシステムであれば、これに コンピュータ化システム適正管理ガイドライン（2010年）が重なり、システムのライフサイクル管理・供給者アセスメント・バリデーション文書が要求されます。実務では「Part 11 対応」という一語が、この日本側の枠組みとセットで読まれているように見えます。
3. PIC/S Annex 11 が足してくる3つ
コンピュータ化システムについての国際的な GMP の付属書（PIC/S / EU GMP の Annex 11）には、監査証跡の項があります。Part 11 (e) に無い要求が3つ入っています。
- 変更・削除の理由を文書化する — 「誰がいつ何を」に加えて「なぜ」
- 定期的にレビューされる — 記録するだけでなく、人が読む前提。つまり絞り込める画面が要る
- 一般に理解できる形式に変換できる — 生の JSON を出して終わりにはできない
紙の実験ノートで「二重線で消して、日付とサインと理由を書く」と教わるあの作法が、電子でもそのまま要求されている、と読むと腑に落ちます。GLP でも生データの訂正は元の記載を判読できる状態で残し、訂正者・日付・理由を記すことになっています。
4. ALCOA+ に当てて、自分の製品を採点する
当局が共通して使うデータインテグリティの原則が ALCOA+ です。実装の状態（2026-09-22 時点の v1.3.x）を正直に並べます。
| 原則 | 意味 | Erlen の実際 |
|---|---|---|
| Attributable | 誰が行ったか | △ 記録者は残るが、反応テーブルを保存したときだけ |
| Legible | 読める・意味が分かる | ✕ 証跡を読む画面も API も無い |
| Contemporaneous | 行ったその時に記録 | △ 保存時に記録（同上、分子のみ） |
| Original | 原本または真正な複製 | △ スナップショットはあるが対象が狭い |
| Accurate | 誤りがない・改変されていない | ✕ データベースを直接触れば書き換えられる |
| +Complete | 削除も含めて全部 | ✕ 本文編集・確定・確定取消・削除・台帳・権限変更・ログインが未記録 |
| +Consistent | 時系列が矛盾しない | ✕ 連番も順序の保証も無い |
| +Enduring | 保存期間中残る | ○ 追記専用のトリガあり・バックアップ対象 |
| +Available | 必要なとき取り出せる | ✕ 取り出す手段が無い |
○が1つ、△が3つ、✕が5つ。 これが「監査証跡があります」と書いていた製品の実態でした。
具体的には、改訂履歴を書き込んでいるのは反応テーブルの保存処理1か所だけで、ページの本文・タイトル・実験日を編集しても、確定しても、確定を取り消しても、削除しても、記録は1件も増えません。さらに確定の取り消しは、編集権限があれば誰でも、理由も記録も無しに実行できます。
5. どう作り直すか（P0 で入れるもの）
audit_eventsテーブルを新設し、全ての書き込み操作を記録する。列は「誰が・いつ・何に対して・何をして・変更前は何で・変更後は何で・理由は何か」- 追記専用（UPDATE と DELETE をデータベースのトリガで拒否）
- ハッシュ連鎖 — 各行が直前の行のハッシュを含む。1行でも消す・書き換えると、それ以降が全部合わなくなる。テナントごとの連番も持たせ、欠番があれば分かるようにする
- 業務の書き込みと同じトランザクションで記録する — 記録できなければ業務の書き込みも失敗する。「監査証跡の無い変更」が残る隙間を作らない
- 読む手段 — 操作ログの一覧、ページ単位の履歴、期間や人での絞り込み、JSONL での書き出し
- 検証コマンド — 連鎖が切れていないかを導入者が自分で確認できるコマンド
設計で迷って、こう決めたこと
- 規制モードでだけ記録する、にはしない。 監査証跡は規制の有無と関係なく記録の信頼性そのものなので、常時オンにする
- 本文そのものは監査証跡に二重保存しない。 自動保存のたびに本文が丸ごと積み上がるため、監査証跡にはハッシュと長さだけを置き、本文の実体は改訂履歴のスナップショットに残す
- ハッシュ連鎖には限界がある。 データベースとコードの両方を握れる人は、連鎖ごと作り直せます。これは「導入者が自分のクラウドにデータを持つ」という設計の構造的な限界で、隠さずに書いておきます。実務的な補いは、外に持ち出した記録を別の場所で保管する運用のほうです
- 過去のデータは遡って証跡を合成しない。 「コンピュータが生成した・その時に記録した」ものではなくなるからです。適用した時点から連番1で始めます
くわしい設計の分かれ道は決定記録に並べています。
6. まだ決めかねていること
現場で規制対応をしている方の感覚を聞きたい点がいくつかあります。レビュー依頼にまとめました。監査証跡のレビューは誰がどの頻度で行うのか、変更前後は差分で見たいのか、理由の入力は選択式と自由記述のどちらが実務に合うのか、といった問いです。
この記事で書かなかったこと: 「適合」「保証」「認証取得」。これらはソフトウェア単体では成立しません。ここで言えるのは、条文が求める技術的な仕組みを実装した、ということまでです。