厚労省コンピュータ化システム適正管理ガイドラインの考察（2010.10執筆）

ウェブセミナー

厚労省「コンピュータ化システム適正管理ガイドライン」について研究するページです。

＊万が一文中に解釈の間違い等がありましても、当社では責任をとりかねます。
　本文書の改訂は予告なく行われることがあります。

医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン

1．総則

1.1 目的

１．総則 １．１　目的 このガイドラインは、「コンピュータ使用医薬品等製造所適正管理ガイドライン」（平成４年 ２月２１日薬監第11 号：平成17 年3 月30 日付薬食監麻発第0330001 号により廃止）に代わる ものとして、「医薬品及び医薬部外品の製造管理及び品質管理の基準に関する省令」（平成16 年厚生労働省令第179 号。以下｢GMP 省令｣という。）の適用を受ける医薬品又は医薬部外品を製造販売する製造販売業者又は製造する製造業者等（以下「製造販売業者等」という。）が、「医薬品、医薬部外品、化粧品及び医療機器の品質管理の基準に関する省令」（平成16 年厚生労働省令第136 号。以下｢GQP 省令｣という。）及びGMP 省令に基づく業務を行うためのコンピュータ化システムの要件を明確にし、コンピュータ化システムが意図したとおりに動作することを 保証するため、これを開発する際に必要な事項、これを検証するバリデーションに関する事項 及び運用管理に関する遵守事項（バリデートされた状態の維持や廃棄に関する事項等）を定め、 GQP 省令及びGMP 省令の適正な実施の確保を図ることを目的とする。

本ガイドラインは、旧ガイドラインである「コンピュータ使用医薬品等製造所適正管理ガイドライン」を置き換えるものである。「コンピュータ化システムが意図したとおりに動作することを保証するため」という文章が記載されているが、これは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 省令における組織・役割に応じた表現を用いていないが、バリデーションや変更・逸脱の管理など、 GMP 省令においては品質部門等の承認が必要であり、 GQP 省令においては品質保証部門による管理体制の中で進めなければならない。従って、製造販売業者等において組織の形態や該当するシステムの範囲を考慮して各々の組織・役割に応じた責任と権限を３ . に規定する「コンピュータ化システムの開発、検証及び運用管理に関する文書」の中に明確にすることが必要である。

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 カテゴリ分類

１．３　カテゴリ分類 このガイドラインの適用を受けるコンピュータ化システムについては、開発、検証及び運用の各段階において実施する内容を決定（「4.3 システムアセスメントの実施」を参照）するために、システムを構成するソフトウェアの種類に応じて、あらかじめソフトウェアカテゴリを決定するものとする。カテゴリ分類の基準及びカテゴリ毎の一般的対応の例を別紙２「カテゴリ分類表と対応例」に示す。

本ガイドラインでは、 GAMP と同様、ソフトウェアをカテゴリ分けしている。カテゴリはすなわちソフトウェアのリスクの分類である。カテゴリの数字が大きくなるほど、ユーザによる変更の度合いが大きく、ソフトウェアに欠陥が含まれる可能性が増大する。ここで注意が必要なのは、新ガイドラインは、 GAMP 5 のカテゴリ分類と整合させており、GAMP 4 のカテゴリ分類ではないということである。もし自社の CSV SOP が GAMP 4 に従って記述されている場合、新ガイドラインとは齟齬が生じる可能性がある。「あらかじめソフトウェアカテゴリを決定するものとする」とあるが、ソフトウェアのカテゴリは、あらかじめ決定できないのが実情である。なぜならば、供給者と打合せを行い、パッケージをどのように変更するのか、すなわち構設定するのか、カスタマイズするのか、あるいは何の変更もしないのかを決定してからでないと、最終的にカテゴリは決まらない。パブリックコメントの回答 80 には、以下の記載がある。本ガイドラインの記述は時系列に並んでいるわけではなく、供給者決定前にカテゴリ分類を行なうことを求めたものではありません。「時系列に並んでいない」とのことであるが、それでは何に対して「あらかじめ」なのかが疑問である。
別紙 2 では、ソフトウェアのカテゴリ分類に応じた対応を例示している。カテゴリについては、 GAMP 5 をよく勉強しておかなければならない。「10. 用語集」には、ソフトウェアカテゴリの定義を以下のように記載している。同程度の信頼性を有するソフトウェアの属すべき範囲。ソフトウェアの性質や特徴を区分する上での基本的な分類。しかしながら、この説明ではさっぱり理解できないのではないだろうか。

2. 適用の範囲

２．適用の範囲 このガイドラインは、コンピュータ化システムを使用して GQP 省令及び GMP 省令が適用される業務を行う製造販売業者等に適用する。 このガイドラインの対象となるコンピュータ化システムの例として、 (1) ～ (7) が考えられる。 また、対象外となるコンピュータ化システムは別紙 2 に記載する。 (1) 医薬品、医薬部外品の市場への出荷の可否の決定に係るシステム及び市場への出荷に係る 記録を作成、保存管理するためのシステム (2) 製造指図書、製造に関する記録等を作成及び保存管理するためのシステム (3) 製造工程を制御又は管理するためのシステム及びその管理データを保存管理するためのシステム (4) 原材料及び製品（製造の中間工程で造られるものを含む。以下同じ。）の保管、出納等の生産を管理するシステム (5) 品質試験に用いる機器を制御又は管理するためのシステム並びに品質試験結果及び管理データを保存管理するためのシステム (6) 空調、製造用水製造設備など、製品の品質に重大な影響を及ぼす可能性のある製造支援設備・施設を制御又は管理するためのシステム及びその管理データを保存管理するためのシステム (7) 文書（手順書類、品質標準書、製品標準書等）を作成、承認、保存管理するためのシステム

GQP 省令及び GMP 省令が適用される業務を遂行するために使用するコンピュータ化システムは、規模、形態等にかかわらず対象となる。「製造販売業者等に適用する」という表現は適用範囲としては不適切と思われる。なぜならば本
来適用範囲には、製造販売業者等が対応すべき範囲を記載するべきであるからである。(1) ～ (7) に記載されたコンピュータ化システムは、あくまでも例示であることに注意が必要である。すなわち記載されていないが、対象となるコンピュータ化システムが存在するということである。例えば、苦情管理（ CAPA）システムなどである。FDA は 2004 年頃から CAPA システムに関する査察を強化した経緯があるため、注意が必要である。筆者がパブリックコメントにおいて、苦情処理のシステムは対象とならないのかとコメントしたのに対して、回答 42 では、以下の回答が得られた。GQP 省令又は GMP 省令に関わる苦情処理の業務にコンピュータ化システムを利用するのであれば対象となります。また、パブリックコメントの回答 33 には、以下の記載がある。苦情管理、変更管理、逸脱管理、是正・予防処置管理などに使用されるシステムも適用の対象となります。ただし、適用の範囲に示したシステムはあくまで例示であり、「２．適用範囲」への追記は不要と考えます。この回答が不誠実であることは、多くの方々の感じるところであると思われる。

