訪問看護システム開発の進め方/やり方/流れや方法/手法/工程/手順

訪問看護システムの開発は、看護記録を電子化するだけではなく、訪問前の予定調整から訪問後の帳票作成、医療保険・介護保険の請求、管理者の経営判断までを一つの流れにつなぐ取り組みです。成功のポイントは、いきなり機能を作り始めず、現場の業務を整理して「どの情報を一度入力し、どの帳票や請求に再利用するか」を決めることです。

本記事では、訪問看護システム開発の進め方を、要件整理、製品・開発会社の選定、設計・開発、テスト、稼働、定着の6フェーズに分けて解説します。クラウド製品を導入する場合と独自開発する場合の費用相場、見積もりの比較方法、訪問先で使えるかを確かめるチェックリストまで、2026年時点で実務に使える判断基準をまとめています。

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

訪問看護システム開発の全体像

訪問看護システムは、利用者台帳、訪問スケジュール、モバイル記録、計画書・報告書、請求、職員や関係者との連携を業務基盤としてまとめる仕組みです。電子カルテ単体として見ると必要な範囲を誤りやすいため、訪問前・訪問中・訪問後・月次請求の一連の業務で評価することが大切です。

現場では、利用者情報を台帳に登録し、訪問予定を組み、訪問先でバイタルや処置内容を入力し、帰社後に記録書や報告書を整え、月末に請求データを確認します。システム開発では、この流れを別々の画面に分断せず、訪問実績を一度入力すれば計画書・報告書・請求の下書きに反映されるデータ構造を設計します。二重入力が残ると、入力時間だけでなく転記ミスや記録の抜けも増えるためです。

利用者台帳には基本情報、保険情報、主治医、家族、緊急連絡先、疾患、アレルギー、同意情報などを登録します。看護師は訪問先でスマートフォンやタブレットから入力し、管理者は訪問件数、キャンセル、稼働率、加算、スタッフの負荷を確認します。医師やケアマネジャーとの共有では、誰がどの情報を閲覧できるか、いつまで保存するか、訂正履歴を残すかまで決める必要があります。

訪問看護システム開発の進め方

開発は、要件整理、選定、設計・開発、テスト、稼働、定着の順に進めると判断しやすくなります。ただし、フェーズを順番に消化するだけでは不十分です。特に請求担当と看護師が早い段階から参加し、実際の一訪問を予約から請求までつなげて確認することが、導入後の手戻りを抑えます。

最初に、訪問前、訪問中、訪問後、月次請求、管理業務を時系列で書き出します。紙帳票、Excel、既存ソフト、電話、FAX、個人のメモに分かれている作業を洗い出し、「誰が」「いつ」「何を入力し」「誰が確認するか」を表にします。利用者数、看護師数、拠点数、医療保険と介護保険の比率、緊急訪問、夜間対応、既存データ量、必要な外部連携も数値で整理します。

要件の優先順位は、最初の請求を安全に通せること、訪問先で記録が完了すること、個人情報を適切に守れることを最上位に置きます。たとえば、AIによる記録下書きや高度な経営分析は便利ですが、利用者台帳や保険判定が不安定なまま追加しても効果が出ません。要件定義書には必須、できれば欲しい、将来検討の3段階を記載し、予算と納期の判断軸にします。

選択肢は、訪問看護向けSaaS、既存パッケージのカスタマイズ、パッケージとAPIの組み合わせ、スクラッチ開発に分かれます。小規模で標準業務に合わせられる場合は、法改正対応やバックアップを任せやすいSaaSが現実的です。複数法人の独自ルール、既存基幹との深い連携、独自の経営指標が重要なら、パッケージ連携や個別開発を検討します。

比較では、機能数よりも実際の業務を再現します。デモで「利用者登録→訪問予定→訪問先で記録→計画書・報告書→請求確認」を通し、看護師が何タップで入力できるか、通信が不安定な場所でどう動くか、訂正履歴や権限設定を確認します。料金は月額だけでなく、端末、初期設定、研修、移行、追加拠点、API、サポート、解約時のデータ出力まで含めて比較します。

