服薬管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

服薬管理システムの開発は、対象業務と例外を先に整理し、方式と連携範囲を選んでから、試用と改善を重ねて進めます。全体は6つのフェーズに分かれ、要件整理から定着まで、順に確認しながら進めます。費用の目安や見積もりで確認したい点も、あわせて紹介します。

▼全体ガイドの記事
・服薬管理システム開発の完全ガイド

服薬管理システム開発の全体像

服薬管理システムの共通機能を、マスタ・予定、実績・変更、安全管理の3層に分けた図。
予定・実績・安全管理が業務を支える構成です。

服薬管理システムは、薬剤情報に加えて、誰に、いつ、どの薬を渡したかを記録する業務システムです。服薬の成否と報告先まで、一続きで管理します。

先に対象業務を切り分けておけば、不要な機能を避けつつ、安全性と使いやすさを両立させられます。

介護施設・病院・薬局で使う場所の違い

利用場所によって中心になる業務が異なります。そのため、必要な機能を決める前に、次の違いを確認しておきます。

  • 介護施設・在宅介護:薬包、時刻、介助者、服薬結果を記録
  • 病院・診療所:処方や投与実績を既存システムと連携
  • 調剤薬局・患者向け:服薬指導、残薬確認、処方箋送信などに対応

介護現場では、渡し間違いや飲み忘れ、重複投与を防ぐことが中心になります。こうした業務を支える候補には、タブレット、薬包OCR、顔認証があります。QRコードや服薬実績ログも候補になります。

病院では、持参薬、処方、変更・中止を扱います。アレルギーや相互作用も、業務の中に含まれます。特に、電子カルテ、オーダリング、薬剤部門システムとの連携は押さえておきたい点です。

薬局や患者向けでは、電子薬歴、服薬指導、副作用確認が中心です。

オンライン服薬指導や電子お薬手帳なども含まれます。

共通機能と安全性の配置

服薬の予定から実績確認まで安全につなぐため、次の機能を業務フローに合わせて配置します。

  • マスタ・予定:利用者、薬剤、用法用量、服薬時刻、スケジュール、リマインド
  • 実績・変更:実施、拒否、飲み忘れ、中止理由、変更履歴
  • 安全管理:アラート、帳票、監査ログ、権限、バックアップ

介護施設では、誰が、いつ、誰に、どの薬を渡したかが事故調査と再発防止に直結します。

顔認証やOCRが失敗した場合に備えて、目視確認や手動登録へ切り替えられる形にしておきます。

機械の判定だけで服薬の可否を決めない設計にする必要があります。

ポイント

対象業務と例外を先に切り分けておくと、機能を増やしすぎずに済みます。利用場所ごとに中心業務が違うため、同じ機能をそのまま当てはめない判断が要ります。

服薬管理システムの進め方と6つのフェーズ

全体は6つのフェーズに分かれ、要件整理、製品・開発会社の選定、設計・開発の順に進みます。その後、テスト、稼働、定着へと続きます。

フェーズに分けて進めると、抜け漏れを確認しやすくなります。

後工程で見つかった課題を前工程に戻して直す前提も、あらかじめ計画に入れておく必要があります。

1. 要件整理:対象業務と事故リスクの洗い出し

まず、施設形態、利用者数、拠点数、服薬回数を一覧にします。関係職種や既存システム、紙が残る工程も書き出します。

服薬準備から申し送りまでを現場で観察し、業務フローに落とし込みます。

  • 対象者:薬剤師、看護師、介護職、管理者、情報システム担当、患者や家族
  • 決めること:入力者、確定時点、異常時の通知先
  • 確認工程:準備、配薬、本人確認、服薬確認、変更、申し送り

要件定義には、利用者・患者登録、薬剤マスタ、用法用量を含めます。

服薬予定と、実施・拒否・飲み忘れの状態も要件に入れます。

臨時薬、持参薬、外泊といった場面も、要件の段階で押さえます。

薬剤変更、アレルギー、相互作用も対象に含めます。

家族や薬剤師への共有も要件に入れます。

監査ログ、権限、データ出力も欠かせません。

