マイグレーションアプローチとは

レガシーシステムから新システムへの切り替えにあたり、最後まで決着がつかないのが「過去のデータをどうするか」という問題である。とりわけGxP規制下の企業にとって、データ移行（マイグレーション）は単なるIT課題ではない。移行後も記録の完全性・可読性・検索性が保たれることは、21 CFR Part 11、EU GMP Annex 11、PIC/S PI 041-1、そしてQMS省令・GMP省令が明文で求めていることである。本稿ではマイグレーションアプローチの考え方を整理したうえで、メタデータと監査証跡は移行できるのか、移行をどう検証（バリデート）するのか、旧システムはいつ落とせるのかという、査察で必ず問われる三つの論点を実務目線で掘り下げる。

マイグレーションアプローチとは何か

定義と射程

マイグレーションアプローチとは、既存システムから新システムへデータを移行する際の戦略と手法の総称である。「マイグレーション（migration）」は「移行」を意味し、システムの更改に伴ってデータ、機能、インターフェースなどをどのように新環境に移し替えるかを計画的に進めるための方法論である。

従来のシステム更改では、最新のデータベース内容をコピーすれば足りると考えられていた時期もあった。しかし現代のシステム移行では、少なくとも次の三点を同時に満たす必要がある。

• データの完全性の維持――移行元と移行先でデータ構造が異なる場合でも、情報の欠落や意図しない改変がないことを保証しなければならない。
• メタデータと監査証跡の保持――「いつ、誰が、何を、なぜ変更したか」という履歴情報は、法令遵守とガバナンスの観点から値そのものと同等に重要である。
• 業務継続性の確保――移行期間中も業務を止めることなく、システムを稼働させ続ける必要がある。

なぜいま移行が問題になるのか

多くの企業が、2000年代から2010年代前半に構築した基幹システムやGxPシステムの老朽化に直面している。これらのシステムは当時の技術で構築されており、クラウド、SaaS、外部連携といった現代の要求に対応しきれない。他方でこれらのシステムには十年を超える期間にわたる記録が蓄積されており、単純に切り捨てることはできない。

PIC/S PI 041-1 も、この状況を正面から扱っている。第9.3項の期待事項では、オペレーティングシステムやネットワーク構成要素はベンダーの推奨に従って適時に更新すべきこと、そして旧プラットフォームがサポート切れの状態に達する前に、計画的にアプリケーションの移行を実施すべきことが求められている。サポートが切れてから慌てて移行するのは、この時点ですでに期待事項を外していることになる。

GxP領域では「IT課題」ではなく「規制課題」である

ここが一般のシステム移行との決定的な違いである。GxP規制下では、移行対象のデータは法令が保存を義務づけている「記録」そのものである。移行の失敗は業務上の不便では済まず、記録の欠落・改変として査察指摘の対象になる。したがってデータ移行は、情報システム部門だけの案件ではなく、品質保証部門が承認し、バリデーションの枠組みの中で実施すべき変更管理案件として位置づけなければならない。

「移行後も記録の完全性が保たれること」の規制上の根拠

21 CFR Part 11 ―― §11.10(a)(b)(c)(e)

FDAの21 CFR Part 11（Electronic Records; Electronic Signatures）は、データ移行という語を明示的に使ってはいない。しかし、閉鎖系システムの管理を定める§11.10の各号が、移行後の記録に対してそのまま適用される。条文は米国連邦規則集の公式電子版であるeCFRで確認できる。

この三つを移行の文脈に置き換えると、要求は次のように読める。

なお、FDAは2003年8月のガイダンス「Part 11, Electronic Records; Electronic Signatures ― Scope and Application」において、バリデーション、監査証跡、記録の保存、記録の複製、レガシーシステムの各領域について執行裁量（enforcement discretion）の方針を示している。ただしこれはPart 11の効力を失わせるものではない。同ガイダンスは、Part 11は引き続き有効であり、執行裁量はガイダンスで特定された範囲に限られると明記している。「レガシーだからPart 11は適用されない」という理解は誤りである。

EU GMP Annex 11 ―― 第4.8項が唯一名指しで移行を扱う

欧州のGMPガイドライン EudraLex Volume 4 の Annex 11「Computerised Systems」（revision 1、2011年6月30日運用開始）は、バリデーションの章の最後にデータ移行を名指しで置いている。