設計では、画面だけでなく利用者、訪問、記録、指示書、計画書、報告書、請求、スタッフ、権限といったデータの関係を定義します。モバイル画面は、片手操作、文字サイズ、入力候補、途中保存、写真や音声メモの扱い、訪問開始・終了の記録を現場で確認します。通信圏外のときに入力を端末へ一時保存するのか、完全オフラインを対象外にしてエラーを表示するのかも、曖昧にしないことが重要です。

開発は、まず一拠点・一チームで利用者台帳、予定、モバイル記録、請求に必要な最小機能を作り、次に外部連携、複数拠点、経営分析を追加する段階導入が適しています。AIを使う場合は、計画書・報告書の下書きや訪問ルート候補の提示までにとどめ、医療判断や緊急度判断を自動で確定しないHuman-in-the-Loopを要件に入れます。

テストには、画面が動くかを見る機能テストだけでなく、業務シナリオテスト、データ移行テスト、権限テスト、性能テスト、障害時の復旧テストを含めます。看護師には実際の訪問記録を入力してもらい、管理者には予定変更や緊急訪問を操作してもらい、請求担当には医療保険・介護保険、加算、返戻・過誤を含む月次処理を確認してもらいます。

受け入れ基準は「使えそう」ではなく、測れる条件にします。たとえば、一件の訪問記録を訪問終了後に何分以内で完了できるか、必須項目の未入力を検知できるか、通信断から復旧したときに重複登録が起きないか、職種ごとに閲覧範囲が分かれるか、バックアップから復旧できるかを確認します。個人情報を使うテストデータは匿名化し、本番データを安易にコピーしないことも必要です。

本稼働日は、単にシステムが完成した日ではなく、現場が使い始め、必要な記録がそろい、最初の請求を安全に確認できる日です。請求締めの直前に切り替えると、操作不慣れやデータ移行の問題が請求遅延につながるため、月初や業務負荷が比較的低い時期を候補にします。旧システムや紙帳票をいつまで参照できるか、二重運用を何日間行うかも決めておきます。

稼働初日は、管理者、現場リーダー、請求担当、ベンダーの連絡先と役割を明確にします。端末の紛失、通信障害、ログイン不能、誤登録、請求データの不整合が起きた場合に、誰へ何分以内に連絡するか、紙や電話で業務を継続するかを手順書にします。医療情報システムの安全管理では、2026年6月に厚生労働省の第7.0版が公表されているため、契約前からアクセス権限、監査ログ、暗号化、バックアップ、委託先管理、インシデント対応を確認します（出典：厚生労働省「医療情報システムの安全管理に関するガイドライン第7.0版」、2026年）。

導入後は、操作研修を一度開催して終わりにせず、職種別に短い動画や手順書を用意し、現場の質問を集めます。看護師が入力しない理由が画面の使いにくさなのか、通信環境なのか、入力項目の多さなのかを分けて、設定変更と業務ルール変更を使い分けます。管理者だけが操作できる状態では定着しないため、現場の相談役となるスーパーユーザーを各拠点に置く方法も有効です。

導入後90日間は、訪問記録の入力完了率、記録にかかる時間、予定作成にかかる時間、請求の返戻・過誤、残業時間、スタッフのログイン率、問い合わせ件数を毎月確認します。目標値は導入前に測った実績を基準に決めます。たとえば、入力時間を短縮しても記録の質や請求精度が下がっていれば成功とはいえないため、速度、正確性、利用率をセットで評価します。

訪問看護システム開発の費用相場とコストの内訳

費用は、既製クラウドを使うか、既存製品をカスタマイズするか、独自システムを開発するかで大きく変わります。公開料金と個別見積もり、導入に伴う初期費用、端末や回線などの運用費を分けて考えると、安い月額だけで判断しにくくなります。以下のレンジは公開情報と類似業務システムの見積もり慣行を整理した予算検討用の目安であり、訪問看護システム全体の公的な平均値ではありません。

