医療系アプリの試作は、モックアップ、プロトタイプ、PoC、MVPの順に進めると、技術・規制・現場適合性を本格開発の前に確認できます。段階ごとに確かめる対象と費用が異なるため、目的に合う手法を選ぶことが欠かせません。
▼全体ガイドの記事
・医療系アプリ開発の完全ガイド
スマホアプリ開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
PoC・プロトタイプ・モックアップの基礎
PoC、プロトタイプ、モックアップは混同されがちですが、検証する対象と目的はそれぞれ異なります。そのため、違いを押さえて使い分けることが、効率的な試作の第一歩になります。医療系アプリでは、技術的な実現性、規制への適合性、現場での使い勝手を、段階を踏んで検証します。
試作手法の違いと役割
4つの手法は、画面の見た目、操作、技術の実現性、実運用の価値と、確かめる対象がそれぞれ異なります。
- モックアップ：画面の見た目や情報配置の共有
- プロトタイプ：操作や画面遷移を試せる試作
- PoC：アイデアの技術的・概念的な実現性の確認
- MVP：最小限の機能を実際に運用して価値を確かめる段階
モックアップは実際には動作せず、関係者間で画面構成やデザインの方向性を合意するために使います。プロトタイプは操作できる試作で、Figmaなどのクリックできるものから、簡易的に動く実装まであります。
PoC（Proof of Concept＝概念実証）は、見た目よりも「本当に動くか」を検証し、確認対象を実現可能性に絞ります。一方で、MVP（Minimum Viable Product＝実用最小限の製品）は、コア機能を使える形にするものです。
医療系アプリでは、まずモックアップで現場の合意を得ます。続いて、操作性、技術と規制、現場での有用性を確かめていきます。
期間・費用の目安
手法ごとの期間と費用は、試作計画の一般的な目安です。実際の数字は要件によって変わります。
- モックアップ：期間1〜2週間程度、費用30万〜40万円程度
- プロトタイプ：期間1〜3週間程度、費用70万〜90万円程度
- PoC：期間は数日〜最長3ヶ月以内、費用は50万円から300万円以上
- MVP：片OSは200万〜400万円、両OSは500万〜900万円程度
PoCの期間は技術の難易度で変わり、短いものは数日から2週間程度、複雑なものは最長3ヶ月以内です。費用も規模によって異なり、小規模は50万〜100万円、中規模は100万〜300万円です。大規模なPoCは300万円以上となることもあります。
MVPは実装の比重がさらに高まります。医療系アプリでは、SaMD該当性を専門家に相談する費用が加わることがあり、院内連携の調整コストが上乗せされる場合もあります。
本格開発では数千万円規模の手戻りが起こることがあります。そのため、試作への投資は、そうした手戻りを防ぐ保険と捉えられます。
医療系アプリで試作が重要な理由
医療系アプリでは、手戻りの原因を試作の段階で早く確かめることが重要です。後になってから仕様や設計を変えると、その分高くつきます。
- 規制：SaMD該当性によっては、薬事申請が必要になる場合があります。
- 連携：電子カルテとの接続により、設計変更を迫られる場合があります。
- 現場適合：業務フローに合わないと、アプリが使われないおそれがあります。
SaMDに該当すると本格開発の途中で分かった場合、薬事申請が必要になり、スケジュールは数ヶ月から年単位で延びます。費用も数百万円から数千万円規模で増えます。
電子カルテ連携が想定どおりにならなければ、設計の根本的な見直しも必要です。また、現場で使われなければ、投資そのものが無駄になります。
本格開発の前に小さく試作しておけば、取り返しのつかない手戻りを先回りして防げます。これが試作の本質的な価値であり、試作は大きな失敗を避けるためのリスク管理の手段です。
医療系アプリのPoC・試作で検証すべき項目
医療系アプリの試作では、一般的なアプリとは大きく異なる内容を検証します。技術の実現性だけでなく、規制への適合性と医療現場での実用性も確かめる必要があります。
SaMD該当性の見極め
試作の段階で、アプリが薬機法上のプログラム医療機器（SaMD）に該当するかを確かめておく必要があります。該当の有無は規制対応と開発コストに影響するため、早い段階での判断が求められます。
- 機能の切り分け：診断・治療に寄与する機能の特定
- 非該当機能：記録・連絡・予約などの機能の区別
- 専門家との確認：法務やRA、必要に応じてPMDAへの相談
たとえば、検査データから疾病の可能性を示す診断支援は、判断の対象となる機能の一例です。開発会社と発注側が、企画やプロトタイプの段階で機能を明確にします。
そのうえで、開発チームはRA（レギュラトリーアフェアーズ）コンサルタントなどと、機能ごとのスコープをすり合わせます。この確認を省いて本格開発へ進むと、後から医療機器に該当すると判明する場合があります。そうなると、薬事申請のやり直しや大幅な再設計につながります。SaMD該当性の確認は、医療系アプリのPoCで投資対効果の高い検証項目です。
院内システム連携の技術検証
電子カルテやレセコンと連携する場合は、接続が技術的に成り立つかをPoCで確かめます。机上の検討だけでは判断しきれないためです。
- データ取得：APIが想定どおりに動作するかどうか
- 性能：成功率と応答速度が実用に耐えるかどうか
- 接続と保護：院内ネットワークとデータ保護の要件を満たすかどうか
HL7 FHIRやSS-MIX2などの標準規格があっても、実際の連携は個別の仕様に左右されます。電子カルテベンダーや医療機関ごとに仕様が異なります。
そのため、テスト環境で接続方法を検証しておきます。セキュリティ面では、アクセス権限の設計や匿名化・マスキングも確認します。
成功基準の例は、電子カルテからのデータ取得APIの成功率99.9%以上です。数値基準を設けておくと、本格開発後の問題を避けやすくなります。
診療フロー適合のUX検証
医療従事者向けアプリでは、多忙な診療現場の業務に組み込めるかを確かめるUX（ユーザー体験）の検証が欠かせません。使いにくいアプリは定着しないためです。
- 操作環境：手袋をしたままでも操作できるかどうか
- 情報の把握：限られた画面で患者情報を確認できるかどうか
- 入力負荷：患者1人あたりの入力時間が許容範囲かどうか
まず、医師や看護師などの想定ユーザーに、プロトタイプやMVPを操作してもらいます。得られた意見から、業務フローへの影響を確かめます。
たとえば回診中は、タブレットの限られた画面で必要な患者情報を瞬時に把握できるかを試します。操作導線は、Figmaなどで事前に確認します。
その後、限定した病棟でMVPを運用し、段階的に診療フローへの適合性を見ます。試作段階で現場の声を取り入れておくと、完成後に使われないリスクを大きく減らせます。
PoCを成功させる進め方
PoCを成功させるには、検証だけで終わる「PoC死」を防ぐため、事前に進め方を組み立てておくことが欠かせません。何をどこまで確かめ、どの条件で次へ進むかを先に決めておくと、試作を成果につなげられます。
MoSCoW法によるスコープの絞り込み
PoCの典型的な失敗は、機能を増やしすぎて、ミニ本開発のようになってしまうことです。そこで、MoSCoW法で機能に優先度をつけ、範囲を絞ります。
- Must：今回の検証に必須の機能
- Should：推奨する機能
- Could：あれば望ましい機能
- Won’t：今回は対象外とする機能
MoSCoW法は、機能をMust、Should、Could、Won’tの4段階に分ける手法です。PoCでは、Mustだけに絞ります。
たとえば医療従事者向けアプリなら、特定疾患の患者一覧表示と簡易入力に絞る例があります。Should以降を削ると、見積もりや工数を大きく圧縮できるうえ、検証の速度と精度も高まります。SaMD該当性や院内連携など本質的な論点に集中するには、検証範囲を最小限にする規律が欠かせません。
成功基準と撤退基準（No-Goライン）の設定
PoCを始める前に、成功条件と中止条件を数値で決めておけば、検証が長引く事態を防げます。さらに、撤退基準（No-Goライン）も決めておきます。
- 成功基準：客観的に判定できる数値
- 撤退基準：未達時の中止や別案への移行
- 事前合意：経営層や医療専門家を交えた確認
成功基準の例としては、電子カルテAPIの成功率99.9%以上があります。医師のテストで入力時間を指定秒数以内とする方法もあります。
撤退基準では、レスポンス要件を満たせなければ中止すると定めておきます。院内セキュリティ部門の許可が難しい場合は、別案を検討します。
未達時の対応は計画書に明記しておきます。検証結果がグレーでも判断を先送りしないためです。
関係者が多い医療系アプリでは、判断が曖昧だと巨額の投資が宙に浮くおそれがあります。そのため、経営層や医療専門家との事前合意が、健全な投資判断につながります。
PoC→プロト→MVP→本番のロードマップ
医療系アプリの試作は、単発のPoCで終わらせず、段階的なロードマップとして設計します。各段階に判断ゲートを設けることで、投資リスクを抑えられます。
- PoCで、技術的・概念的に作れるかを確認
- プロトタイプで、操作性を磨く
- MVPを一部病棟で試し、現場での有用性を見極める
- 結果を踏まえて、本番展開へ進む
PoCに成功しても、ただちに大規模開発へ進むべきではありません。技術検証だけでは、使い勝手や継続して使う意思までは確かめられないためです。
連携できたことだけで成功と判断すると、現場で使われないおそれがあります。そのため、各段階で定めた基準を満たしたときに、次へ進みます。
医療PoCでよくある失敗と回避策
医療PoCでは、よくある失敗を事前に知り、回避策を講じておくことで、試作を成果につなげられます。特に注意したいのは、現場を置き去りにすることと、セキュリティ要件を後回しにすることです。
現場非接続の回避
医療PoCで最も多い失敗は、現場非接続です。開発ベンダーや情報システム部門だけで進め、医師や看護師が関わらないまま完成させてしまうことを指します。
技術的には動いても業務フローに合わないと、リリース後に使いにくいと敬遠され、やがて誰も使わなくなることがあります。
- 初日から参加：医療従事者を検証チームに加える
- 操作と対話：試作品を使ってもらい、率直な意見を得る
- 運用制約の把握：現場固有の慣習や暗黙のルール
現場の医師や看護師が試作に関わると、「自分たちが作ったシステム」という当事者意識も生まれ、後の定着につながります。
医療現場には、外部から見えにくい運用上の制約があります。そのため、試作段階で現場の声を通じて把握しておくことが、実用化の前提になります。
セキュリティ・ガバナンス要件の先行合意
もう一つの典型的な失敗は、セキュリティやガバナンス要件の定義を後回しにすることです。開始前に、関係部門と要件を合意しておく必要があります。
- アクセス権限：医療データに誰がアクセスできるかの決定
- データ保護：匿名化やマスキングの処理の確認
- ネットワーク：分離要件の担当者とのすり合わせ
機微な医療情報の要件を満たさないと、病院のセキュリティ部門や倫理委員会で承認されない場合があります。患者の臨床データを扱うときは、倫理委員会の承認が必要となることもあり、審査には相応の時間がかかります。
初期段階で要件を合意しておかないと、技術検証に成功しても組織の承認を得られず、計画が止まるおそれがあります。そのため、技術の実現可能性と並行して、組織のガバナンス要件も早い段階で確認しておくことが、後の頓挫を防ぎます。
まとめ
医療系アプリの試作では、目的に応じて手法を段階的に使い分けます。モックアップで画面を合意し、プロトタイプで操作性を確かめたうえで、PoCで技術と規制を、MVPで現場の有用性を検証します。
本格開発の前には、SaMD該当性、院内システム連携、診療フロー適合のUXを確かめます。この確認が、数千万円規模の手戻りを防ぎます。
MoSCoW法で範囲を絞り、定量的な成功・撤退基準と判断ゲートを設けると、投資リスクを段階的に管理できます。現場の医療従事者を初日から巻き込み、セキュリティ要件も先に合意しておきましょう。
▼全体ガイドの記事
・医療系アプリ開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。