短い一文だが、ここには決定的な語が二つ入っている。「値（value）」だけでなく「意味（meaning）」も変わっていないことを求めている点である。数値としては同一でも、単位の定義、フラグの意味、コード値の対応表が変わっていれば、それは「意味」が変わった移行であり、Annex 11 第4.8項に照らして不適合となる。「数字は合っています」という検証だけでは足りない、というのがこの条項の核心である。

Annex 11 の関連条項もあわせて押さえておきたい。

第17項の「テストする（tested）」という語に注意したい。移行後に旧データを取り出せるはずである、では足りない。実際に取り出してみせた記録が求められている。

PIC/S PI 041-1 ―― 第9.4項と第9.9項

PIC/S PI 041-1「Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments」（2021年7月1日発効）は、データ移行をもっとも具体的に記述している文書である。該当箇所は第9.4項「Data Transfer」（項目名は “Data transfer and migration”）と第9.9項「Storage, archival and disposal of electronic data」である。

第9.4項――移行は文書化されたプロトコルに従って行う

さらに同項の期待事項2は、ソフトウェア（OSを含む）を導入・更新する場合、既存データおよびアーカイブ済みデータが新しいソフトウェアで読めることを利用者が確認すべきであり、必要に応じて既存アーカイブデータを新形式に変換すること、そして新形式への変換が不可能な場合は旧ソフトウェアを維持すべきこと（一台のコンピュータへの導入等の技術的解決、およびアーカイブ媒体の読み出し手段の確保）を求めている。調査が必要になったときにアーカイブデータを読めるようにしておくため、という理由も明記されている。

期待事項3はさらに踏み込む。レガシーシステムのソフトウェアがサポート不能になった場合、データへのアクセス目的でソフトウェアを（仮想環境で維持する等の方法により）できるだけ長く維持することを検討すべきであるとし、そのうえで次のように述べる。

ここは実務上きわめて重要である。PIC/Sは「動的データ機能を失う移行もあり得る」ことを条件付きで認めている。ただし条件は厳しい。(1) リスクとデータの重要性に基づく評価を行うこと、(2) 設定の不正変更やデータ操作に対する脆弱性もリスク評価で検討すること、(3) リスク低減のための管理策をすべて文書化し、その有効性を検証することである。「技術的に無理だったので静的PDFにしました」という記録だけでは足りず、なぜそれで許容できるのかを示した評価文書が必要になる。

第9.9項――保存には「全原データと関連メタデータ」を含める

同項の期待事項2は「記録保存手順にはメタデータを保持する規定を含めるべきである。これにより、将来の照会や調査においてバッチに関連して発生した活動を再構築することが可能になる」と述べる。ここに移行の合否基準がある。移行後のデータだけで当時の活動を再構築できるか――これが問われている。

また、リスク欄では「データの保存・バックアップ・アーカイブのシステムが、全データと関連メタデータを捕捉するよう設計されていることを確認せよ」「更新または置き換えられたシステムに関連するデータが適切に管理され、アクセス可能であることを確認せよ」という点検項目が明示されている。査察官はこの通りに見に来る。

GAMP 5 第2版の位置づけ

ISPEが2022年に発行したGAMP 5 第2版（A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition）では、データ移行が独立した付録として整理されている。目次上の該当箇所は次のとおりである（ISPE刊行物のため、内容の逐語引用は行わない）。

これら3つの付録は初版（2008年）にも置かれており、第2版でも構成が維持されている。第2版では、これに加えて分散台帳／ブロックチェーン（Appendix D10）、AI／機械学習（Appendix D11）、ITインフラストラクチャ（Appendix M11）、クリティカルシンキング（Appendix M12）といった付録が新設された。GAMP 5の基本思想であるリスクベース・スケーラブルなアプローチは移行にもそのまま当てはまる。すなわち、すべてのレコードを同じ厳格さで検証するのではなく、患者安全・製品品質・データインテグリティへの影響度に応じて検証の深さを変え、その判断根拠を文書化する。当社ではGAMP 5第2版とCSAをめぐる論点についても別稿で整理している。

日本の規制 ―― QMS省令とGMP省令

国内では、記録の管理と保管期限を定める条が移行の枠を決める。条番号はe-Gov法令検索で確認できる。

QMS省令（医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令）

この括弧書きこそ、データ移行に直結する国内の根拠である。「記録が作成された時点から不適切な改変がない状態を保つ」――移行はまさに、記録が作成された時点から時間が経ったあとに記録に手を触れる作業である。移行によって値・書式・関連づけが変わってしまえば、この条に照らして「不適切な改変がない状態」を維持したとは言えなくなる。

あわせて次の条を押さえる。