訪問看護向けクラウドの公開価格では、ナーシングネットプラスワンが月額8,000円から、カイポケ訪問看護が月額25,000円（税別）を掲げています。iBowは基本料金、証明書費用、訪問件数などに応じた料金を組み合わせる方式です。これらを踏まえると、公開価格を基準にしたSaaSの目安は月額8,000円〜25,000円程度からですが、電子カルテ、医療・介護レセプト、複数拠点、端末、従量料金、追加サービスを含めると実際の支払額は変わります（出典：各社公式料金ページ、2026年8月確認）。

月額25,000円の定額で訪問件数に関わらず使える製品もあれば、基本料金に従量料金を加える製品もあります。月の訪問件数が少ない開業直後は従量型が合う場合でも、利用者が増えると定額型が有利になることがあります。反対に、定額型でも端末レンタル、モバイル回線、追加拠点、データ移行、特別な帳票は別料金の可能性があるため、見積書で確認します。

既製クラウドの初期費用が0円でも、端末の購入・レンタル、初期設定、職員研修、紙や他社ソフトからのデータ移行、帳票の調整、請求開始前の伴走支援が発生することがあります。1事業所で少人数、移行データが少ない場合は導入関連費を0円〜30万円程度、複数端末、研修、移行、個別設定まで含む場合は30万円〜100万円程度を検討レンジに置けます。ただし、これは公開料金と一般的な導入項目からの試算です。

初期費用を比較するときは、見積書の「一式」を分解します。アカウント発行、マスタ登録、職員研修、データ移行、テスト支援、現場立ち会い、稼働後サポートのどこまで含まれるかを確認し、含まれない作業を自社の工数として見積もります。端末を月額で借りる場合は、36か月の総額と買い切り価格を比べ、故障交換や返却条件まで見ておくと予算のずれを抑えられます。

独自開発は、利用者台帳と予定だけを作るのか、モバイルアプリ、電子カルテ、医療・介護請求、オンライン資格確認、外部API、複数拠点、経営分析まで含めるのかで大きく変わります。類似する医療・介護系の個別業務システムからの予算検討では、訪問看護のモバイル・請求・連携・制度対応まで含む場合、初期800万円〜3,000万円、期間6〜15か月程度を置くことがあります。これは訪問看護システムの公表相場ではなく、要件を仮置きした推定レンジです。

独自開発では、初期開発費だけでなく、保守、法改正対応、クラウド利用料、監視、障害対応、セキュリティ診断、端末更新、問い合わせ対応を毎年見込みます。保守費を初期開発費の年15〜25％程度と仮置きする見積もり慣行もありますが、契約内容や対応時間によって変動します。開発費を抑えるために保守を削ると、制度改定や障害発生時の業務継続が難しくなるため、5年間の総保有コストで比較します。

訪問看護システムの見積もりを取る際のポイント

見積もりの精度は、発注側が業務と条件をどれだけ明確に渡せるかで決まります。会社ごとに同じ前提で比較できるRFPを用意し、機能一覧だけでなく、現場のシナリオ、データ移行、セキュリティ、導入支援、運用保守を含めます。金額が安い提案を選ぶのではなく、抜けている作業がないか、将来の追加費用が読みやすいかを確認します。

RFPには、事業所数、利用者数、職員数、訪問件数、保険の種類、営業時間、夜間対応、既存システム、移行対象、連携先を記載します。機能要件は「スケジュール管理ができる」ではなく、「緊急訪問を登録し、担当者へ通知し、実績を記録し、請求対象へ反映できる」のように業務の前後関係で書きます。非機能要件には、稼働時間、応答性能、バックアップ頻度、復旧目標、監査ログ、暗号化、多要素認証、権限、データ保管場所、障害時の連絡体制を含めます。

特にモバイル利用では、端末の種類、OS、画面の向き、通信圏外、端末紛失、写真撮影、通知、バッテリー切れを確認します。訪問看護のオンライン請求・オンライン資格確認は、2024年6月の開始と2024年12月2日からの義務化が案内されているため、2026年時点でも製品の対応状況、端末要件、経過措置の有無を契約前に確認します（出典：厚生労働省「オンライン資格確認について」「訪問看護レセプトの電子化」、2026年確認）。制度対応をベンダー任せにせず、更新時の責任分担を契約書に残します。

