医療系アプリのRFP（提案依頼書）や要件定義書には、基本項目に加えて、薬機法やSaMD該当性、電子カルテ・レセコン連携といった医療固有の要件を書く必要があります。
全体像をまだ把握していない場合は、まず医療系アプリ開発の完全ガイドから読むことをおすすめします。
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
医療系アプリRFPの基本項目と準備すべきこと
法律を要件に翻訳する作業に入る前に、RFPの土台となる基本項目を固めておく必要があります。目的、ターゲット、MVPの優先順位は、医療系でも他のアプリと共通する骨格です。KPIと予算も、この骨格の一部になります。
ただし、医療系では「誰のどんな課題を解くか」が曖昧だと、規制対応の範囲まで定まらなくなります。そのため、基本項目こそ精密に書く必要があります。
目的・ターゲット・MVP優先順位の書き方
医療系であれば、「待合混雑の緩和」「医療事務スタッフの会計業務の削減」「問診の質の向上」など、現場の切実な課題を起点に据えます。
ターゲットは、患者なのか医療従事者なのかを明示します。患者であれば、年齢層や来院頻度まで書きます。特に小児を含む場合は、後述する保護者同意の要件が発生するため、ターゲットの定義が規制対応の範囲を左右します。
目的とターゲットが曖昧なままだと、ベンダーは何を作ればよいか判断できず、提案の方向がぶれてしまいます。
MVPの優先順位づけは、医療系アプリのRFPでとりわけ重要です。機能の範囲による費用の目安は、最低限の機能で50〜100万円、基本機能で100〜150万円、複雑な機能で150〜300万円です。さらに、AI診断や電子カルテ連携を含めると、800万円から5,000万円以上に達します。
最初から全機能を求めると、費用も規制対応も膨らみます。そのためRFPでは、「必須機能」と「将来拡張機能」を分けて、優先順位を示します。
規制対応を現実的に進められる機能（予約・会計など）を必須に置き、診断補助やオンライン診療のような重い機能は将来拡張に回します。この優先順位がRFPに明記されていれば、ベンダーは段階的な開発を提案しやすくなり、見積もりの精度も上がります。
RFPでは、課題の現場と機能の区分を、ベンダーが読んで判断できる形で書いておきます。
- 解決したい課題と、その課題が起きている現場：現場のどの場面で、何に困っているか
- 必須機能と将来拡張機能の区分：段階的な開発に向けた機能の優先順位
KPI・予算・運用体制のRFPへの明記
成果を測るKPIには、医療系であればレセコン連携率や会計待ち時間の削減、問診入力率などが候補になります。いずれも、現場の効果を数値で示せる指標です。
自動精算機「NOMOCaシリーズ」がレセコン連携率96.6%という指標で評価されているように、KPIを具体的に決めておけば、開発の成否を客観的に判断でき、ベンダーとの認識のずれも防げます。KPIが曖昧なRFPは、「作って終わり」のアプリを生む温床になります。
予算と運用体制も、RFPで率直に示すべき項目です。開発費用だけでなく、ランニングコストも見込んでおく必要があります。
運用費の目安は、中規模で月10〜30万円、大規模なオンライン診療システムで月50万円以上です。
医療系アプリは法規制の改正に継続して追従する必要があります。そのため、運用体制を要件定義に含めておかないと、リリース後に対応できる人がいない事態に陥ります。予算と運用は、一体で示してこそ現実的なRFPになります。
RFPでは、成果の測り方と運用の担い手を、ベンダーが見積もれる形で書きます。
- 成果を測るKPIの指標：開発の成否を判断できる、数値で測れる指標
- リリース後の運用担当：問い合わせ対応と法改正への追従を担う主体
法律をシステム要件に翻訳するチェックリスト
ここからは、医療系アプリのRFPで差がつく核心部分です。多くのRFPは、「薬機法に注意」「個人情報保護に配慮」といった抽象的な注意書きで法規制を済ませています。しかし、それではベンダーが具体的に何を実装すればよいか判断できません。
そこで重要なのが、法律を検証可能なシステム要件に翻訳することです。これが、手戻りと法令違反を防ぐ最大の防衛策です。
SaMD該当性と薬機法の要件化
最初に判定すべきは、開発するアプリがプログラム医療機器（SaMD）に該当するかどうかです。SaMDは実質的にクラスII以上が対象とされ、クラスI相当のものは対象外です。
「心房細動の可能性を検出」のような診断的な判断に踏み込む場合は、医療機器としての承認プロセスや製造販売業の許可が必要になり、開発の範囲と期間も変わります。この判定をRFPの段階で行わなければ、開発の終盤でSaMD該当が発覚し、計画が根底から覆ります。
薬機法は、広告表現の面でも要件に落とす必要があります。アプリの説明文や画面上の文言で効果効能を断定的に謳うと、薬機法に抵触します。
薬機法違反の課徴金は、違反期間中の売上額の4.5%とされ、225万円未満の場合は免除されます。そこでRFPには、アプリ内の表現が薬機法のNGワードに触れないかを確かめる工程を、要件として組み込みます。
法律を「注意してください」で済ませず、「SaMD該当性の判定書の提出を求める」「文言の薬機法レビューを工程に含める」のように、検証できる形で書くことが要件翻訳の要諦です。実際にどんな失敗が起きるかは、関連記事『医療系アプリ開発/導入の失敗/課題/注意点/リスクについて』で確かめられます。
SaMDの判定と広告表現は、要件として具体的に落とし込んでおきます。
- 機能ごとの区分：情報の整理・表示か、診断的判断か
- 広告表現の確認：説明文や画面の文言を、薬機法の観点で確かめる
安全管理ガイドラインと個人情報保護法の要件化
医療情報を扱うアプリには、厚生労働省などが示す医療情報の安全管理ガイドラインへの準拠が求められます。RFPでは、これを抽象論で終わらせず、ネットワーク設計の水準まで翻訳します。
たとえば、IP-VPNを用いた経路の暗号化、アクセスログの長期保存、生体認証による本人確認が挙げられます。
とくに、オンプレミスの電子カルテとクラウドアプリを接続する場合は、通信経路のセキュリティ要件を要件定義に書き込んでおかないと、リリース直前のセキュリティ監査で差し戻されます。
2026年改正個人情報保護法への対応も、要件として落とし込みます。改正では、16歳未満の保護が厳格化され、法定代理人の同意取得と、子どもの最善の利益を優先する原則が導入されます。さらに、顔認証や歩容解析などの「特定生体個人情報」は、オプトアウトによる第三者提供が全面的に禁止されます。
RFPには、小児向けであれば保護者同意取得のUIを実装要件に入れます。生体認証を使う場合は、生体情報の保存場所と、第三者提供を行わない仕組みも明記します。法律を、画面・データ・経路のどこでどう担保するかという実装の水準に翻訳することが、医療系RFPの最大の差別化要素です。
ガイドラインと個人情報保護法の要件は、ネットワークと同意取得の両面で、RFPに書き込んでおきます。
- 院内の閉域網とクラウドの接続方法：院内とクラウドをつなぐ経路の守り方
- 小児向けの同意取得：保護者同意のUIと、生体情報の扱い
電子カルテ・レセコン連携の要件化
規制要件と並んで、医療系アプリのRFPで欠かせないのが、既存システム連携の要件化です。電子カルテやレセコンとの連携は、医療系アプリの効果を最大化する一方で、技術面でも組織面でも難所が多いため、RFPで前提を明示しておかないと費用が膨らみます。連携がなぜ高額で難しいのかを理解したうえで、要件に落とすことが大切です。
連携が高額・難しい理由と前提
電子カルテ・レセコン連携が高額になるのには、明確な理由があります。
第一に、電子カルテやレセコンはベンダーごとに仕様が異なり、標準化された連携インターフェースも整っていません。そのため、連携のたびに個別の作り込みが発生します。
第二に、多くの電子カルテはオンプレミス環境で稼働しています。外部アプリからアクセスするには、院内ネットワークへの接続許可を得るための交渉が必要です。
これは技術というより、情報システム部門やベンダーとの調整という政治的なハードルです。連携費用が100〜300万円に達するのは、こうした個別開発と調整コストが積み上がるためです。
連携方式（API・ファイル連携など）も、RFPに書いておく項目です。
前提を曖昧にしたままRFPを出すと、ベンダーは連携のリスクを見積もれず、後から追加費用や納期の遅れが生じます。連携の前提をRFPで具体化しておくことが、費用の膨張を防ぐ最大の手段です。
連携を支える機能設計は、関連記事『医療系アプリの必要機能や標準機能の一覧について』で確かめられます。
連携の前提は、製品の情報と、オンプレ環境の扱いの2つに分けて書きます。
- 連携の前提：連携対象の製品名、バージョン、データ項目
- オンプレ環境への接続と交渉の主体：アクセスの可否と、交渉を担う主体
連携要件のチェックリストと役割分担
連携要件を漏れなく書くために、RFPには連携に関するチェックリストを用意します。
さらに、連携のタイミング（リアルタイムかバッチか）と、連携が失敗した場合の処理も整理します。連携作業を担う主体は、自院、アプリベンダー、電子カルテベンダーのいずれかです。
とくに役割分担は重要で、電子カルテベンダーの協力が得られるかどうかによって、連携の難易度が変わります。RFPの段階で、電子カルテベンダーとの調整を誰が担うかを明示しておけば、後の責任の押し付け合いを防げます。
連携の要件化では、データの整合性をどう担保するかも明記します。たとえば、予約や問診の情報を電子カルテに書き込む場合は、どちらのシステムを正とするかや、データの重複や矛盾をどう防ぐかを要件として定義します。
連携が中途半端だと、スタッフが二重入力を強いられ、自動化の効果が相殺されます。NOMOCaが、レセコン連携率96.6%で現場に定着したのは、連携を機能の中心に据えたからです。
RFPで連携要件を具体化し、役割分担とデータ整合性まで定義しておくことが、現場で使われる医療系アプリの前提になります。
連携の要件は、対象システムとデータの方向、調整の担い手の2点から書き起こします。
- 連携対象システムと、データの方向：読み取りか書き込みか
- 電子カルテベンダーとの調整を担う主体：協力を取り付ける側を、RFPの段階で決めておく
まとめ
医療系アプリのRFP・要件定義書は、目的・ターゲットからKPI・予算・運用体制までの基本項目に加えて、医療固有の二大要件を盛り込むことで完成します。二大要件とは、「法律のシステム要件化」と「電子カルテ・レセコン連携の要件化」です。
SaMD該当性の判定書、薬機法レビュー工程、安全管理ガイドラインに基づくネットワーク設計が、その中身になります。さらに、生体認証や保護者同意の実装要件まで、法律を検証可能な要件に翻訳することが最大の差別化です。
連携については、ベンダーごとに仕様が異なり、オンプレ環境での交渉という政治的なハードルがあることを前提に、連携対象・範囲・役割分担を明示します。
医療系アプリの失敗の多くは、要件定義の曖昧さに起因します。法律を一般的な注意書きで済ませず、判定書やレビュー工程、ネットワーク設計といった具体的な要件に落とし込みます。連携の前提をRFPに書いておけば、手戻りや費用の膨張を防ぎ、法令違反のリスクも減らせます。
ベンダーに丸投げせず、自社主導でRFPを作ることから始めてください。riplaはフルスクラッチ受託とノーコードを組み合わせ、規制を要件に翻訳するRFP作成と、現場に定着する医療系アプリづくりを支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。