更新され続けるソフトウェアをどう検証するか——GAMP 5とFDAガイダンスが求めるもの

Manufacturing Chemist に、⁠規制下の環境で使うソフトウェアが更新されたとき、FDAのガイダンスと GAMP 5 が製薬企業に何を求めるのかを検討する記事が掲載された。Original Software の CEO、Carl Andrews 氏によるものである。

見出しが「誰も語らないコンプライアンスの負担」となっているのは、この作業が導入時ではなくその後ずっと続く性質のものだからと読める。

バリデーションは一度きりの行事ではない

コンピュータ化システムバリデーション（CSV）は、システムを導入するときの作業として語られやすい。要求仕様を書き、設計を確認し、テストを実施し、報告書をまとめる。

しかしソフトウェアは、導入したあとも変わり続ける。

最後の項目が、近年この議論が増えた理由にあたる。従来のオンプレミス型では、いつ更新するかを自社で決められた。SaaS型では更新の時期も内容も供給者が決める⁠。使う側は、更新されたという通知を受け取る立場になる。

ここで実務が直面するのが、⁠どこまで検証をやり直すかという判断である。

パッチが当たるたびに全機能を再テストしていては、資源が持たない。かといって何もしなければ、「バリデートされた状態」が維持されている根拠を示せない。

GAMP 5 の考え方は、この間をリスクに基づいて埋めるものである。

最後の点が要点になる。供給者が実施した検証をそのまま信じるのではなく、⁠その供給者を評価したうえで根拠として使う⁠——という組み立ては、供給者管理と受入試験でCoAに依拠する条件を整えるのと同じ構造をしている。

査察で問われるのは、テストの量ではなく説明できるかどうかである。

この形は、リスクベースの品質マネジメントや傾向監視（OOT）で繰り返し出てくるものと同じである。⁠薄くしたこと自体ではなく、薄くしてよいと判断した根拠が問われる。

近年のFDAの方向性（Computer Software Assurance の考え方）も、文書作成の量を増やすことではなく、⁠リスクの高いところに検証の労力を集中させるほうへ寄っている。記事が「負担」を主題にしているのは、その配分がうまくできていない現場が多いことの裏返しとも読める。

更新の頻度が上がるほど、手作業の回帰テストは追いつかなくなる。ここでテストの自動化が現実的な選択肢に入る。

ただし自動化にも前提がある。

つまり自動化は負担を消すのではなく、⁠負担の置き場所を変える⁠。それでも更新が頻繁な環境では、置き換えたほうが総量は小さくなる——という判断になる。

規制対象のシステムが増え、そのすべてが更新され続ける以上、この問題は減る方向には向かわない。⁠導入時ではなく運用期間全体で費用を見積もるという当たり前の話が、実際には抜けやすいという指摘といえる。

※ 本ページは公開情報（Manufacturing Chemist の記事）をもとにしたProglenth編集部による整理です。ガイダンスの具体的な要求事項・適用範囲は一次情報および各当局の文書をご確認ください。

本記事は業界メディア等の報道をもとに、Proglenth編集部が独自に見出し・要約・解説を加えて整理したものです。正確性には努めていますが、最終的な仕様・条件は各社の公式情報・一次情報をご確認ください。編集の考え方は編集方針に記載しています。