健康管理アプリのRFP（提案依頼書）と要件定義書は、目的とKPIを決めることから作ります。継続率の仕掛けや規制を要件に落とし込めるかで、使われ続けるアプリになるか、審査落ちや法令抵触で頓挫するかが分かれます。
全体像をまだ把握していない方は、まず健康管理アプリ開発の完全ガイドからお読みください。
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
目的・KPIと継続率から始める要件定義の進め方
健康管理アプリの要件定義は、「どんな機能が欲しいか」から考え始めると、判断の基準がないまま機能が増えてしまいます。まず決めるのは、誰に、何のために使ってもらい、どうなれば成功なのかという目的とKPIです。
目的は、健康経営での参加率向上なのか、特定保健指導での行動変容なのか、特定疾患の患者の自己管理支援なのかによって分かれます。目的が曖昧なまま機能を決めると、誰にも刺さらない多機能アプリができあがり、継続率が伸びずに撤退します。
ターゲットとKPIの定義
最初に行うべきは、ターゲットユーザーとKPIを定義することです。ユーザーが高齢者なのか働き盛りの会社員なのか、健康意識が高い層なのか無関心層なのかで、求められるUIも継続の仕掛けもまったく変わります。
そのうえで、成功を測るKPIを定めます。健康経営なら参加率と継続率、特定保健指導なら脱落率と健診結果の改善が指標になります。
たとえば医療機関なら、患者のモニタリング継続率が指標になります。定量的に測れる指標を最初に決めることが、要件定義の前提になります。
ここで欠かせないのが、継続率を最重要のKPIに据える視点です。健康管理アプリは、記録（セルフトラッキング）が蓄積されてこそ価値を持ちますが、アプリを続けて使うことは構造的に難しいものです。
また、観光分野では30日リテンションが約5.8%という水準もあります。成功の基準は「何人が使うか」より「何人が使い続けるか」に置き、それを高める仕掛けを要件に組み込みます。
この継続率起点のKPI設計が、機能の優先順位を正しく導きます。継続率を高める具体的な機能は、機能特化の関連記事もあわせてご覧ください。
ユーザー像が決まると、画面の作り方と継続の仕掛けが具体的に決まります。この二つを要件に書き込みます。
- UIの方針：ユーザー像に合う画面と操作の作り方
- 継続の仕掛け：ユーザー像ごとに変える通知や達成感の出し方
継続率の仕掛けの明文化
継続率を高める仕掛けは、「あればいいな」という曖昧な期待で済ませず、具体的な要件として明文化します。たとえば、プッシュ通知をどのタイミングで何回送るか、ゲーミフィケーションでどんな達成感を提供するか、記録の手間を減らすためにどの自動連携を実装するかを、要件定義書に書き込みます。
継続率は、作ったあとに自然に上がるわけではなく、設計と運用の双方で生み出すものです。
「作って終わり」で失敗する原因は、継続率の要件化と運用設計を怠ったことにあります。機能の実装だけを要件にし、リリース後の改善運用を決めないまま完成とすると、習慣化の仕掛けが弱いアプリが数週間で使われなくなります。
要件定義の段階で運用要件まで盛り込むことが、巨額の無駄遣いを避ける最大の対策になります。
失敗の詳細は、失敗特化の関連記事もあわせてご覧ください。
仕掛けは、次の観点で整理します。
- 改善の担当：データを見て改善する人の役割
- 仕掛けの一覧：通知、ゲーミフィケーション、自動連携ごとの要件
法律をシステム要件に翻訳するチェックリスト
ここは、健康管理アプリの要件定義でもっとも難しく、かつ最重要の工程です。競合の解説記事でも表面的にしか触れられていません。「法律に注意」を要件にするには、具体的な機能の条件に置き換える必要があります。
薬機法（SaMD）・改正個人情報保護法・App Store審査という規制を具体的なシステム要件に翻訳してはじめて、ベンダーは正しく見積もり、開発できます。曖昧なまま進めると、リリース直前の審査で落ちたり、公開後に法令抵触が発覚したりして、致命的な手戻りが生じます。
SaMD該当判定の要件化
まず要件化すべきは、SaMD（プログラム医療機器）の該当判定です。健康管理アプリが、記録の可視化や一般的な生活習慣のアドバイスにとどまるなら、医療機器には該当しません。
しかし、「心房細動の可能性を検出」のように疾患の有無を示唆する判定機能を持つと、医療機器に該当します。その場合、実質クラスII以上が薬機法の対象になります。
判定の結果、当たるなら医療機器としての承認プロセスを、当たらないなら判定的な表現を排除する設計を、要件に明記します。
要件定義の段階で、自社が作りたい機能が医療機器の線をまたぐかどうかを判定し、この判定と広告表現の二つを開発の前に確認しておきます。
- 該当判定：医療機器に当たるかどうかの判定
- 広告表現：説明文と紹介文での効能表現
広告で、医療機器でないものが医療的な効果をうたうと、薬機法に抵触します。こうした表現を避けるルールを要件として先に定めておけば、開発後の致命的なやり直しを防げます。
薬機法違反の課徴金は違反期間の対象売上額の4.5%（225万円未満は免除）と重く、効能効果をうたう表現には細心の注意が必要です。
また、SaMD該当判定は、技術ではなく規制の解釈を要するため、早期に専門家の確認を取っておきます。
改正個情法とApp Store審査の要件化
健康・生体データは機微情報であり、改正個人情報保護法の要件をシステム要件に翻訳する必要があります。2026年の改正では、16歳未満の保護が厳格化され、法定代理人の同意と最善の利益の優先が求められます。
顔認証や歩容解析といった「特定生体個人情報」は、オプトアウトによる第三者提供が全面的に禁止されます。
これをシステム要件に落とすと、生体情報の第三者提供を防ぐデータ管理などが、具体的な機能要件になります。
要件定義では、「個人情報に配慮する」を同意取得フローやアクセス制御として明文化する必要があります。
App Storeの審査基準も、要件として押さえておきます。HealthKitで取得した健康データを広告ターゲティングに使うことは禁止されています。
HealthKitでは、読み取りと書き込みで、それぞれ個別に権限を取得する必要があります（ガイドライン5.1.3／出典：ripla）。
さらに、App Store手数料は原則30%（小規模事業者やサブスク2年目以降は15%）です。アプリ内課金を設ける場合は、この収益構造も事業計画に織り込む必要があります。
審査基準を満たすデータ取り扱いと権限設計を要件にしておかないと、開発が完了してもリリースできません。SaMD・改正個情法・App Store審査という三つの規制を要件に翻訳できれば、健康管理アプリ要件定義の最難関は越えたと言えます。
要件に落とすときは、同意取得と権限設計の二つを具体的に確かめます。
- 同意取得：未成年の保護者同意と、同意の撤回の記録
- 権限設計：HealthKitの読み取りと書き込みの個別取得
機能要件と非機能要件の整理
要件定義書は、機能要件と非機能要件の両方を網羅する必要があります。機能要件は「何ができるか」を、非機能要件は「どれだけの品質で動くか」を定めるものです。
健康管理アプリでは機能要件に目が行きがちですが、機微な健康データを扱い、多数のユーザーが使うため、非機能要件もおろそかにできません。
機能要件の必須・優先・将来による分類
機能要件は、一覧にするだけでなく優先度を付けて分類しておきます。
健康管理アプリは、機能を盛り込むほど費用が膨らみます。たとえば、単機能型なら50〜150万円、複雑な機能なら150〜300万円です。
AI診断や電子カルテ連携を加えると、800万〜5,000万円以上と跳ね上がります。そのため、この優先度付けが予算管理に欠かせません。
優先度を付けておくと、見積りが予算を超えた場合に、どの機能を初期リリースから外すかを冷静に判断できます。すべてを必須にしてしまうと、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。
優先度が明確なら、まずMVP（必要最小限の機能）でリリースし、継続率の効果を見ながら優先機能を追加する段階的なリリース計画が立てられます。
フルスクラッチで500〜1,500万円かかる開発も、AI・ノーコードを活用すると約80%削減できる場合があります。また、優先度に応じた手法の選択も予算を左右します。機能要件の分類は、要件定義書の中でも特に投資判断に直結する部分です。
分類では、次の二つの軸で機能を見ていきます。
- 必須機能：目的の達成に直結する機能
- 優先と将来：初期リリースに含めるか、後から追加するかの判断
必須機能に当たるのは、記録の表示、継続率を高める通知やゲーミフィケーション、必要な連携です。
「効果は大きいが初期になくても運用できる」機能は優先機能、「将来追加でよい」機能は将来機能とし、三段階に分けます。
非機能要件（セキュリティ・性能・可用性）
非機能要件では、セキュリティ、性能、可用性を定義します。健康管理アプリで最も大切なのがセキュリティです。健康・生体データは機微情報であり、漏えいすれば致命的な信頼失墜につながります。
通信とデータの暗号化、アクセス権限の厳格な制御、操作ログの記録を、要件に含めます。不正アクセスへの対策も、要件の一つとして盛り込みます。
とくに医療機関と連携する場合は、厚生労働省の医療情報システムの安全管理に関するガイドラインを踏まえた設計が求められます。
性能と可用性も欠かせません。多数のユーザーが朝晩の決まった時間に記録を入力するため、ピーク時でも快適に動く性能が必要です。表示が遅いだけで、継続率は簡単に下がります。
可用性については、ユーザーが記録したいときに使えないと習慣が途切れます。そこで、稼働率の目標と障害時の復旧時間、バックアップ体制を定めます。
非機能要件を曖昧にすると、リリース後に「遅い」「止まる」「漏れる」というトラブルが起き、ユーザーの信頼を一気に失います。機能要件と同じ程度に非機能要件を詰めることが、健康管理アプリの品質の担保につながります。
非機能要件は、セキュリティと、性能・可用性の二つに分けて押さえます。
- セキュリティ：改正個人情報保護法の要件と整合する設計
- 性能・可用性：ピーク時の動作と、障害時に復旧するまでの時間
RFPに盛り込む項目と見積り妥当性の判断
要件定義書がまとまったら、それをもとにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。
曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。健康管理アプリは費用の幅が規制によっても広がるため、RFPで前提をそろえておくことが、見積りの妥当性を判断するうえでの大前提になります。
RFPに必ず盛り込むべき項目
RFPに最低限盛り込むべき項目は、プロジェクトの目的とKPI（参加率・継続率・健診結果の改善など）、ターゲットユーザー、継続率を高める要件です。機能要件は、必須・優先・将来の分類付きで書き込みます。
規制要件（SaMD該当判定・改正個情法・App Store審査）と、既存システムとの連携要件（電子カルテ・ウェアラブル）も、欠かせない項目です。
さらに、非機能要件（セキュリティ・性能・可用性）、予算とスケジュールの目安、開発・運用の体制要求も書き込みます。とくに健康管理アプリでは、規制要件と継続率の運用要件を明記することが、提案の質を左右します。
見落とされがちなのが、リリース後の運用・改善の体制要求です。健康管理アプリは「作って終わり」では成果が出ないため、継続率のデータを見て改善し続ける運用が欠かせません。
RFPで「継続率向上のためにどんな施策を提案できるか」を問うと、作って納品するだけのベンダーと、成果まで支援できるベンダーを見分けられます。
健康データを扱う以上、開発実績だけでなく規制対応の経験があるかも、体制要求として確認すべき項目です。
体制要求では、リリース後の運用を支えられるかと、規制対応の経験があるかを確かめます。
- 運用の支援：リリース後の改善をどう支えるかの提案
- 規制対応の経験：健康データを扱った実績の有無
見積りの妥当性の判断基準と補助金
集まった見積りの妥当性を判断するには、まず相場観を持つことが大切です。健康管理アプリの相場は、単機能型で50〜150万円、複雑な機能で150〜300万円、AI診断・電子カルテ連携で800万〜5,000万円以上が目安です。
見積りがこの相場から外れている場合は、その理由を確認します。安すぎる場合は規制対応や継続率の仕掛けが漏れている可能性があり、高すぎる場合は不要な機能が含まれている可能性があります。
あわせて検討したいのが補助金です。デジタル化・AI導入補助金（2026年）は4業務プロセス以上で最大450万円が補助され、補助率は原則2分の1、賃上げ要件を達成すれば3分の2になります。
要件定義書とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得ず、補助金申請に必要な要件の整理もしやすくなります。
riplaは、フルスクラッチ受託とノーコードの両面から、要件の透明な整理と、補助金も視野に入れた予算設計を支援しています。要件定義の精度が、見積りの妥当性判断の精度を決めます。
見積りを精査するときは、費用の内訳と補助金の二点を押さえます。
- 内訳：一式でまとめられた費用の、機能ごと・工程ごとの内訳
- 補助金：対象になるかの確認と、申請を前提にした予算の組み方
まとめ
健康管理アプリの要件定義とRFPは、機能を並べる前に、目的とKPIを定め、継続率の設計を要件に含めることから始めます。そのうえで、法律をシステム要件に翻訳することが鉄則です。
SaMD・改正個情法（保護者同意・生体情報の保護）・App Store審査という規制を、具体的なシステム要件に落とします。また、機能を必須・優先・将来に分け、セキュリティを中心とする非機能要件も詰めます。
これらをRFPに明記すれば、ベンダーの提案を横並びで比べられます。単機能型は50〜150万円、複雑な機能は150〜300万円、AI診断や電子カルテ連携は800万〜5,000万円以上という相場に照らして、見積りの妥当性も判断できます（出典：ripla）。
健康管理アプリ特有の二大失敗は「使われない」と「審査落ち・法令抵触」です。継続率の仕掛けと運用を要件化し、規制をシステム要件に翻訳することが、この両方を防ぎます。
riplaは、フルスクラッチ受託とノーコードを組み合わせ、目的・KPIの整理から継続率の設計、規制の要件化、RFP作成までを発注企業と協働で支援します。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。