医療機器ソフトウェア開発 ― スタートアップのための”後悔しない”実践ガイド 　連載第1回

JPUSリコール事例と「日米規制のギャップ」から学ぶ“負けない開発”の原則

まだ「自分には関係ない」と思っていませんか？

2024年、アメリカで報告された医療機器ソフトウェアのリコール件数は前年比134.5%増。
影響台数は、なんと5億8千万ユニットにものぼりました。
いまや医療機器は、ハードではなくソフトウェアの品質が安全性を左右する時代。
そんな中で「アプリだから軽く始められる」と考えることは、致命的なリスクになり得ます。

【事例で学ぶ】なぜリコールは起こるのか？

📱 ケース1：インスリンポンプ連携アプリ（米国・クラスIリコール）

• 対象：t:slim X2（iOS版アプリ v2.7）

• 不具合：アプリがクラッシュ → Bluetooth暴走 → ポンプ電池が急速に消耗 → インスリン投与が停止

• 結果：224件の傷害報告／対象デバイス8.5万台以上／最重大のクラスIリコール判定

💡 教訓： 通信や電源との連携は“軽視できない”設計項目です。

📶 ケース2：遠隔モニタリングアプリ Health Harmony（米国・クラスII）

• 対象：遠隔患者管理システム（スマホアプリ＋クラウド連携）

• 不具合：通信不安定・アプリ終了時に例外処理が不完全 → 患者データが1～2日同期されず、診療判断が遅延

• 影響：診断ミスや治療遅延の懸念から、クラスIIリコールへ

 💡 教訓：フェールセーフ設計（フォールトトレランス）と、通信エラー時の検知＆再送設計は不可欠。

🖥 ケース3：国内ソフトウェア起因リコール（複数）

• Seavo View（画像診断アプリ）：UIとバージョン管理のズレにより、X線画像の左右が誤表示 → 1,200ライセンスを自主回収

• 電動手術台（MOT‑VS700UIj）：Bluetooth例外処理ミスにより、停止後も昇降が継続

• パッチ型脳波計（HARU‑2）：ファーム更新でメモリずれ → 波形に周期ノイズ → 解析不能

💡 教訓：「UI設計」「通信制御」「ファーム更新」…いずれも「たった1つの見落とし」が全国規模のリコールに発展しています。

このように「仕様外の状況」や「例外パス」に潜むバグこそ、事故を引き起こす温床です。リスクマネジメントは「起きてから」ではなく、「設計段階で想像しきれるか」が勝負となります。

【整理】失敗を呼ぶ「5つのギャップ」

あなたのチームにも、当てはまるところはありませんか？

① 規制解釈ギャップ　「アプリは医療機器ではない」と思い込んでいませんか？

スマホアプリやクラウドサービスは「診断や治療に直接関係ないから医療機器ではない」と誤解されやすいですが、 “使用目的（Intended Use、意図する使用）”によっては医療機器と判断されます。
たとえば、「診療の参考となる画像を表示する」「治療データを記録・分析する」アプリは、十分に医療機器該当性があります。見逃すと、未承認販売扱いで行政指導や出荷停止につながるリスクがあります。

② プロセスギャップ　「アジャイルだからドキュメントは不要」── その誤解が命取りに。

スタートアップではアジャイル開発を採用するケースが多く、スピードを重視して「記録は後回し」「Slackに残ってるから大丈夫」となりがちです。
しかし、医療機器の審査では仕様・設計・検証の証跡（ドキュメント）が必須です。
証跡が不十分だと、承認申請時に“どの仕様に基づいて何をテストしたか”が証明できず、審査が止まるケースも。

③ 品質保証ギャップ　「とりあえず動けばいい」は、最大のリスク。

スタートアップでは限られた人員で“通しテスト（E2E）”だけで品質を担保しようとする傾向があります。しかし、E2Eは全体の動作確認には向いていても、個別の欠陥検出には不向きです。
結果として、初期の小さなバグを見逃し、後工程で機能ごと巻き込んで炎上── という事態に。
設計段階からユニット単位での検証を計画することが重要です。

④ セキュリティギャップ　「医療データじゃないから、脆弱でも大丈夫」は通用しない。

「個人情報は扱っていないからセキュリティは後回しでいい」と判断するケースは少なくありません。
しかし、通信やシステムの脆弱性が悪用されると、機器の誤作動やデータ破損により“医療安全そのもの”が脅かされます。
たとえば、遠隔モニタリングやBluetooth接続のデバイスでは、第三者からの制御・妨害が実害に直結することも。

