教えて Pharman Cloud
CSV / CSA / GAMP 5 2nd Edition

【CSAとGAMP5改訂】コンピュータソフトウェアアシュアランスとCSV最新実務

形式的なテストスクリプト作成と過剰な文書化(ドキュメンテーション)に疲弊する従来のCSVから、FDAが推進するクリティカルシンキング重視のCSAアプローチへの転換点を詳解します。

公開日: 2026年9月16日 / 最終更新: 2026年9月22日 / 実務ガイド

目次

  1. 従来のCSVが抱えていた「過剰文書化」の限界とCSA登場の経緯
  2. CSV vs CSA:アプローチとテスト手法の根本的相違
  3. GAMP 5 第2版(2nd Edition)の改訂要点とライフサイクル
  4. クリティカルシンキングに基づくリスクアセスメント実施手順
  5. アンスクリプテッドテスト(Unscripted Testing)の実務と記録化
  6. CSA導入チェックリスト & よくある質問(FAQ)

1. 従来のCSVが抱えていた「過剰文書化」の限界とCSA登場の経緯

従来のコンピュータ化システムバリデーション(CSV: Computerised System Validation)は、本来の目的である「ソフトウェアが意図した通りに安全に動作することの保証」から乖離し、「査察官に見せるための膨大なスクリーンショットの印刷とサイン集め(過剰文書化)」へと形骸化していました。

製薬企業では検証工数の80%が文書作成・証拠画像貼付に費やされ、実際のテストや探索的バグ発見には20%しか割けないという本末転倒な状況が生じていました。これが新技術(クラウド、SaaS、自動化ツール、AI)の製薬現場への導入を妨げる最大の障壁となっていました。

この危機感を背景に、米FDAのCDRH(医療機器・放射線保健センター)およびCDER(医薬品評価研究センター)が中心となって提唱したのが「コンピュータソフトウェアアシュアランス(CSA: Computer Software Assurance)」です。2022年にドラフトガイダンスが公開され、ISPE GAMP 5 第2版にも全面的にその概念が取り入れられました。

2. CSV vs CSA:アプローチとテスト手法の根本的相違

CSAは従来のCSVを否定するものではなく、「クリティカルシンキング(批判的思考)」と「リスクベースアプローチ」を徹底することで、無駄な文書化を削減し、真の品質保証活動に資源を集中させる枠組みです。

比較項目 従来のCSV(Validation) 最新のCSA(Assurance)
重点志向 文書化・エビデンス(画面キャプチャ)中心 テスト実行・ソフトウェアの信頼性確認中心
工数配分 文書作成 80% : テスト実行 20% 文書作成 20% : テスト実行 80%
リスク評価 システム全体の包括的リスク評価のみ 「意図した機能」ごとの患者安全・製品品質への直接影響度評価
テスト手法 詳細なスクリプトテスト(一字一句指示・全画面キャプチャ貼付) アンスクリプテッドテスト(探索的テスト)、ハイレベルテスト、サプライヤー検証活用
ベンダー監査活用 形式的なベンダーチェックシート記入 SaaS/ベンダーのテストエビデンスを最大限レバレッジ(重複テスト排除)

3. GAMP 5 第2版(2nd Edition)の改訂要点とライフサイクル

2022年7月に14年ぶりに改訂された「ISPE GAMP 5 Second Edition」では、アジャイル開発、クラウド(IaaS/PaaS/SaaS)、継続的インテグレーション(CI/CD)、そしてCSAの概念が公式に統合されました。

ソフトウェア分類(GAMPカテゴリ) 分類定義と具体例 CSAにおけるアシュアランス戦略
カテゴリ1: 基盤ソフトウェア OS、データベースエンジン、仮想化環境 サプライヤーの適格性確認とバージョン管理のみ。追加テスト不要。
カテゴリ3: ノンコンフィグ製品 計量器、標準オフィスソフト、定型スタンドアロン機器 サプライヤーの出荷試験を信頼。業務プロセスへの適合性(アンスクリプテッド)テスト。
カテゴリ4: コンフィグ製品 LIMS、MES、ERP、EDMS(パッケージソフトの設定変更運用) 設定(コンフィグレーション)部分にフォーカス。標準機能はベンダー検証を活用。
カテゴリ5: カスタム(独自開発) 自社専用にコーディングされたスクリプト、独自マクロ 直接患者リスクと直結するため、詳細なスクリプトテストおよびコードレビューを実施。

