6つのステップ＝CSAのフレームワーク

CSVからCSAへ。FDAの最新ガイダンスが描く「リスクベースの保証」を、実務に落とし込むための整理である。あらかじめ断っておくと、FDA最終ガイダンス本体が示すのは「4つのステップ」であり、本稿で示す「6つのステップ」は、それを自社の手順へ当てはめやすくするために筆者が横断的論点を加えて整理したものである。両者の関係を明確にしたうえで、CSAのフレームワークを解説する。

CSAとは何か ― CSVからの転換

医療機器の品質システムやソフトウェアの検証といえば、長らく「CSV（Computer System Validation）」が王道であった。膨大なテストスクリプトを書き、すべての機能を網羅的にテストし、分厚いドキュメントを積み上げる。しかしその実態は、いつしか「文書のための文書」を量産し、本来守るべき製品品質や患者安全への寄与が見えにくくなっていた。その背景は「なぜ「バリデーション」から「アシュアランス（保証）」へ変わったのか」で詳述している。

そこでFDAが打ち出したのが「CSA（Computer Software Assurance）」である。その対象は、医療機器の製造または品質マネジメントシステム（QMS）で使用されるソフトウェアの保証であり、製品に組み込まれるソフトウェアそのものとは区別される。

ガイダンスの発出経緯

詳しい経緯は「CSAガイダンス発出までの長い道のり」を参照されたい。

FDA最終ガイダンスが示す「4つのステップ」

CSAの肝はリスクベースの発想である。中核となるのは4つの要素、すなわち「意図する使用の特定 → リスクベースアプローチの決定 → 適切な保証活動の決定 → 適切な記録の確立」というフローである。

そして運用を貫く原則が「必要以上のことはしない（no more than necessary）」である。FDAはこれをleast burdensome（最小負担）のアプローチと表現している。守るべきものに資源を集中させ、寄与の薄い文書作業を削ぎ落とす――その思想が根底にある。

実務に落とすための6ステップ

ここからは、筆者が実務上当てはめやすいよう整理した6つのステップを示す。

1. 意図する使用の特定そのソフトウェアを何のために使うのか。すべての起点である。
2. リスクベースアプローチの決定患者安全・製品品質・データ完全性への影響度を見極める。
3. 変更管理ライフサイクル全体に関わる横断的論点（便宜上ここに配置）。
4. 適切な保証活動の決定リスクに応じてテスト手法を柔軟に選ぶ。
5. 追加考慮事項ベンダー活用・市販ソフトの扱いなど（筆者の整理上の括り）。
6. 適切な記録の確立判断の根拠を後から追える記録を残す。

ステップ2 ― リスク判定の3つの軸

対象のソフトウェアが「患者安全・製品品質・データ完全性（data integrity）」に影響しうるかという観点で考える。現行版は、この三つの軸でリスクを整理している。判定の単位はシステム全体ではなく、機能・フィーチャ・オペレーション単位である点が重要である。ひとつのシステムの中に、高リスクの機能と低リスクの機能が同居することは珍しくない。

ステップ3 ― 変更管理は「第3の順番」ではない

変更管理は便宜上3番目に置いているが、実際にはソフトウェアのライフサイクル全体に関わる横断的な論点である。4要素のフロー（使用→リスク→保証活動→記録）に並ぶ「第3の順番」ではない点に注意したい。FDAガイダンス本文でも変更管理は扱われるが、ここでの番号付けは理解の便宜にすぎない。

実務上は、変更のたびにステップ1（意図する使用は変わったか）とステップ2（リスクは変わったか）へ戻り、そのうえで必要な保証活動を決め直す、というループとして捉えるのが正しい。

ステップ4 ― 保証活動は「高リスク＝スクリプトのみ」ではない

ステップ4の保証活動は、よく「高リスクはスクリプトテスト、それ以外は探索的」と単純化されがちだが、これは正確ではない。プロセスリスクが「高い／高くない」かに応じて、スクリプトテスト・非スクリプト（探索的）テスト・両者のハイブリッドを柔軟に選択するのが本来の姿である。高リスクであってもハイブリッドが選ばれることはありうる。「高リスクならスクリプトのみ」と固定的に捉えてはならない。

アンスクリプトテストの実務については「アンスクリプトテストという新概念」で詳しく解説している。

ステップ5 ― 追加考慮事項（ベンダー活用・COTS／SaaS・Part 11）

ステップ5の「追加考慮事項」は、ベンダー／サプライヤのエビデンス活用や、市販ソフト（COTS／SaaS）の扱いなどを含む。ただしこれはFDA公式の見出し名と一致するとは限らず、筆者が整理上まとめた括りである。

Part 11（電子記録・電子署名）への対応についても、predicate rule（根拠規制）が要求する記録を電子で維持・提出するかを起点に、FDAのScope and Applicationガイダンスの考え方で整理するのが実務上扱いやすい。紙と電子のどちらを正とするかという論点は「紙の記録と電子記録はどちらが優先されるのか」を、電子署名の表示要件は「電子署名の表示（manifestations）」を参照されたい。

ステップ6 ― 記録は「重い手順書」ではない

ステップ6の記録は、重い手順書を指すのではない。FDAが示す記録の構成要素は、次のとおりである。

• 意図する使用
• リスクベース分析（およびその根拠）
• テストした目的
• 実施したテスト
• 発見した問題（および処置）
• 結論
• 実施者と日時

判断の根拠を後から追えること、それが要点である。記録を削れるという話ではない。削れるのは「形式を満たすためだけの文書」であって、証拠そのものではない。

フレームワークであるがゆえに

CSAはあくまでフレームワークであり、自社の手順レベルで「何を（WHAT）」「どこまで（HOW）」実施するかまでを一律に規定するものではない。それゆえ業界では「曖昧で、結局何をやればいいのか分からない」という声も少なくない。

だが、それは欠陥ではなく性質である。自社の製品・プロセス・リスクは各社で異なる以上、画一的な答えを与えないことにこそ意味がある。求められるのは、4要素という構造を正しく理解し、それを自社の文脈へ丁寧に当てはめる力である。

CSAを「楽にドキュメントを減らす方便」と誤解すれば足をすくわれる。リスクに見合った保証を、根拠をもって設計する――その思考こそがCSAの本質なのである。