なぜ「バリデーション」から「アシュアランス（保証）」へ変わったのか

CSV（Computer System Validation）は本来、コンピュータシステムが意図した用途に適することを客観的証拠で示す活動である。ところが実務では、いわば「文書をそろえること」に重心が偏りがちであった。これに対して新しい考え方であるCSA（Computer Software Assurance）は、「リスクに応じて、本当に大事なところを実質的に確認し、意図した用途に適しているという信頼性を示す」ことへ重心を移す。同じ「ソフトウェアが意図どおり動くことを確かめる」という目的のはずなのに、なぜ重心がここまで動いたのか。本稿では、その背景を初心者にも分かるように、しかし規制の文脈を外さずに解説する。

ひとことで言えば ― 労力の配分が上下逆転した

両者の違いを乱暴に図式化すると、労力の配分が上下逆転したと言ってよい。従来のCSV実務では、しばしば「文書化に8割・テストに2割」と言われるほど、文書作成に労力が偏ることがあった。CSAが目指すのは、その逆、すなわち「文書化は2割・クリティカルシンキングとテストに8割」という感覚である。

そもそも「バリデーション」とは何だったのか

バリデーション（Validation）とは、本来「そのシステムが意図した用途に対して、確かに適切であることを客観的な証拠によって確認すること」を指す。GMPの世界では古くから使われてきた概念であり、コンピュータシステムにこれを適用したものがCSVである。バリデーションとベリフィケーションの区別については「バリデーションとベリフィケーションの違い」を、その歴史的な成り立ちについては「1970年代に始まったバリデーションの歴史」を参照されたい。

問題は、CSVという概念そのものではなく、その実務上の運用にあった。規制対応の現場で年月を重ねるうちに、査察対応を意識するあまり、文書作成や承認記録の整備に過度に重心が置かれることが少なくなかった。査察で指摘を受けないための文書、監査証跡を残すための記録、署名欄を埋めるための承認――こうした「形式」が積み上がり、いつしか「文書をいくつ作ったか」が品質の指標であるかのように扱われることさえあった。

ソフトウェア安全性の教訓 ―― Therac-25

ソフトウェアの欠陥が患者安全に直結し得ることを示した象徴的な事例が、放射線治療装置Therac-25（セラック25）の事故である。

カナダ原子力公社（AECL）が製造したこの装置は、1985年から1987年にかけて、少なくとも6名の患者に、重篤または致死的となり得る過線量の放射線を照射した。原因は単一ではない。ソフトウェアの欠陥、とりわけ競合状態（レースコンディション）やエラー処理の不備に加え、本来ハードウェアで担保すべき安全インターロックをソフトウェアに過度に依存させた設計、そして運用・報告体制の問題などが複合的に重なったものである。通常の数十倍から最大で約100倍の線量が投与された例もあったとされ、結果として複数名が死亡し（一般に少なくとも3名の死亡が事故に起因するとされる）、生存者も生涯にわたる障害を負った。1987年2月にはFDA（米国食品医薬品局）が装置を欠陥品と判断し、AECLに是正計画の提出や使用者への通知などを求める対応がとられた。

Therac-25が示したのは、ひとつの教訓であった。膨大な文書をそろえることよりも、「どこに本当の危険が潜んでいるか」を考え抜き、そこを徹底的に検証することのほうが、はるかに患者を守る。ところが文書中心に偏ったCSV実務は、リスクの大小にかかわらず一律に重い文書化を求めがちで、本当に検証すべき箇所に労力が回りにくいという矛盾を抱えていた。

CSAという「揺り戻し」 ―― 重心を実質へ

こうした問題意識と、近年のリスクベースアプローチ・クリティカルシンキング重視の流れの中で整理されたのが、CSA（Computer Software Assurance、コンピュータソフトウェア・アシュアランス）という考え方である。