3. コンピュータ化システムの開発、検証及び運用管理に関する文書の作成

３．コンピュータ化システムの開発、検証及び運用管理に関する文書の作成 販売業者等はコンピュータ化システムの開発、検証及び運用にあたっては、あらかじめ、そ の基本方針等に関する文書（以下「コンピュータ化システム管理規定」という。）を定めるもの とする。

「コンピュータ化システム管理規定」は、製造販売業者等における、コンピュータ化システムの品質保証全般にかかわるポリシー文書である。新ガイドラインにしたがって、書き下ろさなければならない。

コンピュータ化システム管理規定は、原則として次の事項を記載するものとする｡ (1) コンピュータ化システムの開発、検証及び運用管理に関する基本方針 ① 目的 ② 適用範囲 ③ システム台帳の作成 ④ 基本的な考え方 ・ソフトウェアのカテゴリ分類 ・製品品質に対するリスクアセスメント ・供給者アセスメント ・開発、検証及び運用段階で実施すべき項目等 ・コンピュータシステムの廃棄に関する事項 (2) 開発業務、検証業務及び運用管理業務における責任体制と役割 (3) 開発業務、検証業務及び運用管理業務で作成すべき文書及びその管理方法 (4) 開発業務、検証業務及び運用管理業務の業務完了の確認及び承認の手続き

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 開発計画に関する文書の作成

４．開発業務 ４．１　開発計画に関する文書の作成 製造販売業者等は、開発計画に関する事項を記載した文書（以下「開発計画書」という。）を作成するものとする。開発計画書には、原則として次の事項を記載するものとする。 (1) 開発目的 (2) 開発条件 (3) 開発体制 ① 組織 ② 責任者 ・開発責任者 ・検証責任者 (4) 開発スケジュール

「開発計画書」というタイトルを見て、短絡的に「プロジェクト計画書」のことと勘違いしてはならない。
「開発計画書」は、「プロジェクトチャータ」に相当する。その根拠は 2 つある。まず「開発計画書」は製造販売業者等（すなわち経営者）が作成するものであること。また「開発計画書」の中で開発責任者を任命することとしていることである。パブリックコメントの回答 44 には以下の記載がある。開発計画書は当該企業で必要とされるコンピュータ化システムの導入の端緒であることから、製造販売業者等が作成すべき文書であり、また、開発と検証が並行して進行することから、この中で開発責任者及び検証責任者を任命することとしています。一般に「プロジェクト計画書」は、「プロジェクトチャータ」で任命されたプロジェクトマネージャが作成することになっている。

4.2 要求仕様に関する文書の作成

４．２　要求仕様に関する文書の作成 開発責任者はコンピュータ化システムに求められている事項を記載した文書（以下「要求仕様書」という。）を作成するものとする。

「要求仕様書」は、一般には「ユーザ要求仕様書」と呼ばれている。なぜあえて「ユーザ要求仕様書」ではなく、「要求仕様書」と呼んでいるのかは疑問が残るところである。用語集では、「要求仕様書」の英語名を「 User Requirements Specification」としており、日本語との間に齟齬が生じている。パブリックコメントの回答 57 には、以下の記載がある。必要な事項が記載されていれば、文書の名称は各々の製造販売業者等で決定することで差し支えありません。

要求仕様書には原則として次の事項を記載するものとする｡ (1) 適用される法規制及び適用する規定等 (2) ハードウェアの概要 (3) 要求機能 ① システム機能の概要 ② 運用要件の概要 ③ 性能要件の概要 ④ 障害対策機能の概要 ⑤ 機密保護機能の概要（セキュリティ） (4) データ ① 入出力情報の項目一覧 ② 保存方法 (5) インターフェース（関連設備及び他システム等） (6) 環境 ① 設置条件 ② システムの配置 (7) 電源、接地等の設置条件

要求仕様書に記載すべきコンテンツの例示が行われている。ちなみに、「4.4 機能仕様に関する文書の作成 」では、コンテンツが記載されていないが、基本的には、要求仕様書と同じであると考えられる。なぜならば、「機能仕様書」は、「要求仕様書」をコンピュータ化システムの設計レベルまで詳細化したものであるからである。

4.3 システムアセスメントの実施

４．３　システムアセスメントの実施 開発責任者は開発、検証及び運用の各段階にて実施すべきそれぞれの内容を定めるために、コンピュータ化システム管理規定に基づき、原則として以下の事項を実施する。 (1) ソフトウェアカテゴリ分類 (2) 製品品質に対するリスクアセスメント (3) 供給者アセスメント

本ガイドラインでは、 GAMP と同様、ソフトウェアをカテゴリ分けしている。カテゴリはすなわちソフトウェアのリスクの分類である。カテゴリの数字が大きくなるほど、ユーザによる変更の度合いが大きく、ソフトウェアに欠陥が含まれる可能性が増大する。一般に、開発業務と検証業務で作成される成果物は、システムアセスメントのなかで実施される、当該ソフトウェアのカテゴリ分類に従って決定される。一般にソフトウェアのカテゴリが 3 の場合には、作成する成果物が最も少なく、カテゴリ 5 の場合には最も多くなる。供給者アセスメントは、コンピュータ化システムを新規導入する際などに、当該供給者を選定するための調査のことを指す。一般的には、当該供給者の品質管理システム（ QMS）、品質保証体制、開発体制、従業員に対する教育訓練の程度等を調査することになる。また当該供給者の財務状況の調査も必要に応じて実施しなければならない。一般的にはこれらの調査をサプライヤオーディット（供給者監査）と呼んでいるが、パブリックコメントの回答 89 には、以下の記載がある。本ガイドラインにおける供給者アセスメントは、適切な供給者を選定するために必要な開発業務の一部ですが、供給者監査は選定された供給者が適切な業務を行っているかを監査する検証業務の一部です。したがって、供給者アセスメントと供給者監査は別個の概念であり、過去の供給者監査の結果を以降の供給者アセスメントに活用することはできますが、それは監査をアセスメントの手段とすることではありません。つまり供給者監査は、選定し契約した供給者に対して実施するものを指すということであり、供給者アセスメントとは異なるものである。このことは我々の一般的な理解と異なるので、注意が必要である。

4.4 機能仕様に関する文書の作成

４．４　機能仕様に関する文書の作成 開発責任者は、供給者に要求仕様書に記載された要件に対応した具体的なコンピュータ化システムの機能と性能を記載した機能仕様に関する文書（以下「機能仕様書」という。）を作成させ、承認するものとする。

