CSAガイダンス発出までの長い経緯

FDAは2025年9月24日、Computer Software Assurance（CSA）の最終ガイダンスを発出した。さらに2026年2月3日、QMSR（Quality Management System Regulation）との整合を図るため、表題を「Computer Software Assurance for Production and Quality Management System Software」へ改めた改訂版が公表され、2025年9月版を置き換えた。ドラフト発出から3年、構想段階から数えれば十数年におよぶ長い道のりである。本稿では、なぜこれほど時間がかかったのか、そして「CSAは本当に新しい概念なのか」という根源的な問いについて解説するものである。

いつ、どのような名称で発出されたのか

2025年9月24日の最終化と、2026年2月3日の改題

FDAのCDRH（機器・放射線保健センター）およびCBER（生物製剤評価研究センター）は、2025年9月24日に最終ガイダンス「Computer Software Assurance for Production and Quality System Software」を発出した。連邦官報での告示は同日付（90 FR 45945、Docket No. FDA-2022-D-0795）である。

その後、2026年2月2日にQMSRが施行されたことを受け、FDAは2026年2月3日付で表題を「Computer Software Assurance for Production and Quality Management System Software」へ改めた改訂最終版を公表し、2025年9月24日版をsupersede（置換）した。これが現行版である。

CSAに至る道のり ― 年表

なお、QMSR施行前後の記録の取り扱いについては「QMSR施行前の記録は査察でどう扱われるのか」を、Case for Qualityの残された課題については「Case for Qualityに残された障壁」を併せて参照されたい。

CSAとは何か ― 初心者のための整理

CSA（Computer Software Assurance）とは、ソフトウェアの意図した用途（intended use）、プロセスリスク、患者安全・製品品質への影響を踏まえ、適切な厳格度（rigor）の保証活動を選択する考え方である。

FDAは、製造業者が高品質な医療機器を製造しつつ21 CFR Part 820に適合できるよう、リスクベースのアプローチ、追加的な厳格度が必要となる場面の特定、各種テスト活動の活用について推奨を示している。従来のCSV（Computer System Validation／コンピュータ化システムバリデーション）が「網羅的なドキュメント作成」に傾倒しがちであったのに対し、CSAは「リスクベース思考」と「Critical Thinking（クリティカルシンキング）」を前面に押し出した考え方である。

CSAの4つのポイント

• ソフトウェアの意図した用途とリスクを起点に、保証活動の深さを決定する
• ベンダーテストやベンダー資料を積極的に活用し、無駄な再テストを排除する
• スクリプトテストだけでなく、アドホックテストや非公式テストも適切に活用する（「アンスクリプトテストという新概念」参照）
• ドキュメントは「証拠を残すため」ではなく「価値を生むため」に作成する

要するに、「やらされ仕事のCSV」から「思考するアシュアランス」への転換を促すものである。その思想的背景については「なぜ「バリデーション」から「アシュアランス（保証）」へ変わったのか」で詳述している。

根拠条文はどこにあったのか

旧QSR（Quality System Regulation）では、自動化されたプロセスに用いるソフトウェアのバリデーション要求は21 CFR 820.70(i)に置かれていた。QMSRへの移行に伴い、Part 820の多くのサブパートは「Reserved（留保）」とされ、実体的な要求は引用組込みされたISO 13485:2016へ移った。ソフトウェアバリデーションに関しては、品質マネジメントシステムで使用するソフトウェアがISO 13485:2016 4.1.6、製造・サービス提供で使用するソフトウェアが同 7.5.6で要求される構造である。

ドラフトから最終版まで ― 検討プロセスの経緯

FDAは2022年9月13日にCSAドラフトガイダンスを連邦官報で公表し、パブリックコメント期間を設けた。寄せられたコメントは、ドケット番号 FDA-2022-D-0795 で確認可能である。FDAはこれらのコメントを踏まえ、定義セクションの追加、手動テスト／自動テストの事例の更新、各種ソフトウェアへの当てはめ例の追加といった修正を行ったうえで最終化した。

