「これで本当に認証が通るのか」という不安を抱える開発責任者やエンジニアの方に向けて、今回から全4回の「医療機器・規格適合特集」をお届けします。当社のプロジェクトマネージャーである高木さんへのインタビューを通じ、開発現場で本当に避けるべきリスクと、その具体的な対策を整理していきます。
第1回となる今回は、プロジェクトのタイムラインを根底から覆す「最大の手戻り」の正体に迫ります。
医療機器開発における「内製化」のハードルは、技術そのものよりも、その背後にある法規制や規格への適合にあります。
【本記事は、特にこのような課題を抱える方に向けた記事です】
・「自社のシステム、この医療機器クラスの想定で開発を進めて大丈夫か?」と、不安を抱えている開発責任者の方
・優れた医療用アルゴリズムはあるが、薬事規制や適合プロセスの全体像がまだ見えていない企業の技術責任者の方
・認証/承認審査に提出したあとで、根本的なやり直しを命じられるリスクを何としても避けたい方
【医療機器・規格適合特集(全4回)】
第1回:安全クラス分類の誤認と手戻りリスク(本記事)
[第2回:AI時代に“規格適合チェック”を人に頼む理由(次回)]
[第3回:かゆいところに手が届くスポット診断の選択肢]
[第4回:お客様が“自走できる”ようになる規格適合支援]
——医療機器の開発を自社で進める(内製化する)企業が増えていますが、規格への適合において、最も避けるべき「手戻り」とはどのようなものでしょうか?
高木: 最もインパクトが大きく、何としても回避すべきなのは、ソフトウェアの「安全クラス分類」における誤認です。
医療機器は不具合発生時の人体へのリスクに応じて「一般医療機器(クラスI)」から「高度管理医療機器(クラスIV)」の4段階に分類されます。また、医療機器プログラムの国際規格である「JIS T 2304(IEC 62304)」では、患者やユーザーへのリスクの大きさに応じて、ソフトウェアの安全クラス(A、B、C)を決定することが要求されます。
これは、医療機器のリスクマネジメント規格「JIS T 14971(ISO 14971)」と密接に連携した活動で、開発するシステムに潜むリスクと、その対策の力点を見極める極めて重要なプロセスです。
——具体的に、どのような誤認が起きるのでしょうか?
高木:例えば、医療機器クラスⅡ(管理医療機器)のつもりでプロジェクトを進めていたものの、実は「承認」が必要なクラスⅢ(高度管理医療機器)に該当することが、当局から指摘されるようなケースや、開発チームが「このシステムならソフトウェア安全クラスはBだろう」と判断したものの、最終審査の段階になって「ソフトウェアの安全クラスはCです」と指摘されるケースが考えられます。
——なぜ、そのような誤認が起きてしまうのですか?
高木: 理由は大きく分けて2つあります。
1つ目は、開発の初期段階で前提条件を確定させていないことです。まずは医療機器の使用目的を明確にし、一般的名称や認証基準が存在するのか、どのクラス分類に該当するのかを確認してから開発を進める必要があります。ここが未決のまま進めてしまうことが、大きな手戻りの原因になります。特に新規性の高い製品では判断が難しいケースもありますが、PMDA(医薬品医療機器総合機構)の全般相談を活用すれば、クラス分類についてのアドバイスを受けることができます。
そして2つ目、こちらが本題ですが、薬機法のクラス分類とJIS T 2304のソフトウェア安全クラスが完全にリンクしないことです。
JIS T 2304では、ソフトウェアの不具合は100%発生し得るという前提に立ち、故障した際の影響(重篤度)のみでリスクを評価します。そのため、「発生確率×重大度」で考える薬機法のリスク評価とは考え方が少し異なります。その結果、医療機器としてはクラスⅡだが、ソフトウェアの安全クラスは最高レベルのCといった事態が起こり得るのです。

——クラスBとクラスCとでは、何がそんなに違うのですか?
高木:主にはソフトウェア詳細設計の工程とその検証に厳密さが求められることです。付随してリスクマネジメントに関わる活動を見直しが必要になりますし、最悪の場合はソフトウェア全体のリスクを下げるために、初期の設計プロセスからやり直すこともあり得ます。これこそが、プロジェクトのタイムラインを根底から覆す、最も避けるべき致命的な手戻りです。
——そうした事態を防ぐために、どのような検証が必要なのでしょうか。
高木:当社では薬機戦略の立案・検討に伴走し、医療機器の特性を整理、一般的名称は何であるか、医療機器の範囲はどこまでかをお客様と一緒に整理します。
さらに、当社が提供している「規格適合スポット診断」では、まさにそうした「これで本当に医療機器として承認・認証が取れるか」という観点と、「そのクラスに対して妥当な設計・検証プロセスが踏まれているか」というエンジニアの客観的な目線で網羅的にチェックします。
例えば「ソフトウェアアイテムをどう分割するか」といった、開発実務に即した踏み込んだアドバイスも可能です。開発プロセスの手戻りは、早ければ早い段階で気づくほど、コストも時間も最小限に抑えられます。
【本記事のまとめ】
第1回のポイントをまとめます。医療機器開発の内製化を進める上で、持って帰っていただきたい最大の教訓は以下の2点です。
・大きな手戻りリスクの1つに、医療機器クラスおよびJIS T 2304(IEC 62304)における「ソフトウェア安全クラス(A/B/C)の誤認」がある
・最終審査でのクラスBからCへの変更は、初期設計プロセスの見直しを含む甚大な影響を及ぼす
開発プロセスの初期段階で正しいルートを選べているか不安な方は、ぜひお気軽にご相談ください。
リベルワークスでは、医療機器認証における「規格に適合しているか」のチェックに特化したサービスを提供しています。
・「この医療機器クラス分類の判断で、本当に審査に通るか不安」
・「JIS T 2304(IEC 62304)や サイバーセキュリティ(IEC 81001-5-1)の対応漏れがないかチェックしたい」
・「一般的な方針論のコンサルではなく、成果物の実務レベルのフィードバックがほしい」
医療機器開発の内製化に挑む企業様の不安を一つ一つ解消し、必要なプロセスや成果物の適合性をエンジニア目線でサポートいたします。
「規格適合チェックサービス」詳細はこちら





