レガシーシステムとは

医薬品業界や医療機器業界において、「レガシーシステム」という言葉を耳にする機会が増えている。とりわけFDA 21 CFR Part 11への対応において、レガシーシステムの扱いは企業にとって重要な課題となっている。経済産業省が2018年9月に公表した「DXレポート」は、基幹系システムが21年以上稼働している企業の割合が2018年時点の約2割から2025年には約6割へ増えると見込み、これを「2025年の崖」と呼んで警鐘を鳴らした。製薬・医療機器業界も例外ではない。本稿では、Part 11施行から29年が経過した現在において、レガシーシステムの定義、FDAの規制姿勢、そして実務上何をどこまでやれば当局に説明できるのかを、補完的統制の設計と退役時のデータ保存まで含めて解説する。

レガシーシステムとは何か

FDA規制における定義

レガシーシステムとは、FDA 21 CFR Part 11（電子記録・電子署名に関する規制）が施行された1997年8月20日以前から既に稼働していたコンピュータシステムを指す。

FDAが2003年8月に公表したガイダンス「Part 11, Electronic Records; Electronic Signatures — Scope and Application」は、Part 11の施行日前から稼働していたシステムを「commonly known as legacy systems（一般にレガシーシステムと呼ばれるもの）」と位置づけ、その扱いをSection III.C.3「Legacy Systems」で定めている。これらのシステムは、Part 11の要件が定められる前に設計・導入されたため、当初から規制要件を満たすことを前提として構築されていない。

具体的には、以下のようなシステムが該当する可能性がある。

• 1990年代に導入された製造実行システム（MES）で、電子署名機能を持たないもの
• 古い世代のクロマトグラフィーデータシステム（CDS）で、監査証跡機能が限定的なもの
• Part 11施行前に構築された品質管理データベースで、アクセス制御が現行基準を満たさないもの
• 製造支援設備（空調、製造用水製造設備等）に組み込まれた制御装置で、ログの保持期間が短いもの

「古い」ことと「レガシー」であることは同義ではない

ここで最初につまずきやすいのが、「古いシステム＝レガシーシステム」ではないという点である。FDAの文脈における「レガシーシステム」は、あくまでPart 11施行日という特定の日付を基準にした法的な区分であって、単に old という意味ではない。2005年に導入されて20年以上使い続けているシステムは、日常語としては十分に「レガシー」であるが、FDAの2003年ガイダンスがいう執行裁量の対象にはならない。Part 11は施行後に導入されたシステムには最初から全面適用されるからである。

したがって実務では、次の2つを混同しないことが出発点となる。

日本のIT全体の文脈

この問題は規制対応だけの話ではない。経済産業省の「DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～」（平成30年9月7日）は、既存システムの複雑化・ブラックボックス化を解消できなければ、システム維持管理費がIT予算の大半を占め、保守運用の担い手不在によってセキュリティや事故・災害のリスクが高まると指摘した。同省は2025年5月にも「レガシーシステムモダン化委員会総括レポート」を取りまとめており、レガシー脱却は国策レベルの課題として継続している。

規制産業においては、これに「記録の信頼性」という追加の制約が乗る。一般産業であれば「動いているうちは使い続ける」という判断もあり得るが、GxP領域では、動いていることと記録が信頼できることは別問題である。

技術的特徴

レガシーシステムには、技術的に以下のような特徴が見られることが多い。

• オペレーティングシステムが古く、現代のセキュリティ標準に対応していない
• 監査証跡機能が不十分、または全く存在しない
• 電子署名機能が未実装、または暗号化技術が旧式である
• ユーザー認証機構が単純で、多要素認証などに対応していない
• データのバックアップやリカバリー機能が限定的である
• 設計文書・要求仕様書が散逸しており、システムの挙動を説明する資料がない

FDAのレガシーシステムに対する規制姿勢

Part 11要件に対する執行裁量

FDAのレガシーシステムに対する姿勢を理解する上で最も重要なのが、2003年8月に公表された前掲の Scope and Application ガイダンスである（連邦官報での公表告知は2003年9月5日）。このガイダンスは現在も有効であり、FDAのPart 11に対する執行方針の基礎となっている。

このガイダンスにおいて、FDAは特定の条件を満たすレガシーシステムに対して「enforcement discretion（執行裁量）」を行使すると明記している。具体的には、以下の4つの条件をすべて満たす場合、Part 11のすべての要件について執行措置を取らないとしている。

