第6回：CSVの維持と継続的改善

全6回にわたる本連載も、今回がいよいよ最終回です。これまで、CSVの基礎から計画、性能適格性評価（PQ）、そして成果物となる文書の管理について解説してきました。

コンピュータ化システムバリデーション（CSV）の主たる活動としてシステム導入時のプロジェクトフェーズを中心にお話をしてきましたが、CSVにおいて最も重要なのは「システムを稼働させた瞬間」ではありません。もちろん、プロジェクトフェーズの締めくくりとしてのシステムリリースは重要ではありますが、システムの稼働開始後、数年、十数年と使い続ける中で、ビジネスニーズの変化、規制要件の更新、技術の進歩、あるいは運用中に発見される不具合などの波を乗り越え、「バリデートされた状態（妥当性が確認された状態）」を維持し続けるという「ライフサイクル管理」にこそ、真の価値があります。

最終回となる今回は、本連載の締めくくりとして、システムの稼働後の「運用フェーズ」に焦点を当て、バリデートされた状態をいかにして維持し続けるか、その戦略と実務の要点を深掘りします。

 

画像

 

システムは一度稼働すると、多くの場合、機能追加、性能改善、セキュリティパッチの適用、OSのアップデート、ハードウェアの交換など、様々な変更が発生します。これらの変更がシステムのバリデーションステータス（妥当性が確認された状態）に影響を与えないよう、適切に管理するプロセスが「変更管理（Change Control）」です。変更管理が不十分だと、どのような経緯でリリース時点からの変更を重ねたのかを把握できず、結果的に知らぬ間にシステムの品質や規制適合性が損なわれる「サイレント劣化」を招くリスクがあります。

プログラム（ソースコード）自体の修正を伴う機能の変更は、大きな変更だと見なされる一方、変更管理において特に関係者が陥りやすい落とし穴が、プログラム修正を伴わない「構成設定（設定値）の変更」を軽視してしまうことです。

• 設定変更の影響: 例えば、ワークフローの承認ルートの変更、計算式の係数の微調整、データ入力時の必須チェックの有効化/無効化などは、システム画面上の設定変更だけで完了するものもありますが、その影響は機能の変更と同等、あるいはそれ以上の場合もあります。
   
• 構成設定管理の重要性: これらの設定変更が、URS（ユーザー要求仕様書）で定義した「意図した動作」を逸脱させないか、あるいはデータインテグリティを損なわないか、事前に影響評価を行う必要があります。何の評価や根拠もなく、「設定を変えるだけだから再テストは不要」という判断は、リスクの発生要因となります。

変更管理は単に変更点を記録するだけではありません。どのような変更であっても、その影響を十分に精査しないと、システムが「いつの間にか意図しない状態」に変質する場合があります。これを防ぐため、以下のステップを変更管理SOP（標準作業手順書）として確立することが望ましいです。

• リスクと再検証範囲の評価: ラベル文字列の修正といった軽微な設定変更であれば限定的な確認で済みますが、基幹機能に及ぶ変更（メジャーバージョンアップ等）の場合は、直接の変更箇所でない部分までを含む広範囲な回帰テスト（リグレッションテスト）が必要となります。こうした点を踏まえ、影響評価及びテスト計画は変更管理プロセスの中で行うようにし、評価の結果は変更管理の記録とともに文書として残すようにします。
   
• 文書の同期: システムの変更に合わせて、FS、DSといった設計文書や構成設定仕様書、操作マニュアル等の関連文書を遅滞なく改訂し、常に「現実のシステム」と「文書による定義」を一致させる必要があります。SaaSの場合、設計系の文書の改訂はベンダーのタスクですが、機能の変更に伴って操作手順が変わるようであれば、SOPやマニュアル類を改訂します。ここに乖離があると、文書の資産価値はなくなってしまいます。
   

目立った変更やトラブルがなくても、システムは時間の経過とともに「論理的劣化」を起こす可能性があります。運用環境の微細な変化や、ユーザーの慣れによる手順の形骸化など、システムそのものは変更がなくとも、導入当初のバリデーションステータスが維持できなくなる要因は多岐にわたります。そのため、業務を含めたコンピュータ化システムの「健康診断」である自己点検と、その結果に対する定期的なレビューの実施が不可欠です。

システムの利用や運用管理がSOPに則って正しく行われているかを確認する自己点検は、システムの重要度（クリティカル性）や、過去に発生した逸脱の有無に応じて、数か月から最長で1年程度の周期で計画します。点検にあたっては、一般ユーザーの利用におけるSOP遵守の確認に加え、特に運用保守の観点から、以下の点を中心に確認します。

• 保守点検状況の確認: 運用保守業務の一環として、不要ユーザーアカウントの無効化や監査ログの確認が、長くとも月次程度のスパンで行われていることを実施記録と月次報告で確認します。必要に応じて、「データの削除」「システム設定の変更」「時刻の修正」といった管理者権限（特権ユーザー）での意図せぬ操作が行われていないか、不自然な動作や、理由のない設定変更がないかといったイレギュラーなシステム操作に対する監査ログの点検を自己点検の一環として盛り込みます。
   
