第4回：テスト戦略と実施における留意点

このコラムも第4回目となりました。今回は、コンピュータ化システムバリデーション（CSV）のプロセスにおいて、システムの設計や構築が完了した後、そのシステムが「実際の業務手順とデータを用いて、意図した通りに一貫して動作すること」を検証する、性能適格性評価（PQ : Performance Qualification）について取り上げます。
 

画像

システムそのものの技術的な構築（IQ:据付時適格性評価）や機能検証（OQ:稼働時適格性評価）は、SaaSやパッケージ導入においてはベンダー提供の文書を利用することが多くなりましたが、PQはユーザー企業が主体的に実施し、規制要件と自社の業務手順にシステムが適合していることを証明する、運用開始前の最終的な品質を担保するための活動です。
今回は、このPQを効果的かつ効率的に実施するための戦略と、「品質を証明する」ための具体的な勘所について解説します。

PQの目的は、ユーザー要求仕様書（URS）に記載された業務要件、すなわち「何を達成すべきか」を、業務プロセスの中で、実際の運用時の手順に基づいて検証することにあります。そのため、以下の点に留意すべきです。

PQにおける最も一般的な不備は、単に「システムがエラーを出さずに動いた」という機能テスト（OQの延長）で終わってしまうことです。本来のPQテストは、以下の要素を網羅したものであるべきです。

• 業務シナリオへの適合性: システムを利用する複数部署のユーザーや、関連する周辺のシステムとの接続/データ交換を含めた、実際の業務フロー全体を模擬したテストケースを計画します。この中でURSに記載した各要件の検証を可能とする手順を組み込んでいきます。
   
• 規制要件の充足: 特にデータインテグリティ（DI）や電子記録・電子署名（ER/ES）に関連する要件（例：監査証跡の自動記録、権限設定に基づくアクセス権管理等）が、業務の内容に即して適切に機能していることを検証します。
   
• 同時実行と負荷の検証: 当コラムの第3回「要件定義の精緻化」にも記載した通り、複数のユーザーが同時にシステムにアクセスした場合や、大量のデータを処理した場合においても、システムの応答速度やデータ処理の正確性が維持されることといった、非機能要件に関する検証を含めます。

規制対象システムでは、ユーザーの職務に応じてアクセス権限を厳格に分けるのが一般的です。PQでは、この権限管理が正しく機能していることを業務シナリオの中で検証するべきです。ユーザーごとに許可された操作のみが実行できることを確認します。
 

現代のシステムは単体で完結することは稀であり、ERP、LIMS、あるいは製造装置といった外部との連携が不可欠です。PQでは、この「システムの境界（インターフェース）」におけるデータの整合性として、欠損や意図せぬ変換などが生じていないかを、実際の業務プロセスの中で検証する必要があります。分析機器や自動倉庫など、物理的な機器に接続されるシステムでは独立した検証環境が用意できないこともあるため、リスクを踏まえながら本番環境での部分検証も計画します。
 

PQの信頼性は、使用するテストデータの現実性に大きく左右されます。PQは本番環境での運用を控えての最終的な検証となるため、適当な値を入力するようなその場限りの確認ではなく、実際の業務において発生し得る多様なデータを想定して準備することが重要です。また、バッチ処理のパフォーマンス検証といったケースでは、本番運用時に実際に処理が想定されるデータ量を考慮する必要があります。

CSVにおけるテストは、単に「システムが正常に動くこと」を確認するだけでは不十分です。動くべきでない（エラーとなるべき）箇所は正しく止められることの検証も必要です。

• ポジティブテスト（正常系）: 通常の業務フローと、最も頻繁に使用されるデータを模擬したシナリオ。これにより、システムの機能が期待通りに動作することを確認します。
   
• ネガティブテスト（異常系）: エラーメッセージの表示など、システムが予期せぬ入力を適切に拒否するかを検証するシナリオ。例えば、文字数や文字種などの規定外の文字入力、数値の上限・下限を超えた入力、必須項目が未入力の場合などで、異常に対するシステムの「防御力」を確認します。

これらの観点でのテストは、PQでは業務で使うデータや、誤って受け入れられては困るデータなどを用いて検証します。やりすぎるとキリがない話ですが、特に異常系のテストはリスクに応じてどこまで行うのかを判断します。
 

PQは、通常、本番環境とは異なる検証環境（バリデーション環境又はUAT環境ともいう）で行われます。この環境の違いを踏まえ、使用するデータは、本番環境のデータと明確に区別し、適切に管理する必要があります。

• 個人情報・機密データの取り扱い: 本番環境からコピーした個人情報や機密性の高い業務データを検証環境で使用することは、重大なセキュリティリスクを伴う場合があります。検証環境は、システム構成や設定の確認、様々な条件でのテストを自由に行うためのセキュリティ設定の緩和により、本番環境と比較して外部攻撃に対する防御が脆弱な場合があるためです。
   
• マスキングとダミーデータの活用: テストの現実性を担保しつつ、機密情報の漏洩を防ぐためには、検証用にデータの匿名化（マスキング）や、現実のデータ特性を模したダミーデータを生成して準備することも必要になります。

