LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

医療に関わるソフトウェアを作ろうとすると、避けて通れない問いがあります。「これは医療機器に当たるのか」という問題です。当たるなら薬機法の枠組みに入り、開発の進め方も、必要な体制も、市販後の責任も変わってきます。当たらないなら通常の受託開発として進められます。この分かれ目を最初に確かめないまま作り始めると、後の手戻りが大きくなります。

本記事では、医療機関や医療機器メーカー向けにソフトウェアを開発する立場、あるいは自社で医療系サービスを企画する立場の担当者に向けて、プログラム医療機器の考え方、クラス分類と手続き、求められる体制、そして受託開発で問われる成果物を整理します。判断は個別性が高いため、実際には公式の資料と規制当局への相談を組み合わせて進めてください。

プログラム医療機器とは——ソフトウェア単体が医療機器になる場合

日本では、薬機法（医薬品医療機器等法）の改正により、ソフトウェア単体でも医療機器として扱われる道が整えられました。いわゆるプログラム医療機器、国際的にはSaMD（Software as a Medical Device）と呼ばれる領域です。診断や治療に用いられ、その結果が人の健康に影響を与えうるものが対象になります*1。

判断の軸は二つあります。ひとつは、そのソフトウェアが診断や治療にどう関わるのか。もうひとつは、不具合が起きたときに人へどの程度の危害が及ぶのか。この二つの組み合わせで、対象になるかどうか、そして対象になった場合にどのクラスに当たるのかが決まっていきます。

いっぽうで、対象外とされる領域もあります。一般的な健康管理を目的としたもの、医療機関の事務処理を担うもの、既存の情報を単に転記・表示するだけのもの——このあたりは医療機器に当たらないと整理されることが多いところです。ただし、機能を足していくうちに境界を越えることがあり、「健康管理アプリのつもりが、解析結果で受診を促す機能を入れた」といった変化には注意が必要です。

医療機関向けの業務システムを作る場合との違いも押さえておきましょう。電子カルテや予約、会計といった領域は通常の業務システムとして扱われます。詳しくは医療分野のシステム開発を外注する費用と進め方で扱っていますが、同じ「医療系の開発」でも薬事の枠に入るかどうかで様相が大きく変わるのです。

クラス分類と手続き——認証と承認の違い

医療機器は、リスクの程度に応じてクラスに分けられます。プログラム医療機器も同じ枠組みで扱われ、クラスによって手続きの重さが変わります。

加えて、製造販売業の許可という枠組みがあります。ソフトウェアを世に出す主体には、品質管理や市販後の責任を担える体制が求められます。開発だけを受託する立場であれば、この主体になるのは委託元です。ただし、体制の一部（設計や検証の記録づくり）は受託側が担うことになるため、「誰が製造販売業者で、どの記録を誰が作るのか」を最初に確認しておく必要があります。

近年は、プログラムの特性を踏まえた手続きの工夫も進んでいます。臨床的な意義の確立に時間がかかる領域について、段階を分けて承認を進める考え方が示されており、開発の進め方に選択肢が広がりました*2。自社の製品がこうした枠組みに乗るのかは、開発計画の初期に確かめておきたいところです。

求められる体制——品質管理と市販後の責任

医療機器として扱われると、開発の「やり方」そのものが問われます。単に良い製品を作れば足りるのではなく、決められた手順に沿って作り、その記録が残っていることが求められます。中心になるのは次の三つです。

• 品質管理の体制：設計から製造、出荷、市販後までの手順を定め、実施した記録を保持する仕組み
• リスクマネジメント：想定される危害を洗い出し、対策を設計に織り込み、残るリスクを評価して文書に残す
• 市販後の対応：不具合が生じたときの報告、更新の管理、サイバーセキュリティへの備え

ソフトウェア開発の現場感覚と、ここが最もぶつかります。素早く作って出し、使われ方を見て直していく——この進め方は、記録を残す前提と衝突しがちです。したがって現実的なのは、「変更のたびに何を残すか」を最初に決めてしまうことです。変更の理由、影響の評価、検証した内容、承認した人。この四点が自動的に残る仕組みにできれば、開発の速度をある程度保ちながら要求を満たせます。

市販後のサイバーセキュリティも、近年重みを増しています。医療機器は使われる期間が長く、公表された脆弱性への対応が問われます。部品として使っているライブラリの一覧を持ち、影響を調べられる状態にしておくこと——この備えはソフトウェアサプライチェーン対策で扱う考え方と同じです。

AI・機械学習を使う場合の論点

画像解析や予測にAIを使う場合、追加の論点が生じます。学習に使ったデータの性質、性能の評価方法、そして運用中に性能が変わりうるという性質です。

