Computer System Validation — A Practical Guide for GxP Compliance
2026年6月
CSV（Computer System Validation：コンピュータ化システムバリデーション）とは、GxP環境で使用されるコンピュータシステムが「意図した目的に対して一貫して適合することを、文書化された証拠によって確立する」プロセスです。この定義はFDA 21 CFR Part 11およびEU GMP Annex 11が基盤とする概念であり、「システムが動いていること」を確認するのではなく、「意図した業務目的を満たすことを文書で証明すること」がCSVの本質です。
CSVの対象となるシステムは、GxP業務（製造・品質試験・臨床試験・市販後安全管理等）に影響を与えるコンピュータシステム全般です。ERP（SAP等）・LIMS・EDC・DMS・MES・PLC（プログラマブルロジックコントローラ）等、多岐にわたります。
| CSVが必要な「理由」を正確に理解する |
よくある誤解：「CSVは規制当局に提出するための書類作り」 本当の目的：「システムが業務目的を確実に果たすことを継続的に保証する活動」 CSVを「書類を作ること」として捉えると ・形式的な文書は揃っているが実態を反映していない ・バリデーション後に変更が加えられても再バリデーションされない ・査察で「システムは稼働しているがバリデーションが実態と乖離している」と指摘される CSVを「システムの継続的な品質保証」として捉えると ・システムの変更・アップグレードのたびに影響評価が行われる ・ユーザーはシステムが正しく動いていることを証拠に基づいて確信できる ・規制当局の査察にも根拠のある回答ができる |
| 規制・ガイドライン | 適用地域 | コンピュータ化システムに関する主な要件 |
| 21 CFR Part 11 （電子記録・電子署名） | 米国（FDA） | GxP記録の電子化・電子署名の要件 監査証跡・アクセス制御・システムバリデーション |
| EU GMP Annex 11 （コンピュータ化システム） | EU（EMA） | GxP環境でのコンピュータシステムの ライフサイクル管理・バリデーション要件 |
| PMDA コンピュータ化システム適正管理ガイドライン | 日本（PMDA） | 日本のGMP環境でのCSV実施要件 2012年改訂版が現行 |
| GMP省令 第11条 | 日本（厚生労働省） | 製造・品質管理に用いるコンピュータの 管理を求める国内法的根拠 |
| GAMP5 | ISPE（業界団体） | リスクベースのCSVアプローチ ソフトウェアカテゴリ分類とライフサイクル |
| ICH Q9 | グローバル（ICH） | 品質リスクマネジメント手法 CSVのリスク評価に適用 |
CSVは全てのITシステムに適用されるわけではありません。GxP業務（GMP・GLP・GCP・GDP・GVP）に直接影響を与えるシステムのみが対象です。システムカタログ（全社のシステム一覧）を整備し、各システムのGxP影響度を評価することがCSVプログラムの出発点です。
| システム種別 | GxP影響 | CSV要否 | 例 |
| 製造・品質に直接関与 | 製品品質・安全性データに 直接影響 | CSV必須 | LIMS・MES・ERP（生産/品質モジュール） PLC・DCS・環境モニタリングシステム |
| GxP記録の作成・管理 | GxPデータの記録・保管・ 報告に使用 | CSV必須 | DMS（文書管理）・LES（電子実習） EDC・CTMS（治験管理） |
| GxP業務を間接支援 | GxP業務に間接的に影響 | 限定的なCSV （リスクに応じ） | HR（人事・訓練管理） メンテナンス管理・資産管理 |
| GxP業務に影響なし | 製品品質・規制要件に 影響しない | CSV対象外 | 給与計算・法務契約管理 社内コミュニケーションツール |
各システムについてGxP影響評価（GxP Impact Assessment）を実施し、CSV対象かどうか・どのレベルのバリデーションが必要かを文書化します。評価の観点は「このシステムが誤動作した場合、患者の安全・製品品質・データの信頼性に影響があるか」です。
| GxP影響評価の問いかけ（システムカタログ評価） |
以下の問いに一つでも「はい」と答えれば、そのシステムはCSV対象候補： □ このシステムはGxP記録（電子記録）を作成・修正・保存・報告するか？ □ このシステムは製品の製造指図・仕様・製法に関するデータを管理するか？ □ このシステムは原材料・中間体・製品の試験・規格適合性を管理するか？ □ このシステムは環境モニタリング（温度・湿度・清浄度）のデータを収集するか？ □ このシステムが停止・誤動作した場合、製品の出荷判定に影響があるか？ □ このシステムは臨床試験データ（被験者データ・有効性・安全性）を管理するか？ □ このシステムは市販後安全性情報（副作用報告・シグナル）を管理するか？ □ このシステムのアクセス管理・監査証跡がGxP要件を満たす必要があるか？ |
CSVのバリデーションライフサイクルは「Vモデル」で表現されます。Vの左側が「仕様化（Specification）」フェーズ、右側が「テスト（Qualification/Testing）」フェーズです。左側の各文書が右側の対応するテストのインプットとなり、仕様通りに実装・動作することを確認する構造です。
| CSVのVモデル構造 |
【要求仕様書 URS】 ↙ ↘ 【機能仕様書 FS】 【性能適格性確認 PQ】 ↙ ↘ 【設計仕様書 DS】 【運用適格性確認 OQ】 ↙ ↘ 【コード/設定】 【設置適格性確認 IQ】 左側（下降）：「何を作るか」を詳細化していく仕様化フェーズ 右側（上昇）：「作ったものが仕様を満たすか」を確認するテストフェーズ URSで定義した業務要件 → PQで業務シナリオが正しく動くことを確認 FSで定義した機能要件 → OQで機能が正しく動くことを確認 DSで定義した設計要件 → IQで正しくインストール・設定されたことを確認 |
バリデーション計画書（Validation Master Plan：VMP）は、企業全体またはプロジェクト単位のCSVアプローチ・スコープ・組織・文書体系・スケジュールを定義した最上位文書です。個々のシステムに対するシステムバリデーション計画書（VP）はVMPの下位文書として位置づけられます。
| バリデーション計画書の主な記載事項 | 内容 |
| スコープ | バリデーション対象システムの特定・GxP影響評価の結果 |
| バリデーション戦略 | リスクベースアプローチの適用方針・GAMP5カテゴリの適用 |
| 組織・責任 | バリデーションオーナー・品質保証担当・ITの役割分担 |
| 文書体系 | VMP・VP・各種仕様書・テストプロトコル・報告書の階層構造 |
| テスト戦略 | IQ・OQ・PQの実施方針・合格基準・逸脱処理手順 |
| 変更管理 | バリデーション後の変更管理・再バリデーションのトリガー |
| 定期的見直し | Periodic Reviewの頻度・実施方法 |
URS（User Requirements Specification：ユーザー要求仕様書）はVモデルの頂点に位置し、「システムに何をさせたいか」をユーザー（業務部門）の言葉で記述した文書です。技術的な実装方法は記載せず、業務要件・規制要件・データ要件・インターフェース要件・パフォーマンス要件を業務の観点から定義します。
URS作成の最大の失敗は「技術者がURSを書く」ことです。URSはシステムを使う業務担当者が主体となって作成し、QA（品質保証）がGxP要件の観点からレビューすべき文書です。URSの品質がVモデル全体の品質を決定します。
| URS記載項目 | 具体例 |
| 業務要件 | ・バッチごとの製造記録を電子的に作成・承認できること ・原材料の入庫から出庫までのトレーサビリティを管理できること |
| 規制要件 | ・21 CFR Part 11に準拠した電子署名機能を有すること ・監査証跡を自動生成し、ユーザーが修正できない仕組みであること |
| データ要件 | ・患者識別データを匿名化した状態でレポートできること ・データのバックアップが毎日自動実行されること |
| インターフェース要件 | ・SAP ERPとのリアルタイム在庫データ連携 ・LIMS（試験管理システム）への試験結果自動転送 |
| パフォーマンス要件 | ・同時ユーザー数200名での通常業務時、画面応答時間が3秒以内 |
| セキュリティ要件 | ・役割ベースのアクセス制御（RBAC） ・パスワードポリシー（90日更新・最低8文字・複雑性要件） |
FS（Functional Specification：機能仕様書）はURSの要件をシステムの機能として定義した文書です。「このボタンを押すとこの処理が行われる」という機能レベルの記述であり、URSの各要件がFSのどの機能で実現されるかのトレーサビリティ（追跡可能性）が維持されます。
DS（Design Specification：設計仕様書）はFSの機能をどのような技術的手段で実現するかを記述した文書です。データベース設計・画面設計・インターフェース仕様・セキュリティ設計等が含まれます。SAPを例にとると、SAPのトランザクションコード・カスタマイズ設定・アドオン仕様がDSに相当します。
IQ（Installation Qualification：設置適格性確認）は、「システムが承認された設計仕様通りに設置・設定されているか」を確認するプロセスです。ハードウェア・ソフトウェア・ネットワーク設定・セキュリティ設定・ライセンス等が検証対象です。
| IQ検証項目（例：SAP S/4HANA） | 確認方法 |
| ソフトウェアバージョン確認 | SAP S/4HANA リリース・スタック・パッチレベルが承認済みバージョンと一致 |
| OS・データベース設定 | 承認されたOSバージョン・データベース（HANA）設定の確認 |
| セキュリティパラメータ | パスワードポリシー・セッションタイムアウト・ログイン失敗時のロック設定 |
| バックアップ設定 | 自動バックアップの設定・頻度・保管先・リストア手順の確認 |
| ネットワーク構成 | システム構成図と実際のネットワーク構成の一致確認 |
| インストール記録 | インストール日時・実施者・手順書の参照番号の記録 |
OQ（Operational Qualification：運用適格性確認）は、「システムが機能仕様書通りに動作するか」を確認するプロセスです。個々の機能を設計されたテストケースで確認し、正常系・異常系・境界値テストを実施します。OQは「システムが動く」ことを証明するフェーズです。
PQ（Performance Qualification：性能適格性確認）は、「システムが実際の業務シナリオ・実際の業務データで意図した通りに動作するか」を確認するプロセスです。本番またはそれに近い条件で、エンドユーザーが実際の業務シナリオを実行します。VモデルにおけるPQはURSへの回答であり、「ユーザーが要求したことが実際に実現されているか」の最終確認です。
| OQとPQの違いを正確に理解する |
OQ（機能確認）の例： 「『原材料入庫登録』画面で、ロット番号・数量・入庫日を入力して保存すると 在庫データベースに正しく記録される」 → 機能単位でテスト。テストデータはダミーデータでよい PQ（業務確認）の例： 「A製品（品番XXXXXX）の製造バッチ（Lot No. 2024-001）について 原材料入庫から製造・試験・出荷判定・出荷までの 全業務フローをSAP上で実際に処理し、 全工程の記録が正しく残ることを確認する」 → 実際の業務シナリオで確認。テストデータは本番相当のものを使う → エンドユーザー（業務担当者）がテストを実施する PQはUATと目的が重なることが多く、 UATをPQとして位置づける（UATを証跡として活用する）設計が効率的 |
CSVの歴史的な問題点は「全てのシステム・全ての機能に同じ深度のバリデーションを要求する」一律アプローチでした。これはリソースの無駄遣いを生み、本当に重要な機能の検証が疎かになるというパラドックスを生じさせます。GAMP5が提唱するリスクベースアプローチは「患者の安全・製品品質・データインテグリティへのリスクが高い機能・システムに、より深いバリデーションを行う」という原則です。
| リスク軸 | 評価の観点 | 高リスクの例 | 低リスクの例 |
| 患者安全への影響 | このシステムが誤動作した場合 患者の安全に直接影響があるか | 製造指図システムのエラー → 過剰/過少投与につながる可能性 | 社内コミュニケーションツール → 患者に直接影響なし |
| 製品品質への影響 | このシステムが誤動作した場合 製品の品質/規格に影響があるか | LIMS試験結果管理のエラー → 不適合品の出荷リスク | 財務報告システムのエラー → 製品品質には直接影響なし |
| データインテグリティへの影響 | このシステムが生成するGxPデータの 信頼性が損なわれるリスクがあるか | 監査証跡のないシステム → データ改ざんが検出できない | 外部公開しない内部分析ツール → 規制当局に報告するデータではない |
| リスクレベル | 対象システム例 | 必要なバリデーション深度 |
| 高リスク | LIMS・MES・EDC・DCS/SCADA （製品品質・患者安全に直接影響） | URS→FS→DS→IQ→OQ→PQ全段階 全機能のテストケース作成 異常系・境界値テストを含む網羅的テスト |
| 中リスク | ERP（生産/品質モジュール）・DMS （GxP記録管理に使用） | URS→FS→IQ→OQ→PQ リスクの高い機能を重点的にテスト 設定変更の影響評価を実施 |
| 低リスク | インフラ（OS・DB・ネットワーク） スプレッドシート（軽微な使用） | IQ中心。メーカー提供のFATを活用 設置・設定の確認を主体とする |
21 CFR Part 11（Code of Federal Regulations Title 21, Part 11）は、FDAが1997年に公布した「電子記録と電子署名に関する規制」です。GxP環境で紙の記録を電子記録に置き換える・または電子署名を使用する場合に適用されます。21 CFR Part 11への準拠は、FDA査察において電子記録・電子署名の使用を認めてもらうための条件です。
| 21 CFR Part 11の主要要件 | 技術的実装 |
| §11.10(a) バリデーション | システムが仕様通りに機能することをCSVで証明 変更時の再バリデーション |
| §11.10(b) 正確かつ完全なコピー | 電子記録の人間が読める形式でのコピー・規制当局への提供 |
| §11.10(c) 記録の保護 | 記録の不正修正・削除の防止 データバックアップ・ディザスタリカバリ |
| §11.10(d) アクセス制御 | 権限のあるユーザーのみがアクセス可能 ユーザーID・パスワード管理・役割ベースアクセス制御 |
| §11.10(e) 監査証跡（Audit Trail） | レコードの作成・修正・削除の 日時・ユーザー・変更前後の値を自動記録 ユーザーが修正・削除できない設計が必須 |
| §11.10(g) 権限確認 | 承認実施前に電子署名者の権限を確認する手順 |
| §11.50 電子署名の構成 | 電子署名には署名者の氏名・日時・署名の意味（承認/審査/実施）を含む |
| §11.70 電子署名と記録のリンク | 電子署名が特定の記録に結び付けられ、切り離せない設計 |
21 CFR Part 11・EU Annex 11において最も重要視されるのが監査証跡（Audit Trail）です。GxP電子記録への全ての操作（作成・参照・修正・削除・承認）を自動的に記録し、ユーザーが改ざんできない形で保存することが求められます。SAPのAudit Trail機能（変更文書・ログレコード等）はこの要件に対応しますが、適切な設定・有効化が必要です。
| SAPにおける監査証跡設定の確認ポイント |
SAP S/4HANAで確認すべき監査証跡要件： 1. 変更文書（Change Document）の有効化 GxP対象のデータオブジェクトに対して変更文書が記録されているか 例：バッチマスタ・品質情報記録・検査ロット等 2. Audit Information System（AIS） ユーザーアクション・ログイン・ログアウト・認証失敗の記録 TCode：SM20（セキュリティ監査ログ）の設定確認 3. テーブル変更ログ（TCODE: SCU3） GxP重要テーブルへの変更履歴の有効化 4. プロセス指示（PI）の電子署名 製造指図・品質判定等の承認に電子署名を実装している場合 SAP Digital Signature機能の設定確認 5. 監査証跡の保護 監査証跡データを削除・修正できるのはシステム管理者のみで その操作自体も別のログに記録される設計になっているか |
EU GMP Annex 11（Computerised Systems）は、EU GMP（Good Manufacturing Practice）のAnnex（付録）として、コンピュータ化されたシステムの使用に関する要件を定めた文書です。2011年改訂版が現行であり、米国21 CFR Part 11と並ぶGxPコンピュータシステムの主要参照規制です。
Annex 11は「プロジェクトフェーズ」と「運用フェーズ」に分けてシステムライフサイクル全体の要件を定めています。21 CFR Part 11が「電子記録・電子署名」という技術的要件に焦点を当てているのに対し、Annex 11はシステムの「選定から廃棄まで」の管理プロセス全体を規定している点が特徴です。
| Annex 11の主要条項 | 内容 |
| 条項1：リスクマネジメント | システム全体でのリスクベースアプローチの採用 ICH Q9の品質リスクマネジメント手法の適用 |
| 条項3：サプライヤーとサービスプロバイダー | コンピュータシステムのサプライヤーの適格性確認 監査・品質合意書（Quality Agreement）の締結 |
| 条項4：バリデーション | リスクに基づくバリデーション範囲の決定 URS・仕様書・テスト記録の整備 |
| 条項7.1：データとデータ管理 | データの正確性・完全性の確保 ALCOA+原則への適合 |
| 条項9：監査証跡 | GxPに影響する全データへのAudit Trailの実装 定期的な監査証跡レビュー |
| 条項11：電子署名 | 電子署名の使用に関する条件・記録要件 |
| 条項13：変更管理 | システム変更の影響評価・再バリデーション判断 |
| 条項17：アーカイブ | GxP記録の保管・移行・廃棄の管理 |
日本では2012年に厚生労働省が「コンピュータ化システム適正管理ガイドライン」を公布し、医薬品製造販売業者・製造業者がGMP環境で使用するコンピュータ化システムの適正な管理方法を規定しています。本ガイドラインはGAMP5の考え方を基盤とし、リスクベースアプローチ・ライフサイクル管理・ベンダー評価を求めています。
| 日本のCSVガイドライン主要要件 | 内容 |
| システム台帳の整備 | GMP対象システムを一覧化したシステム台帳の作成・維持 GxP影響評価の結果・バリデーション状況を管理 |
| ベンダー評価 | コンピュータシステムのサプライヤーのSDLC（ソフトウェア開発ライフサイクル）評価 アンケート・監査によるベンダー適格性確認 |
| バリデーション計画・実施 | VMP（バリデーション基本計画書）の作成 URS・仕様書・テストプロトコル・報告書の作成・保管 |
| 変更管理 | バリデーション後の変更に対する影響評価 再バリデーション要否の判断と実施 |
| 定期的見直し（Periodic Review） | 定期的（通常3年ごと）にシステムのバリデーション状態を再評価 システムが継続してGxP要件を満たすことを確認 |
| 運用管理 | ユーザー管理・バックアップ・障害対応・セキュリティ管理の文書化 |
2022年の薬機法（医薬品医療機器等法）改正では、データインテグリティへの要件強化・GDPガイドライン導入・電子申請の拡大等が盛り込まれました。特に「データの信頼性確保」は近年のPMDA査察での最重要テーマとなっており、電子記録の改ざん防止・監査証跡の完全性がCSVの中心的確認項目になっています。
SAP S/4HANA Cloud（Rise with SAP）・Veeva Vault・Microsoft Azure等のクラウド・SaaSシステムをGxP環境で使用する場合、従来のオンプレミスCSVとは異なるアプローチが必要です。クラウドプロバイダーが管理するインフラ・OS・ミドルウェア・アプリケーション基盤については、プロバイダーの認証・監査証跡を活用し、製薬企業は「アプリケーション設定・業務プロセス・データ」のバリデーションに集中するアプローチが効率的です。
| クラウドCSVにおける責任分担 | クラウドプロバイダー | 製薬企業 |
| インフラ（サーバー・ネットワーク） | 管理責任あり （ISO 27001・SOC2等で証明） | プロバイダーの認証確認のみ |
| OS・ミドルウェア・DB | 管理責任あり | プロバイダーの資料・認証で確認 |
| アプリケーション基盤（SaaS機能） | 機能のバリデーション証跡を提供 （FAT・IQOQ提供のケースあり） | プロバイダー提供証跡のレビュー ＋業務への適合性確認（PQ） |
| 設定・カスタマイズ・アドオン | 変更管理・リリース管理を担当 | 設定内容の仕様書作成 OQ・PQによるテスト実施 |
| 業務プロセス・データ | URS定義・PQ実施 データインテグリティの保証 |
クラウドSaaSの特徴の一つが「プロバイダー主導のアップグレード（自動更新）」です。オンプレミスでは変更管理プロセスを経てパッチ適用を管理できますが、SaaSでは定期的なアップグレードがプロバイダー側から配信されます。このアップグレードがGxP機能に影響する場合、再バリデーション（またはバリデーションの維持確認）が必要です。
| SaaSアップグレード対応のCSV戦略 |
アプローチ①：回帰テスト（Regression Test）の自動化 ・GxP重要機能のテストスクリプトを自動化ツールで管理 ・アップグレードごとに自動回帰テストを実行 ・変更の影響がない場合は「バリデーション維持確認済み」として記録 アプローチ②：プロバイダー提供のリリースノート活用 ・プロバイダーのリリースノート・変更影響評価文書を入手 ・GxP機能への影響有無を評価 ・影響なしと判断できれば軽微なPeriodic Review記録で対応可 アプローチ③：テスト環境でのサンドボックス検証 ・本番適用前にSandbox/QAS環境でアップグレードを適用し GxP機能への影響を確認してから本番適用する ・この手順が変更管理記録として証跡になる |
CSVは「一度バリデーションすれば終わり」ではありません。バリデーション後にシステムに変更が加えられた場合、その変更がGxP機能に影響するかを評価し、必要に応じて再バリデーションを実施する「変更管理（Change Control）」が義務です。変更管理なしの改修は重大なGMP違反となります。
| 変更の種類 | 例 | 対応方針 |
| Minor変更 （軽微な変更） | パスワードポリシーの文字数変更 UIの表示ラベル変更 バグ修正（GxP機能に影響なし） | 変更管理記録の作成 IQ/OQの部分的再確認 またはPeriodic Reviewに組み込み |
| Major変更 （重大な変更） | GxP機能に影響するSAPモジュールの追加 データ移行（別システムからの移行） インフラの移行（オンプレ→クラウド） | 変更の影響評価 影響範囲のOQ・PQを再実施 変更後のバリデーション報告書の作成 |
| Emergency変更 （緊急変更） | 本番環境の重大障害対応 セキュリティ脆弱性への緊急パッチ | 事後の変更管理文書作成 回帰テストによる影響確認 QA承認の事後実施（緊急の場合） |
Periodic Review（定期的見直し）は、バリデーション済みシステムが引き続きバリデーション状態を維持しているかを定期的（通常2〜3年ごと）に評価するプロセスです。EU GMP Annex 11・PMDAガイドラインが要求しており、「システムを導入したが何年も見直しをしていない」という状態はGMP違反のリスクがあります。
| Periodic Reviewのチェック項目 |
以下を確認し、問題がなければ「バリデーション状態維持」と結論づける： □ バリデーション後に実施された変更の一覧と変更管理記録の確認 □ 逸脱・インシデントの発生状況とCAPA完了状況 □ ユーザーアクセス権限の棚卸し（退職者・異動者の権限削除確認） □ バックアップ・リストアの定期実施記録と成功率 □ セキュリティパッチ適用状況 □ 教育訓練の実施状況（ユーザー訓練記録） □ 監査証跡の定期レビュー実施記録 □ GxP法規制・ガイドラインの改訂への対応状況 □ サプライヤー（SaaSプロバイダー）の認証更新状況 問題が発見された場合： → リスク評価を実施し、軽微なら是正処置のみ → 重大な問題があれば部分的または全面的な再バリデーション |
以上
21 CFR Part 11において最初に理解すべき重要概念が「閉鎖系（Closed System）」と「開放系（Open System）」の区別です。両者で求められるセキュリティ要件が大きく異なるため、まずシステムの種類を正確に判断することが実装の出発点となります。
| 区分 | 定義 | 代表例 | 追加要件 |
| 閉鎖系 （Closed System） | 電子記録を作成・修正・維持・送信するシステムへのアクセスが そのシステムの電子記録を使用する組織によって制御されているシステム | 社内LAN内のLIMS 製造実行システム（MES） 社内ERP（SAP） 研究所内のデータ取得システム | ユーザーIDとパスワードによる アクセス制限 監査証跡の自動記録 電子署名 |
| 開放系 （Open System） | 閉鎖系の定義に当てはまらないシステム 特に記録の作成者・修正者と受領者が 異なる組織に属する環境 | インターネット経由のメール クラウドベースのシステム （外部ベンダー管理） EDCシステム（外部治験サイト） | 閉鎖系の要件に加えて： 暗号化 デジタル署名 文書の真正性担保策 （タイムスタンプ等） |
| ハイブリッド システム | 電子記録と紙記録が混在する環境 21 CFR Part 11のFDA解釈で 特別な管理が必要 | 電子で入力し紙で承認するワークフロー LIMS出力を紙に印刷して保管 | 紙部分がマスターレコードか 電子部分がマスターレコードかを 明確に定義する必要がある |
多くの製薬企業が直面するのが「電子入力・紙承認」のハイブリッド環境です。FDAはハイブリッドシステムを否定するものではありませんが、「どの記録がオフィシャルなマスターレコードか」を明確に文書化し、その管理ルールを徹底することを要求します。ハイブリッドを意図せず運用している場合（電子記録があるのに紙に「バックアップ的に」記録を転記している等）は、監査証跡の矛盾や二重管理の問題が発生します。
| ハイブリッドシステム管理の判断マトリクス |
ケース①：電子入力 + 電子承認 + 紙は参照用コピー → 電子がマスター。紙への「COPY」スタンプが必要 → Part 11の全要件を電子側に適用 ケース②：電子入力 + 紙への印刷 + 紙承認 → 紙がマスター。電子側のデータは補助記録 → 電子データの変更管理・バックアップが必要だがPart 11の 電子署名要件は免除される（ただし監査証跡は推奨） ケース③：紙入力 + スキャン保管（電子アーカイブ） → 原本管理（原紙の廃棄ルール）が重要 → スキャン画像の真正性・検索性・読取可能性を証明 → Part 11の電子記録要件を適用（スキャン画像もPart 11対象） ★リスク：ハイブリッドで最も問題になるのは 「どちらがマスターか明確でない」ことによるデータ矛盾 導入時にSOP・システム設計書で明文化すること |
バリデーションテスト（IQ/OQ/PQ）の実施中に予期せぬ結果が得られた場合を「逸脱（Deviation）」または「テスト失敗（Test Failure）」と呼びます。重要なのは、「逸脱が発生したこと」そのものは問題ではなく、「逸脱に対して正しいプロセスを踏んで対応したか」が規制当局の査察で確認されるポイントです。「テスト失敗を書き直した」「テスト結果を隠した」行為こそが最大の違反です。
| 逸脱の種類 | 定義 | 対応の考え方 |
| 予期逸脱 （Planned Deviation） | テスト実施前から分かっていた手順からの逸脱 例：試験機器の代替を使用することが事前に決まっていた | テスト実施前に逸脱報告書（Deviation Report）を起票し 承認を得てからテストを実施する |
| 非予期逸脱 （Unplanned Deviation） | テスト実施中に発生した予期せぬ問題 例：システムがクラッシュした・期待値と異なる結果が出た | テスト実施中に即時記録し、テスト一時停止 逸脱報告書の起票・原因調査・是正処置の実施後に再テスト |
| プロトコル逸脱 （Protocol Deviation） | 承認済みテストプロトコルの手順を誤って実行した場合 例：規定の待ち時間を短縮してテストしてしまった | プロトコル変更管理（Protocol Amendment）で対応するか 逸脱として記録し影響評価を行う |
逸脱報告書は規制当局が査察時に必ず確認する重要文書です。「何が起きたか」だけでなく「なぜ起きたか（根本原因）」「再発を防ぐために何をするか（CAPA）」まで文書化します。単に「システムを再起動して再試験したら合格した」では不十分です。
| 逸脱報告書の必須記載項目 |
1. 逸脱ID・タイトル・逸脱発生日時 2. 逸脱の詳細説明 何が起きたか・誰が発見したか・どのテスト手順で発生したか 期待値と実際の結果の比較 3. 影響評価（Impact Assessment） 当該逸脱がGxPに与える影響（患者安全・製品品質・データの信頼性） 他のシステム・プロセスへの影響の有無 4. 根本原因分析（Root Cause Analysis） 「なぜその逸脱が発生したか」を5Why法・フィッシュボーン図等で分析 直接原因だけでなく系統的原因まで追求する 5. 是正処置・予防処置（CAPA） 是正処置（Corrective Action）：問題を修正するために行う処置 予防処置（Preventive Action）：再発を防ぐための仕組みの変更 各処置の担当者・完了予定日 6. テスト結論（合格/不合格/条件付き合格）の判断と根拠 7. 承認者のサインと日付 |
レガシーシステムから新しいシステム（例：旧LIMS→新LIMS、旧ERP→SAP S/4HANA）への移行時、GxPに関連するデータの移行には厳格なバリデーションが必要です。「データを移しました」だけでは不十分で、「移行後のデータが元データと完全に一致し、移行プロセス中にデータが変質・欠落・改ざんされていないこと」を証明する必要があります。
| データ移行バリデーションのフェーズ | 主な活動 | 成果物 |
| 計画フェーズ | 移行対象データの特定（GxP/非GxPの分類） 移行ルール（マッピング）の定義 データクレンジングの範囲決定 移行テスト環境の準備 | データ移行計画書 データマッピング仕様書 移行テスト計画書 |
| 検証フェーズ | 移行ツール・スクリプトのバリデーション 移行前データのバックアップ パイロット移行（一部データで試験移行） 移行後データの検証方法確立 | 移行ツール検証報告書 パイロット移行報告書 |
| 本番移行 | 本番データのバックアップ 本番移行の実行（ダウンタイム管理） 移行後データの完全性検証（100%照合または統計的サンプリング） 移行証跡の保管 | 本番移行実施記録 データ照合報告書 移行完了報告書 |
| 移行後検証 | 移行後システムでの業務継続確認 旧システムのアーカイブ・廃棄手順 GxP記録のアクセス確保（法定保管期間中） | ユーザー受入テスト報告書 廃棄記録 |
移行後のデータ照合は、元データと移行後データが一致することを確認する核心的な活動です。全件照合が理想ですが、データ量によっては統計的サンプリングで対応します。いずれの場合も「どのように照合したか」「不一致が発見された場合にどう対処したか」を文書化します。
| データ照合の実施方針（例：SAP移行） |
【全件照合が必要なデータ】 ・マスターデータ（得意先マスタ・品目マスタ・BOM） ・GxP直接関連データ（検査ロット・ライセンス・試験結果） ・金額・数量データ（残高・在庫量） 【統計的サンプリングで可能なデータ】 ・大量のトランザクションデータ（受注・請求等） ・非GxPの参照データ 【照合方法】 1. チェックサム比較：件数・金額合計値の一致確認 2. フィールド照合：キー項目・重要項目の全件/サンプル比較 3. ビジネスルール検証：移行後データが業務ルールを満たすか確認 （例：有効期限 > 製造日、在庫量 >= 0） 4. 目視サンプリング：画面上でランダムサンプルを目視確認 【不一致発見時】 → 逸脱として記録 → 根本原因分析 → 移行ルール修正 → 再移行 |
製造現場のプロセス制御システム（PLC：プログラマブルロジックコントローラ、DCS：分散制御システム、SCADA：監視制御システム）は、バッチ製造・連続製造・温度制御等の製造プロセスを直接制御します。これらのシステムはGxP直接影響システムであり、严格なCSVが必要ですが、オフィスITシステムとは異なる特性を持ちます。
| プロセス制御システムの種類 | 用途・特徴 | CSV上の考慮点 |
| PLC （プログラマブルロジックコントローラ） | 機械・設備の動作を制御するマイクロコントローラ 打錠機・充填機・包装機に内蔵 ラダー図（Ladder Diagram）でプログラミング | ハードウェアとソフトウェアの不可分性 プログラム変更管理が特に重要 GAMP5 Cat.4（設定済み製品）または Cat.5（カスタム）として扱う |
| DCS （分散制御システム） | プラント全体のプロセス変数を監視・制御 蒸留塔・発酵槽・反応器等の連続プロセス 複数のコントローラが分散配置 | プロセスパラメータのリアルタイム記録 Alarm管理・インターロックのバリデーション データ収集・トレンド記録の証跡確保 |
| SCADA （監視制御データ収集） | PLC/DCSの上位に位置する監視システム プラント全体の可視化・データ収集 HMI（ヒューマン・マシン・インターフェース）を含む | HMI画面のバリデーション（表示正確性） データアーカイブの完全性 電子記録としての監査証跡 |
| BAS/EMS （ビルディング・環境管理システム） | クリーンルームのHVAC制御・温湿度・差圧管理 製薬環境の環境条件をリアルタイム監視 | 環境モニタリングデータのCSV適用 Alarmへの対応記録 年次再バリデーション |
プロセス制御システムのOQでは、プロセスパラメータ（温度・圧力・pH・攪拌速度等）が規定範囲内で正確に制御・記録されることを検証します。特に重要なのは、センサー精度のキャリブレーション、アラーム設定値の検証、インターロック（規定範囲逸脱時の自動停止）の動作確認です。
GxPシステムの廃棄（使用終了）は、システム導入と同様にバリデーションされたプロセスで実施する必要があります。廃棄時に問題となる主な点は、GxP記録の法定保管期間中のアクセス保証と、電子記録・電子署名の完全な移行・アーカイブです。「古いシステムを消してしまったので試験記録が見られない」状態は重大なGMP違反です。
| GxP記録の法定保管期間（主要規制） | 保管期間の原則 |
| GMP（製造記録・品質記録） | 製品の有効期限後最低1年以上（日本薬機法） FDA: バッチ記録は3年以上・安定性データは有効期限+1年 EU GMP: 製品有効期限後1年以上・最低5年 |
| GCP（治験記録） | 治験薬の最終承認・不承認から15年（FDA） 治験終了後25年（EU）・治験終了後3年（日本GCP省令） |
| GLP（非臨床試験記録） | 試験報告書提出後10年（日本）・2年〜10年（OECD指針） |
| 電子記録の特別考慮 | ハードウェア・OS・アプリケーションが廃棄されても 電子記録は人間が読める形式で保管期間中アクセス可能にする |
| GxPシステム廃棄の実施手順 |
【フェーズ1：廃棄計画の策定（廃棄の12〜6ヶ月前）】 1. 廃棄計画書（Decommissioning Plan）の作成 廃棄理由・廃棄予定日・影響範囲・代替システムの確認 2. GxP記録の棚卸しと保管期間の確認 まだ保管期間中の記録は何か・保管先はどこか 3. データ移行・アーカイブ方針の決定 後継システムへの移行 or 読み取り専用アーカイブシステムへの移行 【フェーズ2：データアーカイブの実施（廃棄の3ヶ月前）】 4. 電子記録の完全エクスポート・アーカイブ 5. アーカイブの完全性検証（データ照合・チェックサム） 6. アーカイブシステムのアクセス確認テスト 【フェーズ3：廃棄の実施】 7. 廃棄日時・実施者の記録 8. ハードウェア・ライセンスの廃棄記録 9. 廃棄完了報告書の発行・承認 ★廃棄後も廃棄記録自体は保管（廃棄した証拠として） |
以上