1. 施行日前からの稼働そのシステムが施行日（1997年8月20日）以前から稼働していたこと。
2. 施行日前の述語規則適合施行日以前に、適用されるすべての述語規則（predicate rule）要件を満たしていたこと。
3. 現在の述語規則適合現在も、適用されるすべての述語規則要件を満たしていること。
4. 意図した用途への適合の立証そのシステムが意図された用途に適合していることの文書化された証拠と正当化があること（記録のセキュリティと完全性が許容水準にあることを含む）。

述語規則（predicate rule）要件は例外なく適用

重要なのは、Part 11の技術要件については執行裁量が適用され得る一方で、述語規則（predicate rule）の要件は一切免責されないという点である。

述語規則とは、Part 11以前から存在する基礎的な規制要件、すなわち医薬品のCGMP（21 CFR Part 210/211）、医療機器の品質システム規則（21 CFR Part 820）、GLP（21 CFR Part 58）、GCP（21 CFR Part 312/812等）といった電子記録という手段とは無関係に成立している規則群を指す。これらの規則は、記録の正確性、完全性、信頼性、そして査察時に利用可能であることを要求している。

例えば、1995年に導入された製造管理システムで記録された製造ロット情報が、現在も製品トレーサビリティの根拠として使用されている場合を考える。Part 11の電子署名要件については執行裁量が適用される可能性がある。しかし、CGMPが求めるデータの正確性、完全性、改ざん防止については、現行の基準で完全に遵守しなければならない。FDAは「古いシステムだから」という理由で、これらの基本的な品質要件を容認することは決してない。

システム変更時の注意点

1997年8月20日以降にシステムに変更が加えられ、その変更によって述語規則要件を満たさなくなった場合は、執行裁量の対象外となり、Part 11の管理策を完全に適用する必要がある。つまり、レガシーシステムであっても、大幅な改修を行った場合には、もはや「レガシー」としての特例的扱いを受けられなくなる可能性がある。

ここで実務上見落とされやすいのが、「変更していない」ことを証明できるかという論点である。1997年以降の30年近い期間に、OSのパッチ適用、サーバのリプレース、ネットワーク構成の変更、周辺機器の入れ替えが一度も行われていないシステムは現実にはほとんど存在しない。変更管理記録が残っていなければ、「施行日当時と同じ状態である」という主張自体が立証不能になる。

何が問題なのか——「古いから使えない」ではなく具体的に特定する

レガシーシステムの議論が空回りする最大の原因は、「古いから危ない」という漠然とした不安のまま議論が進むことにある。当局が問題にするのは古さそのものではなく、古さの結果として生じている具体的な統制の欠落である。したがって、まず何が欠けているのかを個別に特定しなければならない。

1. 監査証跡がない、または不十分である

最も頻繁に指摘されるのがこれである。21 CFR §11.10(e)は、セキュアで、コンピュータが自動生成し、タイムスタンプが付された監査証跡により、電子記録を作成・変更・削除した操作者の行為とその日時を独立して記録することを求めている。さらに、変更によって従前の情報が隠されてはならず、監査証跡は当該電子記録に求められる保存期間以上の期間保持され、当局の閲覧・複写に供せるものでなければならない。

レガシーシステムでよく見られる不十分な状態は次のとおりである。

• 監査証跡機能自体が存在しない
• 機能はあるが、管理者権限でオフにできる（そして実際にオフになっている）
• ログが上書き式で、一定期間経過後に自動で消える
• 「誰が」が記録されない（共有アカウントのため）
• 「なぜ変更したか」の理由が記録されない
• ログが人間に判読可能な形式に変換できない、または検索できない

なお、意図した変更と改ざんの線引きは、監査証跡の有無ではなく変更理由の記録と承認の有無で決まる。監査証跡は「線引きの材料を残す仕組み」であって、それ自体が善悪を判定するわけではない。

2. 個人アカウントがない（共有ID・共有パスワード）

21 CFR §11.10(d)はシステムへのアクセスを許可された個人に限定することを、§11.10(g)は許可された個人だけが署名・変更・操作を実行できることを確認する権限チェックを求めている。また§11.100(a)は、各電子署名は特定の個人に固有であり、他者に再利用・再割当てされてはならないと規定する。

共有アカウントの運用は、これらすべてに正面から抵触する。「operator1」というIDで複数名が交代で作業しているなら、監査証跡がどれほど詳細でも、記録を個人に帰属させることはできない。ALCOA+の最初の A（Attributable：帰属性）が原理的に成立しないのである。

