ASTROM通信バックナンバー

2019.01.15

【PIC/Sデータ・インテグリティ関連ガイドラインドラフトについて(3)】ASTROM通信<162号>Part1

 ~安全な医薬品の安定供給をご支援する~ 

こんにちは 
ASTROM通信担当の橋本奈央子です。

明けましておめでとうございます。本年もどうぞよろしくお願いいたします。

ご存知の方も多いと思いますが、2018年12月28日に医薬品の適正流通(GDP)ガイドラインが発出 
されました。 
医薬品の市場出荷後、薬局、医薬品販売業、医療機関にわたるまでの医薬品の仕入、保管及び 
供給業務に適用されるとありますが、仕入先はもとより、販売先の適格性評価、医薬品の受入業務・ 
廃棄に関する規定もありますので是非ご一読ください。 
■医薬品の適正流通(GDP)ガイドライン 
https://www.mhlw.go.jp/content/11120000/000465675.pdf

今回は、前回に引き続き、2018年11月30日にPIC/Sから発出された、「GMP/GDP環境でのデータ管理と 
インテグリティに関する適正管理基準のガイドラインのドラフト(PI 041-1 (Draft 3))」について 
見ていきたいと思います。今回は、9章の、コンピュータ化システムを使用したデータ・インテ 
グリティについて取り上げます。 
とても長いため、Part1とPart2の2部構成になります。 
このPart1をお送りした後、Part2を送付させていただきますが、最後までお付き合いいただければ 
幸いです。 
■出典 
https://www.picscheme.org/en/news


◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆ 
PIC/S GMP/GDP環境でのデータ管理とインテグリティに関する適正管理基準のガイドラインのドラフト 
GOOD PRACTICES FOR DATA MANAGEMENT AND INTEGRITY IN REGULATED GMP/GDP ENVIRONMENTS

PI 041-1 (Draft 3) 
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆ 
9章 コンピュータ化システムに関するデータ・インテグリティの留意事項 
9.1 QMSの体制とコンピュータ化システムの管理 
9.1.1 多種多様のコンピュータ化システムが多数の操作を手助けするために会社で使用されている。 
    シンプルなスタンドアロンから、広く統合されて複雑なものまであり、それらの多くは、製造 
される製品の品質に影響を与える。全てのコンピュータ化システムを評価して管理することや、 
GMP及びGDPの要件に従って運営することは、規制される各組織の責任である。 
9.1.2 組織は、利用されるコンピュータ化システムの機能と範囲を完全にわかっているべきであり、 
各システムの使用目的と機能、改ざんの影響を受けやすいデータ・インテグリティのリスク 
または脆弱性の記述のアセスメントが行われているべきである。製品品質に関わるコンピュータ化 
システム及び関連するデータの重要性の判断に重点が置かれるべきである。 
9.1.3 製品品質に影響を与える可能性のある全てのコンピュータ化システムは、偶然または意図的な 
改ざん、変更、または、データの品質やインテグリティに影響を与えうる活動からシステムが 
保護されていることを保証するために設計された成熟した医薬品品質システムのもとで効果的に 
管理されるべきである。 
9.1.4 コンピュータ化システムの設計、評価、選択の過程で、システムのデータ・マネジメントとデータ 
・インテグリティの側面の適切な検討を含むべきである。規制されるユーザは、新しいシステムが 
効果的なデータ・マネジメントを保証するための適切な管理を含むことを保証しなければならない。 
レガシー・システム(新しいシステムが登場しても、長年使われてきたために完全に捨てることの 
できない古いシステム)も基本的に同じ要件を満たすことが期待される。しかしながら、完全な 
要件遵守のためには、追加の管理 (例:管理手順を支援、もしくは、セキュリティを補足するソフト 
ウエア/ハードウエア)を必要とするかもしれない。 
9.1.5 データの脆弱性やリスクを判断するとき、コンピュータ化システムのビジネスプロセス内での使用の 
背景が考慮されることが重要である。例えば、統合されたコンピュータのインタフェースを利用した 
分析により生成された結果のインテグリティは、サンプルの準備、システムへのサンプルの重さの 
入力、データを生成するためのシステムの利用、データを使用した最終結果の処理・記録の影響を 
受ける。データフローマップの作成とアセスメントは、特にインタフェースされたシステムといった、 
コンピュータ化システムのリスクと脆弱性の理解に役立つだろう。 
9.1.6 このガイドラインは、コンピュータ化システムを背景としたデータ・インテグリティに関する留意 
事項を提供することを目的としている。さに、コンピュータ化システムに関する適正な管理基準は、 
PIC/Sの、規制された“GxP”環境におけるコンピュータ化システムの適正な管理基準(PI 011)にも 
記載されているかもしれない。