⑤ 組織体制ギャップ　「QMS担当は兼任でOK」では、いずれ破綻する。

品質マネジメント（QMS）は、単なる書類仕事ではありません。
設計、変更管理、苦情対応、市販後調査……開発全体を“品質の視点”で横断管理する役割です。
担当者が営業や開発と兼任だと、対応が後回しになり、是正要求が積み重なって、最終的に製品開発そのものがストップする事態になりかねません。

“負のスパイラル”は、こうして始まる

1つでもギャップがあると、

１．規制を正しく理解できない
２．プロセス設計があいまいに
３．テストや品質保証が手薄に
４．セキュリティの穴が放置される
５．組織全体が後手に回る

── このような「負のカスケード（連鎖反応）」は一度起きると、リコールや開発停止に至るのは時間の問題です。
1つ1つのギャップは小さな“ひずみ”でも、組み合わさると大きな事故や損失に発展します。
だからこそ、早期に見つけて、全体最適の視点で対策していくことが大切です。

リコールの本当のコストは？

💸 損失額：最大1日500万ドル（McKinsey試算）
📉 株価：リコール後3ヶ月で平均13%下落
🛑 スタートアップ：半年以上の開発停滞も珍しくない

リコールはエンジニアだけの問題ではなく、経営リスクそのものです。
だからこそ、「どこにどんな落とし穴があるのか」を設計段階で見抜ける体制・人材・プロセスが重要なのです。

【5分で確認】あなたの開発は大丈夫？

​​下記の5項目、貴社のチームは何点取れますか？
当てはまる項目数をカウントしてください。

📊 判定と対応レベル

🧭 この5項目は、今の開発状況を“安全に進められるかどうか”を見極めるための出発点です。
少しでも不安が残る場合は、早い段階で外部の視点を取り入れるなど、将来的なリスクや手戻りを最小限に抑えることを意識しましょう。

【まとめ】組織として、どう備えるべきか？

• 開発を外注していても「どこにどんなリスクがあるか」を知っておくこと

• Intended Use （意図する使用）を明確にし、使用環境で想定されるリスクを分析・共有すること

• ISO 14971 （医療機器リスクマネジメント国際規格）などを活用し、“医療機器ならではのリスク感覚”をチーム全体で共有すること

次回「ISO13485に準拠してるのに、なぜFDAは追加質問してくるのか？」

第2回では、**ソフトウェア開発ライフサイクルと日米規制の“思想のねじれ”**を深掘りしていきます。

📬 医療機器ソフトウェア開発でお困りの方へ

「自社の開発体制、このままで本当に大丈夫だろうか？」
「海外規制も見据えた設計・文書化ができているか不安…」
そんな医療機器スタートアップ・開発チームの皆さまへ。
xCAREでは、実務経験豊富なエキスパートが並走し、後悔しない開発体制づくりを支援しています。
まずはお気軽に、現在の課題や懸念をお聞かせください。

👉 xCAREへのご相談はこちら（無料個別相談あり）

👤 執筆・監修：酒井 由夫（さかい よしお）

医療機器ソフトウェア開発コンサルタント／xCAREエキスパート
医療機器メーカーでのソフトウェア開発、規格対応支援経験を経て、外資系企業・医療スタートアップにて医療機器ソフトウェア（SaMD）の製品企画・規制対応・QMS運用の支援をはじめる。
クラスII・III機器の開発～市販後に関するISO 13485、IEC 62304、ISO 14971、FDA対応、薬機法承認申請などの支援を専門とする。
現在は医療機器ソフトウェア専門のコンサルタントとして独立し、国内外のスタートアップ・製販企業に対して、開発プロセス設計やチーム育成、技術文書の作成支援など、実行支援を提供中。
2025年よりxCAREエキスパートとしても活動を開始。

🔗 詳細プロフィール・個別相談をご希望の方は：
👉 酒井さんのコンサルティング会社サイトはこちら

参考文献・リンク

1. Tandem Diabetes Care t:connect クラス I リコール詳細
2. 汎用画像診断アプリケーション Seavo View 自主回収
3. 手術台 MOT‑VS700UIj 自主回収 (p2, No.14)
4. パッチ式脳波計 HARU‑2 ファームウェア改修 (p7, No.78)
5. Sedgwick ブランドプロテクション 2024 YTD リコール統計
6. McKinsey サプライチェーン・リスク管理論考
7. Medical Software Consulting 公式YouTubeチャネル
8. ISO 14971 解説動画