「Validation（バリデーション／妥当性確認）」から「Assurance（保証）」へという言葉の変化は、バリデーションを不要にするという意味ではない。むしろ、意図した用途に適しているという信頼性を、リスクに応じた証拠によって、より合理的に示すことへ重心を移すものである。問われているのは「規定どおりに文書を作ったか」ではなく、「そのソフトウェアが意図した用途に適していると、どこまで確信できるか」である。確信（confidence）を、リスクに見合った合理的な労力で得る――これがCSAの核心である。

具体的には、次のような発想の転換が起きる

1. リスクベースであるすべてのシステム・すべての機能を一律に扱うのではなく、製品品質や患者安全への影響が大きい部分に労力を集中する。影響の小さい機能には、リスクに見合った簡素な確認や、供給者の検証結果の活用（ベンダー検証結果の利用）を組み合わせる。
2. テスト手法を目的に合わせて選ぶ一字一句を定めたスクリプトテストだけが正解ではない。リスクの低い機能であれば、探索的（アドホック／非スクリプト）テストやエラー推測（error guessing）といった、より軽量で実質的な手法を積極的に認める。詳しくは「アンスクリプトテストという新概念」を参照されたい。
3. 文書は「証拠」に絞るリスク判断・テスト手法の選択理由・検証した事実を裏づける証拠に絞る。なぜそのリスク分類にしたのか、なぜその手法を選んだのかという根拠は残すが、形式を満たすためだけの文書は作らない。冒頭で述べた「文書化2割・テスト8割」への逆転は、このようにして起こる。

この4要素（意図した使用の特定 → リスクベースアプローチの決定 → 保証活動の決定 → 記録の確立）というフレームワークの中身については、「6つのステップとCSAのフレームワーク」で詳しく解説している。

規制動向 ―― いま、どこまで来ているか

CSAは単なる業界の流行語ではない。FDA（CDRH・CBER）は2022年9月13日に「Computer Software Assurance for Production and Quality System Software」のドラフトガイダンスを公表し、2025年9月24日にその最終版を発行した（連邦官報 90 FR 45945、Docket No. FDA-2022-D-0795）。

重要なのは、このガイダンスが2002年のGPSVを全面的に廃止するものではなく、生産・品質システムソフトウェアに関する部分を補完・更新する位置づけであることである。FDAの記述によれば、本ガイダンスはGPSVを補完し、その第6章（自動化された製造装置および品質システムソフトウェアのバリデーション）のみを置き換えるとされている。最新の文言や適用範囲を引用する際は、必ずFDA公式ガイダンスページの該当版を確認されたい。

なお、旧QSRでは自動化プロセスに用いるソフトウェアのバリデーション要求は21 CFR 820.70(i)に置かれていたが、QMSRへの移行に伴いPart 820の該当サブパートはReserved（留保）とされ、実体的な要求は引用組込みされたISO 13485:2016の4.1.6（QMSで使用するソフトウェア）および7.5.6（製造・サービス提供で使用するソフトウェア）へ移っている。条文の置き場所は変わったが、要求の実質は維持されている点に留意されたい。

いずれにせよ、「文書中心に偏ったバリデーション実務」から「リスクに応じた保証」への移行は、もはや一部の先進企業の試みではなく、規制当局が公式に推奨する方向性となったのである。なお、ALCOA+はあくまでデータインテグリティの原則であり、GAMP 5（第2版）はリスクベースのアプローチを示す業界ガイダンスである。これらはCSAそのものの根拠文書ではないが、思想的には一貫している。

まとめ ―― 「何のための仕事か」を取り戻す

バリデーションからアシュアランスへの変化は、ルールが緩くなったことを意味しない。むしろ問われる知性は高くなった。「とりあえず全部テストして全部文書化する」ことは、考えることを放棄した安全策でもあった。CSAは、「どこが本当に危ないのか」を自ら考え、説明し、証明する責任を現場に求める。

Therac-25の事故が遺した教訓は、いまも色あせない。文書は手段であって目的ではない。守るべきは患者であり、製品の品質である。「コンプライアンスのための仕事」から「品質と安全のための仕事」へ――バリデーションからアシュアランスへの転換とは、その当たり前を取り戻す試みなのである。

用語ミニ解説