機能仕様書は、要求仕様書に記載した要件を、コンピュータ化システム設計に対する要求事項として十分なレベルまで定義するものである。ソフトウェアのカテゴリが 4 または 5 の場合に作成する。すなわち通常カテゴリ 3 では、機能仕様書は作成しない。機能仕様書は、承認されたユーザ要求仕様書をもとに作成しなければならない。機能仕様書は、供給者側で作成したものを、製薬会社側で承認しなければならない。ここで注意が必要なのは、作成というのは、供給者内で作成・レビュ・承認が行われるということである。供給者内で承認が行われた機能仕様書は、製薬企業に納品される。製薬会社側では、納品された機能仕様書をレビュし、コメントを付け、修正や疑義事項等があれば、供給者に差し戻さなければならない。供給者側では、製薬会社のコメントや指示に従って、加筆・修正を検討し、妥当な変更を行って再度製薬会社に納品することになる。このようなレビュプロセスを経て、機能仕様書は最終的に開発責任者が承認することになる。
その際に、供給者側のサインページの上に、製薬会社側のサインページをのせて、サインを行うこととなるのである。
くれぐれも、製薬会社側で形式的にサインを入れるといった、いわゆる「めくら判」にならないようにしなければならない。本ガイドラインでは、要求仕様書や設計仕様書と違い、機能仕様書のコンテンツが定義されていない。筆者がパブリックコメントにおいて、機能仕様に関するコンテンツの記載がなく、要求仕様、設計仕様、他と不整合であるとコメントしたのに対して、パブリックコメントの回答 91 では、以下の回答が記述された。機能仕様書の内容はシステムの機能と性能に関して、システムの内容に応じて必要な事項を決定すべきであると考えます。これでは、回答 1 にある「できるだけ具体的な求め方を記載している」という理念と相反することになる。
機能仕様書執筆時に、要求仕様書と機能仕様書間のトレーサビリティマトリックスを作成しておくことも大切である。
トレーサビリティマトリックスによって、ユーザの要求事項がもれなく機能仕様書において定義されたことが保証されるのである。またトレーサビリティマトリックスは、設計時適格性評価（DQ）の際にも用いられる。しかしながら、本ガイドラインには、トレーサビリティマトリックスに関する記載はない。機能仕様書において構成設定（コンフィギュレーション）により要求機能を実現すると決定した機能に関しては、別途構成設定仕様書にその設定値を記載することになる。すなわちソフトウェアのカテゴリが 4 の場合には、機能仕様書に加えて、構成設定仕様書を作成することになるのである。しかしながら、本ガイドラインには、構成設定仕様書に関する記載はない。

4.5 設計仕様に関する文書の作成

４．５　設計仕様に関する文書の作成 開発責任者は、供給者に機能仕様書に基づいてコンピュータ化システムの詳細機能を記載した設計仕様に関する文書（以下「設計仕様書」という。）を作成させ、承認するものとする。

設計仕様書は、機能仕様書と同様、供給者が作成し、製薬企業側で承認を行う。ここで注意が必要なことは、開発責任者による設計仕様書の承認前に、検証責任者は検証業務で定義されている設計時適格性評価（DQ）を実施しなければならないということである。

設計仕様書には、原則として次の事項を記載するものとする。 4.4.1 ハードウェア設計仕様 (1) ハードウェア構成 (2) ハードウェアリスト及び仕様 (3) インターフェース (4) 入出力信号の詳細 (5) 環境 ① 設置の詳細条件 ② システム機器の配置 (6) 電源、接地等の設置条件

ハードウェアに関する設計仕様書は、ソフトウェアのカテゴリに関係なく、必要となる。また、IQ では、このハードウェア設計仕様に基づいて、ハードウェアを据え付けなければならない。

4.4.2 ソフトウェア設計仕様 (1) 入出力情報の詳細 (2) ファイル及びデータ構造 (3) データ処理の詳細 (4) 機能・モジュールの構成 (5) インターフェースの詳細 (6) 選択したパッケージソフトウェア

ソフトウェアの設計仕様書は、カテゴリが5 の場合に作成する。また、IQ では、このソフトウェア設計仕様に基づいて、ソフトウェアをインストールしなけなければならない。

4.6 プログラムの作成及びプログラムテスト

４．６　プログラムの作成及びプログラムテスト 開発責任者は、必要に応じて、供給者にプログラム作成及びプログラムテストを実施させるものとする｡プログラム作成及びプログラムテストには、以下の内容が含まれるものとする。 4.6.1 プログラムの作成 (1) 供給者は、プログラムの仕様に関する文書（以下「プログラム仕様書」という。）を設計仕様書に従って作成するものとする｡ (2) 供給者はプログラムをプログラム仕様書どおりに作成するものとする｡ 4.6.2 プログラムテストの実施 (1) 供給者は、プログラムテスト方法、プログラムテスト結果の判定方法及び判定基準を記載したプログラムテストの計画に関する文書（以下「プログラムテスト計画書」という。）を作成するものとする｡ (2) 供給者は、プログラムテスト計画書に基づき、プログラムテストを実施し、その結果を記録するものとする。 (3) 供給者は、プログラムテストの結果の適否を判定するものとする。

ソフトウェアのカテゴリが5 に場合、供給者は設計仕様書に基づいてプログラム仕様書を作成することになる。
またプログラムは、プログラム仕様書に基づいて作成する。作成されたプログラムをテストするために、プログラムテスト計画書を作成しなければならない。プログラムテスト計画書に基づいてプログラムテストを実施した際に、プログラムテスト結果を文書化し、最終的にプログラムテスト報告書にその内容が要約されることになる。プログラム仕様書の作成からプログラムテストに至るプロセスは、通常供給者側で実施され、その際の成果物は製薬会社に納品されないことが一般的である。したがって、製薬会社では、検証業務の一環として、供給者監査を実施し、プログラム仕様書、プログラム、プログラムテスト計画書およびプログラムテスト結果、プログラムテスト報告書等を調査しなければならない。

4.7 システムテスト

４．７　システムテスト 開発責任者は、必要に応じて供給者にシステムテストを実施させるものとする｡システムテストには以下の内容が含まれるものとする。 4.7.1 システムテストに関する文書の作成 供給者はシステムテストにあたっては、システムテストの計画に関する文書（以下「システムテスト計画書」という。）を作成するものとする。システムテスト計画書には、原則として次の事項を記載するものとする｡ (1) システムテストの実施環境（テスト時のハードウェアの設置状況及びソフトウェア構成等をいう｡） (2) システムテストの項目及び使用するテストデータ (3) システムテストの方法及び結果の確認方法 (4) システムテストの判定基準 (5) システムテストのスケジュール (6) システムテストを実施する場合の実施体制 4.7.2 システムテストの実施 (1) 供給者は、システムテスト計画書に基づいてシステムテストを実施し、その結果（システムテストの実施時に発生したトラブルの内容及びその措置内容を含む｡）を記録するものとする｡ (2) 供給者は、システムテストの結果の適否を判定する。この場合において、システムテストの結果の適否の判定事項は、原則として次のとおりとする｡ ① 機能（機能仕様書及び設計仕様書に規定されたとおりに機能するか等） ② 性能（機能仕様書及び設計仕様書で期待された応答性等を確保しているか等）

