CSV（コンピュータ化システムバリデーション）とは？GAMP 5の考え方

そこで問われるのが、「そのシステムは、意図したとおりに、正しく動いているといえるか」です。装置や工程にバリデーション試験法が目的に合う性能を持つことを立証する妥当性確認。正確さ・精度などを評価する。詳しく →（妥当性確認）が求められるのと同じように、品質に関わるコンピュータ化システムにも、それが期待どおり機能することを証明する仕組みが要る。これがコンピュータ化システムバリデーション（CSV, Computerized System Validation）です。

ただ、CSVを支える考え方は一つではありません。本稿では、まずCSVが何を示す作業なのかを揃えます。そのうえで、実務の共通言語である GAMP 5 のソフトウェア分類とVモデル、FDAが後押しするリスクベースの手法（CSA）、電子記録を規定する 21 CFR Part 11 と EU GMP Annex 11コンピュータ化システムに関するEU GMPの付属書。監査証跡の定期的なレビューなどを求める。詳しく →、そして データインテグリティ との関係を順に整理します。バラバラに見えるこれらは、結局「そのシステムを信頼してよいか」という一点でつながっています。

CSVとは何か ― システムを「信じてよい」と示す作業

まず前提を揃えます。 CSVは、品質に関わるコンピュータ化システムが「意図した用途どおりに、正確・一貫して機能する」ことを、文書化された証拠で示す一連の活動です。 完璧なソフトウェアを作ることが目的ではありません。そのシステムに依存して品質判断をしてよいと示すことが、CSVの本質です。

ここでの「コンピュータ化システム」は、ソフトウェア単体ではありません。ソフトウェア、それが載るハードウェア、接続される装置や周辺機器、運用する人と手順（SOP作業の手順を定めた文書。品質システムの要素を具体化し、査察でも運用が確認される。詳しく →）。その全体を指します。制御プログラムだけが正しくても、運用手順やアクセス権限の設計が甘ければシステムとしては信頼できない。CSVはこの全体を対象にします。

対象になるかどうかの目安は単純です。そのシステムが扱うデータや判断が、製品品質・患者安全・規制上の記録に関わるか。GMPなどのGxPに影響するかどうかです。給与計算システムは規制対象外です。米国なら 21 CFR Part 211 が、日本なら GMP省令 が対象の外枠を決めます。試験結果を保存するLIMS検体・試験・結果などラボの情報を一元管理するシステムです。データの追跡性を確保し、記録の正確さと業務の効率化を支えます。詳しく →（試験室情報管理システム）や、製造記録を電子化するMES（製造実行システム製造装置の監視・制御(SCADA)と、製造手順や記録の管理(MES)を担うシステムです。工程の実行状況を見える化し、記録を残します。詳しく →）は対象です。すべてを同じ厳しさで扱いません。影響の大きさに応じて力の入れどころを変える。この発想が、後述するリスクベースリスクの大きさに応じて管理の濃淡や頻度を決める考え方。監査証跡レビューの頻度決定に用いる。詳しく →の考え方につながります。

GAMP 5 ― 業界の共通言語

CSVの進め方に、単一の法的な正解はありません。

各極の規制は「妥当性を確認せよ」とは求めても、手順の細部までは規定しません。そこで実務の拠り所になっているのが、ISPE が発行する GAMP 5 です。リスクの見積もり方は ICH Q9 に、システムをどう品質システムへ組み込むかは ICH Q10医薬品品質システムを定めた国際ガイドライン。ライフサイクルを通じた品質マネジメントの考え方を示す。詳しく → に接続します。2022年に第2版が公表され、リスクベースの考え方とソフトウェアアシュアランスの発想をより明確にしました。初版から10年以上を経ての改訂です。

GAMP 5GxP対応のコンピュータ化システムを検証する進め方を示す、ISPE発行の業界標準ガイド。の中核の一つが、ソフトウェアを性質で分類し、必要な検証の重さを変えるという発想です。市販のありものをそのまま使うのか、設定でカスタマイズするのか、独自に開発するのか。由来によってリスクの出方が違うので、同じ労力をかけるのは合理的ではありません。実務では4区分が使われます。かつてのカテゴリ2（ファームウェア）は、現行の GAMP 5 では独立区分として使いません。

