医療AIのプロダクト開発で、モデルの精度よりも先に答えるべき問いがあります。
「これは医療機器なのか?」
答えがYesなら、開発プロセス・組織体制・リリースサイクルのすべてが変わります。逆にこの問いを後回しにすると、「作ってから売れないことに気づく」という最悪のパターンに陥ります。この記事では、エンジニアが最低限持っておくべき規制の「地図」を描きます。
注意: 本記事は一般的な制度解説であり、法的助言ではありません。個別製品の該当性判断は、PMDA・都道府県の薬務担当・薬事の専門家に必ず確認してください。
SaMDとは何か
SaMD(Software as a Medical Device) は、国際的な規制当局の集まりであるIMDRF(国際医療機器規制当局フォーラム)が定義した概念で、ざっくり言えば「ハードウェアの一部としてではなく、ソフトウェア単体で医療機器としての目的を果たすもの」です。
日本語では「プログラム医療機器」と呼ばれ、2014年の薬事法改正(現・薬機法: 医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律)で、ソフトウェア単体が医療機器として規制対象になりました。
具体例で感覚をつかみましょう。
| 例 | 医療機器該当性の傾向 |
|---|---|
| CT画像から病変候補を検出し医師に提示するAI | 該当する方向(診断支援) |
| 心電図データから不整脈を検出するアプリ | 該当する方向 |
| 医療従事者向けの医学知識データベース・文献検索 | 非該当の方向(情報提供) |
| 院内の予約管理・シフト管理システム | 非該当(業務システム) |
| 健康な人向けの歩数・睡眠記録アプリ | 非該当の方向(ヘルスケア用途) |
該当性はどう判断されるのか
日本では厚生労働省が「プログラムの医療機器該当性に関するガイドライン」を公開しており、判断の軸は大きく2つです。
- 使用目的: 疾病の診断・治療・予防に使用されることを目的としているか
- リスク: 機能に障害があった場合に、人の生命・健康にどの程度影響するか
エンジニア的に重要なのは、該当性は「技術」ではなく「使用目的(意図)」で決まるという点です。同じ画像解析モデルでも、
- 「研究用です。診療には使いません」→ 研究用途として規制外で運用できる余地
- 「医師の診断を支援します」→ 医療機器該当の方向
と、何を謳うか(ラベリング・広告を含む)で扱いが変わります。だからこそ、プロダクトの企画段階——READMEやランディングページの文言を書く段階——から規制の視点が必要なのです。
クラス分類と「認証」「承認」
医療機器はリスクに応じてクラスI〜IVに分類されます(クラスが上がるほどハイリスク)。プログラム医療機器として多いのは、クラスII(管理医療機器)やクラスIII(高度管理医療機器)です。
手続きの入口も、リスクに応じて変わります。
- 認証: 認証基準があるクラスII等は、登録認証機関(民間の第三者機関)による認証
- 承認: 新規性の高いものやハイリスクのものは、PMDA(医薬品医療機器総合機構)の審査を経て厚生労働大臣の承認
さらに、事業としてやるには製造販売業の許可(体制の許可)も必要です。「モデルをデプロイすれば完了」ではなく、会社としての品質管理体制(QMS: ISO 13485ベースの省令) が求められる、という感覚を持っておいてください。
開発プロセスはどう変わるか
医療機器としてソフトウェアを開発する場合、通常のWeb開発との違いはおおよそ次のとおりです。
| 観点 | 通常のWeb/アプリ開発 | 医療機器ソフトウェア |
|---|---|---|
| 要件 | 変化を歓迎(アジャイル) | 意図した使用目的を文書化し、変更を管理 |
| 品質 | テストは自主基準 | QMS省令・IEC 62304(ソフトウェアライフサイクル)に沿った開発・文書化 |
| リスク管理 | 障害対応ベース | ISO 14971に基づく設計段階からのリスクマネジメント |
| 性能の根拠 | 社内評価でOK | 臨床評価・性能試験の根拠が必要 |
| リリース | いつでもデプロイ | 変更内容によっては一部変更承認等の手続きが必要 |
| リリース後 | 監視は任意 | 不具合報告・市販後安全管理が義務 |
特にAIモデルで問題になるのが「学習し続けるモデルとリリース管理の相性の悪さ」です。承認された性能から変わってしまうなら、再学習のたびに手続きが要るのか?——この課題に対して、あらかじめ変更計画を規制当局と合意しておく仕組み(米FDAのPCCP: Predetermined Change Control Plan、日本のIDATEN: 変更計画確認手続制度)の整備が進んでいます。「AIの継続改善と規制の両立」は、いままさに動いている面白いテーマです。
米国・欧州はどうなっているか
グローバル展開を考えるなら、最低限この2つは知っておきましょう。
- 米国(FDA): 市販前の主なルートは510(k)(既存機器との実質的同等性)、De Novo(新規だが中低リスク)、PMA(ハイリスク)。AI/ML搭載医療機器のリストをFDAが公開しており、承認事例の宝庫です。
- 欧州(MDR): CEマーキングが必要。2021年適用のMDR(医療機器規則)でソフトウェアの分類が厳格化され、多くの診断支援ソフトがクラスIIa以上になりました。
「医療機器にしない」という設計戦略
規制対応はコストなので、あえて医療機器該当を避ける設計も実務ではよく取られます。
- 診断・治療の判断には踏み込まず、業務効率化(文書作成支援、検索、転記削減)に徹する
- 判断の主体が常に医療従事者であることをUI・文言で明確にする(最終判断の自動化をしない)
- 「参考情報」の提示にとどめ、アラートや推奨のような判断誘導を避ける
ただし、これは「文言だけ変えて実質は診断機能」という脱法をすすめるものではありません。実態と表示が一致していることが大前提で、境界事例は必ず専門家・当局に相談してください。
エンジニアが持つべき3つの感覚
- 企画段階で該当性を考える。「あとで薬事対応」は手戻りが最も大きいパターン。
- 文書化を憎まない。要求仕様・リスク分析・検証記録は、規制のためだけでなく、医療という不確実性の高いドメインで品質を保つ実務的な武器になる。
- 変更管理を設計に組み込む。モデルのバージョン、学習データの来歴、性能監視の仕組みは、最初からアーキテクチャに含めておく。
まとめ
- ソフトウェア単体でも、診断・治療への寄与を目的とすれば医療機器(SaMD) になり得る
- 該当性は技術ではなく使用目的と表示で決まり、判断の枠組みは厚労省のガイドラインにある
- 該当する場合、クラス分類に応じた認証/承認と、QMS等の体制整備が必要になる
- AIの継続的改善と規制を両立させる仕組み(PCCP・IDATEN)が国内外で整備されつつある
- 「医療機器にしない」設計戦略も含めて、企画段階から規制を設計変数に入れるのがプロの動き方
規制は「面倒な壁」であると同時に、先に理解した人にとっては強力な参入障壁(moat) でもあります。次は医療AI入門で全体地図を、または医療LLMの安全設計で実装寄りの話をどうぞ。