問診システムのRFPは、目的整理、要件の明文化、連携・安全性の確認の順に進めると、ベンダーからの見積もりを比べやすくなります。
RFPに書く内容は、機能要件、SLA・連携・コスト、セキュリティ要件の順に見ていきます。全体像は問診システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・問診システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
問診システムRFPの基本構成と機能要件
RFP（提案依頼書）は、ベンダーに求める内容を伝え、複数社から提案と見積もりを得るための文書です。
問診システムのRFPでは、まず導入目的と現状の課題を書き、そのうえで機能要件と非機能要件、予算、スケジュールを盛り込みます。
機能要件が曖昧なまま依頼すると、ベンダーごとに前提の違う見積もりが届き、横並びで比べられません。そのため、機能の粒度をそろえて書くことが大切です。
目的・現状(AsIs)・あるべき姿(ToBe)の言語化
RFP作成は、目的と現状、あるべき姿を言葉にするところから始まります。
自院が解決したい課題には、待ち時間や転記工数の削減、来院前の問診完了などがあります。
現状分析が浅いと、ベンダーは的を射た提案を組み立てにくくなります。医師・看護師・受付の立場ごとに、現状を見ておくことが欠かせません。
- 導入目的：解決したい課題と、期待する変化
- 現状（AsIs）：職種ごとの問診業務と、課題や手戻りの箇所
- あるべき姿（ToBe）：導入後の業務の姿を具体化したもの
IDC Japanの2024年のデータでは、AI導入の32%が期待効果に届いていません。そこで、たとえば「1人あたりの問診転記時間を5分削減」のように目的を定量化しておくと、導入後に効果を測れます。
目的とあるべき姿を言葉にしておくと、後の失敗を防ぐ備えになり、ベンダーとの認識合わせにも役立ちます。そのため、要件定義の段階で言語化に時間をかけることは、結果的に最短の導入につながります。
機能要件の一覧化と優先度（MoSCoW）付け
見積もりの前提をそろえるため、機能を一覧にして優先度を付けます。
- 必須（Must）：実現が必須の機能
- 推奨（Should）：優先して実現したい機能
- あれば望ましい（Could）：実現できれば望ましい機能
- 今回は対象外（Won’t）：今回の対象から外す機能
一覧には、Web・タブレット問診、分岐ロジック、電子カルテ連携を含めます。多言語対応や集計分析なども、同じ一覧に入れます。
優先度付けはMoSCoW分析と呼ばれ、予算内で実現する範囲をベンダーと合意しやすくします。
機能ごとには、診療科や患者層、運用方法まで具体的に書きます。
たとえば「分岐ロジック」では、内科の初診で発熱の有無に応じて感染症の追加質問を出し分けます。この粒度なら、ベンダーは工数を正確に見積もりやすくなります。
費用の目安は、シナリオ・FAQ型SaaSが初期費用0〜30万円、月額5千〜15万円です。AI型は初期費用5〜50万円が目安です。ただし、生成AI・RAG・基幹連携を含む大規模な場合は、初期200〜800万円になります。
機能の粒度をそろえることが、比較できる見積もりを得る鍵になります。
非機能要件・SLAの数値要件
稼働率や応答速度、精度なども、RFPに数値で定める重要な非機能要件です。問診システムが止まると受付全体が滞るため、ベンダーの責任範囲を明確にしておく必要があります。さらに、数値を明記しておくと、導入後のトラブルを防ぎやすくなります。
稼働率99.9%・応答速度などの可用性要件
可用性要件では、稼働率と応答速度を数値で定めます。
- 稼働率：一般的なクラウドサービスでは99.9%以上が目安
- 応答速度：神戸市の事例では通常3秒以内、繋ぎ言葉があれば5秒以内
- 復旧・保全：RTO、RPO、バックアップ頻度を定める
- 稼働時間：Web問診は診療時間外の回答に備えて24時間稼働を想定
神戸市の調達事例では、年間稼働率の目標を99.9%に設定しました。問診システムでも、SLA（サービス品質保証）の数値をRFPに明記し、契約上の保証にすることが望ましいです。
発注側は数値をベンダーに示したうえで、未達時のペナルティも定めておきます。「安定して動くこと」とだけ書くと、責任の所在が曖昧になり、トラブル時の対応も決まりません。
回答率・AI精度の目標値とハルシネーション対策要件
AI問診では、回答率やAI精度の目標値も、非機能要件として定めます。
- 回答率：回答完了率の段階的な目標
- AI精度：適切な追加質問を出せる精度
- 誤回答対策：RAG用データの整理と、医師による確認運用
- 診断行為の制限：AIに診断させない設計
神戸市の調達事例では、回答率の目標を導入月50%、2か月後60%、最終的に70%以上としています。また、達成に向けた改善の進め方を、ベンダーと共有しておくと有効です。
生成AIのハルシネーションとは、事実と異なる回答を生成してしまうことです。そのため、RFPでは、RAG用データの整理方法と、誤った医療情報を患者に示さない制御を求めます。
たとえば、KARAKURIには正答率95%保証プランを提供する事例があります。医療行為に直結する問診では、AIに診断させない設計が安全性の前提になります。
連携要件とコスト要件の明文化
電子カルテや予約システムとの連携要件は、問診システムの投資効果を左右します。連携が曖昧なままだと、追加開発費が生じやすく、見積もりも比べられません。
生成AIのトークン課金など、運用フェーズで生じる費用を見込んだコスト要件も、RFPに明記します。
電子カルテ連携の方式とAPI開発範囲の明記
連携要件では、自院の環境や接続方法、受け渡す情報を具体的に書きます。
- 製品情報：電子カルテの製品名とバージョン
- 連携方式：API連携・CSV連携・画面連携などのうち、自院のシステムに合う方法
- 連携データ：システム間で受け渡す項目
- 責任範囲：開発、カルテ側の対応、調整担当
電子カルテは、ベンダーごとに仕様が異なります。そのため、連携実績のないシステムを接続すると、追加のAPI開発が発生します。
連携API費は1件30万〜100万円程度が目安で、この費用を見落とすと予算が大きくぶれます。
発注側はRFPで連携の責任範囲を明確にし、問診ベンダーが開発する範囲と、電子カルテ側に依頼する対応を決めておきます。両社の調整担当も決めておかないと、責任の押し付け合いで進行が止まるおそれがあります。
要件定義の不備による再開発は、100万〜500万円の追加費用につながります。そこで、連携要件は見積もり段階で優先して詰め、連携実績の一覧をベンダーに提示させます。自院の環境で確実に動くかも、あわせて確かめます。
トークン課金前提のコスト要件とTCO算定
生成AIを使う問診システムでは、LLMのトークン課金が運用費になります。
- 利用量：月間の問診件数とトークン消費量
- 費用試算：モデル別の月額コストの見積もり
- TCO：運用費を含む3〜5年の総保有コスト
- 超過対策：想定上限の見積もりと費用上限の設定
ベンダーに運用費の試算を求める際は、想定する月間件数とトークン量を添えます。
月10万リクエスト（入出力各500トークン）で試算すると、Gemini 2.0 Flashは約3,750円、GPT-4o miniは約5,600円、Claude Sonnet 4は約135,000円です。使うモデルによって、月額が桁違いに変わります。
初期費用だけでなく、運用費を含めた3〜5年のTCO（総保有コスト）で評価します。SaaS型は月30万円、フルスクラッチは初期費用1,000万円という試算があります。この5年TCOは約3.5年で損益分岐するため、利用規模と運用期間から有利な方式を判断します。
トークン課金は変動費のため、月5万円の見込みが20万円を超過した事例もあります。したがって、上限の見積もりは必ずベンダーに求めます。
コスト要件が曖昧だと、運用を始めてから想定外の請求を受けることになります。このため、予算を管理できるよう、運用コストの上限もRFPで決めておきます。
セキュリティ・法令遵守の要件
問診システムは症状や既往歴などの要配慮個人情報を扱うため、情報漏えいが起きると、500万円以上の対応費用に加えて医療機関の信頼を失うおそれがあります。そのため、発注側はRFPに要件を明記し、提案の段階でベンダーの対応水準を見極めます。
医療情報ガイドライン準拠・データ保管要件
セキュリティ要件の基盤になるのは、厚生労働省の医療情報システム安全管理ガイドラインへの準拠です。
- 安全管理：ガイドラインに沿った運用
- データ保護：通信・保存データの暗号化
- アクセス管理：職種別の権限制御と監査ログ
- 保管環境：クラウド保管場所の国内指定とISMSなどの第三者認証
クラウドに保管する場合は、保管先の国内指定と第三者認証の取得も要件に加えます。
生成AIを使う場合は、個人情報を外部に送信する際の条件も欠かせません。患者の症状情報を外部AIに送信するときは、学習利用を契約で防ぎます。無料版AIでは入力が学習に使われることがあるため、学習されない契約形態を前提にします。
問診情報を外部送信する場合は、改正個人情報保護法を踏まえた同意取得も要件に含めます。
運用・保守と責任分界点の要件
導入後の運用と保守について、自院とベンダーのどちらがどこまでを受け持つかを決めておきます。
- テンプレート改善：自院で対応するか、ベンダーに委託するか
- 障害対応：窓口と対応時間の取り決め
- 保守費用：月次費用を要件に含める
- 責任分界：保守対象と自院の運用責任の文書化
問診テンプレートや分岐シナリオの改善には、最低でも月5〜10時間の運用リソースが必要です。そのため、この改善を自院とベンダーのどちらが担うかを決めたうえで、窓口や対応時間、月次保守費を契約段階で固めます。
どこまでを誰が受け持つかがはっきりしていると、長期的な安定運用につながります。反対に、責任が曖昧だと、障害時に対応が遅れて診療に支障が出るおそれがあります。
riplaは、フルスクラッチ受託と運用伴走の立場から、要件定義時の論点整理を支援しています。要件定義に時間をかけることは、結果として安く確実な導入の近道になります。
まとめ
問診システムのRFPは、目的とAsIs／ToBeを整理してから、MoSCoWで機能の優先度を決めて組み立てます。
稼働率99.9%、応答3秒、回答率70%以上などの目標に加えて、電子カルテ連携、トークン課金、ガイドライン準拠も要件に含めます。
数値と条件を明記しておくと、比べやすい見積もりを得られ、後悔の少ない選定につながります。また、要件定義の不備による再開発（100万〜500万円）も避けやすくなります。
連携やコストの曖昧さは追加費用につながり、トークン課金では想定を超える場合があります。
要件定義に時間をかけることは遠回りに見えて、実は最短かつ最も安全な導入の道です。
要件整理から定着まで、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を創業。