医療系のシステム開発に携わってきたエンジニアの間で、プログラム医療機器（SaMD）に関わる案件への関心が高まっています。通常のソフトウェア開発の経験に加えて、薬事の手続きや品質管理の視点が重なる分野のため、参入のハードルを高く感じる場面もあります。この記事では、医療機器該当性の見極めから開発・承認・市販後の改良まで、エンジニアが押さえておきたい流れを整理します。自分の経験がどこで活きるのかを確かめながら読み進めてください。

1. なぜいま医療機器ソフトウェア（SaMD）の案件が増えているのか

ソフトウェア単体が医療機器として扱われる時代

医療機関や患者が使うソフトウェアは、機器に組み込まれた一部としてだけでなく、単体のプログラムとしても医療機器に位置づけられるようになりました。診断を支援するアプリや、治療計画を提示するソフトウェアなど、画面の中だけで完結する製品が広がってきたことが背景にあります。クラウドやスマートフォンを介して提供される医療系ソフトウェアが増えたことも、この流れを後押ししています。

プログラム医療機器の枠組みでは、影響の小さい一般医療機器（クラスI）という区分が存在せず、意図したとおりに機能しない場合に生命や健康への影響がほとんどないと言えるもの以外は規制の対象になります¹。

この区分の有無は、設計段階でどこまで慎重に検証を積むかを左右します。意図しない誤動作が生じた場合にどのような影響が及ぶかを、機能ごとに想定しておく視点が、通常のアプリ開発より重視されます。

アプリ開発の感覚だけで案件を引き受けると、想定より対応範囲が広く感じられる場面があります。操作性の作り込みよりも、規制の枠組みを踏まえた設計の順番のほうが、後戻りの少なさを左右します。次章では、どこから医療機器に該当するのかを具体的に見ていきます。

出典：PMDA「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）をもとに作成

エンジニアの視点から見た参入のしやすさ

規制という言葉から距離を感じる方もいますが、要件定義・設計・テスト・保守という開発の骨格そのものは、一般的なソフトウェア開発と大きく変わりません。API設計やセキュリティ対策、テスト自動化の経験は、そのままこの領域でも通用する土台になります。

違いが出るのは、その工程をどう記録し、後から追跡できる形に残すかという点です。普段から仕様書やテストケースを整備してきたエンジニアほど、移行の負担は小さく感じられます。

設計書やAPI仕様、テスト結果を残す習慣そのものは、日頃の開発でも実践してきた工程です。その粒度を医療機器向けに厚くしていく、という捉え方で始められます。エラー処理やログの残し方といった、普段は後回しにされがちな部分が、この領域では最初から評価の対象になります。

2. 医療機器該当性の見極め（どこから医療機器か）

開発の早い段階で確認する理由

開発中のソフトウェアが医療機器に該当するかどうかは、企画や設計の初期段階で確認しておくことが重要です²。仕様が固まった後で該当性が判明すると、設計のやり直しや、必要な文書の後付けが発生しやすくなります。

ソフトウェアを作り込んでから該当性を確認する進め方は、手戻りの範囲を広げがちです。要件定義の段階で、医療機器該当性という観点をチェックリストに加えておくほうが、開発全体の見通しは立てやすくなります。レビューの初回から、この観点を議題に含めておくと、後工程での手戻りを抑えやすくなります。

該当性を判断する視点の例

医療機器該当性の判断は、ソフトウェアが何を目的としているか、その結果を誰がどう使うかによって変わります。診断や治療方針の決定に直接関わるか、単なる情報の記録や共有にとどまるかは、判断の分かれ目になりやすい観点です。同じ機能でも、想定する利用シーンが変わるだけで判断が変わることもあります。以下は、開発現場で確認されることが多い視点の例です。個々の製品の該当性は、資料を参照しながら確認する必要があります。

確認する視点	該当性が高まりやすい例	該当性が低くなりやすい例
ソフトウェアの目的	診断や治療方針の決定を支援する	情報の記録や共有にとどまる
結果の使われ方	医療従事者の判断に直接影響する	参考情報として提示するだけ
対象とする状態	疾病の診断・治療・予防に関わる	健康管理や生活支援が中心

