ASTROM通信バックナンバー
2023.01.01
【EU及びPIC/S GMP ガイドラインAnnex11改訂の動き】ASTROM通信＜２５７号＞
明けましておめでとうございます。
ASTROM通信担当の橋本奈央子です。
本年もよろしくお願いいたします。
2023年最初のメールマガジンは、前回のメールマガジンの冒頭で少し触れた、EU及びPIC/S の
GMPガイドラインAnnex11(コンピュータ化システム)の改訂にむけた動きを確認していきます。
現在Annex11は、改訂にむけてコンセプトペーパーのパブリックコメントが募集されています。
そこで、本メールマガジンでも、コンセプトペーパーのうち、改訂の理由や方向性、今後の
スケジュールが書かれた1章から4章を確認しておきたいと思います。
厚労省は、近年の医薬品の品質確保に対する国際的な動向の変化に対応し、品質確保の手法と
してPIC/S GMPガイドラインを活用する姿勢をとっています。
よって、もしこのコンセプトペーパーに書かれた方向に向かってAnnex11が改訂された場合、
輸出の有無に関わらず、どの製薬会社様にも影響のある大きな変化が生じる可能性があります。
最後までお付き合いいただければ幸いです。
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
GMPガイドラインAnnex11（コンピュータ化システム）改訂のコンセプトペーパー
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
〇１．序論
このコンセプトペーパーは、GMPガイドラインAnnex11(コンピュータ化システム)を改訂すると
いうニーズに対応している。Annex11は、欧州連合（EU）/欧州経済地域（EEA）の加盟国、PIC/S
に参加している当局に普及している。現バージョンは2011年に発出されたが、いくつかの分野に
おいて、十分なガイダンスを与えていない。現バージョンの発出以来、新しい技術の使用に
おいて広範囲な進展があった。
Annex11の改訂の理由は、これに限定されないが、以下に盛り込んでいる (優先順ではない)。
改訂のドラフトを作成しているグループはパブリックコメントを受け取り、より多くの改善が
必要であることがわかるかもしれない：
注１）文中の[]内には、関連する2011年版のAnnex11の章が書かれていて、［新］は今回新しく
検討されている内容です。
注２）文中の★補足★は、コンセプトペーパーの記載だけではわかりづらい部分について、
2011年版のAnnex11と比較して追記した内容です。
１．［新］EMA GMPウェブサイトのAnnex11のQ&Aとデータ・インテグリティのQ&Aの関連部分を
リプレイスするために文書は更新されるべきである。
２．［新］データ・インテグリティに関して、Annex11は『流れているデータ(data in motion)』
と『保存データ(data at rest)』（バックアップ、アーカイブ、処分）の要件を盛り込む
予定である。データ・インテグリティを支え、保護するために、強固な構成設定と統合
した管理が期待される;手動の管理に代わる技術的なソリューションと自動化が好ましい。
３．［新］規制上の期待から、文書の『デジタル・トランスフォーメーション（DX）』や同様の
新しいコンセプトへの最新化が検討される予定である。
４．［原則］範囲はコンピュータ化システムの“手動の作業のリプレイス”だけでなく“他の
システムや手動プロセスのリプレイス”も網羅する予定である。
★補足★2011年版の原則には、手動の作業をコンピュータ化システムにリプレイスする
場合、製品の品質、プロセスコントロ ールや品質保証を低下させたり、プロセスのリスク
を増加させたりしてはいけないとされていますが、改訂版ではシステムのリプレイスや
プロセスの変更にも適用される予定であると言っています。
５． [1章] ICH Q9への引用がされなければならない。
６． [3.1章] サービスのリストには、コンピュータ化システムの運用（例：『クラウド』サービス）
を含むべきである。
７．[3.1章]サービスプロバイダ（例：『クラウド』サービス）によりバリデート/運用されている
重要なシステムについては、”正式な契約が存在すること”以上でなければならない。
規制対象ユーザは、システムのバリデーションと安全な運用のために完全な文書にアクセス
しなければならず、査察中は例えばサービスプロバイダの助けを借りて、文書を提出できな
ければならない。
８．[3.3章] 用語集で言及されているにもかかわらず、既製ソフトウエア（COTS：commercial
off-the-shelf product）は適切に定義されていないし、あまりにも広い意味で簡単に理解
されているかもしれない。重要なCOTS製品は、それが”広い範囲のユーザ“により使用されて
いても、ベンダや規制対象ユーザにより適格性評価がされ、この文書は査察時に利用可能で
なければならない。適格性評価(Qualification)、バリデーション(Validation)、
（例：『クラウド』）のようなシステムの安全な運用に関する用語と期待は、明確にしな
ければならない。
９．[4.1章]バリデーション(と適格性評価)の言葉の意味は明確にされる必要がある。両方の活動は、
ユーザ要求仕様書（URS）または類似のものに記載された通りの必須の指定された機能の検証
から成ることが重要視されなければならない。
１０． [4.1章] リスクベースのアプローチに従い、システムの適格性評価とバリデーションは、
システムの重要な、GMPの判断をするために使用される部分、製品の品質とデータ・インテ
グリティを保証する部分、特別に設計されたりカスタマイズされたりした部分を特に確認
しなければならない。
１１． [4.4章] 何が「ユーザ要件は、ライフサイクルを通してトレースできなければならない」
という文は、十分に明らかではない。全ての実装されたり要求されたGMPの自動化された
重要な機能が述べられ規制対象ユーザが信頼しているユーザ要求仕様や類似のものは、
規制対象ユーザ／ベンダのどちらに実施されたかに関わらず、システムのいかなる適格性
評価やバリデーションの強固な基盤でなければならない。ユーザ要求仕様は、ライフサイ
クルを通じて更新され実装されたシステムと同調し、ユーザ要求、基礎となる機能仕様、
テストケースとのトレーサビリティが文書化されていなければならない。
１２． [4.5章] 今日のソフトウエア開発は、非常にしばしばアジャイル開発プロセスに従って
いることが認められ、対処されなければならない。また、従来の文書を構成しない、それら
の合格基準と対応する文書は明確にされるべきである。
１３．[6章] ガイドラインには、重要なデータと重要なシステムの分類が含まれなければならない。
★補足★2011年版の6章(正確性チェック)では、チェックの対象となる重要なデータや
リスク管理をすべきシステムの判断が明確になっていないため、そこを改善しようとして
いると思われます。
１４． [7.1章] システム、ネットワークとインフラは、GMPプロセスとデータ・インテグリティ
を保護しなければならない。データ・インテグリティの意図的・非意図的な喪失からデータ
を保護するために必要な物理的・電子的な方法の実例が含まれるべきである。
１５． [7.2章] バックアップからシステムデータの（そして、特に簡単に再現されないならば、
システムそのもの）リストアできる能力のテストは極めて重要であるが、この能力について
要求されている定期的なチェックは、バックアップやリストア手順に変更がなかった場合は、
必要とみなされない。揮発性媒体への長期のバックアップ（またはアーカイブ）は、
バリデートされた手順(例：加速試験を通じて)に基づかなければならない。この場合、
テストはバックアップがまだ読めるかを重視するのではなく、定められた期間で読めるかの
バリデートを重視すべきである。
１６． [7.2章] バックアップへの重要な期待が見当たらない。例：バックアップで何がカバー
されるか（データのみか、データとアプリケーションか）、どんなタイプのバックアップが
されるか(増分か、一式か)、バックアップがどれくらいの頻度でなされるか（すべてのタイプ）、
バックアップがどれくらい保持されるか、どのメディアがバックアップのために使われるか、
そして、バックアップがどこで保持されるか（物理的隔離）
１７． [8章]8章には、完全な監査証跡を含むデータが、電子的な形式で得られる期待を含めるべき
である。データを印刷する要件が再考されるかもしれない。
★補足★2011年版の8章(印刷物)は、電子的に保管されたデータを印刷できることを要求して
いますが、電子的に提出できることは要求されていません。
１８．[9章] ユーザ、データ、設定が手動で変えられるGMPの重要なシステム上で、全ての手動の
操作を自動的に記録する監査証跡機能は必須であり、リスクアセスメントに基づいて検討
されるべきでない。監査証跡機能のないシステムで電子データの処理、取込、保存または
転送は許容できない。この分野の全ての猶予期間は既に期限切れになっている。
★補足★2011年版の9章(監査証跡)では、監査証跡はリスクアセスメントに基づいて検討
されるべきとされています。
１９． [9章]監査証跡は変更を行ったユーザを確実に特定できなければならない。何が変更された
か一部始終が提供できなければならない。即ち、新しい値と全ての古い値は明確に目に見え、
変更がなされた全ての日付と時間を含み、空欄に値が入力された場合もしくは入力値が
完全に明らかな場合以外は、全ての変更は理由またはなぜ変更がなされたかの論理的根拠の
入力を促すべきである。
２０．[9章] 監査証跡データを編集したり、システムを操作している通常のユーザや特権的ユーザ
により監査証跡機能を無効化できたりしてはならない。もし無効化できるのであれば、
GMPの製造またはシステムの日常的な作業に関係していないシステム管理者のみアクセ
ス可能であるべきである。（『職務の分離』参照）
２１．[9章] 監査証跡レビュの概念と目的の記述が不十分である。レビュのプロセスは、システム
への手動の変更の完全性のレビュ（例えば、変更の理由の確認や、普通でない日時に、
普通でないユーザによって変更がなされたかどうか）に重点を置くべきである。
２２. [9章] 監査証跡のレビュの許容可能な頻度に関するガイドラインが提供されなければなら
ない。例えば無菌充填に関する差圧の警報を出すBMSシステムの警報の設定のような重要な
パラメータの監査証跡について、監査証跡のレビュは、リスクベースドアプローチに従って
バッチリリースの一部として実施すべきである。
２３. [9章] 監査証跡機能は、事象の完全で正確な状況を記録するために、十分詳細かつ実際の
時間と共に入力データを保存しなければならない。例えばシステムが、エラーメッセージを
出して、入力されたデータの不一致を規定されたユーザに通知し、その後ユーザが入力値
を変更し通知が消える場合、全てのイベントは記録されなければならない。
２４．[9章] 多くのシステムが膨大な量のアラームとイベントのデータを生み出し、さらに、
監査証跡の記録でしばしばごちゃごちゃになることに対応しなければならない。アラームと
イベントが自身のログ、承認、レビュを必要とする場合、システムの手動の操作の監査証跡
のレビュと混同されてはならない。そのため、最低でも、これらはソートできなければ
ならない。
２５．[11章] 構成設定のレビュの概念が追加されなければならない。システムの既知の変更回数
(アップグレードの履歴)をのはじまりをとらえる代わりに、ハードウエアとソフトウエア
の経時的な基準値の比較に基づくべきである。これは、全ての変更の説明と再適格性評価/
再バリデーションの必要性の評価を含むべきである。
２６. [12.1章] 現在の12.1章は、システムへのアクセスを許可された個人に制限することだけに
重点を置いているが、その他にも重要なテーマがある。ISO 27001に従って、ITセキュリティ
に関するセクションは、システムとデータの秘密性、完全性、利用可能性の視点も含むべき
である。
２７. [12.1章] 現在の12.1章は、「コンピュータ化システムのアクセスを許可された個人に制限
するために物理的・論理的な管理がととのっていなければいけない」と言っている。
しかし、もっと具体的で、例えば、多元的な認証、ファイアウォール、プラットホームの
管理、セキュリティパッチ、ウイルス・スキャン、侵入の検知／防止のようないくつかの
管理が必要である。
２８． [12.1章] 重要なシステムの認証は、規定されたユーザを高い確実性で識別すべきである。
したがって、落として誰かに見つけられることもありうる『パスカード』だけによる認証
は十分でないかもしれない。
２９. [12.1章] システムのアクセスの割り当てに関する2つの重要な期待、即ち、システムを
日常的に使用するユーザは管理者権限を持たない『職務の分離』と、業務の機能で必要な
もの以上のアクセス権を持たないという『最小の特権の原則』はあちこちに追加されるべき
である。
３０. [12.3章] 現在の12.3章は、「アクセス権限の付与、変更および取消は記録されるべきで
ある」と言っている。しかし、誰がシステムへのアクセス権を持っているかを単に記録
する以上のことが必要である。忘れられたアクセス権や、好ましくないアクセス権が確実
に取り除かれるためにシステムへのアクセス権や役割は、反復したレビュの対象とすべき
である。
３１. [17章] 7.2章で述べた通り、アーカイブされたデータのアクセス可能性、可読性、完全性
についてアーカイブされたデータを後でチェックしても十分ではない。（これらが維持
されていないとわかっても遅すぎる）そのかわりにアーカイブは、バリデートされた
プロセスに頼るべきである。使われる記憶媒体に応じて、一定期間後に媒体が読めること
をバリデートすることが必要かもしれない。
３２. ［新］産業界では既に実装している人工知能（AI）と機械学習(ML)モデルを、重要なGMP
のアプリケーションに使用することについての法的規制上のガイダンスと期待値が緊急
で必要である。最大の焦点は、モデルの選択、訓練、最適化のプロセスよりも、これらの
モデルをテストするために使用されるデータの妥当性、適切性、完全性と、それらの
テストから得られる結果（測定基準）が最大の焦点となるべきである。
３３. ［新］このコンセプトペーパーが起草され、EMA GMP/GDP査察官のワーキンググループと
GMDP調和に関するPIC/S小委員会の承認の準備が出来た後、FDAは
Computer Software Assurance for Production and Quality System Software (CSA) ガイダンス
のドラフトをリリースした。このガイダンス及び全ての関連事項はGMP Annex11の
法規制上の関連性の面で検討されるだろう。
〇２．考察
現在のAnnex11は対象とするいくつかの分野で十分なアドバイスを与えていない。また、GMPに
とって重要性を増してきているその他の分野を全く対象としていない。改訂される文書は、
ガイダンスを拡大し、既存のバージョンのリリース以降に躍進を遂げている新しい技術の活用を
受け入れるだろう。
可能なら、改訂文書は、重要なGMPのアプリケーションにAI/MLのアルゴリズムを使用すること
を受け入れるガイドラインを含むだろう。これは、製薬業界の既存の規制ガイダンスでカバー
されておらず、製薬会社が既にアルゴリズムを実装しているために、非常に必要とされている
分野である。
〇３．推奨
EMA GMP/GDP査察官のワーキンググループとGMDP調和に関するPIC/S小委員会は、共同で、
Annex11（コンピュータ化システム）の現バージョンがこのコンセプトペーパーにより改訂される
ことを推奨する。
〇４．提案されたタイムテーブル
コンセプトペーパーのドラフトの準備：2021年10月～
EMA GMP/GDP査察官のワーキンググループによるコンセプトペーパーのドラフトの承認：2022年10月
コンセプトペーパードラフトのコメント募集のためのリリース：2022年10月
コンセプトペーパーのコメントの締切：2022年12月(※実際には2023年1月16日になっています)
EMA GMP/GDP査察官のワーキンググループとPIC/S委員会のドラフトグループの検討：2023年3月～
ガイドラインドラフトのコメント募集のためのリリース： 2024年12月
ガイドラインドラフトのコメントの締切：2025年3月
EMA GMP/GDP査察官のワーキンググループによる適用：2026年3月
欧州共同体による公布：2026年6月
GMDP調和に関するPIC/S小委員会による適用：2026年9月
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
まとめ
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
いかがでしたでしょうか。
これまで、Annex11の漠然とした記述のせいで、
・QualificationとValidationの違いは何か？
・監査証跡のレビュはどれくらいの頻度で最低限何をしたらいいのか？
等、いろいろ頭を悩ませてきましたが、これは万国共通の悩みだったことがわかり安心しました。
コンセプトペーパーの通りにAnnex11の改訂が進んだ場合、製薬業界のコンピュータ化システムは、
アジャイル開発が可能になり、細かい機能単位に柔軟に設計→テスト→実装を行えるようになる
かもしれません。
また、バリデーションの観点で実装が難しいとあきらめてきた人工知能（AI）や機械学習（ML）
の活用が可能になるかもしれません。
そして、悩ましかったデータのバックアップとリストアの定期的なチェックは、そのプロセスに
変更がなければ不要という合理的な方向に向かうかもしれません。
柔軟な部分が生じる反面、これまでリスクに応じて対応すればよかった電子の監査証跡の対応が
必須になる可能性が高いです。また、昨今利用が拡大しているクラウドサービスの、わかりづらい
サービス内容を文書化する必要が生じる可能性があります。
2026年9月まで時間はありますが、場合によっては大きなインパクトがあるため、今後の動向には
十分注意が必要かと思います。
