オンライン診療システム開発の発注/外注/依頼/委託方法について

オンライン診療システムの発注・外注は、ビデオ通話機能を買うのではなく、予約から診察、決済、処方、対面診療への引き継ぎまでを安全に運用できる業務基盤を選ぶことが重要です。

医療機関の事務長やシステム担当者、オンライン診療サービスを立ち上げる事業会社が迷いやすいのは、既製SaaSで始めるか、クラウド上でカスタマイズするか、スクラッチ開発を委託するかという判断です。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の比較方法を、2026年時点の公開情報を踏まえて順番に解説します。

▼全体ガイドの記事
・オンライン診療システム開発の完全ガイド

オンライン診療システムの発注で最初に決めること

オンライン診療システムの発注では、機能一覧より先に「誰が、どの患者に、どの診療を提供し、どの業務を何分短縮したいのか」を決めます。患者向けサービスの比較と、医療機関の業務システム開発では、必要な契約・連携・責任分界が異なるため、プロジェクトの目的を曖昧にしたまま会社へ相談すると、見積書を比較できなくなります。

例えば「通院が難しい慢性疾患患者の再診を、1院の2診療科でオンライン化する」「複数拠点の予約、問診、診療記録、決済を一つの患者導線につなぐ」といった表現です。対象が再診中心なのか初診を含むのか、医師だけが利用するのか看護師や事務スタッフも操作するのかによって、本人確認、同意取得、診療計画、対面診療への切り替え機能の優先順位が変わります。

患者、医師、看護師、受付、会計担当、薬局、配送事業者のそれぞれについて、開始前・診療中・診療後の作業を書き出します。診療後に処方箋を薬局へ送る方法、患者が支払う方法、未受診や通信断が起きた場合の連絡方法まで確認しておくと、後から「この業務もシステム化したい」となって追加費用が膨らむ事態を抑えられます。

オンライン診療システムは、患者側の予約、本人確認、保険資格確認、問診、同意、待合室、診察、通知、決済、領収書、処方箋や薬の配送状況確認をつなぐ仕組みです。医療者側には予約枠、患者一覧、問診確認、診療記録、処方、キャンセル、請求、権限管理、監査ログが必要になります。ビデオ通話のデモが滑らかでも、診療前後の入力が別画面に分かれていれば、現場の二重入力や患者取り違えにつながります。

特に確認したいのは、電子カルテやレセコンとの連携方式です。「連携可能」という説明だけでは、APIで自動連携するのか、CSVを出し入れするのか、画面を参照するだけなのか分かりません。データ項目、連携タイミング、エラー時の再送、手入力が残る項目まで提案書に書いてもらうことが、発注後の認識違いを防ぎます。

発注形態はSaaS・カスタマイズ・スクラッチから選びます

発注形態の選択は、初期費用の大小だけでなく、業務をどこまで標準化できるか、独自の患者体験やデータ連携がどれだけ必要かで決めます。最初から全面的な個別開発を選ぶより、標準サービスで検証して差分だけを開発する方が、現場に合わない機能へ投資するリスクを下げやすいです。

1院・少数診療科でオンライン診療を始めたい場合は、予約、問診、ビデオ診察、決済などが用意された医療向けSaaSが候補になります。サービス提供会社がインフラ更新や基本的なセキュリティ対応を担うため、短期間で運用を始めやすく、利用実績を見ながら対象診療科を広げられます。

ただし、SaaSは契約終了後のデータ返却、患者情報の出力形式、外部サービス連携、サポート時間、障害時の連絡手段を確認します。既存の電子カルテと患者情報が自動連携しない場合や、独自の問診・請求ロジックを変えられない場合は、安さだけで選ばないことが重要です。

標準SaaSの業務フローを活かしながら、電子カルテ連携、独自の患者ポータル、薬局や配送とのAPI連携を追加したい場合は、クラウド上のカスタマイズが適しています。既製機能と個別機能の境界を決め、標準アップデートの影響を受ける範囲を契約書と設計書に残します。

