訪問看護システム開発の発注/外注/依頼/委託方法について

訪問看護システムの発注は、業務の棚卸し、RFPの作成、デモとPoC、契約、段階導入の順に進めると、請求までの運用を整えられます。発注する範囲と方式は、この手順に入る前に決めておきます。

▼全体ガイドの記事
・訪問看護システム開発の完全ガイド

発注の対象となる業務範囲

訪問看護システムを中心に、予定調整、訪問記録、帳票、請求を結んだ図解。
訪問の情報が記録から請求へ引き継がれる構成です。

訪問看護システムは、利用者台帳を含め、予定調整、訪問記録、帳票、請求、稼働状況の把握までをつなぐ業務基盤です。

発注の際は、一件の訪問データが請求と経営管理へ届く流れを、発注側の担当者が実際に確かめます。

訪問前の予定と利用者情報の管理

予定管理では、情報を一か所で管理できるか、急な変更に対応できるかを確かめます。

  • 管理情報:台帳・指示書、主治医・家族の連絡先、保険・緊急連絡先、職員の勤務状況
  • 拠点別の権限:複数拠点の場合は、拠点別と全体の権限を分けられるかどうか。
  • 変更・履歴:急な予定変更の通知と訪問履歴の記録を、業務の状況に合わせた要望として伝えます。
  • 一覧表示:利用者・担当者・訪問頻度・移動時間・緊急訪問を、同じ画面で扱えるかどうか。

予定作成の支援も、比較の軸になります。たとえば、2026年にはeWeLLが、最大1か月間の訪問予定と移動ルートを自動で最適化するサービスを有償で提供しています(出典:株式会社eWeLLプレスリリース、2026年6月)。

電話や紙、個人の表計算を行き来する運用では、変更の伝達漏れや二重予約が起きがちです。

訪問記録から帳票・請求までを再入力なしでつなぐ仕組み

事務所へ戻って紙に転記する運用では、訪問先で記録した内容を再び入力することになるため、二重入力は減りません。

  • 入力情報の再利用:バイタル、状態、処置、写真、家族への連絡を、記録書・計画書・報告書・請求へつなげられるかどうか。
  • 通信・端末対応:圏外時の保存と送信失敗時の再送、紛失時の遠隔ロック、写真の保管期間。
  • 請求までの実演:架空の利用者で予約から請求までを操作し、再入力や手作業が残る箇所を洗い出す。
  • 制度判定:同じ利用者でも医療・介護保険の扱いが変わることがあり、加算や返戻の扱いも見る。

発注形態(SaaS・パッケージ・スクラッチ)の選び方

SaaS・クラウド型、パッケージとAPI連携、スクラッチ開発の特徴を並べた3パネル図。
標準機能の活用から独自設計まで、対応範囲が広がります。

発注形態は、まず標準業務に合うかどうかと、法改正にどう追随するかで考えます。外部連携、将来の拠点数、保守人材の有無も、選ぶ際の材料になります。

小規模な事業所では、標準機能から使い始め、必要な部分だけを後から追加する方法もあります。

早く始めたい事業所に合うSaaS・クラウド型

SaaSやクラウド型は、サーバーの構築や大規模な初期開発を抑えられる方式です。初期設定は数日から1か月程度で済みます。さらに、法改正対応やバックアップ、障害監視も提供会社に任せやすい点が特徴です。

  • 契約条件:契約期間、解約時のデータ返却、サポート時間の範囲
  • 従量料金:1人・1訪問単位の料金の有無
  • セキュリティ:保存場所と暗号化、権限、多要素認証、監査ログ
  • 追加開発:独自帳票や既存基幹との連携を、標準機能で代替できるかどうかの切り分け

クラウド上の患者情報に不安がある場合は、バックアップや事故時の連絡体制も、契約書とセキュリティ資料で確かめます。

開業直後や紙・Excelから移行するときは、利用者数や職員数が変わることも見込んでおきます。

パッケージとAPI連携による標準業務と独自業務の両立