システムテストは、ソフトウェアのカテゴリが4 または5 の場合に実施する。カテゴリ4 の場合は、構成設定されたソフトウェアに対して、機能仕様書に記載されたとおり、機能するか、また期待されたとおりの応答性があるかについて、システムテストを実施する。カテゴリ5 の場合は、プログラミングされたソフトウェアに対して、機能仕様書および設計仕様書に記載されたとおり、機能するか、また期待されたとおりの応答性があるかについて、システムテストを実施する。
システムテスト計画書の作成からシステムテスト報告書の作成過程についても、供給者側で実施されるため、供給者監査を実施する必要がある。

4.8 受入試験

４．８　受入試験 開発責任者は、システムの機能及び性能の全てあるいは一部が要求仕様を満足していることを確認するために供給者に受入試験を実施させる。受入試験には、供給者の工場出荷前に機能及び性能を確認するテスト（工場出荷試験 ,FAT）並びにこれらシステム設置場所等における受け入れ時に機能及び性能を確認するテスト（現地受入試験 ,SAT）があり、適宜選択し実施させる。受入試験の結果は開発責任者が承認する。

本条文中には、「原則として」や「必要に応じて」という文言は見当たらない。つまり受入試験は必須事項のように読み取れる。しかしである。FATやSATは、自動化装置とプロセス制御システムに特異なテストであると認識している。したがってITシステムや分析装置などのコンピュータ化システムにおいては、ほとんどの場合、FATやSATは実施されていない。というよりも認知度が高くない。GAMPにおいても、GAMP 5からは、プロセスエンジニアリング（GEP）は、GAMP実践規範ガイド：プロセス制御システムのバリデーション（付属資料G3）として別冊となった。工場出荷試験（FAT）は、出荷前にユーザの要求を満たす機能が実装され、性能が発揮できるのかをあらかじめ確認することが目的である。いわば、出荷判定テストである。その目的は、製薬企業に設置されたのち、調整や修正が必要となった場合に、再度供給者の工場に戻すことがないようにするためである。一方、現地受入試験（SAT）では、実際の製薬企業の工場等において、電子天秤や自動倉庫などの装置や設備との接続を行い、実際に動作させることによって、その機能や性能を確認することが目的である。FAT、SATには通常、製薬企業の担当者が立ち会うことになる。開発責任者がFAT、SATの結果を承認すること。

5. 検証業務

5.1 バリデーションの全体計画に関する文書の作成

５．　検証業務 ５．１　バリデーションの全体計画に関する文書の作成 検証責任者は、コンピュータ化システム管理規定に基づき、システムの検証を行う場合には、 実施するバリデーションの全体計画に関する文書（以下「バリデーション計画書」という。）を 作成するものとする。なお、バリデーション計画書は「 4.3 システムアセスメント」により実施 した評価結果等に基づき作成する。なお、検証業務は開発業務と併行して行われることもある ため、バリデーション計画書は開発段階の適切な時期に作成する。

検証業務の全体計画として、「バリデーション計画書」を作成しなければならない。4.1 において、「開発計画に関する文書の作成」とあるので、5.1 では「検証計画に関する文書の作成」とするのが正しかったのではないだろうか。
また、開発業務では、成果物を承認することとなっているが、検証業務では作成することとなっている。ここにおいて、作成は承認を伴うものであると解釈しなければならない。「バリデーション計画書は開発段階の適切な時期に作成する」とあるように、通常バリデーション活動は、後付で実施できない。したがって、バリデーション計画書は、要求仕様書とリスクアセスメント報告書が作成された後に、遅滞なく作成しなければならない。すなわち、バリデーション計画書は、要求仕様書に対して実施したシステムアセスメントの結果を考慮して、妥当なレベルで作成すること。つまり、当該コンピュータ化システムの重要性、複雑性、規模、新規性などに応じて、適切なレベルでバリデーション（検証）にかかわる活動を定義するのである。一般に、システムアセスメントの結果によって、バリデーションにかかわる組織の大きさ（人数）、要員に必要とされるスキルと経験、作成する成果物の種類等が変化する。「4.3 システムアセスメント」と記載されているが、「4.3 システムアセスメントの実施」が正しい。

また、「6.6 変更の管理」においてバリデーションが必要となった場合は、変更の状況にあわ せて適宜バリデーション計画書を作成すること。バリデーション計画書には、原則として次の 事項を記載するものとする。また、必要な場合には詳細なリスクアセスメント、供給者監査等 の計画についても記載すること。 (1) 目的 (2) システム概要 (3) 責任体制と役割 ① 組織 ② 検証責任者 (4) 適用される法規制及び適用する規定等 (5) バリデーション方針 ① バリデーションの範囲及びバリデーションとして実施すべき項目等 (6) スケジュール (7) バリデーション実施時の変更・逸脱の管理に関する手順

「また、「6.6 変更の管理」においてバリデーションが必要となった場合は、変更の状況にあわせて適宜バリデーション計画書を作成すること。」という記載があるが、変更管理は運用管理業務で実施されるため、検証業務に記載されていることは、紛らわしい。詳細なリスクアセスメントとは、初期リスクアセスメントが要求仕様書にそって実施されるに対して、作成される当該ソフトウェアの機能毎にそのリスクを評価するといったものである。一般に機能リスク評価（Functional Risk Assessment）と呼ばれる。バリデーション計画書において、機能リスク評価をいつ、どのように、だれが実施するのかを明らかにしておくこと。また、必要に応じて、バリデーション計画書において、供給者監査の計画についても記載しておかなければならない。供給者監査は、当該ソフトウェアのカテゴリが4 または5 の場合に実施することになる。特にカテゴリ5 の場合は、より厳密な供給者監査を実施しなければならない。すなわち、カテゴリ5 の場合、供給者がプログラムの作成やテスト、システムテストを実施するが、製薬会社にはそれらの記録等が納品されないため、実際に供給者を訪問し監査しなければならないのである。さらに、検証中における変更管理や障害管理などについても記載が必要である。

5.2 設計時適格性評価（ＤＱ）

５．２　設計時適格性評価（ＤＱ） 検証責任者は、要求仕様書に記載された要求事項が、機能仕様書、設計仕様書等に正しく反映されていることを確認するため設計時適格性評価を実施する。