GMP省令（医薬品及び医薬部外品の製造管理及び品質管理の基準に関する省令）

GMP省令では、第20条（文書及び記録の管理）が中核となる。第1項第3号は、文書及び記録を作成の日（手順書等については使用しなくなった日）から5年間（当該記録等に係る製品の有効期間に1年を加算した期間が5年より長い場合は、教育訓練に係る記録を除きその期間）保管することを求めている。

そして2021年施行の改正で追加された第20条第2項が、データインテグリティ要求そのものである。あらかじめ指定した者に、(1) 作成・保管すべき手順書等および記録に欠落がないよう継続的に管理すること、(2) 作成された手順書等および記録が正確な内容であるよう継続的に管理すること、(3) 他の手順書等および記録の内容との不整合がないよう継続的に管理すること、(4) 欠落・不正確・不整合が判明した場合は原因を究明し、所要の是正措置及び予防措置をとること、(5) その他信頼性確保に必要な業務、(6) これらの業務に係る記録を作成し保管すること、を行わせなければならない。

データ移行はこの三つ（欠落・不正確・不整合）のすべてを一度に脅かす行為である。したがって移行時の検証は、GMP省令第20条第2項の履行そのものとして設計されるべきである。なお原薬たる医薬品に係る製品については、第22条（文書及び記録の保管）が第20条第1項第3号に代わる保管期間（リテスト日までの期間または出荷完了日から3年間のいずれか長い期間、あるいは有効期間＋1年）を定めている。改正GMP省令の全体像は「GMP施行通知」から改正GMP省令へで整理している。

ER/ES指針

電磁的記録を法定記録として用いる場合は、厚生労働省の「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」（平成17年4月1日 薬食発第0401022号）、いわゆるER/ES指針も適用される。真正性・見読性・保存性という三要件は、そのまま移行の受入基準に翻訳できる。ER/ES指針が査察の場でどう見られているかは別稿で詳述している。

移行の4類型と、それぞれの規制上の含意

マイグレーションの手法は、業界では一般に「ビッグバン型」「段階的移行（Phased Migration）」「Trickle Migration」などと呼ばれる。しかしGxP領域で意思決定するには、切り替えのタイミングではなく「原本（オリジナル）がどこに置かれるか」で分類したほうが実務に直結する。その観点から整理すると、選択肢は次の4類型に収まる。

① そのまま移す（完全移行）

すべてのデータを新システムに移行する、もっとも徹底したアプローチである。新システム上で全ての履歴情報にアクセスでき、システムが一元化されて管理がシンプルになり、利用者が複数のシステムを使い分ける必要がなくなる。反面、移行作業に要する時間とコストは最大となり、データ構造の変換に伴うリスクも高く、移行エラーが発生した場合の影響範囲が大きい。

実務上、完全移行を選択できるのは、データ量が比較的少ない場合や、新旧システムのデータ構造が近い場合に限られる傾向がある。

② 変換して移す（構造変換移行）

旧システムと新システムでは、データベースの設計思想が根本的に異なることが多い。旧システムが階層型データベースを採用している一方、新システムがリレーショナルデータベースを採用している場合、単純な一対一対応では移行できない。従来の会計システムや品質システムでは、取引データと監査証跡が別々のテーブルに格納されているケースがあり、新システムでこれらを統合的に管理する設計になっていれば、データの関連付けを再構築する必要がある。

この類型で決定的に重要なのがマッピング仕様書である。旧項目と新項目の対応、コード値の読み替え表、単位換算、桁数・型の変更、NULLや空文字の扱い、変換できない値の扱いを、移行前に一覧として確定し、品質保証部門の承認を得る。Annex 11 第4.8項が求める「意味が変わっていないこと」の証跡は、このマッピング仕様書とその検証結果である。

③ サマリーだけ移して原本は旧システムに残す

直近のデータのみを新システムに移行し、過去のデータは旧システムに残す、あるいは別途参照用システムを構築するアプローチである。移行対象データが限定されるため作業負荷が軽減され、新システムの稼働開始を早められ、移行リスクを段階的に管理できる。一方で、複数のシステムを並行運用する必要が生じ、利用者が参照先を使い分けることになり、システム全体の運用コストが増加する可能性がある。

④ 紙・静的ファイルに出力して保存する

過去データを一切移行せず、旧システムをアーカイブモードで残す、または静的形式に出力して保管する方法である。移行作業が最小限で済み、データの完全性を保ちやすく、移行に伴うリスクが最も低いという利点がある。反面、過去データへのアクセスが不便になり、長期的な保管コストがかかり、旧システムの保守体制を維持する必要が残る。

