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

訪問看護システムの発注・外注は、看護記録だけでなく、訪問予定、計画書・報告書、医療保険と介護保険の請求までを一つの業務として整理し、事業所の規模と運用に合う方式を選ぶことが成功の近道です。

「既製のクラウドを導入するのか、開発会社へ独自システムを委託するのか」「RFPには何を書けばよいのか」「見積金額が安い会社を選んでよいのか」と迷う管理者は少なくありません。この記事では、発注形態の選び方、要件整理とRFP、契約形態、2026年時点の費用レンジ、委託先選定と見積比較のポイントを、現場で確認すべき順番に沿って解説します。

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

訪問看護システムは何を発注するものですか？

訪問看護システムは、利用者台帳を電子化するだけのソフトではありません。訪問前の予定調整、訪問中のモバイル入力、訪問後の記録・帳票作成・請求、管理者による稼働状況の把握までをつなぐ業務基盤です。発注時は機能名の一覧を渡すだけでなく、一件の訪問がどのデータを経由して請求と経営管理へ届くかを確認する必要があります。

最初に発注範囲へ含めたいのは、利用者台帳、主治医や家族の連絡先、保険情報、緊急連絡先、訪問看護指示書、担当者の勤務状況を管理する機能です。管理者が電話、紙のホワイトボード、個人の表計算を行き来している場合、予定変更の伝達漏れや二重予約が起きやすくなります。利用者、担当看護師、訪問頻度、移動時間、緊急訪問を同じ画面で扱えるかを確認し、複数拠点を運営する法人は拠点別と全体の権限を分けられるかも要件に含めます。

発注先へは「スケジュール機能が欲しい」とだけ伝えず、「前日の急な変更を全担当者へ通知したい」「訪問順の候補を自動で比較したい」「夜間の緊急訪問を履歴として残したい」のように業務の状態で伝えます。2026年には、eWeLLが訪問看護向けに最大1か月間の訪問予定と移動ルートを自動最適化するサービスを有償提供しており、予定作成支援は新しい比較軸になっています（出典: 株式会社eWeLLプレスリリース、2026年6月）。

訪問先で入力したバイタル、状態、処置、写真、家族への連絡内容が、訪問看護記録書、計画書、報告書、請求データへ再利用される設計が理想です。スマートフォンやタブレットで入力できても、事務所に戻って紙へ転記するなら、発注の目的である二重入力の削減を達成できません。通信圏外での一時保存、送信失敗時の再送、端末紛失時の遠隔ロック、写真データの保管期間も確認します。

訪問看護では、同じ利用者でも医療保険と介護保険の扱いが変わることがあり、加算や返戻の確認も必要です。したがって、発注要件の中心は「電子カルテがあるか」ではなく、「入力した事実が正しい制度判定と請求につながるか」です。デモでは架空の利用者を一人登録し、予約、訪問記録、計画書・報告書、請求の順に操作して、どこで再入力や手作業が発生するかを見ます。

発注形態はSaaS・パッケージ・スクラッチのどれを選びますか？

発注形態は、安い順に決めるものではありません。標準業務へ合わせられる範囲、法改正への追随、外部連携の必要性、将来の拠点数、社内で保守を担える人材を比較し、最初の請求を安全に通せる方式を選びます。小規模ステーションがいきなり全機能を独自開発するより、標準機能を早く使い始め、差別化したい部分だけを連携・追加開発する方が合う場合もあります。

SaaSやクラウド型は、サーバー構築や大規模な初期開発を抑え、数日から1か月程度の初期設定で使い始められる可能性があります。法改正に合わせたアップデート、バックアップ、障害監視を提供会社へ任せやすい点も利点です。開業直後、紙やExcelから移行する事業所、利用者数や職員数がまだ変わりやすい事業所は、契約期間、解約時のデータ返却、サポート時間、1人・1訪問単位の従量料金を先に確かめます。

ただし、業務をSaaSへ合わせる必要があります。独自の帳票、特殊な勤務ルール、既存基幹との深い連携が必須なら、標準機能で代替できる業務と追加開発が必要な業務を分けます。クラウドに患者情報を置くことへ不安がある場合は、保存場所、暗号化、アクセス権限、多要素認証、監査ログ、バックアップ、インシデント時の連絡体制を、営業資料だけでなく契約書やセキュリティ資料で確認します。