この視点を意識しておくと、企画段階の会話で「これは医療機器に当たるか」を早めに言葉にできるようになります。判断に迷う場合は、独自に結論を出さず、薬事担当や資料に照らして確認する姿勢が欠かせません。仕様書に判断の根拠を残しておくと、後から見直す際の手間も抑えられます。

出典：PMDA「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）をもとに作成

該当性は一度で終わらない

医療機器該当性の判断は、開発の初期に一度行えば終わりというものではありません。仕様追加や利用目的の変更があるたびに、該当性の評価を見直す必要があります。小さな機能追加のつもりが、結果として届出や承認の要否に影響することもあります。特にAIやクラウド連携を追加する改修は、見た目の変更が小さくても、医療機器としての性質を変える場合があるため注意が必要です。

該当性の判断は一度きりではなく、仕様変更のたびに見直す観点でもあります。次章では、該当した後に開発現場で対応する基本要件基準を具体的に見ていきます。

3. 開発で押さえる基本要件基準（ライフサイクル・サイバーセキュリティ・ユーザビリティ）

ソフトウェア開発ライフサイクルプロセスへの対応

プログラム医療機器では、基本要件基準への対応の一つとして、ソフトウェア開発ライフサイクルプロセスへの対応が求められます³。要件定義・設計・実装・検証といった工程を、後から追跡できる形で記録に残す進め方です。

一般的なアジャイル開発の感覚だけで進めると、記録の粒度が追いつかなくなる場面があります。変更履歴やレビューの証跡を、機能の実装と同じ比重で扱う姿勢が問われます。

設計変更のたびに、変更理由と影響範囲を記録に残す運用は、ソフトウェアテストの現場で行われてきたリグレッション管理と近い発想です。すでに近い運用を経験しているエンジニアであれば、大きな戸惑いなく対応を進められます。テスト項目と設計書を紐づけて管理する習慣も、そのまま活かせる工程です。

サイバーセキュリティとユーザビリティへの対応

基本要件基準の改正により、サイバーセキュリティに関する第12条第3項が令和5年3月に追加され、プログラム医療機器にはこの対応が求められています⁴。接続環境との関わり方は製品によって異なるため、どこまでの対策が必要かは個々の設計に応じて確認する必要があります。

操作性（ユーザビリティ）についても、医療従事者や患者が誤った操作をしにくい設計が求められます。機能を作り込む力よりも、使われ方を想定して抜け漏れを潰す力のほうが、この領域では評価されやすくなります。画面のレイアウトやエラーメッセージの出し方一つが、誤操作の起きやすさを左右します。

基本要件基準への対応は、開発の後半でまとめて行うものではなく、工程ごとに積み重ねる性質を持ちます。以下は、プログラム医療機器の開発で押さえる主な要素と、開発現場での関わり方を整理したものです。個々の製品でどこまで対応が必要かは、資料を参照しながら確認します。

要素	求められる対応の例	開発現場での関わり方
ソフトウェア開発ライフサイクル	工程ごとの記録と追跡可能性の確保	設計書・変更履歴・レビュー記録の整備
サイバーセキュリティ	接続環境を踏まえた対策の実装	脆弱性への対応方針の策定と反映
ユーザビリティ	誤操作を防ぐ画面設計の検証	利用者の操作を想定した検証設計

ライフサイクル・サイバーセキュリティ・ユーザビリティの3つは、別々に対応すればよいものではありません。設計変更が生じるたびに、記録の更新、セキュリティへの影響確認、操作性への影響確認を合わせて行う必要があり、開発の初期からこの3つを一体として扱う視点が問われます。

出典：PMDA「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）をもとに作成

記録と追跡可能性が問われる理由

基本要件基準への対応で重視されるのは、機能そのものよりも、その機能がなぜその仕様になったのかを後から説明できる状態です。設計判断の根拠や、レビューでの指摘とその対応を、時系列で追える形に残しておく必要があります。後から資料を確認する担当者が、経緯を追いやすいことが重視されます。