カテゴリ1はインフラと基盤ソフトです。OS、データベース基盤、ネットワークがここに入り、検証の中心は設定管理です。カテゴリ3は設定しない市販品で、単純な計測機器のファームウェアや汎用パッケージ。意図した用途での機能確認が中心です。

カテゴリ4は設定する市販品で、LIMSやMES、ERPを自社向けに設定して使う場合にあたります。設定内容に対して IQ / OQ / PQ を当てる。カテゴリ5はカスタム開発で、独自スクリプトや自社開発アプリが該当し、開発ライフサイクル全体の検証が要ります。試験室なら Thermo Fisher Scientific の SampleManager のようなLIMSがカテゴリ4の典型で、そこへ自社で書いた計算スクリプトを足せば、その部分だけカテゴリ5として扱います。

同じシステムの中に、違うカテゴリの部分が同居します。システム単位で分類すると、自社で書いた部分の検証が抜けます。

数字が大きいほど、そのシステム固有の不具合が入り込む余地が大きく、検証も重くなるというのが基本の直感です。ただしカテゴリは目安であって自動判定装置ではありません。同じLIMSでも、標準機能だけを使うのか複雑な計算式を組むのかで実際のリスクは変わります。 カテゴリはリスク評価工程や製品に潜在するリスクの種類・発生可能性・影響度を系統的に特定・分析し、優先的に管理すべき項目を決定する手続き。詳しく →の出発点であって、それだけで検証範囲が決まる免罪符ではない、という点が実務では重要です。

Vモデル ― 要求と検証を対応づける

GAMP 5がCSVの進め方として示す代表的な枠組みが、Vモデル左側で要求を段階的に詳細化し、右側で各要求に対応する検証を積み上げるCSVのライフサイクル枠組み。と呼ばれるライフサイクルです。左側を下りながら要求を段階的に詳細化し、右側を上りながらそれぞれの要求に対応する検証を積み上げていく。このV字の形が名前の由来です。

左側では、まずユーザ要求仕様（URS, User Requirements Specification）で「このシステムに何をさせたいか」を定義し、そこから機能仕様（FS）や設計仕様（DS）へと具体化します。右側では、その各段に対応づけて、据付時適格性評価（IQ, Installation Qualification製造装置やユーティリティが意図どおりに据え付けられ、動き、性能を出せることを文書で裏づける活動。詳しく →）で正しく設置・構成されたか、運転時適格性評価各機能が機能仕様どおりに動くかを確認する検証。Vモデルの右側に位置づけられる。詳しく →（OQ, Operational Qualification）で仕様どおりに動くか、性能適格性評価実運用条件で意図した用途・狙いの性能を満たすかを確認する検証。ユーザ要求仕様に対応する。詳しく →（PQ, Performance Qualification）で実運用条件で狙いの性能が出るかを確認します。

対応は三つです。ユーザ要求仕様（URS）に対して性能適格性評価（PQ）が、実運用条件で意図した用途を満たすかを確かめる。機能仕様（FS）に対して運転時適格性評価（OQ）が、各機能が仕様どおり動くかを見ます。設計仕様（DS）に対して据付時適格性評価システムが正しく設置・構成されているかを確認する検証。Vモデルで設計仕様に対応する。詳しく →（IQ）が、正しく設置・構成されているかを確認する。

Vモデルの要点は、検証項目が思いつきではなく、必ずどこかの要求に紐づいている点です。URSに書かれていない機能はテストの根拠を持たず、逆にURSにある要求はどこかで必ず検証される。この対応づけ（トレーサビリティ要求と検証を一対一で結びつけ追跡できるようにすること。抜け漏れと過剰検証の両方を防ぐ。詳しく →）が、抜け漏れと過剰検証の両方を防ぎます。 Vモデルは検証を網羅するための道具ではなく、要求と検証を一対一で結び、労力を要求の重要度に沿って配分するための地図です。