ただし規制の観点では、この類型がもっとも慎重な扱いを要する。紙やPDFへの出力は動的データを静的データに変えてしまうからである。PIC/S PI 041-1 は、元々動的な状態で取得された情報はその状態で利用可能であり続けるべきとしつつ（ALCOA+ の Original の要件）、技術的に不可能な場合には属性や動的機能を失う形式への移行があり得ることをリスク評価と管理策の文書化を条件に認めている。まず動的なまま維持できないかを検討し、できない理由を記録に残す――この順序を逆にしてはならない。

最大の論点 ―― メタデータと監査証跡は移行できるのか

値だけ移すとALCOA+の何が壊れるか

データ移行で実際にもっとも多く失敗するのが、この点である。移行ツールはテーブルの「値」を移すことは得意だが、監査証跡は別テーブル、別スキーマ、あるいはアプリケーション内部の独自形式で保持されていることが多く、標準の移行機能ではそもそも対象外になっていることがある。結果として「データは全件移行できました」という報告書が上がってくるが、実は監査証跡が一件も移っていない、という事態が起きる。

PIC/S PI 041-1 第7.4項・第7.5項が示す ALCOA+ の属性に照らすと、監査証跡を失った移行は次のように評価される。

要するに、値だけを移した移行は「移行」ではなく「要約の作成」である。これは第③類型（サマリー移行）を選んだのと同じことであり、その場合は原本たる旧システムを保存義務期間中維持しなければならない。移行方式の呼称と実態がずれたまま旧システムを廃棄してしまうのが、最悪のシナリオである。

監査証跡を移せないときの現実解

では監査証跡が技術的に移行できないとき、どうするか。実務では次の順で検討する。

1. ベンダーに移行仕様を確認する監査証跡テーブルのエクスポート機能があるか、あればどの項目が出るか（変更前値・変更後値・理由コードまで出るか）を、移行方式を決める前に確認する。ベンダー任せにせず、出力サンプルを実際に受け取って中身を確認する。
2. 新システムの「移行データ」領域に監査証跡を格納できるか検討する新システムの正規の監査証跡テーブルに旧システムの履歴を混ぜると、新システム自身の監査証跡の完全性が疑われる。参照専用の領域に分離して格納し、値レコードから辿れるようにする設計が実務的である。
3. 読み取り専用の形で外部保管する監査証跡をCSV等でエクスポートし、改変防止措置（書込禁止領域への格納、ハッシュ値の記録、アクセス制御）を施したうえで保管する。エクスポート物のハッシュ値を移行報告書に記載しておくと、後日の同一性証明に使える。
4. 旧システムを読み取り専用で維持する上記がいずれも不可能なら、PIC/S 第9.4項 期待事項2・3が示すとおり、旧ソフトウェアを（必要なら仮想環境で）維持する。この場合、維持している旧システムのバリデーション状態、アクセス制御、管理策の有効性検証を文書化することが同項で求められている。
5. 選択の根拠をリスク評価として残すいずれを選ぶにせよ、患者安全・製品品質・データインテグリティへの影響を評価し、残存リスクと低減策を文書化する。「技術的に無理だった」だけの記録では査察で持ちこたえられない。

どこまでのメタデータを移すのか

「メタデータをすべて移す」は理想だが、機械的に適用すると移行が破綻する。PIC/S PI 041-1 第9.9項のリスク欄は、この点について現実的な判断基準を示している。捕捉するメタデータの範囲はリスクマネジメントの原則に基づくべきであり、利用者は活動またはプロセスの再構築にとってクリティカルなメタデータがすべて捕捉されることを確保すべきである、というものである。

したがって移行計画の段階で、メタデータを次のように仕分けしておくとよい。

重要なのは、「移行しないもの」を移行計画書に積極的に列挙して承認を得ておくことである。後から「なぜこれは移っていないのか」と問われたとき、事前に判断していたことを示せるかどうかが分かれ目になる。

移行のバリデーション ―― 何をどう検証するか

移行の検証は、感覚的なサンプリングで済ませてはならない。次の各手法を組み合わせ、それぞれの合否基準を移行計画書に事前に定める。

1. 件数照合とコントロールトータル

もっとも基本的な検証である。テーブル単位・区分単位でレコード件数が一致すること、および金額・数量など加算可能な項目の合計値（コントロールトータル）が一致することを確認する。件数だけでは、同じ件数のまま内容が入れ替わっている異常を検出できないため、必ず合計値と併用する。