連携先と情報にアクセスできる範囲を整理して、製品ごとの役割を決めておきます。

  • 製品の分担:請求・帳票は専門製品に任せ、法人独自の分析は別システムで補う形。
  • 連携条件:APIやCSVの項目・更新頻度・エラー通知・データ所有者・停止時の復旧方法
  • 情報の共通化:看護・介護・障害福祉の利用者情報を、どこまでまとめるかの線引き。
  • 閲覧・編集権限:拠点・職種・役割・担当利用者ごとに分け、退職者の停止担当と期限をRFPに書き込む。

全員がすべての情報を見られる設計は、最小権限の原則に合わないことがあります。

独自性と連携を優先する場合のスクラッチ開発

スクラッチ開発は、設計の自由度と、社内で継続して運用できるかを合わせて判断します。

  • 設計の自由度:複数法人・拠点の独自業務、地域連携基盤、将来の分析を設計に組み込める点。
  • 運用責任:制度改定、脆弱性修正、障害監視、夜間窓口、保守人材の確保など、継続して担う作業。
  • 契約終了時の引き継ぎ:ソースコード、設計書、インフラ設定、データの扱いを取り決める。
  • 選定条件:標準機能では差別化できず、連携が売上や品質に直結し、社内に責任者を置ける場合。
  • 段階導入:1拠点・1チームで記録と請求を試し、結果を見て複数拠点やAIへ広げる進め方。

引き継ぎ条件が曖昧だと、ベンダーロックインにつながります。

ポイント

標準機能で業務が収まるなら、早く始められるSaaS・クラウド型を検討します。標準と独自の業務を両立したいならパッケージとAPI連携、独自性と連携を優先し社内に責任者を置けるならスクラッチ開発を選びます。

訪問看護システムの発注・外注の手順

発注手順を業務の棚卸し、RFP、デモとPoC、移行・研修の4項目で示した図。
現場の整理から稼働後支援までを発注範囲に含めます。

発注前に業務を観察し、RFPで条件をそろえたうえで、デモやPoCで操作を試してから小さく導入します。

仕様の優先順位と受け入れ条件は、発注側と開発会社のあいだで合意しておきます。

1.訪問前・訪問中・訪問後・月次請求の業務の棚卸し

棚卸しには、現場看護師、管理者、請求・事務担当に加わってもらいます。

可能であれば、医師やケアマネジャーにも確認します。

各工程について、入力者、項目、参照情報、出力先を書き出します。困りごとや、許容できる手作業も併せて残します。

  1. 訪問前は、予定作成と指示書確認の流れを整理します。
  2. 訪問中は、本人確認と記録の手順を洗い出します。
  3. 訪問後は、承認と帳票作成の順番を並べます。
  4. 月次は、保険判定、請求、返戻確認の順序を確かめます。

紙帳票とExcelをすべて廃止する前提で進めると、移行の負担が大きくなります。そのため、請求前の確認事項、訪問先で入力が必要な情報、監査や事故対応で残す履歴を優先します。

導入前に、入力時間、記録漏れ、返戻、予定作成時間、残業時間を測っておきます。そうすると、導入後の効果を金額だけでなく、業務指標でも判定できます。

2.RFPに書く業務要件・非機能要件・見積条件

見積条件をそろえるため、RFPには事業規模、必要機能、運用条件を分けて記載します。

  • 事業情報:事業所数、利用者数、職種と人数、月間訪問件数
  • 運用環境:保険比率・訪問エリア・夜間対応・既存システム・移行量・外部連携
  • 機能の優先度:必須・希望・将来の三つに分け、台帳・予定・記録・帳票・請求・権限・監査ログを必須候補にする。
  • 非機能要件:対応OS・圏外時・復旧目標・バックアップ頻度・暗号化・認証・ログ保存期間・サポート時間・法改正時の更新責任・返却形式を指定します。
  • 見積条件:オンライン請求・資格確認の時期と範囲、追加費用、テスト環境について、開発会社から回答を得ます。

AIや経営分析は、追加候補として分けておきます。一方で、オンライン請求や資格確認は、「将来対応予定」とだけ書かれた回答では済ませず、具体的な回答を求めます(出典:厚生労働省「訪問看護レセプトの電子化」、2026年確認)。

