ASTROM通信バックナンバー

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

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


今回は、前回に引き続き、2018年11月30日にPIC/Sから発出された、「GMP/GDP環境でのデータ管理と
インテグリティに関する適正管理基準のガイドラインのドラフト（PI 041-1 (Draft 3)）」の
9章の、コンピュータ化システムを使用したデータ・インテグリティについて取り上げているのですが、
非常に長いため、先ほどお送りした【PIC/Sデータ・インテグリティ関連ガイドラインドラフトについて(３)】
ASTROM通信＜１６２号＞Part1に引き続き、Part2を送付させていただきます。


◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
PIC/S　GMP/GDP環境でのデータ管理とインテグリティに関する適正管理基準のガイドラインのドラフト
GOOD PRACTICES FOR DATA MANAGEMENT AND INTEGRITY IN REGULATED GMP/GDP ENVIRONMENTS
PI 041-1 (Draft 3) 
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
9.6　コンピュータ化システム内のデータのレビュ
＜電子データのレビュ＞
１－期待
・規制を受けるユーザは、コンピュータ化システムにより生成された全てのGMP/GDPに関連する電子データ
  を確認し、データの重要性を確認するために、リスクアセスメントを実施しなければならない。一旦
  確認したら、重要なデータは、規制を受けるユーザによって監査され、作業が正しく行われ、
  変更（修正、削除、上書き）が電子記録上でオリジナルの情報に対して実施されたかどうかを判断する
  ために検証されなければならない。
・SOPは、どのデータが第二のオペレータによりいかにチェックされるかプロセスを述べなければならない。
  これらのSOPは、レビュされる重要なローデータ、データ・サマリのレビュ、関連するログブックや
  ハードコピーの記録のレビュの概要を述べ、いかにレビュが実施され、記録され、承認されるかを説明
  しなければならない。
・監査証跡のレビュは、承認プロセスの中の所定のデータレビュの一部でなければならない。
・監査証跡のレビュの頻度、役割と責任は、コンピュータ化システムに記録されたデータのGMP/GDPに関連
  する価値によるリスクアセスメントに基づくべきである。例えば、医薬品の品質に直接の影響を持つ
  電子データの変更に関しては、重大な決定（例：出荷判定）をするのに利用される前に、監査証跡の
  レビュが実施されることが期待されるだろう。
・規制を受けるユーザは、監査証跡をいかにレビュするか、何を探し、いかに検索するか等の詳細を述べ
  たSOPを制定すべきである。手順は、監査証跡のレビュを担当した職員が従うべきプロセスを詳細に決定
  すべきである。監査証跡のレビュ活動は、文書化され、記録されるべきである。
・監査証跡のレビュ中にみつかった、全ての期待される結果からの重大なばらつきは、完全に調査され
  記録されなければならない。手順には、監査証跡のレビュで、医薬品の品質やデータのインテグリティ
  に影響を与えうる重大な問題を確認した場合に取られるべきアクションを記載しなければならない。
１－期待を満たさない場合の潜在的なリスク/チェック項目
・電子データがその重要性（製品品質及び/または意思決定への影響）に基づいてレビュされていること
  を保証するための手順をチェックせよ。各レビュのエビデンスは記録され、査察官が利用可能でなけ
  ればならない。
・データ・サマリが内部または外部の報告のために使用される場合、それらのサマリがローデータと一緒
  に確認されたことを示すためのエビデンスが利用可能でなければならない。
・いかに第二のレビュや監査証跡のレビュが実施され、もし一連のレビュ中に問題がみつかった場合、
  どんな手順がとられるかをまとめた詳細のSOPを規制を受ける団体が持っていることをチェックせよ。
・グローバルなシステムが使用される場合、記録が同時に行われたことを示すために、タイム・ゾーン
  の記録を含む日時の記録が必要になるかもしれない。
・知られたデータに対する変更、修正、削除が、監査証跡機能により実際に記録されていることを
  チェックせよ。
２－期待
・会社の品質部門は、重要性とシステムの複雑性に基づき、継続的に監査証跡のレビュを実施するため
  の計画とスケジュールを制定すべきである。これらのレビュは会社の自己査察プログラムの中に組み
  込まれていなければならない。
・手順は、監査証跡の矛盾に対応し調査するために整っていなければならない。必要な場合、経営陣や
  国の当局に知らせる上申プロセスも含んでいなければならない。
２－期待を満たさない場合の潜在的なリスク/チェック項目
・自己査察プログラムは、存在している管理の効果とデータのレビュに関する内部手順に従っている
  ことを確認するために、監査証跡のチェックを含んでいることを確認せよ。
・監査証跡のチェックは、ランダム（偶然に選択される）なものと、的を絞った（重大性やリスクに
  基づき選択される）ものの両方でなければならない。