照合は全体の総件数だけでなく、区分ごとの内訳でも実施する。品目別・年度別・ステータス別など、複数の切り口で内訳が一致することを確認すると、特定条件のレコードだけが脱落する不具合（例：ステータスが「無効」のレコードが移行対象から漏れる）を検出できる。

2. チェックサム／ハッシュによる同一性検証

PIC/S PI 041-1 第9.4項が検証方法として明示的に挙げているのがチェックサムである。ファイル単位で移行する場合は、移行元ファイルと移行先ファイルのハッシュ値（SHA-256等）を突合し、ビット単位で同一であることを示す。データベース間の移行では、レコード単位またはブロック単位でハッシュを算出して突合する方法をとる。

ハッシュ値は移行報告書に記載しておく。これにより、後日「移行時点のデータと現在のデータが同一である」ことを証明する手段が残る。

3. サンプリング検証

全件を目視で確認することは現実的ではない。そこでサンプリング検証を行うが、「何件見れば十分か」を移行計画書で事前に定義し、その根拠を示すことが求められる。実務では次の3層構造で設計することが多い。

• 全数検証層――出荷判定記録、逸脱・CAPA記録、電子署名付き記録など、患者安全に直結する高リスクレコードは全数を機械的に突合する。
• 統計的サンプリング層――中リスクレコードは、あらかじめ定めた抜取方式（ANSI/ASQ Z1.4等の受入方式を援用する例が多い）でサンプルサイズと合格判定個数を決める。合格判定個数はゼロ（不適合が1件でも出たら不合格）とするのが原則である。データ移行に「許容できる不適合率」はない。
• リスクベース抽出層――統計的サンプリングとは別に、後述する境界値・特殊文字・異常値のレコードを意図的に抽出して検証する。ランダム抽出では引っかからない不具合はここで捕まえる。

4. 境界値・特殊文字・日付書式・文字コードの検証

移行の不具合は、平均的なレコードではなく端のレコードで起きる。次の観点を検証項目としてチェックリスト化しておくとよい。

5. 移行前後の再計算結果の一致

格納された値が一致しても、それが正しく使われるとは限らない。移行後のシステムで同じ計算・同じ判定を実行し、旧システムと同じ結果が得られることを確認する。具体的には次のようなものである。

• 同一の試験データに対して規格判定（適合／不適合）を再実行し、判定結果が一致すること。
• 同一期間・同一条件でトレンド分析や統計値（平均、標準偏差、Cpk等）を再計算し、結果が一致すること。
• 同一の検索条件で検索を実行し、ヒット件数と内容が一致すること。これはQMS省令第9条第4項が求める「検索することができる」の直接の検証にあたる。
• 同一のレポート・帳票を出力し、内容が一致すること（§11.10(b) の「人間が読める形式での正確かつ完全な複製」の検証）。

この検証は、単位の定義や丸め規則が変わってしまった移行を検出する唯一の実効的な手段である。Annex 11 第4.8項の「意味（meaning）が変わっていないこと」の証跡としても、これがもっとも説得力を持つ。

6. 逆方向の検証

移行元から移行先への突合（順方向）だけでは、移行先に余分なレコードが増えていることを検出できない。重複投入、テストデータの混入、リトライによる二重登録は実際に起きる。移行先から移行元への逆方向の突合も行い、移行先の全レコードが移行元に対応を持つことを確認する。

移行計画書と移行報告書に何を書くか

移行計画書の必須項目

PIC/S PI 041-1 第9.4項が「文書化されたプロトコルに従って」と明示している以上、移行計画書（マイグレーションプラン／プロトコル）は必須である。少なくとも次を含める。