• バックアップ・リストアの「実効性」の検証: 自己点検の頻度では、「バックアップ完了ログ」を確認するに留まらず、実際にデータが復元できるか（リストアテスト）の確認を含めます。併せて、新たに追加された機器やフォルダがバックアップ対象から漏れていないかも確認対象とします。アーカイブの場合は、アーカイブしたデータが正しく読み出せるかどうかを点検することも重要です。
   
• 構成管理（インベントリ）の整合性: バリデートされた導入当時の構成（OSバージョン、パッチ、接続機器）から、未承認の変更が行われていないか、設定が一致しているかを確認します。構成設定の定義外で、許可されていないソフトウェアのインストール形跡がないかもチェックします。
   
• 障害・逸脱と変更管理の紐付け: 発生したシステムエラー（障害）が適切に報告され、その修正や対応が「変更管理SOP」に従って行われ、影響評価の結果に応じて再バリデーションが実施されているかという、プロセスの「一貫性」を確認します。

運用の記録や自己点検の結果を取りまとめ、業務も含めたコンピュータ化システムとして、バリデートされた状態が今も保てているか、といった視点で総合的に判断します。この結果から、不足のある点、予見される脆弱性に対する対策を、次期の運用計画に盛り込みます。技術面、セキュリティ面といった現場の管理者やシステムオーナーの判断を要するレビューから、人的リソースやコストの生じる対策への判断が必要となる経営者層が関与するマネジメントレビューまでを階層的に行うのが望ましい形です。

• 逸脱・障害履歴の傾向分析: 過去の不具合記録を見返し、特定の機能に逸脱や不具合が集中していないか、あるいは再発している問題がないかを確認します。構成設定や利用手順に逸脱を誘発する原因がないか探索的に検討し、可能であれば設定変更や手順書改訂などの措置を行います。ハードウェア老朽化の兆候があれば、デバイス等のリプレースを検討します。
   
• 運用プロセスの適格性評価: 取りまとめた自己点検の結果を俯瞰的に確認し、一般ユーザーのシステム操作や運用保守業務がSOPに基づき的確に行われているかを確認します。特定の機能や手順で逸脱が多発するような状況があれば何が原因であるかを深掘りし、手順書改訂や機能の改修、追加のシステム導入の要否等を含めて最善策を判断します。
   
• リソースと教育の妥当性: 一般ユーザーの利用でSOP外の操作や逸脱が頻発している場合、担当者の教育不足や、システム操作が複雑すぎるなどの根本原因がないかを確認、検討します。必要に応じて教育コンテンツの見直しや手順の改善を計画します。
   
• 外部環境への適合性: 前回の定期レビュー以降に新しく発出された規制要件、ガイドラインや、クラウドプロバイダによる仕様変更に対し、現在のシステムと運用SOPが適用可能かを確認します。システムが利用するライブラリの脆弱性や、利用に必要なライセンスの更新、証明書の有効期限など、通常利用で目に見えない箇所も定期レビューといった機会にコストを含めて確認できると、次期計画に盛り込むことに繋げやすいと言えます。
    

どんなに高度なバリデーションを経て導入されたシステムであっても、それを使用する「人」が正しい利用手順を守らなければ、バリデートされた状態は一瞬で崩れてしまいます。稼働後の維持管理において、システムの機能維持と同等に重要なのが、SOP（標準作業手順書）の遵守と、その形骸化の防止です。

運用開始から時間が経過すると、現場では「効率」を優先するあまり、正式な手順を省略したり、自己流の操作が常態化したりするリスクが高まります。

• 属人化のリスク: 「ベテランの〇〇さんしか知らない操作手順」が存在する状態は、規制環境下では極めて危険です。その操作がバリデーションの範囲内であるか保証されず、製品品質やデータの完全性を損なう温床となります。
   
• 手順と実態の乖離: システムの軽微なアップデートや業務フローの変化に合わせてSOPが改訂されていないと、現場は「手順書通りには動かない」と判断し、独自の手順・操作で運用を始めてしまいます。これが常態化してしまうと、「SOP不遵守」として監査で指摘を受けることに繋がります。

SOPは一度作ったら完成ではありません。操作ミスが多発する箇所があれば「手順が分かりにくいのではないか」と疑い、現場の声を取り入れて改善し続ける必要があります。「手順書を守る」ことを目的化するのではなく、「ミスを防ぎ、データの信頼性を守るために、この手順がある」という目的意識を組織全体で共有することが、真の意味での維持管理に繋がります。

SOPを遵守していることを証明するためには、以下の2点が不可欠です。

• タイムリーな教育訓練の実施: SOPが改訂された際、あるいは新しい担当者が着任した際に、適切な教育が行われているか。その受講記録が、「教育を受けた本人の署名」と「実施日」を伴って保管されていることが、監査における必須要件となります。
   
• 自己点検の仕組み: 2章でも述べた通り、定期的な自己点検でSOPと実態の乖離がないかを点検します。「決めた通りにやっているはず」という思い込みを排除するため、単に担当者にヒアリングするだけではなく、実際の操作記録や監査ログを確認し、SOPから逸脱した運用がないかを点検するプロセスを組み込みます。 
    