9.7　電子データの保管、アーカイブ、廃棄
１－期待
・データの保管は、安全でバリデートされた手順を使い、監査証跡を含む完全なオリジナルのデータと
  メタデータを含んでいなければならない。
・もしデータがバックアップされたり、コピーが作られたりする場合、バックアップやコピーも、
  データに対する許可されないアクセスや変更、削除や修正を禁止するための、オリジナルの保管と
  同じ適切な管理レベルをもっていなければならない。例えば、携帯用のハードドライブにバックアップ
  をとる会社は、そのハードドライブからデータを削除することを禁止しなければならない。データの
  保管とバックアップに関するいくつかの追加で考慮すべきことには以下のことが含まれる：
  -動的電子記録の真正なコピーは、全ての内容（すなわち、全てのデータとメタデータが含まれる）と
   オリジナルの記録の意味が維持されているという期待と共に作成することができる。
  -保管されたデータは完全に判読可能なフォーマットでアクセスできなければならない。データの
   保持期間中、電子的に保管されたデータのバックアップやコピーにアクセスするために、会社は、
   適切なソフトウエアとハードウエアを保持する必要があるかもしれない。
  -定期的なバックアップのコピーは、災害に備えて、離れた場所（物理的に離れている）に保管され
   なければならない。
  -バックアップデータはソフトウエアが新しいバージョンに更新されたり、より性能のよいバージョン
   に置き換えられたりしても、定められた法的な保持期間中はずっと、判読可能でなければならない。
  -システムは、メタデータと監査証跡を含む全てのデータのバックアップとリストアが可能でなけれ
   ばならない。
１－期待を満たさない場合の潜在的なリスク/チェック項目
・データのストレージ、バックアップ、アーカイブのシステムは、全てのデータとメタデータを保存
  するために設計されていることをチェックせよ。これらのシステムがバリデートされ、検証されて
  いることを示す文書化されたエビデンスがなければならない。
・廃止された、またはアップグレードされたシステムに関連するデータは適切に管理され、アクセス
  可能であることをチェックせよ。
２－期待
・記録の保持手順は、メタデータを保持する対策も含まなければいけない。これは、将来の問合せや
  調査のために、ロットに関して発生した活動を復元することを可能にする。
２－期待を満たさない場合の潜在的なリスク/チェック項目
・なし
３－期待
・データは、書かれた手順に従って定期的にアーカイブされなければならない。アーカイブのコピー
  は、バックアップとオリジナルデータが保管されている場所から隔離されて離れた場所で物理的に
  保護されていなければならない。
・アーカイブのすべての期間中、データはアクセス可能で判読可能で、そのインテグリティが保持
  されていなければならない。
・調査で必要とされた場合に備えて、アーカイブデータのリストアに関する手順が存在していなけ
  ればならない。アーカイブデータのリストア手順は、定期的に試験されなければならない。
・アーカイブのプロセスに関して設備が必要であれば、意図的またはうっかりした変更や喪失からの
  保護を保証するために、特別な環境管理や、許可された職員のみのアクセスが実施されなければ
  ならない。データへの長期のアクセスの問題が想定されるために設備内のシステムを廃棄しなけ
  ればいけない場合、手順は、アーカイブされたデータの継続的な判読可能性を保証しなければ
  ならない。例えば、データを別のシステムに転送する手段が制定されるかもしれない。
３－期待を満たさない場合の潜在的なリスク/チェック項目
・ソフトウエア・アプリケーションの更新や装置の廃棄により、データへのアクセスと判読可能性
  が失われる可能性があるので、アーカイブされたデータにはリスクがある。会社がアーカイブ
  されたデータにアクセスできて、アーカイブされたデータのレビュを可能にする必要なソフトウエア
  へのアクセスを保持していることを確認せよ。
・データのアーカイブに、外部やサードパーティの設備が利用される場合、これらのサービスプロバイダ
  はアセスメントが必要であり、全ての責任は、品質技術契約の中に記録されていなければならない。
　アーカイブされた記録のインテグリティを保証するための考慮がされていることを確認するために、
  契約とアセスメントの記録をチェックせよ。
４－期待
・コンピュータ化システムによって生成された全てのデータ（メタデータを含む）の判読可能で意味
  のある記録のプリントアウトが可能でなければならない。
・記録に対して変更がなされた場合、いつ、どのようにオリジナルのデータが変更されたかを示す記録
  の変更がプリントアウトできなければならない。
４－期待を満たさない場合の潜在的なリスク/チェック項目
・判読可能で完全な記録の生成に関してシステムがバリデートされたことを保証するために、システム
  のバリデーション文書をチェックせよ。
・プリントアウトのサンプルが確認されるかもしれない。
５－期待
・電子的に保管されたデータの廃棄に関するプロセスが記述された手順が整っているべきである。
  これらの手順はデータのアセスメントに関する手引きとデータの保持期間を提示し、また、もはや
  必要でないデータの廃棄の方法を記述しなければならない。