カスタマイズでは、標準機能の変更が将来のアップデートで使えなくなる可能性があります。発注時には、追加画面を独立させるのか、標準画面を改修するのか、API連携で疎結合にするのかを確認します。要件を細かく分離できる会社ほど、機能追加やベンダー変更の影響を限定しやすいです。

多院展開、独自の診療体験、複数の医療機関をまたぐ地域連携、蓄積データを活用したサービスなどが競争力になる場合は、スクラッチ開発を検討します。患者側のWebやアプリ、医療者画面、認証・権限、ビデオ通信、データベース、決済・通知API、監査ログを一体で設計できる一方、保守運用と制度変更への追随を発注者が長期的に担います。

スクラッチを選ぶときは、画面の完成度だけでなく、障害対応、バックアップ、脆弱性管理、ログ監視、データ移行、再委託先管理まで提案してもらいます。医療情報を扱うため、開発会社に任せれば終わりではなく、医療機関側が運用責任を果たせる体制を同時に作る必要があります。

オンライン診療システムの発注・外注の進め方

発注は「相談して見積を受け取る」だけでは完了しません。現場業務の整理、発注形態の比較、RFPの配布、提案評価、契約、設計、受入テスト、運用開始という流れで、発注者が意思決定する場面をあらかじめ区切ります。

最初の1〜2週間は、患者の予約から診療後の請求・処方までを観察し、現行の電子カルテ、レセコン、予約台帳、決済、薬局連絡、配送の流れを図にします。担当者へのヒアリングだけでなく、実際に1件の診療がどの画面を何回行き来するかを確認すると、仕様書に出にくい手作業を見つけられます。

この段階で、初診を扱うか、再診だけにするか、処方箋をどこへ送るか、患者の本人確認を誰が行うか、診療を対面へ切り替える条件は何かを決定します。判断できない制度事項は、医療側の責任者や専門家へ確認し、開発会社に制度解釈を丸投げしないことが大切です。

RFPには、背景と目的、対象拠点・診療科、想定患者数、診療フロー、必須機能、将来機能、既存システム、連携したいデータ、セキュリティ要件、スケジュール、予算の考え方、提案書の提出形式を記載します。例えば「電子カルテ連携」と書く場合も、患者基本情報、予約、問診、診療記録のどこまでを自動化したいかを分けて記述します。

提案依頼先には、同じ質問への回答を求めます。概算総額だけではなく、初期構築、追加開発、連携、データ移行、テスト、教育、月額保守、従量課金、決済手数料、障害対応を分けた見積書を提出してもらうと、会社ごとの前提を比較できます。提案の前提条件が違う場合は、安い見積が本当に安いとは限りません。

テストは画質や音声だけでなく、実際の診療シナリオで行います。新規患者の登録、本人確認の失敗、予約変更、問診の未回答、医師の診察開始、通信断、患者取り違え防止、決済失敗、返金、処方箋の薬局連絡、対面診療への切り替え、監査ログの確認までを通しで試します。

現場スタッフが受入テストに参加しないと、運用開始後に入力項目や権限の不足が見つかります。医師、看護師、受付、会計担当にそれぞれ操作してもらい、1件あたりの処理時間、患者への案内の分かりやすさ、例外処理の手間を記録します。合格条件、修正期限、再テストの手順を契約またはプロジェクト計画に含めることが有効です。

契約形態は開発範囲と責任分界で選びます

オンライン診療では、仕様の不確実さだけでなく、個人情報、診療継続、障害時対応という責任が関係します。準委任契約か請負契約かを名称だけで決めず、どの成果物をいつ納品し、誰が確認し、障害や制度変更に誰が対応するのかを契約書と別紙で明確にします。

画面、機能、連携、性能、テスト条件を確定し、成果物と完成条件を明示できる範囲は、請負契約で発注しやすいです。納品物、検収方法、瑕疵や契約不適合が判明した場合の修正、納期変更の扱い、知的財産権の帰属を確認します。医療情報を扱うシステムでは、仕様書だけでなく、セキュリティ設計書、運用手順書、バックアップ・復旧手順も納品対象に含めるか検討します。

