タイムカプセルアプローチとは

ある時点のシステム環境をまるごと「凍結」し、将来にわたってそのまま維持し続ける――本稿ではこの発想をタイムカプセルアプローチと呼ぶ。規制対象システムの現場では「査察に備えて環境を固めておく」という説明とともに、いまなお選択されることがある。しかし結論から述べれば、規制当局がシステム環境の凍結を求めた事実はない。むしろ現行および改訂作業中の規制文書は、変更管理と定期レビューを前提に「変わり続けながら妥当性を保つ」ことを求めている。本稿ではタイムカプセルアプローチの実体を定義し、その利点とされてきたもの、そして長期的な問題点と代替策を整理する。

タイムカプセルアプローチとは何か

本稿における定義

タイムカプセルアプローチとは、システムやアプリケーションを構築した時点の環境を、変更を加えずにそのまま保持し続ける手法である。まるで地中に埋めたタイムカプセルのように、特定の時点の状態を「凍結」して保存するイメージである。

凍結の対象となる要素

具体的には、以下のような要素を固定する。

• オペレーティングシステムのバージョン
• プログラミング言語やランタイムのバージョン
• ライブラリや依存パッケージのバージョン
• ミドルウェアやデータベースのバージョン
• 設定ファイルや環境変数

GAMP 5 第2版に「凍結」という概念はあるか

結論から言えば、ない。ISPE GAMP 5 第2版（2022年）の目次を見ると、運用フェーズに対応する附属書は次のように構成されている。いずれも「変更を止める」ではなく「変更を管理し続ける」ことを前提に置いた構成である。

GAMP 5 第2版は有償刊行物であるため本稿では逐語引用を行わないが、ISPEが公開している目次だけでも、この体系に「freeze（凍結）」という選択肢が正式な位置を与えられていないことは確認できる。凍結に最も近い正式概念は「廃止（Retirement）」と「アーカイブと検索（Archiving and Retrieval）」であり、いずれもシステムを止めたうえで記録の側を守るという発想である点に注意したい。この点はレガシーシステムとは、およびマイグレーションアプローチとはで扱った論点とも直結する。

どのような場面で用いられるか

タイムカプセルアプローチが選択される典型的な状況として、以下のようなケースがある。

• 規制対応システム
  金融機関や製薬会社などで、規制当局の査察や監査に対応する必要があるシステムである。これらのシステムには、保存義務期間（規制や記録の種類により数年から十数年に及ぶ）にわたり、記録を真正かつ読取り可能な状態で提示できることが法的に求められる。ただし後述のとおり、これは記録に対する要求であって、システム環境の凍結を求めるものではない。
• 長期保守契約システム
  顧客との契約で、特定のバージョンでの動作保証が求められるシステムである。バージョンアップによる動作変更が許容されない場合、タイムカプセルアプローチが選択される。
• レガシーシステムの延命
  すでに開発チームが解散し、技術的な知見が失われたシステムを、リスクを避けるために現状維持で運用し続けるケースである。

「凍結すれば査察に強い」という誤解

規制が求めているのは「記録」の保存であって「環境」の凍結ではない

米国の21 CFR Part 11は、閉鎖系システムの管理策として次を求めている。

§11.10(a) が求めているのはシステムのバリデーションであり、§11.10(c) が求めているのは保存期間を通じた記録の正確かつ迅速な検索可能性である。どちらも「当初の環境を変更してはならない」とは書いていない。守るべき対象は記録であって、記録を生んだ環境そのものではない。

この点はFDA自身がより明示的に述べている。2003年8月の最終ガイダンス「Part 11, Electronic Records; Electronic Signatures — Scope and Application」の記録保存に関する項では、次の趣旨が示されている。

つまりFDAは、元のシステムを生かし続けなくとも、中立的な形式に書き出して保存する道を認めている。「システムを凍結しなければ記録を守れない」という前提そのものが成り立っていない。

欧州側も同様である。EU GMP Annex 11（Computerised Systems、revision 1／2011年6月30日運用開始）の第17項「Archiving」は次のように定めている。

