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