デモでは、営業担当の説明を聞くだけでなく、実際の看護師が一件の訪問を操作します。確認項目は、(1)利用者情報と保険情報の登録、(2)担当者と訪問枠の設定、(3)訪問先でのバイタル・処置・写真・音声メモの入力、(4)途中保存と通信断からの復旧、(5)計画書・報告書への反映、(6)管理者の承認、(7)請求データの確認、(8)訂正履歴の確認です。ここで入力の負担やデータ連携の欠落が見つかれば、契約前に条件を修正できます。

無料トライアルがある場合は、最低でも一つの実業務サイクルを試します。看護師、管理者、請求担当の3者が同じデータを使い、誰がどこで困ったかを記録します。トライアル期間中にサポートへ質問し、回答までの時間、制度判断の相談範囲、操作以外の支援、障害時の連絡窓口を確認することも、料金表だけでは分からない重要な比較材料です。

見積書と契約書では、納品物、検収条件、仕様変更の扱い、移行作業の範囲、操作研修、問い合わせ対応、法改正対応、障害時の復旧、バックアップ、解約時のデータ出力を確認します。SaaSでは、データをCSVで出せるか、画像や帳票も含めて返却されるか、退会後にいつ消去されるかを確認します。独自開発では、ソースコード、クラウドアカウント、ドメイン、APIキーの管理者と、保守会社を変更できる条件を明確にします。

医療情報を扱うため、ベンダーのセキュリティ認証だけで安心せず、自社の運用も決めます。職種別の権限、退職者のアカウント停止、共有端末の自動ロック、パスワードや多要素認証、監査ログの確認、端末紛失時の遠隔消去、紙に残った帳票の廃棄を運用規程に落とします。開発会社には、委託先や再委託先、データ保管地域、インシデント時の初動と報告期限を質問します。

よくある質問（FAQ）

訪問看護システムの導入では、開発方法、費用、現場での使いやすさについて疑問が生じます。ここでは、発注前に多く寄せられる質問へ直接回答します。

標準的な業務で早く導入したい場合は既製クラウド、独自の業務ルールや複数システムとの深い連携が重要な場合は独自開発が向いています。まず既製品のデモで業務を再現し、足りない部分が設定やAPIで補えるかを確認してから、開発費と保守費を含めて判断します。

既製クラウドの初期設定は数日から1か月程度、データ移行や研修まで含めると1〜3か月程度が目安です。パッケージをカスタマイズする場合は3〜9か月、スクラッチ開発は要件と連携範囲によって6〜15か月程度を予算検討のレンジに置きます。請求開始日から逆算し、要件・移行・テスト・研修の期間を確保することが大切です。

対応可否は製品と契約プランによって異なるため、製品名だけで判断せず、訪問看護の医療保険請求、オンライン請求、オンライン資格確認、端末要件、制度改定時の更新時期を確認します。厚生労働省は訪問看護についてオンライン請求とオンライン資格確認の導入を進めており、2026年にも訪問看護ステーション向け端末要件を更新しています。自社の対象範囲と経過措置を確認し、ベンダーの対応予定を文書で受け取ります（出典：厚生労働省、2026年）。

まとめ

訪問看護システム開発は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで進めます。最初に現場の業務を分解し、一度入力した訪問情報を記録、帳票、請求、経営管理へ再利用できる状態を目指します。月額料金や機能数だけでなく、訪問先での入力、請求の正確性、データ移行、サポート、セキュリティを同じ条件で比べることが重要です。

新規開発で最初から全機能を実現しようとすると、予算も期間も膨らみ、現場の確認が追いつかなくなります。利用者台帳、訪問予定、モバイル記録、計画・報告、請求の最小構成を先に検証し、その後に複数拠点、医師・家族連携、経営分析、AI支援を追加する段階導入が安全です。RFPでは必須機能と将来機能を分け、受け入れ基準を数字で定めます。

まず看護師、管理者、請求担当を集め、現在の一訪問を予約から請求まで記録します。その業務シナリオを使って複数の製品・開発会社にデモと見積もりを依頼し、入力時間、請求への反映、データ移行、障害対応、5年間の総額を比較します。導入後90日間の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を創業。