9.2 コンピュータ化システムの適格性評価とバリデーション 
9.2.1 コンピュータ化システムの適格性評価とバリデーションは、関連するGMP/GDPのガイドラインに従って 
実施されるべきである:以下の表に、コンピュータ化システムの適正なデータの保証に関する特別な 
期待に関する説明がある。 
9.2.2 ユーザは、バリデーションだけが必ずしも生成されたデータが適切に保護されていると保証せず、 
バリデートされたシステムも、偶然または悪意のある方法による喪失や変更に対して脆弱な可能性が 
あることに気づくべきである。従って、バリデーションは、適切な管理上のまたは物理的なコント 
ロールや、ユーザの訓練や教育により補われるべきである。 
<システムのバリデーションとメンテナンス> 
1-期待 
・規制を受ける会社は、データの管理とインテグリティに関する要件がシステム調達の最初の段階と、 
システムとデータのライフサイクルを通じて考慮されていることを保証するために、適切なシステムを実装 
しなければならない。GMPの規制を受けるユーザは、機能仕様書(FS)、ユーザ要求仕様書(URS)等の 
Annex15の要件に適切に取り組まなければならない。 
・システムがデータ・インテグリティのコントロールに関して購入前に適切に評価されることを保証する 
ために、GxPの重要な装置の購入に特別な注意が払わなければならない。 
・使用中のレガシー・システムは、存在しているシステムの機器構成や機能が、適正なデータの管理とインテ 
グリティの管理基準に従って、データの適切な管理が可能なのかどうかを判断するために評価されるべきで 
ある。これらのシステムの機能や設計が適切な管理レベルを提供しない場合、追加の管理が検討され実装 
されるべきである。 
1-期待を満たさない場合の潜在的なリスク/チェック項目 
・DI(データ・インテグリティ) の要件の不十分な検討により、求められるデータの管理とインテグリティ 
の期待を満たす基本機能を含まないソフトウエアシステムを購入することになるかもしれない。 
・査察官は、新しいシステムの実装が、DIの原則を適切に考慮した手順に従っていることを確認しなければ 
ならない。 
・いくつかのレガシー・システムは、データ・マネジメントに関する適切な管理を含まず、検知の可能性の 
低いデータの改ざんの余地があるかもしれない。 
・存在するシステムのアセスメントは、入手可能であり、全ての脆弱性に関する概説と、データ・インテ 
グリティを保証するために実装された全ての追加の管理のリストを提供しなければならない。 
2-期待 
・規制を受けるユーザは、使用中の全てのコンピュータ化システムの台帳を持っていなければならない。 
このリストには以下のことに関する内容を含まなければならない。 
-各コンピュータ化システムの名前、設置場所と主要な機能 
-機能とシステムの重要性と関連するデータのアセスメント(例:GMP/GDPへの直接の影響あり、非直接 
の影響あり、何もなし) 
-各システムの現在のバリデーションの状態と、存在するバリデーション文書の参照 
・特に、データ・インテグリティを保証するために必要な管理の評価を行い、各システムのリスクアセス 
メントが行われているべきである。データ・インテグリティに関する管理のバリデーションのレベルと 
範囲はシステム及び処理の重要性と、製品品質へのリスクの可能性に基づいて判断されるべきである。 
例:ロットのリリースデータを生成または管理する処理やシステムは、一般的に、重要でないデータや 
処理を管理するシステムより大きな管理が要求される。 
・これらのシステムについて、災害、誤動作、または、システムが動作不能になる可能性の高さも考慮 
されるべきである。 
・アセスメントは、システムの重要な構成設定の不注意もしくは無断の変更や、データの改ざんに関する 
脆弱性もレビュすべきである。全ての管理は、文書化され、効果が検証されていなければならない。 
2-期待を満たさない場合の潜在的なリスク/チェック項目 
・全てのコンピュータ化システムに関して適切な可視性を持たない会社はシステムの重大性を見落とし、 
データのライフサイクルを通じて脆弱性を生むかもしれない。 
・システム台帳は、これらのシステムに対するすべての変更や改良が管理されることを保証し、全ての 
システムが明確につながることに役立つ。 
・リスクアセスメントが重要な装置やデータ収集システムに関して実施されていることを確認せよ。 
システムの影響の徹底的なアセスメントの欠如は、適切なバリデーションとシステムの管理の欠如に 
つながるだろう。レビュするための重要なシステムの例は、以下の通りである。 
-製品及び原材料の購入やステイタスの管理をするシステム 
 -重要な製造工程の管理とデータ収集をするシステム 
-ロットの品質を判断するために使用される、データを生成し、保存し、処理するシステム 
-ロットの加工や包装の記録に含まれるデータを生成するシステム 
-製品の出荷判定に関する判断の過程で使用されるシステム 
3-期待 
・各コンピュータ化システムのバリデーション・サマリ・レポート(Annex15の要件に従って書かれ承認 
されたもの)が整えられ、少なくとも下記の内容が記述(もしくは参照)されていなければならない。 
-重要なシステムの構成設定の詳細と、構成設定へのアクセス制限に関する管理と、全ての変更(変更管理) 
-ユーザの名前とその役割を明記した、現在許可されている全ての通常のユーザと管理ユーザのリスト 
-監査証跡とシステムログのレビュの頻度 
-下記の手順 
  ○いかに新しいシステムユーザが生成されるか 
  ○存在しているユーザの変更(権限の変更)の手順 
  ○各システムのパスワードの組み合わせ/フォーマットの定義 
   ユーザのレビュと削除の手順 
  ○バックアップの手配と頻度 
  ○災害復旧手順の言及 
  ○アーカイブしたデータのアクセスと読み取りを含む、データのアーカイブに関する手順と責任 
  ○データの保管に関して認められた場所 