既製パッケージを中心に、勤怠、経営ダッシュボード、ルート管理、通知、会計などをAPIやCSVでつなぐ方式は、現実的な中間案です。請求や帳票など制度対応が必要な中核は専門製品に任せ、法人独自の分析や業務だけを別システムで補います。発注時はAPIの有無だけでなく、利用できる項目、更新頻度、エラー通知、データの所有者、連携停止時の復旧方法まで確認します。

複数の事業所を統合する法人では、看護、介護、障害福祉の利用者情報をどこまで共通化するかが重要です。全員がすべての情報を閲覧できる設計は便利に見えても、最小権限の原則と合わないことがあります。拠点、職種、役割、担当利用者ごとに閲覧・編集・出力の権限を分け、退職者のアカウント停止を誰が何時間以内に行うかまでRFPへ書きます。

スクラッチ開発は、複数法人・複数拠点の独自業務、地域連携基盤との接続、将来のデータ分析などを細かく設計できる方式です。一方で、制度改定への対応、脆弱性修正、障害監視、夜間の問い合わせ、保守人材の確保が自社の責任になります。開発会社へ委託しても、契約終了後にソースコード、設計書、インフラ設定、データを引き継げる状態かを決めておかなければ、ベンダーロックインが起きます。

独自開発を選ぶ基準は、「既製品にない機能が欲しい」だけでは不十分です。標準機能では事業上の差別化ができない、外部システムとの連携が売上や品質に直結する、社内にプロダクト責任者を置ける、といった条件がそろうかを検討します。まずは1拠点・1チームでモバイル記録と請求の最小構成を検証し、その結果をもとに複数拠点やAIへ広げる段階導入が安全です。

訪問看護システムの発注・外注を進める手順

発注の失敗は、開発会社を決めた後ではなく、発注前に要件を曖昧にした時点で始まります。現場の業務を観察し、RFPで条件をそろえ、デモやPoCで実操作を試し、契約後に小さく導入する流れを作ります。最初から完璧な仕様書を作る必要はありませんが、優先順位と受け入れ条件は発注前に合意しておくことが大切です。

現場看護師、管理者、請求担当、事務担当、可能であれば医師やケアマネジャーにも参加してもらい、業務を時間の流れで書き出します。訪問前は予定作成と指示書確認、訪問中は本人確認と記録、訪問後は承認と帳票作成、月次は保険判定、請求、返戻確認という形です。各工程について、入力者、入力項目、参照する情報、出力先、現在の困りごと、許容できる手作業を整理します。

紙帳票とExcelをすべて廃止する前提にすると、移行の負担が大きくなります。まず「請求前に必ず確認したい情報」「訪問先で入力しないと二重入力になる情報」「監査や事故対応で履歴を残す情報」を分けます。入力時間、記録漏れ、返戻、訪問予定作成時間、残業時間を導入前に測っておくと、導入後の効果を金額だけでなく業務指標でも判定できます。

RFPには、事業所数、利用者数、職種と人数、月間訪問件数、医療保険と介護保険の比率、訪問エリア、夜間対応、既存システム、移行データ量、必要な外部連携を記載します。機能は「必須」「できれば欲しい」「将来検討」に分け、見積でどこまで含めるかを揃えます。例えば必須機能を利用者台帳、予定、モバイル記録、計画書・報告書、医療・介護請求、権限管理、監査ログとし、AIや経営分析は追加候補に分けます。

非機能要件も同じくらい重要です。スマートフォンとタブレットの対応OS、通信圏外時の扱い、復旧目標、バックアップ頻度、暗号化、多要素認証、ログ保存期間、サポート時間、法改正時の更新責任、データ返却形式を指定します。訪問看護レセプトのオンライン請求やオンライン資格確認については厚生労働省の最新資料が更新されるため、「将来対応予定」ではなく、対応時期、対象範囲、追加費用、テスト環境をベンダーから回答してもらいます（出典: 厚生労働省「訪問看護レセプトの電子化」、2026年確認）。