ただし、制度の解釈や現場の要望が変わりやすい段階で、未確定の範囲まで固定価格・固定納期にすると、変更要求のたびに追加契約が発生しやすいです。まず要件定義を別工程として契約し、その成果を基に開発契約へ進む方法が現実的です。

現状業務の整理、アーキテクチャ検討、プロトタイプ、アジャイル開発、運用改善のように、作業内容を協議しながら進める範囲は準委任契約が適する場合があります。稼働する専門家、期間、会議体、報告物、優先順位の決め方、成果の評価方法を明記し、作業時間を投入するだけで課題が放置されないようにします。

SaaSの導入支援では、サービス利用契約と導入支援契約が別になることもあります。サービス障害の責任、設定ミスの責任、連携先の障害、通信会社や決済会社の障害を分け、問い合わせ窓口と復旧目標を決めます。2026年4月改訂の厚生労働省「オンライン診療の適切な実施に関する指針」でも、オンライン診療システム事業者と医療機関の責任分界点を明らかにする考え方が示されています。

契約前に、患者情報の所有権と利用目的、再委託先、海外クラウドの利用、アクセス権限、ログの保存期間、バックアップ、事故発生時の報告期限、脆弱性対応、データの返却形式、契約終了後の削除証跡を確認します。保存データの削除だけでなく、バックアップやテスト環境に残るデータも対象にすることが大切です。

厚生労働省の2026年改訂指針では、オンライン診療の通信についてTLS1.3以上を基本とし、やむを得ずTLS1.2を使う場合は十分な暗号強度を確保する考え方が示されています。提案書には「暗号化対応」とだけ書かず、通信・保存・鍵管理・多要素認証・監査ログをどの方式で実装するかを記載してもらいます。

RFPと要件整理で漏れを防ぐポイント

RFPは、発注者が欲しい機能を並べる書類ではなく、複数社から同じ条件の提案を受けるための比較基準です。必須要件と希望要件を分け、業務・データ・非機能・運用・契約の各面から記載すると、提案の違いを評価しやすくなります。

機能要件は「予約管理機能が必要」と書くより、「患者がスマートフォンから診療科・医師・時間帯を選び、問診と同意を完了して予約を確定する」「受付が未回答の問診を一覧で確認し、診療前に差し戻す」と書きます。画面の利用者、入力項目、エラー時の処理、通知のタイミング、履歴の残し方までシナリオに含めます。

医療者側では、患者一覧、診療開始・終了、診療録への記録、処方箋や薬局への連携、キャンセル・未受診、返金、対面診療への移行を一連の流れで定義します。患者が通信できない場合や、本人確認に失敗した場合に、診療を中止するのか別の連絡へ切り替えるのかも、例外シナリオとしてRFPに含めます。

非機能要件には、同時接続数、応答時間、稼働時間、バックアップ頻度、復旧目標時間、復旧時点、ログ保存期間、対応する端末やブラウザ、脆弱性診断、障害通知の期限を記載します。「安定稼働」「十分なセキュリティ」といった言葉だけでは、完成後の検収で判断できません。

患者の診療情報をどの国のどの環境に保存するのか、開発・検証環境へ実データを持ち込むのか、運用担当がどの権限で閲覧できるのかも確認します。多院展開を想定する場合は、医師・スタッフ・拠点・診療科ごとの権限分離と、退職者のアカウント停止手順を要件化します。

電子カルテ、レセコン、予約管理、電子処方箋、オンライン資格確認、薬局のオンライン服薬指導、配送、検査結果、ウェアラブル機器やPHRと連携する場合は、対象データを一覧化します。患者ID、氏名、生年月日、予約日時、問診回答、診療記録、処方情報など、項目単位で送受信の方向、連携頻度、エラー時の扱い、再送方法を確認します。

