医療機器のソフトウェアテストとは？必要な試験・規格・リスク管理を実務目線で解説

一般的なソフトウェア開発や評価の経験があっても、医療機器の開発に関わり始めると「これまでと同じテストで十分なのか」と迷いやすくなります。

医療機器では、単に仕様通り動作することを確認するだけでなく、ソフトウェアの誤動作が患者や医療従事者へ与える影響を考え、安全性に関わるリスクが適切に管理されていることまで確認する視点が欠かせません。

さらに、IEC 62304／JIS T 2304によるソフトウェアライフサイクル、ISO 14971／JIS T 14971によるリスクマネジメント、サイバーセキュリティなど、複数の要求を実際の開発・テスト活動へ結び付ける必要があります。

そのため重要なのは、規格の条文を暗記したりテストケースを大量に作ったりすることではなく、「どの要求やリスクを、どの試験で確認したのか」を説明できる仕組みを整えることです。

そこで今回は、医療機器のソフトウェアテストで押さえておきたい考え方から具体的なテスト方法、要求・リスク・証跡のつなげ方までを実務の流れに沿って整理しました！

テスト計画の作成やレビュー、監査・承認申請に向けたプロセスの見直しに役立つ全体像を確認していきます。

▼テストの種類について詳しい内容はこちら▼

医療機器のソフトウェアテストは何が違う？安全・規格・検証の全体像をつかもう！

医療機器のソフトウェアテストを理解するうえで、最初に押さえておきたいのが一般的なソフトウェアテストとの目的の違いです。

もちろん、要求された機能が正しく動くか、不具合がないかを確認することは医療機器でも重要です。

ただし、それだけでは十分とはいえません。

医療機器では、ソフトウェアの誤動作や出力の誤りが患者への危害につながる可能性を考え、要求、設計、リスクコントロール、検証結果を関連付けながら安全性を確認していく必要があります。

JIS T 2304に基づくライフサイクルとリスクマネジメントを組み合わせ、単発の試験ではなく開発プロセス全体で安全なソフトウェアを作り込むことが基本となります。

個々のテスト技法から入るより、まず「安全性をどのような根拠で説明するのか」という全体像を理解すると、その後のテスト設計も整理しやすくなります。

「バグがない」だけでは足りない！医療機器でテストが重要になる理由

一般的なソフトウェアでも不具合は問題になりますが、医療機器ではその影響が診断や治療、患者の安全へ及ぶ可能性があります。

たとえば、測定値を誤って表示する、必要な警報が作動しない、通信異常によってデータが欠落するといった問題は、単なる使いにくさでは終わらない場合があります。

そのためテストでは、正常に動くことに加えて、故障や誤入力、通信断、想定外操作が起きたときにも危険な状態へ進まないかを確認することが重要です。

さらに、「試験に合格した」という結果だけでなく、対象となる要求やリスク、実施条件、期待結果、実際の結果を追跡できる状態にしておく必要があります。

安全性はテスト工程だけで作るものではなく、要求定義、設計レビュー、リスクマネジメント、構成管理、問題解決などを含むライフサイクル全体で作り込むものです。

つまり、不具合を見つけるテストから、安全性を根拠付きで確認するテストへ視点を広げることが医療機器では欠かせません。

規格は一つだけ見ればよい？テストに関係する規格の役割を整理しよう！

医療機器ソフトウェアに関わる規格は複数ありますが、すべてを同じ目的のルールとして扱うと理解しにくくなります。

IEC 62304／JIS T 2304は、ソフトウェアの要求分析、設計、実装、検証、保守、構成管理、問題解決など、ソフトウェアライフサイクルを管理するための軸として考えると整理しやすくなります。

ISO 14971／JIS T 14971は、ハザードを特定し、関連するリスクを評価・コントロールして、その有効性を確認するためのリスクマネジメントの枠組みです。

ISO 14971:2019は2025年にも内容が確認され、現在も有効な版として扱われています。