リスクベースへ ― CSVからCSA（Computer Software Assurance）へ

Vモデルは強力です。

ただ、運用を誤ると「とにかく大量のテスト文書を作る」作業に陥ります。すべての機能を同じ密度でスクリプト化し、証跡のためのスクリーンショットを延々と貼る。本来の目的である品質・患者安全への寄与よりも、文書量が目的化してしまうという反省が、次のCSA労力を患者安全・製品品質への影響が大きい機能に集中させる、FDAが後押しするリスクベースの考え方。という考え方につながります。

これに対してFDAが後押ししているのが、CSA（Computer Software Assurance労力を患者安全・製品品質への影響が大きい機能に集中させる、FDAが後押しするリスクベースの考え方。, コンピュータソフトウェアアシュアランス）という考え方です。2022年にFDAが発行した、製造・品質システム向けソフトウェアのドラフトガイダンスで示された発想です。労力を、そのソフトウェアが患者安全と製品品質に与える影響に応じて配分します。影響の小さい機能は供給者の検証や単純な確認で足りるとみなし、影響の大きい機能に検証の力を集中させます。

CSAはVモデルやGAMP 5を否定するものではなく、その中でリスクに応じてテストの手法と記録の粒度を選び分ける、という上乗せの考え方です。影響の小さい機能はアドホックテストあらかじめ詳細な手順書を用意せず、テスト担当者が探索的に操作して動作を確認する非形式的なソフトウェアテスト手法。、つまり探索的な操作確認で足ります。影響の大きい機能にはスクリプト化した厳密なテストと詳細な証跡を残す。そうやって濃淡をつけます。 CSAの狙いは検証を減らすこと自体ではなく、証跡づくりに割いていた労力を、本当にリスクの高いところへ振り向け直すことにあります。

電子記録・電子署名 ― 21 CFR Part 11 と EU GMP Annex 11

CSVと切り離せないものがあります。

システムが生み出す電子記録の信頼性です。紙の記録を電子記録に置き換えるとき、その電子記録を紙と同等に信頼できるものとして扱うための要件を定めているのが、FDAの21 CFR Part 11記録が正確で完全・改ざんされていないことを保証する考え方で、ALCOA+などの原則で健全性を管理します。詳しく →（電子記録・電子署名に関する規則）です。EUでは EU GMP Annex 1無菌医薬品の製造に関するEU GMPの付属書。汚染管理戦略などを求める無菌製造の基準。詳しく →1（コンピュータ化システム）が対応します。

日本では改正GMP省令が、データインテグリティの確保を同じ方向から求めています。これらが求めるのは大きく分けて二つです。ひとつは電子記録の真正性を守る仕組みです。システムバリデーション、監査証跡、アクセス制御システムの機能やデータへのアクセスを、権限を付与された利用者のみに限定する仕組みで、不正操作や改ざんを防ぐために用いられる。、正確なコピーの生成。もうひとつは電子署名を手書き署名と法的に同等とみなすための要件で、署名者の一意な特定、署名と記録の不可分な結合、署名の意味の明示が要ります。電子署名は単なるパスワード入力ではなく、「誰が・いつ・何の目的で（承認/レビュー/作成）署名したか」が記録に固定されていなければなりません。

CSVはこれらの要件を「満たしていることを示す」手段でもあります。監査証跡が無効化できない設定になっているか。共有IDが使えない権限設計になっているか。バックアップと長期可読性が確保されているか。こうした点はCSVのテスト項目としてURSそのシステムに何をさせたいかを定義する文書。Vモデルで検証項目をひもづける起点になる。詳しく →に落とし込まれ、OQ / PQ で確認されます。 Part 11 と Annex 11 が「何を守るべきか」を規定し、CSVが「それが実際に守られていること」を裏づけます。

データインテグリティとの関係