ソフトウェアのカテゴリが 5 の場合、DQ（Design Qualification：設計時適格性確認）の実施が必須である。DQ とは、設計がユーザの要求を満たしていることを、製造に前もって検証しておくことである。DQ の実施にあたっては、当該システムに関する深い知識と経験が必要となるため、当該サプライヤが実施することとなる。製薬企業側では、その DQ が適切に行われたかどうかを確認しておく必要がある。特にトレーサビリティマトリックスの作成が行われており、ユーザ要求仕様書で要求された機能が、もれなく設計仕様書に反映されていることを確認しておくこと。

5.2.1 設計時適格性評価の計画に関する文書の作成検証責任者は、設計時適格性評価の計画に関する文書（以下「設計時適格性評価計画書」という。）を作成ものとする。設計時適格性評価計画書には、原則として次の事項を記載するものとする｡ (1) 設計時適格性評価の対象となる文書名 (2) 具体的な確認の方法 (3) 設計時適格性評価における判定基準 (4) スケジュール (5) 責任者及び担当者の氏名

検証責任者は、供給者または検証担当者などの適切な者に「設計時適格性評価計画書」（DQ 計画書）を作成させた後に、その内容を確認し、承認しなければならない。「作成ものとする」と記載されているが「作成するものとする」が正しい。

5.2.2 設計時適格性評価の実施 (1) 検証担当者は、設計時適格性評価計画書に基づいて評価を実施し、その結果を記録するものとする｡ (2) 検証責任者は、設計時適格性評価の結果の適否を判定するものとする。

開発業務には開発担当者という役割は定義されていないが、検証業務では、検証担当者が登場する。ここにおいて検証担当者は、製薬企業の従業員であると思われる。しかしながら、一般にDQ の実施は、製薬企業では困難である。なぜならば、設計仕様書が読め、理解でき、問題点等を指摘するためには、相応の知識と経験が必要だからである。パブリックコメントの回答155 には、以下の記載がある。製造販売業者等が自身でＤＱの実施が困難な場合、製造販売業者等の責任において、供給者の協力を得て実施することも可能です。製薬企業のSOP には、DQ の実施は供給者の協力を得る旨の記載が必要であると思われる。

5.2.3 設計時適格性評価の報告に関する文書の作成検証責任者は、設計時適格性評価の報告に関する文書（以下「設計時適格性評価報告書」という。）を作成するものとする。設計時適格性評価報告書には、原則として次の事項を記載するものとする｡ (1) 設計時適格性評価の対象となる文書名 (2) 評価結果と是正措置 (3) 責任者及び担当者の氏名

検証責任者は、DQを実施した者に「設計時適格性評価報告書」（DQ報告書）を作成させた後に、その内容を確認し、承認しなければならない。

5.3 据付時適格性評価（IQ）

５．３　据付時適格性評価（ IQ） 検証責任者は、コンピュータ化システムが、設計仕様等に記載されたとおりに据え付けられ、プログラムがインストールされたことを確認するため据付時適格性評価を実施する。

プログラムをインストールするとの記載があるが、ソフトウェアの間違いであると思われる。なぜならば5.3.1 (7)と矛盾するからである。

5.3.1 据付時適格性評価の計画に関する文書の作成 検証責任者は、ハードウェア及びソフトウェアの据付時適格性評価の計画に関する文書（以下「据付時適格性評価計画書」という。）を作成するものとする。据付時適格性評価計画書には原則として次の事項を記載するものとする｡ (1) 据付時適格性評価の対象となる文書名 (2) ハードウェア構成及び設置場所 (3) ハードウェアの温度、湿度、振動等の環境条件 (4) 電源、接地等の設置条件 (5) 通信、入出力に関する仕様 (6) ハードウェアの設置の確認方法 (7) ソフトウェアのインストールの確認方法 (8) 据付時適格性評価における判定基準 (9) スケジュール (10) 責任者及び担当者の氏名

検証責任者は、供給者または検証担当者などの適切な者に「据付時適格性評価計画書」（IQ 計画書）を作成させた後に、その内容を確認し、承認しなければならない。

5.3.2 据付時適格性評価の実施 (1) ハードウェアの設置の確認 ① 検証担当者は据付時適格性評価計画書に基づいて、ハードウェアが適切に設置されてい ることを確認し、その結果を記録するものとする｡ ② 検証責任者は、ハードウェアの設置の適否を判定するものとする｡ (2) ソフトウェアのインストールの確認 ① 検証担当者は基本ソフトウェアを含め、適切にインストールされていることを確認し、 その結果を記録するものとする｡ ② 検証責任者は、ソフトウェアのインストールの結果の適否を判定するものとする｡

IQもDQ同様、製薬会社側で実施することは困難である。適切に供給者の協力を得て、実施しなければならない。

5.3.3 据付時適格性評価の報告に関する文書の作成 検証責任者は、据付時適格性評価の報告に関する文書（以下「据付時適格性評価報告書」と いう。）を作成するものとする。据付時適格性評価報告書には、原則として次の事項を記載する ものとする｡ (1) 据付時適格性評価の対象となる文書名 (2) 評価結果と是正措置 (3) 責任者及び担当者の氏名

検証責任者は、IQを実施した者に「据付時適格性評価報告書」（IQ報告書）を作成させた後に、その内容を確認し、承認しなければならない。

5.4 運転時適格性評価（OQ）

５．４　運転時適格性評価（ OQ） 検証責任者は、コンピュータ化システムが運転時において、機能仕様等に示された機能及び性能を発揮することを確認するため運転時適格性評価を実施する。

一般にOQ は、当該コンピュータ化システムに、機能仕様書に記載されたとおりに全機能が実装されており、問題なく運転できる（つまり不具合やバグ等がない）ことを確認するために実施する。

5.4.1 運転時適格性評価の計画に関する文書の作成 検証責任者は、運転時適格性評価の計画に関する文書（以下「運転時適格性評価計画書」という。）を作成するものとする。運転時適格性評価計画書には原則として次の事項を記載するものとする。 (1) 運転時適格性評価の対象となる文書名 (2) システムの運転環境における機能の確認方法 (3) 運転時適格性評価における判定基準 (4) スケジュール (5) 責任者及び担当者の氏名

検証責任者は、検証担当者などの適切な者に「運転時適格性評価計画書」（OQ 計画書）を作成させた後に、その内容を確認し、承認しなければならない。

5.4.2 運転時適格性評価の実施 (1) 検証担当者は、運転時適格性評価計画書に基づいて評価を実施し、その結果を記録するものとする｡ (2) 検証責任者は、運転時適格性評価の結果の適否を判定するものとする｡