電子署名まわりの要求事項については、電子署名の3つの明示事項、およびなぜ2人以上の共議が必要とされたのか（§11.200(a)(3)）もあわせて参照されたい。

3. OS・データベースのサポートが終了している

Windows Server 2008やOracle の旧バージョンの上で動いているシステムは珍しくない。サポート終了（EOL）そのものを直接禁じる規制条文はないが、問題は次の連鎖である。

• セキュリティパッチが提供されない → 既知の脆弱性が放置される
• 脆弱性が放置される → 記録の完全性を保証する根拠が失われる
• EU GMP Annex 11 第12項（Security）は、権限のある者にアクセスを制限する物理的・論理的統制を求めている。統制の実効性が失われれば、この要求は満たせない
• Annex 11 第11項（Periodic evaluation）は、コンピュータ化システムを定期的に評価し、バリデートされた状態が維持されていることとGMP適合を確認することを求めている。EOLはこの定期評価で必ず論点になる

つまり、EOL は「それ自体が違反」なのではなく、EOLの結果として他の要求事項を満たせなくなることが問題なのである。この因果関係を文書上で説明できるかどうかが分かれ目になる。

4. バックアップ・リストアが検証されていない

Annex 11 第7項（Data Storage）は、データを物理的・電子的な手段で毀損から守り、保存データのアクセス可能性・判読性・正確性を確認し、保存期間を通じてアクセスを確保することを求める。加えて、定期的なバックアップと、バックアップデータの完全性・正確性およびリストア能力をバリデーション時に確認し、その後も定期的に監視することを要求している。

実務でよくある不備は「バックアップは毎晩取っている」で止まっていることである。取得しているだけでは要求を満たさない。戻せることを試したか、その記録があるか、が問われる。PIC/S PI 041-1も、アーカイブしたデータを復元する手順を定め、その手順を定期的にテストすべきとしている。

システム障害時の代替手段の設計については、BCPの「第3形態」、用意できているかも参照されたい。

5. ベンダー支援が終了している

開発元が撤退している、担当技術者が退職している、ソースコードが失われている——こうした状態では、障害発生時に原因を特定できず、是正措置を計画することもできない。Annex 11 第3項は、第三者を用いる場合に責任範囲を明記した正式な取決めを求めているが、そもそも相手方が存在しなければ取決めのしようがない。

この場合、企業は自らがサプライヤの役割を引き受ける覚悟が必要になる。すなわち、システム記述書を自社で作成し、挙動を自社で説明し、障害対応手順を自社で用意するということである。これができないなら、そのシステムは実質的に「制御不能」であり、退役計画を立てる以外の選択肢はない。

欠落と規制要求の対応関係

リスクベースでの対処——4つの選択肢と求められる文書

リスク評価に基づく優先順位付け

FDAは、レガシーシステムに対してもリスクベースアプローチを適用することを推奨している。システムが古いという事実そのものではなく、そのシステムが製品品質や患者安全に与えるリスクの大きさに応じて、対応の優先順位を判断すべきという考え方である。Annex 11 第1項も、リスクマネジメントをライフサイクル全体に適用し、バリデーションとデータインテグリティ統制の範囲を、正当化され文書化されたリスク評価に基づいて決定すべきとしている。

高リスクなシステム、例えば無菌製剤の製造記録を管理するシステムや、臨床試験の重要なデータを扱うシステムについては、レガシーであっても早急な対応が求められる。一方、製造現場から離れた管理業務用のシステムであれば、相対的に優先度を下げることが可能である。

ただし、これは対応の優先順位付けを意味するものであり、最終的には述語規則要件を満たす必要があることに変わりはない。リスク評価を適切に実施し、そのリスクに見合った管理策を文書化し、正当化することが求められる。

4つの選択肢

ギャップを特定したあとに取り得る対処は、大きく4つに整理できる。どれを選ぶかは自由だが、選んだ以上は、その選択に対応する文書一式が必要になる。文書がなければ、どの選択肢も「何もしていない」と同義である。

実務の進め方