５－期待を満たさない場合の潜在的なリスク/チェック項目
・手順が明確にデータの廃棄の条件を規定し、そのライフサイクル中に必要なデータのうっかりした
  廃棄を避けるための対策が講じられていることをチェックせよ。

9.8　ハイブリッドシステムの管理
１－期待
・ハイブリッドシステムは、システムの複雑さと、潜在的に増加するデータの改ざんに対する脆弱性
  を反映して、特別の追加の管理が必要である。
・ハイブリッドシステムの各要素は、手動とコンピュータ化システムに関するガイダンスに従って、
  適格に管理されているべきである。
・システムに適用される管理方法の効果の評価、定義、証明をする場合、適切な品質リスクマネジ
  メントの原則に従うべきである。
・システムの主要な構成要素、各構成要素の機能、データ・マネジメントとインテグリティの管理、
  システムの構成要素の相互作用の方法の概要を述べたシステム全体の記述が利用可能でなければ
  ならない。
・手動と自動のシステム間のインタフェースを管理し、適切にコントロールするために、手順と記録
  が利用可能でなければならない。特に以下に関連する手順を含めよ：
　-手作業で生成されたデータのコンピュータ化システムへの手動の入力
　-自動化されたシステムにより生成されたデータの紙の記録への転記（手動を含む）
　-プリントされたデータの自動検知と、コンピュータ化システムへの転記　
１－期待を満たさない場合の潜在的なリスク/チェック項目
・ハイブリットシステムが明確に定義されて識別され、システムの各要素がバリデートされている
  ことをチェックせよ。
・手動とコンピュータ化システムの間のインタフェースに対する注意が払われていなければならない。
  査察官は、システム間で手動の転記が行われる場合、適切な管理と第二のチェックが行われること
  を確認せよ。
・転記や加工の後に、オリジナルのデータは、保持されているべきである。
・ハイブリッドシステムは、一般に、コンピュータ化システムと手動のシステムの組み合わせから
  なっている。以下のことを確認するために特別な注意が払われるべきである：
  -コンピュータ化システムの適格性評価　及び/または バリデーションの範囲
  -手動のプロセスの一貫した適用の難しさによる、ハイブリッドシステムの手動の要素のマネジ
   メントに適用される管理の強固さ


◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
まとめ
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
いかがでしたでしょうか。

私は、久しぶりに、 “データフローマップ”や“システム台帳”という言葉を見て、メンテンナンスが
気になりました。厚労省のコンピュータ化システム適正管理ガイドラインが発出された頃は、これらの
文書の作成やメンテナンスに注意を払っていたのですが、昨今は新しい要件のほうに目がいってしまって
いるということはないでしょうか。

それ以外に、下記の点について、へー！と思い、対応状況の確認が必要であると感じました。
１．オペレーティング・システム（OS）やネットワーク部品のセキュリティ・パッチの適用や更新は、
    ベンダの提案に従いタイムリーに行うべきであること
    →＜ポイント＞ベンダの提案を前提としていること
２．セキュリティのためのUSBポートの管理が明記されていること
    →＜ポイント＞ポートの管理や、USBメモリの使用の制限
３．管理者権限を持ったユーザは、システムで通常業務を実施すべきではない
　　もし、するのであれば、日常作業用にアクセス権限の制限されたアカウントを作るべきであること
    →＜ポイント＞実際には、システム管理者が日常業務を行っているケースもあると思いますが、
      管理業務と通常業務でアカウントを分けほうがいいということ
４．ファイアウォールのルールをレビュすべきであること
    →定期点検等に織り込む必要があること
５．ユーザレビュのために、ログインの成功/失敗、ログイン成功時のセッションの長さ（接続時間）の
    リストが求められていること
    →ユーザレビュのためのリストの準備
６．監査証跡のレビュは、定期的に実施するだけでなく、承認プロセス中や、重大な決定の前にもされる
    べきであること
    →監査証跡は、定期的な実施だけでなく、日々の業務内でも必要であること

皆様も是非参考にしてみていただければと思います。

☆次回は、2/1（金）に配信させていただきます。


◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
おしらせ
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
弊社は、今年も、2月20日（水）～2月22日（金）に開催される医薬品・化粧品・洗剤 研究・製造技術展
インターフェックス大阪（会場：インテックス大阪）に出展します。
ブースは、１号館【３－１８】となります。
お時間がおありの方は、是非弊社ブースにお立ち寄りいただければ幸いです。
よろしくお願いいたします。


◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
★弊社サービスのご案内 
https://drmarketing.jp/cch/73/233/3/426/146792/4fc12f

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


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

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

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

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

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

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

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

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

※9章の残りは、後ほど、ASTROM通信＜１６２号＞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通信』担当　橋本奈央子