OQ の実施にあたっては、OQ スクリプトの作成が必要となる。OQ スクリプトは、当該供給者に作成させることが望ましい。なぜならば、製薬会社にとって、初めて操作するシステムに関するテストの内容を適切かつ網羅的に作成することは困難であるからである。OQ スクリプトを用いて、OQ を実施した記録を記載したものが、OQ ログであり、OQ の記録となる。

5.4.3 運転時適格性評価の報告に関する文書の作成 検証責任者は、運転時適格性評価の報告に関する文書（以下「運転時適格性評価報告書」という。）を作成するものとする。運転時適格性評価報告書には、原則として次の事項を記載するものとする｡ (1) 運転時適格性評価の対象となる文書名 (2) 評価結果と是正措置 (3) 責任者及び担当者の氏名

検証責任者は、OQ を実施した者に「運転時適格性評価報告書」（OQ 報告書）を作成させた後に、その内容を確認し、承認しなければならない。

5.5 性能適格性評価（PQ）

５．５　性能適格性評価（ PQ） 検証責任者は、コンピュータ化システムが稼働時において、要求仕様等どおりに機能し、性能を発揮して運転できることを確認するため性能適格性評価を実施する。

一般にPQ は、当該コンピュータ化システムが、要求仕様書に記載されたとおりの性能を発揮して稼働できることを確認するために実施する。「運転」と「稼働」の違いは、以下の通りと理解する。「運転」とは、当該コンピュータ化システムを単独で動作させることであり、「稼働」とは、実際にライン等に組み込んで動作させることである。したがって、「運転」は、空で運転し、「稼働」は、実際に生産させてみることに相当する。「運転できることを確認」とあるが、「稼働できることを確認」が正しいと思われる。

5.5.1 性能適格性評価の計画に関する文書の作成 検証責任者は、性能適格性評価の計画に関する文書（以下「性能適格性評価計画書」という。） を作成するものとする。性能適格性評価計画書には原則として次の事項を記載するものとする。 (1) 性能適格性評価の対象となる文書名 (2) システムの稼働時における機能及び性能の確認方法 (3) 性能適格性評価における判定基準 (4) スケジュール (5) 責任者及び担当者の氏名 5.5.2 性能適格性評価の実施 (1) 検証担当者は、性能適格性評価計画書に基づいて、性能適格性評価を実施し、その結果を記録するものとする｡ (2) 検証責任者は、性能適格性評価の結果の適否を判定するものとする｡

PQ の実施にあたっては、PQ スクリプトの作成が必要となる。PQ スクリプトについても、当該供給者に作成させることが望ましい。PQ スクリプトを用いて、PQ を実施した記録を記載したものが、PQ ログであり、PQ の記録となる。

5.5.3 性能適格性評価の報告に関する文書の作成 検証責任者は、性能適格性評価の報告に関する文書（以下「性能適格性評価報告書」という。） を作成するものとする。性能適格性評価報告書には、原則として次の事項を記載するものとする｡ (1) 性能適格性評価の対象となる文書名 (2) 評価結果と是正措置 (3) 責任者及び担当者の氏名

検証責任者は、PQ を実施した者に「性能適格性評価報告書」（PQ 報告書）を作成させた後に、その内容を確認し、承認しなければならない。

5.6 適格性評価の一部省略と引用

５．６　適格性評価の一部省略と引用 (1)「5.4 運転時適格性評価（ OQ）」における検証内容、環境、条件などが「 5.5 性能適格性評価（ PQ）」の内容と差がない場合は運転時適格性評価を省略しても差し支えないものとする。但しその場合、省略の旨を「バリデーション計画書」若しくは「性能適格性評価計画書」又はいずれかの報告書に明記すること。 (2) 工場出荷試験又は現地受入試験を行った場合等、その確認の方法及び記録が検証責任者によって適切と認められる場合には、適格性評価にあたって、その結果を引用しても差し支えないものとする。