テスト自動化やコードレビューの運用を整えてきた経験は、この記録づくりと相性の良いスキルです。すでに行っている工程を、追跡できる形に整え直すところから始められます。

4. 承認と市販後の改良（二段階承認・IDATEN）

二段階承認の考え方

プログラム医療機器の承認をめぐっては、段階的に承認を進める「二段階承認」の考え方が示されています⁵。最初から完成形を求めるのではなく、段階を分けて確認を進める考え方です。

一度にすべての機能を固めて申請するよりも、段階を分けて確認を進める設計のほうが、開発側にとっても見通しを立てやすくなります。どの機能をどの段階に位置づけるかは、企画の初期から意識しておきたい観点です。

段階を分けて確認する考え方は、機能を絞った最小限の形でまず動かし、そこから拡張していく開発の進め方とも重なります。一度にすべてを作り込もうとしないことが、承認の見通しを立てやすくする一因になります。どの機能を先に固め、どの機能を後の段階に回すかという設計判断そのものが、開発者に求められる役割になります。

市販後も改良を続けるIDATEN制度

AIを活用した医療機器など、市販後に性能が変化する製品向けには、変更計画をあらかじめ確認し、計画の範囲内で迅速な一部変更を認めて継続的な改良を可能にするIDATEN制度があります⁶。一件ごとに都度申請する仕組みと比べ、計画に沿った改良を継続しやすくする制度です。

市販後もモデルの精度改善やアルゴリズムの更新を続ける前提の製品であれば、この制度を踏まえた開発計画が欠かせません。機械学習を扱ってきた経験は、この領域で活かしやすいスキルの一つです。学習データの管理体制も、計画づくりの一部として問われます。

出典：PMDA「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）をもとに作成

エンジニアが備える改良の準備

IDATEN制度を活かした継続的な改良は、開発側が変更計画をあらかじめ整理し、想定される変更の範囲と検証方法を明確にしておくことが前提になります。モデルの再学習や機能の見直しを、都度の申請ではなく計画に沿って進められる形に設計しておく視点が求められます。

検証データの管理やモデルの性能評価を継続的に行ってきた経験は、この計画づくりに直接活きます。運用を止めずに改善を積み重ねる開発スタイルに慣れているエンジニアほど、なじみやすい領域です。

5. リモート・フリーランス案件でどう関わるか（開発・品質・薬事・見極め）

求められる役割は開発だけではない

SaMD領域の案件は、実装を担当するエンジニアだけでなく、品質保証や記録整備、薬事とのやり取りを支える役割でも人材が求められています。プログラミングの力に加えて、工程を記録に残す几帳面さが評価されやすい分野です。

クラウド上で動くソフトウェアや、モバイル端末で使うアプリなど、扱う技術自体は一般的な開発と共通する部分があります。開発の技術力に、記録を残す几帳面さを重ねられるかどうかが、この領域に向いているかどうかの目安になります。

医療機関に常駐する働き方だけでなく、設計書のレビューやドキュメント整備など、場所を選ばない形で関わる案件も広がっています。

SaMD領域の案件は、担う役割によって求められる経験が変わります。以下は、リモートで関わりやすい役割の類型を整理したものです。積み上げてきた経験がどの類型に近いかを確かめる材料にしてください。

関わり方の類型	主な作業内容	活きる経験
ソフトウェア実装	要件に沿った設計・実装・単体検証	記録を残しながら進める開発経験
品質保証・記録整備	ライフサイクルの記録、レビュー証跡の整備	品質管理やドキュメント整備の経験
薬事対応の支援	該当性の整理、申請資料の準備支援	規制文書を読み解く経験

手を動かす速さよりも、後から誰が読んでも分かる記録を残す丁寧さのほうが、この領域では評価につながりやすい観点です。積み上げてきた開発経験を、この視点で棚卸ししてみましょう。

経験の伝え方を整える

