ヘルスケアアプリは健康データや規制が絡むため、ベンダーに開発を依頼する際の最初の関門が、RFP（提案依頼書）と要件定義書の作成です。
「何を、なぜ、どこまで作るか」を発注側が言葉にして整理する必要があります。全体像はヘルスケアアプリ開発の完全ガイドでご確認ください。
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
目的・ターゲット・MVPの優先順位の設定
要件定義の出発点は、技術の話ではなく「なぜこのアプリを作るのか」という目的の言語化です。たとえば、健康経営のために従業員の運動を促したいのか、患者の通院負担を減らしたいのか、生活習慣病の予防を支援したいのか。目的が違えば、必要な機能も変わります。
目的が定まって初めて、ターゲットユーザーと必要な機能が見えてきます。ここを飛ばすと、要件の曖昧さがそのまま開発の迷走につながります。
目的とKPIを言語化するヒアリング
RFPの冒頭には、アプリの目的と、それを測るKPIを明記します。たとえば「従業員の平均歩数を3カ月で15%向上」「予約のオンライン化率を50%に」といった具体的な数値目標です。
KPIが定まると、その達成に必要な機能を逆算でき、不要な機能を盛り込む無駄も避けられます。
目的とKPIのヒアリングは、経営層・現場・情報システム部門など社内の関係者を巻き込んで行う必要があります。立場によって期待する成果は異なるため、認識を揃えておかないと、後で要件が膨張します。
このヒアリングで得た目的とKPIは、ベンダー選定の評価の基準にもなります。提案を受けたとき、その提案が自社のKPI達成にどう貢献するかを問えるからです。
目的が曖昧なRFPには、ベンダーも「とりあえず多機能」な提案で応じがちで、結果として過剰な見積もりを招きます。逆に目的とKPIが明確なRFPには、ベンダーも無駄を削ぎ落とした的確な提案で応じます。要件定義は、目的の言語化から始まるのです。
ヒアリングでは、アプリの目的と、その達成度を測るKPIの2点を言語化します。
- 目的：アプリで実現したいこと
- KPI：目的の達成度を測る数値
機能を必須・優先・将来で分類する方法
目的とKPIが固まったら、必要な機能を「必須」「優先」「将来」に分類します。必須に当たるのは、記録・表示・連携などの機能で、これがなければアプリは成立しません。
分類しておけば、見積もりが予算を超えたときに、どの機能を初期リリースから外すかを冷静に判断できます。
分類の効果は費用に直結します。たとえば、基本的な健康管理アプリは100〜150万円ですが、AI診断や電子カルテ連携を加えると800万〜5,000万円以上に膨らみます。
すべてを必須にすると、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。逆に優先度が明確なら、まず必須機能でリリースし、効果を見ながら段階的に追加できます。
そのため、どの機能が必須かを判断するには、機能ごとの中身を理解しておく必要があります。詳しくは『ヘルスケアアプリの必要機能や標準機能の一覧について』もあわせてご覧ください。
機能は、「必須」と「優先・将来」の2区分に分けて書きます。
- 必須：予算を超えたときも最後まで残す中核機能
- 優先・将来：初期リリースから外せる機能、または効果検証の後に追加する機能
法律をシステム要件に翻訳するチェックリスト
ここは、ヘルスケアアプリの要件定義で最大の難所であり、本記事が最も力を入れる差別化のポイントです。多くの記事は「医療系は薬機法に注意」で止まりますが、要件定義として使うには、もう一歩踏み込む必要があります。
重要なのは、薬機法・個情法・App Store審査という抽象的な法律を、具体的なシステム要件のチェックリストに翻訳することです。
SaMD該当性を要件として判定する手順
最初に要件化すべきは、アプリの各機能がSaMD（プログラム医療機器）に該当するかどうかの判定です。SaMDは実質的にクラスII以上が規制対象で、「心房細動の可能性を検出」のように診断につながる機能が付くと、医療機器に該当します。
要件定義書では、機能一覧の各項目に「医療機器該当の可能性：あり/なし」を併記します。これにより、開発後に「この機能は作れない」と判明する事態を防げます。
たとえば「血圧を記録・グラフ表示する（記録機能）」は非医療機器ですが、「血圧値から高血圧症のリスクを判定し受診を勧める（診断機能）」は医療機器に該当します。
この境界線を要件定義書に言葉として残しておくことは、薬機法の課徴金（違反期間の売上額の4.5%。また、225万円未満は免除／出典：ripla）という経営リスクを避けるための備えになります。なお、曖昧な表現のままだと、開発の途中でベンダーと「これは診断にあたるか」を巡って揉めることになります。
判定では、機能を「診断につながる機能」と「記録・表示のみの機能」に分けて確認します。
- 診断につながる機能：医療機器該当の判定と、薬機法の承認・認証の要否
- 記録・表示のみの機能：診断・治療・受診勧奨を行わないことを、要件に明記
個情法・HealthKit審査を満たす非機能要件
次に要件化すべきは、個人情報保護法とApp Store審査を満たすための非機能要件です。
健康データは要配慮個人情報にあたるため、通信・保存の守り方から同意の取り方まで、要件定義書に書き込みます。
HealthKitを使う場合は、ガイドライン5.1.3に基づき「健康データを広告ターゲティングに利用しない」「読み取り・書き込みに個別権限を取得する」「プライバシーポリシーを提示する」ことを要件として固定します。これらが欠けると、App Storeの審査でリジェクトされ、リリースそのものが頓挫します。
2026年の改正個人情報保護法では、16歳未満の保護が厳格化され、法定代理人の同意取得と本人の最善の利益を優先する設計が求められます。
さらに、顔認証や歩容解析といった特定生体個人情報は、オプトアウトによる第三者提供が全面禁止されました。子ども向けアプリや生体認証を扱う場合は、これらを非機能要件として明記しておく必要があります。
法律を「注意事項」ではなく「実装すべき要件」として書き下すことが、要件定義書の質を決めます。この翻訳を曖昧にしたまま進めると、後述する高額な手戻りや審査落ちにつながります。
失敗の詳細は『ヘルスケアアプリ開発/導入の失敗/課題/注意点/リスクについて』もあわせてご覧ください。
非機能要件は、暗号化・アクセスログと、同意・未成年の扱いの2つの面から確認します。
- 暗号化・アクセスログ：健康データの通信と保存、利用の記録
- 同意・未成年の扱い：利用目的ごとの同意と撤回、16歳未満の法定代理人の同意
既存システム連携の要件化
ヘルスケアアプリ、とくに医療機関向けのアプリでは、電子カルテやレセコンといった既存システムとの連携が要件になることが多くあります。
この連携を要件定義の段階でどこまで具体化できるかが、見積もりの精度と開発の成否を左右します。連携費用が高くなるのは、明確な理由があるからです。
電子カルテ・レセコン連携の前提の明示
電子カルテやレセコンとの連携を要件にする場合は、RFPの段階で連携先を具体的に示す必要があります。電子カルテはベンダーごとに仕様が異なり、標準化されたインターフェースが存在しないことも多いため、どのシステムと連携するかで開発の難易度と費用が変わります。
連携費用は100〜300万円が目安ですが、連携先が特殊なシステムだとこの範囲を超えることもあります。連携先を曖昧にしたままRFPを出すと、各社の見積もりが比較できなくなります。
さらに見落としがちなのが、オンプレミス環境へのアクセス許可という技術以前のハードルです。多くの電子カルテは病院内のオンプレミス環境に閉じており、外部のアプリから接続するには、システムベンダーや院内の情報システム部門との交渉が必要になります。
これは技術というより政治的な調整であり、時間がかかります。このため、要件定義の段階で手を打っておかないと、開発が始まってから連携できないことが判明し、プロジェクトが止まります。連携の前提は、RFPで必ず明示しておくべきです。
連携の前提は、連携先の特定と協力体制の2点で整理します。
- 連携先の特定：ベンダー名、製品名、バージョンの明記
- 協力体制：連携先ベンダーや情報システム部門の協力を、要件定義の段階で取り付ける
性能・可用性・運用の非機能要件の整理
機能要件と並んで重要なのが、性能・可用性・セキュリティ・運用といった非機能要件です。これらを明記しておくと、ベンダーは適切なインフラ構成で見積もりを出せます。
ヘルスケアアプリは健康データという機微情報を扱うため、セキュリティの非機能要件はとくに厳格に定める必要があります。
あわせて、リリース後の運用・保守の要件も欠かせません。ランニングコストは中規模で月10〜30万円、大規模なオンライン診療では月50万円以上が目安です。
誰がアプリを運用し、保守をどう回すかを要件として整理しておかないと、「作って終わり」のアプリになり、運用が破綻します。非機能要件と運用要件は、目立たないものの、長期的にアプリを使い続けられるかを左右する部分です。
非機能要件は、性能・可用性と、運用・保守の2つに分けて整理します。
- 性能・可用性：同時アクセス数、レスポンス速度、稼働率（SLA）、復旧時間
- 運用・保守：運用の担い手、バックアップ、セキュリティパッチの適用
RFPに盛り込む項目と見積もりの妥当性判断
RFP（提案依頼書）は、ベンダーに「何を提案してほしいか」を伝える文書です。盛り込むべき項目を網羅し、各社が同じ前提で提案できるようにすることで、見積もりの比較精度が高まります。
RFPの必須項目と、返ってきた見積もりの妥当性の見方を、順に見ていきます。
RFPに必ず盛り込むべき項目
RFPでまず示すのは、アプリが何を実現するかと、誰がどんな場面で使うかです。
- プロジェクトの目的・背景とKPI
- ターゲットユーザーと利用シーン
RFPには、機能要件（必須・優先・将来の分類付き）と医療機器該当の判定、非機能要件（性能・可用性・セキュリティ・運用）、規制要件（薬機法・個情法・HealthKit審査の対応）も盛り込みます。
既存システム連携の前提（連携先のベンダー・製品・バージョン）や、予算感とスケジュール、納品・検収の基準も、RFPに盛り込みます。
これらを網羅したRFPは、ベンダーにとって提案しやすく、発注側にとって比較しやすい文書になります。特に、規制要件と連携の前提を明示することは、ヘルスケアアプリのRFPで欠かせません。
さらに、RFPには検収基準と要件未達時の対応も明記しておくべきです。何をもって完成とするか、要件を満たさない場合にどう対応するかを契約前に取り決めておくと、開発後のトラブルを防げます。
これは、双方の責任範囲を明確にして泥沼化を防ぐための備えです。RFPは単なる依頼書ではなく、プロジェクト全体の進む方向を示す文書として機能します。
見積もりの妥当性の判断基準
返ってきた見積もりの妥当性は、相場と突き合わせて判断します。基本的な健康管理アプリは100〜150万円、複雑なもので150〜300万円、AI診断や電子カルテ連携を含むと800万〜5,000万円以上が目安です。
安すぎる見積もりは、規制対応や連携が見積もりに含まれていない危険信号かもしれません。
もう一つの判断基準は、見積もりの内訳がどこまで分かれているかです。
一式いくらという見積もりは、後から追加費用を請求される原因になります。フルスクラッチでは500〜1,500万円かかる開発も、ノーコード・ローコードと補助金（医療分野は最大450万円／出典：ripla）の活用で圧縮できる場合があります。
また、複数の手法を比較できる提案かどうかも、重要な判断の基準です。riplaは、フルスクラッチ受託とノーコードの両方の観点から、この見積もりの妥当性を発注企業と一緒に検証する支援を行っています。
見積もりは、相場との差と内訳の明確さの2点から見ます。
- 相場との差：提示額が目安から外れた場合の要因
- 内訳の明確さ：要件ごとの工数と費用、規制対応・連携・運用保守の費用
まとめ
ヘルスケアアプリの要件定義とRFPの核心は、目的とKPIを言語化し、薬機法・個情法・App Store審査という規制を具体的なシステム要件のチェックリストに翻訳することにあります。電子カルテ・レセコン連携の前提も、あわせて示します。
SaMD該当性の判定を機能ごとに併記し、HealthKitの広告利用禁止や改正個情法の同意要件を非機能要件に落とし込むことで、開発後の手戻りと審査落ちを防げます。
さらに、連携費用100〜300万円という相場を踏まえ、連携先と協力体制をRFPで明示することも欠かせません。
要件定義で大切なのは、「法律に注意」で止めず、それを「実装すべき要件」として書き下すことです。これにより、ベンダー各社の提案を同じ前提で比べられ、見積もりの妥当性も判断できます。
要件定義の主導権は自社が握り、規制と技術の翻訳をベンダーの知見で補う形で一緒に進めるのが理想です。
riplaはフルスクラッチ受託とノーコードを組み合わせ、規制を要件に翻訳する要件定義を発注企業と二人三脚で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。