連携方式は、API、CSV、ファイル連携、画面参照、手入力などに分けて評価します。API連携でも、相手システムの仕様変更を誰が検知して改修するのか、接続試験の環境を誰が用意するのか、連携先の費用が別に発生するのかを契約前に確認します。ここを曖昧にすると、開発終盤に連携できない項目が判明します。

オンライン診療システムの費用相場と内訳

費用は、既存SaaSの利用料、導入支援費、個別開発費、外部サービス費、保守運用費に分けて考えます。SaaSの公開価格や医療機関の実態調査は、個別開発の見積相場とは別の数字です。両者を同じ表で単純比較せず、必要な機能と責任範囲をそろえて判断します。

厚生労働省「令和6年度入院・外来医療等における実態調査（速報）」では、オンライン診療を利用する医療機関のシステム導入時初期費用は中央値27.5万円、四分位範囲は3.65万円から47.5万円でした。月額維持費用は中央値1万円、四分位範囲は5,000円から2万4,250円でした（出典：厚生労働省、令和6年度入院・外来医療等における実態調査、2025年）。これは既存サービスを利用する医療機関に近い実勢値として、予算の初期検討に使えます。

公開料金の例では、YaDocは導入費用0円で月額3万3,000円（税込）、YaDoc Quickは導入費用0円で月額1万1,000円（税込）です（出典：株式会社インテグリティ・ヘルスケア、医療機関向け料金ページ、2026年確認）。サービスの対象規模や機能は異なるため、そのまま相場と断定せず、決済、SMS、配送、追加連携、サポート、患者向け利用料などの別費用を含めて確認します。

オンライン診療だけを切り出した全国一律の公的なスクラッチ開発統計は確認できないため、個別開発の金額は計画用の推定として扱います。予約、問診、ビデオ診察、決済、最低限の管理画面に絞るMVPは1,000万〜3,000万円、電子カルテ・レセコン・電子処方箋・薬局・配送・多院管理・監査ログまで含む開発は3,000万〜8,000万円程度、病院グループや医療事業者向けの大規模基盤は8,000万円〜2億円超を見込むケースがあります。

このレンジは、医療連携やセキュリティ審査、データ移行、運用監視まで含めた要件から算出する計画上の幅であり、特定の発注金額を保証するものではありません。診療科数、拠点数、同時接続数、アプリの有無、既存システムの仕様、第三者試験、移行データの品質で大きく変わります。見積書に画面数だけでなく、連携本数、データ項目、テストケース、運用設計の工数が含まれているか確認します。

運用開始後は、クラウド利用料、ビデオ通信、SMSやメール、決済手数料、配送、監視、ヘルプデスク、脆弱性対応、OSやライブラリの更新、追加開発が発生します。患者数や診療件数に応じた従量課金がある場合は、少ない月と繁忙月の両方で試算し、1診療あたりの変動費を確認します。

個別開発では、初期費用だけで予算を使い切らないように、制度改定対応や連携先仕様変更、障害調査、データ移行のやり直しに備えた予備費を確保します。契約期間中の保守に何が含まれ、機能追加や夜間休日対応がいくらから別料金になるかを明記してもらうことが重要です。

委託先の選定と見積比較で見るべきポイント

委託先は、医療向けSaaS会社、医療業務に詳しいSIer、クラウド開発会社、既存システムの保守会社などに分かれます。知名度や価格だけでなく、診療フローを理解し、法令・ガイドライン、連携、運用を提案に落とせるかを確認します。

実績は「医療系の開発経験あり」という一文で判断せず、診療科、施設規模、患者数、利用者の役割、連携先、導入後の運用体制を確認します。公開事例が難しい場合も、匿名化した業務フロー、担当範囲、障害対応の考え方、検収後の保守体制を説明してもらいます。

医療向けサービスの事例では、単に診察の映像をつなぐだけでなく、本人確認、予約、処方、薬局、対面移行、データ保護が一連で設計されています。AWSのMICIN事例では、セキュリティ体制の継続改善やアクセス制御・ログ監視に加え、処方箋FAX送付機能を2日でリリースしたと紹介されています（出典：AWS「導入事例：株式会社MICIN」、2026年確認）。短期開発の実績を見る場合も、速さだけでなく、変更管理と安全性をどう両立したかを確認します。