1. システム台帳を作るAnnex 11 第4.3項が求める「GMP機能を含む全関連システムの最新の一覧」を整備する。ここが空欄のままでは、そもそも何がレガシーなのかを議論できない。重要システムについては、物理的・論理的構成、データフロー、他システムとのインターフェース、前提となるハード／ソフト、セキュリティ対策を記したシステム記述書も必要になる。
2. ギャップ分析を行うPart 11の技術要件と述語規則の基本要件を分けて評価する。前者については執行裁量の適用可能性を検討し、後者については確実な遵守を確認する。この区別を曖昧にしたギャップ分析は、後で必ず破綻する。
3. リスク評価と優先順位付け患者安全への影響、製品品質への影響、当局の指摘を受けた場合の事業インパクトを総合的に考慮する。この評価は文書化し、「なぜこのシステムが意図された用途に適合しているといえるのか」を正当化する根拠とする。これは2003年ガイダンスの第4条件を満たすために不可欠である。
4. 段階的な改善計画を策定するすべてのレガシーシステムを一度に更新することは、資源やリスクの観点から現実的でないことが多い。短期は手順による管理強化と紙記録の併用、中期は部分的な機能強化や外部ツールとの連携、長期は新システムへの完全移行、という時間軸で計画を組む。
5. 継続的にモニタリングし、文書を維持する対策実施後も、述語規則要件が維持されていることを継続的に確認する。バリデーション記録、変更管理記録、定期レビュー記録を適切に維持することが、次回査察での説明材料になる。

補完的統制（compensating controls）の設計と限界

PIC/Sが示した基本姿勢

補完的統制を考えるうえで出発点になるのが、PIC/Sの「Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments」（PI 041-1、2021年7月1日発効）第9.1.4項である。同項は、規制対象ユーザーがコンピュータ化システムを設計・評価・選定する際にデータ管理と完全性の観点を織り込むべきとしたうえで、レガシーシステムも同じ基本要件を満たすことが期待されると明記している。そのうえで、完全な適合のためには、補助的な管理手順や補完的なセキュリティのハードウェア／ソフトウェアといった追加の統制が必要になり得ると述べている。

この一文の含意は重い。「機能がないから要件は免除される」とは書かれていない。「機能がないなら別の方法で同じ水準に到達せよ」と書かれているのである。補完的統制とは、この「別の方法」の総称にほかならない。

何をどこまで代替できるか

補完的統制の限界——ここから先は代替できない

したがって、補完的統制を採用する場合は、それが恒久的な解決ではなく期限付きの措置であることを計画書に明記すべきである。「補完的統制で運用しつつ、20XX年度にリプレースする」という記載があるかないかで、査察官の心証は大きく変わる。逆に、10年前から同じ補完的統制を「暫定措置」と呼び続けている状態は、それ自体が品質システムの機能不全とみなされる。

ハイブリッド運用は「解決策」ではない

電子システムと紙記録を組み合わせる「ハイブリッドシステム」は、レガシーシステム対応の定番手段である。しかしPI 041-1 第9.10項は、ハイブリッドシステムについて、その複雑さとデータ操作に対する脆弱性の高さゆえに追加の特別な統制が必要であり、その使用は推奨されず、可能な限り置き換えるべきであると明記している。

同項は、ハイブリッド運用を維持する場合に求められるものとして、次を挙げている。

• システム全体の詳細な記述書（主要構成要素、各要素の機能、データ管理・完全性の統制、要素間の相互作用）
• 手動系と自動系のインターフェースを管理する手順と記録。とくに、手作業で生成したデータの電子システムへの入力、自動生成データの紙記録への転記、印字データの電子システムへの自動読取り
• 転記後も原データを保持すること
• 電子データと紙データをどう突き合わせて1つの完全な記録を構成するかの指示、各系統の出力に対する承認の期待事項

「電子と紙の両方があるから安心」ではなく、「電子と紙の両方があるから接合部が弱点になる」というのが規制当局の見方である。この認識のずれは、実地査察でしばしば表面化する。

退役（decommissioning）とデータ保存——記録の寿命はシステムより長い

保存義務はシステムの寿命に縛られない

レガシーシステム対応で最も軽視されがちなのが、この論点である。記録の法定保存期間は、それを生成したシステムの耐用年数とは無関係に走る。システムを止めた瞬間に記録の保存義務が消えるわけではない。

21 CFR §11.10(c)は、記録を保存期間を通じて正確かつ迅速に検索できるよう保護することを求めている。§11.10(b)は、当局の閲覧・照査・複写に適した形で、人が読める形式と電子形式の双方において正確かつ完全な複製を生成できることを求める。監査証跡についても、§11.10(e)は対象電子記録に求められる期間以上の保持を要求している。