SaMD領域の案件では、担当してきた工程を具体的に言葉にできるかどうかが、経験を伝える際の分かれ目になります。「開発を担当した」ではなく、「要件定義から検証まで、どの記録をどう残しながら進めたか」を言語化しておくと、経験が伝わりやすくなります。実績を語る際は、成果物だけでなく、途中の検証や修正の過程も含めて伝えると、記録を重んじる姿勢が伝わりやすくなります。

品質保証やドキュメント整備に携わった経験も、遠回りではなく直接活きる経験として棚卸ししておきたいところです。

6. まとめ

プログラム医療機器の開発は、通常のソフトウェア開発の力に加えて、該当性の見極め、基本要件基準への対応、承認や市販後の改良という薬事の視点が重なる領域です。専門知識のすべてが求められるわけではなく、工程を記録に残す姿勢や、使われ方を想定して抜け漏れを潰す視点が土台になります。

該当性の見極めから基本要件基準への対応、承認、市販後の改良まで、一つひとつの工程は、これまでの開発経験の延長線上にあります。特別な資格や医療分野での実務経験がなくても、記録を残しながら進める姿勢を土台に関わっていくことができます。

医療の専門でないことを理由に案件を遠ざけてしまうと、積み上げてきた開発経験を活かす機会を狭めることにもなります。案件の90%以上がフルリモート可能です⁷。積み上げてきた経験がどの役割で活きるのか、まず確かめてみましょう。

医療機器該当性やライフサイクル対応という言葉に身構える前に、これまでのスキルを一度棚卸しし、まず登録して自分に合う条件を確かめてみてください。

7. よくある質問

医療の専門でなくても関われますか

医療の専門知識をゼロから求められる案件ばかりではありません。該当性の見極めや基本要件基準への対応は、資料と薬事担当との連携によって進める部分が大きく、開発の力を土台にしながら知識を積み重ねていく進め方が一般的です。分からない点は薬事担当や資料で確認しながら進める体制が一般的なので、最初からすべてを把握しておく必要はありません。

どんなスキルが活きますか

要件定義から実装、検証までを記録に残しながら進めてきた経験や、仕様変更の影響範囲を丁寧に洗い出す姿勢が活きやすい領域です。特定の言語やフレームワークよりも、工程を追跡できる形で進める習慣のほうが評価につながりやすい観点です。コードの正しさだけでなく、その正しさをどう説明できるかまで考える習慣が問われます。

品質保証やライフサイクルの経験は活きますか

活きやすい経験です。ソフトウェア開発ライフサイクルプロセスへの対応³は、品質保証やテスト管理の経験と重なる部分が多く、レビュー記録や変更履歴の整備に慣れた経験は評価につながりやすい傾向にあります。特に変更管理やレビュー記録の運用経験は、そのまま活かしやすい部分です。

機械学習を使ったSaMDはどう違いますか

市販後に性能が変化する製品では、変更計画をあらかじめ確認したうえで、計画の範囲内で改良を続けられるIDATEN制度⁶が関わってきます。モデルの再学習や精度改善を前提にした開発計画を、企画の段階から意識する必要があります。検証データの扱いに慣れていることも、この領域では強みになります。

案件はフルリモートでもできますか

設計書のレビューやドキュメント整備、実装といった工程はリモートで進めやすい部分です。医療機関への常駐が必要な工程が一部に含まれる案件もあるため、案件ごとの条件は登録後に確認するとよいでしょう。案件を選ぶ段階で、常駐が必要な範囲をあらかじめ確認しておくと安心です。

ここまでの疑問が解消したら、次の一歩として登録を済ませ、積み上げてきた経験に合う案件の条件を確かめてみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 医薬品医療機器総合機構「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）
＊2 医薬品医療機器総合機構「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）
＊3 医薬品医療機器総合機構「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）
＊4 医薬品医療機器総合機構「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）
＊5 医薬品医療機器総合機構「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）
＊6 医薬品医療機器総合機構「プログラム医療機器の薬事開発・承認申請に関する手引き」（2026年5月）
＊7 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能