資料の機能一覧だけでは、現場で使いやすいか判断できません。匿名化した利用者情報を使い、予定変更、訪問先での入力、写真や音声メモ、上長承認、計画書・報告書の作成、請求前のエラー確認までを通して操作します。入力にかかった時間、タップ数、途中で迷った箇所、通信が切れた時の挙動、管理者が修正できる範囲を記録し、看護師と事務担当の両方から評価します。

独自開発の場合は、いきなり全機能を作るのではなく、1拠点・1チームでモバイル記録と請求連携を試すPoCが有効です。受け入れ条件は「訪問記録が一定時間以内に登録できる」「必須項目の抜けを検知できる」「請求に必要な項目が正しく出力される」のように測定可能にします。PoCの費用、作成物の権利、正式開発へ進まなかった場合のデータ扱いも、発注前に契約へ入れます。

システムが完成しても、既存データが移せず、職員が入力できず、最初の請求で混乱すれば導入は失敗です。利用者台帳、保険情報、過去記録、指示書のどこまで移行するか、移行前の名寄せを誰が行うか、誤登録時の修正履歴をどう残すかを決めます。移行件数だけでなく、紙資料のスキャン、入力代行、旧システムの閲覧期間も見積の対象にします。

研修は管理者向け、請求担当向け、訪問看護師向けに分け、実際の一日の業務で練習します。本番前には並行運用期間を置き、少なくとも一度は請求前のデータ照合を行います。稼働後30日、60日、90日の支援窓口、問い合わせの優先度、障害時の代替手段を決めておくと、現場の「結局紙に戻る」を防ぎやすくなります。

契約形態と責任分界を先に決める

同じ「外注」でも、完成した成果物を納品してもらう契約と、専門家に一定期間の作業を支援してもらう契約では、責任と費用の考え方が異なります。SaaSの利用契約、初期設定・データ移行の契約、追加開発の契約、保守・運用の契約を一つにまとめるのか、分けるのかを明確にし、後から追加費用が発生する条件を先に確認します。

請負契約は、合意した成果物を完成させることを重視する契約です。画面、帳票、API、テスト結果などの納品物と検収条件を明確にできる場合に向きますが、要件変更が多いと追加見積が増えやすくなります。準委任契約は、要件定義、設計、改善、運用支援などの業務を一定期間委託する形で、変化に対応しやすい一方、作業時間や体制の管理が必要です。

SaaSでは、サービス提供者が継続運用する範囲と、利用者側が設定・入力する範囲を利用規約や個別契約で確認します。追加開発を依頼する場合は、標準機能のアップデートで作った機能が壊れたときの修正責任、仕様変更の承認者、月額料金に含まれるサポートの範囲を決めます。見積書に「一式」とだけ書かれた項目は、作業内容、数量、前提条件、含まない作業を質問して明細化します。

訪問看護システムは、病歴、服薬、家族情報、保険情報などの要配慮個人情報を扱います。厚生労働省は2026年6月に「医療情報システムの安全管理に関するガイドライン第7.0版」を公表し、経営管理、企画管理、システム運用、保守委託機関などの編に分けて安全管理を示しています（出典: 厚生労働省、2026年6月）。発注先の認証取得だけで安心せず、利用者側のアカウント管理、委託先の再委託、ログ確認、バックアップ復旧、事故報告の役割を確認します。

契約書には、障害の重大度ごとの一次連絡時間、復旧目標、計画停止の通知、漏えい時の報告期限、バックアップからの復元テスト、データの保管地域、契約終了時の削除・返却方法を記載します。開発会社が再委託する場合は、再委託先の名称、作業範囲、秘密保持、アクセス権限、監査可能性も確認します。医療情報を扱う発注では、機能の安さより責任分界の曖昧さが将来の大きなコストになるためです。

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

費用は、月額利用料、初期設定、端末、データ移行、研修、追加開発、保守、請求や連携のオプションに分けて見ます。公開料金と、個別見積が必要な費用を混ぜると、最初は安く見えても年間総額が比較できません。ここでは2026年時点で確認できる公開価格と、リサーチノートに基づく業務システムの推定レンジを分けて示します。