「服薬できなかった」を未入力でまとめると、後で理由ごとの分析ができません。

拒否、嘔吐、外出は分けて記録し、薬の未着、体調不良、入力忘れも区別します。分析と報告に役立つため、ここで分けておきます。

2. 選定:業務適合性と連携範囲の比較

方式には、既製SaaS・パッケージ、クラウド型の個別開発、オンプレミスがあります。ほかに、スクラッチ開発もあります。

  • SaaS:標準業務に合わせ、早期導入や法改正対応を重視
  • 個別開発:独自の配薬フローや深い外部連携を重視
  • ハイブリッド:既製品と個別機能を組み合わせる

個別開発を選ぶ場合は、開発費に加えて、保守、移行、障害対応の責任分界も確認します。

候補には、実際の業務シナリオを使って操作してもらいます。

たとえば、朝食前の定期薬、変更後の旧薬の中止、臨時薬の追加を試します。また、顔認証できない利用者の目視確認や、通信断の記録と復旧後の同期も試します。

電子カルテ、レセコン、電子薬歴との連携方式を確認します。介護記録や電子処方箋との連携も、あわせて見ておきます。

APIの有無、データ出力、契約終了時の返却形式は、同じ質問票で各社を比べます。

判断は、デモ画面の印象より、業務シナリオでの動きと連携の条件をもとに行います。

3. 設計・開発:画面より先のルールの確定

設計では、データの関係、利用者ごとの画面の役割、現場での操作性を先に決めます。

  • データ:利用者・患者、薬剤、処方、予定と実績、職員、拠点、通知、変更履歴を整理
  • 画面:管理者はマスタ・権限、現場職員は服薬、薬剤師・看護師は変更、家族・患者は共有を担当
  • 操作性:片手操作、文字の見やすさ、バーコードやカメラの使いやすさ、短時間入力を優先
  • AIの確認:AI-OCR、顔認証、音声入力、薬歴下書きの結果は、人の確認を経て登録
  • 代替手順:認識失敗、マスク・照明、印字揺れ、薬剤変更、拒否、通信障害への備え

AIの結果を人が確認してから登録する考え方は、Human-in-the-Loopと呼ばれます。

2025年には、三菱電機デジタルイノベーションが保険薬局向けのAIサービスを発表しました。

さらに、EMシステムズにも薬歴生成AIサポートオプションがあります。これらは業務を補助する位置付けで、AIが投薬判断を代替する前提で要件を書くと、責任範囲を誤るおそれがあります。

4. テスト:正常系と例外系を実データに近い形で確認

テストでは、画面の表示だけでなく、正常系と例外系を実際の業務に近い条件で確かめます。

  • 服薬業務:誤表示、誤配薬、変更前の薬の残存、重複登録、通知漏れ、権限外閲覧を確認
  • 服薬シナリオ:匿名化した移行前データで、朝・昼・夕・就寝前の定期薬、頓服、中止薬、臨時薬を試験
  • 障害対応:通信断、端末紛失、サーバー障害、復旧、連携遅延、通知重複を想定

合格基準は業務ルールで示します。たとえば、本人確認ができなければ服薬を確定しないことや、例外理由を必須にする設定が挙げられます。

監査ログから職員、時刻、操作をたどれるかも、基準に含めます。

稼働判定へ進む前に、責任者が結果と未解決課題を承認します。

5. 稼働:小規模な開始と切り戻し条件の決定

まずは、実際の端末や薬包、職員で使えるかを確かめます。

  • 展開範囲:全施設一斉ではなく、1施設・1工程・限られた利用者から開始
  • 参考事例:奉優会は「めでぃさぽ」を2025年3月に約2週間試用し、4月に3施設へ導入

公式事例では、薬包と利用者をタブレットで確認しながら、本人確認と介助記録を同時に行っています。

薬包と利用者の確認を一度に行う運用は、短期試用でどこを確かめるかを考える材料になります。

稼働初日は、紙をすぐにはやめず、対象と期間を限定して二重に確認します。そのうえで、紙をやめる時期と、障害時に使う代替帳票を決めておきます。ただし、二重入力を続けると現場の負担が増えます。