・レポートは、製造工程または分析作業を復元することを可能にする関連メタデータと共にオリジナル 
データがいかに保管されているかを説明しなければならない。 
3-期待を満たさない場合の潜在的なリスク/チェック項目 
・バリデーションのシステムとレポートが以下のGMP/GDP要件とALCOAの原則を考慮したインテグリティの 
要件に対応していることをチェックせよ。 
・システムの構成設定と職務の分離(例:データを生成する権限は、データを検証する権限と独立すべき 
である)がバリデーションの前に定義され、試験中効果的に検証されているべきである。 
・システムへの改良や変更が制限され、変更管理マネジメントの対象になっていることを保証するための 
システムのアクセスに関する手順をチェックせよ。 
・システムの管理者アクセスがオーソライズド・パーソンに限定されていて、日常の作業で使用されて 
いないことを保証せよ。 
・アクセスの許可、修正、除去が管理されていることを保証するために、その手順をチェックせよ。 
ユーザのアクセスログと特権レベルをチェックせよ。権限のないユーザのシステムへのアクセスがなく、 
アクセス・アカウントは最新化されていなければならない。ユーザが監査証跡機能を修正することを 
防ぐための制限もあるべきである。 
4-期待 
・会社は、コンピュータ化システムのバリデーションに関する具体的な方針と要求事項とシステムや 
関連データのインテグリティの要求事項を含むバリデーション・マスタ・プランを整えなければ 
いけない。コンピュータ化システムのバリデーションの範囲は、リスクに基づいて判断されなければ 
ならない。コンピュータ化システムバリデーションの要求事項の評価に関する更なるガイドラインは、 
 PI 011にも記載されているだろう。 
・システムが日常的な使用に移行する前に、許容範囲に適合することを確認するために決められた試験が 
実施されなければならない。 
・コンピュータ化システムの予測的バリデーションが実施されることが期待される。適切なバリデー 
ションデータが、既に使用中のシステムにおいて利用可能でなければならない。 
・コンピュータシステムバリデーションは、GMP Annex15のURS(ユーザ要求仕様書)、 
FAT(工場出荷試験)、SAT(現地受入試験)、IQ(据付時適格性評価)、OQ(運転時適格性評価)、 
PQ(性能適格性評価)の内容に従って設計されなければならない。 
・適格性評価には、DQ(設計時適格性評価)、IQ(据付時適格性評価)、OQ(運転時適格性評価)、 
PQ(性能適格性評価)を含まなければいけない。特に、データの品質やインテグリティにリスクが 
ある分野の試験をするために、固有の試験が計画されるべきである。 
・会社は、コンピュータ化システムがその使用目的に関して適格性が評価されていることを保証すべき 
である。従って、会社は、ベンダの適格性評価されたパッケージだけを信頼すべきではない;バリデー 
ション活動は、通常の使用と意図した使用が織り込まれた作業中にデータのインテグリティが維持される 
ことを保証するため、特定の試験を含むべきである。 
・試験の数は、リスクアセスメントにより導き出され、少なくとも重要な機能が特定されて試験されるべき 
である。例えば、基本的なアルゴリズムまたはロジックの組み合わせに基づくPLCやシステムの場合は、 
機能的試験が、コンピュータ化システムの信頼性を適切に保証するだろう。重要で、かつ/または、より 
複雑なシステムは、IQ、OQ,PQの段階において詳細の検証試験が必要とされる。 
4-期待を満たさない場合の潜在的なリスク/チェック項目 
・バリデーション文書がデータ・インテグリティに関する固有の条項を含んでいることを確認せよ; 
バリデーション・レポートは、データ・インテグリティの原則に対応し、設計と試験を通じて適切な管理 
が整っていることを示すべきである。 
・バリデートされていないシステムは、ユーザのアクセス権限やシステム設定がデータの修正を許す可能性 
があるので、データ・インテグリティに関して重大な脆弱性が存在するかもしれない。 
・エンド・ユーザの試験は、ソフトウエアがベンダの要件を満たすだけでなく、その意図した使用に合って 
いることを示すために設計されたテストスクリプトを含んでいることをチェックせよ。 
5-期待 
・コンピュータ化システムは、データ・インテグリティの管理を考慮した継続的なコンプライアンス状態に 
あることを保証するために定期的に評価されるべきである。評価は、逸脱、変更(変更の全ての蓄積され 
た効果を含む)、アップグレードの履歴、性能とメンテナンスを含むべきである。また、これらの変更が 
データ・マネジメントとインテグリティの管理に有害な影響を与えなかったかを評価すべきである。 
・再評価の頻度は、前回のレビュからシステムに対して実施された変更の累積的な効果を考慮し、 
コンピュータ化システムの重要性によるリスクアセスメントに基づくべきである。実施されたアセスメント 
は文書化されるべきである。 
5-期待を満たさない場合の潜在的なリスク/チェック項目 
・バリデーション・スケジュールの中に、コンピュータ化システムの再バリデーションのレビュの概要が 
述べられていることをチェックせよ。 
・システムが、特にデータ・インテグリティに関する全ての潜在的な脆弱性を考慮し、定期的なレビュの 
対象になっていることを確認せよ。 
・既存のソフトウエア/ハードウエアの制限などの、確認された全ての問題がタイムリーに対処され、確認 
された全てのリスクに対応するために是正処置・予防処置や暫定的な管理が実施されるべきである。 
6-期待 
・オペレーティング・システムとネットワーク部品はベンダの提案に従ってタイムリーに更新され、古い 
プラットフォームから新しいプラットフォームへのアプリケーションの移行は、システムにより生成された 
データのマネジメントとインテグリティに影響を与えうることになるプラットフォームがサポートされない 
状態になる前に計画され、実行されるべきである。 
・オペレーティング・システムとネットワーク部品のセキュリティ・パッチは、データの安全を維持するため 
に、ベンダの提案に従って、管理されたタイムリーな方法で適用されるべきである。 
・サポートされていないオペレーティング・システムが維持される場合、即ち、古いオペレーティング・ 
システムについて、ベンダもしくはサポートされたバージョンのセキュリティのパッチがあてられる期間が 
切れた後は、システム(サーバ)は、可能な限り、その他のネットワークから隔離されるべきである。 
残ったインタフェースと他の装置へ/からのデータの転送は、サポートされていないオペレーティング・ 
システムにより引き起こされる脆弱性の発生を防ぐために慎重に設計され、設定され、適格性を評価されな 
ければならない。 
・固有の脆弱性によりサポートがされていなシステムは、ネット経由でアクセス可能であるべきでない。 
6-期待を満たさない場合の潜在的なリスク/チェック項目 
・システムのアップデートは、管理されたタイムリーな方法で実施されていることを確認せよ。古い 
システムは、適切なデータ・インテグリティの管理が統合されて実施されていること、または(統合した 
管理が不可能な場合は)適切な管理が実装されていて効果的であることが十分にレビュされるべきである。