3.実データに近いシナリオでのデモとPoC

実データに近い操作を通して、現場での使いやすさを確かめます。

  • デモシナリオ:匿名化した利用者情報で、予定変更から訪問入力、写真・音声メモ、承認、帳票、請求前の確認まで。
  • 記録する項目:入力時間・タップ数・迷った箇所・圏外時の動作・管理者の修正範囲
  • PoCの範囲:独自開発の場合は、1拠点・1チームでモバイル記録と請求連携を試します。
  • 受け入れ条件:記録時間と必須項目の検知、請求項目の正しい出力を、あらかじめ定めます。
  • 契約事項:PoC費用、成果物の権利、正式開発へ進まない場合のデータの扱い

4.移行・研修・請求開始後の支援を含む発注範囲

移行から稼働後の支援まで、どこまでを発注範囲に含めるかを決めます。

  • 移行データ:利用者台帳、保険情報、過去記録、指示書の移行範囲
  • 移行作業:名寄せ担当、誤登録の修正履歴、紙資料のスキャン、入力代行、旧システムの閲覧を、見積に含めます。
  • 研修:管理者、請求担当、訪問看護師ごとに分け、実務に沿った内容にします。
  • 稼働前確認:本番前の並行運用と、少なくとも一度は請求前のデータ照合。
  • 稼働後支援:稼働後30日・60日・90日の窓口と問い合わせの優先度、障害時の代替手段を決め、紙への逆戻りを防ぎます。

ポイント

迷ったときは、業務の棚卸しで現場の困りごとを洗い出し、RFPで条件をそろえてから、デモとPoCで操作を試します。移行、研修、稼働後の支援も発注範囲に含めて決めておきます。

契約形態と責任分界の決め方

成果物の納品を重視する契約と、一定期間の作業を専門家に委託する契約とでは、責任と費用が異なります。そのため、SaaS・設定・移行・追加開発・保守の契約を分けるか、まとめるかを先に決めておきます。

請負・準委任・SaaS利用契約の違い

契約形態ごとに成果物や作業の責任が異なるため、追加費用の条件もあわせて確かめます。

  • 請負:成果物の完成を重視する契約で、納品物と検収条件を定めます。ただし、変更があると追加見積が増える傾向があります。
  • 準委任:要件定義や運用支援を一定期間委託する契約です。変化に対応しやすい一方で、時間と体制の管理が必要になります。
  • SaaS:提供者の運用範囲と利用者の設定・入力範囲を確かめ、追加開発の修正責任も決めます。
  • 見積明細:「一式」の項目は、作業内容、数量、前提条件、対象外作業を質問して明らかにします。

SaaSの追加開発では、仕様変更の承認者と、月額料金に含まれるサポート範囲も決めておきます。

個人情報・障害・データ返却の責任分界と契約への記載

病歴、服薬、家族、保険情報などの要配慮個人情報を扱うため、安全管理の責任を確かめておく必要があります。なお、厚生労働省は2026年6月にガイドライン第7.0版を公表しました(出典:厚生労働省、2026年6月)。

  • 日常管理:利用者側のアカウント、ログ確認、バックアップ復旧、事故報告の役割分担
  • 障害対応:連絡時間・復旧目標・計画停止の通知・漏えい報告期限を、契約に記載します。
  • データ管理:復元テスト、保管地域、契約終了時の削除・返却方法
  • 再委託:委託先名、作業範囲、秘密保持、権限、監査可能性

発注先の認証取得を確認したうえで、責任分界を曖昧にしないことが、将来の負担を抑えます。

ポイント

成果物の完成を求めるのか、作業を一定期間任せるのかで、責任と費用が変わります。個人情報、障害、データ返却の責任分界は、契約に記載しておきます。

訪問看護システムの費用相場と見積の内訳

費用は、初期費用と月額に分けて見ます。初期費用には、初期設定、端末、移行、研修が加わります。追加開発、保守、請求や連携のオプションは、費用の項目として別に確かめます。