稼働前後では、誤薬件数、未服薬の把握率、確認時間を比べます。

記録漏れ、ダブルチェック回数、利用率も指標に入れます。

6. 定着:利用率と例外対応の改善

定着には、職員研修と、利用状況を踏まえた定期的な改善が必要です。

  • 研修:夜勤者、新任職員、応援職員に、服薬前後・未服薬時・薬剤変更時の手順書を用意
  • 定期確認:月1回など、問い合わせ、入力漏れ、アラート見逃し、未使用項目を確認

確認結果をもとに、設定や画面を改善していきます。

医療情報を扱う場合は、厚生労働省が2026年6月に公表した「医療情報システムの安全管理に関するガイドライン 第7.0版」を確認します。

アクセス制御、認証、監査ログは、契約と手順に反映します。バックアップ、委託先管理、インシデント対応は、契約と手順に入れます。事業継続計画もあわせて反映します。

機能を追加するときも、安全性と現場負担を見直します。

ポイント

進め方は要件整理から定着まで6つのフェーズで、後工程で見つかった課題は前工程に戻す前提で計画します。選定では、デモの印象より業務シナリオでの動きと連携の条件を重視します。

服薬管理システムの費用相場とコストの内訳

服薬管理システムの見積費用を、初期費用、運用費用、終了時費用の3区分で示した図。
導入時から契約終了時まで費用区分が続きます。

費用は、利用者数や拠点数に加えて、端末、移行、連携も含めた総保有コストで判断します。

AI・OCR、研修、保守も同じ枠で見ていきます。

公開されている価格が少ないため、ここに示す金額は契約額ではなく、2026年時点の予算レンジです。ITreviewの2026年の製品比較情報でも、規模や形態によって幅があると整理されています。

SaaS・既製品・スクラッチ別の予算の考え方

方式によって、初期費用や月額費用、開発期間の目安は異なります。次に示すレンジも、要件によって変わります。

  • SaaS:初期10万〜50万円、月額1万〜10万円程度
  • 既製品の設定・移行・連携:初期50万〜300万円程度
  • 専用MVP:300万〜800万円程度、3〜6か月
  • 中規模スクラッチ:800万〜2,000万円程度、6〜12か月
  • 大規模法人:2,000万〜5,000万円以上、12〜18か月以上

1施設・少人数のSaaSであれば、下限寄りになります。

一方で、複数拠点、多職種、大人数の場合は上限寄りになります。通知や帳票が多いことも、上限に近づく要因です。

専用MVPの小規模構成の金額は、介護施設向けの類似業務システムから推定したものです。

中規模の構成には、薬局・病院連携、電子処方箋、電子カルテが含まれます。レセコン、薬剤マスタ、相互作用チェックも加わります。さらに、複数拠点とモバイルも含まれます。

大規模構成では、高可用性、多数の既存システム連携、データ移行を想定します。加えて、24時間運用とBCPも想定します。

スクラッチ開発の金額は定価ではなく、要件をもとに置いた概算です。

見積書の初期費用と運用費用の内訳

費用の漏れを防ぐため、見積書では初期費用と運用費用を分けて確認します。

  • 初期費用:要件定義、環境・画面・権限設定、マスタ登録、移行、連携、テスト、端末、研修
  • 運用費用:利用料、通信、AI・OCR・顔認証、保守、法改正対応
  • 終了時費用:データ返却、移行支援、解約後の閲覧

運用の中には、問い合わせ、バックアップ、監査ログの保管も含まれます。

端末は1台あたり数万円〜十数万円程度を別に見込みます。台数と予備機の扱いも確認します。

連携では、電子カルテやレセコンの仕様調査、接続試験、エラー時の再送に工数がかかります。マスタのコード変換も工数に加わります。そのため、単純なCSV取込より費用が増える場合があります。

5年程度の利用を想定し、終了時にかかる費用も含めたTCO(総保有コスト)で比べます。

期間と効果の評価

期間と効果は、導入前に置いた条件や指標に照らして評価します。

  • 期間の目安:SaaS設定は数週間〜数か月、既製品連携・移行は数か月
  • 個別開発:専用MVPは3〜6か月、中規模スクラッチは6〜12か月
  • 効果指標:誤薬、未服薬把握率、確認時間、記録漏れ、二重確認回数、報告時間、職員利用率