<システム間のデータ転送> 
1-期待 
・インタフェースは、正しく完全なデータの転送を保証するために、バリデーション中に評価され対処される 
べきである。 
・インタフェースは、データ・インテグリティのリスクを最小化するために、正しい安全なデータの入力と 
処理に関する適切な組み込みのチェックを含むべきである。検証方法は、下記の使用を含むとよい。 
○安全な転送 
○暗号化 
○チェック・サム(※データ通信におけるエラー検出方法の一つ) 
・可能であれば、システム間のインタフェースは、GxPデータの転送の自動化を含めて設計され、検証される 
べきである。 
1-期待を満たさない場合の潜在的なリスク/チェック項目 
・コンピュータ化システム間のインタフェースは、転送中に、データが気づかずに失われたり、間違って修正 
されたり書き換えられたりするリスクをもたらす。 
・データが安全な場所/データベースに直接転送され、ローカル・ドライブ(変更される可能性がある場所) 
から簡単にコピーされないことを保証せよ。 
・最終的なデータ保管場所またはデータ処理場所に転送される前のローカルなコンピュータ化システム 
(例:機器のコンピュータ)の一時的なデータ保管場所は、データが消されたり、改ざんされたりする可能性 
を作る。これは、スタンドアロン(ネットワークでつながっていない)システムの固有のリスクである。 
最初にデータが保管された環境は適切なデータ・インテグリティの管理が整っていることを保証せよ。 
・うまく設計され、適格性評価がされている自動データ転送は、人により実施されるいかなる手動データ転送 
より信頼できる。 
2-期待 
・システムのソフトウエアがインストールもしくはアップデートされた場合、ユーザは、アーカイブされた 
データが新しいソフトウエアで読めることを保証すべきである。このことは、存在しているアーカイブされ 
たデータを新しいフォーマットに変換することが必要になるかもしれない。 
・データが新しいソフトウエアの新しいデータ・フォーマットに変換が出来ない場合、古いソフトウエアは 
1つのコンピュータ内にインストールされ、査察時にアーカイブされたデータを読むためにバックアップ 
メディアとして利用可能でなければならない。 
2-期待を満たさない場合の潜在的なリスク/チェック項目 
・データのライフサイクルを通じて、データはそのもともとの形式で読めることが重要である。従って、 
ユーザは、データの可読性を維持しなければならず、廃止されたソフトウエアへのアクセスを保持すること 
が求められるかもしれない。

