意見を聞きたいこと — 監査証跡の設計で迷っている9つ（回答をもらいました）

2026-09-22 追記: 回答をいただきました。 何がどう変わったかを各問いの下に書き、決まったことは決定記録の「現場の意見を受けて決めたこと」に D-40〜D-47 として残しています。Q9 で聞かれた「PMDA に手引きはあるのか」は調べて別の記事にしました。引き続き意見は募集しています（別の現場では違う、という話がいちばんありがたいです）。

監査証跡の勉強記事を書いたあと、条文からは決められないことが残りました。どれも「現場ではどう運用されているか」を知らないと設計を誤るものです。

規制対応の実務に関わっている方、あるいは監査を受けた経験のある方の意見をいただけると助かります。GitHub の Issues か、日本語であれば Discord へお願いします。所属や具体的な社名・製品名は書かないでください。 一般論として、こういう運用が普通だ、という話で十分です。

Q1. 監査証跡の「レビュー」は、誰がどの頻度で行いますか

規制の文書には「定期的にレビューされること」とありますが、実際に誰が・どのくらいの頻度で・何を見るのかが分かると、絞り込みの設計が決まります。

期間で絞りたいのか、人で絞りたいのか、操作の種類（削除だけ、権限変更だけ）で絞りたいのか、特定のページに紐づく履歴だけを追いたいのか——どれがいちばん多い見方でしょうか。

→ 決まったこと: 「監査・査察の前にまとめて」「逸脱や調査が起きたときだけ」が実態で、定期的なレビューがいちばん抜けやすいと分かりました。「定期的に責任者が確認するよう通知がほしい」という声をそのまま受けて、未確認の記録を知らせる仕組みを作ります（D-41）。絞り込みの軸は D-45 に。

Q2. 削除した記録は、どう見えているべきですか

Erlen はページを削除しても実体は消さず、一覧から下げるだけの実装です。このとき、「削除されたページがあったこと」をどう示すべきでしょうか。

• 監査証跡に「削除した」という事象が残っていれば足りる
• 削除済みのものだけを一覧で見られる画面が要る
• 削除済みも通常の一覧に、印をつけて出ているべき

→ 決まったこと: 削除済みだけの一覧を作ります（D-44）。また「変更があったら全て理由を書いて、管理者が確認のサインをする。タイムスタンプあり」という運用像をもらったので、確認サインの記録を新設します（D-40）。なお「監査証跡は任意にしたい」は、記録を止めるのではなく理由入力を必須にするモードの ON/OFFを指していると読み替えました（D-47）。読み違いなら教えてください。

Q3. 変更前と変更後は、どう見たいですか

紙のノートなら、二重線で消した元の値がその場に見えています。電子ではどう見えていてほしいでしょうか。

• 変更前と変更後が並んで見える（差分表示）
• 変更前の値が読めれば、形式は問わない
• その時点のページ全体を復元して見られる必要がある

→ 決まったこと: 並べて差分にします（D-42）。「畳んでおいて押したら開く」案は取り下げました。

Q4. 時刻の表示はどうあるべきですか

記録は協定世界時（UTC）で持ち、画面では現地時間に直す設計にしています。現場ではタイムゾーンの明記やUTC の併記を求められることがありますか。複数の国にまたがる試験だと事情が変わりそうだと想像しています。

→ 決まったこと: 現地時間に UTC を併記します（D-43）。保存は UTC のままです。

Q5. 変更理由の入力は、どの形式が実務に合いますか

規制モードでは訂正のときに理由を必須にする予定です。そのとき、

• 自由記述だけ
• 選択式（誤記の訂正／測定のやり直し／追記／その他）＋自由記述
• 選択式のみ

のどれが現実的でしょうか。理由を書く習慣がどのくらい根付いているかも知りたいところです。自由記述だけにすると「訂正」の2文字で埋まってしまうのではないか、と懸念しています。

→ 決まったこと: 選択式＋自由記述にします（D-46）。なお調べたところ、分析装置のデータシステムでも「管理者が定型の理由を登録し、利用者はそこから選ぶ。自由記述を許すかは権限で決める」という作りが一般的で、出荷時に既定の理由リストを持っている製品は見当たりませんでした。そこで Erlen も理由リストは導入者が自分で登録する形にし、例だけ文書で示します。

Q6. クラウドは「開放系」と見なされますか

Part 11 は、システムの内容に責任を持つ者がアクセスを管理しているシステムを「閉鎖系」と呼び、そうでない場合には暗号化や電子署名の追加要件がかかります。

Erlen は導入する人自身のクラウドアカウントの中だけで動き、招待された人しか入れません。これは閉鎖系だと考えていますが、品質部門の目から見ると「クラウド＝開放系」と判断されることが多いでしょうか。その場合、何を示せば閉鎖系として扱ってもらえるのでしょうか。

→ 決まったこと: 判断の経験が無い、という回答自体が重要でした。製品が「閉鎖系です」と断言するのをやめ、判断の材料（誰がアクセスを管理しているか・招待制であること・データの置き場所）を情報シートに並べて、導入する側が判断できる形にします。

Q7. 記録しすぎて困ることはありますか

試薬マスタ・在庫・機器台帳の変更も含めて、全ての書き込み操作を記録する設計にしています。「何が GMP に関係するか」はシステムには判定できないからです。

ただ、実際にレビューする立場から見て「これが混ざっていると読みにくい」という操作はありますか。

→ 決まったこと: 記録する範囲は減らしません。代わりに絞り込みを最初から作ります（D-45）。「ALCOA+ のように検索性は重要」という指摘は、調べるほど核心でした——実務者アンケートでも「変更・削除のみの証跡に絞り込めない」が最多の困りごとに挙がっています。これは使う人ではなく作る側の宿題です。

Q8. 監査や査察のとき、どんな形式で出せと言われますか

記録の持ち出しとして、1行1事象のテキスト（JSONL）と、人が読める HTML・添付ファイルの実体・ハッシュ一覧をまとめた ZIP を考えています。

実際の場面では、PDF や表計算ファイルでの提出を求められることが多いでしょうか。

→ 決まったこと: 経験が無いとのことだったので、条文に戻りました。PIC/S の文書が「印刷と電子コピーができ、可能なら表計算ソフトへのエクスポートのような動的機能を保持すること」と書いているので、JSONL に加えて CSV と印刷可能な形式を出します。

Q9. 根本的な読み違いがあれば

条文の理解そのものがずれている箇所、「その順序では実務が回らない」という指摘があれば、遠慮なく教えてください。間違いの指摘はこのラボの記事に反映し、どう直したかも公開します。

→ 調べました: 「PMDA のサイトに無いですか」の答えは「手引きは無い」でした。ただし当局自身が参照先を指定していることが分かり、日本語で読める実務の手引きも見つかりました。→ 別の記事にまとめました

あわせて、この回答でいちばん有用だったのは「Q8 までは、見たことのある分析装置の監査証跡モードを参考にした」という一言でした。規制対応の記録システムに何を期待するかは、条文よりも普段使っている装置のソフトの作法で決まっている——調べ直したところ、実際にその作法は業界で共通していて、こちらの設計もそれに寄せるべきだと分かりました。

---

この9問への回答は、設計に反映したうえで決定記録に残します。回答をくださった方の所属や個人が分かる形での引用はしません。