とくに扱いが難しいのが、モデルの更新です。学習をやり直して性能を上げたとき、それは「同じ製品の改良」なのか「別の製品」なのか。変更の程度によって必要な手続きが変わるため、更新の計画を最初から設計に含めておく必要があります。承認された範囲を超える変更は、追加の手続きなしには出せません。

評価の設計も要です。どのデータで、どの指標をもって性能を示すのか。開発の途中で評価用データを増やしていくと、比較ができなくなります。評価用のデータセットを凍結し、変更履歴を残す運用にしておくのが定石でしょう。この考え方は医療画像診断AIで扱っている実務の勘どころと重なります。

あわせて、個人情報の取り扱いも当然に関わってきます。学習用データの取得根拠、匿名化の程度、保管場所と権限。医療データは機微な情報として扱われるため、設計段階で線を引いておくのが確実です。

医療機関との連携で生じる論点

プログラム医療機器は、単体で完結することが少なく、医療機関の既存システムと組み合わせて使われます。ここで生じる論点を三つ挙げておきます。

第一に、データの受け渡しです。院内のシステムから検査値や画像を受け取る場合、形式と経路をどう定めるかが設計の起点になります。標準的な形式に寄せておけば、導入先が増えたときの追加開発を抑えられます。逆に、施設ごとの独自形式に個別対応していくと、保守の負担が増えていきます。

第二に、責任の境界です。解析の結果をどう提示し、最終的な判断を誰が行うのか。表示の仕方ひとつで受け取られ方が変わるため、画面の文言や注意表示は要件として明確に決めておく必要があります。ここは薬事の観点だけでなく、現場での使われ方を想定した設計が問われる部分です。

第三に、導入と運用の支援です。医療機関側では、担当者が入れ替わることも珍しくありません。手順書と教育の材料をセットで用意しておくと、導入後の問い合わせが減ります。標準型電子カルテと医療DXの流れのなかで、施設側のシステム環境も変わっていくため、連携部分は変更に耐える作りにしておきたいところです。

受託開発で押さえる実務ポイント

薬事の枠に入る案件を受託する場合、通常の開発案件とは見積りも進め方も変わります。次の五点を最初に固めておくと、後の摩擦を避けられます。

第一に、対象になるかの確認を先に行うことです。「たぶん医療機器ではない」という前提で作り始めると、後から手続きが必要になったときに設計からやり直しになります。判断が微妙なら、開発着手前に公式の考え方を確かめ、必要なら相談の場を使います。

第二に、役割分担の明文化です。製造販売業者は誰か、品質管理の体制は誰が持つのか、設計や検証の記録は誰が作るのか。受託側が担うのは通常「設計・実装・検証の実施と記録」ですが、その範囲を契約に落としておきます。

第三に、成果物の一覧です。要求仕様、リスク分析、設計文書、検証の記録、トレーサビリティの表。これらは通常の受託開発でも作りますが、薬事の枠では「様式と保管」まで問われます。テンプレートを最初に決めておくと、後半の手戻りが減ります。

第四に、変更管理の手順です。開発中の変更、承認後の変更、市販後の更新。それぞれで必要な作業が違います。とくに承認後の変更は、手続きの要否を判断する仕組みが必要になります。

第五に、運用フェーズの取り決めです。不具合の報告、問い合わせ対応、脆弱性の調査と更新。保守契約に含めるのか別枠にするのかを決め、体制を確保しておきます。医療機器は使われる期間が長いため、ここを曖昧にすると後々負担が偏ります。

まとめ：プログラム医療機器の開発で押さえる3つの視点

医療に関わるソフトウェアは、診断や治療への関わり方と危害の程度によって、薬機法上のプログラム医療機器として扱われることがあります。押さえたい視点は三つです。第一に、対象になるかの判断を開発着手前に行うこと。境界に近い機能を足していくうちに枠へ入ることがあるため、企画段階での確認が欠かせません。第二に、対象になった場合はクラスに応じた手続きに加え、品質管理の体制とリスク分析・設計・検証の記録が求められ、開発の進め方そのものが変わること。第三に、受託開発では役割分担と成果物の様式、変更管理の手順、市販後の対応範囲を契約段階で固めることが実務の要になることです。まずは自社の企画が枠に入るのかを確かめ、入るなら記録が自然に残る開発の型を用意するところから始めてみてください。

よくある質問

出典

1. *1　参考：厚生労働省「医療機器プログラムについて」（https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000179749_00004.html）。プログラム単体が医療機器として扱われる考え方と該当性の判断に関する公式情報の参考として（2026年8月確認）
2. *2　参考：独立行政法人 医薬品医療機器総合機構（PMDA）「プログラム医療機器」（https://www.pmda.go.jp/review-services/drug-reviews/about-reviews/devices/0048.html）。審査・相談の枠組みと、プログラムの特性を踏まえた手続きに関する公式情報の参考として（2026年8月確認）

Tweet