GxP適用システムのCSVは、リリースして運用を開始すれば完了するものではなく、むしろそこからが長い運用の始まりとなります。その期間においては、常にPDCAの観点から改善の余地が存在するため、継続的な維持管理は不可欠です。しかしながら、そのために過剰な文書化や形式的な手続きにリソースを割きすぎて、肝心の「品質リスク」への注視が疎かになってしまっては本末転倒です。最新の技術トレンドや規制当局の考え方（例：CSA; Computer Software Assurance）を参考に、将来のGxP適用システムのバリデーションの在り方、維持管理の進化について触れてみたいと思います。

2025年9月に米国FDAから発出されたCSA（Computer Software Assurance）ガイダンスでの考え方は、医療機器の製造システムおよび品質システムを対象に、CSVをより効率的に、かつ省リソース、省コストで実施することを規制当局が示したものです。

• 真のリスクへのフォーカス: すべての機能に一律のテストを行うのではなく、製品品質に直結するクリティカルな部分にテストリソースを集中させ、それ以外の部分はベンダーの検証結果を活用したり、手順書なしのテストとすることにより、冗長で長大な文書作成やテスト実施を廃し、全体の工数を最適化します。
   
• テストの自動化: 定期レビューや回帰テストにおいて、繰り返し実施される操作を自動化ツールに置き換えることで、人的ミスを排除し、検証コストの大幅な削減が期待できます。運用中に何らかの障害やデグレードが生じていないかを確認することにも利用が想定されます。
   
• ベンダー文書の活用: 特にパッケージ品やSaaSの場合には、システムベンダーにおける開発および検証に関する活動記録や文書を積極的に活用し、不足している検証がある場合にのみ追加で実施するなど、ベンダー文書の活用による効率化が推奨されます。
   

内容を見てお気づきになった方もいらっしゃるかも知れません。CSAは従来のCSVを置き換えるものではなく、従来からあったGAMP5等でも提唱されるリスクベースアプローチをCSV実施方針とすることを当局が追認したもので、古い（文書過多な）CSVの慣習からの脱却を促した発出と言えます。すでにGAMP5では2nd Editionにて、低リスクの機能にはアドホックテストや探索的テストといった手順書なしのテスト（Unscripted Testing）や自動化ツールの利用が提唱されていましたが、CSAも同様に、これらの採用によってソフトウェア保証活動の効率化を図ることを当局が公式に認めたものです。ただし、これらの柔軟な対応は、あくまでSME（Subject Matter Expert: 特定分野の専門家）による適格なリスクの判断をベースにしたものであることが大事です。そのため、単純に手順書作成を省略してよい、というものではなく、なぜそういう検証を採用したのか、どのような結果であったのかの報告をまとめる力が必要であるため、よりシステムとリスクに精通したリソースが必要になるとも言えます。

PMDAのPIC/S加盟等を踏まえ、査察指針の国際整合性が構築される中では、日本もCSAの考えに準拠していくものとは推察されますが、本記事の発行時点で、国内当局よりCSAガイダンスに相当する通知の発出はないため、適用可能な基準が具体的に示されていない状況です。一方、日本国内においては「コンピュータ化システム適正管理ガイドライン」にて、特に運用フェーズでの変更管理におけるバリデーションに対しては「リスクの程度に応じて」とされているため、もし実際のCSV活動でCSAに近い手法を採用する場合には、対象が低リスクであることを前提に十分な検討の上、従来と同様に、理由と根拠を揃えて正当性を説明可能であることが重要と言えます。

全6回にわたる連載を通じてお伝えしてきた通り、CSVは一度きりのイベントではなく、システムの誕生から廃棄まで続く、長い「旅（ライフサイクル）」そのものです。

最初は複雑で高いハードルに感じるかもしれませんが、適切なルールとツール、関係者全員の理解と誠実な運用、そして「なぜこれを行うのか」という目的意識を持つことで、CSVは単なる規制対応のコストから、システムの安定稼働と企業の信頼を支える「品質のインフラ」へと変わります。本連載が、皆様の現場におけるCSV活動の羅針盤となり、より安全で高品質な医薬品・医療機器の提供に貢献できれば幸いです。

長らくのご愛読、ありがとうございました。

著者紹介

2015年までの約20年間、製薬企業向けコンサルティング会社にてシステム開発に従事。Part11制定当初よりCSVの実施に携わる。
CROへの移籍とそこでのシステム部門長としてのCSV文書レビュー等を経て、2020年よりシーエーシーに在籍。
同業界における経験を活かし、GxP適用のクラウド環境構築・運用サービスの立ち上げや、CSV支援サービスに携わり、現在に至る。

関連リンク：
Webサイト「Innovation Hub」に、株式会社シーエーシーのCSV支援サービスの記事が掲載中です。

皆様のお役に立てる情報を発信するため今後の参考にさせていただきたく、下記アンケートへのご協力をお願いできますと幸いです。
（所要時間：1〜2分程度）

なお、ご回答いただいた方には、過去に実施いたしましたCSVに関するWebinarのオンデマンド配信をご視聴いただけるURLをご案内いたします。