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