独立型ソフトウェア医療機器（SaMD）許可ガイドライン

要点サマリー — SaMD審査の最初の問いは、コードではなく「このソフトウェアの使用目的は何か」です。医療機器に該当するかどうかも、クラス分類も、臨床資料の要否も、すべて使用目的から分かれます。そして実務のボトルネックは、たいてい一カ所で生じます — 開発をすべて終えた後に、IEC 62304の文書を遡って作ろうとするときです。

ハードウェアがなくても医療機器になる

独立型ソフトウェア医療機器（SaMD、Software as a Medical Device）とは、専用ハードウェアに組み込まれることなく、汎用コンピュータやスマートフォン上でそれ自体が医療目的を果たすソフトウェアを指します。画像から病変の疑い部位を提示する読影支援プログラム、生体信号を解析して不整脈の可能性を知らせるアプリ、認知療法を提供するデジタル治療機器などがこれに当たります。

韓国ではデジタル医療製品法の施行以降、こうしたソフトウェアが「デジタル医療機器ソフトウェア」という名称で管理され、MFDS（韓国食品医薬品安全処、旧KFDA）が別途の許可・審査ガイドライン（民願人向け案内書）を設けています。名称は変わりましたが、審査の骨格は同じです。医療機器か否かを分けるのは技術ではなく、標榜する使用目的です。心拍数を表示するだけならウェルネス製品であり得ますが、「不整脈の可能性を知らせる」と書いた瞬間に、医療機器としての判断領域に入ります。

この境界線は、MFDSが独立した判断基準（「医療機器と個人用健康管理（ウェルネス）製品の判断基準」）を設けているほど、実務で頻繁に争点となる部分です。たとえばスマートフォンで心拍数を測定し記録・表示するにとどまるアプリは、日常的な健康管理用のウェルネス製品と判断され得ますが、同じ測定値をもとに「不整脈の可能性」や「医師への相談が必要」と通知するアプリは、疾病のモニタリング・診断補助を標榜したものと読まれ得ます。実際に、心拍数・酸素飽和度の測定アプリでは、判断基準が整備される前に医療機器該当性をめぐる論争が起き、市場参入が数カ月遅れた事例がありました。機能ではなく文言が規制上の位置づけを決める — SaMDの企画段階で真っ先に心に留めるべき原則です。

クラス分類は情報の「重み」で分かれる

SaMDのクラスは、そのソフトウェアが提示する情報が診療上の判断にどれだけ関与するか、そして対象となる患者の状態がどれだけ重篤かの組み合わせで検討されます。国際医療機器規制当局フォーラム（IMDRF）の枠組みが、韓国の分類にも織り込まれています。

情報の役割	例	通常の検討の方向性
情報の表示・管理が中心	医用画像の伝送・閲覧、測定値の記録	低いクラスの範疇
診断・治療の「補助」	病変疑い部位の提示、読影の優先順位の提案	クラスII〜IIIの範疇
診断・治療の判断に直接関与	疾病の有無・重症度の判定、治療反応の予測	クラスIIIの範疇

同じアルゴリズムでも、「参考情報の提供」と「診断」ではクラスが変わり得ます。クラスが決まれば手続きの大枠は一般の医療機器と同じで — 通常、クラスIIの認証で約3〜4カ月、クラスIIIの許可で約6〜8カ月 — 全体の構造は申告・認証・許可の違いガイドで確認できます。

準備文書の全体地図

SaMDの技術文書は、ハードウェア医療機器の「試験成績書の束」とは性格が異なります。完成品を試験所に送って受け取る成績書よりも、開発プロセスそのものを証明する文書の比重が大きくなります。

領域	根拠規格	主な成果物
ソフトウェアライフサイクル	IEC 62304	開発計画書、要求仕様書、アーキテクチャ設計、検証・妥当性確認（V&V）報告書
リスクマネジメント	ISO 14971	リスク分析、リスクコントロール措置と残留リスク評価
ユーザビリティ	IEC 62366-1	使用関連リスク分析、形成的・総括的評価
サイバーセキュリティ	MFDSガイドライン・IEC 81001-5-1参照	セキュリティ要求事項、脅威分析、試験資料