複数社の見積を比べるときは、要件定義、UX設計、画面開発、サーバー・データベース、ビデオ通信、認証、外部連携、テスト、移行、教育、プロジェクト管理、保守を同じ項目にそろえます。見積の安さより、必要な工程が抜けていないかを先に確認します。

特に差が出やすいのは、連携先ごとの接続試験、セキュリティ診断、負荷試験、データ移行、現場教育、リリース後の伴走です。「別途」「要相談」「発注者支給」が多い場合は、発注者側の作業や追加費用を洗い出します。提案会社へ、同じRFPを渡したうえで、必須要件の対応可否と未対応項目を一覧で回答してもらうと比較しやすいです。

リリース後は、操作に慣れていない患者やスタッフから問い合わせが届きます。問い合わせ窓口の時間、一次切り分けの範囲、障害の優先度、復旧目標、利用状況のレポート、操作研修、マニュアル更新、制度変更への対応を確認します。導入後に現場から改善要望が出た際の、追加開発の見積方法も聞いておきます。

ベンダーを乗り換える可能性も発注時から考えます。患者・診療データを標準形式で出力できるか、画像や監査ログをどう返却するか、APIの利用条件、契約終了後の削除、移行支援の料金を確認します。乗り換えを想定した要件は、現在の委託先を疑うためではなく、医療機関が診療を継続するための事業継続策です。

よくある質問

オンライン診療システムの発注でよく寄せられる質問を、予算、開発期間、会社選びの順に回答します。制度やサービス料金は更新されるため、最終的な契約前には公式情報と提案書の最新版を確認します。

既存SaaSの導入では、初期0〜80万円程度、月額0〜5万円程度が検討用のレンジです。厚生労働省の調査では初期費用中央値27.5万円、月額維持費用中央値1万円でした。個別開発は機能と連携範囲によって1,000万円〜2億円超の計画推定まで幅があるため、RFPで前提をそろえた見積が必要です。

SaaSの標準導入は数週間から2か月、標準API連携を含む導入は2〜4か月、MVPの個別開発は4〜8か月、複数システム連携や多院展開を含む本番基盤は9〜18か月程度を計画値とします。実際には要件確定、相手システムの接続試験、セキュリティ審査、データ移行、医療者の受入テストで変わるため、提案会社には工程ごとの前提を提出してもらいます。

医療業務の実績、電子カルテ・レセコン・薬局との連携経験、セキュリティと責任分界の説明力、障害時の支援、データ返却条件を確認します。営業担当の説明だけで決めず、プロジェクト責任者、医療ドメイン担当、開発・運用担当との面談を行い、同じ診療シナリオを使って提案内容を比較します。

まとめ

オンライン診療システムの発注では、患者側のビデオ通話だけを見ず、予約、本人確認、問診、診療記録、決済、処方、薬局連携、対面診療への移行までを業務として整理します。1院・少数診療科で早く検証するならSaaS、独自連携を足すならクラウドカスタマイズ、多院展開や独自サービスを競争力にするならスクラッチ開発が候補になります。

発注前には、現状業務と必須要件を整理し、RFPで同じ条件の提案を依頼します。見積は総額だけでなく、連携、移行、テスト、教育、保守、従量課金、除外項目まで比較します。契約では、成果物と検収だけでなく、患者データ、再委託、セキュリティ、障害時の責任分界、終了時のデータ返却を確認します。

最後に、医療者が参加する受入テストを行い、通信断や決済失敗などの例外時にも診療を継続できる運用を作ります。最初から全機能を抱え込まず、1診療科・1拠点で始めてKPIを確認し、必要な差分だけを追加する段階導入が、手戻りを抑えながらオンライン診療を定着させる進め方です。

▼全体ガイドの記事
・オンライン診療システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。