抗体医薬基礎知識・規制

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

新しいシステムを導入するたびに、「このシステムのCSV品質に関わるコンピュータ化システムが意図どおり正確・一貫して機能することを、文書化された証拠で示す活動。はどこまでやればいいのか」という問いが繰り返されます。培養槽の温度制御も、試験結果の記録も、ロット出荷の判断材料の取りまとめも、今日の製造現場では多くがコンピュータ化されたシステムに委ねられています。紙の記録簿だけで工程が回っていた時代とは、記録が生まれる場所が根本から変わりました。

LIMSSCADA/MES#バリデーション#GMP#データインテグリティ#電子記録
選び方ガイド製造・試験のITシステムの選び方——候補カテゴリ・選ぶ理由・メーカーと製品
CSV(コンピュータ化システムバリデーション)とは?GAMP 5の考え方

そこで問われるのが、「そのシステムは、意図したとおりに、正しく動いているといえるか」です。装置や工程にバリデーション(妥当性確認)が求められるのと同じように、品質に関わるコンピュータ化システムにも、それが期待どおり機能することを証明する仕組みが要る。これがコンピュータ化システムバリデーション品質に関わるコンピュータ化システムが意図どおり正確・一貫して機能することを、文書化された証拠で示す活動。(CSV, Computerized System Validation)です。

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

この記事の要点
  • CSVは、品質に関わるコンピュータ化システムが意図どおり正確・一貫して機能することを、文書化された証拠で示す活動です。
  • GAMP 5のソフトウェアカテゴリとVモデルで検証の重さと範囲を定め、リスクベースのCSAで労力を配分します。
  • 21 CFR Part 11/Annex 11に沿って電子記録を守り、データインテグリティの確保をライフサイクルで維持します。

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

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

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

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

GAMP 5:業界の共通言語

CSVの進め方には、単一の法的な正解があるわけではありません。各極の規制(FDA、EU GMP欧州の医薬品製造・品質管理の基準。第1章の品質システムのなかでPQRの実施を求めている。など)は「妥当性を確認せよ」とは求めても、手順の細部までは規定しない。そこで実務の拠り所として広く使われているのが、ISPE(国際製薬技術協会)が発行するGAMP 5GxP対応のコンピュータ化システムを検証する進め方を示す、ISPE発行の業界標準ガイド。というガイドです。2022年に第2版が公表され、リスクベースの考え方やソフトウェアアシュアランスの発想をより明確にしています。

GAMP 5の中核の一つが、ソフトウェアを性質で分類し、必要な検証の重さを変えるという発想です。市販のありもの(COTS, 商用オフザシェルフ製品そのまま使う市販の商用ソフトウェア製品。供給者の実績に頼れるぶん自社で検証する範囲が狭まる。)をそのまま使うのか、設定でカスタマイズするのか、独自に開発するのか——由来によってリスクの出方が違うため、同じ労力をかけるのは合理的ではない、という整理です。実務では次の4区分が使われます(かつてのカテゴリ2(ファームウェア)は現行のGAMP 5では独立区分として用いられません)。

カテゴリ性質例(一般的な整理)検証の重み
1インフラ・基盤ソフトOS、データベース基盤、ネットワーク設定管理が中心
3設定しない市販品単純な計測機器のファーム、汎用パッケージ意図した用途での機能確認
4設定する市販品LIMS・MES・ERP等を設定して使う場合設定内容に対するIQ/OQ/PQ
5カスタム開発独自スクリプト、自社開発アプリ開発ライフサイクル全体の検証

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

POINT

GAMP 5のソフトウェアカテゴリは「どれだけ手をかけるか」の当たりをつけるための道具です。市販品をそのまま使うほど供給者の実績に頼れる一方、独自開発に近づくほど自分たちで検証する範囲が広がります。分類はゴールではなく、リスク評価の入口。そう捉えるのが安全です。

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

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

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