4. クリティカルシンキングに基づくリスクアセスメント実施手順

CSAでは、システムの「どの機能が患者安全や製品品質、データ完全性に直接影響するか」を機能単位で判断します。

CSA適用の3ステップ判定ロジック

1
意図した使用(Intended Use)の特定: ソフトウェアまたは機能が「製造・品質試験・出荷判定・公的記録」に直接関与するかを判定。
2
直接リスク vs 間接リスクの分類: 故障時に「規格外品の流出」「データ改ざんの見逃し」が直ちに起きるか(Direct Impact)、補助的・管理用にとどまるか(Indirect/Non-GxP)を評価。
3
適切なテスト手法の選定: 高リスク機能にはスクリプトテスト、中低リスク機能にはアンスクリプテッドテスト(探索的テスト)やベンダー評価を割り当て。

5. アンスクリプテッドテスト(Unscripted Testing)の実務と記録化

CSAの最大の革新は、「アンスクリプテッドテスト(スクリプトなしテスト)」の公式承認です。ステップごとの詳細なマニュアルを作らず、テスターの専門知識を活用して「自由にシステムを操作し、限界値や例外操作を試す」テストが推奨されます。

【アンスクリプテッドテストの記録に残すべき必須事項】
  • テスト目的(Objective): 何を検証しようとしたのか(例: ユーザーが同時に同一ロットの承認ボタンを押した際の排他制御確認)。
  • テスター名・資格・実施日時: 業務に精通したテスターの署名。
  • 実行環境・バージョン: テストを実施したシステム環境とビルド番号。
  • 合否結果と観察事項: 期待通りの挙動をしたか、不具合(バグ)の有無。画面キャプチャは「不具合発生時」のみ貼付すればよく、正常終了時はキャプチャ不要。

6. CSA導入チェックリスト & よくある質問(FAQ)

【CSA運用体制自己点検チェックリスト】
  • [ ] 社内CSVポリシー・SOPにおいて「CSA」および「アンスクリプテッドテスト」の適用根拠が規定されているか?
  • [ ] テスト計画において「全画面キャプチャの義務」が撤廃され、リスクベースの証拠収集基準が定義されているか?
  • [ ] クラウドサービス(SaaS)利用時、ベンダーのリリースノートやSOC2報告書・監査証跡を適格性評価資料として活用できているか?
  • [ ] テスターに対して「クリティカルシンキング研修」および探索的テストの実施手法が教育されているか?

Q1. 日本のPMDA査察でもCSAアプローチ(アンスクリプテッドテスト)は認められますか?

A. はい、十分に認められます。改正GMP省令におけるコンピュータ化システム管理指針でも「システムの特性およびリスクに応じた柔軟な検証」が認められています。重要なのは、「なぜその機能をアンスクリプテッドで十分と判断したのか」というリスクアセスメントの論理的根拠(クリティカルシンキングの記録)を査察官に明快に説明できることです。

Q2. 画面スクリーンショットを一切貼らないと査察で指摘されませんか?

A. FDAのドラフトガイダンスでは「正常にパスしたテストについて、1ステップごとにスクリーンショットを貼る行為は不要な負荷であり、品質向上に寄与しない」と明確に述べています。合格時はテスターの署名と実行日時、テスト環境の記録で十分であり、キャプチャはエラー発生時や高リスクな重要計算式の結果確認などに限定するのが国際標準です。

【専門情報・免責事項】

本ガイドはFDA Computer Software Assuranceガイダンス、ISPE GAMP 5 2nd Edition、PIC/S Annex 11に基づく解説です。社内システムのバリデーション計画・手順書改訂の際は、自社の品質保証責任者および最新の公的ガイドラインをご確認ください。

← ガイド一覧に戻る / データインテグリティ実務解説 → / チャットで質問する