法務・セキュリティ審査や端末調達が長引くことがあります。受入テストや電子カルテ側の調整も、期間を延ばす要因になります。こうした部分は、開発会社の作業だけでは短縮できません。

指標は月単位で追います。

システムだけで誤薬ゼロを保証することはできないため、安全対策と合わせて、リスクの発見や再発防止の速さを評価します。

ポイント

費用は、初期費用と運用費用、終了時費用を分けて見積書で比べます。金額は2026年時点の予算レンジで要件によって変わるため、同じ条件で複数社に見積もりを依頼します。

服薬管理システムの見積もりを取る際のポイント

見積もり依頼にまとめる施設・利用規模、既存環境、例外シナリオ、提出資料の4項目を示すチェックリスト。
4項目を揃えると各社の提案を比べやすくなります。

見積もりの精度は、発注側が渡す情報の具体性で変わります。そのため、業務フローや例外、既存システムの情報をそろえて、複数社に依頼します。セキュリティや運用体制も、あわせて伝えておきます。

条件をそろえておくと、連携や保守を含まない提案と、必要な作業を含む提案を見比べられます。

RFPに書く利用者数・業務フロー・例外

RFPや要件メモには、利用規模、既存環境、例外業務をまとめます。提案時に必要な資料も、あわせて書き添えます。

  • 施設・利用規模:施設形態、拠点、利用者・患者数、職員数、1日の服薬回数
  • 既存環境:端末数、利用場所、電子カルテ、レセコン、電子薬歴、介護記録、連携要件、移行期間
  • 例外シナリオ:直前の薬剤変更、頓服追加、拒否、家族報告、夜勤時の通信不安定
  • 提出資料:機能、画面、業務フロー、連携、体制、工程、費用、保守、SLA、セキュリティ、移行計画

提案では、標準機能、設定対応、追加開発を分けてもらいます。将来対応も別に示してもらうことで、契約後に別料金となる機能を見分けられます。

複数社の比較:価格に加えて体制とドメイン理解

候補は3社程度に絞り、同じRFP、デモシナリオ、質問票で比べます。価格以外では、次の体制も確認します。

  • 現場理解:医療・介護の導入実績と職種へのヒアリング体制
  • 担当体制:要件定義から保守までの担当者と障害時の窓口
  • 継続性:製品やサービスを継続できる見通し

製品提供会社と受託開発会社では、責任の範囲が異なります。そのため、個別開発やAPI連携の担当を明確にします。移行や運用支援も、担当の範囲を書き分けておきます。

2026年の選定では、電子処方箋との連携も確認します。厚生労働省によると、院内処方等情報の登録機能は2025年1月23日に始まりました。登録情報の参照や、その情報を含む重複投薬等チェックができます。

対応データ、本人同意、エラー時の扱いを見積書に反映します。連携先の更新費用も、見積書に含めて確認します。

契約前のセキュリティ・障害・終了時のリスク確認

契約前には、クラウドの安全対策、障害時の業務、サービス終了時のデータ対応を確認します。

  • 情報保護:暗号化、MFA、多要素認証、最小権限、拠点・職種別アクセス制御
  • 運用・復旧:操作ログと保管期間、バックアップ世代、復旧目標、委託先、保管場所
  • 障害対応:紙への切替、復旧後の再入力、認識誤りの警告、薬剤マスタ更新の承認
  • 終了時対応:データ返却形式、移行支援費用、契約終了後の閲覧期間

厚生労働省の「医療情報システムの安全管理に関するガイドライン 第7.0版」は、経営管理や企画管理、システム運用などの編で構成されています。

開発会社のチェックシートを見るだけでなく、自社の責任者と運用手順も確かめます。

障害時に服薬を続けるか、紙へ切り替えるかは、事前に決めておきます。

ポイント

見積もりは、発注側が要件をどこまで具体的に示せるかで比べやすさが変わります。利用規模と例外を揃えて依頼し、契約前には責任分界と障害時の扱いまで確かめておくと、後の食い違いを減らせます。

