1．総則
1.1 目的
１．総則 |
本ガイドラインは、旧ガイドラインである「コンピュータ使用医薬品等製造所適正管理ガイドライン」を置き換えるものである。「コンピュータ化システムが意図したとおりに動作することを保証するため」という文章が記載されているが、これはCSV の目的そのものであり、コンピュータ化システムの品質保証のゴールと言えるものである。
「意図した」とは、ユーザの要求を指す。ユーザの要求事項はあらかじめ要求仕様書で明らかにしておかなければならない。GxP業務で使用するコンピュータ化システムは、ユーザの「意図」どおりに開発、検証、運用、廃棄を行わなければならないのである。
このガイドラインにおいては、コンピュータ化システムの開発から、検証、運用管理及び廃棄までの流れを総合してコンピュータ化システムのライフサイクルという。ライフサイクル全体の構成を別紙１「コンピュータ化システムのライフサイクルモデル」に示す。 |
新ガイドラインでは、コンピュータ化システムの開発から、検証、運用管理および廃棄までをライフサイクルとして定義している。しかしながら本文は、ライフサイクルにもとずいていない。すなわち時系列にはなっていないので、注意が必要である。なお、廃棄は運用管理業務に含まれる。
また、このガイドラインに示した管理方法は標準的な例を示したものであり、これに代わる方法で、それが同等又はそれ以上の目的を達成できるものである場合には、その方法を用いても差し支えない。 |
本ガイドラインが発出される前に、CSV SOPを作成してあったような場合など、改めてSOPを作成したり、改定する必要がないよう配慮された記載となっている。当然のことながら、当該SOPは、本ガイドラインの基準を満たすものでなければならないことは言うまでもない。しかしながら、日本の査察においては、本ガイドラインをもとに実施されるので、注意が必要である。
その場合において、自社のSOPと本ガイドラインとの整合性を示すことができるように、対応表などの準備が必要となる。
Q&A 集の1．では、「それに代わる適切な方法」とは、具体的にはISPE の「GAMP ガイド」やPIC/S の「Good Practices For Computerised Systems In Regulated "GXP" Environments」等の欧米のガイドラインに基づいた方法が挙げられる。とある。
「GAMP ガイド」は、2008 年2 月に発表されたGAMP 5 が最新である。
またPIC/S ガイダンスは、2004年に発行されたものが最新であり、その内容はGAMP 4と整合している。PIC/Sガイダンスは、ヨーロッパで広く製薬業界やサプライヤが参考にしている。おそらく、日本の企業でPIC/S ガイダンスに準拠してSOP を作成しているところは少ないであろう。
PIC/Sガイダンスには、カテゴリ分類という考え方はない。またカテゴリ分類の考え方は、
GAMP 4 とGAMP 5 では異なるので注意が必要である。
1.2 コンピュータ化システムの取扱い
１．２ コンピュータ化システムの取扱い |
GQP 省令と GMP 省令では、品質保証部門の役割と責任に関して対応が異なる。「コンピュータ化システム管理規定」等を、 GQP 部門と GMP 部門にまたがって作成する際などは、十分な検討が必要となる。新ガイドラインにのっとって、新システムを導入する際には、組織・役割に応じた責任と権限をあらかじめ「コンピュータ化システム管理規定」に明らかにしておかなければならない。その場合、もし製造販売業者と製造業者で法人を分けているような場合は、さらに複雑になる。なぜならば法人が別であるため「コンピュータ化システム管理規定」は、それぞれが作成し、各品質保証部門が承認しなければならないからである。
また、このガイドラインの対象となるコンピュータ化システムは「医薬品等の承認又は許可等に係る申請等に関する電磁的記録・電子署名利用のための指針」（平成 17 年 4 月 1 日薬食発第0401022 号）及び「薬事法及び採血及び供血あつせん業取締法の一部を改正する法律の施行に伴う医薬品，医療機器等の製造管理及び品質管理（ GMP/QMS）に係る省令及び告示の制定及び改廃について」（平成 17 年 3 月 30 日薬食監麻発第 0330001 号）第 3 章第 3 35.「その他（電磁的記録等について）」の適 用を受けるコンピュータ化システムは、併せてそれら要件を備える必要がある。 |
「医薬品等の承認又は許可等に係る申請等に関する電磁的記録・電子署名利用のための指針」（いわゆる ER/ES 指針）は、平成 17 年 4 月 1 日に発出され、すでに 5 年半以上が過ぎている。しかしながら、これまで実質、臨床試験（治験）における EDC の利用に適用されてきたにすぎない。今後は、 GMP や GQP の分野でも、 ER/ES 指針を遵守しなければならないこととなった。ER/ES 指針への対応の要求が盛り込まれた訳は、 PIC/S との整合性を考慮したためと思われる。思い起こせば、米国では FDA が、 1997 年 8 月に、 21 CFR Part 11 を施行し、業界がその対応に大変苦慮したことがあった。特にコンプライアンスコストが膨大にかかってしまうといった問題点があった。日本においても同様なことが繰り返されないよう、E R/ES 指針の解釈を適切に行い、計画性を持って遵守することが望まれる。米国では、レガシーシステムであっても、 Part11 適応対象とされたために、監査証跡の機能を持たないシステムの対応に苦慮した経緯がある。しかしながら、パブリックコメントの回答 22 には、以下の記載がある。監査証跡の機能が実装されていない場合、手書きの記録等で、変更履歴、操作履歴が適切に管理されていれば差し支えありません。それらの運用をあらかじめ運用管理基準書等に規定しておくことが必要です。この記載によると、コンピュータ化システムは監査証跡機能を備えていなくても良いようにとらえられる。ガイドラインの適用を受ける製薬企業にとっては、歓迎できる回答であるが、監査証跡機能が備えられていなければ、Part 11 やANNEX11 を満たさないこととなり、欧米各国では規制要件違反となる。筆者は、この回答による考え方が、厚生労働省全体のものなのか、それとも監視指導・麻薬対策課だけの見解であるのかについて関心を持っている。すでに査察が実施されてる臨床試験における EDC システムでは、監査証跡が自動的に採取されなければならないことは、周知の事実である。
なお、このガイドラインの適用日以前に開発又は運用が開始されているシステムであって、「コンピュータ使用医薬品等製造所適正管理ガイドライン」に示された方法又はそれに代わる適切な方法で開発、検証及び運用等が行われていないシステムについては、当該システムの適格性を確認する必要がある。 |
適用日以前に稼働したシステムの適格性確認を要求している。案の段階では「回顧的なバリデーション」という記述があったが、新ガイドラインでは削除された。 パブリックコメントの回答 24 には、回顧的なバリデーションの用語については、回顧的バリデーションとの誤解を生じる恐れがあることから、この用語を使用せず、ガイドラインには適格性を確認するよう記載し評価の方法については Q&A で補足する。との記述がある。では、適格性を確認する方法とはどういうものであろうか。 Q&A 集の 2 には、以下のような記述がある。適格性を確認する方法として、当該システムの開発時の仕様書などの文書類や記録類に遡って、その適格性を検証する方法や、現在の使用目的に適合した要求仕様やそれに準じる文書との適格性を確認する方法等が考えられるが、適格性の確認にあたっては、現在の運用における記録類の照査や定期的レビューの結果を利用してもよい。なお、使用目的に適合した要求仕様やそれに準じる文書とは、例えば、当該のコンピュータ化システムに関する「標準操作手順書」や、そのコンピュータ化システムが適用される製造プロセスに関する製造指図書等が考えられる。これらの文書に基づいて適格性を検証する場合は、この両文書を合わせて要件を確認するなど、検証項目に漏れのない様な配慮も必要である。製造販売業者等は自社の品質保証に関するポリシーやリスク評価の結果等を考慮し、「コンピュータ化システム管理規定」等にその対象や実施方法、検証項目等に関する基本的な考え方を定め、それに基づき実施すること。すなわち適用日以前に稼働したシステムの適格性確認の実施方法には、以下の 3 種類があると理解する。
1) 当該システムの開発時の仕様書などの文書類や記録類に遡って、その適格性を検証する方法
2) 現在の使用目的に適合した要求仕様やそれに準じる文書との適格性を確認する方法
3) 現在の運用における記録類の照査や定期的レビューの結果を利用する方法
上記のうち、 3. が本来の「回顧的バリデーション」である。
1) は、過去に作成した仕様書等を精査する方法で、おそらく多くの問題点が見つかると思われる。
2) は、過去に作成した仕様書等はさておき、現在のコンピュータ化システムの使用方法が、ユーザの要求を満たしているものであるかどうかを検証する方法である。おそらくこの方法が最も容易であろう。
注意しなければならないことは、「適用日以前に開発又は運用が開始されているシステム」を対象としているため、本日以降に開発又は運用が開始されてるシステムも対象になることである。
1.3 カテゴリ分類
１．３ カテゴリ分類 |
本ガイドラインでは、 GAMP と同様、ソフトウェアをカテゴリ分けしている。カテゴリはすなわちソフトウェアのリスクの分類である。カテゴリの数字が大きくなるほど、ユーザによる変更の度合いが大きく、ソフトウェアに欠陥が含まれる可能性が増大する。ここで注意が必要なのは、新ガイドラインは、 GAMP 5 のカテゴリ分類と整合させており、GAMP 4 のカテゴリ分類ではないということである。もし自社の CSV SOP が GAMP 4 に従って記述されている場合、新ガイドラインとは齟齬が生じる可能性がある。「あらかじめソフトウェアカテゴリを決定するものとする」とあるが、ソフトウェアのカテゴリは、あらかじめ決定できないのが実情である。なぜならば、供給者と打合せを行い、パッケージをどのように変更するのか、すなわち構設定するのか、カスタマイズするのか、あるいは何の変更もしないのかを決定してからでないと、最終的にカテゴリは決まらない。パブリックコメントの回答 80 には、以下の記載がある。本ガイドラインの記述は時系列に並んでいるわけではなく、供給者決定前にカテゴリ分類を行なうことを求めたものではありません。「時系列に並んでいない」とのことであるが、それでは何に対して「あらかじめ」なのかが疑問である。
別紙 2 では、ソフトウェアのカテゴリ分類に応じた対応を例示している。カテゴリについては、 GAMP 5 をよく勉強しておかなければならない。「10. 用語集」には、ソフトウェアカテゴリの定義を以下のように記載している。同程度の信頼性を有するソフトウェアの属すべき範囲。ソフトウェアの性質や特徴を区分する上での基本的な分類。しかしながら、この説明ではさっぱり理解できないのではないだろうか。
2. 適用の範囲
２．適用の範囲 |
GQP 省令及び GMP 省令が適用される業務を遂行するために使用するコンピュータ化システムは、規模、形態等にかかわらず対象となる。「製造販売業者等に適用する」という表現は適用範囲としては不適切と思われる。なぜならば本
来適用範囲には、製造販売業者等が対応すべき範囲を記載するべきであるからである。(1) ～ (7) に記載されたコンピュータ化システムは、あくまでも例示であることに注意が必要である。すなわち記載されていないが、対象となるコンピュータ化システムが存在するということである。例えば、苦情管理（ CAPA）システムなどである。FDA は 2004 年頃から CAPA システムに関する査察を強化した経緯があるため、注意が必要である。筆者がパブリックコメントにおいて、苦情処理のシステムは対象とならないのかとコメントしたのに対して、回答 42 では、以下の回答が得られた。GQP 省令又は GMP 省令に関わる苦情処理の業務にコンピュータ化システムを利用するのであれば対象となります。また、パブリックコメントの回答 33 には、以下の記載がある。苦情管理、変更管理、逸脱管理、是正・予防処置管理などに使用されるシステムも適用の対象となります。ただし、適用の範囲に示したシステムはあくまで例示であり、「２．適用範囲」への追記は不要と考えます。この回答が不誠実であることは、多くの方々の感じるところであると思われる。
3. コンピュータ化システムの開発、検証及び運用管理に関する文書の作成
３．コンピュータ化システムの開発、検証及び運用管理に関する文書の作成 |
「コンピュータ化システム管理規定」は、製造販売業者等における、コンピュータ化システムの品質保証全般にかかわるポリシー文書である。新ガイドラインにしたがって、書き下ろさなければならない。
コンピュータ化システム管理規定は、原則として次の事項を記載するものとする｡ |
3.1 コンピュータ化システムの開発、検証及び運用管理に関する基本方針
システム台帳の作成については、ほかの条文中に記述はなく、その全貌および対応が把握できない。しかしながら、パブリックコメントの回答52には、以下の記載がある。本ガイドラインの管理対象のシステムを明確に示すために、原則としてこのガイドラインの対象となるコンピュータ化システムを台帳に登録する必要があります。本台帳の記載項目としてはシステム名称 ( ハード、ソフト )、管理番号、バリデーション対象の有無 ( カテゴリ分類)、システムの担当者等が考えられます。また必要に応じて、リスクアセスメントの結果（高中低）などを記載したり、複雑なシステム構成の場合は図を使用するなどの方法も考えられます。新規コンピュータ化システムについては、運用開始までにはシステム台帳に登録することが必要です。登録の時点で未定の項目があった場合は、決定後、速やかに追記する必要があります。
システム台帳は管理者を明確にするとともに、常に最新に管理された状況にしておくことが必要です。システム台帳への登録、及び承認等の事項については、あらかじめ運用管理手順書等に規定しておく等、適切な管理が求められます。
基本的な考え方については、本ガイドラインの以下の事項について、その対応方法を記載しておかなければならない。
(1) ソフトウェアのカテゴリ分類
ソフトウェアのカテゴリ分類については、別紙 2に詳細な記載がある。このカテゴリ分類は、 GAMP 5と整合しており、 GAMP ４のものとは異なるので注意が必要である。
新ガイドラインとの齟齬を避けるためには、「コンピュータ化システム管理規定」に別紙 2をそのまま引用することが望ましいと思われる。
(2) 製品品質に対するリスクアセスメント
リスクアセスメントについては、 ICH Q9を参照することは必須である。 ICH Q9は、にほんにおいても「品質リスクマネージメントに関するガイドライン」として、平成 18年9月1日に審査管理課、監視指導・麻薬対策課から発出されている。しかしながら、その理解と実践については、かなり難しいものがある。
(3) 供給者アセスメント
供給者は、コンピュータ化システムの品質の大きな担い手である。したがって、供給者を事前に調査・評価し、適切に選択することは必須である。今後は、いわゆる随意契約のような形態は避けなければならない。
(4) 開発、検証及び運用段階で実施すべき項目等
開発、検証、運用の各段階において実施すべき事項は、多岐にわたる。本ガイドラインに示されているもののみを書き写したのでは不足である。
(5) コンピュータシステムの廃棄に関する事項
GMPやGQP業務で使用したコンピュータシステムは、容易には廃棄できない。なぜならば、電子記録が保存されているからである。ここにおいて、コンピュータ化システムではなく、コンピュータシステムであることに注意が必要である。
廃棄を行う場合、捨てても良いのは、ハードウェアとソフトウェアのみである。電子記録は安心・安全・確実な場所にアーカイブしておかなければならない。また各種手順書、操作説明書、変更記録、障害記録、教育訓練記録や、 CSVにより作成した各種成果物等も一緒に保存しておくことが必要である。一般に、電子記録は新システムに移行されることが多いが、その際に監査証跡等のメタデータも同時に移行しなければならない。なぜならば監査証跡を伴わない電子記録は、その真正性が証明できなくなるからである。
3.2 開発業務、検証業務及び運用管理業務における責任体制と役割
開発、検証、運用の各段階における責任体制を明確にしておかなければならない。ここにおいて、 GMP 業務と GQP 業務にまたがって組織を構築する場合は、各品質保証部門の責任範囲について十分に検討を行っておかなければならない。
また製造販売業者と製造業者で法人が別の場合、「コンピュータ化システム管理規定」は、各法人で作成しなければならず、その組織も別々のものとしなければならない。
3.3 開発業務、検証業務及び運用管理業務で作成すべき文書及びその管理方法
一般にコンピュータ化システムを開発、検証、運用、廃棄する際には、数多くの文書を作成しなければならないことになる。本ガイドラインで示されている文書は、その一部だけであって、すべてではない。また各文書は、適切な経験とスキルを持った者が作成するべきであるし、また適切な者がレビュを行うべきである。製造販売業者等が自ら作成すべき文書と、供給者などに作成させる文書を区別しておく必要もあるだろう。
3.4 開発業務、検証業務及び運用管理業務の業務完了の確認及び承認の手続き
開発、検証、運用における各業務の官僚に関する見極めを、いつ、誰が、どのように行うべきかを記載しておかなければならない。一般に、 GMP 業務においては、品質保証部門が最終的な承認を行うこととなっているが、品質保証部門は必ずしもコンピュータ化システムの専門家ではない。したがっていわゆる「めくら判」とならないよう、当該コンピュータ化システムの担当者等が、十分なスキルと経験を持って確認作業を行っておく必要がある。
4. 開発業務
4.1 開発計画に関する文書の作成
４．開発業務 |
「開発計画書」というタイトルを見て、短絡的に「プロジェクト計画書」のことと勘違いしてはならない。
「開発計画書」は、「プロジェクトチャータ」に相当する。その根拠は 2 つある。まず「開発計画書」は製造販売業者等（すなわち経営者）が作成するものであること。また「開発計画書」の中で開発責任者を任命することとしていることである。パブリックコメントの回答 44 には以下の記載がある。開発計画書は当該企業で必要とされるコンピュータ化システムの導入の端緒であることから、製造販売業者等が作成すべき文書であり、また、開発と検証が並行して進行することから、この中で開発責任者及び検証責任者を任命することとしています。一般に「プロジェクト計画書」は、「プロジェクトチャータ」で任命されたプロジェクトマネージャが作成することになっている。
4.2 要求仕様に関する文書の作成
４．２ 要求仕様に関する文書の作成 |
「要求仕様書」は、一般には「ユーザ要求仕様書」と呼ばれている。なぜあえて「ユーザ要求仕様書」ではなく、「要求仕様書」と呼んでいるのかは疑問が残るところである。用語集では、「要求仕様書」の英語名を「 User Requirements Specification」としており、日本語との間に齟齬が生じている。パブリックコメントの回答 57 には、以下の記載がある。必要な事項が記載されていれば、文書の名称は各々の製造販売業者等で決定することで差し支えありません。
要求仕様書には原則として次の事項を記載するものとする｡ |
要求仕様書に記載すべきコンテンツの例示が行われている。ちなみに、「4.4 機能仕様に関する文書の作成 」では、コンテンツが記載されていないが、基本的には、要求仕様書と同じであると考えられる。なぜならば、「機能仕様書」は、「要求仕様書」をコンピュータ化システムの設計レベルまで詳細化したものであるからである。
4.3 システムアセスメントの実施
４．３ システムアセスメントの実施 |
本ガイドラインでは、 GAMP と同様、ソフトウェアをカテゴリ分けしている。カテゴリはすなわちソフトウェアのリスクの分類である。カテゴリの数字が大きくなるほど、ユーザによる変更の度合いが大きく、ソフトウェアに欠陥が含まれる可能性が増大する。一般に、開発業務と検証業務で作成される成果物は、システムアセスメントのなかで実施される、当該ソフトウェアのカテゴリ分類に従って決定される。一般にソフトウェアのカテゴリが 3 の場合には、作成する成果物が最も少なく、カテゴリ 5 の場合には最も多くなる。供給者アセスメントは、コンピュータ化システムを新規導入する際などに、当該供給者を選定するための調査のことを指す。一般的には、当該供給者の品質管理システム（ QMS）、品質保証体制、開発体制、従業員に対する教育訓練の程度等を調査することになる。また当該供給者の財務状況の調査も必要に応じて実施しなければならない。一般的にはこれらの調査をサプライヤオーディット（供給者監査）と呼んでいるが、パブリックコメントの回答 89 には、以下の記載がある。本ガイドラインにおける供給者アセスメントは、適切な供給者を選定するために必要な開発業務の一部ですが、供給者監査は選定された供給者が適切な業務を行っているかを監査する検証業務の一部です。したがって、供給者アセスメントと供給者監査は別個の概念であり、過去の供給者監査の結果を以降の供給者アセスメントに活用することはできますが、それは監査をアセスメントの手段とすることではありません。つまり供給者監査は、選定し契約した供給者に対して実施するものを指すということであり、供給者アセスメントとは異なるものである。このことは我々の一般的な理解と異なるので、注意が必要である。
4.4 機能仕様に関する文書の作成
４．４ 機能仕様に関する文書の作成 |
機能仕様書は、要求仕様書に記載した要件を、コンピュータ化システム設計に対する要求事項として十分なレベルまで定義するものである。ソフトウェアのカテゴリが 4 または 5 の場合に作成する。すなわち通常カテゴリ 3 では、機能仕様書は作成しない。機能仕様書は、承認されたユーザ要求仕様書をもとに作成しなければならない。機能仕様書は、供給者側で作成したものを、製薬会社側で承認しなければならない。ここで注意が必要なのは、作成というのは、供給者内で作成・レビュ・承認が行われるということである。供給者内で承認が行われた機能仕様書は、製薬企業に納品される。製薬会社側では、納品された機能仕様書をレビュし、コメントを付け、修正や疑義事項等があれば、供給者に差し戻さなければならない。供給者側では、製薬会社のコメントや指示に従って、加筆・修正を検討し、妥当な変更を行って再度製薬会社に納品することになる。このようなレビュプロセスを経て、機能仕様書は最終的に開発責任者が承認することになる。
その際に、供給者側のサインページの上に、製薬会社側のサインページをのせて、サインを行うこととなるのである。
くれぐれも、製薬会社側で形式的にサインを入れるといった、いわゆる「めくら判」にならないようにしなければならない。本ガイドラインでは、要求仕様書や設計仕様書と違い、機能仕様書のコンテンツが定義されていない。筆者がパブリックコメントにおいて、機能仕様に関するコンテンツの記載がなく、要求仕様、設計仕様、他と不整合であるとコメントしたのに対して、パブリックコメントの回答 91 では、以下の回答が記述された。機能仕様書の内容はシステムの機能と性能に関して、システムの内容に応じて必要な事項を決定すべきであると考えます。これでは、回答 1 にある「できるだけ具体的な求め方を記載している」という理念と相反することになる。
機能仕様書執筆時に、要求仕様書と機能仕様書間のトレーサビリティマトリックスを作成しておくことも大切である。
トレーサビリティマトリックスによって、ユーザの要求事項がもれなく機能仕様書において定義されたことが保証されるのである。またトレーサビリティマトリックスは、設計時適格性評価（DQ）の際にも用いられる。しかしながら、本ガイドラインには、トレーサビリティマトリックスに関する記載はない。機能仕様書において構成設定（コンフィギュレーション）により要求機能を実現すると決定した機能に関しては、別途構成設定仕様書にその設定値を記載することになる。すなわちソフトウェアのカテゴリが 4 の場合には、機能仕様書に加えて、構成設定仕様書を作成することになるのである。しかしながら、本ガイドラインには、構成設定仕様書に関する記載はない。
4.5 設計仕様に関する文書の作成
４．５ 設計仕様に関する文書の作成 |
設計仕様書は、機能仕様書と同様、供給者が作成し、製薬企業側で承認を行う。ここで注意が必要なことは、開発責任者による設計仕様書の承認前に、検証責任者は検証業務で定義されている設計時適格性評価（DQ）を実施しなければならないということである。
設計仕様書には、原則として次の事項を記載するものとする。 |
ハードウェアに関する設計仕様書は、ソフトウェアのカテゴリに関係なく、必要となる。また、IQ では、このハードウェア設計仕様に基づいて、ハードウェアを据え付けなければならない。
|
ソフトウェアの設計仕様書は、カテゴリが5 の場合に作成する。また、IQ では、このソフトウェア設計仕様に基づいて、ソフトウェアをインストールしなけなければならない。
4.6 プログラムの作成及びプログラムテスト
４．６ プログラムの作成及びプログラムテスト |
ソフトウェアのカテゴリが5 に場合、供給者は設計仕様書に基づいてプログラム仕様書を作成することになる。
またプログラムは、プログラム仕様書に基づいて作成する。作成されたプログラムをテストするために、プログラムテスト計画書を作成しなければならない。プログラムテスト計画書に基づいてプログラムテストを実施した際に、プログラムテスト結果を文書化し、最終的にプログラムテスト報告書にその内容が要約されることになる。プログラム仕様書の作成からプログラムテストに至るプロセスは、通常供給者側で実施され、その際の成果物は製薬会社に納品されないことが一般的である。したがって、製薬会社では、検証業務の一環として、供給者監査を実施し、プログラム仕様書、プログラム、プログラムテスト計画書およびプログラムテスト結果、プログラムテスト報告書等を調査しなければならない。
4.7 システムテスト
４．７ システムテスト |
システムテストは、ソフトウェアのカテゴリが4 または5 の場合に実施する。カテゴリ4 の場合は、構成設定されたソフトウェアに対して、機能仕様書に記載されたとおり、機能するか、また期待されたとおりの応答性があるかについて、システムテストを実施する。カテゴリ5 の場合は、プログラミングされたソフトウェアに対して、機能仕様書および設計仕様書に記載されたとおり、機能するか、また期待されたとおりの応答性があるかについて、システムテストを実施する。
システムテスト計画書の作成からシステムテスト報告書の作成過程についても、供給者側で実施されるため、供給者監査を実施する必要がある。
4.8 受入試験
４．８ 受入試験 |
本条文中には、「原則として」や「必要に応じて」という文言は見当たらない。つまり受入試験は必須事項のように読み取れる。しかしである。FATやSATは、自動化装置とプロセス制御システムに特異なテストであると認識している。したがってITシステムや分析装置などのコンピュータ化システムにおいては、ほとんどの場合、FATやSATは実施されていない。というよりも認知度が高くない。GAMPにおいても、GAMP 5からは、プロセスエンジニアリング（GEP）は、GAMP実践規範ガイド：プロセス制御システムのバリデーション（付属資料G3）として別冊となった。工場出荷試験（FAT）は、出荷前にユーザの要求を満たす機能が実装され、性能が発揮できるのかをあらかじめ確認することが目的である。いわば、出荷判定テストである。その目的は、製薬企業に設置されたのち、調整や修正が必要となった場合に、再度供給者の工場に戻すことがないようにするためである。一方、現地受入試験（SAT）では、実際の製薬企業の工場等において、電子天秤や自動倉庫などの装置や設備との接続を行い、実際に動作させることによって、その機能や性能を確認することが目的である。FAT、SATには通常、製薬企業の担当者が立ち会うことになる。開発責任者がFAT、SATの結果を承認すること。
5. 検証業務
5.1 バリデーションの全体計画に関する文書の作成
５． 検証業務 |
検証業務の全体計画として、「バリデーション計画書」を作成しなければならない。4.1 において、「開発計画に関する文書の作成」とあるので、5.1 では「検証計画に関する文書の作成」とするのが正しかったのではないだろうか。
また、開発業務では、成果物を承認することとなっているが、検証業務では作成することとなっている。ここにおいて、作成は承認を伴うものであると解釈しなければならない。「バリデーション計画書は開発段階の適切な時期に作成する」とあるように、通常バリデーション活動は、後付で実施できない。したがって、バリデーション計画書は、要求仕様書とリスクアセスメント報告書が作成された後に、遅滞なく作成しなければならない。すなわち、バリデーション計画書は、要求仕様書に対して実施したシステムアセスメントの結果を考慮して、妥当なレベルで作成すること。つまり、当該コンピュータ化システムの重要性、複雑性、規模、新規性などに応じて、適切なレベルでバリデーション（検証）にかかわる活動を定義するのである。一般に、システムアセスメントの結果によって、バリデーションにかかわる組織の大きさ（人数）、要員に必要とされるスキルと経験、作成する成果物の種類等が変化する。「4.3 システムアセスメント」と記載されているが、「4.3 システムアセスメントの実施」が正しい。
また、「6.6 変更の管理」においてバリデーションが必要となった場合は、変更の状況にあわ |
「また、「6.6 変更の管理」においてバリデーションが必要となった場合は、変更の状況にあわせて適宜バリデーション計画書を作成すること。」という記載があるが、変更管理は運用管理業務で実施されるため、検証業務に記載されていることは、紛らわしい。詳細なリスクアセスメントとは、初期リスクアセスメントが要求仕様書にそって実施されるに対して、作成される当該ソフトウェアの機能毎にそのリスクを評価するといったものである。一般に機能リスク評価（Functional Risk Assessment）と呼ばれる。バリデーション計画書において、機能リスク評価をいつ、どのように、だれが実施するのかを明らかにしておくこと。また、必要に応じて、バリデーション計画書において、供給者監査の計画についても記載しておかなければならない。供給者監査は、当該ソフトウェアのカテゴリが4 または5 の場合に実施することになる。特にカテゴリ5 の場合は、より厳密な供給者監査を実施しなければならない。すなわち、カテゴリ5 の場合、供給者がプログラムの作成やテスト、システムテストを実施するが、製薬会社にはそれらの記録等が納品されないため、実際に供給者を訪問し監査しなければならないのである。さらに、検証中における変更管理や障害管理などについても記載が必要である。
5.2 設計時適格性評価（ＤＱ）
５．２ 設計時適格性評価（ＤＱ） |
ソフトウェアのカテゴリが 5 の場合、DQ（Design Qualification：設計時適格性確認）の実施が必須である。DQ とは、設計がユーザの要求を満たしていることを、製造に前もって検証しておくことである。DQ の実施にあたっては、当該システムに関する深い知識と経験が必要となるため、当該サプライヤが実施することとなる。製薬企業側では、その DQ が適切に行われたかどうかを確認しておく必要がある。特にトレーサビリティマトリックスの作成が行われており、ユーザ要求仕様書で要求された機能が、もれなく設計仕様書に反映されていることを確認しておくこと。
5.2.1 設計時適格性評価の計画に関する文書の作成検証責任者は、設計時適格性評価の計画に関する文書（以下「設計時適格性評価計画書」という。）を作成ものとする。設計時適格性評価計画書には、原則として次の事項を記載するものとする｡ |
検証責任者は、供給者または検証担当者などの適切な者に「設計時適格性評価計画書」（DQ 計画書）を作成させた後に、その内容を確認し、承認しなければならない。「作成ものとする」と記載されているが「作成するものとする」が正しい。
5.2.2 設計時適格性評価の実施 |
開発業務には開発担当者という役割は定義されていないが、検証業務では、検証担当者が登場する。ここにおいて検証担当者は、製薬企業の従業員であると思われる。しかしながら、一般にDQ の実施は、製薬企業では困難である。なぜならば、設計仕様書が読め、理解でき、問題点等を指摘するためには、相応の知識と経験が必要だからである。パブリックコメントの回答155 には、以下の記載がある。製造販売業者等が自身でＤＱの実施が困難な場合、製造販売業者等の責任において、供給者の協力を得て実施することも可能です。製薬企業のSOP には、DQ の実施は供給者の協力を得る旨の記載が必要であると思われる。
5.2.3 設計時適格性評価の報告に関する文書の作成検証責任者は、設計時適格性評価の報告に関する文書（以下「設計時適格性評価報告書」という。）を作成するものとする。設計時適格性評価報告書には、原則として次の事項を記載するものとする｡ |
検証責任者は、DQを実施した者に「設計時適格性評価報告書」（DQ報告書）を作成させた後に、その内容を確認し、承認しなければならない。
5.3 据付時適格性評価（IQ）
５．３ 据付時適格性評価（ IQ） |
プログラムをインストールするとの記載があるが、ソフトウェアの間違いであると思われる。なぜならば5.3.1 (7)と矛盾するからである。
|
検証責任者は、供給者または検証担当者などの適切な者に「据付時適格性評価計画書」（IQ 計画書）を作成させた後に、その内容を確認し、承認しなければならない。
5.3.2 据付時適格性評価の実施 |
IQもDQ同様、製薬会社側で実施することは困難である。適切に供給者の協力を得て、実施しなければならない。
5.3.3 据付時適格性評価の報告に関する文書の作成 |
検証責任者は、IQを実施した者に「据付時適格性評価報告書」（IQ報告書）を作成させた後に、その内容を確認し、承認しなければならない。
5.4 運転時適格性評価（OQ）
５．４ 運転時適格性評価（ OQ） |
一般にOQ は、当該コンピュータ化システムに、機能仕様書に記載されたとおりに全機能が実装されており、問題なく運転できる（つまり不具合やバグ等がない）ことを確認するために実施する。
5.4.1 運転時適格性評価の計画に関する文書の作成 |
検証責任者は、検証担当者などの適切な者に「運転時適格性評価計画書」（OQ 計画書）を作成させた後に、その内容を確認し、承認しなければならない。
|
OQ の実施にあたっては、OQ スクリプトの作成が必要となる。OQ スクリプトは、当該供給者に作成させることが望ましい。なぜならば、製薬会社にとって、初めて操作するシステムに関するテストの内容を適切かつ網羅的に作成することは困難であるからである。OQ スクリプトを用いて、OQ を実施した記録を記載したものが、OQ ログであり、OQ の記録となる。
|
検証責任者は、OQ を実施した者に「運転時適格性評価報告書」（OQ 報告書）を作成させた後に、その内容を確認し、承認しなければならない。
5.5 性能適格性評価（PQ）
５．５ 性能適格性評価（ PQ） |
一般にPQ は、当該コンピュータ化システムが、要求仕様書に記載されたとおりの性能を発揮して稼働できることを確認するために実施する。「運転」と「稼働」の違いは、以下の通りと理解する。「運転」とは、当該コンピュータ化システムを単独で動作させることであり、「稼働」とは、実際にライン等に組み込んで動作させることである。したがって、「運転」は、空で運転し、「稼働」は、実際に生産させてみることに相当する。「運転できることを確認」とあるが、「稼働できることを確認」が正しいと思われる。
5.5.1 性能適格性評価の計画に関する文書の作成 |
PQ の実施にあたっては、PQ スクリプトの作成が必要となる。PQ スクリプトについても、当該供給者に作成させることが望ましい。PQ スクリプトを用いて、PQ を実施した記録を記載したものが、PQ ログであり、PQ の記録となる。
5.5.3 性能適格性評価の報告に関する文書の作成 |
検証責任者は、PQ を実施した者に「性能適格性評価報告書」（PQ 報告書）を作成させた後に、その内容を確認し、承認しなければならない。
5.6 適格性評価の一部省略と引用
５．６ 適格性評価の一部省略と引用 |
ここでは、適格性評価を簡略化できる条件が記載されている。(1) では、OQ とPQ の間で、検証内容、環境、条件などに違いがなければ、OQ を省略できるとある。しかしながら、長年CSV に携わってきた筆者にとって、OQ とPQ が一致する場合の想像ができない。いったいどういう場合であろうか。(2) では、供給者が実施した、工場出荷試験（FAT）や現地受入試験（SAT）に関して、検証責任者が適切と認めたならば、適格性評価時、すなわちOQ やPQ の実施時において、その結果を引用できるとある。すなわち、OQ やPQ を簡略化できる条件と方法を示しているのである。しかしながら、本来、適格性検証は、供給者が実施した作業について、製薬企業側で再度検証することが目的であるはずである。
供給者の実施したテスト結果を引用する際には、適切かつ妥当なレベルにとどめる必要があると思われる。
5.7 バリデーションの全体報告に関する文書の作成
５．７ バリデーションの全体報告に関する文書の作成 |
一般に、バリデーションの全体報告に関する文書のことを、「バリデーション報告書」と呼ぶ。検証業務の総括、すなわち、DQ、IQ、OQ、PQ のサマリーを、「バリデーション報告書」にまとめることになる。「バリデーション報告書」は、検証担当者等の適切な者に作成させ、検証責任者が承認すること。筆者が、パブリックコメントにおいて、「引き渡しというアクティビティを定義するべきと考えます。GAMP でも述べている通り、引き渡し作業は、労力がかかり、また品質保証にも大きく影響します。運用時に必要な文書は、開発段階で作成（運用になってから作成したのでは遅い）し、
引き渡しにおいて移管すべきと考えます。」とコメントしたのに対し、回答124 では、以下のよう
に記載されている。検証の完了（バリデーションの全体報告）が「引き渡し」に相当することから、あえて別途
設定する必要はないと考えます。すなわち、引き渡しをバリデーション計画書で総括することととらえられる記述であるが、おかしい。引き渡しは開発業務で実施されるべき事項であるが、本ガイドラインにおけるバリデーションの
定義は検証のことであって、バリデーション報告書では検証業務を総括することになる。つまり、バリデーション報告書は、検証責任者が作成するものであり、DQ、IQ、OQ、PQ を総括するものであって、引き渡し業務とは関係しない。
開発業務において、「開発報告書」の定義がないため、上記のような回答となったものと考えられる。ここでも、パブリックコメントの回答による混乱がみられる。
6. 運用管理業務
6.1 運用管理に関する文書の作成
６． 運用管理業務 |
案では、「運用管理手順書」であったものが、「運用管理基準書」に変更となった。「運用管理基準書」は、企業または組織で1つ作成するものであって、コンピュータ化システム毎に作成するものではない。しかしながら、そのコンテンツを見ていると、システム毎に記述しなければならないものもあり、考慮が必要である。しかしながら変更の管理、逸脱（システムトラブル）の管理、教育訓練は、GQP省令、GMP省令における手順に従って運用することが望ましいため、「運用管理基準書」に基づくこととされている。
6.2 コンピュータ化システムの操作の手順に関する文書の作成
６．２ コンピュータ化システムの操作の手順に関する文書の作成 |
「標準操作手順書」は、一般にSOP とも呼ばれ、コンピュータ化システム毎に作成しなければならない。
6.3 保守点検事項の実施
６．３ 保守点検事項の実施 |
タイトルの「保守点検事項の実施」は、多少違和感がある。「保守点検の実施」が適切ではないであろうか。
この章以降では、「運用基準書」と「運用基準書等」という用語を明確に使い分けているので注意が必要である。「運用基準書等」は、運用基準書と標準操作手順書を合わせたものである。ここでは、「運用管理基準書」とは別に、コンピュータ化システム毎に、「保守点検の手順書」を作成しなければならないのである。
6.4 セキュリティ管理の実施
６．４ セキュリティ管理の実施 |
タイトルの「保守点検事項の実施」は、多少違和感がある。「保守点検の実施」が適切ではないであろうか。この章以降では、「運用基準書」と「運用基準書等」という用語を明確に使い分けているので注意が必要である。「運用基準書等」は、運用基準書と標準操作手順書を合わせたものである。ここでは、「運用管理基準書」とは別に、コンピュータ化システム毎に、「保守点検の手順書」を作成しなければならないのである。
6.5 変更の管理
1.1 バックアップ及びリストア |
「運用基準書等」と記載されていることに注意が必要である。すなわち、「運用管理基準書」とは別に、「バックアップ/ リストアの手順書」を作成しなければならないのである。なお、「バックアップ/ リストアの手順書」にしたがって、リストアが適切かつ確実に実施できることを検証しておくことが必要である。すなわち、「バックアップ/ リストアの手順書」の適格性を確認しておくこと。リストア作業について、適切な検証が行われていない場合は、要事にデータの復旧ができない可能性もあり、問題である。
6.6 変更の管理
６．６ 変更の管理 |
ここにおいて、「運用管理基準書」であり、「運用管理基準書等」ではないことに注意が必要である。
すなわち、変更管理においては、別途手順書を作成してはならないという趣旨である。特にGMP 省令に係るシステムの場合には、GMP 省令における変更の管理の手順に従わなければならず、コンピュータ化システムに特化した「変更管理手順書」を別途作成してはならないことを意図しているように読める。その場合、GMP 省令における変更の管理の手順に上記（1）から（4）の内容を追記しなければならない。しかしである。GMP 省令における変更の管理の手順を、コンピュータ化システムの変更管理にも利用できるように加筆・修正することに筆者は反対である。コンピュータ化システムの変更管理に関しては、その対象物がシステム毎に異なることや、当該供給者を交えなければならないことなどから、システム毎に作成しなければならないためである。一般に、コンピュータ化システムの変更管理は、特に断りがない場合は、運用段階における変更を指す。すなわち、バリデートされ運用に入ったシステムを変更することであり、開発段階における変更を指すものではない。バリデートされたシステムを変更することは、リスクを伴い、適切かつ慎重に管理しなければならない。また、当該システムの変更に伴い、再度バリデーションが必要となることがあるが、その場合においても「バリデーション計画書」の作成が必要である。
6.7 逸脱（システムトラブル）の管理
６．7 逸脱（システムトラブル）の管理 |
本ガイドラインでは、システムトラブルを逸脱としてるが、違和感を感じる。一般に、システムトラブルは、障害と呼び、逸脱ではない。ここにおいても、「運用管理基準書」であり、「運用管理基準書等」ではないことに注意が必要である。ただし、逸脱管理においては、「GMP 省令における逸脱の管理の手順に従って運用することでよい」とあり、変更管理のそれに比べて、柔軟な記載となっている。ただし、GMP 省令における逸脱の管理の手順に従って運用する場合、その手順に上記（1）から（3）の内容を追記しなければならない。
6.7 教育訓練
６．8 教育訓練 |
適切な時期に教育訓練が実施できるよう、「教育訓練計画書」を作成しておかなければならない。ここにおいて、「教育」と「訓練」は、内容、目的、方法が異なるので、注意が必要である。「教育」は、英語ではEducation であり、すべての受講者が同じカリキュラム、すなわち同じテキストで学習することをいう。それに対し、訓練は、担当者の役割、責任、担当業務に応じて、実際に当該コンピュータ化システムを操作しながら学習することを指す。
6.8.2 教育訓練の実施 |
教育訓練の実施に当たっては、責任者を決め、その記録を作成しておくことが必要である。
6.8.3 教育訓練の記録の保管 |
教育訓練の記録は、適切に保管し、社内監査や当局の査察時等に、要求に応じて速やかに提示できるようになっていなければならない。
7. 自己点検
7.1 自己点検の実施
７． 自己点検 |
ここにおいて、自己点検は、定期監査のことではないことに注意すること。自己点検は、QC 業務の一環である。
7.2 改善措置の実施
７．２ 改善措置の実施 |
自己点検の結果に伴い、改善が必要な場合には所要の措置を講じる必要がある。これは、いわゆるCAPA（Corrective Actions; Preventive Actions：是正措置、改善措置）の実施である。
8. コンピュータシステムの廃棄
8.1 コンピュータシステムの廃棄の計画に関する文書の作成
８．コンピュータシステムの廃棄 |
コンピュータシステムを廃棄する際においても、品質保証を行うことが肝要である。すなわち、計画書を作成し、計画のとおり実施し、記録し、報告書を作成しなければならない。ここにおいて、「コンピュータシステムの廃棄」であって、「コンピュータ化システムの廃棄」でないことに注意が必要である。当該コンピュータ化システムがその役目を終え、利用を中止する際に、廃棄しても良いものは、ハードウェアとソフトウェアのみである。つまり、電子記録、標準操作手順書（SOP）、変更の記録、障害の記録、バリデーションの記録等は、絶対に廃棄してはならない。
これらは、安心・安全・確実にアーカイブしておかなければならず、社内の監査や規制当局の査察時等に、要求に応じて速やかに提示できなければならない。特に、電子記録に関しては、監査証跡や電子署名の情報などの、いわゆるメタデータを共に保存しておく必要がある。さもなくば、電子記録の真正性が失われるからである。コンピュータシステムの廃棄に当たっては、当該システムを構築した供給者と相談し、どのように電子記録を新システムに移行するのか、あるいは別途アーカイブしておくのかを検討しておかなければならない。すなわち、新規システムの導入プロジェクトは、旧システムの廃棄プロジェクトからはじまるということである。「カテゴリ等」に応じて廃棄する旨の記述があるが、一般に廃棄にはカテゴリは影響しない。廃棄計画書の最後に、廃棄完了の判断基準を記載することとなってるが、廃棄に関してのみ完了の判断基準が記載されていることに違和感を覚える。同様に開発業務、検証業務についても、完了の判断基準が必要ではないだろうか。
8.2 コンピュータシステムの廃棄記録の作成
８．２ コンピュータシステムの廃棄記録の作成 |
廃棄の責任者は、廃棄計画書にしたがって、廃棄業務を行い、その記録を保管しなければならない。
9. 文書及び記録の管理
９． 文書及び記録の管理 |
「保存管理」という表現は、「保管」とどう違うのであろうか。GQP 省令及びGMP 省令にまたがるシステムの場合は、どちらの省令にしたがって管理するのかをあらかじめ決めておかなければならない。しかしながら、製造販売業者と製造業者で法人が異なる（すなわち親会社と子会社）場合、注意が必要である。なぜならば、法人が違うのであれば、文書や記録は、各法人がもっていなければならず、またそれぞれの品質保証部門が承認を行っていなければならない。
すなわち、1 つのコンピュータ化システムであっても、文書や記録を2 部作成し、各々が保管しなければならないことになる。また、外資系企業の場合、海外の本社で作成されたコンピュータ化システムの文書や記録は、多くの場合、英語等で記述されているが、日本法人で適切に邦訳し、保管しておくことも必要となるかもしれない。