このほか、ISO 13485は品質マネジメント、IEC 62366-1はユーザビリティ、IEC 81001-5-1／JIS T 81001-5-1はサイバーセキュリティといった役割があります。

特にネットワーク接続などを伴う医療機器では、サイバーセキュリティについても製品ライフサイクルを通じた対応が求められています。

大切なのは規格を別々にチェックすることではなく、要求・リスク・設計・検証という一連の開発活動の中で関係付けることです。

ベリフィケーションとバリデーションを混同しない！それぞれの役割を押さえよう

医療機器開発では、V&V（Verification and Validation：検証と妥当性確認）という言葉がよく使われます。

ベリフィケーションは、作成した設計やソフトウェアなどが、あらかじめ定められた要求事項を満たしているかを確認する活動です。

たとえば、ソフトウェア要求仕様に「異常を検知して一定時間以内に警報を表示する」と定めている場合、その条件通りに機能するかを試験することが該当します。

一方、バリデーションでは、最終的な医療機器が意図した使用目的や実際のユーザーニーズを満たしているかを確認します。

仕様書に書かれた内容を満たしていても、実際の医療現場で安全かつ適切に使用できなければ、製品として十分とはいえません。

そのため、医療従事者の操作、使用環境、合理的に予見できる誤使用なども含めて考える必要があります。

「仕様通りに作れているか」と「必要な医療上の目的を達成できるか」を分けて整理すると、単体・結合・システムテストと製品全体の妥当性確認を混同しにくくなります。

必要なテストを漏れなく整理！工程別・目的別に何を確認するか決めよう！

医療機器だからといって、一般的なソフトウェアテストとはまったく異なる特殊な試験だけを行うわけではありません。

単体テスト、結合テスト、システムテストといった一般的なテストレベルを基本としながら、安全性、リスク、規制要求、使用環境などの観点を加えていくことがポイントです。

また、すべての機能を同じ深さで試験すればよいわけでもありません。

プログラム医療機器では、危害につながる可能性を踏まえてソフトウェア安全クラスを設定し、そのクラスに応じた対応を行う考え方があります。

製品の用途や構成、機能の重要度、リスクによって重点的に検証する部分は変わります。

テストケースの名称を揃えることよりも、「何を保証するために、その試験を行うのか」まで明確にすることが重要です。

単体・結合・システムテスト！開発工程ごとの役割を明確にしよう

単体テストでは、関数やクラス、モジュールなど比較的小さな単位に分け、ロジックや計算処理、入力条件、例外処理などを確認します。

早い段階で問題を見つけられるため、後工程での大きな手戻りを防ぐうえでも重要です。

結合テストでは、複数のソフトウェアアイテムを組み合わせ、インターフェース、データ受け渡し、通信、処理順序などが設計通りに機能するかを確認します。

個々のモジュールが正常でも、接続部分でデータ形式やタイミングが食い違えばシステムとしては正しく動きません。

ソフトウェアシステムテストでは、統合されたソフトウェア全体がソフトウェア要求事項を満たしているかを確認します。

ここでは、機能そのものだけでなく、安全性に関係する要求やエラー処理なども対象になります。

重要なのは、同じケースを各工程で繰り返すことではなく、それぞれのレベルで何を保証するのかを決め、リスクや安全クラスを踏まえて必要な深さを設定することです。

正常系だけでは危険！異常系・境界値・状態変化を重点的に確認しよう

通常の入力で期待通りに動作することを確認するだけでは、実際の使用環境で起こる問題を十分に見つけられません。

特に医療機器では、異常が起きたときに危険な状態へ進まないことが重要な確認ポイントになります。

入力値を扱う機能では、正常値だけでなく、最小値、最大値、閾値の直前と直後、不正な形式、欠損値などを確認します。

同値分割や境界値分析を利用すれば、すべての入力を試さなくても効率よく代表的な条件を選べます。

状態を持つソフトウェアでは、状態遷移テストを使い、正常な遷移だけでなく、許可されていない遷移や想定外イベントが発生した場合も確認します。