1. 目的と適用範囲対象システム、対象データの範囲、対象期間、移行の類型（前掲の4類型のいずれか）を明記する。移行しないデータとその理由も明記する。
2. 規制要求とのひもづけ21 CFR §11.10(a)(b)(c)(e)、Annex 11 第4.8項・第7項・第17項、PIC/S PI 041-1 第9.4項・第9.9項、QMS省令第9条・第68条、GMP省令第20条など、該当する条項を列挙し、本計画のどの検証がどの条項に対応するかを示す。
3. 役割と責任移行実施者、検証実施者、承認者を分離して定義する。品質保証部門の承認を明示する。
4. リスクアセスメントデータの重要度分類、想定される移行リスク、低減策、残存リスクの受容判断。メタデータの仕分け（必須／重要／参考）もここに含める。
5. マッピング仕様旧項目と新項目の対応表、コード値変換表、単位換算、型・桁数の変更、NULL／空文字の扱い、変換不能値の扱い。
6. 移行手順とカットオフ実施手順、基準時点（カットオフ）、業務停止の要否、カットオフ後の更新の扱い、実施体制とスケジュール。
7. 検証方法と受入基準件数照合、コントロールトータル、チェックサム、サンプリング方式とサンプルサイズ、境界値・特殊文字等のテストケース、再計算検証、逆方向検証。それぞれの合否基準を数値で事前に定める。
8. 逸脱の扱い受入基準を満たさなかった場合の判定手順、逸脱管理・CAPAへの連結、再移行の判断基準。
9. 切り戻し（ロールバック）計画移行を中止する判断基準と、旧システムへ戻す手順。移行元データのバックアップとその検証。
10. 旧システムの取り扱い移行後に旧システムをどうするか（廃止／読み取り専用で維持／仮想環境で維持）、その期間、およびその期間の根拠となる保存義務期間。

逸脱の扱い

移行では必ず何かが出る。重要なのは、出たときの扱いを事前に決めておくことである。

• 受入基準を満たさなかった事象は、すべて逸脱として起票する。「移行ツールの仕様上、想定内だった」という説明で記録を残さないのが最悪の対応である。
• 逸脱ごとに、影響を受けたレコードの範囲を特定する。「何件が影響を受けたか」を示せない逸脱は、影響評価が完了していない。
• 是正の選択肢は、(1) 修正して再移行する、(2) 当該データは移行対象外とし旧システムに残す、(3) 現状のまま受け入れる、の三つである。(3) を選ぶ場合は、患者安全・製品品質・データインテグリティへの影響がないことの根拠を示し、品質保証部門の承認を得る。
• GMP省令第20条第2項第4号は、記録の欠落・不正確・不整合が判明した場合に原因を究明し、所要の是正措置及び予防措置をとることを明示的に求めている。移行時の逸脱はこの条の適用場面そのものである。

移行報告書に何を書くか

移行報告書（マイグレーションレポート）は、計画書に対する結果報告である。「移行は成功しました」だけの報告書は、査察で何の役にも立たない。次を含める。

• 実施日時、実施者、使用したツール・スクリプトとそのバージョン、実行環境。
• 移行元と移行先のレコード件数（全体および区分別）と、その一致の証跡。
• コントロールトータル、チェックサム／ハッシュ値の実測値。
• サンプリング検証の対象レコードの特定情報（何を何件見たか）と結果。
• 境界値・特殊文字・日付・文字コード等のテストケースごとの実行結果。
• 再計算検証・逆方向検証の結果。
• 発生した逸脱の一覧と、それぞれの影響評価・是正内容・判定。
• 受入基準に対する合否判定と、判定者・承認者の署名（日付を含む）。
• 旧システムの取り扱いの決定事項と、その保存義務期間の算定根拠。

実務上とくに有効なのは、移行報告書に「移行後の代表レコードのスクリーンショット（新旧並置）」を添付しておくことである。査察の場で、値・監査証跡・署名が新旧で対応していることを一目で示せる。

旧システムはいつ落とせるのか

保存義務期間から逆算する

もっとも多い誤解が、「新システムが安定稼働したら旧システムは落としてよい」というものである。判断基準は業務上の安定稼働ではなく、法定の保存義務期間と、原本がどこにあるかの二つである。

保存義務期間の算定は次のとおりである。医療機器ではQMS省令第68条により、記録は作成の日から、特定保守管理医療機器に係る製品は15年間（有効期間＋1年が15年より長い場合はその期間）、それ以外の医療機器等に係る製品は5年間（同5年より長い場合はその期間）保管する。教育訓練に係るものは5年間である。品質管理監督文書については第67条が、廃止の日を起算点として同様の期間を定めている。生物由来医療機器等については第79条（記録の保管の特例）により、厚生労働大臣が指定する期間の保管が求められる場合がある。

医薬品ではGMP省令第20条第1項第3号により、文書及び記録は作成の日（手順書等については使用しなくなった日）から5年間（有効期間＋1年が5年より長い場合は、教育訓練に係る記録を除きその期間）保管する。原薬たる医薬品に係る製品については第22条が、リテスト日までの期間または出荷完了日から3年間のいずれか長い期間、あるいは有効期間＋1年という別の算定を定めている。

読み取り専用での維持という選択

旧システムを落とせないと判明した場合、稼働時と同じ運用を続ける必要はない。読み取り専用（read-only）で維持するのが実務的である。この場合、次を整備する。