公開料金の例では、ナーシングネットプラスワンが月額8,000円から、iBowが1事業所あたり基本料金18,000円に証明書費用1,000円と事業規模に応じた従量料金、カイポケ訪問看護が月額25,000円（税別）の定額制を掲げています（出典: 各社公式料金ページ、2026年8月確認）。このため、訪問看護向けSaaSの公開価格を基準にすると、月額8,000円から25,000円程度に、端末、オプション、従量料金が加わるレンジをまず比較できます。

ただし、この金額だけで年間予算を決めてはいけません。初期費用が0円でも、端末を購入・レンタルする費用、回線、初期設定、操作研修、データ移行、訪問件数や利用者数に応じた従量料金が発生する場合があります。1事業所・少人数・既存データが少ない場合の初期導入は0円から30万円程度、複数端末、移行、研修を含める場合は30万円から100万円程度を検討用の概算レンジとしますが、これは個別条件からの試算であり、公式な市場平均ではありません。

訪問看護システムだけの公的な平均開発費は確認しにくいため、独自開発の費用は断定できません。リサーチノートで整理した医療・介護系の個別業務システムの情報と、モバイルアプリ、電子カルテ、医療・介護請求、外部連携、制度マスタを含む工数から試算すると、初期800万円から3,000万円程度、期間6か月から15か月程度を検討用のレンジに置けます。これは市場統計ではなく、要件を絞った場合から複数拠点・連携まで含めた場合の編集上の試算です。

見積では、要件定義、UI・UX設計、モバイル開発、サーバー・データベース、請求ロジック、制度マスタ、外部連携、テスト、移行、教育、保守を別々に出してもらいます。保守費は、一般的な見積慣行に基づく仮置きとして初期開発費の年15％から25％程度を考えることがありますが、24時間運用、法改正、セキュリティ監視、問い合わせ窓口の範囲で変わります。特定金額を正解とせず、5年間の総保有コストで比較します。

比較表を作るときは、1年目、3年目、5年目の支払額を分けます。初期設定、端末、通信、移行、研修を初年度へ入れ、月額基本料、従量料金、オプション、保守、法改正対応、データ出力費を毎年へ入れます。安い見積があったときは、機能が不足しているのか、移行や研修が別料金なのか、サポート時間が短いのか、契約期間が長いのかを確認します。

コスト削減は、機能を一律に削るのではなく、利用頻度とリスクで判断します。月次請求や権限管理を削ってはいけませんが、初期段階の経営ダッシュボードや高度なAIは後から追加できる場合があります。開発会社には、必須機能だけの案、将来拡張を含む案、既製品との連携案の3パターンを依頼すると、発注形態の違いを含めて意思決定しやすくなります。

委託先の選び方と見積比較のポイント

委託先は、知名度や営業担当者の印象だけでなく、訪問看護の業務と制度を理解し、導入後まで伴走できるかで評価します。SaaSを提供する会社と、独自開発を請け負う会社では比較の軸が違うため、同じRFPへ回答してもらい、機能・体制・総額・契約条件を並べます。見積金額の差は、単価だけでなく、要件の解釈や含まれる作業の差で生じることが多いからです。

実績は、単に「医療系の開発実績があります」では足りません。訪問看護ステーションでの導入件数、医療保険と介護保険の請求、帳票改定、オンライン請求、複数拠点、モバイル利用、データ移行の経験を確認します。守秘義務の範囲で、導入前の課題、導入期間、現場定着までの支援、障害や制度改定への対応例を聞きます。

2026年時点では、AIによる計画書・報告書の下書きや訪問予定・ルート作成を提案するサービスもあります。AI機能を評価する場合は、何を学習・参照するか、入力データが再学習に使われるか、生成結果の確認者を設定できるか、誤りを訂正した履歴が残るかを確認します。医療判断や緊急度判断を自動確定させず、最終的には看護師や管理者が確認するHuman-in-the-Loopを要件にします。

委託先の候補を絞るときは、同じ利用者シナリオでデモを依頼します。新規利用者の登録、指示書の確認、担当者の割り当て、訪問予定の変更、訪問先でのバイタル入力、写真添付、管理者承認、計画書・報告書、医療・介護の請求準備までを実演してもらいます。どの情報が引き継がれ、どこで再入力し、エラーを誰が直すのかを、画面を見ながらメモします。