左側(要求・設計)右側(検証)何を確かめるか
ユーザ要求仕様そのシステムに何をさせたいかを定義する文書。Vモデルで検証項目をひもづける起点になる。URSそのシステムに何をさせたいかを定義する文書。Vモデルで検証項目をひもづける起点になる。性能適格性評価製造装置やユーティリティが意図どおりに据え付けられ、動き、性能を出せることを文書で裏づける活動。(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の狙いは検証を減らすこと自体ではなく、証跡づくりに割いていた労力を、本当にリスクの高いところへ振り向け直すことにあります。

POINT

CSVとCSAは対立する概念ではありません。CSAは「同じ密度で全部テストする」運用を見直し、患者安全・製品品質への影響が大きい機能に検証を集中させるためのリスクベースの整理です。文書の量ではなく、リスクの高い箇所での確からしさを増やすのが本来の目的です。

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

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

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

CSVはこれらの要件を「満たしていることを示す」手段でもあります。監査証跡が無効化できない設定になっているか、共有IDが使えない権限設計になっているか、バックアップと長期可読性が確保されているか——こうした点はCSVのテスト項目としてURSに落とし込まれ、OQ/PQで確認されます。 Part 11 / Annex 11コンピュータ化システムに関するEU GMPの付属書。監査証跡の定期的なレビューなどを求める。 は「何を守るべきか」を規定し、CSVは「それが実際に守られていること」を検証で裏づける、という補完関係にあります。

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

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

たとえば「誰が操作したか特定できる(帰属性)」を担保するには共有IDを禁じるアクセス設計が要り、「失敗データも含めてすべて残る(完全性)」を担保するには削除できない監査証跡いつ誰が何をしたかを記録し、改ざんや削除ができないようにした操作履歴。記録の信頼性を支える。が要る。これらはいずれもCSVでURSに書き込み、検証で確認する対象です。 CSVはデータインテグリティを実現するための工学的な裏づけであり、両者は「求める姿(ALCOA+)」と「それを作り込む手段(CSV)」として一体で捉えるのが実務的です。

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

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

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

まとめ

CSVは、品質に関わるコンピュータ化システムが「意図した用途どおりに、正確・一貫して機能する」ことを文書化された証拠で示す活動です。その進め方の共通言語がISPEのGAMP 5であり、ソフトウェアカテゴリで検証の重さの当たりをつけ、Vモデルで要求と検証を一対一に対応づけます。近年はFDAが後押しするCSA(Computer Software Assurance)の考え方が広がり、労力を患者安全・製品品質への影響が大きい箇所へ集中させるリスクベースの配分が重視されています。システムが生む電子記録は 21 CFR Part 11 / EU GMP Annex 11 に沿って守り、その要件が実際に満たされていることをCSVが検証で裏づけます。最終的に目指すのは データインテグリティ の確保であり、CSVは ALCOA+ が求める記録の信頼性をシステムに作り込むための工学的な手段です。そしてバリデーションは導入時で完結せず、変更管理を伴ってライフサイクル全体で維持されて初めて意味を持ちます。

参考文献

Newsletter

この分野の新着を、メールで受け取る

こうした製造・分析・品質の解説記事と、装置・試薬の新製品ニュースを月数回お届けします。登録は無料で、いつでも解除できます。

登録によりプライバシーポリシーに同意したものとみなします。

次に読む

目次・関連閉じる
編集メモ:この記事はProglenth編集部が、抗体医薬に関する基礎的な情報を、はじめての方にも分かるように整理したものです。実際の製造方法・管理戦略・品質基準は、製品や企業、各国の規制によって異なります。本記事は一般的な解説であり、特定製品の推奨や規制・医療上の助言ではありません。実務で判断される際は、各極の薬局方・ガイドライン(ICH/GMP等)やメーカーの一次情報を必ずご確認ください。内容に誤りやご指摘があればお問い合わせからお知らせください。