1. 書き込み権限の全面停止全利用者から更新・削除権限を剥奪し、参照権限のみを付与する。権限変更の記録を残す。データベース側でも読み取り専用モードに設定する。
2. アクセス制御と記録誰がいつ参照したかを記録する。Annex 11 第12.3項は、アクセス権限の作成・変更・取消しを記録すべきとしている。
3. ネットワーク分離サポートが終了したOSを使い続ける場合、PIC/S PI 041-1 第9.3項は、当該システム（サーバ）をネットワークの他の部分からできる限り隔離すべきであり、残るインターフェースと他機器とのデータ転送は脆弱性の悪用を防ぐよう慎重に設計・構成・適格性確認すべきとしている。リモートアクセスは脆弱性リスクの観点から慎重に評価すべきとも述べている。
4. 定期的な取り出しテストAnnex 11 第17項が求めるのは「取り出せることを確保し、かつテストすること」である。年1回など頻度を定め、実際に記録を取り出して可読性を確認し、その記録を残す。バックアップの復元テストも同様である（Annex 11 第7.2項）。
5. バリデーション状態の維持読み取り専用にしたこと自体が変更である。変更管理に乗せ、変更後の状態で必要な確認を行い、定期照査（Annex 11 第11項）の対象に残す。

仮想環境での延命

ハードウェアの故障や部品調達不能に備え、旧システムを仮想マシンとして保存する手法は、PIC/S PI 041-1 第9.4項 期待事項3が「仮想環境でソフトウェアを維持することにより達成し得る」と明示的に認めている。ただし同項のリスク欄は、ソフトウェアを仮想環境で維持する場合、当該ソフトウェアを管理する適切な措置（バリデーション状態、権限者によるアクセス制御等）が整っていることを確認すべきであり、すべての管理策は文書化され、その有効性が検証されるべきであるとしている。仮想化すれば自動的に要求を満たす、ということではない。

廃棄の記録

保存義務期間が満了し、旧システムを廃棄する段になったら、廃棄そのものを記録として残す。QMS省令第9条第2項は、記録の管理方法として「廃棄」についての手順を文書化することを明示的に求めている。廃棄の判断根拠（対象記録の範囲、保存義務期間の算定、満了日）、承認者、実施日、実施方法（媒体の物理的破壊、暗号化消去等）、実施の証明を残す。リーガルホールドがかかっていないことの確認も忘れてはならない。

移行と並行して検討すべき参照手段

なぜ参照手段の設計が要るのか

サマリー移行や旧システム維持を選んだ場合、過去データへのアクセス手段が課題として残る。旧システムを保管しておくだけでは、次の問題が生じる。

• アクセスの煩雑さ――利用者が新旧システムを使い分ける必要があり、操作習熟や問い合わせ対応の負担が増加する。査察の場で「その記録は旧システムにあります」と言ってから画面が出るまでに時間がかかること自体が、§11.10(c) の「速やかな検索（ready retrieval）」の観点で心証を悪くする。
• 検索性能の問題――旧システムは現代の検索技術に対応していないことが多く、大量の記録から特定の情報を探し出すことが困難である。QMS省令第9条第4項が求める「検索することができる」状態を維持できているかが問われる。
• セキュリティリスク――旧システムへの直接アクセスを広く許可することは、とくに保守が終了して脆弱性が放置されている場合、リスクとなる。

統合的な参照手段を設計する場合の考慮点

これらの課題に対し、新旧双方のデータを読み取り専用で統合し、単一のインターフェースから検索できるようにする手法がとられることがある。設計にあたっては次を考慮する。

• 読み取り専用であること――参照用システムから元データを更新できてはならない。参照用システム上のデータは原本ではなく複製であることを明確にし、原本の所在を利用者が判別できるようにする。
• 監査証跡も検索対象に含めること――値だけを検索できても、査察で問われるのは「誰がいつ変更したか」である。監査証跡が検索対象から漏れていると、参照用システムを作った意味が半減する。
• 参照用システム自体の監査証跡――「誰が、いつ、どのデータを参照したか」を記録する。参照用システムもGxPシステムであり、バリデーションの対象である。
• 取り込み時のデータ品質チェック――文字コードの不統一、欠損データ、フォーマットの不整合は検索精度に直結する。取り込みは実質的にデータ移行であり、本稿で述べた検証がそのまま適用される。
• 段階的な構築――一度に全期間を取り込むのではなく、直近数年分から始めて対象期間を拡大する方法が現実的である。
• 性能――大量の記録を実用的な速度で検索するには、適切なインデックス設計とキャッシング戦略が要る。初期構築時から性能試験を繰り返す。

