6つのステップ＝CSAのフレームワーク
CSV から CSA へ。FDA の最新ガイダンスが描く「リスクベースの保証」を、6つのステップで実務に落とす。
CSAとは何か ー CSVからの転換
医療機器の品質システムやソフトウェアの検証といえば、長らく「CSV(Computer System Validation)」が王道であった。
膨大なテストスクリプトを書き、すべての機能を網羅的にテストし、分厚いドキュメントを積み上げる。
しかしその実態は、いつしか「文書のための文書」を量産し、本来守るべき製品品質や患者安全への寄与が見えにくくなっていた。
そこでFDAが打ち出したのが「CSA(Computer Software Assurance)」である。
その対象は、医療機器の製造または品質マネジメントシステム(QMS)で使用されるソフトウェアの保証であり、製品に組み込まれるソフトウェアそのものとは区別される。
FDAは2022年9月にドラフトガイダンスを公表し、2025年9月24日に最終版を発行した。
その後、2026年2月3日付の改訂最終版として公表され、2025年9月版を置換(supersede)した。
これが現行・最新版である。
改訂の背景には、QMSR(Quality Management System Regulation。21 CFR Part 820にISO 13485:2016を引用組込みし、2026年2月2日に施行)との整合がある。
CSAの肝はリスクベースの発想である。中核となるのは4つの要素、すなわち「意図する使用の特定 → リスクの決定 → 保証活動の決定 → 記録の確立」というフローだ。
そして運用を貫く原則が「必要以上のことはしない(no more than necessary)」である。
守るべきものに資源を集中させ、寄与の薄い文書作業を削ぎ落とすーーその思想が根底にある。
実務に落とすための6ステップ
ここからは、筆者が実務上当てはめやすいよう整理した6つのステップを示す。
意図する仕様(使用)の特定 ー そのソフトウェアを何のために使うのか。すべての起点。
リスクベースアプローチの決定 ー 患者安全・製品品質・データ完全性への影響度を見極める。
変更管理 ー ライフサイクル全体に関わる横断的論点(便宜上ここに配置)。
適切な保証活動の決定 ー リスクに応じてテスト手法を柔軟に選ぶ。
追加考慮事項 ー ベンダー活用・市販ソフトの扱いなど(講師整理上の括り)。
適切な記録の確立 ー 判断の根拠を後から追える記録を残す。
ステップ2のリスク判定では、対象のソフトウェアが「患者安全・製品品質・データ完全性(data integrity)」に影響しうるかという観点で考える。現行2026年2月版は、この三つの軸でリスクを整理している。
ステップ3の変更管理は、便宜上3番目に置いているが、実際にはソフトウェアのライフサイクル全体に関わる横断的な論点である。4要素のフロー(使用→リスク→保証活動→記録)に並ぶ「第3の順番」ではない点に注意したい。FDAガイダンス本文でも変更管理は扱われるが、ここでの番号付けは理解の便宜にすぎない。
ステップ4の保証活動は、よく「高リスクはスクリプトテスト、それ以外は探索的」と単純化されがちだが、これは正確ではない。プロセスリスクが「高い／高くない」かに応じて、スクリプトテスト・非スクリプト(探索的)テスト・両者のハイブリッドを柔軟に選択するのが本来の姿である。高リスクであってもハイブリッドが選ばれることはありうる。「高リスクならスクリプトのみ」と固定的に捉えてはならない。
ステップ5の「追加考慮事項」は、ベンダー／サプライヤのエビデンス活用や、市販ソフト(COTS/SaaS)の扱いなどを含む。ただしこれはFDA公式の見出し名と一致するとは限らず、講師が整理上まとめた括りである。Part 11(電子記録・電子署名)への対応についても、predicate rule(根拠規制)が要求する記録を電子で維持・提出するかを起点に、FDAのScope and Applicationガイダンスの考え方で整理するのが実務上扱いやすい。
ステップ6の記録は、重い手順書を指すのではない。FDAが示す記録の構成要素は、意図する使用・リスクベース分析・テストした目的・実施したテスト・発見した問題・結論・実施者と日時である。判断の根拠を後から追えること、それが要点である。
なお、本ガイダンスは医療機器の製造・QMSソフトウェアを主対象とするため、製品組込みソフトウェアやSaMD、医薬品GMP領域のCSV/CSA適用では、別途該当する規制・ガイダンスとの関係を確認する必要がある。
フレームワークであるがゆえに
CSAはあくまでフレームワークであり、自社の手順レベルで「何を(WHAT)」「どこまで(HOW)」実施するかまでを一律に規定するものではない。
それゆえ業界では「曖昧で、結局何をやればいいのか分からない」という声も少なくない。
だが、それは欠陥ではなく性質である。自社の製品・プロセス・リスクは各社で異なる以上、画一的な答えを与えないことにこそ意味がある。
求められるのは、4要素という構造を正しく理解し、それを自社の文脈へ丁寧に当てはめる力である。
CSAを「楽にドキュメントを減らす方便」と誤解すれば足をすくわれる。リスクに見合った保証を、根拠をもって設計する——その思考こそがCSAの本質なのである。