Annex 11 第17項（Archiving）は、アーカイブしたデータについてアクセス可能性・判読性・完全性を確認すべきとし、システムに関連する変更（機器やプログラムの変更）を行う場合には、データを取り出せることを保証し、かつ検証することを求めている。

可読性の確保——「ファイルは残っているが開けない」を防ぐ

PI 041-1 第9.9項は、この問題を具体的に描いている。同項は、保存データが完全に判読可能な形式でアクセスできるべきであり、企業は保存期間中、電子的に保存されたバックアップや複製にアクセスするために適切なソフトウェアとハードウェアを維持する必要があり得るとしている。さらに、ソフトウェアが新バージョンに更新されたり、より高性能なものに置き換えられたりした場合でも、バックアップデータは規制上の保存期間の全体にわたって読める状態でなければならないとする。

そして、長期的なデータアクセスに問題が予想されるためにシステムを退役させる場合には、アーカイブされたデータの継続的な可読性を確保する手順を定めるべきであり、その一例として他システムへのデータ移行を挙げている。

実務上の含意は次のとおりである。

移行時のデータ完全性の検証

Annex 11 第4.8項は簡潔だが決定的である。データを別のデータ形式やシステムへ移す場合、その移行過程でデータの値および／または意味が改変されていないことを、バリデーションの一部として確認しなければならないとする。

「値」だけでなく「意味」が明示されている点に注意したい。数値そのものが一致していても、単位の解釈、丸め規則、タイムゾーン、文字コード、区切り文字、空欄と0の区別、参照関係の切断などによって、意味は容易に失われる。移行検証は、件数の一致確認だけでは足りない。

PI 041-1 第9.9項も、更新・置換されたシステムに関連するデータが適切に管理されアクセス可能であることを確認すべきとしている。ISPEのGAMP 5 第2版にも「Appendix D7 – Data Migration」が置かれており、データ移行は独立した検証対象として扱われている。

廃棄計画書に何を書くか——厚労省ガイドラインの規定

日本では、「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」（平成22年10月21日 薬食監麻発1021第11号、平成24年4月1日適用）が、第8章「コンピュータシステムの廃棄」で退役時の要求を明文化している。同ガイドラインは、開発から検証、運用管理、廃棄までを通じてコンピュータ化システムのライフサイクルと位置づけている。

第8.1項は、廃棄計画書に原則として次を記載するよう求めている。

• 廃棄に関する責任体制と役割（組織、廃棄の責任者）
• 廃棄対象とするコンピュータシステム
• データの移行に関する事項
• セキュリティに関する事項
• 廃棄方法（リスクアセスメント、前提条件、スケジュール、ハードウェア／ソフトウェア／データ／文書類それぞれの具体的な廃棄方法）
• 廃棄完了の判断基準

第8.2項は、廃棄の責任者が廃棄計画書に基づいて廃棄を実施し、廃棄の記録を作成して保管することを求めている。「使わなくなったので電源を落とした」で終わらせてはならない、ということである。

なお、GAMP 5 第2版も第4.4節「Retirement」と「Appendix M10 – System Retirement」を設けており、退役はライフサイクルの正規のフェーズとして扱われている。退役は例外処理ではなく、計画された工程である。

日本の規制ではどう扱われるか

ER/ES指針とCSV適正管理ガイドライン

日本には、Part 11のような「施行日以前のシステム」という明示的なレガシー条項は存在しない。関連する枠組みは主に次の2つである。

既存システムの適格性をどう確認するか

CSV適正管理ガイドラインの発出通知は、適用日（平成24年4月1日）までの間について、旧「コンピュータ使用医薬品等製造所適正管理ガイドライン」を参考としつつ、可能なシステムから順次適用されるよう指導することを求めていた。段階適用を前提としていたわけである。

そのうえで、同日付の「質疑応答集（Q&A）」は、既存システムの適格性を確認する方法として、開発時の仕様書などの文書類・記録類に遡って適格性を検証する方法や、現在の使用目的に適合した要求仕様（またはそれに準じる文書）との適格性を確認する方法などが考えられる、と示している。要するに、過去に遡って証拠を集める道と、現在の要求仕様に対して今の状態を評価する道の両方があり得るということである。

後者は、実務上きわめて重要な選択肢である。20年前の設計文書が失われていても、「このシステムに現在求めている機能は何か」を要求仕様として今から書き起こし、それに対して現状が適合していることを確認・記録する道は残されている。バリデーションとベリフィケーションの違いを踏まえれば、これは未来形の保証ではなく現時点での確認であり、性質が異なる作業であることも意識しておきたい。