注目すべきは「If relevant changes are to be made to the system」（システムに関連する変更が行われる場合）という書き出しである。Annex 11は、コンピュータ機器やプログラムに変更が加えられることを当然の前提として置いたうえで、そのときに検索能力を保証し試験せよと求めている。「変更するな」ではなく「変更するなら取り出せることを試験せよ」である。

日本のER/ES指針（平成17年4月1日 薬食発第0401022号「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」）も、真正性・見読性・保存性の確保を求めるものであって、システム構成の凍結を求めるものではない。ER/ES指針をめぐる査察の現況はER/ES指針査察のいまで詳述している。

「バリデーション済み状態の維持」＝「変更禁止」ではない

誤解の根はここにある。バリデーション済み状態（validated state）を維持する義務を、「一切手を触れない義務」と読み替えてしまう運用である。しかし規制文書が用意しているのは、変更管理と定期レビューという継続的な仕組みである。

Annex 11は第10項「Change and Configuration Management」で、コンピュータ化システムに対するいかなる変更も、システム構成を含め、定められた手順に従い管理された方法でのみ行うべきであると定める。さらに第11項「Periodic evaluation」で、コンピュータ化システムは妥当な状態を保ちGMPに適合していることを確認するため定期的に評価すべきであると定める。第11項が評価対象として例示する項目には「upgrade history（アップグレードの履歴）」が明記されている。アップグレードが行われることが、規制側の想定にあらかじめ織り込まれているということである。

現在進行中のAnnex 11改訂ドラフトでは、この姿勢がさらに明確になっている。欧州委員会の意見募集（2025年7月7日〜2025年10月7日）にかけられたAnnex 11ドラフトは、第15章「Security」に次の条項を置いている（いずれも趣旨訳）。

また、改訂ドラフトは第3章「Pharmaceutical Quality System」において、コンピュータ化システムに対するいかなる変更も、構成・ハードウェア・ソフトウェア構成要素・プラットフォーム・OSを含め、管理された方法で定められた手順に従って行われること、そして製品品質・患者安全・データインテグリティに影響し得る重大な変更については再適格性確認およびバリデーションの対象とすべきことを求めている（趣旨）。「変更するなら再検証」であって「変更するな」ではないという構造が、ここでも明示されている。

検証範囲はリスクに応じて決める――CSAとリスクベースアプローチ

「セキュリティパッチを当てると全面的な再バリデーションが必要になる」という業界の通念も、規制側の現在の考え方とは一致しない。FDAは「Computer Software Assurance for Production and Quality Management System Software」（2026年2月3日発出。2025年9月24日発出の最終版を差し替えたもの）において、ソフトウェアの機能・用途ごとにプロセスリスクを判定し、リスクに見合った範囲でのみ検証労力を投入するという考え方を示している。同ガイダンスはこれを最小負担（least burdensome）のアプローチとして位置づけている。GAMP 5 第2版が採るリスクベースアプローチも同方向である。CSA・GAMP 5・データインテグリティの関係はER/ES実践講座 続報で整理している。

「凍結」で回避できると思われがちな作業と、実際には回避できない理由

タイムカプセルアプローチのメリットと問題点

タイムカプセルアプローチに一定の合理性があること自体は否定できない。ただしその利点はいずれも短期的・条件付きであり、対価が伴う。主張されるメリットと、それに対応する現実を対比する。

タイムカプセルアプローチの深刻な問題点

しかし、タイムカプセルアプローチには、長期的に見ると致命的な問題が存在する。

1. セキュリティリスクの増大

脆弱性への対応不可

ソフトウェアには常に新たな脆弱性が発見される。古いバージョンを使い続けることは、既知の脆弱性を放置することを意味する。特に深刻なのは、サポート終了後に発見された脆弱性である。これらは修正パッチが提供されないため、システムが攻撃に対して無防備な状態となる。

実例として、2017年5月12日から世界規模で拡散したWannaCryランサムウェアがある。米CISA（当時のUS-CERT）の警報が示すとおり、この攻撃はWindowsのSMBv1の脆弱性を悪用した。この脆弱性に対する修正プログラムはセキュリティ情報 MS17-010として2017年3月14日にすでに公開されていた。すなわち被害の決定的な要因は「古いこと」そのものではなく、公開済みの修正を適用していなかったこと――まさに「凍結」――であった。タイムカプセルアプローチの危険性を示す事例として読むべきは、この点である。