ここでは、適格性評価を簡略化できる条件が記載されている。(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 運用管理に関する文書の作成

６．　運用管理業務 ６．１　運用管理に関する文書の作成 製造販売業者等はコンピュータ化システムの運用管理に関する文書（以下「運用管理基準書」という。）を作成するものとする。運用管理基準書には原則として次の事項を記載するものとする。但し、 GQP 省令又は GMP 省令に関する手順書に基づき管理を行う項目については、その旨を記載すること。 (1) 運用に関する責任体制と役割 ① 組織 ② 運用責任者 (2) コンピュータ化システムの操作 コンピュータ化システムの操作の手順に関する文書（標準操作手順書）をコンピュータ化 システムごとに作成し、それに基づき操作するものとする。 (3) 保守点検管理 ① 日常点検事項 ② 定期点検事項 ③ 保守点検を専門業者に委託する場合の取決め事項 (4) セキュリティ管理 ① データの入力、修正、削除等に関する担当者のアクセス権限の設定と不正アクセス防止 ② 識別構成要素の管理 ③ ハードウェア設置場所への立入制限 (5) バックアップ及びリストア (6) 変更の管理 ① 変更の計画、承認の手順 ② 変更の影響評価 ③ その他、変更に必要な事項 (7) 逸脱（システムトラブル）の管理 ① 逸脱（システムトラブル）発生時の対応のための組織等 ② 逸脱（システムトラブル）の原因の究明及び影響評価 ③ 再発防止対策 ④ 回復措置 ⑤ システム停止後の再開手順及び再開時の確認事項 ⑥ その他逸脱の管理に必要な事項 (8) 担当者の教育訓練 (9) 自己点検

案では、「運用管理手順書」であったものが、「運用管理基準書」に変更となった。「運用管理基準書」は、企業または組織で1つ作成するものであって、コンピュータ化システム毎に作成するものではない。しかしながら、そのコンテンツを見ていると、システム毎に記述しなければならないものもあり、考慮が必要である。しかしながら変更の管理、逸脱（システムトラブル）の管理、教育訓練は、GQP省令、GMP省令における手順に従って運用することが望ましいため、「運用管理基準書」に基づくこととされている。

6.2 コンピュータ化システムの操作の手順に関する文書の作成

６．２　コンピュータ化システムの操作の手順に関する文書の作成 コンピュータ化システムの操作の手順に関する文書（以下「標準操作手順書」という。）をコ ンピュータ化システムごとに作成し、それに基づき操作するものとする。 標準操作手順書には、原則として以下の事項を記載する ① システムの担当者 ② コンピュータ化システムの操作 ③ コンピュータ化システムの保守点検 ④ コンピュータ化システムのセキュリティ管理 ⑤ その他、コンピュータ化システムの特性に応じた運用管理

「標準操作手順書」は、一般にSOP とも呼ばれ、コンピュータ化システム毎に作成しなければならない。

6.3 保守点検事項の実施

６．３　保守点検事項の実施 運用責任者は、運用管理基準書及び標準操作手順書（以下「運用管理基準書等」という。）に基づき、次に掲げる業務を行うものとする。 (1) 担当者に保守点検を実施させ、その結果を記録し、保管すること。 (2) 保守点検の記録により保守点検管理が適切に行われていることを確認すること。

タイトルの「保守点検事項の実施」は、多少違和感がある。「保守点検の実施」が適切ではないであろうか。
この章以降では、「運用基準書」と「運用基準書等」という用語を明確に使い分けているので注意が必要である。「運用基準書等」は、運用基準書と標準操作手順書を合わせたものである。ここでは、「運用管理基準書」とは別に、コンピュータ化システム毎に、「保守点検の手順書」を作成しなければならないのである。

6.4 セキュリティ管理の実施

６．４　セキュリティ管理の実施 運用責任者は、運用管理基準書等に基づき、次に掲げる業務を行うものとする。 (1) データの入力、修正、削除等に関する担当者のアクセス権限の設定と、不正アクセスの防止措置を講じること。 (2) 識別構成要素等の取扱いについて、機密保護を図ること。 (3) 必要に応じてハードウェア設置場所への立入制限を行うこと。 (4) セキュリティ管理に関する記録を作成するとともに、これを保管すること。

タイトルの「保守点検事項の実施」は、多少違和感がある。「保守点検の実施」が適切ではないであろうか。この章以降では、「運用基準書」と「運用基準書等」という用語を明確に使い分けているので注意が必要である。「運用基準書等」は、運用基準書と標準操作手順書を合わせたものである。ここでは、「運用管理基準書」とは別に、コンピュータ化システム毎に、「保守点検の手順書」を作成しなければならないのである。

6.5 変更の管理

1.1 バックアップ及びリストア 運用責任者は、あらかじめ指定した者に対し、運用管理基準書等に基づき、次に掲げる業務を行わせること。 (1) ソフトウェア及びデータのバックアップを行うこと。 (1) 障害発生からの回復のためにソフトウェア及びデータのリストアを行うこと。 (1) バックアップ及びリストアに関する記録を作成するとともに、これを保管すること。

「運用基準書等」と記載されていることに注意が必要である。すなわち、「運用管理基準書」とは別に、「バックアップ/ リストアの手順書」を作成しなければならないのである。なお、「バックアップ/ リストアの手順書」にしたがって、リストアが適切かつ確実に実施できることを検証しておくことが必要である。すなわち、「バックアップ/ リストアの手順書」の適格性を確認しておくこと。リストア作業について、適切な検証が行われていない場合は、要事にデータの復旧ができない可能性もあり、問題である。

6.6 変更の管理

６．６　変更の管理 運用責任者は、あらかじめ指定した者に対し、運用管理基準書に基づき、次に掲げる業務を 行わせること。 (1) 変更がコンピュータ化システムに与える影響を評価し、評価の結果に基づき適切な措置を 実施すること。なお評価の結果、バリデーションが必要と判断された場合は、リスクの 程度に応じて「４. 開発業務」及び「５. 検証業務」に戻ってバリデーションを実施すること。 (2) 変更に伴い発生する手順に関する文書の変更箇所を特定し、必要な改定を実施すること。 (3) 変更内容の関係者への周知の方法を決定し、必要に応じて教育訓練を実施すること。 (4) 変更の管理の記録を作成し、運用責任者の確認を得るとともに、運用責任者及び変更の管 理に関する責任者等の承認を得てこれを保管すること。 GMP 省令に係るシステムに関する変更の管理については、GMP 省令における変更の管理の手 順に従って運用すること。ただし、その場合も上記（1）から（4）の内容を含むこと。

ここにおいて、「運用管理基準書」であり、「運用管理基準書等」ではないことに注意が必要である。
すなわち、変更管理においては、別途手順書を作成してはならないという趣旨である。特にGMP 省令に係るシステムの場合には、GMP 省令における変更の管理の手順に従わなければならず、コンピュータ化システムに特化した「変更管理手順書」を別途作成してはならないことを意図しているように読める。その場合、GMP 省令における変更の管理の手順に上記（1）から（4）の内容を追記しなければならない。しかしである。GMP 省令における変更の管理の手順を、コンピュータ化システムの変更管理にも利用できるように加筆・修正することに筆者は反対である。コンピュータ化システムの変更管理に関しては、その対象物がシステム毎に異なることや、当該供給者を交えなければならないことなどから、システム毎に作成しなければならないためである。一般に、コンピュータ化システムの変更管理は、特に断りがない場合は、運用段階における変更を指す。すなわち、バリデートされ運用に入ったシステムを変更することであり、開発段階における変更を指すものではない。バリデートされたシステムを変更することは、リスクを伴い、適切かつ慎重に管理しなければならない。また、当該システムの変更に伴い、再度バリデーションが必要となることがあるが、その場合においても「バリデーション計画書」の作成が必要である。

6.7 逸脱（システムトラブル）の管理

６．7　逸脱（システムトラブル）の管理 運用責任者は、あらかじめ指定した者に対し、運用管理基準書に基づき、次に掲げる業務を行わせること。 (1) 発生した逸脱（システムトラブル）が製品の品質に及ぼす影響を評価し、速やかに適切な対応措置を講じるとともに、その原因を究明し、必要な再発防止措置を実施すること。 (2) 逸脱（システムトラブル）発生後にコンピュータ化システムの運用を再開する場合には、復帰稼働が適切に行われていることを確認すること。 (3) 逸脱（システムトラブル）の管理の記録を作成し、運用責任者の確認を得るとともに、運用管理責任者及び逸脱の管理に関する責任者等の承認を得てこれを保管すること。 GMP 省令に係るシステムに関する逸脱の管理については、 GMP 省令における逸脱の管理の手順に従って運用することでよいが、その場合も上記（ 1）から（ 3）の内容を含むこと。

本ガイドラインでは、システムトラブルを逸脱としてるが、違和感を感じる。一般に、システムトラブルは、障害と呼び、逸脱ではない。ここにおいても、「運用管理基準書」であり、「運用管理基準書等」ではないことに注意が必要である。ただし、逸脱管理においては、「GMP 省令における逸脱の管理の手順に従って運用することでよい」とあり、変更管理のそれに比べて、柔軟な記載となっている。ただし、GMP 省令における逸脱の管理の手順に従って運用する場合、その手順に上記（1）から（3）の内容を追記しなければならない。

6.7 教育訓練

６．8　教育訓練 6.8.1 教育訓練計画の作成 運用責任者は、運用管理基準書に基づき、あらかじめ指定した者に、コンピュータ化システムを使用した業務に従事する者に対する教育訓練計画を作成させること。なお、教育訓練については GQP 省令、 GMP 省令における手順に従って運用することが望ましい。

適切な時期に教育訓練が実施できるよう、「教育訓練計画書」を作成しておかなければならない。ここにおいて、「教育」と「訓練」は、内容、目的、方法が異なるので、注意が必要である。「教育」は、英語ではEducation であり、すべての受講者が同じカリキュラム、すなわち同じテキストで学習することをいう。それに対し、訓練は、担当者の役割、責任、担当業務に応じて、実際に当該コンピュータ化システムを操作しながら学習することを指す。

6.8.2 教育訓練の実施 運用責任者は、教育訓練計画に基づき、あらかじめ指定した者に次に掲げる業務を行わせること。 (1) コンピュータを使用した業務に従事する者に対して、コンピュータ化システムを使用した業務に関する教育訓練を計画的に実施し、その記録を作成すること。 (2) 教育訓練の実施状況について運用責任者の確認を得るとともに、品質保証責任者又は製造管理者若しくは責任技術者に対して文書により報告すること。 6.7.3 教育訓練の記録の保管 運用責任者は教育訓練の実施の記録を保管すること。

教育訓練の実施に当たっては、責任者を決め、その記録を作成しておくことが必要である。

6.8.3 教育訓練の記録の保管 運用責任者は教育訓練の実施の記録を保管すること。

教育訓練の記録は、適切に保管し、社内監査や当局の査察時等に、要求に応じて速やかに提示できるようになっていなければならない。

7. 自己点検

7.1 自己点検の実施

７．　自己点検 ７．１　自己点検の実施 製造販売業者等は、運用管理基準書に基づき、あらかじめ指定した者に次に掲げる業務を行 わせること。なお、自己点検においては、 GQP 省令、 GMP 省令における手順に従って運用する ことが望ましい。 (1) コンピュータ化システムがこのガイドラインに基づき管理されていることを確認するために定期的に自己点検を実施すること。 (2) 自己点検の結果について品質保証責任者又は製造管理者若しくは責任技術者に対して文書により報告すること。 (3) 自己点検の結果の記録を作成し、これを保管すること。

ここにおいて、自己点検は、定期監査のことではないことに注意すること。自己点検は、QC 業務の一環である。

7.2 改善措置の実施

７．２　改善措置の実施 製造販売業者等は、自己点検の結果に基づき、改善が必要な場合には所要の措置を講じ、その記録を作成しこれを保管させること。

自己点検の結果に伴い、改善が必要な場合には所要の措置を講じる必要がある。これは、いわゆるCAPA（Corrective Actions; Preventive Actions：是正措置、改善措置）の実施である。

8. コンピュータシステムの廃棄

8.1 コンピュータシステムの廃棄の計画に関する文書の作成

８．コンピュータシステムの廃棄 ８．1　コンピュータシステムの廃棄の計画に関する文書の作成 製造販売業者等はコンピュータシステムの廃棄にあたっては、コンピュータシステムの種類や規模、カテゴリ等、必要に応じて、コンピュータシステムの廃棄に関する計画書（以下「廃棄計画書」という。）を作成すること。廃棄計画書には原則として以下の事項を記載するものとする。 (1) 廃棄に関する責任体制と役割 ① 組織 ② コンピュータシステムの廃棄の責任者 (2) 廃棄対象とするコンピュータシステム (3) データの移行に関する事項 (4) セキュリティに関する事項 (5) コンピュータシステムの廃棄方法 コンピュータシステムの種類や規模、用途等に応じて以下を参考にして適切に定めること ① リスクアセスメント ② 前提条件 ③ スケジュール ④ 具体的な廃棄の方法 ・ハードウェア ・ソフトウェア ・データ ・文書類（手順書、記録、契約書等） (6) 廃棄完了の判断基準

コンピュータシステムを廃棄する際においても、品質保証を行うことが肝要である。すなわち、計画書を作成し、計画のとおり実施し、記録し、報告書を作成しなければならない。ここにおいて、「コンピュータシステムの廃棄」であって、「コンピュータ化システムの廃棄」でないことに注意が必要である。当該コンピュータ化システムがその役目を終え、利用を中止する際に、廃棄しても良いものは、ハードウェアとソフトウェアのみである。つまり、電子記録、標準操作手順書（SOP）、変更の記録、障害の記録、バリデーションの記録等は、絶対に廃棄してはならない。
これらは、安心・安全・確実にアーカイブしておかなければならず、社内の監査や規制当局の査察時等に、要求に応じて速やかに提示できなければならない。特に、電子記録に関しては、監査証跡や電子署名の情報などの、いわゆるメタデータを共に保存しておく必要がある。さもなくば、電子記録の真正性が失われるからである。コンピュータシステムの廃棄に当たっては、当該システムを構築した供給者と相談し、どのように電子記録を新システムに移行するのか、あるいは別途アーカイブしておくのかを検討しておかなければならない。すなわち、新規システムの導入プロジェクトは、旧システムの廃棄プロジェクトからはじまるということである。「カテゴリ等」に応じて廃棄する旨の記述があるが、一般に廃棄にはカテゴリは影響しない。廃棄計画書の最後に、廃棄完了の判断基準を記載することとなってるが、廃棄に関してのみ完了の判断基準が記載されていることに違和感を覚える。同様に開発業務、検証業務についても、完了の判断基準が必要ではないだろうか。

8.2 コンピュータシステムの廃棄記録の作成

８．２　コンピュータシステムの廃棄記録の作成 コンピュータシステムの廃棄の責任者は、廃棄計画書に基づきコンピュータシステムを廃棄 するとともに、廃棄の記録を作成し、これを保管すること。

廃棄の責任者は、廃棄計画書にしたがって、廃棄業務を行い、その記録を保管しなければならない。

9. 文書及び記録の管理

９．　文書及び記録の管理 このガイドラインに基づき作成された文書及び記録は GQP 省令又は GMP 省令に基づき定めた文書及び記録の管理の方法に従って適切に保存管理するものとする。 GQP 省令及び GMP 省令にまたがるシステムの場合は、あらかじめどちらの省令に従って管理するかをコンピュータ化システム管理規定等に明記しておくこと。

「保存管理」という表現は、「保管」とどう違うのであろうか。GQP 省令及びGMP 省令にまたがるシステムの場合は、どちらの省令にしたがって管理するのかをあらかじめ決めておかなければならない。しかしながら、製造販売業者と製造業者で法人が異なる（すなわち親会社と子会社）場合、注意が必要である。なぜならば、法人が違うのであれば、文書や記録は、各法人がもっていなければならず、またそれぞれの品質保証部門が承認を行っていなければならない。
すなわち、1 つのコンピュータ化システムであっても、文書や記録を2 部作成し、各々が保管しなければならないことになる。また、外資系企業の場合、海外の本社で作成されたコンピュータ化システムの文書や記録は、多くの場合、英語等で記述されているが、日本法人で適切に邦訳し、保管しておくことも必要となるかもしれない。