現場看護師には入力の速さと視認性、管理者には予定変更と権限、請求担当には制度判定と返戻対応、経営者には稼働率や未収管理を評価してもらいます。担当者ごとに採点表を作り、価格だけでなく「必須機能の適合度」「月次業務の削減」「学習のしやすさ」「障害時の代替手段」を比べます。営業デモで再現できない条件は、正式導入前のPoCや受け入れテストの項目へ移します。

各社の見積を比較する際は、要件定義、設計、開発、テスト、移行、研修、保守、サポートを同じ列に並べます。工数、人月単価、外部サービス費、端末費、月額、従量料金、税、契約期間、解約条件を明示してもらい、「含まないもの」も同じ資料へ記載します。特にデータ移行、帳票の追加、API連携、制度改定、訪問看護師への現地研修は、後から追加費用になりやすい項目です。

選定時には、最安値の会社へすぐ発注せず、見積差分を質問します。回答が早いかだけでなく、要件の不明点を質問できるか、リスクと前提を説明できるか、都合の悪い制約も伝えるかを見ます。月額が安い会社でも、データ出力が有料、サポートが平日昼間のみ、端末が別契約、契約終了時に移行支援がない場合があります。反対に高い見積でも、請求テスト、研修、運用設計が含まれていれば、実質的な追加負担が小さいことがあります。

よくある質問

訪問看護システムを発注するときに、管理者から特に多く寄せられる質問へ回答します。費用や期間は規模、データ量、請求方式、連携の有無で変わるため、ここでは判断の軸を示します。

公開価格のあるクラウド型では、月額8,000円から25,000円程度を一つの比較起点にできます。ただし、端末、従量料金、初期設定、移行、研修、オプションを含めると変わるため、初年度と5年間の総額で見積を比較します。独自開発は要件の幅が大きく、訪問看護固有の公的平均がないため、800万円から3,000万円程度は検討用の試算にとどめ、必ず個別見積を取得します。

既製クラウドの初期設定は数日から1か月程度、データ移行と研修まで含めると1か月から3か月程度が目安です。パッケージのカスタマイズは3か月から9か月程度、スクラッチ開発は6か月から15か月程度を検討します。期間を短くするには、最初の請求に必要な最小機能を先に決め、AIや高度な分析、特殊な連携を第二段階へ分ける方法が有効です。

相談できますが、事業所数、利用者数、職員数、業務フロー、困っている作業、既存データ、外部連携、予算と開始時期を整理してから相談すると、比較可能な提案を得やすくなります。完成したRFPでなくても、現状課題と必須条件を1枚にまとめ、候補会社から不足している質問を出してもらいます。質問の質と、曖昧な点を見積前に明らかにする姿勢も選定評価になります。

クラウド利用の可否は、クラウドかどうかだけでなく、医療情報を扱うための安全管理、委託先管理、権限設定、暗号化、ログ、バックアップ、障害時対応を確認して判断します。厚生労働省の医療情報システム安全管理ガイドライン第7.0版を参照し、ベンダーのセキュリティ資料、契約上の責任分界、データの返却・削除方法を確認します。事業所側の端末管理やパスワード運用も含めて安全対策を設計する必要があります。

まとめ

訪問看護システムの発注・外注では、機能の多さや初期費用の安さだけで判断せず、訪問前の予定、訪問先での記録、帳票、医療・介護請求、管理者の確認が一つの流れでつながるかを見ます。SaaS、パッケージ＋連携、スクラッチにはそれぞれ適した事業所があるため、現状業務と将来の拠点数を先に整理します。

まず、現場看護師、管理者、請求担当の業務を棚卸しし、必須機能と将来機能を分けます。RFPでは、機能だけでなく、通信圏外、権限、監査ログ、バックアップ、オンライン請求・資格確認、データ移行、研修、保守まで条件化します。候補会社には同じシナリオのデモを依頼し、一件の訪問が予約から請求までつながるかを確認します。

見積比較では、初期費用、月額、端末、移行、研修、追加開発、保守、法改正対応を分け、3年から5年の総額で考えます。請負、準委任、SaaS利用の違いを理解し、個人情報、障害、再委託、データ返却の責任分界を契約へ残します。導入後90日までの支援と評価指標を決め、現場が使い続けられる訪問看護システムを発注することが、費用を成果へ変えるポイントです。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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