さらに、通信断、センサー異常、電源断、データ破損、処理途中の中断など、製品構成から合理的に予見できる異常状態を洗い出します。

思いつきで異常系ケースを増やすのではなく、要求仕様とリスク分析から試験条件を導き出すことが抜け漏れ防止につながります。

患者への影響から逆算！リスクコントロールが本当に効くか検証しよう

医療機器のテストでは、機能一覧から試験項目を作るだけでなく、リスク分析からテストを逆算する考え方が重要です。

ISO 14971では、ハザードを特定し、関連するリスクを評価し、必要なリスクコントロールを実施して、その有効性を確認するという流れでリスクを管理します。

たとえば、誤った値を入力すると危険な出力につながる可能性がある場合、入力範囲の制限や警告表示、処理の停止などをリスクコントロールとして実装することがあります。

テストでは、その安全機能が通常時に存在することを確認するだけでは十分ではありません。

実際に異常条件を発生させ、期待したタイミングで制御が働き、危険な状態への進展を防げるかまで確認します。

アラーム、インターロック、フェイルセーフなどについても同様です。

さらに、試験結果をリスク分析の記録へ結び付け、どの試験がどのリスクコントロールの有効性を裏付けているかを説明できる状態にしておくことが重要です。

性能・ユーザビリティ・セキュリティも忘れない！機能以外の品質も確認しよう

ソフトウェア要求を満たしていても、処理速度が遅すぎたり、操作を誤りやすかったり、外部から攻撃を受けやすかったりすれば、安全な医療機器とはいえません。

そのため、製品特性に応じて性能、ユーザビリティ、サイバーセキュリティなどの観点もテストへ組み込みます。

性能では、応答時間、処理量、連続稼働時の挙動、大量データを扱った際の変化など、医療上の使用目的へ影響する条件を確認します。

ユーザビリティでは、実際の使用者や使用環境を踏まえ、操作ミスや表示の読み違いが危険につながらないかを確認する視点が重要です。

ネットワーク接続や外部アクセスが想定される製品では、認証、権限管理、通信、脆弱性などのセキュリティ要求も対象になります。

国内では、対象となる医療機器についてサイバーリスクを特定・評価・低減し、製品ライフサイクル全体でセキュリティを確保することが求められています。

外部ライブラリやOSなどの構成要素も含め、製品の用途とリスクに応じて必要な検証を選ぶことが大切です。

修正したら終わりではない！変更影響と回帰テストまで設計しよう

不具合を修正したとき、「修正した機能が正常に動いたので完了」と判断するのは危険です。

ソフトウェアは複数のモジュールやインターフェースが関連しているため、小さな変更でも既存機能や安全機能へ思わぬ影響が広がる場合があります。

まず必要なのが、変更したコードだけを見るのではなく、依存するモジュール、データ、通信、共通部品、リスクコントロールなどへの変更影響分析です。

その結果をもとに、修正箇所そのものを確認する再テストと、影響を受ける可能性がある既存機能を確認する回帰テストの範囲を決めます。

また、機能追加や設計変更によって新しいハザードが生じたり、既存リスクの評価が変わったりする可能性もあります。

その場合は、テストだけでなくリスクマネジメントの記録も見直す必要があります。

医療機器ソフトウェアでは開発後の保守までライフサイクルとして捉えるため、変更理由、影響範囲、実施した試験、その結果を追跡できる仕組みを最初から設計しておくことが重要です。

要求・リスクからテストケースへ！監査でも説明できる設計と運用にしよう！

医療機器のソフトウェアテストの実務で難しいのは、テストケースそのものを作ることより、「なぜこのテストが必要なのか」という根拠を残すことです。

要求仕様、リスク分析、設計、試験仕様、試験結果が別々に管理されていると、個々の資料が正しくても全体として安全性を説明しにくくなります。

そこで重要になるのが、要求からテスト結果までを追跡できるトレーサビリティです。

さらに、不具合修正や仕様変更が起きた際にも、どの要求、リスク、試験へ影響するのかを確認できる状態が求められます。