コンプライアンス違反のリスク

皮肉なことに、査察対応のために採用されたタイムカプセルアプローチが、セキュリティ基準を満たさないことで、別の規制上の問題を引き起こす可能性がある。近年、多くの分野でサイバーセキュリティ対策が規制要求に組み込まれており、古いシステムの継続使用が不適合とされる場面は増えている。

医薬品分野では、前掲のAnnex 11改訂ドラフト15.12・15.14が、サポート切れ・パッチ未適用のプラットフォームをネットワークから隔離すべき対象として明示している。医療機器分野では、FDAが市販前の要求として「Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions」（現行版は2026年2月3日発出。2025年6月27日版、さらにその前の2023年9月27日版を順次差し替えたもの）を、市販後については「Postmarket Management of Cybersecurity in Medical Devices」を置いている。後者はレガシー機器やサポート終了（end of support）を含む市販後の脆弱性管理を扱う。「凍結してあるから触れない」という説明は、これらの枠組みの下では成立しにくい。

すなわち、GxP文脈ではサポート切れのOS上で稼働する規制対象システムそれ自体が、査察指摘の対象になり得る。「ベンダーサポートが失われる」ことの帰結は、技術的な不便にとどまらないのである。

2. システムの陳腐化

技術的負債の累積

時間が経過するにつれ、タイムカプセル化されたシステムと最新技術との間のギャップは拡大し続ける。この技術的負債は、いずれシステムを更新する際に、莫大なコストと時間を要する原因となる。

例えば、2010年代初頭のPython 2.7環境をタイムカプセル化していた場合、Python 2が2020年1月1日をもってサポート終了（sunset）となった後、Python 3系への移行は単純なバージョンアップではなく、実質的な再開発となる可能性が高い。

新機能への対応不可

市場環境やビジネス要件は常に変化する。タイムカプセル化されたシステムは、新しい機能要件に柔軟に対応できないため、ビジネス競争力の低下につながる。

3. サポート終了という壁

ベンダーサポートの喪失

ほとんどのソフトウェアには「サポート終了日」が設定されている。この日を過ぎると、ベンダーからの技術サポート、セキュリティパッチ、バグ修正が提供されなくなる。特に問題なのは、依存関係にある複数のソフトウェアが、それぞれ異なる時期にサポート終了を迎えることである。エンタープライズ向けOSでは10年以上のサポートが提供される場合もあるが、多くのミドルウェアやライブラリはそこまで長期のサポートを受けられない。

インフラ環境の入手困難

古いバージョンのソフトウェアは、最新のハードウェアやクラウド環境で動作しないケースがある。物理サーバーの故障時に、同等の代替機を調達できない、あるいは仮想化環境への移行ができないといった状況に陥る可能性がある。凍結とは、この調達リスクを将来の自分に押し付ける行為でもある。

4. 人材確保の困難

スキルの陳腐化

古い技術に精通した技術者は、年々減少していく。特に若手エンジニアは最新技術の習得を優先するため、レガシーシステムの保守要員の確保が困難になる。1990年代までに構築されたCOBOLシステムを維持するために、退職した技術者を高い報酬で再雇用する事例も知られており、タイムカプセルアプローチの長期的なコストが想定以上に高額になり得ることを示している。

タイムカプセルアプローチの代替策

では、査察対応などの要件を満たしつつ、これらの問題を回避するにはどうすればよいか。以下の4つはいずれも単独の万能解ではなく、それぞれに留保がある点を含めて理解されたい。