服薬管理システム開発でよくある質問

導入前に、自動化の範囲、例外の判断者、既存記録との連携を決めておくと、手戻りを抑えられます。

費用、期間、AIやクラウドについて回答します。

服薬管理システムの開発費はいくらですか?

導入方式によって費用は大きく変わるため、SaaSの標準利用から専用MVPまでの目安を、安い方式から順に示します。

  • SaaSの標準利用:初期10万〜50万円、月額1万〜10万円程度
  • 既製品の設定・移行・API連携:初期50万〜300万円程度
  • 専用MVP:300万〜800万円程度から検討

金額は、利用者数、拠点数、端末で変わります。外部連携やAI・OCRの有無も金額に響きます。研修と保守も含めて、要件を示した相見積もりで確定させます。

服薬管理システムの開発期間はどのくらいですか?

開発期間も方式によって差があるため、SaaS設定から中規模スクラッチまでの目安を、短い方式から順に示します。

  • SaaS設定:数週間〜数か月
  • 既製品の移行・連携:数か月
  • 専用MVP:3〜6か月
  • 中規模スクラッチ:6〜12か月

受入テストやセキュリティ審査、端末調達が期間を左右します。電子カルテやレセコン側の調整も、期間に響く要素です。

1施設・1工程の試用から始めると、本番を判断する際のリスクを抑えられます。

AI・顔認証・OCRを使えば服薬確認を自動化できますか?

AI・顔認証・OCRは、薬包の読み取りや本人確認を支援します。薬歴の下書きや入力漏れの発見にも役立ちます。ただし、確認なしで投薬判断を任せるものではありません。

想定するのは、認識失敗、薬剤変更、臨時薬です。顔認証を嫌がる利用者や、照明・マスク・通信障害も含みます。そのため、目視確認や手動登録を用意しておきます。

最終判断と登録は、業務上の責任を持つ職員や有資格者が行う運用が基本です。

医療・介護情報をクラウドで管理しても問題ありませんか?

可否は、クラウドかオンプレミスかの区分に加えて、次の項目で判断します。

  • 安全対策:アクセス制御、認証、暗号化の中身
  • 運用:監査ログ、バックアップ、委託先管理、障害時の復旧、契約終了時のデータ返却
  • 責任分界:自社の責任分界とベンダーの対策を照らし合わせる
  • 介護施設の要件:個人情報、職員権限、端末紛失時の対応

医療機関や薬局は、厚生労働省の安全管理ガイドライン第7.0版を参照します。

ポイント

AIや顔認証は確認を前提とした補助で、最終判断は職員や有資格者が行う運用が基本です。クラウドの可否は、アクセス制御や認証、暗号化の中身で判断します。

服薬管理システム開発の進め方・費用・見積ポイントまとめ

開発は、機能を先に選ぶのではなく、対象業務と事故リスク、現場の例外を整理するところから始めます。6フェーズごとに完了条件を置くと、手戻りを抑えられます。

費用の判断:開発費よりもTCOと効果

SaaSの月額に加え、初期設定、端末、連携も含めて比べます。移行、研修、保守もあわせて見ます。法改正への対応、障害対応、終了時の移行も含めます。

誤薬件数、未服薬の把握率、記録時間をKPIにします。記録漏れや利用率も加え、1施設・1工程のPoCで効果を確かめます。

相場は参考値として扱い、同じ要件で複数社へ見積もりを依頼します。特定の金額を決め打ちせず、比べることが大切です。

例外運用と定着支援まで含めた開発会社の選び方

開発会社は、平常時だけでなく例外運用や稼働後の支援まで対応できるかを確認します。

  • 例外対応:薬剤変更、臨時薬、拒否、外泊、認識失敗、通信障害、サービス終了
  • 支援体制:医療・介護の知識、既存連携、セキュリティ・移行の説明、研修・改善

まず服薬業務を観察して、事故リスクと指標を整理します。そのうえで、候補3社程度へ同じ条件のRFPを送ります。最後に、PoCで職員と利用者に試してもらいます。

▼全体ガイドの記事
・服薬管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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