2026年時点の公開価格と、リサーチノートに基づく推定レンジは、区別して読みます。

クラウド型の公開価格の目安(月額8,000円から25,000円程度)

公開価格の例は、月額8,000円から25,000円程度です。ただし、次に挙げる料金には、端末や従量料金などが別途加わる場合があります。

  • ナーシングネットプラスワン:月額8,000円から
  • iBow:1事業所あたりの基本料金18,000円、証明書費用1,000円、規模別の従量料金
  • カイポケ訪問看護:月額25,000円(税別)の定額制
  • 初期導入:1事業所・少人数・データ少なめなら0円〜30万円程度、複数端末・移行・研修込みなら30万〜100万円程度の試算

出典は各社の公式料金ページ(2026年8月確認)です。また、初期費用は個別条件による試算で、公式な市場平均ではありません。

初期費用には端末、回線、設定、研修、移行が加わります。一方で、月額は利用者数や訪問件数に応じた料金が発生する場合があります。

独自開発の検討用レンジ(800万円から3,000万円程度)

訪問看護システム固有の公的な平均開発費は確認しにくいため、次の数値は検討用の試算です。

  • 初期費用・期間:800万〜3,000万円程度、6〜15か月程度を見込みます。
  • 試算の範囲:要件を絞る場合から、複数拠点・連携を含む場合まで。
  • 見積項目:要件定義、UI・UX、アプリ、基盤、請求、制度マスタ、連携、テスト、移行、教育、保守ごとの内訳。
  • 保守費:初期費用の年15〜25%程度を仮置きする場合があります。
  • 比較期間:24時間運用などの条件も確かめたうえで、5年間の総保有コストで比べます。

試算は市場統計ではなく、編集上の目安です。また、保守費は、法改正、セキュリティ監視、問い合わせ窓口の範囲によって変わります。

見積書の初期費用・月額・追加費用の並べ方

支払時期と費用の内訳をそろえておくと、見積同士を比べられます。

  • 支払時期:1年目、3年目、5年目の支払額
  • 費用の内訳:初年度は初期設定・端末・通信・移行・研修、各年は基本料・従量・オプション・保守・法改正・出力費を計上します。
  • 見積差の確認:安い見積では、機能不足、移行・研修の別料金、サポート時間、契約期間を確かめます。
  • 費用削減:利用頻度とリスクで判断し、月次請求や権限管理は削りません。
  • 追加案:経営ダッシュボードや高度なAIは、後から追加できる場合があります。そのうえで、必須機能のみ、将来拡張込み、既製品連携の3案を依頼します。

ポイント

クラウド型は公開価格を比べる起点にし、独自開発は800万円から3,000万円程度の試算を出発点にします。どちらも、初年度と5年間の総額で見積を比べます。

委託先の選び方と見積比較

委託先は、訪問看護の業務と制度を理解しているか、導入後も支援できるかで評価します。そのうえで、同じRFPをもとに、機能、体制、総額、契約条件を比べます。

訪問看護の実績と制度対応の責任者

訪問看護の制度対応と、現場での導入後の経験を具体的に確かめます。

  • 導入経験:ステーション導入から、医療・介護請求、帳票改定、オンライン請求、複数拠点、モバイル、データ移行まで
  • 対応事例:導入前の課題、現場定着、障害、制度改定への対応例
  • AI機能:2026年時点で、計画書・報告書の下書きや訪問予定・ルート作成を提案するサービスもあります。
  • AIの確認体制:学習・参照内容、入力データの再学習利用、結果の確認者、訂正履歴
  • 医療判断:医療や緊急度は自動で確定させず、看護師や管理者が確認します。

一件の訪問を予約から請求まで操作するデモ

同じ利用者シナリオで、新規登録、指示書確認、担当者割当、予定変更を、開発会社に実演してもらいます。バイタル入力と写真添付、承認、帳票、請求準備も、同じ流れで見せてもらいます。また、情報の引き継ぎ、再入力、エラー修正について、誰が担当したかを記録します。

