Good Automated Manufacturing Practice 5 — 2nd Edition対応実践ガイド
2026年6月
GAMP5（Good Automated Manufacturing Practice 5）は、ISPE（International Society for Pharmaceutical Engineering：国際製薬技術者協会）が発行する、GxP環境で使用されるコンピュータ化・自動化システムのバリデーションに関するベストプラクティスガイドです。法規制ではありませんが、FDA・EMA・PMDAがGxPコンピュータシステムのバリデーション手法として広く参照・推奨しており、業界標準（De Facto Standard）の地位を確立しています。
GAMP5の核心原則は「リスクベースアプローチ（Risk-Based Approach）」と「ライフサイクルアプローチ（Life Cycle Approach）」です。全てのシステム・全ての機能に同じ深度のバリデーションを要求する一律アプローチを廃し、患者の安全・製品品質・データインテグリティへのリスクに応じてバリデーションの深度を調整することで、適切な品質保証を効率的に実現します。
| 版 | 発行年 | 主な特徴 |
| GAMP 1 | 1994年 | 英国製薬業界（GAMP Forum）が発行。自動化製造システムの検証手法 |
| GAMP 2 | 1995年 | スコープ拡大・欧州規制との整合 |
| GAMP 3 | 1998年 | ソフトウェアカテゴリ（1〜5）の導入。バリデーション戦略の体系化 |
| GAMP 4 | 2001年 | リスクマネジメントの明示的導入・スプレッドシート対応追加 |
| GAMP 5 （初版） | 2008年 | ISPEが引き継ぎ。リスクベースアプローチの全面採用 ICH Q9（品質リスクマネジメント）との整合 ソフトウェアカテゴリをCat.1・3・4・5に再編 |
| GAMP 5 （第2版） | 2022年 | クラウド・SaaS・AIへの対応 Data Integrity・Agile開発への対応強化 CSV from QMSへの統合的アプローチ |
| GAMP5は「規制」ではなく「業界のベストプラクティス」 |
よくある誤解：「GAMP5に準拠しなければ規制違反になる」 正しい理解：「GAMP5は規制要件（GMP・21 CFR Part 11・EU Annex 11）を 満たすための推奨アプローチである」 GAMP5に従っていなくても、GxP規制要件を満たす別のアプローチで バリデーションを実施していれば規制違反ではない。 しかし、GAMP5は規制当局が「このアプローチは適切だ」と認識しており FDA・EMA査察において「GAMP5に沿ったバリデーションを実施しました」と 説明できることは、査察対応において大きな強みになる。 |
GAMP5のソフトウェアカテゴリは「バリデーションの深度はソフトウェアの種類とカスタマイズの程度によって決まる」という考え方を体系化したものです。カスタマイズが少ないソフトウェアは開発者が既にテストを実施しており、製薬企業が実施すべきバリデーションはより限定的になります。カスタマイズが多いほど、製薬企業側でのテストが重要になります。
| GAMP5ソフトウェアカテゴリの全体像 |
カテゴリ1：インフラソフトウェア 例：OS（Windows・Linux）・RDBMS（Oracle・SAP HANA）・仮想化基盤・ネットワーク機器 → メーカーが十分にテスト済み。インストール確認（IQ相当）を中心とする カテゴリ3：ノンコンフィグレーション製品（設定なし既製品） 例：文書管理の汎用ツール（設定変更なし）・オフィスソフト（管理用途） → 設定変更なしで使用。OQを中心とした機能テストを実施 カテゴリ4：コンフィグレーション製品（設定あり既製品） 例：SAP S/4HANA・Veeva Vault・LIMS（設定して使う製品） → 製品の設定・カスタマイズ内容のバリデーション。最もよく使われるカテゴリ カテゴリ5：カスタムアプリケーション（独自開発） 例：自社開発の製造管理システム・独自アドオン → 全工程（URS→FS→DS→IQ→OQ→PQ）の完全なV-modelバリデーションが必要 ※ カテゴリ2（設定変更可能なインフラ）は第2版で統合・廃止 |
OSやデータベース等のインフラソフトウェアは、メーカーが広範なテストを実施して市場提供しています。GAMP5の観点では「メーカーのテスト証跡を活用しつつ、自社環境への設置確認（IQ相当）を実施する」というアプローチが適切です。具体的にはインストールの確認・設定パラメータの記録・ライセンスの確認等が主な活動です。
設定変更なしで使用する既製品ソフトウェアです。メーカーの開発テストが充実しているため、製薬企業のバリデーション活動は「意図した目的に適合しているかの確認（OQ相当）」が中心です。ただし、GxP業務への影響度に応じてテスト範囲を調整します。
SAP S/4HANAはカテゴリ4の代表例です。製品自体はメーカーがテスト済みですが、製薬企業がGxP業務に応じて行う「設定（Customizing）」が正しく動作することをバリデーションします。URSで定義した業務要件が、設定されたSAPの機能として実現されているかをOQ・PQで確認します。
| カテゴリ4（SAP等）のバリデーション活動 | 内容 | 主な証跡文書 |
| URS作成 | GxP業務要件・規制要件・データ要件を業務の言葉で定義 | ユーザー要求仕様書（URS） |
| サプライヤー評価 | SAPのSDLC・品質マネジメント・サポート体制の確認 | サプライヤー評価報告書 （監査または書面評価） |
| 設定仕様書作成 | SAPの設定内容（Customizing・マスタ設定）を仕様書として記録 | 設定仕様書（CS/DS相当） |
| IQ実施 | SAPのインストール・設定が承認仕様通りか確認 | IQプロトコル・IQ報告書 |
| OQ実施 | 設定された機能がFSの仕様通りに動作するか確認 | OQテストスクリプト・OQ報告書 |
| PQ実施 | 実際の業務シナリオで意図した目的を果たすか確認 （UATをPQとして活用可） | PQプロトコル・PQ報告書 |
| バリデーション報告書 | 全バリデーション活動の要約・結論・残留リスク | バリデーション報告書（VSR） |
自社独自開発のシステムはカテゴリ5に分類され、最も厳密なバリデーションが求められます。開発者がメーカーと製薬企業の両方を兼ねるため、ソフトウェア開発ライフサイクル（SDLC）全体にGxPの管理が必要です。SAPのアドオン開発もカテゴリ5として扱うことが多いです。
GAMP5のリスクベースアプローチは、ICH Q9（品質リスクマネジメント）の原則を踏まえ、コンピュータ化システムのリスクを評価します。評価の3軸は「患者の安全」「製品品質」「データインテグリティ」です。これらへのリスクが高いシステム・機能に対してより深いバリデーションを実施し、リスクが低い部分には最小限の確認で対応します。
| リスク評価の観点 | 高リスク（詳細なバリデーション必要） | 低リスク（簡略なバリデーション可） |
| 患者の安全への影響 | 製造指図の誤り→過剰/過少投与 出荷判定システムの誤り→不適合品の出荷 | 社内承認ワークフロー （製品品質に間接的にしか影響しない） |
| 製品品質への影響 | 原材料試験データの管理ミス 製造条件の記録誤り | 財務管理システム（製品品質に影響なし） |
| データインテグリティ | 監査証跡なし→改ざんが検出できない 電子署名の不備→承認プロセスの信頼性欠如 | 参照専用の読み取りダッシュボード （データを変更しないシステム） |
GAMP5に基づくリスクアセスメントは、システム全体の評価（System Impact Assessment）から始まり、GxPに影響するシステムに対して機能レベルの詳細評価（Function Risk Assessment）を実施するという段階的アプローチを取ります。
| リスクアセスメントの二段階アプローチ |
【第一段階：System Impact Assessment（SIA）】 システム全体として「GxP業務に影響があるか」を評価 → GxP影響なし：CSVの対象外。通常のIT管理のみでよい → GxP影響あり：第二段階に進む 【第二段階：Function Risk Assessment（FRA）】 GxP影響ありと判定されたシステムの各機能を評価 評価軸： ① 患者安全への影響（高/中/低） ② 製品品質への影響（高/中/低） ③ データインテグリティへの影響（高/中/低） 評価結果に応じてバリデーション深度を決定： ・全軸で「高」→ IQ+OQ+PQ、網羅的テスト、詳細なトレーサビリティ ・一部「中」→ OQ+PQ、重点機能のみテスト ・全軸で「低」→ PQのみ、またはサプライヤーテスト証跡の活用のみ |
GAMP5はコンピュータ化システムを「調達・開発→運用→廃棄」というライフサイクル全体で管理することを求めます。バリデーションは「稼働前の一時的なテスト活動」ではなく、システムが廃棄されるまで継続するライフサイクル活動です。
| ライフサイクルフェーズ | 主な活動 | 主な文書 |
| 概念フェーズ | GxP影響評価（SIA） システムカタログへの登録 バリデーション戦略の決定 | GxP影響評価書 バリデーション計画書（VP） |
| プロジェクトフェーズ | ユーザー要求仕様（URS）作成 サプライヤー評価 設計・設定仕様書作成 IQ・OQ・PQ実施 | URS・FS/DS・CS サプライヤー評価報告書 IQ/OQ/PQプロトコル・報告書 |
| 運用フェーズ | 変更管理（Change Control） 定期的見直し（Periodic Review） インシデント管理 継続的なユーザー訓練 | 変更管理記録 Periodic Review報告書 インシデント記録 |
| 廃棄フェーズ | データ移行計画・実施 システム廃棄計画 GxP記録のアーカイブ・保管 | データ移行バリデーション報告書 廃棄記録・アーカイブ証跡 |
GAMP5では、コンピュータ化システムのサプライヤー（メーカー・SIer・クラウドプロバイダー）の品質管理体制を評価する「サプライヤー評価（Supplier Qualification：SQ）」を重要活動として位置づけています。サプライヤーのSDLC（ソフトウェア開発ライフサイクル）が成熟していれば、製薬企業側のバリデーション負荷を軽減できます。
| サプライヤー評価の方法 | 適用場面 | 確認内容 |
| 書面評価 （Desk Top Review） | カテゴリ1・低リスクのカテゴリ3 | 品質マニュアル・SDLCの説明文書 ISO 9001・ISO 27001等の第三者認証 サプライヤーが提供するバリデーション支援文書 |
| アンケート評価 | 中リスクのカテゴリ3・4 | SDLCの詳細・変更管理・テスト管理 品質不具合・リコールの履歴 セキュリティ対策・事業継続計画 |
| 実地監査 （On-site Audit） | 高リスクのカテゴリ4・5 | 施設・組織・プロセスの実態確認 バリデーション文書のサンプルレビュー 不適合事例と改善措置の確認 |
カテゴリ4・5のシステムでは、サプライヤーの工場での出荷前テスト（FAT：Factory Acceptance Test）と、製薬企業の現地での受入テスト（SAT：Site Acceptance Test）がバリデーションの重要要素になります。
| テスト種別 | 実施場所 | 実施主体 | 目的 | GAMP5での位置づけ |
| FAT 工場出荷試験 | サプライヤーの工場 またはオンライン | サプライヤー＋ 製薬企業代表 | 合意した設計仕様通りに システムが動作するかを 納入前に確認 | OQの一部として 活用可能 （証跡を保管する） |
| SAT 現地受入試験 | 製薬企業の 本番環境 | 製薬企業＋ サプライヤー | 本番環境での インストール・設定・ 機能の最終確認 | IQ・OQの完了確認 として活用 |
GAMP5は「必要最低限の文書で、必要最大限の品質保証を実現する」という原則を持ちます。文書のための文書作成（ペーパーワーク最小化）を否定し、品質保証に実際に役立つ文書を作成することを求めます。文書体系はリスクに応じて決定され、全てのシステムに同じ文書セットを要求するわけではありません。
| 文書 | 略称 | 目的 | 必須度 |
| バリデーション計画書 | VPまたはVMP | バリデーション戦略・スコープ・スケジュール・組織を定義 | 全カテゴリ必須 |
| GxP影響評価書 | SIA | システムのGxP影響を評価した記録 | 全システム必須 |
| ユーザー要求仕様書 | URS | 業務・規制・データ・セキュリティ要件の定義 | Cat.4・5必須 Cat.3は簡略版 |
| 機能仕様書 | FS | URSを機能要件として定義 | Cat.4・5推奨 |
| 設計仕様書（設定仕様書） | DS/CS | 技術的実装・設定内容の記録 | Cat.4：設定仕様書 Cat.5：設計仕様書 |
| IQプロトコル・報告書 | IQ | インストール・設定の確認テストと結果 | 全カテゴリ |
| OQプロトコル・報告書 | OQ | 機能テストとその結果記録 | Cat.3・4・5 |
| PQプロトコル・報告書 | PQ | 業務シナリオテストとその結果記録 | Cat.4・5 |
| サプライヤー評価報告書 | SER | サプライヤーの評価プロセスと結論 | リスクに応じて |
| バリデーション要約報告書 | VSR | 全バリデーション活動の要約・結論・残留リスク | 全カテゴリ |
| Periodic Review報告書 | PR | 定期的なバリデーション状態の確認記録 | 全カテゴリ（定期） |
トレーサビリティマトリクスは、URSの各要件がFS・DS（設定仕様）・テストケースのどれに対応するかを横断的に追跡する文書です。「この要件は設計に反映されているか」「この設計はテストされているか」「このテストはどの要件を検証しているか」という双方向の追跡可能性（トレーサビリティ）を確保します。
| トレーサビリティマトリクスの構造（例） |
要件ID │ URS記述 │ FS参照 │ CS参照 │ テストID │ テスト結果 ────────┼───────────────────┼───────────┼───────────┼───────────┼────────── URS-001 │ バッチ記録を電子的 │ FS-012 │ CS-SAP-07 │ OQ-045 │ PASS │ に作成・承認できる │ │ │ PQ-023 │ PASS URS-002 │ 監査証跡を自動生成 │ FS-018 │ CS-SAP-11 │ OQ-052 │ PASS │ する │ │ │ URS-003 │ 役割ベースの │ FS-005 │ CS-SAP-03 │ OQ-031 │ PASS │ アクセス制御 │ │ │ OQ-032 │ PASS このマトリクスにより： ・未テストの要件（テストIDが空欄の行）が一目で分かる ・テスト結果がFAILの要件がURSにトレースできる ・査察官が「URSのこの要件はどこでテストしているか」と聞いたとき 即座に該当テスト記録を提示できる |
GAMP5第2版（2022年）では、データインテグリティ（Data Integrity：DI）への対応が大幅に強化されました。2016年以降、FDA・MHRA・PMDAによるデータインテグリティ指摘が急増しており、GxP電子記録の信頼性確保がCSV・GAMP5実施の最重要テーマとなっています。
| データインテグリティの原則 | システム設計・バリデーションでの実装 |
| データは生成された時点で すぐに記録される（同時性） | システムが自動的にタイムスタンプを付与 手動入力の遡及修正ができない設計 |
| データは改ざんされていない （正確性・完全性） | 監査証跡（Audit Trail）で全変更を記録 削除・上書きができない設計（ソフト削除のみ） |
| 全ての修正は 記録・理由付けが必要 | 修正時に「修正理由」入力を必須とする機能 原データと修正後データの両方を保持 |
| 承認プロセスが証拠で証明できる | 電子署名の実装 「誰が・いつ・何に対して承認したか」の記録 |
| バックアップデータは 本番データと同じ信頼性 | バックアップからのリストア試験の定期実施 リストア試験記録の保管 |
医薬品業界では品質管理・安定性評価・プロセスバリデーション計算にExcelスプレッドシートが広く使用されています。GxP目的で使用されるExcelスプレッドシートはGAMP5のカテゴリ4または5（用途による）に相当し、適切なバリデーションが必要です。
| GxP Excelスプレッドシートのバリデーション要点 |
① スプレッドシートの種類と管理方法の決定 ・テンプレートファイル（.xltx等）として版管理し、データ入力用コピーと分離する ・複数人が編集する場合は変更管理の仕組みが必要 ② 機能テストの実施 ・全計算式が正しい計算をすることを確認（OQ相当） ・入力値の範囲チェック・エラーメッセージの動作確認 ・正常値・異常値・境界値での計算結果確認 ③ URS相当の要件定義 ・「このスプレッドシートは何の計算をするために使うか」 ・「どのセルが入力セルで、どのセルが計算結果セルか」 ・「GxPに影響するデータはどれか」を明記 ④ バージョン管理 ・計算式の変更はバージョンアップとして管理 ・旧バージョンで作成したデータは旧バージョンで再現・検証できる ⑤ データの保護 ・計算式セルをロック（保護）し、意図しない修正を防止 ・保護パスワードをSOPで管理 【注意】Excelの「Track Changes」機能はGxPの監査証跡要件を 満たさない場合がある。使用制限を明確にすること。 |
GAMP5初版（2008年）発行以来、コンピュータ化システムを取り巻く環境は大きく変化しました。クラウド・SaaSの普及、アジャイル開発手法の台頭、AI・機械学習の活用、データインテグリティへの規制強化——これらに対応するため2022年に第2版が発行されました。
| 第2版の主要変更点 | 初版との違い | 実務への影響 |
| クラウド・SaaS対応 | クラウドプロバイダーの評価 責任共有モデルへの対応 | SaaSをGxP環境で使う際の バリデーション戦略が明確化 |
| カテゴリ2の廃止 | Cat.2（設定変更可能なインフラ）を廃止 Cat.1に統合 | インフラのバリデーション アプローチが簡略化される |
| アジャイル開発への対応 | スプリントベースの開発での GxP管理アプローチを追記 | ウォーターフォール以外の 開発手法でもCSV対応が可能に |
| データインテグリティの強化 | DI要件をバリデーション活動の 中心に据えた構成に改訂 | DIリスクの評価がSIA・FRAに 明示的に組み込まれた |
| CSV from QMS | バリデーションをQMS （品質マネジメントシステム）の 一部として統合的に管理 | 変更管理・CAPA・訓練等の QMS活動とCSVの統合が促進 |
| サプライヤー評価の強化 | クラウドプロバイダー・SaaS事業者を 含めた評価フレームワークの整備 | Microsoft・SAP・AWS等の 評価手法が明確化 |
従来のウォーターフォール型開発を前提としたCSVアプローチでは、アジャイル（スプリントベース）開発に対応することが困難でした。GAMP5第2版では、アジャイル開発においてもGxPコンプライアンスを維持するためのアプローチが示されています。
| アジャイル開発でのCSV対応原則 |
原則①：リスクベースアプローチは変わらない → 開発手法が変わっても、「何を・どの深度でバリデーションするか」の判断基準は同じ → スプリントの早い段階でFRAを実施し、バリデーション要件を明確にする 原則②：URSは「User Stories」として表現できる → アジャイルのUser Story（「〇〇として〇〇したいので〇〇できる」形式）を URS要件として文書化することが可能 → 各User StoryのGxP影響を評価し、テスト基準を事前定義する 原則③：スプリントリリースには証跡が伴う → 各スプリントのリリース時に「何をテストしたか・結果はどうだったか」の 証跡（テスト記録）を残す → CI/CD（継続的インテグレーション）の自動テスト結果もGxP証跡として活用可 原則④：GxP機能の変更は変更管理を通じる → アジャイルのバックログ管理とGxP変更管理を統合する → 「スプリントで追加・変更した機能がGxPに影響するか」を各スプリントで評価 |
SAP S/4HANAはGAMP5カテゴリ4（コンフィグレーション製品）の代表例です。GxP業務（製造・品質管理・物流等）に使用するSAPのモジュールに対してバリデーションが必要です。以下はSAP S/4HANAのバリデーション実践における重要ポイントです。
| SAP S/4HANA バリデーションのポイント | 考え方 | 実践上の留意点 |
| SAPのソフトウェア自体は カテゴリ1扱い | SAPが提供するソフトウェアプラットフォーム（ABAP基盤等）は SAPが広範にテスト済みのため メーカーテスト証跡を活用 | SAP Trusted Partner Programや ISO認証・SOC報告書を サプライヤー評価証跡として活用 |
| Customizing（設定）が カテゴリ4のバリデーション対象 | SAPのCustomizingで設定した内容 （承認ワークフロー・品質管理設定等）が 正しく動作することを確認する | 設定仕様書（Configuration Specification）に 設定内容を記録し、OQでテストする |
| アドオンはカテゴリ5 | SAPの標準機能を拡張した独自開発 プログラム（ABAP）はカテゴリ5 としてSDLC管理が必要 | アドオンのURS・FS・DS・テストを 標準Vモデルで実施する 設計書とテスト記録を保管 |
| アップグレード（EHP・SP）は 変更管理が必要 | SAPのEnhancement Package・ Support Packageの適用は GxP機能への影響評価が必要 | テスト環境での事前確認 回帰テストによる影響範囲の検証 変更管理記録の作成 |
LIMS（Laboratory Information Management System：試験管理システム）は、製薬・生命科学企業の品質管理試験において最も重要なGxPシステムの一つです。試験結果の記録・管理・承認・報告を担うため、データインテグリティへの影響は最高レベルであり、最も厳密なバリデーションが求められます。
| LIMS バリデーションの重点確認項目 | 内容 |
| 試験結果の電子記録要件 | 測定値の入力・計算・承認の全プロセスが21 CFR Part 11準拠で記録されるか |
| 監査証跡の完全性 | 試験結果の全ての変更・承認・削除が監査証跡に記録されるか ユーザーが監査証跡を削除・修正できない設計になっているか |
| 規格値との自動判定 | 規格値に対する合否判定が自動化されている場合 計算ロジックが正しく実装されているかをOQで検証 |
| 試験メソッドのバリデーションとの連携 | LIMSに登録された試験メソッド（試薬量・判定基準等）が バリデーション済みの試験方法と一致しているか |
| データのインポート | 機器（HPLC・UV等）からのデータ自動インポート機能の 正確性・完全性・トレーサビリティを検証 |
MES（Manufacturing Execution System：製造実行システム）は製造現場と上位の計画系システム（ERP）を結ぶ中間層のシステムです。製造指図の展開・製造実績収集・プロセスパラメータ管理・電子バッチ記録等の機能を持ち、GxP影響は非常に高いシステムです。
| MESバリデーションで最も重要な確認点 |
① 電子バッチ記録（EBR）の完全性 製造の全工程記録（原材料使用量・工程パラメータ・製造担当者・承認等）が 電子的に記録され、紙のバッチ記録と同等の情報を含むことを検証する ② ERPとのインターフェース整合性 SAP PPからMESへの製造指図の転送・MESからSAPへの実績転送が 正確・完全に行われることをPQの業務シナリオテストで確認する （特に「分割指図・再作業・廃棄処理」等の例外フローを必ず検証する） ③ PLCとのデータ収集の信頼性 MESが現場のPLC・センサーから収集するプロセスデータ（温度・圧力等）が 正確に記録されること・タイムスタンプが正確であることを確認する ④ 環境モニタリングデータとの統合 製造エリアの温度・湿度・差圧モニタリングデータがMESに統合されている場合 アラーム設定・記録・逸脱通知の動作を検証する |
以上
ISPE（国際製薬技術者協会）はGAMP5本体に加えて、特定のトピックについて詳細なガイダンスを提供するGood Practice Guide（GPG）シリーズを発行しています。GPGはGAMP5フレームワークの実践的な補完資料であり、「GAMP5に書いてある原則を、このシステム・この状況にどう適用するか」を具体的に示します。GAMP5本体では「リスクベースで判断せよ」という原則が示されますが、GPGには「では具体的にどう判断するか」の実践例が含まれます。
| 主要GAMP5 GPGタイトル | 対象読者・用途 | 発行年 |
| IT Infrastructure (Operation Qualification) | ITインフラ（サーバー・ネットワーク・仮想化環境）の 適格性確認に特化したガイド ITチームとバリデーションチームの共通言語となる | 2021 |
| Records and Data Integrity | データインテグリティ（DI）のGAMP5フレームワーク内での 実践方法。ALCOA+原則をシステム設計に組み込む方法 | 2017 |
| A Risk-Based Approach to Compliant GxP Computerized Laboratory Systems | LIMS・クロマトグラフィーデータシステム（CDS）・ ELNなどの試験室システムへのGAMP5適用 | 2012（改訂中） |
| Electronic Data Management (Using an Operational DMS) | 文書管理システム（DMS）・電子文書のGxP管理 GMP文書のライフサイクル管理 | 2010 |
| Testing of GxP Systems | バリデーションテスト（IQ/OQ/PQ）の実践ガイド テスト設計・実施・文書化の具体的手法 | 2012 |
| Validation of Process Control Systems | PLC・DCS・SCADAのバリデーション実践ガイド プロセス制御特有のバリデーション手法 | 2014 |
| Cloud Computing (Appendix to GAMP5 2nd Ed.) | クラウドシステムへのGAMP5適用 IaaS/PaaS/SaaSの区分別バリデーション | 2022（第2版付録） |
| GPGを活用すべき代表的なシーン |
【LIMSを新規導入するとき】 → 'A Risk-Based Approach to GxP Computerized Laboratory Systems' GPGを参照 → LIMS固有のリスク（検体取り違え・試験結果の完全性・OOS管理）への対応方法を確認 【クラウドERPやSaaSシステムを導入するとき】 → 'Cloud Computing' Appendixを参照 → SaaSの場合サプライヤー（クラウドベンダー）の監査要件 ユーザーが実施すべきバリデーション範囲の考え方を確認 【DCSやPLCのバリデーションをするとき】 → 'Validation of Process Control Systems' GPGを参照 → オフィスITとは異なるリアルタイム制御システム特有の テスト方法・アラームバリデーション手法を確認 【バリデーションテストの設計に迷ったとき】 → 'Testing of GxP Systems' GPGを参照 → 各テストフェーズ（IQ/OQ/PQ）のスコープ・テストケース設計手法の 具体的なテンプレートが掲載されている |
ソフトウェアのOQ・PQが注目されがちですが、その土台となるハードウェア・ネットワーク・OS・セキュリティ設定のIQが不十分では上位のバリデーションも成立しません。GAMP5第2版では「ITインフラの適格性確認はソフトウェアバリデーションと同等に重要」との立場が明確になりました。特に近年のクラウド環境ではインフラのバリデーション責任分担（ベンダー vs. ユーザー）の明確化が必須です。
| IQ対象 | 確認項目の例 | 証跡の形式 |
| ハードウェア （サーバー・ストレージ） | 型番・スペックが仕様書と一致するか RAID構成・冗長化設定の確認 UPS（無停電電源）の動作確認 ラックへの設置・配線の記録 | 設置記録写真 ハードウェア仕様書との照合チェックリスト BIOS/UEFI設定のスクリーンショット |
| OS・ミドルウェア | OSバージョン・パッチレベルの記録 タイムゾーン・NTPサーバー設定 インストール済みコンポーネントの一覧 サービス・プロセスの起動設定 | インストール記録 OS設定パラメータリスト systeminfo / uname -a 等のコマンド出力 |
| ネットワーク | IPアドレス・DNSホスト名の設定確認 ファイアウォールルールの確認 VLAN構成・帯域幅設定 SSL/TLS証明書の有効期限・設定 | ネットワーク構成図との照合 ファイアウォールルール一覧 SSL証明書の詳細情報 |
| セキュリティ設定 | パスワードポリシー（複雑さ・有効期限） 未使用アカウントの無効化確認 ログ記録（監査証跡）の有効化確認 アンチウイルスの設定・定義ファイル更新 | セキュリティポリシー設定のスクリーンショット ユーザーアカウント一覧 セキュリティスキャンレポート |
| バックアップ・DR | バックアップジョブの設定確認 バックアップの実施・復元テスト RTO/RPO目標値との整合確認 DRサイトへのレプリケーション確認 | バックアップジョブ設定一覧 復元テスト記録 DR訓練報告書 |
AI・機械学習（ML）システムは従来のソフトウェアと根本的に異なる特性を持ちます。従来のソフトウェアはプログラムされたルールに従って動作しますが、ML系システムはデータから学習した統計的モデルが推論を行います。この「学習による不確実性」がGxPバリデーションに新たな課題をもたらしています。GAMP5第2版はAI/ML適用の議論を含み、ISPEは現在AI/ML専用のGPGを策定中です。
| AI/MLシステムの課題 | 従来システムとの違い | バリデーション上の対応 |
| 出力の不確実性 | 従来：同一入力→同一出力 ML：確率的出力・モデルによる「予測」であり 正解が保証されない | 閾値設定・信頼区間の定義 モデル性能指標（精度・再現率等） の合格基準を事前に設定 |
| ブラックボックス性 | ニューラルネットワーク等は 推論プロセスの説明が困難 （説明可能AIの必要性） | 重要な意思決定への使用制限 人間によるレビュープロセスの維持 説明可能AIアルゴリズムの採用 |
| モデルドリフト | 本番運用後、時間経過に伴い モデルの性能が劣化する可能性 | 定期的なモデル性能モニタリング 再学習・再バリデーションのトリガー定義 モデルバージョン管理 |
| 学習データの品質 | 学習データのバイアス・欠損が 出力品質に直接影響する | 学習データセットのGxP管理 データプレパレーションの文書化 データリネージュの追跡 |
ISPEおよびPDAの現在の見解では、AI/MLシステムは「GAMP5 Cat.5」として取り扱い、高いリスクレベルのバリデーションを適用することが推奨されています。特にモデルの「トレーニング・検証・テスト」の3段階の分離と、それぞれの結果の文書化が求められます。また、GxP用途でのAI利用において、最終的な意思決定は「訓練を受けた人間」が行うというヒューマンインザループの原則が重視されています。
| AI/MLシステムのバリデーション実施フレームワーク |
【ステップ1：用途・リスクの定義】 ・どのGxP業務にAIを適用するか（例：画像検査・異常検知・予測保全） ・誤った出力が患者安全・製品品質に与える影響の評価 ・人間のレビュープロセスの役割（ALにするかHITLにするか） 【ステップ2：データセットの管理・文書化】 ・学習データ・検証データ・テストデータの分割方針（例：70/15/15） ・学習データのGxP管理（バージョン管理・出所・前処理の記録） ・データバイアスの評価・対策 【ステップ3：モデル開発・選択の文書化】 ・使用アルゴリズム・ハイパーパラメータの記録 ・モデル選択の根拠（評価指標・比較検討結果） ・モデルファイルのバージョン管理 【ステップ4：性能検証（OQ相当）】 ・合格基準：精度（Accuracy）・感度（Recall）・特異度・AUC等 ・独立テストデータセットでの性能確認 ・最悪条件（エッジケース）でのテスト 【ステップ5：運用モニタリング計画（PQ相当）】 ・本番データでの性能継続モニタリング ・ドリフト検出の閾値・アラート設定 ・再学習・再バリデーションのSOPの整備 |
Data Integrity（DI）対応として「後付けでAudit Trailを有効にする」「SOPでDIを義務付ける」だけでは不十分です。規制当局が求めるのは「システムの設計段階からDIが組み込まれていること（Data Integrity by Design）」です。これはGAMP5の「品質リスクマネジメントの統合」という原則とも一致します。ALCOA+の各原則をシステム要件に落とし込み、URS（ユーザー要求仕様書）の段階からDI要件を定義することが重要です。
| ALCOA+原則 | URSへの落とし込み例（LIMS設計の場合） |
| Attributable（帰属性） 誰がいつ何をしたか | ・ユーザーIDとパスワードは個人に割り当て・共有禁止 ・全操作（入力・修正・削除・承認）にユーザーIDと日時を自動付与 ・監査証跡は手動での変更・削除が不可能であること |
| Legible（判読性） 読める・理解できる | ・電子記録は保管期間中常に人間が読める形式でアクセス可能 ・フォントサイズ・表示形式のUX要件 ・印刷時のフォーマット要件 |
| Contemporaneous（同時性） 実施と同時に記録 | ・試験結果は機器から自動取得（手入力を最小化） ・試験実施日時と入力日時の差は設定値以内 ・承認ワークフローのタイムスタンプの自動付与 |
| Original（原本性） オリジナルデータの保存 | ・生データ（Raw Data）の保存・上書き禁止 ・修正時は原本を保持した上で修正後値を記録 ・機器からのデータ取得は双方向連携（再入力でなく自動連携） |
| Accurate（正確性） データの正確さ | ・計算式の固定化とバリデーション ・単位変換の自動計算と誤入力防止（入力バリデーション） ・機器との連携精度のバリデーション |
| Complete（完全性） | ・必須フィールドの入力必須化（空白保存不可） ・全試験項目の記録完了確認後にのみ承認ステータスに遷移 ・削除は論理削除のみ（物理削除不可・削除理由の記録必須） |
| Consistent（一貫性） | ・日時フォーマット・タイムゾーンの統一設定 ・マスターデータとの整合性チェック（品目コード等） |
| Enduring（耐久性） | ・バックアップ・DR計画 ・保管媒体の寿命・移行計画 ・クラウドベンダーのデータ保管ポリシーのSLA確認 |
| Available（利用可能性） | ・保管期間中の検索・取得・印刷機能の維持 ・廃棄後の代替アクセス手段の確保 |
GAMP5第2版のCloud Computing Appendixは、IaaS・PaaS・SaaSの各サービスモデルで「ユーザーが実施すべきバリデーション」と「ベンダーへの委託で対応可能な部分」を整理しています。クラウドサービスの最大の特徴は、従来「ユーザーが管理していたインフラ」の一部または全部をベンダーが管理することです。これはバリデーション責任の委譲（Transfer of Validation Responsibility）を意味しますが、GxP責任そのものはユーザーが保持します。
| サービスモデル | ベンダー管理範囲 | ユーザーが実施すべきバリデーション |
| IaaS （インフラ as a Service） | 物理ハードウェア ネットワーク基盤 仮想化レイヤー | OS・ミドルウェアのIQ アプリケーションの全バリデーション ベンダーのデータセンター認証確認 |
| PaaS （プラットフォーム as a Service） | 物理ハードウェア OS・ランタイム環境 データベース基盤 | アプリケーション設定のIQ/OQ アプリケーションの機能バリデーション プラットフォーム変更への影響評価 |
| SaaS （ソフトウェア as a Service） | 物理ハードウェア OS・アプリケーション本体 インフラ全体 | ユーザー設定（コンフィグレーション）のOQ 業務プロセスへの適合性確認（PQ） ベンダー管理プログラムの実施 |
SaaSを利用する場合、ユーザーはインフラやソフトウェア本体の制御権を持ちません。代わりに「ベンダー管理プログラム（Vendor Management Program）」を通じて、ベンダーのGxP対応能力を継続的に確認します。ベンダーが提供するISO 27001・SOC 2 Type II等の第三者認証の確認や、ユーザー監査権の確保が重要です。また、ベンダーによるシステムアップデートへの変更管理対応が特有の課題となります。
| SaaSシステムのバリデーション戦略（例：クラウドERP） |
【ベンダー管理プログラム】 ・初期監査：ベンダーのGxP対応能力の確認 （ISO 27001・SOC 2 Type II・GxP特有の認証の確認） ・年次レビュー：ベンダーのセキュリティ報告書・インシデント対応履歴の確認 ・契約：データの所有権・保管期間・移行権・監査権のSLA明文化 【設定IQ（Configuration IQ）】 ・クラウドシステムのユーザー設定（コンフィグレーション）のみを対象 ・設定パラメータ一覧・設定根拠の文書化 ・設定のスクリーンショット・エクスポートデータの保管 【OQ：業務プロセス検証】 ・GxP業務シナリオに基づくテスト ・ユーザー権限管理・監査証跡の動作確認 ・セキュリティ設定の動作確認 【変更管理：ベンダー主導アップデートへの対応】 ・ベンダーのリリースノートのGxP影響評価 ・GxP関連機能の変更時は回帰テスト実施 ・マイナーアップデート・セキュリティパッチのSOP整備 |
以上