ここで二つの点が実務上の分かれ道になります。第一に、IEC 62304ではソフトウェア安全性クラス（A/B/C）に応じて要求される文書の深さが変わりますが、このクラス判定を後回しにすると、文書セット全体を組み直すことになりかねません。クラス別の差は具体的です。誤動作しても危害の可能性がないクラスAは要求仕様書とリリース文書のレベルで整理し得ますが、クラスBからはアーキテクチャ設計とユニット検証・統合試験の文書が加わり、重篤な危害の可能性があるクラスCではさらにアルゴリズム・データ構造レベルの詳細設計と全工程にわたるトレーサビリティの立証まで求められるのが通常です。クラス判定の根拠がリスクマネジメント（ISO 14971）の結果と噛み合っていなければならない点も、よく見落とされます。第二に、サイバーセキュリティ資料は、ネットワーク接続やデータ保存があるソフトウェアであれば事実上の必須準備物です。何をどこまで用意すべきかは、ソフトウェアのサイバーセキュリティ審査ガイドで別途扱っています。これらの文書が集まって技術文書の骨格を成します。

性能・臨床的根拠が必要になる場合

すべてのSaMDに臨床試験が必要なわけではありません。ただし「診断補助」「予測」「治療」のように臨床的判断へ介入する標榜を行うのであれば、その標榜を裏づける性能の根拠 — 感度・特異度といった分析的性能、さらには臨床的有効性の資料 — を求められるのが通常です。既存の文献や後ろ向きデータで代替できるのか、前向き臨床が必要なのかは、標榜文言の強さと製品特性によって変わります。標榜を一段階下げることで臨床の負担が大きく減る場合もあり、標榜の設計がそのまま開発期間の設計になることもあります。

AIベースSaMD特有の論点

AI・機械学習が入ると、審査での問いが二つ増えます。「何で学習したのか」と「変わったときにどう管理するのか」です。学習・検証データの出所と代表性、学習用データと性能評価用データの分離が資料の核心であり、再学習によって性能が変わり得る製品では変更管理計画も併せて検討されます。どのような変更が審査の対象になるかは変更許可ガイドに整理しました。MFDSはAIを適用した医療機器、さらには生成AI医療機器についての許可・審査ガイドラインまで公表しており、参照できる基準文書はむしろ充実している方です。

手続きと期間

品目・クラスの確認 → 安全性クラスの判定と文書セットの設計 → 技術文書の作成・性能根拠の確保 → 許可（認証）申請・補完対応 → KGMP審査、という順序が一般的です。ソフトウェアであってもKGMPが免除されることはなく、開発・構成管理のプロセスが品質システム審査の中心になります。期間は通常、クラスIIの認証で約3〜4カ月、クラスIIIの許可で約6〜8カ月であり、臨床資料が必要な場合はその準備期間が別途加わります。

ただし、各段階が必ず直列に進むわけではありません。技術文書の作成と性能根拠の確保はかなりの部分を並行して進められますし、申請後の補完対応期間にKGMP審査の準備を並行させるのも一般的な進め方です。とりわけソフトウェア企業が初めてKGMPを準備する際は、イシュートラッカーやバージョン管理の履歴といった開発ツールの記録を品質記録へつなぎ込む作業に、思いのほか手間がかかります。開発の初期段階から記録の体系を審査の視点で整理しておけば、後半のボトルネックは目に見えて小さくなります。

よくある差戻し・補完の理由

• 使用目的の標榜と性能根拠の不一致 — 「診断補助」を標榜しながら分析的性能の資料しか提出していない
• IEC 62304文書間のトレーサビリティの断絶 — 要求事項・設計・試験項目が互いに紐づいていない
• ソフトウェア安全性クラスの判定根拠が未記載、または過小に判定されている
• サイバーセキュリティ資料の欠落 — ネットワーク機能があるのにセキュリティ脅威分析がない
• AI製品における学習データと性能評価データの分離が立証されていない
• ユーザビリティ評価を開発完了後に形式的に実施しただけと見られる形跡

着手前チェックリスト

• 標榜する使用目的の文言を確定 — 医療機器該当性・クラスの出発点
• 品目名・クラスの確認、類似の許認可事例の調査
• IEC 62304の安全性クラス（A/B/C）の判定と、文書セットの範囲設計
• リスクマネジメント（ISO 14971）・ユーザビリティ（IEC 62366-1）の計画策定
• ネットワーク・データ機能のリスト化 → サイバーセキュリティ資料の範囲確認
• 性能・臨床的根拠の水準の決定（文献・後ろ向きデータ・前向き臨床）
• AI製品であれば、学習データの仕様書と変更管理基準のドラフト準備

---

SaMDは、同じアルゴリズムであっても標榜文言ひとつでクラスと臨床の負担が変わる品目です。現在お使いの製品紹介文と機能一覧さえあれば、無料事前レビューにて、医療機器該当性と必要な文書セットの骨格をまず確認いたします。