移行プロジェクトの進め方

1. 現状分析と方針決定現行システムのデータ量、構造、法定保存要件を詳細に調査する。監査証跡・メタデータがどこにどの形式で保持されているかを、ベンダーに確認したうえで実データで裏を取る。そのうえで前掲の4類型のいずれを採るかを決定する。この段階で重要なのは「全てを移行する」という完璧主義にも「とりあえず動くものだけ移す」という近視眼にも陥らず、保存義務期間と原本の所在から逆算することである。
2. リスクアセスメントと移行計画書の作成・承認データの重要度分類、メタデータの仕分け、マッピング仕様、検証方法と受入基準を確定し、品質保証部門の承認を得る。ここを飛ばして作業に入ると、後から遡って計画書を作ることになり、バリデーションとして成立しなくなる。
3. パイロット（リハーサル）の実施限定的な範囲のデータで移行プロセスの実証を行う。移行ツールの性能、変換の精度、所要時間を測定し、本番計画に反映する。ここで境界値・特殊文字・文字コードのテストケースを流し切っておく。本番で初めて文字化けに気づくのは避けたい。
4. 本番移行の実行カットオフを設定し、移行元のバックアップを取得・検証したうえで実行する。実行ログを保全する。切り戻し判断の基準を手元に置いておく。
5. 検証と報告書の作成・承認計画書に定めた検証を実施し、結果を移行報告書にまとめて承認を得る。逸脱があれば逸脱管理・CAPAに連結する。
6. 旧システムの処置廃止するか、読み取り専用で維持するかを決定し、実行する。維持する場合は維持期間・アクセス制御・定期的な取り出しテストの計画を定め、定期照査の対象に載せる。
7. 運用開始後のモニタリング移行データの整合性の抜き取り確認、検索性能の監視、利用者からの申告の収集を継続する。移行直後には見つからなかった不整合が、数か月後の照会で表面化することがある。

今後の動向

EU GMP Annex 11 の改訂とAnnex 22

前述のとおり、欧州委員会はChapter 4・Annex 11の改訂案と新設のAnnex 22（Artificial Intelligence）について2025年7月から10月にかけて意見募集を実施した。改訂案は、コンピュータ化システムのライフサイクル管理全般に品質リスクマネジメントの原則を適用すること、要求仕様の定義と維持、サプライヤおよび外部サービス提供者の監督、データインテグリティ・監査証跡・電子署名・システムセキュリティの管理強化を打ち出している。本稿執筆時点で最終版は発出されておらず、現に有効なのは2011年6月30日運用開始のrevision 1である。移行計画を立てる際は、現行版を根拠としつつ改訂の方向性も視野に入れておきたい。

クラウドを前提としたアーカイブ

長期データ保管に特化したクラウドサービスの選択肢は広がっている。低コストでの大容量保管と、必要時の取り出しを両立させる設計のものが多い。ただしGxP文脈では、保管場所がクラウドであること自体よりも、Annex 11 第3項が求めるサプライヤとの正式な取決め（責任分界を明記したもの）と、取り出しテストが実際にできるかが問われる。取り出しに数時間から数十時間を要する低頻度アクセス階層に置いた場合、§11.10(c) の「速やかな検索」の観点でどう説明するかを事前に整理しておく必要がある。

移行支援における自動化・AIの活用

データ構造の差異を分析し、変換ルールの候補を提示するツールが実用化されつつある。従来は専門家の手作業に依存していたマッピング仕様の作成が効率化される見込みである。ただしGxPの観点では、提案されたマッピングを人が検証し承認するプロセスは省略できない。ツールの出力をそのまま採用してよいことにはならず、Human in the Loop の設計が必要になる。この論点はCSVとCSAをめぐる別稿でも扱っている。

改ざん防止技術

監査証跡の改ざん防止を強化するため、分散台帳（ブロックチェーン）技術を活用する研究開発が進んでおり、GAMP 5第2版でもAppendix D10（Distributed Ledger Systems）として付録が設けられている。もっとも、レガシーシステムとの統合の複雑さや性能上の課題もあり、GxP領域での本格的な普及にはなお時間を要すると見込まれる。当面は、エクスポートしたデータのハッシュ値を独立に保管する、書込禁止媒体を使う、といった枯れた手段のほうが実装しやすく、査察でも説明しやすい。