抗体医薬基礎知識・規制

コンピュータ化システムバリデーション（CSV・GAMP 5・Annex 11）とは？

Proglenth 編集部2026-07-06約9分で読めます

医薬品の製造現場は、いまやソフトウェアの上で動いています。培養槽の温度を制御するのも、試験結果を記録するのも、ロットの出荷可否を判断する材料をまとめるのも、多くはコンピュータ化されたシステムです。紙の記録簿だけで工程が回っていた時代とは、記録が生まれる場所が変わりました。

小型バイオリアクター LIMS#バリデーション#GMP#データインテグリティ#電子記録

コンピュータ化システムバリデーション（CSV・GAMP 5・Annex 11）とは？

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

本記事では、CSVの基本的な考え方を出発点に、実務の共通言語となっているGAMP 5のソフトウェア分類とVモデル、近年FDAが後押しするリスクベースの手法（CSA）、そして電子記録・電子署名を規定する21 CFR Part 11とEU GMP Annex 11、さらにデータインテグリティとの関係までを、専門外の方にも読める密度で整理します。

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

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

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

対象になるかどうかの目安は、「そのシステムが扱うデータや判断が、製品品質・患者安全・規制上の記録に関わるか（GxPに影響するか）」です。給与計算システムは規制対象外ですが、試験結果を保存するLIMS（試験室情報管理システム）や、製造記録を電子化するMES（製造実行システム）は対象になります。すべてを同じ厳しさで扱うのではなく、影響の大きさに応じて力の入れどころを変える——この発想が、後述するリスクベースの考え方につながります。

GAMP 5：業界の共通言語

CSVの進め方には、単一の法的な正解があるわけではありません。各極の規制（FDA、EU GMPなど）は「妥当性を確認せよ」とは求めても、手順の細部までは規定しません。そこで実務の拠り所として広く使われているのが、ISPE（国際製薬技術協会）が発行するGAMP 5というガイドです。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モデルと呼ばれるライフサイクルです。左側を下りながら要求を段階的に詳細化し、右側を上りながらそれぞれの要求に対応する検証を積み上げていく——このV字の形が名前の由来です。

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

左側（要求・設計）	右側（検証）	何を確かめるか
ユーザ要求仕様（URS）	性能適格性評価（PQ）	実運用条件で意図した用途を満たすか
機能仕様（FS）	運転時適格性評価（OQ）	各機能が仕様どおり動くか
設計仕様（DS）	据付時適格性評価（IQ）	正しく設置・構成されているか

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

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

Vモデルは強力ですが、運用を誤ると「とにかく大量のテスト文書を作る」作業に陥りがちでした。すべての機能を同じ密度でスクリプト化し、証跡のためのスクリーンショットを延々と貼る——本来の目的である品質・患者安全への寄与よりも、文書量が目的化してしまう、という反省です。

これに対してFDAが後押ししているのが、CSA（Computer Software Assurance, コンピュータソフトウェアアシュアランス）という考え方です。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（電子記録・電子署名に関する規則）であり、EUでは EU GMP Annex 11（コンピュータ化システム）が対応する位置づけになります。

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

CSVはこれらの要件を「満たしていることを示す」手段でもあります。監査証跡が無効化できない設定になっているか、共有IDが使えない権限設計になっているか、バックアップと長期可読性が確保されているか——こうした点はCSVのテスト項目としてURSに落とし込まれ、OQ/PQで確認されます。 Part 11 / Annex 11 は「何を守るべきか」を規定し、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+ が求める記録の信頼性をシステムに作り込むための工学的な手段です。そしてバリデーションは導入時で完結せず、変更管理を伴ってライフサイクル全体で維持されて初めて意味を持ちます。

参考文献

目次・関連閉じる