9.3 コンピュータ化システムのシステム・セキュリティ 
<システム・セキュリティ> 
1-期待 
・ユーザのアクセス権限は、データへの権限のないアクセスや変更や削除を禁止するために設定され、強化 
されなければならない。セキュリティ管理の範囲は、コンピュータ化システムの重要性による。例えば: 
-個々のログインIDとパスワードは、電子システムにアクセスし利用する必要のある全てのスタッフに設定 
され、与えられなければならない。共有されたログイン認証情報は、活動を行った個々のトレーサビリ 
ティのために、許されない。この理由から、経済的な節約のためであっても、共有パスワードは禁止され 
るべきである。 
-コンピュータ化された記録に対するデータの入力と変更は、許可された職員によってのみ実施されるべき 
である。会社は、使用中の各電子システムについて、アクセスを許可された個人と、彼らのアクセス権限 
のリストを保持すべきである。 
-システムが効果的に保護されていることを保証するために、パスワードのフォーマットと使用に関する 
適切な管理が行われるべきである。 
-はじめに許可されたシステムのアクセスに基づき、システムは、通常のパスワードのルールに従い、 
ユーザが新しいパスワードを作ることを許可しなければならない。 
-システムは、ユーザのさまざまなアクセスの役割(レベル)をサポートし、役割の割り当ては、最低限の 
特権付与のルールに従うべきである。すなわち、いかなるジョブの機能に対しても最低限必要なアクセス 
レベルを付与すること。最低限として、シンプルなシステムは、通常ユーザと管理ユーザを持つべきだが、 
より複雑なシステムは、通常は、アクセス管理を効果的にサポートするためにユーザにより多くのレベル 
が必要になるだろう。 
-GxPの重要なアプリケーションを運営するために、コンピュータシステムやインフラへの管理者のアクセス 
権限を許可することは、厳しく管理されるべきである。管理者のアクセス権限は、システムの通常のユーザ 
に与えられるべきではない。(職務の分離) 
-通常のユーザは、コンピュータシステムの重要な局面へのアクセス権限を持つべきでない。 
(例:システム・クロック、ファイルの削除機能等) 
-システムは、システムに実際にアクセスしたユーザの名前と役割を含むリストを作ることができるべきで 
ある。そのリストは、定期的なユーザのレビュ中に用いられるべきである。 
 -システムは、下記の情報を含んだ、ログインの試みの成功と失敗のリストを作ることができるべきである。 