GAMP 5 第2版はレガシーをどう位置づけるか

ISPEが2022年7月に発行したGAMP 5 第2版には、興味深いことに「レガシーシステム」専用の付録は置かれていない。目次を通覧すると、レガシー問題に対応する道具立ては、独立した特例としてではなく、通常の運用・退役の枠組みの中に配置されていることがわかる。

ここから読み取れる思想は明快である。すなわち、既に稼働しているシステムに対して、後から「バリデーション文書一式」を作文して辻褄を合わせる（いわゆる遡及的バリデーション）のではなく、定期レビューによって現在の状態を評価し、ギャップを是正措置として処理し、以後の運用記録によって管理された状態を示す——という筋道である。

この考え方は、日本のCSV適正管理ガイドラインQ&Aが示す「現在の使用目的に適合した要求仕様との適格性を確認する」という道筋とも整合する。過去を捏造するのではなく、現在を正しく評価して、そこから先を管理する。これがレガシー対応の基本姿勢である。CSV／CSAの潮流全体については、ER/ES実践講座（第7回）続報——2008年のCSV課題は解決したかもあわせて参照されたい。

データインテグリティと今後の論点

規制当局の継続的な重視

近年、FDAをはじめとする規制当局は、データインテグリティ（データ完全性）に対する監視を強化している。FDAは2018年12月に「Data Integrity and Compliance With Drug CGMP: Questions and Answers」ガイダンスの最終版を公表し、CGMPにおけるデータインテグリティの重要性を明確化した。

さらに2024年4月3日には、BA/BE（生物学的利用能／生物学的同等性）試験に特化したドラフトガイダンス「Data Integrity for In Vivo Bioavailability and Bioequivalence Studies」が公表された。特定分野に限定されたものではあるが、FDAのデータインテグリティへの継続的な関心を示している。

臨床試験領域では、2024年10月2日に「Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers」が最終化され、2007年の「Computerized Systems Used in Clinical Investigations」に代わる文書となった。医療機器分野では2025年9月24日に「Computer Software Assurance for Production and Quality System Software」が最終化されている。Part 11そのものは1997年から実質的に変わっていないが、その周辺の運用ガイダンスは着実に更新されているという構図である。

レガシーシステムにおいても、データインテグリティの原則は等しく適用される。とくにALCOA+の原則は、システムの新旧を問わず遵守すべき基本要件である。

データの改変をどこから改ざんと呼ぶのかについては、改ざんの真の定義もあわせて参照されたい。

EU GMP Annex 11の改訂動向

現在有効なEU GMP Annex 11は2011年1月改訂版（適用開始は2011年6月30日）であり、本稿の引用もこれに基づく。一方、欧州委員会は2025年7月7日にAnnex 11の改訂ドラフトを公表し、同年10月7日までパブリックコメントに付した。ドラフトは分量が大幅に増え、サイバーセキュリティが独立の要求事項として盛り込まれるなど、内容が現代化されている。あわせて新しいAnnex 22（人工知能）およびChapter 4（Documentation）の改訂案も公表された。

レガシーシステムを抱える企業にとっての含意は明確である。要求水準は下がる方向には動いていない。「そのうち規制が緩むかもしれない」という前提で判断を先送りするのは、合理的な賭けとはいえない。

準備すべきこと

今後に向けて企業が準備すべきことは、以下のとおりである。

• 社内教育を実施し、レガシーシステムのリスクと述語規則要件の重要性について全社的な理解を深めること
• 2003年ガイダンスの内容を正確に理解し、執行裁量が適用される4条件を満たしているかを個別のシステムごとに確認すること
• システム台帳とシステム記述書を整備し、「何が、どこで、どのデータを扱っているか」を可視化すること
• データインテグリティの原則に基づいたシステム運用を確立し、文書化すること
• 補完的統制を採用する場合は、その有効性を定期的に評価し、期限を設けて恒久対策へ移行する計画を持つこと
• 退役とデータ保存の計画を、システムを止める前に立てておくこと
• 規制動向を継続的にモニタリングし、要求事項の変化に迅速に対応できる体制を整えること

完璧なシステムへの一足飛びの移行ではなく、述語規則要件を確実に満たしながら着実に改善を積み重ねることこそが、規制対応と事業継続の両立を実現する鍵となるであろう。技術の進化と規制要件の変化に柔軟に対応しながら、患者の安全性を守り続けることが、医薬品・医療機器業界に携わるすべての企業の責務である。