CQVマスタープランとは

ほとんどのバリデーションプログラムは、実施の段階で失敗するわけではありません。プログラムが何を証明すべきかを、誰も事前に書き留めなかったために失敗するのです。それが明らかになる頃には、誰も合意していない前提に基づいて200ものプロトコルが書かれています。

これを防ぐ文書がCQVマスタープランです。バリデーション文書体系の頂点に位置し、その下にあるすべての文書、すなわちシステムレベル影響評価、品質リスク評価、ユーザー要求仕様書、FATおよびSATプロトコル、IQ、OQ、PQ、要求事項トレーサビリティマトリクスが、その考え方を受け継ぎます。

CQVマスタープランに記載すべき内容

査察官がたどることができ、プロジェクトチームが実際の拠り所にできるCQVMPは、次の九つの事項を扱います。

1. 範囲とシステム境界

どのシステム、どの建屋、どのフェーズを対象とするか。さらに重要なのは、各システムがどこで終わるかです。たとえば精製水の製造設備と供給ループの間、あるいは充填ラインとそれを囲むアイソレータの間の境界をめぐる食い違いは、適格性評価のギャップの最も一般的な原因です。二つのチームがそれぞれ、インターフェースは相手の担当だと思い込んでいるのです。

境界は図面上に引き、その図面番号を参照し、明示的に範囲外とするものを列挙します。

2. 組織と責任

誰が作成し、誰がレビューし、誰が実施し、誰が承認し、誰が逸脱を受け入れる権限を持つか。リスクベースのアプローチでは、これは以前よりも重要になります。従来は既定で品質部門にあった判断を、各分野の専門家（SME）が担うようになるからです。

3. リスク評価のアプローチ

これが文書の核心です。どの手法を用いるか、影響のカテゴリーは何か、重要度をどのように判断するか、そして決定的に重要な点として、リスク評価の結果をどのように適格性評価の深さに反映させるかを記載すべきです。システムを分類するだけで、その後の対応を何も変えないリスク評価は、飾りにすぎません。

4. 文書体系

プログラム内のすべての文書の種類、それぞれの役割、文書同士のトレースの関係を示した全体図です。これがあるからこそ、要求事項トレーサビリティマトリクスを、発掘作業ではなく構築作業として作成できます。

5. 活用戦略

コミッショニングの証拠を適格性評価の裏付けに使う場合（ASTM E2500およびISPE Baseline Guide Volume 5のもとでは、通常そうすべきです）、CQVMPはそれを条件とともに合意する場です。校正済みの計器、教育訓練を受けた実施者、文書管理、そして品質部門による事前承認です。事後に決めた活用は活用ではありません。後付けの正当化を添えたギャップです。

6. 受け入れ基準の考え方

基準そのものではありません（それはプロトコルに記載します）。基準を設定するためのルールです。基準の出所はどこか。URS、ベンダー仕様、規制上の限度値、プロセス要求事項のいずれか。基準を記載どおりに満たせない場合はどうするか。

7. 逸脱と不一致の処理

分類、誰が何を完了させられるか、そして拠点QMSへのエスカレーション経路です。拠点の逸脱手順と連携していないCQVMPは並行する品質システムを生み出し、査察官はそれに気づきます。

8. 変更管理とのインターフェース

実施中の設計変更は必ず発生します。計画には、変更がバリデーションに与える影響をどのように評価し、再実施が必要かどうかを誰が判断するかを記載すべきです。

9. リリース基準

システムをGMP製造に使用できるようになる前に、何が満たされ、文書化されていなければならないか。これはプログラム全体が答えるために存在する問いであり、それが暗黙のままにされていることの多さには驚かされます。

文書体系における位置づけ

CQVマスタープラン（CQVMP）
 ├── システムレベル影響評価（SLIA）
 ├── 品質リスク評価（QRA）
 ├── ユーザー要求仕様書（URS）
 │    └── 設計時適格性評価（DQ）
 ├── FAT／SATプロトコル
 ├── IQ／OQ／PQプロトコルおよび報告書
 ├── 要求事項トレーサビリティマトリクス（RTM）
 └── バリデーション総括報告書 → システムリリース

各層は、その上の層から導き出せるものであるべきです。あるOQ試験を、RTMを通じてURSの要求事項へ、そこからリスク評価における重要度の判断へ、さらにCQVMPに定めたアプローチへとさかのぼれないのであれば、それは理由のない試験です。そして査察官は、なぜそれを実施したのか、あるいはなぜ別のものを実施しなかったのかを尋ねるでしょう。

CQVMPを失敗させる五つの誤り

プロトコルの作成開始後に書くこと。 そうなると計画は、あるべき姿を管理するのではなく、起こったことを記録するものになります。境界は完了済みの作業の周りに引かれます。

システム境界を定義しないままにすること。 インターフェースこそ、適格性評価のギャップが潜む場所です。インターフェースの担当者を計画に記載しなければ、誰も担当しません。

リスクアプローチをエンジニアリングとだけ合意し、品質部門と合意しないこと。 そのアプローチから生まれた判断を最終的に説明しなければならないのは品質部門です。事後の承認は承認ではありません。

活用戦略がないこと。 コミッショニングを適格性評価として繰り返すか（高コストで時間がかかり、コンプライアンス上も何ら優れていません）、文書化された根拠なしに活用するか（さらに悪い結果になります）のどちらかになります。

受け入れ基準を完全にプロトコル任せにすること。 考え方が示されていなければ、15人のプロトコル作成者が15通りの基準を作り出し、その不整合はレビューの段階になって初めて表面化します。

CQVマスタープランが必要な場合

数個を超えるシステムを含むプロジェクト、あらゆるグリーンフィールド施設、あらゆる技術移転、そして複数の組織が実施に関わるあらゆるプログラムです。成熟したVMPを持つ稼働中の拠点での単一設備の適格性評価であれば、独自のマスタープランは不要かもしれません。しかし、何らかのマスタープランの傘下に位置づけられている必要はあります。

判断基準は単純です。明日新しいエンジニアがプロジェクトに加わったとして、その人は文書から、何を、なぜ、どの深さで適格性評価するのか、そして「完了」とは何を意味するのかを判断できるでしょうか。できないのであれば、文書の名称が何であれ、計画は存在しないのと同じです。