看護師は入力速度と視認性、管理者は予定変更と権限、請求担当は制度判定と返戻、経営者は稼働率と未収を評価します。加えて、必須機能、業務削減、学習のしやすさ、障害時の代替手段も比べます。

営業デモでは再現できない条件は、正式導入の前のPoCや受け入れテストに移します。

前提条件と5年間の総額による見積比較

比較表では、同じ条件で各社の費用と契約範囲を並べます。

  • 作業費:要件定義、設計、開発、テスト、移行、研修、保守、サポート
  • 料金条件:工数・人月単価・外部サービス・端末・月額・従量料金・税の明示
  • 契約条件:期間、解約、データ出力、移行支援、窓口時間
  • 追加費用:帳票、API、制度改定、現地研修が見積に含まれるかどうか。
  • 見積差分:不明点、リスク、制約への説明と、請求テスト・研修の有無を評価します。

最安値の見積にすぐ発注せず、差額の理由や見積の前提を質問します。端末別の契約、平日日中のみの窓口、データ出力費、移行支援の有無も、実質的な負担を左右します。

高い見積でも、請求テスト、研修、運用設計が含まれていれば、追加の負担が小さい場合があります。

ポイント

委託先は、訪問看護の制度と実績、デモで一件の訪問を予約から請求まで操作できるか、総額と前提条件で比べます。最安値の見積は、含まれる作業と前提を確かめてから判断します。

よくある質問

費用や期間は、規模、データ量、請求方式、連携の有無で変わります。発注前に確かめておきたい判断の軸を、質問ごとに回答します。

訪問看護システムの発注費用はどのくらいですか?

公開価格のあるクラウド型は、月額8,000円から25,000円程度を比べる起点にできます。

独自開発は公的な平均がないため、800万円から3,000万円程度を検討用の試算とし、個別見積を取得します。

見積は、端末、従量料金、初期設定、移行、研修、オプションも含め、初年度と5年間の総額で比べます。

発注から利用開始まで何か月かかりますか?

クラウドの初期設定は数日から1か月程度です。移行と研修も含めると、1か月から3か月程度が目安になります。

パッケージのカスタマイズは3か月から9か月程度、スクラッチ開発は6か月から15か月程度を見込みます。

請求に必要な最小限の機能を先に作り、AIや分析、特殊な連携は第二段階に分けると、期間を短くできます。

RFPがなくても開発会社へ相談できますか?

相談できます。その前に、事業所数、利用者数、職員数、業務フローを整理します。課題、既存データ、連携、予算、開始時期も、同じように整理します。

完成したRFPがなくても、現状の課題と必須条件を1枚にまとめます。さらに、不足事項を事前に質問する姿勢も、選定の評価に含めます。

クラウドに患者情報を保存しても問題ありませんか?

クラウドかどうかだけでなく、安全管理、委託先管理、権限を確かめたうえで判断します。暗号化、ログ、バックアップ、障害時対応も、判断の材料に含めます。

厚生労働省の医療情報システム安全管理ガイドライン第7.0版を参照し、契約上の責任、データの返却・削除方法、事業所側の端末・パスワード管理も確かめます。

まとめ

発注時は、訪問前の予定、訪問記録、帳票、医療・介護請求、管理者の確認が一つの流れでつながるかを見ます。そのうえで、方式は現状の業務と将来の拠点数に合わせて選びます。

発注前の現場と要件の整理

現場看護師、管理者、請求担当の業務を棚卸しし、必須機能と将来機能を分けます。そのうえで、RFPには圏外対応、権限、ログ、バックアップの条件を書き込みます。さらに、請求、移行、研修、保守の条件も、同じRFPに含めます。

同じシナリオのデモで、一件の訪問が予約から請求までつながるかを確認します。

見積の総額、責任分界、定着支援の確認

初期費用、月額、端末、移行は、3年から5年の総額で比べます。研修、追加開発、保守、法改正対応も、同じ総額の中で見ます。あわせて、契約形態と、個人情報・障害・再委託・返却の責任分界を明記します。

稼働後90日までの支援と評価指標を決めておくと、現場への定着を確かめられます。

▼全体ガイドの記事
・訪問看護システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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