CSVの最終的な目的は、そのシステムが生み出す記録を信頼できるものにすることです。ここで データインテグリティ（データの完全性・信頼性）と正面から結びつきます。記録が満たすべき属性を整理したのが ALCOA+ の原則です。帰属性（Attributable）、同時性（Contemporaneous）、完全性（Complete）。どれも、CSVがシステムに作り込むべき要件そのものです。

たとえば「誰が操作したか特定できる（帰属性）」を担保するには共有IDを禁じるアクセス設計が要り、「失敗データも含めてすべて残る（完全性）」を担保するには削除できない監査証跡いつ誰が何をしたかを記録し、改ざんや削除ができないようにした操作履歴。記録の信頼性を支える。詳しく →が要る。これらはいずれもCSVでURSに書き込み、検証で確認する対象です。 ALCOA+ が求める姿を書き、CSVがそれを作り込む。両者は一体です。

運用フェーズ ― バリデーションは導入時で終わらない

CSVは、導入時に一度やって終わりではありません。コンピュータ化システムはライフサイクル全体を通じて検証状態（バリデートされた状態）を維持する必要があります。OSやパッチの更新、設定変更、装置の追加、供給者の仕様変更。こうした変化のたびに影響範囲を評価し、必要な再検証を判断する変更管理が要ります。

運用フェーズで特に重要になるのが、変更管理工程・設備・手順などの変更を評価・承認し、品質への影響とともに記録する仕組み。詳しく →・逸脱承認された手順や規格から外れた事象。GMPでは発見したら記録し、製品品質への影響を評価してロットの可否を判断します。詳しく →管理・定期レビュー・バックアップ/リストアの確認・アクセス権限の棚卸しです。導入時に完璧でも、無管理の変更が積み重なれば検証状態は崩れます。設計時のリスク評価から運用・保守・廃棄までを一続きで捉える発想は、プロセスバリデーション がライフサイクル全体で品質を作り込むのと同じ考え方に立っています。 CSVは一度きりのイベントではありません。システムが使われ続ける限り、維持し続ける活動です。

決める順番

最後に、CSVをどの順で組むかを並べます。

先に決まるのは、そのシステムがGxP製品品質・患者安全・規制上の記録に関わる規制要件の総称。CSV対象かどうかの判断基準になる。に関わるかどうかです。扱うデータや判断が製品品質・患者安全・規制上の記録に関わるか。給与計算システムは対象外で、LIMSやMESは対象。⁠ここを曖昧にしたまま「とりあえず全部やる」と決めると、労力の配分が最後まで決まりません。

次に、システムの中をカテゴリで割ります。市販品をそのまま使う部分、設定して使う部分、自社で書いた部分。同じシステムの中に違うカテゴリが同居するので、システム単位ではなく機能単位で見ます。自社で書いたスクリプトだけがカテゴリ5、という切り分けが普通です。

そのうえで、検証の濃淡を決めます。CSAの考え方に沿って、患者安全と製品品質への影響が大きい機能へ力を集中させる。影響の小さい機能は供給者の検証や探索的な操作確認で足ります。⁠減らすことが目的ではなく、証跡づくりに割いていた労力を振り向け直すことが目的です。

最後に、運用フェーズの管理を先に設計します。変更管理、逸脱管理、定期レビュー、バックアップとリストアの確認、アクセス権限の棚卸し。導入時に完璧でも、無管理の変更が積み重なれば検証状態は崩れます。ここを導入後に決めようとすると、最初のOSパッチで判断の根拠がありません。

CSVは文書を作る作業ではありません。そのシステムに依存して品質判断をしてよいと言えるところまで、根拠を積む作業です。

参考文献

• FDA, 21 CFR Part 11: Electronic Records; Electronic Signatures
• FDA, Computer Software Assurance for Production and Quality System Software（ドラフトガイダンス）
• EMA, EudraLex Volume 4, EU GMP Annex 11: Computerised Systems
• ISPE, GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems（Second Edition）
• ICH Q9リスクに基づいて品質を判断する、品質リスクマネジメントの考え方を示すICHのガイドライン。詳しく →(R1), Quality Risk Management
• PMDA, 医薬品医療機器総合機構 GMP・品質関連情報