１章でも述べた通り、システムの性能検証や外部システムとの連携検証など一部の検証のために本番環境を利用する必要がある場合は、その検証で使用するデータが本番運用時に影響を与えないよう検証後に適切に処理することを計画し、PQ手順書に記載することが望ましいです。
 

PQのテストの結果は、単に合否を記録するだけでなく、後日の監査において「誰が、いつ、何を確認したか」を客観的に証明できるものでなければなりません。不正確であったり、改ざんの疑いを招くものであったりすれば、バリデーション全体の信頼性が危うくなります。監査に耐えうる記録を作成・維持するための原則を理解しておく必要があります。

テストの結果記録は、多くの場合、あらかじめ準備されたPQ手順書（テストスクリプト）に、実施者が結果を記入する形式で行われます。重要なのは、テスト結果を単に「OK」「NG」と記録するだけではなく、その合否判定の根拠を明確に示すことです。

• 期待結果の明確化: PQの範囲とする業務全体のシナリオに対し、PQ手順書には、実施する個々の操作手順（例：ボタンをクリック、データを入力）に加え、その結果としてシステムが「どのような状態となるのか」を具体的に記載しなければなりません。例えば、1ステップの操作に対し「画面上に『処理完了』のメッセージが表示され、かつ、関連する監査証跡に記録が生成されること」などを記載します。
   
• 期待結果との照合記録: テスト実施者は、操作後の状態が、このPQ手順書に記載された期待結果と一致したかどうかをOK/NGといった記録として残します。加えて、そのことを証跡として残すために、出力されたデータファイルやシステムログ、スクリーンショットを残すケースもあります。どのステップで何を証跡として残すかは、PQ手順書にあらかじめ指定することが望ましいです。

テスト結果の記録は、テスト実施と同時に行うことで、記録の正確性と同時性を保ちます。後からまとめて記録を作成することや、スクリーンショットを後日撮り直すことは、記録の信頼性を損なうため避けるべき行為です。同様に、同時性が保たれていることを保証するために、スクリーンショットはPCの日時が写り込む形で取得することもルールの一つです。
 

PQの実施中に、期待された結果と異なる事象が発生した場合、それは逸脱として正式な管理プロセスに乗せる必要があります。PQフェーズでの逸脱は、単なるシステムの不具合で片付けるわけにはいかず、「ユーザー要求（URS）とシステムの機能が適合していない」＝「業務に適用できない」ことを裏付ける証拠となり得ます。

ただし、PQテストで発生した全ての予期せぬ結果が、同じ厳格さで処理されるわけではありません。逸脱は、生じた原因やデータインテグリティ面も含めた影響の度合に応じて、その後の対応プロセスを分岐する必要があります。

• 軽微な問題: テスト手順の誤記、UI上の軽微な表記違い、あるいは業務やデータの品質、データインテグリティに影響を与えないテスト実施者の操作ミスなどを含みます。これらは、生じた事象を記録した上で、システムの適格性や品質に影響がないことを判断することで、逸脱管理プロセスから切り離して対処されることが多いです。ただし、実施者が単独で判断するべきではなく、確認者や責任者など2名以上の確認と合意の上で処理すべきです。
   
• 重大な逸脱: 特にシステムの構成設定や実装上の誤りにより、ユーザー要求仕様（URS）に定義されたクリティカルな要件が満たされず、その結果、データの正確性や見読性といったデータインテグリティが損なわれる可能性がある場合、あるいは製品品質や患者さんの安全性に影響を及ぼす欠陥が確認された場合が該当します。これらの重大な逸脱は、システムの適格性自体に疑義を生じさせるため、厳格な逸脱管理プロセスを適用して、文書化、影響評価、原因分析の上で対策を実施する必要があります。

逸脱が発生した際、最も避けるべきは、影響評価や原因の深掘りを行わない場当たり的な対応です。特に、問題を安易に「人的ミス」として片付け、その場しのぎの修正と極小部分の再テストだけで済ませてしまう傾向には注意が必要です。真の原因がシステムの仕様不備や論理的な欠陥にある場合、再テストの範囲が不適切であれば、潜在的なリスクを抱えたまま本番稼働を迎えることになります。

性能適格性評価（PQ）は、単なるバリデーションの1ステップではなく、ユーザー企業がシステムを信頼し、規制環境下で適切に業務利用することを担保するための、規制要件及び業務要件への適合性保証とも言えるものです。PQは、OQ的な機能検証に留まるものではなく、ユーザー企業の業務に即した現実的なシナリオとデータを用い、信頼性の高い記録を作成し、厳格な逸脱管理を行うことで、システムの品質をより確かなものにすることができます。

次回は、CSVの成果物である文書を、監査に耐えうる「資産」として活用するための、文書管理の勘所と効率化について解説します。どうぞご期待ください。

著者紹介

2015年までの約20年間、製薬企業向けコンサルティング会社にてシステム開発に従事。Part11制定当初よりCSVの実施に携わる。
CROへの移籍とそこでのシステム部門長としてのCSV文書レビュー等を経て、2020年よりシーエーシーに在籍。
同業界における経験を活かし、GxP適用のクラウド環境構築・運用サービスの立ち上げや、CSV支援サービスに携わり、現在に至る。

関連リンク：
Webサイト「Innovation Hub」に、株式会社シーエーシーのCSV支援サービスの記事が掲載中です。