SAP Computer System Validation in Life Sciences — Design & Implementation Guide
2026年7月
医薬品・医療機器・食品製造業では、GxP（GMP/GCP/GLP/GDP）規制に基づき、製品品質に影響を与えるコンピュータ化システムのバリデーション（CSV：Computer System Validation）が義務付けられています。FDAの21 CFR Part 11、EUのAnnex 11、PIC/S GMP Annex 11等がその根拠規制であり、システムの適格性確認（IQ/OQ/PQ）と継続的な変更管理が要求されます。
SAP ERPは、製造実行・品質管理・在庫管理・財務処理など、GxP規制対象業務を広くカバーします。製薬企業がSAPを導入する際は、単なるITプロジェクトではなく「CSVプロジェクト」として位置づけ、規制当局が査察で確認する証拠書類を体系的に準備する必要があります。
GAMP5（Good Automated Manufacturing Practice v5）はISPE（国際製薬技術協会）が定めたCSVのベストプラクティスガイドラインです。システムをカテゴリ分類してリスクに比例したバリデーション活動を定め、過剰なバリデーション（Over-validation）を防止しながら規制適合を確保する「リスクベースドアプローチ」を採用しています。2022年に第2版（GAMP5 Second Edition）が発行され、アジャイル手法・クラウドシステム・データインテグリティへの対応が追加されました。
| GAMP5の核心原則 | 内容 |
| リスクに比例したバリデーション | 全システムを同じ強度でバリデーションするのは非効率。リスク（製品品質への影響度）が高いほど厳格なバリデーションを実施 |
| 製品ライフサイクルアプローチ | 計画→設計→開発→試験→リリース→運用→廃棄の全フェーズでバリデーション活動を継続 |
| サプライヤー活用 | サプライヤー（ここではSAP社）の開発プロセス・品質保証体制を活用。サプライヤー評価により自社テスト範囲を縮小可能 |
| スケーラビリティ | システムの規模・複雑さ・リスクに応じてバリデーション文書の範囲・詳細度を調整 |
| 科学的根拠 | バリデーション判断は根拠ある科学的思考に基づく。「やって当然」という慣習的判断でなく論理的根拠を示す |
GAMP5はコンピュータ化システムを4カテゴリ（1/3/4/5）に分類します。カテゴリが高いほどカスタマイズ度が高く、バリデーション要件も重くなります。SAPはその構成により複数のカテゴリにまたがることが特徴です。
| カテゴリ | 定義 | バリデーション要件 | SAPでの該当例 |
| Cat.1 インフラ | OS・DBサーバー・ネットワーク等 ソフトウェアを動かす基盤 | 適格性確認（IQ相当） 設定記録の保管 | SAP BASIS環境 WindowsServer/Oracle DB SAP HANAデータベース |
| Cat.3 非設定製品 | 設定変更なしで使用する COTS（市販品） | サプライヤー評価 機能試験（OQ相当） ユーザー受入試験（UAT） | SAP標準レポート SAP標準ワークフロー 変更していない標準機能 |
| Cat.4 設定可能製品 | SPROコンフィグレーション等 設定により機能を変更する製品 | Cat.3に加えて 設定証拠の記録 設定変更の変更管理 | SPRO設定変更 組織構造・勘定設定 標準ワークフローの有効化 |
| Cat.5 カスタム製品 | 顧客固有のプログラミング・ カスタム開発（ABAP等） | フルバリデーション （IQ+OQ+PQ+設計仕様） コードレビュー・ユニットテスト | ABAPカスタム開発 User Exit / BAdI実装 カスタムレポート・界面 |
SAP導入プロジェクトでは、全機能・設定・開発をリストアップしてGAMP5カテゴリを判定し、バリデーション活動の範囲を決定します。以下の判定フローを用いることで、Over-validationを防止しながら規制リスクをカバーします。
| GAMP5カテゴリ判定フロー（SAP適用版） |
Step 1：GxP影響度の評価 Q：このシステム機能は製品品質・患者安全・データインテグリティに直接影響するか？ NO → Cat.1（インフラ）またはバリデーション対象外 YES → Step 2へ Step 2：カスタム開発の有無 Q：ABAPカスタム開発・User Exit・BAdI実装を含むか？ YES → Cat.5（フルバリデーション） NO → Step 3へ Step 3：SPRO設定変更の有無 Q：SAP標準SPROトランザクションで設定を変更しているか？ YES → Cat.4（設定証拠記録・設定変更管理が必要） NO → Step 4へ Step 4：標準機能のみ → Cat.3（サプライヤー評価＋機能試験のみ） |
| SAP QM機能 | Cat. | 根拠 |
| 検査ロット自動生成（標準） | 3 | SPRO設定で有効化するが標準ロジックのみ使用 |
| 使用決定ロジック（標準コード） | 3 | 標準の使用決定コード・移動タイプを使用 |
| 検査計画（標準MIC定義） | 4 | SPROで検査方法・許容値・サンプルスキームを設定 |
| カスタム品質証明書レイアウト | 5 | ZXXXXプログラムでABAPカスタム開発 |
| QM-WM統合カスタムBAdI | 5 | BAdI実装によるカスタムロジック |
| SAP標準品質通知レポート | 3 | 設定変更なし・標準レポート利用 |
バリデーション計画書（Validation Plan：VP）はCSVプロジェクト全体の方針・範囲・組織・スケジュール・文書体系を定めるマスタードキュメントです。FDA/EMA査察では最初に提出を求められる重要文書です。SAP導入プロジェクトでは、プロジェクトキックオフ後すぐにVPを策定し、ステアリングコミッティの承認を得ます。
| VPセクション | 記載内容 | 作成担当 |
| 1. 目的・適用範囲 | バリデーション対象システム・モジュール・拠点の明確化 GxP規制対象業務の列挙 | 品質保証（QA）部門 |
| 2. 参照規制・ガイドライン | 適用規制（21 CFR Part 11 / EUAnnex 11 / GAMP5） 国内薬事法・通達の参照 | QA部門 |
| 3. 役割と責任 | バリデーション責任者・QA責任者・ITシステム管理者 プロセスオーナー・サプライヤー担当者の役割定義 | プロジェクトマネージャー |
| 4. システム概要 | SAP S/4HANAのシステム構成（ランドスケープ） GAMP5カテゴリ分類サマリー | SAP BASIS担当 |
| 5. バリデーション戦略 | リスクベースドアプローチの適用方針 カテゴリ別バリデーション活動の概要 | QA部門・ITリーダー |
| 6. バリデーション文書体系 | VP→RA→URS→FS/DS→IQ/OQ/PQ計画・報告書の体系図 各文書のテンプレート・命名規則 | QA部門 |
| 7. サプライヤー評価 | SAP社の品質システム評価方針 （SAPのISO9001認証・SDLリファレンスの活用） | QA部門・購買 |
| 8. データ移行バリデーション | レガシーデータのSAPへの移行検証方針 | データ移行チームリード |
| 9. スケジュール | 実装フェーズとバリデーションフェーズのマイルストーン | PMO |
| 10. 偏差・変更管理 | バリデーション中の偏差処理手順 リリース後の変更管理方針 | QA部門 |
バリデーション計画に先立ち、SAP機能単位でGxPリスクアセスメントを実施します。影響度（Severity：患者リスク/製品品質リスク/データインテグリティリスク）と発生確率（Likelihood）を評価し、リスクスコアに基づいてバリデーション活動の強度を決定します。
| リスクスコアリング基準（例） |
影響度（Severity） H（3点）：患者安全・製品リリース判定に直接影響 M（2点）：監査証跡・報告書データの正確性に影響 L（1点）：間接的影響（管理情報・参照データ等） 発生確率（Likelihood） H（3点）：新規開発・複雑な設定変更・外部IF M（2点）：標準機能の設定変更・データ移行 L（1点）：設定変更なし・使用実績あり機能 リスクスコア = 影響度 × 発生確率 6-9点：Cat.5相当の厳格なバリデーション 3-5点：Cat.4のバリデーション 1-2点：Cat.3のバリデーション |
SAP S/4HANAの標準導入方法論「SAP Activate」は6フェーズ（Discover/Prepare/Explore/Realize/Deploy/Run）で構成されます。GAMP5のライフサイクル（計画→設計→構築・試験→リリース・運用）をSAP Activateの各フェーズにマッピングすることで、開発活動とバリデーション活動を並行して効率的に進められます。
| SAP Activateフェーズ | GAMP5対応活動 | 主要CSV成果物 |
| Discover （探索） | バリデーション計画の初期策定 サプライヤー評価（SAP社評価） GxP影響評価（初期） | バリデーション計画書（VP）初版 サプライヤー評価記録 GxP影響評価書 |
| Prepare （準備） | プロジェクトバリデーション計画確定 GAMP5カテゴリ分類 リスクアセスメント実施 | VP確定版・承認 カテゴリ分類表 リスクアセスメント記録 |
| Explore （要件定義） | ユーザー要件仕様書（URS）策定 機能仕様書（FS）策定 トレーサビリティマトリクス（TM）初版 | URS（GxP要件を含む） 機能仕様書（FS） TM（URS-FS列） |
| Realize （設計・構築） | 設計仕様書（DS）策定 IQプロトコル・OQプロトコル作成 設定記録（SPRO証拠）取得開始 ABAPコードレビュー | DS（設計仕様書） IQプロトコル・OQプロトコル SPRO設定記録 コードレビュー記録 |
| Deploy （展開） | IQ実施・IQ報告書作成 OQ実施（機能試験）・OQ報告書 PQプロトコル作成 データ移行バリデーション | IQ実施記録・IQ報告書 OQ実施記録・OQ報告書 PQプロトコル データ移行バリデーション記録 |
| Run （本番運用） | PQ実施（業務検証）・PQ報告書 バリデーションサマリーレポート 変更管理手順の確立 | PQ実施記録・PQ報告書 バリデーションサマリー 変更管理手順書（SOP） |
トレーサビリティマトリクス（Traceability Matrix：TM）は、ユーザー要件から設計・テストケース・テスト結果まで、各バリデーション成果物の関連性を一覧で示す管理表です。規制当局はTMを用いて「全ての規制要件が設計に反映され、テストで検証されているか」を確認します。TMはバリデーション文書体系の「背骨」であり、査察で最頻出の確認資料です。
| TM列 | 内容 | 記載例 |
| URS番号 | ユーザー要件仕様書の要件ID | URS-QM-001 |
| 要件説明 | ユーザーが求める機能・性能の記述 | 検査ロットが入庫時に自動生成されること |
| GxP関連 | GxP規制への関連（21CFR/AnnexII等） | 21 CFR 211.68(b) / GAMP5 Cat.4 |
| GAMP5カテゴリ | 該当カテゴリ | Cat.4 |
| FS参照 | 機能仕様書の参照ID | FS-QM-014 |
| DS参照 | 設計仕様書の参照ID（Cat.5のみ） | DS-ZQMRPT-001 |
| IQテストケース | IQでの検証項目ID | IQ-TC-QM-003 |
| OQテストケース | OQ機能試験のテストケースID | OQ-TC-QM-015 |
| PQテストケース | PQ業務試験のテストケースID | PQ-TC-QM-002 |
| テスト結果 | 合否・偏差番号 | Pass / 偏差なし |
| 完了日 | テスト完了日 | 2025/03/15 |
TMは静的な文書ではなく、プロジェクト進行とともに継続更新が必要な生きた管理表です。URS変更・設計変更・テスト結果の更新を都度反映し、全列が埋まった状態でバリデーション完了と見なします。GxP未検証の要件が残っていれば本番移行が承認されません。ExcelまたはALM（Application Lifecycle Management）ツールで管理するのが一般的です。
IQ（Installation Qualification）はSAPシステムが設計仕様通りにインストール・設定されていることを確認するフェーズです。「正しいものが、正しくインストールされているか」を証明します。
| IQ確認項目 | 確認内容 | 証拠取得方法 |
| ハードウェア構成 | サーバースペック・冗長性構成が設計仕様と一致 | BASISシステム情報画面のスクリーンショット |
| OSバージョン | 承認されたOSバージョン・パッチレベル | OS情報コマンド出力のキャプチャ |
| SAP S/4HANAバージョン | 導入バージョン・Support Package Level | SAP Software Center / SPAM画面 |
| ライセンス | 全必要ライセンスの有効性確認 | SAP System Measurement画面 |
| ランドスケープ構成 | Dev→QA→Prodの3段構成・Transport経路 | STMS設定のスクリーンショット |
| バックアップ設定 | 定期バックアップスケジュール・復元テスト結果 | バックアップ設定画面・復元テスト記録 |
| セキュリティ設定 | パスワードポリシー・ログイン失敗ロック設定 | セキュリティプロファイルパラメータ一覧 |
| プリンタ・周辺機器 | 承認された周辺機器の接続確認 | デバイス設定記録 |
OQ（Operational Qualification）はシステムが設計した通りに動作することを確認する機能試験フェーズです。「設定した通りに動くか」「境界値・異常値でも正しく動作するか」を体系的に試験します。SAPでは各ビジネスプロセスをシナリオベースで試験します。
| OQテストケースの記載フォーマット |
テストケースID：OQ-TC-QM-015 テスト対象要件：URS-QM-001（検査ロット自動生成） テスト目的：入庫トリガーで検査ロットが自動生成されること 事前条件： ・品目マスタの品質管理タブに検査設定が完了していること（QM01実施済み） ・検査計画が品目・工場に割当済みであること テスト手順： Step 1：MIGOでGR（入庫：移動タイプ101）を実施 品目：FG-001、数量：100EA、工場：1000 Step 2：QA32で検査ロットが生成されていることを確認 Step 3：QA32→検査ロット詳細→検査計画が自動コピーされていることを確認 期待結果： ・MIGOで入庫した直後にQA32で検査ロットが表示されること ・検査計画（MIC・許容値）が自動展開されていること ・使用決定が「未決定」状態であること 実施結果：（Pass / Fail / 偏差番号） 実施日： 実施者署名： |
PQ（Performance Qualification）は実際の業務シナリオ（または実業務データに近いデータ）を用いて、システムが要求されるGxP業務を支援できることを確認するフェーズです。OQが機能単位の試験であるのに対し、PQはE2E業務フロー全体を対象とし、プロセスオーナー（業務部門）が主体となって試験します。
| PQシナリオ例（SAP QM） | 試験内容 |
| PQ-SC-01 原材料受入検査 | 仕入先からの原材料入庫→検査ロット生成→サンプリング→ 検査結果記録（MIC）→使用決定（321）→在庫解放まで一連確認 |
| PQ-SC-02 製造中間製品の品質管理 | 製造指図完了→中間製品検査ロット→工程内検査→ 不合格時のブロック（344）→再検査→最終使用決定 |
| PQ-SC-03 製品リリース判定 | 完成品PQ検査→GMP要件に基づく最終使用決定→ 出荷ブロック解除（321）→SOによるデリバリー |
| PQ-SC-04 偏差処理（OOSシナリオ） | OOS（規格外）結果発生時の品質通知起票→ リテスト指示→原因調査→品質不良棄却（553） |
| PQ-SC-05 監査証跡確認 | 全トランザクション実施後に変更ログ（CDHDR/CDPOS）を確認 誰が・いつ・何を・何に変更したかが記録されていること |
SAP S/4HANAのコンフィグレーションはSPROトランザクションで実施され、その設定内容が製品品質に直接影響します。例えば「移動タイプ101で検査ロットが生成されるか否か」はSPRO設定で決まり、GxP観点では設定値とその承認記録が証拠として必要です。SPRO設定の証拠取得は、以下の方法で実施します。
| 証拠取得方法 | 内容・用途 | ツール |
| スクリーンショット | SPRO設定画面のキャプチャ 設定値を視覚的に記録 | Print Screen / Snipping Tool GitHub等で管理 |
| SE16N テーブル内容エクスポート | 設定テーブル（例：T001/T156Q等）を Excel/CSV形式でエクスポート | SE16N→「プログラム」→エクスポート |
| SCC1 / SPRO比較ツール | Dev環境とProd環境の設定差分確認 「設計通りに移送されたか」の証拠 | SPRO→設定差分チェックツール |
| 移送依頼記録（SE10/STMS） | Dev→QA→Prodへの設定移送の証拠 いつ・誰が・何を移送したかの履歴 | SE10（移送依頼管理） STMS（移送管理システム） |
| チェンジポインタ（SCU3） | SPRO設定変更の変更ログ 変更前後の値を記録 | SCU3トランザクション |
| バリデーション設定台帳 | GxP影響のある全設定値を バリデーション文書として整理したExcel台帳 | QA部門が作成・管理 |
| ABAPカスタム開発の証拠取得チェックリスト |
□ 機能仕様書（FS）：ビジネス要件を技術仕様に落とした設計書（QA承認必須） □ 設計仕様書（DS）：ABAP技術設計書（モジュール構成・DB設計・IF仕様） □ コードレビュー記録：別担当者によるABAPコードレビュー結果（署名付き） □ ユニットテスト記録：開発者が実施した単体テスト（入力/期待結果/実際結果） □ OQテスト実施記録：QA承認テストケースによる機能試験の実施記録 □ 移送依頼記録：Dev→QA→Prodの移送履歴（SE10/STMS） □ ソースコードバージョン管理：ABAPコードのバージョン管理（SE80/Git連携） □ 変更管理記録：本番移送前の変更管理委員会（Change Advisory Board）承認記録 |
バリデーション完了後のSAPシステムに対する変更はすべて変更管理（Change Control）の対象です。規制当局は「バリデートされたシステムが変更により無効化されていないか」を確認するため、変更の影響評価・承認・実施・バリデーション再実施の証拠を求めます。
| 変更の種類 | 例 | GxP影響評価の必要性 | 対応 |
| 緊急パッチ （Emergency Fix） | 本番システムの重大バグ修正 セキュリティパッチ適用 | 必要 （緊急対応後に事後評価可） | 緊急変更手順に従い実施後 事後評価・偏差報告を提出 |
| 計画的設定変更 （SPRO変更） | 組織構造の変更 検査設定の追加・変更 | 必要 （GxP影響あり機能は必須） | 変更管理委員会（CAB）で事前承認 影響テスト実施後に移送 |
| ABAPカスタム変更 | レポート機能追加 既存機能修正 | 必要（Cat.5） | フルバリデーション（DS/コードレビュー /OQテスト）を実施後に移送 |
| SAPアップグレード （Support Package） | SAPSPレベルアップ 新機能有効化 | 必要 リバリデーション計画が必要 | 回帰テスト計画を策定 影響機能のOQ再試験を実施 |
| インフラ変更 | DBバージョンアップ サーバー増設 | 必要（IQ範囲） | IQ項目の再確認 BASIS設定記録の更新 |
| セキュリティ変更 | ロール追加・削除 ユーザー権限変更 | 必要（アクセス制御） | 権限変更影響評価 アクセス制御SOPに従う |
| SAP変更管理の標準フロー（GxP対応） |
Step 1：変更要求（Change Request）起票 → 変更内容・理由・GxP影響度（H/M/L）・緊急度を記載 → 変更要求システム（変更管理ツールまたはSAP Solution Manager）へ登録 Step 2：GxP影響評価（Impact Assessment） → QA担当者がGxP影響度を評価 → 影響評価記録（どのバリデーション済み機能に影響するか）を文書化 Step 3：変更管理委員会（CAB）レビュー・承認 → IT・業務・QAの三者が承認（電子署名または手書き署名） → 実施スケジュール・リスク軽減策を確認 Step 4：Dev環境での実装・試験 → ABAP開発またはSPRO設定変更を実施 → 影響機能の回帰テスト（OQテストケース再実行） Step 5：QA承認とQA環境テスト → QA環境での確認試験 → QA承認記録（署名付き） Step 6：本番環境への移送（STMS） → CAB承認後に本番移送を実行 → 移送依頼番号を変更記録に記載 Step 7：変更記録のクローズ → 本番確認・異常なし確認後に変更記録をクローズ → バリデーション文書（TM・設定台帳）を更新 |
SAPのSupport Package適用・バージョンアップグレード・機能追加（Enhancement Package）は、バリデート済み機能に影響を与える可能性があります。リバリデーションの範囲を合理的に決定するため、影響評価（Impact Assessment）を実施し、「何を再試験するか」を根拠とともに文書化します。
| 変更内容 | リバリデーション範囲の判断 | 推奨アプローチ |
| SAPセキュリティパッチ （機能変更なし） | GxP機能への影響なし → IQ項目の更新のみ | パッチレベル更新記録 回帰テスト不要（理由文書化） |
| Support Package （SAP提供機能修正） | リリースノートを精査 GxP影響機能の特定 | 影響機能のOQテストケース再実行 サプライヤーリリースノートを証拠として添付 |
| Enhancement Package （新機能追加） | 追加機能のGAMP5カテゴリ判定 既存機能への影響評価 | 追加機能：新規URSからバリデーション 既存機能：影響評価+回帰テスト |
| SAP S/4HANA メジャーバージョンアップ | システム全体への広範な影響 フルリバリデーション計画が必要 | リバリデーション計画書を策定 全GxP機能の回帰試験 |
| カスタム開発の修正 （ABAP変更） | 変更されたABAPと 影響を受ける下流機能 | 設計仕様書更新 OQテストケース再実行（影響範囲） |
アップグレードのたびに全OQテストケースを再実行するのは非効率です。リスクベースドアプローチに基づき、「高リスク機能（患者安全・製品リリース直結）は常に再実行」「変更影響のある機能は選択的に再実行」「影響なし機能は影響評価記録を証拠として回帰テスト免除」という3段階の回帰テスト戦略を採用します。この戦略をリバリデーション計画書に明記することで、査察時に合理的判断の証拠を示すことができます。
| モジュール | GxP影響の主要機能 | バリデーション重点項目 |
| QM 品質管理 | 検査ロット生成・使用決定 在庫ステータス変更（321/344/553） MIC（管理特性）・許容値管理 | 在庫隔離→解放→棄却の制御が 設定通りに動作すること 使用決定と在庫移動タイプの連動 |
| MM 資材管理 | 原材料入庫（101） サプライヤー評価（ME61） MRO消耗品管理 | GxP原材料の受入検査連動 仕入先ブロック機能 バッチ管理・有効期限管理 |
| PP 生産計画 | 製造指図・バックフラッシュ GR（101）・廃棄（551） 製造記録（PHR連携） | 電子バッチ記録（EBR）との連携 製造指図ステータス管理 使用原材料の遡及性（Traceability） |
| WM/EWM 倉庫管理 | 保管場所別在庫追跡 有効期限管理（FEFO） シリアル番号追跡 | GxP原材料の保管条件管理 FEFOピッキングの動作確認 温度管理エリアの在庫制御 |
| FI 財務会計 | GxP費用の会計処理 廃棄損失の計上 保証コスト管理 | GxP費用コードの設定 廃棄品移動と費用計上の連動 |
| SD 販売 | 製品リリース判定後の出荷許可 出荷ブロック制御 シリアル番号出荷追跡 | QM使用決定と出荷ブロックの連動 製品シリアルの出荷記録 |
| 文書名 | 略称 | 目的・内容 | 保管期間の目安 |
| バリデーション計画書 | VP | プロジェクト全体のCSV方針・範囲・組織 | 製品ライフサイクル + 1年 |
| GxP影響評価書 | GxP-IA | 全機能のGxP影響度評価結果 | 同上 |
| GAMP5カテゴリ分類表 | Cat.Table | 機能・開発単位のカテゴリ分類一覧 | 同上 |
| リスクアセスメント記録 | RA | 機能別リスクスコア・対応方針 | 同上 |
| ユーザー要件仕様書 | URS | GxP要件を含む業務要件仕様 | 同上 |
| 機能仕様書 | FS | URSを機能設計に落とした仕様書 | 同上 |
| 設計仕様書（Cat.5のみ） | DS | ABAP等の技術設計仕様 | 同上 |
| サプライヤー評価記録 | SA | SAP社の品質システム評価記録 | 同上 |
| IQプロトコル・報告書 | IQ | インストール確認の計画・実施記録 | 同上 |
| OQプロトコル・報告書 | OQ | 機能試験の計画・実施記録 | 同上 |
| PQプロトコル・報告書 | PQ | 業務試験の計画・実施記録 | 同上 |
| トレーサビリティマトリクス | TM | 要件→設計→テストの対応表 | 同上 |
| 偏差報告書 | DR | 試験偏差・不具合の記録・分析 | 同上 |
| バリデーションサマリーレポート | VSR | バリデーション完了の総括報告書 | 同上 |
| 変更管理記録 | CCR | 本番リリース後の変更記録 | 変更日から5年以上 |
| CSV手順書（SOP） | SOP | 変更管理・定期レビュー等の手順 | 現行版 + 廃止後5年 |
以上