筆者は公開情報をベースに、ドラフト発出の瞬間から、業界団体の意見書、各種コンファレンスでのFDA関係者の発言、関連解説などを継続的に追跡してきた。なお、個別の業界団体（ISPE、PDA、PhRMA等）の意見書については、ドケットを通じて公開されている各団体のコメントレターを個別に参照されたい。

3年という期間は、決して「遅い」のではなく、むしろ「丁寧に練り上げた」ことの証左であると評価できる。

最終版で重視されている論点

なお、データインテグリティ（ALCOA+原則）、21 CFR Part 11、AI／機械学習ソフトウェアといった関連論点については、実務上の検討課題として並行して議論されているが、CSAガイダンス本文での明確化範囲については原文を確認のうえ個別判断が必要である。

独自の視点 ― CSAは本当に「新しい概念」なのか

ここで強調しておきたいのは、CSAは決して新しい概念ではないということである。FDAが2002年に最終化した「General Principles of Software Validation」は、医療機器ソフトウェア、または医療機器の設計・開発・製造に使用されるソフトウェアのバリデーションに適用可能な一般原則を示した文書である。

そのため、CSAで強調されるリスクベース、意図した用途、適切な保証活動という考え方は、まったく新しい発想というより、従来のソフトウェアバリデーション原則をより実務的・明示的に整理したものと位置づけられる。実務の現場では、「すべてのテストを一律に行う必要はない」「リスクに応じてバリデーションの深さを変えるべきだ」「ベンダー資料を活用せよ」というメッセージは、業界セミナーや公開資料の場で長年議論されてきたものである。

しかしながら、これらの考え方が明文化された包括的なガイダンス文書になっていなかったため、業界全体には十分に浸透しなかったと考えられる。とりわけ、一部の企業では「FDAは厳格な網羅的バリデーションを求めている」という保守的な解釈が残り、過剰なドキュメント作成、無意味な再テスト、形骸化したIQ／OQ／PQが行われてきた事例が見受けられた。

規制動向としての位置づけ ― FDA・EMA／PIC/S・PMDA

CSAガイダンスは米国FDAが発出したものであり、その直接の対象は医療機器の製造および品質マネジメントシステムである。一方で、その思想は他の規制領域でも参照されつつある。

また、医薬品GMP領域でのCSA適用については、FDA本ガイダンスの直接対象ではないため、「参考になる」「応用可能性が議論されている」という位置づけで捉えるのが適切である。国際調和の観点からは、リスクベースアプローチやライフサイクル管理という潮流と親和性があるため、今後も注視すべきテーマである。

実務への示唆 ― ベストプラクティス

CSA最終ガイダンスを受けて、企業が検討すべき主なアクションを整理する。なお、以下は「必須要求事項」ではなく、リスクベースのアプローチを取り入れるうえでの実務的な推奨事項である。

1. 既存のCSV手順書（SOP）を見直す網羅的なテストを前提とした手順を、リスクベースのアシュアランス活動に転換する作業が有効である。「どのシステムにも同じテンプレートを当てる」運用こそが、過剰文書化の温床である。
2. ベンダーアセスメントを強化するベンダーテストを活用するためには、ベンダーの品質システムや開発プロセスを評価する能力が不可欠である。評価できなければ、結局は自社で再テストするほかない。
3. 人材を育成するCSAは「思考するアプローチ」であり、手順書をなぞるだけでは実践できない。Critical Thinkingを実装できる人材の育成こそが、最大の課題となるのである。

おわりに

CSAガイダンスの発出は、ゴールではなくスタートである。長年明文化されてこなかった原則が公式文書として世に出た今、業界がこれをどう受け止め、どう実装していくかが問われている。規制動向は「発出された瞬間」よりも「その後の運用」が重要である。

FDAが現行版を「Quality Management System Software」として位置づけ直していることからもわかるように、関連規制（21 CFR Part 820のQuality Management System regulation等）との整合性を踏まえた継続的な追跡が、コンプライアンス担当者には求められるのである。