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

ひとことで言えば
CSV（Computer System Validation） は本来、コンピュータシステムが意図した用途に適することを客観的証拠で示す活動である。ところが実務では、いわば「文書をそろえること」に重心が偏りがちであった。これに対して、新しい考え方である CSA（Computer Software Assurance） は、「リスクに応じて、本当に大事なところを実質的に確認し、意図した用途に適しているという信頼性を示す」ことへ重心を移す考え方である。
両者の違いを乱暴に図式化すると、労力の配分が 上下逆転 したと言ってよい。従来のCSV実務では、しばしば「文書化に8割・テストに2割」と言われるほど、文書作成に労力が偏ることがあった。CSAが目指すのは、その逆、すなわち「文書化は2割・クリティカルシンキングとテストに8割」という感覚である（これは公式の比率ではなく、方向性を表す業界的な比喩である）。同じ「ソフトウェアが意図どおり動くことを確かめる」という目的のはずなのに、なぜ重心がここまで動いたのか。本稿では、その背景を初心者にも分かるように、しかし規制の文脈を外さずに解説する。

そもそも「バリデーション」とは何だったのか
バリデーション（Validation）とは、本来「そのシステムが意図した用途に対して、確かに適切であることを客観的な証拠によって確認すること」を指す。GMPの世界では古くから使われてきた概念であり、コンピュータシステムにこれを適用したものがCSVである。
問題は、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の核心である。
具体的には、次のような発想の転換が起きる。

第一に、リスクベースである。 すべてのシステム・すべての機能を一律に扱うのではなく、製品品質や患者安全への影響が大きい部分に労力を集中する。影響の小さい機能には、リスクに見合った簡素な確認や、供給者の検証結果の活用（ベンダー検証結果の利用）を組み合わせる。

第二に、テスト手法を目的に合わせて選ぶ。 一字一句を定めたスクリプトテストだけが正解ではない。リスクの低い機能であれば、探索的（アドホック／非スクリプト）テストやエラーゲシングといった、より軽量で実質的な手法を積極的に認める。

第三に、文書は、リスク判断・テスト手法の選択理由・検証した事実を裏づける証拠に絞る。 なぜそのリスク分類にしたのか、なぜその手法を選んだのかという根拠は残すが、形式を満たすためだけの文書は作らない。冒頭で述べた「文書化2割・テスト8割」への逆転は、このようにして起こる。

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

CSAは単なる業界の流行語ではない。FDA（CDRH・CBER）は2022年9月13日に「Computer Software Assurance for Production and Quality System Software」のドラフトガイダンスを公表し、2025年9月24日にその最終版を発行した（Federal Register 90 FR 45945、Docket No. FDA-2022-D-0795）。重要なのは、このガイダンスが2002年のGPSVを全面的に廃止するものではなく、生産・品質システムソフトウェアに関する部分を補完・更新する位置づけであることである。FDAの記述によれば、本ガイダンスはGPSVを補完し、その第6章（自動化された製造装置および品質システムソフトウェアのバリデーション）のみを置き換えるとされている。

さらにFDAは2026年2月3日に、これを「Computer Software Assurance for Production and Quality Management System Software」へと改題した更新版を発行し、新たな品質マネジメントシステム規制（QMSR、ISO 13485:2016ベース）に整合させた。最新の文言や適用範囲を引用する際は、必ずFDA公式ガイダンスページの該当版を確認されたい。

なお、このFDAガイダンスの中心的な対象は、医療機器の生産および品質システム／品質マネジメントシステムで使用されるソフトウェアであり、すべてのGMPコンピュータ化システムや製品組込みソフトウェアを一律に対象とするものではない。もっとも、その根底にある「リスクに応じて保証の重みづけを変える」という思想は、医薬品GMPを含む幅広い領域で参照され始めている。

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

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

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

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

用語ミニ解説

CSV（Computer System Validation）：コンピュータ化システムが意図した用途に適して一貫して動作することを、文書化された客観的証拠により示す活動。
CSA（Computer Software Assurance）：ソフトウェアが意図した用途に適しているという信頼性を、リスクに応じた検証活動と証拠によって合理的に示す考え方。FDAでは特に生産・品質（マネジメント）システムソフトウェアへの適用が示されている。
GPSV（General Principles of Software Validation）：FDAによるソフトウェアバリデーションの基本原則。草案は1997年、最終版は2002年。
ALCOA+：データインテグリティの原則。Attributable・Legible・Contemporaneous・Original・Accurateに、Complete・Consistent・Enduring・Availableなどを加えたもの。
レースコンディション（競合状態）：複数の処理の実行順序やタイミングによって、予期しない結果が生じるソフトウェア欠陥。