サイバーセキュリティについても、適合性確認の実施を記録・保管し、必要に応じて説明できる体制が求められています。

文書を監査のためだけに作るのではなく、開発チーム自身が品質判断を再現するための証拠として活用することがポイントです。

まず要求をテスト可能にする！曖昧な仕様をそのまま試験へ持ち込まない

よいテストケースを作るには、その前提となる要求がテスト可能な状態になっている必要があります。

たとえば、「すばやく表示する」「操作しやすい」「異常時は適切に警告する」といった要求では、試験を実施しても合格・不合格を客観的に判断できません。

「入力から何秒以内に表示する」「どの条件で、どの警告を出す」といった形で、判定できる要求へ具体化することが重要です。

入力条件、前提条件、期待される出力、性能値、エラー時の挙動などが明確であれば、試験ケースも一貫して作りやすくなります。

さらに、ソフトウェア要求だけを見るのではなく、上位のシステム要求、意図する使用、ユーザーニーズ、リスクコントロールとの関係も確認します。

要求に矛盾や抜けがある場合、テスト担当者が独自判断で補完してしまうと、後から判断根拠が分からなくなります。

テスト設計を早期から始め、テストできない要求を上流工程へ戻すこと自体を品質活動として捉えることが大切です。

「このリスクにはこの試験」と言える！要求・リスク・テストを一本につなごう

テストケースを大量に作っても、要求との対応関係が分からなければ、必要な検証を網羅できているか判断しにくくなります。

そこで、ユーザーニーズ、システム要求、ソフトウェア要求、リスクコントロール、テストケース、テスト結果を関連付けます。

要求側からテストをたどれば、試験が用意されていない要求の発見に役立ちます。

反対にテスト側から要求へ戻れば、「この試験は何を確認するために存在するのか」をチェックできます。

特に安全性に関わる要求では、リスク分析で設定したリスクコントロールがどの要求として実装され、どのテストによって有効性が確認されたのかを追跡できることが重要です。

こうした関係を一覧化する方法として、トレーサビリティマトリクスが利用できます。

単なる管理表にするのではなく、「このリスクに対してこの設計を行い、この試験結果によって有効性を確認した」と説明するための地図として使うと、レビューや変更影響分析にも役立ちます。

合否だけでは足りない！再現できるテスト仕様書と記録を残そう

テスト結果に「合格」とだけ残しても、後から同じ条件で結果を再現できなければ十分な証跡とはいえません。

テスト仕様には、対象となる要求、テスト目的、前提条件、入力値、操作手順、期待結果、合否判定基準などを明確にします。

試験を実施した際には、実際の結果に加えて、使用したソフトウェアやハードウェアのバージョン、試験環境、テストデータなども記録しておくと再現性を高められます。

ログ、測定結果、画面記録など、判定を裏付ける客観的な証拠を残すことも重要です。

不合格が発生した場合は、問題を削除して新しい結果だけを残すのではなく、問題報告、原因調査、修正、再試験まで追跡できる形で管理します。

また、サイバーセキュリティについても適合性確認の結果や関連文書を特定し、説明できる状態が必要とされています。

資料の量を増やすことが目的ではなく、第三者が後から見ても同じ判断にたどり着けるだけの情報を残すことを基準にすると、過剰な文書化も避けやすくなります。

限られた工数でも品質を守る！リスクベースで優先順位を付けよう

現実の開発では、考えられるすべての入力値や状態、組み合わせをテストすることはできません。

そこで重要になるのが、リスクに応じてテストの優先順位を変える考え方です。

患者への危害につながる可能性が高い機能、複雑なアルゴリズムを持つ箇所、複数機能から利用される共通モジュール、過去に不具合が多かった部分などは、重点的に確認する候補になります。

変更頻度が高い領域も回帰不具合が入り込みやすいため、影響を考慮して試験を厚くします。

一方で、単純にテストケース数を増やしたり、コードカバレッジの数値だけを高めたりしても、安全性に関わる重要な条件を見逃していれば十分とはいえません。

