アンスクリプトテストという新発想
バリデーションの現場に長く身を置いた者なら、テストスクリプトの作成にどれほどの時間が吸い取られるかをよく知っているはずだ。
仕様書を読み込み、操作手順を一行ずつ書き起こし、期待結果を定義し、レビューを重ねる。
そしていざ実行となる前に、ドライランーースクリプトの予行演習ーーを繰り返す。
ここでつまずく。手順の記述が曖昧だったり、画面遷移が想定と違ったり、そもそもスクリプト自体に誤りがあったりする。そう、忘れられがちな事実だが、テストスクリプトそのものにもバグがあるのだ。
筆者は四十年近くCSVに携わってきたが、振り返れば膨大な時間をこのドライランの繰り返しに費やしてきた。
テスト対象のソフトウェアではなく、テストの台本を直すことに労力を注いでいたのである。
この本末転倒への違和感が、本稿で紹介する考え方の出発点だ。
アンスクリプトテストとは何か
FDAの「Computer Software Assurance」ガイダンス、いわゆるCSAガイダンスは、従来の「スクリプトテスト（scripted testing）」と並べて、「アンスクリプトテスト（unscripted testing、非スクリプト型テスト）」という概念を正式に導入した。
ここには探索的テスト（exploratory）、アドホックテスト（ad-hoc）、エラー推測（error guessing）などが含まれる。
詳細な手順をステップごとに書き起こす必要はなく、合否（pass/fail）という目的そのものに焦点を当てる。
つまり、スクリプトを緻密に書く代わりに、テスターがシステムと向き合いながら検証を進めるアプローチである。
なお、これらはソフトウェアテストの国際規格ISO/IEC/IEEE 29119でも用いられる用語である。
CSAはFDAが2022年9月にドラフトを公表し、2025年9月24日に最終ガイダンスを発行した。
さらに、QMSR（医療機器品質マネジメントシステム規則）が2026年2月2日に発効したことを受け、2026年2月にはこれと整合する現行版が2025年版を置き換えた。
現行版の正式名称は「Computer Software Assurance for Production and Quality Management System Software」であり、医療機器の製造または品質マネジメントシステムの一部として用いられるコンピュータ・自動データ処理システムを対象とする。
その骨子は、リスクに応じてスクリプトテストとアンスクリプトテスト（アドホック・探索的・エラー推測）を適切に使い分け、ドキュメント作成に費やしていた労力を、追加の厳格さが必要な箇所の品質保証へ振り向けるという考え方ーーいわゆるCSAアプローチだ。
なぜ品質に資するのか
ここで多くの読者が抱くであろう疑問に答えておきたい。
スクリプトを書かずにテストして、本当に品質は保てるのか、と。
むしろ逆になり得る。スクリプト作成に費やしていた時間を実際のテストに振り向ければ、仕様書ベースの確認だけでは見落としやすい挙動を発見しやすくなり、品質保証の実効性はかえって高まり得る。
理由は明快だ。スクリプトテストは仕様書を起点とするため「仕様どおりに動くか」を確認する肯定的テスト（positive testing）に偏りやすい。
一方アンスクリプトテストは、システムとユーザーの実際の挙動に焦点を当て、想定外の操作や予期せぬ振る舞いを能動的に探りにいく。
いわばシステムに挑む（challenge the system）テストである。
スクリプトどおりになぞるだけでは見つからなかった欠陥が、ここで浮かび上がる。
アンスクリプトテストはスクリプトテストを置き換える万能手段ではなく、それを補完するアプローチである。
重要な機能には必要な厳格さを確保しつつ、探索的テストでカバレッジを補い、想定外の欠陥を拾い上げるーー両者は対立するものではなく、リスクに応じて併用される関係にあるのだ。
ただし、ここで誤解を断っておかねばならない。事前に詳細な手順を逐語的に書かないことと、事後の証拠記録を残さないことは、まったくの別物である。
アンスクリプトテストであっても、テストの目的、実施者、実施日、試した内容、観察結果、合否判断、必要に応じた不具合・逸脱の処理は記録しなければならない。
該当する場合には、ALCOA+の原則やPart 11／Annex 11が求める記録の完全性・信頼性の要求も、台本の有無にかかわらず引き続き満たす必要がある。削れるのは事前のスクリプト作成の労力であって、証拠記録ではないのである。
誰がやってもよいわけではない
さらに、ここは強調しておきたい。アンスクリプトテストは「台本がないのだから誰がやってもよい」ものではない。
スクリプトがないということは、テスターの判断にすべてが委ねられるということだ。何を試すべきか、どの挙動が異常なのか、どこにリスクが潜むのかーーそれを見抜くには、対象システムを高度に使いこなす熟練と、SOPおよび業務への深い理解が不可欠である。
GAMP 5 第2版が知識と経験を持つSME（Subject Matter Expert、業務精通者）によるクリティカルシンキングを重視するのは、まさにこのためだ。期待される挙動と予期せぬ挙動の双方を見抜くには、業務を深く理解した目が要る。
つまりアンスクリプトテストは、力量の低いテスターでも務まる楽な手法ではない。むしろ、対象業務・SOP・システムの意図した使用を理解した、教育訓練済みの担当者やSMEが関与すべき、相応の力量を要する手法なのである。
結び
これは「バリデーション不要論」ではない。ねらいはバリデーションを減らすことではなく、賢くする（smarter validation）ことにある。
リスクに応じて労力を正しく配分し、重要機能には厳格なテストを集中させながら、探索的なアンスクリプトテストでカバレッジと欠陥検出を補う。
限られたリソースを最も効く場所へ振り向けるための発想なのだ。
新しい発想に聞こえるかもしれない。だがGAMP 5 第2版もFDAのCSAガイダンスも、すでにこの方向を明確に指し示している。スクリプトを書く時間を、システムと向き合う時間へ。その転換を、力量ある専門家の手で実現する時が来ている。