○ユーザの名前 
○ユーザの役割 
○ログインを試みた日時 
○セッション(交信)の長さ(ログイン成功時) 
-ユーザのアクセス管理は、役割の厳格な分離を確実に行うべきである。すなわち、通常の業務を行う 
システムの全ユーザは、通常のアクセス権限のみを持つべきである。普通は、高いアクセス権限を持った 
ユーザ(例:管理者)は、システムで通常業務を実施すべきでない。 
-システム管理者は、通常、ユーザの実施する業務と独立し、生成されたデータに関与や関心を持ってはいけ 
ないし、電子システムを利用できてはいけない。例えば、QCの管理者やマネージャは、試験室の電子シス 
テム(例:HPLC、GC、UV-Vis)のシステム管理者に任命されるべきではない。通常は、品質や製造の組織 
の外部の人間(例:情報技術の管理者)がシステム管理者の役目を果たし、高度な許可レベルを持つべきで 
ある。 
-より小さな組織の場合、品質部門や製造部門で指名された人間がシステム管理者としてアクセス権限を持つ 
ことは許容してもよい。しかし、これらの場合、管理者のアクセスは、日常作業の実施に用いられるべき 
ではなく、ユーザは、第二の日常作業の実施用の制限されたアクセス権限を持つべきである。これらの 
場合、管理者の実施した全ての活動は、記録され、品質システム内で承認されるべきである。 
-新しいユーザ、新しいユーザの権限に関する全ての要求は、適切な職員(例:ラインのマネージャ、 
システムオーナ)に許可され、標準手順に従ってトレース可能な方法でシステム管理者に送付されなければ 
ならない。 
-GxPの重要なデータや作業にアクセス権限が与えられているコンピュータシステムは、事前に定義した時間 
よりも長い間不応のユーザを、アプリケーションまたはオペレーション・システムレベルでログアウトする 
非活動ログアウト機能を持つべきである。その時間は、通常は、長くするのではなく、システムへの権限の 
ないアクセスを防ぐために短く設定されるべきである。非活動ログアウトの有効化に加え、システムは、 
再ログインのために通常の認証手順を要求すべきである。 
1-期待を満たさない場合の潜在的なリスク/チェック項目 
・会社が、使用中のコンピュータ化システムが安全で、意図的またはうっかりした変更から保護されている 
ことを保証するためにあらゆる合理的なステップを踏んでいることをチェックせよ。 
・物理的かつ管理上保護されていないシステムは、データ・インテグリティの点で脆弱である。査察官は、 
コンピュータ化システムがバリデートされ、改ざんから保護された状態が保たれていることを保証する、 
システムのセキュリティを管理する検証された手順が存在することを確認すべきである。 
・一部のコンピュータ化システムは、単一ユーザのログイン、または、限定された人数のユーザのログイン 
のみをサポートしていることが認識されている。適切な代替のコンピュータ化システムが利用できない 
場合、サードパーティのソフトウエア、または、トレーサビリティ(バージョン管理と共に)を提供する 
紙ベースの方法による同等の管理を提供してもよい。代替システムの適合性は、正当化され、文書化され 
なければならない。ハイブリッドシステムについては、さらなるデータレビュが求められることがありうる。 
・査察官は、システムが適切なパスワードのルールを強制し、強固なパスワードを要求することを保証する 
ためにパスワードの方針が整っていることを確認すべきである。重要なデータを生成し処理するシステム 
には、より強固なパスワードを使用するための検討がなされるべきである。 
・ユーザによって新しいパスワードが変更できず、管理者のみがパスワードを作れるシステムは、パスワード 
の信頼性が保持できないので、データ・インテグリティに合わない。 
・ユーザのアクセスレベルが適切に定義され、文書化され、管理されていることをチェックせよ。ユーザの 
単一のアクセスレベルを使用し、この役割を全ユーザに割り当てることは、定義次第でアクセスレベルは 
管理者の権限になるので、容認できない。 
・許可された個人だけがシステムを使用でき、電子的に記録にサインし、操作を行い、入力または出力装置 
にアクセスし、記録を変更し、または手近で作業が行えることを保証するために、コンピュータシステム 
は管理者がチェックしていることを確認せよ。 
2-期待 
・コンピュータ化システムは、偶然の変更や意図的な改ざんから保護されているべきである。会社は、 
最終的にデータ・インテグリティに影響を与えうるバリデートされた設定に対する許可のない変更を防ぐ 
ためにシステムとその設計を評価すべきである。以下の考慮がされるべきである。 
-コンピュータ化システムのハードウエアの物理的セキュリティ 
-サーバの場所とアクセス制限 
-PLCモジュールへのアクセス制限(例:点検用パネルの錠締め) 
-コンピュータ、サーバ、メディアへの物理的なアクセスは、許可された個人に限定されるべきである。 
通常は、システムのユーザは、サーバやメディアに対するアクセス権限を持つべきでない。 
・ローカルや外部の攻撃からのネットワークシステムの脆弱性 
・リモートのネットワークの更新(例:ベンダによるネットワークシステムの自動更新) 
・システムの設定、構成、重要データのセキュリティ 
システムの重要なデータ/操作パラメータへのアクセス権限は適切に制限され、設定/構成の変更は、権限 
を与えられた職員による変更マネジメント手順を通じて管理されていなければならない。 
・システム時間は、接続するシステムの時計と同期され、アクセスは権限を与えられた職員に限定される 
べきである。 
・ファイアウォールは、重要なデータや作業を守るためにセットアップされていなければならない。ポート 
の開放(ファイアウォールのルール)は、可能な限り厳しくし、許可されたトラフィックのみを許可し、 
最低限の特権付与方針に基づくべきである。 
2-期待を満たさない場合の潜在的なリスク/チェック項目 
・ハードウエアとソフトウエアへのアクセスが適切に保護され、権限を与えられた職員に限定されている 
ことをチェックせよ。 
・適切な認証方法が実装されていることを確認せよ。これらの方法は、ユーザIDとパスワードを含んでいる 
か、他の方法でもよいが、認証が要求されなければならない。ユーザが確実に特定可能であることが必須 
である。 
・インターネット経由で利用できる重要なデータを含むシステムのリモートの認証については、パスコード・ 
トークンや生体認証の使用などの追加の認証が使用されていることを確認せよ。 
・システムの重要な操作パラメータへのアクセスが適切に管理され、システムが、GxPの手順に関する事象 
や設定の正しい順番を強制することを確認せよ。 
<ファイアウォールのレビュ> 
ファイアウォールのレビュ - 期待 
・ファイアウォールのルールは、許可されたトラフィックのみ許可し、必要であれば制限をかけるように 
設定されていることを保証するために、定期的なレビュの対象とされるべきである。レビュは文書化され 
ていなければならない。 
ファイアウォールのレビュ - 期待を満たさない場合の潜在的なリスク/チェック項目 
・ファイアウォールのルールは、通常は、時間と共に変化しがちである。(例:サーバのメンテナンスに 
よるポートの一時的な開放等) もしレビュが全くされなければ、ファイアウォールのルールは廃れ、 
望まれていないトラフィックや侵入を許すことになるだろう。 
3-期待 
・手書きサインの代わりに使用される電子サインは、記録に電子的にサインした職員の真正性とトレース 
の可能性を保証するために適切な管理がされなければならない。 
・電子サインは個々の記録と永久的に結びついていなければならない。すなわち、もし、サインされた 
記録に後で変更がなされた場合、記録は、修正を示し、サインされていないものとならなければならない。 
・電子サインが使用される場合、電子サインは機能的に、署名がされた日時を自動的に記録しなければなら 
ない。 
・電子署名のされたフォームの使用は、より一般的になってきている。(例:会社により、生体認証の使用 
はより普及してきている。電子署名のされたフォームの使用が促進されるはずである。 
3-期待を満たさない場合の潜在的なリスク/チェック項目 
・電子署名が適切にバリデートされ、職員に関する問題が管理され、いつも、電子署名が個人にすぐに 
帰属可能であることをチェックせよ。 
・電子署名がされた後のデータへの変更は、データが再びレビュされ、再度署名されるまでは、その 
電子署名は無効化されなければならない。 
4-期待 
・システム・セキュリティの理由で、クライアントコンピュータやGxPの重要なデータを持つサーバの 
USBポートは無効にされているべきである。必要な場合、ポートは、承認された目的のためだけに開放 
され、全てのUSBデバイスは、使用前に適切にスキャンされなければならない。 
・会社のクライアントコンピュータやGxPデータを持つサーバにおける個人用のUSBデバイスの使用 
(フラッシュデバイス、カメラ、スマートホン、キーボード等)、または、個人用コンピュータに 
おける会社のUSBデバイスの使用は許されるべきでない。 
4-期待を満たさない場合の潜在的なリスク/チェック項目 
・USBデバイスが、キーボードのような別の外部装置であることを装うことで、実行ファイルをスタート 
することができる脆弱性の知られたWindows環境では、これは特に重要である。

9.4 コンピュータ化システムの監査証跡 
<監査証跡> 
1-期待 
・コンピュータ化システムの調達と実装を行う時、データ・マネジメントとインテグリティの要件が考慮 
されるべきである。会社は、適切な電子監査証跡機能を含むソフトウエアを選択すべきである。 
・会社は、電子監査証跡機能を含むソフトウエアを実装するために、購入や古いシステムのアップグレード 
に努めるべきである。  
・一部のとてもシンプルなシステムは、適切な監査証跡機能が欠けていることが認識されている。しかし、 
データの正確性を立証するために、代わりの手順が実装されるべきである。(例:管理の手順、第二の 
チェックと管理) 
追加のガイドラインは、ハイブリットシステムに関する9.9章にある。 
・個々の手動の作業に関連する重要なデータの全ての変更と削除が記録され、ALCOA+の原則を満たすこと 
を保証するために、システムのバリデーション中に、監査証跡機能は検証されるべきである。 
・監査証跡機能はいつも使用可能で機能が固定されていなければならない。機能を停止させることが可能 
であってはならない。もし管理者ユーザが、監査証跡機能を停止させることが可能ならば、監査証跡が 
停止していることを示して自動入力がされるべきである。 
・会社は、リスクマネジメントの原則に従い、監査証跡のレビュに関する方針とプロセスの要点を述べた 
手順を実装すべきである。各操作に関する重要な監査証跡は、操作完了のレビュの前に、操作に関連 
する他の全ての記録と一緒に独立してレビュされなければならない。(例:ロットの出荷判定の前に、 
重要なデータとロットになされた変更が容認可能であることを保証する) このレビュは、データの 
発生した部署によって実施され、必要であれば品質部門により確認されるべきである。(例:自己査察 
または調査活動) 
1-期待を満たさない場合の潜在的なリスク/チェック項目 
・バリデーション文書は、監査証跡が機能的で、システム内の全ての活動、変更、その他のトランザク 
ションが全てのメタデータと共に記録されていることを示さなければならない。 
・監査証跡が定期的に(品質リスクマネジメントの原則に従って)レビュされ、矛盾は調査されている 
ことを確認せよ。 
・もし電子的な監査証跡システムがない場合、完全な監査証跡の(統合システムまたはバリデートされた 
インタフェースを使用した独立した監査ソフトウエア)システムが利用可能になるまで、データへの 
変更を示すための紙ベースの記録は容認される。これらのハイブリッドのシステムは、それらが、 
PIC/S GMPガイドラインのAnnex11に記述されているような、統合された監査証跡と同等である場合に 
認められる。 
・適切な監査証跡のレビュの不履行は、操作された、または、誤りのあるデータが品質部門及び/または 
オーソライズド・パーソンによりうっかり承認されうる。 
・どのデータが重要で、どの変更や削除が記録されるべきか(監査証跡)の明確な詳細が文書化されな 
ければならない。 
2-期待 
・監査証跡機能が利用可能な場合、電子ベースのシステムに関する監査証跡機能は評価され、監査の目的 
のために、データの収集、削除、上書き、変更に関するいかなる重要な活動も保存するために適切に 
設定されていなければならない。 
監査証跡は、重要なデータに関する、全ての手動で開始されたプロセスを記録するために設定されて 
いなければならない。 
・システムは、登録と電子記録の生成、修正、削除の活動の日時を独立して記録した、安全なコンピュ 
ータが生成したタイムスタンプのついた監査証跡を提供しなければならない。 
・監査証跡は、以下のパラメータを含んでいなければならない。 
 -誰が変更を行ったか 
 -何が変更されたか:新旧の値を含む 
 -いつ変更が行われたか:日時を含む 
 -なぜ変更が行われたか(理由) 
 -変更の権限を与えられた人物の名前 
・監査証跡は、電子記録の生成、修正、削除に関するイベントの経過の復元を可能にしなければならない。 
・システムは監査証跡を印刷し、電子コピーを提供できなければならない。監査証跡は、システムで見ても 
コピーで見ても意味がわかるフォーマットで利用可能でなければならない。 
・可能であれば、監査証跡は、コンピュータシステム内で動的な機能性を保つべきである。 
(例:検索機能、例えばExcelへのエクスポート) 
2-期待を満たさない場合の潜在的なリスク/チェック項目 
・全ての重要な情報と関連する情報が保存されることを保証するために、監査証跡のフォーマットを確認 
せよ。 
・監査証跡は、全ての前の値を含まなければならない。記録の変更で、前に記録された情報を不明確にして 
はいけない。 
・監査証跡は、正確な時間に、実際の活動の時間を反映して記録されるべきである。監査証跡に、複数の 
一連の作用に関し、同時に記録する、もしくは、全ての作用が完了した時に1つだけ記録するのは、特に、 
別々の作用、または一連の作用が重要な場合(例:4つの原料を1つの混合容器に追加する際の電子記録)、 
データ・インテグリティの期待に従っていないかもしれない。 
 もし、追加の順番が重要管理点(CCP)の場合、各追加は、タイムスタンプと共に個々に記録されなけ 
ればならない。もし、追加の順番がCCPでない場合、全4原料の追加は1つのタイムスタンプの活動と 
して記録することができる。

9.5 コンピュータ化システムのデータ収集/入力 
1-期待 
・システムは、方法が手動でも自動でも、正しいデータの保存のために設計されるべきである。 
・手動入力の場合: 
 -重要データの記録は、権限を与えられた個人によってのみされるべきで、システムは、個人の入力の 
詳細と、いつ入力されたかを記録しなければならない。 
 -データはソフトウエアで管理された特定のフォーマットで入力されていなければならない。バリデー 
ション活動では、正しくないデータ・フォーマットはシステムに受け入れられないことを確認すべき 
である。 
 -全ての重要データの手動入力は、第二のオペレータ、または、バリデートされたコンピュータ化された 
手段により、確認されるべきである。 
-入力の変更は監査証跡に保存され、適切に権限を与えられ独立した職員によりレビュされるべきである。 
・自動入力の場合: 
 -データの発生元であるシステムとデータの保存と記録をするシステムの間のインタフェースは、データ 
の正確性を保証するためにバリデートされるべきである。 
-システムによって保存されたデータは、改ざん、喪失、変更に対して脆弱でないフォーマットでメモリ 
に保存されるべきである。 
-システムのソフトウエアは、保存されたデータと、データに関連する全てのメタデータの完全性を保証 
するために、バリデートされたチェックを組み込むべきである。 
1-期待を満たさない場合の潜在的なリスク/チェック項目 
・コンピュータ化システムに手動でされた入力は、適切な第二のチェックを必要とする。 
・自動のデータ保存を使用しているシステムに関するバリデーションの記録は、データの検証とインテ 
グリティの方法が実装され、効果的であることを保証するためにレビュされるべきである。 
2-期待 
・データへの必要な変更はすべて、承認された手順に従って、承認され、管理されなければならない。 
・たとえば、試験結果の手動の積分や再加工は、承認され、管理された方法で実施されなければならない。 
会社の品質部門は、必要な時に指名された人によってのみデータへの変更が実施されることを保証する 
ための手順を制定しなければならない。オリジナルの(変更されていない)データは、そのオリジナル 
の形式で保存されなければならない。 
・オリジナルのデータに対するすべての変更や修正は、完全に文書化され、少なくとも一人の適切に訓練 
され、適格な個人によりレビュされ承認されなければならない。 
2-期待を満たさない場合の潜在的なリスク/チェック項目 
・データのいかなる修正や再加工も管理するための適切な手順が存在することを確認せよ。エビデンスは、 
提案された変更の正式な承認、管理された/制限された/明示された変更、変更の正式なレビュの適切な 
プロセスを示すべきである。

※9章の残りは、後ほど、ASTROM通信<162号>Part2で送信させていただきます。


◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇ 
★弊社サービスのご案内 
https://drmarketing.jp/cch/73/232/3/426/144184/c301a2

★ブログ毎日更新中! 
◆ PROS.社長の滋養強壮ブログ 
https://drmarketing.jp/cch/73/232/1/426/144184/4ecce6 
◆ プロス橋本のブログ 
https://drmarketing.jp/cch/73/232/2/426/144184/853970 
※URLクリック数の統計をとらせていただいております。

本メルマガは、名刺交換させていただいた方に、毎月1日、15日(土日祝日に重なった場合 は前日)に 
配信いたしております。 
今後このような情報が必要ない方は、お手数ですが、こちらに配信停止依頼のメールをお願いいたします。 
hashimoto@e-pros.co.jp

【発行責任者】 
株式会社プロス 
ASTROM通信』担当 橋本奈央子