ISO 14971では、リスクの特定・評価・コントロールと、その有効性をライフサイクルを通じて管理する枠組みが示されています。

テストレビューでも「何件実施したか」ではなく、重要な要求とリスクを必要な深さで確認できているかを見ることで、限られた工数を有効に使いやすくなります。

自動化は目的ではない！回帰テストと証跡作成を効率化しよう

テスト自動化は、医療機器ソフトウェア開発でも有効ですが、自動化率そのものを目標にすると本来の目的を見失いやすくなります。

向いているのは、毎回同じ条件で繰り返す単体テスト、既存機能の回帰テスト、大量の入力データを扱う試験などです。

変更のたびに手作業で同じ確認を行っている領域から自動化すれば、短時間で安定した結果を得やすくなります。

一方、実際の操作性を評価するユーザビリティテストや、人の観察や判断が重要となる探索的な確認など、手動で実施する価値が高い試験もあります。

重要なのは、自動と手動を競わせることではなく、それぞれが得意な領域へ適切に配置することです。

また、自動テストでも、対象バージョン、試験環境、入力、期待結果、実行結果を追跡できるようにします。

ツールを導入した結果、要求と試験結果の関係が見えなくなっては意味がありません。

「重要なリスクを短時間で繰り返し確認できるか」「変更時の影響をすばやく確認できるか」を基準に自動化対象を選ぶことがポイントです。

開発・品質保証・薬事で認識をそろえる！テストをチームの品質保証活動にしよう

医療機器のソフトウェアテストをテスト担当者だけの仕事にすると、要求、リスク、規制、設計の間に情報の分断が生まれやすくなります。

開発者は設計や実装を理解し、品質保証担当者はプロセスや記録を確認し、薬事担当者は承認・認証で求められる説明を意識しています。

それぞれが別々に作業するのではなく、要求レビューやリスクレビューの早い段階から試験方法や必要な証拠を共有することが重要です。

テスト担当者が上流工程へ参加すれば、試験できない要求や、検証方法が曖昧なリスクコントロールを早期に見つけやすくなります。

また、「誰が試験を実行するか」だけではなく、誰が要求を承認し、誰がリスク評価を確認し、誰が試験結果の妥当性を判断するのかまで役割を明確にしておく必要があります。

監査や申請の直前になって記録を集める運用ではなく、通常の開発活動そのものが証跡として残る仕組みにすると負担も減らせます。

市場で得た不具合情報や脆弱性情報も次のリスク分析や設計、テストへ戻し、ライフサイクルを通じて品質を改善する体制につなげることが大切です。

まとめ｜テストの数ではなく「安全を説明できる仕組み」を作ろう！

医療機器のソフトウェアテストでは、単体テスト、結合テスト、システムテストを実施するだけでは十分ではありません。

患者や使用者への影響を考え、どのリスクをどのような要求・設計によって低減し、それをどの試験で確認したのかを説明できる状態まで作ることが重要です。

IEC 62304／JIS T 2304によるソフトウェアライフサイクルと、ISO 14971／JIS T 14971によるリスクマネジメントを切り離さず、要求、設計、テスト、結果を一つの流れとして管理すると全体像を整理しやすくなります。

ネットワーク接続などを伴う医療機器では、サイバーセキュリティも開発時だけの確認事項ではなく、市販後を含むライフサイクル全体で管理する必要があります。

必要以上にテストケースや文書を増やすのではなく、重要な要求とリスクを特定し、そこへ重点的に検証工数を配分することも欠かせません。

まずは現在のプロジェクトについて、要求、リスクコントロール、テストケース、試験結果が互いに追跡できるかを確認すると、改善すべきポイントが見えやすくなります。

最終的に目指したいのは、「医療機器だから多くのテストを実施した」という状態ではなく、「この試験結果があるから、この要求とリスクについて安全性を説明できる」と論理的に示せる状態です。

QA業務効率化ならPractiTest

テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！

この記事の監修

Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。

記事制作：川上サトシ（マーケター、合同会社ぎあはーと代表）