1. バージョン管理と段階的更新完全な凍結ではなく、セキュリティパッチやマイナーアップデートは適用しつつ、システムの主要な動作を保証する検証体制を構築する方法である。これが規制文書の想定に最も素直に沿う。GAMP 5 第2版が Appendix S4（Patch and Update Management）と Appendix O6（Operational Change and Configuration Management）を用意しているのは、まさにこの運用のためである。検証範囲は変更の影響度に応じて決め、その判断根拠を文書化する。留保：この方式が機能するのは、影響度評価を行える力量と、リグレッションを検出できる試験資産が組織内にある場合に限られる。まずその整備が前提となる。
2. コンテナ技術の活用Dockerなどのコンテナ技術を用いて、特定の環境を再現可能な形で保存しつつ、ホストOSやインフラ層は最新化を続けるアプローチである。これにより、セキュリティリスクを低減しながら、アプリケーション層の安定性を維持できる。留保：コンテナ化そのものが「変更」であり、再検証の対象となる。実行基盤が変わる以上、Annex 11 第17項が求める「変更後の検索能力の保証と試験」も当然に適用される。また、コンテナイメージの中身が古いままであれば、そこに含まれるライブラリの既知脆弱性は温存される。イメージの更新とスキャンを運用に組み込まなければ、「凍結の入れ物を替えただけ」になる。
3. 査察用環境の分離本番環境は継続的に更新しつつ、査察や監査のための専用環境を別途維持する方法である。これにより、規制対応と技術的健全性の両立を図る考え方である。留保：この選択肢は安易に推奨できない。本番と異なる環境を当局に提示することは、提示された記録が本番の記録と同一であることを別途立証しなければならないことを意味する。データインテグリティの観点では、記録の同一性・完全性・監査証跡の連続性が新たな論点として発生し、二重管理の負担と齟齬のリスクを抱え込む。採用するのであれば、「本番記録の忠実な複製であること」を検証済プロセスとして担保し、その根拠を文書化しておく必要がある。分離すること自体が目的化した瞬間に、この手法は査察対応を有利にするどころか不利にする。
4. 段階的な刷新計画（期限と出口を決める）やむを得ず凍結する場合は、それを「一時的な措置」と明確に位置づけ、期限と刷新計画を策定する。例えば「査察終了後1年以内にシステム更新を完了する」といった具体的なロードマップを持つことが重要である。GAMP 5 第2版が Appendix M10（System Retirement）と Appendix D7（Data Migration）を置いているとおり、正規の出口は廃止と移行である。移行の設計についてはマイグレーションアプローチとはを、長期保存に固有の難しさについては電子記録の長期保存が困難な理由を参照されたい。

なお、製薬業界では従来のCSV（Computer System Validation）からCSA（Computer Software Assurance）への移行が進んでいる。CSAはリスクベースアプローチを強化し、高リスクの機能に検証を集中することで、文書化負担を軽減しながら患者安全と製品品質を確保する方向にある。この動きは、過度に保守的なシステム凍結から、適切なリスク管理を伴う継続的改善へのシフトを示している。

日本国内のGMP領域では「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」（平成22年10月21日 薬食監麻発第1021011号）が、開発・検証・運用・廃棄の各段階の管理を求めている。ここでも運用段階には変更管理・自己点検が置かれており、凍結という選択肢は用意されていない。また、レガシーシステムの妥当性をどう立証するかについては、PIC/S PI 011-3が第16章で回顧的（retrospective）な documentation による立証という道筋を示している。バリデーションという概念がそもそも何を守るために生まれたのかについては、バリデーション概念の歴史的背景で扱っている。

まとめ

タイムカプセルアプローチは、短期的には安定性やコンプライアンス対応の面でメリットがあるように見える。しかし、セキュリティリスクの増大、システムの陳腐化、サポート終了という避けられない問題により、長期的には組織に深刻なリスクをもたらす可能性が高い。

そして本稿が最も強調したいのは、その凍結を正当化する規制上の根拠は存在しないということである。21 CFR Part 11が守れと言っているのは記録であり、Annex 11が求めているのは変更管理と定期評価であり、FDAは中立的な形式へのアーカイブを容認している。「査察のために凍結する」という理由づけは、規制の要求ではなく、業界内で自己増殖した誤解である。

重要なのは、タイムカプセルアプローチを「最後の手段」として位置づけ、可能な限り代替策を検討することである。どうしても採用せざるを得ない場合でも、明確な期限設定と出口戦略を持ち、技術的負債の累積を最小限に抑える努力が不可欠である。

技術は常に進化し続ける。その流れに逆らって時を止めようとすることは、一時的な安心感と引き換えに、より大きな問題を先送りにしているに過ぎない。真の安定性とは、変化に柔軟に対応できる体制を築くことにあるのである。