服薬管理システム開発の発注/外注/依頼/委託方法について

服薬管理システムの発注・外注は、既製のSaaSを導入するか、既存システムと連携した個別開発を依頼するかを、対象業務と安全要件から決めることが重要です。費用だけでなく、誤薬・飲み忘れの防止、記録の正確性、現場の例外対応、契約終了時のデータ移行まで含めて比較すると、導入後に使われる仕組みを選びやすくなります。

本記事では、服薬管理システムを発注・外注するときの進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積書の比較方法まで順に解説します。介護施設、病院・診療所、調剤薬局では必要な機能と連携先が異なるため、自社の業務を整理してから候補企業へ同じ条件で相談する方法を紹介します。

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

服薬管理システムを発注する前に押さえる全体像

服薬管理システムは、薬を飲む時間を知らせるだけのアプリではありません。利用者・患者・薬剤・用法用量・服薬時刻を管理し、誰が、いつ、どの薬を、どのような結果で確認したかを残す業務基盤です。発注時は「服薬管理」という言葉をそのまま依頼せず、対象業務と責任範囲を分解して伝える必要があります。

介護施設では、薬包の取り違え防止、本人確認、服薬介助の実績記録、拒否や飲み忘れの申し送りが中心です。病院・診療所では、持参薬、処方、投与実績、変更・中止、アレルギーや重複投薬の確認に加えて、電子カルテやオーダリングとの連携が重要です。調剤薬局では、電子薬歴、服薬指導、服薬期間中のフォロー、処方箋送信、患者向けのお薬手帳などが主な対象になります。

この3領域を一つの要件に混ぜると、候補企業が想定する製品や見積条件がばらばらになります。発注書やRFPの冒頭に「利用場所」「主な利用者」「服薬確認の責任者」「連携する既存システム」を記載し、今回の第一目的を一つか二つに絞ると、比較しやすい提案が集まります。

発注理由を「AI-OCRを使いたい」「顔認証を導入したい」といった機能名だけで書くと、導入後の評価が難しくなります。「配薬前の本人確認を漏れなく記録する」「服薬確認にかかる時間を測定する」「未服薬を当日中に管理者と薬剤師へ共有する」のように、業務成果と測定方法まで決めます。KPIの候補は、誤薬件数、記録漏れ件数、服薬確認1回あたりの時間、未服薬の把握率、申し送りに要する時間、現場の利用率です。

三菱電機デジタルイノベーションの「めでぃさぽ」は、介護施設の服薬介助で顔認証による本人確認と服薬記録を組み合わせる製品です。公式情報では、誤薬防止だけでなく、職員の精神的負担の軽減や正確な記録を導入目的として示しています。自社のRFPでも、機能の有無だけでなく、どのリスクと負担を下げるための機能かを書き分けると、提案内容を評価しやすくなります（出典: 三菱電機デジタルイノベーション「服薬介助支援ツール めでぃさぽ」、2026年確認）。

服薬管理システムの発注形態はどれを選ぶ？

発注形態は、SaaS・パッケージの導入、既製品への設定や連携追加、クラウド個別開発、オンプレミス、スクラッチ開発の順に自由度と責任範囲が大きくなります。最適解は会社の規模ではなく、業務を標準機能に合わせられるか、既存システムとどの深さで連携するか、個人情報をどう管理するかで決まります。

SaaSやパッケージは、短期間で始めやすく、法改正や機能更新を提供会社に任せやすい発注形態です。介護施設の服薬介助記録や、薬局の電子薬歴のように、業界で共通する業務が中心なら、個別開発よりも導入費と期間を抑えられる可能性があります。複数拠点へ展開する場合も、アカウントや権限を追加しやすい点がメリットです。

ただし、標準機能にない臨時薬、外泊、拒否、通信障害などを現場の工夫で補うことになると、導入後の負担が増えます。デモでは平常時の操作だけでなく、薬剤変更や中止、誤認識、端末紛失、担当者不在を再現し、操作回数と代替手順を確認します。契約終了時のデータ出力形式、保存期間、移行支援の有無も必ず確認します。

電子カルテ、レセコン、電子薬歴、介護記録、家族向けアプリなど複数のシステムをつなぐ場合や、独自の配薬フローを変えられない場合は、クラウド個別開発やスクラッチ開発が候補です。利用者・薬剤・服薬実績のマスタを共通化し、二重入力を減らせる一方で、要件定義、テスト、セキュリティ、保守の責任を発注者と開発会社で分担する必要があります。

最初から全拠点・全機能を作るのではなく、1施設または1業務を対象にMVPやPoCを実施する方法が安全です。介護施設なら「配薬前の本人確認から服薬結果の記録まで」、薬局なら「処方受付から服薬フォローの記録まで」のように範囲を絞り、誤薬防止や記録時間、利用率を測ります。結果を見て次の連携やAI機能を追加する段階導入にすると、要件の作り込み過ぎを防げます。

RFPと要件整理はどこまで準備して発注する？

RFPは、開発会社へ「何を、なぜ、いつまでに、どの条件で実現したいか」を同じ基準で伝える文書です。画面の細部を発注者だけで決め切る必要はありませんが、業務範囲、利用者、データ、連携、セキュリティ、費用の前提、提案してほしい事項は揃える必要があります。曖昧なまま相見積もりを取ると、安い会社が要件を含めていないだけという比較ミスが起きます。

要件整理は、機能一覧から始めるより、現場の一日の流れから始めると具体化しやすくなります。薬の受け取り・保管、服薬準備、配薬、本人確認、服薬確認、未服薬や拒否の報告、薬剤変更、申し送り、家族や薬剤師への共有を順番に記録します。各工程で「誰が」「どの端末で」「何を確認し」「失敗したら誰へ通知し」「後から何を監査できるか」を書きます。

特に、定時薬だけでなく頓服、臨時薬、持参薬、休薬、変更後の旧薬、外泊、入退院、利用者の服薬拒否を洗い出します。顔認証や薬包OCRを使う場合も、マスクや照明、薬包の汚れ、薬剤変更、読み取り失敗の代替手段を要件に含めます。正常系だけを仕様書に書くと、現場が最も困る場面で紙や口頭に戻ってしまいます。

RFPには、患者・利用者情報、薬剤情報、服薬実績、アレルギー、変更履歴、監査ログをどのシステムから受け取り、どこへ返すかを記載します。API、CSV、ファイル連携など方式の指定が難しい場合は、開発会社に方式・頻度・エラー時の再送・二重登録防止を提案させます。連携先の仕様書やテスト環境を発注者が用意できるかも、見積条件に影響します。

医療機関や薬局が外部サービスを利用する場合は、アクセス権、MFA、通信・保存時の暗号化、監査ログ、バックアップ、障害復旧、委託先管理、インシデント報告、契約終了時のデータ返却を確認します。厚生労働省は2026年6月に「医療情報システムの安全管理に関するガイドライン」第7.0版を公表し、概説編、経営管理編、企画管理編、システム運用編、保守委託機関編を示しています。RFPでは「ガイドラインを参照した対応方針と、発注者・受託者の役割分担を提案してください」と依頼すると、確認漏れを減らせます（出典: 厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」、2026年6月）。

契約形態と開発プロセスはどう決める？

服薬管理システムでは、業務理解や連携仕様が途中で変わりやすいため、要件の確定度に応じて契約を分ける方法が現実的です。企画・現状分析は準委任、仕様が固まった機能の実装は請負、運用改善は月額の保守・準委任という組み合わせが考えられます。契約名だけで判断せず、成果物、検収、変更手続き、責任範囲を文書にします。

準委任契約は、専門家が調査・設計・開発支援を行うことに対して、作業時間や役務の提供を管理しやすい契約です。要件が固まっていない初期フェーズや、発注者と受託者が一緒に現場検証するPoCで使いやすい一方、完成責任や成果物の扱いを別途明確にします。請負契約は、合意した仕様のシステムを完成させ、検収を受ける関係を作りやすい契約です。仕様変更や追加連携が発生したときの追加費用・納期の決め方を条項に入れます。

保守契約では、障害受付の時間帯、一次回答と復旧の目標、法改正対応、薬剤マスタ更新、脆弱性対応、バックアップ確認、問い合わせ範囲を確認します。クラウドサービスなら、月額利用料にどこまで含まれるか、データ容量や拠点追加の料金、解約時のデータ出力費用も見ます。医療情報を扱うため、再委託先の開示、秘密保持、事故発生時の報告期限も発注前に確認します。

進行は、現状調査、要件定義、基本設計、画面・データ・連携設計、開発、単体・結合・運用テスト、現場受入テスト、研修、試行運用、本稼働という流れに分けます。各段階で成果物と意思決定者を置き、受入条件を明確にします。例えば、服薬実績が本人・薬剤・時刻・担当者と紐づき、変更履歴と監査ログを確認できることを受入条件にします。

テストでは、通常の定時薬だけでなく、薬剤変更の直後、服薬拒否、飲み忘れ、臨時薬、通信断、端末交換、権限のない職員による閲覧、連携データの重複を確認します。現場受入テストには、管理者だけでなく、夜勤者、看護師、介護職、薬剤師など実際に操作する人を参加させます。研修を一度の説明会で終わらせず、短い手順書と問い合わせ窓口を用意すると定着しやすくなります。

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

服薬管理システムの費用は、利用者数、拠点数、端末、データ移行、既存システム連携、AI・OCR・顔認証、セキュリティ要件、保守体制で大きく変わります。以下は2026年時点の公開比較情報と、類似する医療・介護業務システムの開発規模から予算を置くための目安です。製品ごとの正式な価格表ではないため、RFPでは同じ前提を渡して見積を取得します。

既製品をそのまま利用する場合は、初期費用10万〜50万円、月額1万〜10万円程度を予算の起点にできます。1施設・少人数の服薬介助なら下限寄り、複数拠点・多職種・大人数の利用なら上限寄りになります。公開比較情報では、クラウド型を1ユーザーあたり月額1,000〜5,000円前後、小規模から大規模まで月額数万円から10万円以上、オンプレミス型を初期30万〜300万円以上と整理する例もありますが、サービスごとの課金単位が異なるため単純比較はできません（出典: ITreview「服薬管理システムのおすすめ製品」、2026年確認）。

既製品に設定、データ移行、帳票変更、API連携を加える場合は、初期50万〜300万円程度が一つの目安です。利用者・患者の既存データを整形する作業や、電子カルテ、レセコン、電子薬歴、介護記録との接続が増えるほど、導入支援とテストの工数が増えます。見積書では、アカウント費用だけでなく、初期設定、端末設定、マスタ登録、移行、研修、連携、現地支援を項目別に確認します。

介護施設向けに利用者・薬包・服薬実績・権限・監査ログを中心に作る小規模な専用MVPは、類似業務システムの規模から300万〜800万円程度、期間は3〜6か月程度を初期検討の目安にできます。薬局・病院連携、電子処方箋、薬剤マスタ、相互作用チェック、複数拠点、モバイル、管理者画面まで含む中規模開発では、800万〜2,000万円程度、6〜12か月程度が目安になります。

大規模な医療機関や法人グループで、高可用性、既存システムとの多数の連携、全拠点のデータ移行、24時間運用、監査・BCPを含める場合は、2,000万〜5,000万円以上、12〜18か月以上になる可能性があります。これらは服薬管理システム固有の公開見積ではなく、機能数・連携数・品質要件に基づく推定レンジです。端末1台あたり数万円〜十数万円、クラウド利用料、外部OCR・顔認証サービス、保守、法改正対応、研修も別枠で見積もる必要があります。

AIやOCRを導入しても、人が確認して登録する工程を残します。AIの認識結果を無確認で服薬指示や薬歴として確定する設計は避け、誤認識時の修正履歴と承認者を記録します。AI利用料だけでなく、確認作業、教育、精度検証、モデル更新、障害時の手作業を含めた総保有コストで比較すると、過度に安い見積の見落としを防げます。

委託先選定と見積比較で確認すべきポイント

委託先は、医療・介護の業務知識、連携経験、現場定着の支援力、セキュリティと保守体制を総合して選びます。知名度や提示価格だけでは、薬剤変更や未服薬などの実務を扱えるか判断できません。候補を3社程度に絞り、同じRFP、同じデータ項目、同じ導入希望日を渡して、提案書と見積書を横並びにします。

実績を確認するときは、「医療機関向けの実績があります」という説明だけで終わらせず、どの業態で、何拠点、何人が使い、どの範囲を担当したかを質問します。要件定義だけか、開発・連携・データ移行・研修・保守まで含むかで、発注後の責任分界が変わるためです。可能であれば、現場画面のデモ、導入後のサポート事例、障害時の連絡フローを確認します。

薬局向けなら電子薬歴やレセコンとの連携、病院向けなら電子カルテや電子処方箋、介護施設向けなら介護記録やタブレット運用の経験を見ます。電子処方箋は、複数の医療機関・薬局の処方や調剤情報を参照し、重複投薬等をチェックする基盤であり、2025年1月23日から院内処方等情報の登録機能も開始されています。連携を将来計画に含めるなら、現時点の接続だけでなく、仕様変更への追随方法を提案できる会社が候補になります（出典: 厚生労働省「電子処方箋」、2026年確認）。

見積比較では、合計金額の安い順に並べるのではなく、要件定義、設計、開発、連携、テスト、移行、研修、保守を同じ分類にそろえます。特に「別途見積」と書かれた項目は、端末、薬剤マスタ登録、API仕様調査、現地立会い、追加アカウント、データ修正、法改正対応、障害対応の時間外費用などを具体化します。安い見積が、重要な作業を除外しているだけではないかを確認します。

提案書では、納期の根拠、発注者側の作業、必要なデータ提供、連携先の協力、受入テストの回数、導入後の問い合わせ窓口を確認します。見積の不確実性が高い場合は、いきなり本開発を契約せず、現状分析と要件定義を先行契約に分けます。成果物として業務フロー、画面一覧、データ項目、連携一覧、非機能要件、概算見積の前提を残せば、後続の発注判断にも使えます。

選定時には、障害時に紙へ切り替える手順、通信が戻った後の再入力、端末故障、ID共有の禁止、退職者の権限削除、バックアップからの復旧、誤登録の訂正履歴を確認します。顔認証やOCRは便利ですが、利用者が認証を拒否した場合、薬包が読めない場合、AIの候補が誤っている場合に、人が安全に判断できる導線を作る必要があります。自動化の範囲と人の承認範囲を契約書・仕様書に残します。

また、サービスの提供会社が変わる可能性も考えます。2026年には、harmoおくすり手帳が2026年9月30日に終了し、株式会社ファルモの「eお薬手帳3.0」へ移行する案内が出ています。このような事例は、製品の優劣だけでなく、サービス継続性、運営主体、データ移行の方法と費用を発注前に確認する重要性を示しています（出典: harmoサポート「サービス終了・移行案内」、2026年確認）。

よくある質問（FAQ）

服薬管理システムを発注するときに寄せられやすい質問を、契約前に確認したい観点から回答します。製品や開発会社によって条件が変わるため、回答をそのまま要件にするのではなく、自社の業務フローと照らし合わせてRFPへ反映します。

SaaSをそのまま使う場合は初期10万〜50万円、月額1万〜10万円程度、既製品に設定・移行・連携を加える場合は初期50万〜300万円程度が予算の起点になります。個別開発は、介護施設向けの小規模MVPで300万〜800万円程度、複数システム連携を含む中規模開発で800万〜2,000万円程度という推定レンジがあります。いずれも利用者数、拠点数、端末、連携、保守で変わるため、公開価格や類似開発の目安として扱い、同じRFPで正式見積を取ります。

標準化できる業務を早く始めたい場合はSaaSやパッケージ、独自の配薬フローや深い連携を優先する場合は個別開発が向いています。最初から一方に決めず、標準機能で満たせる範囲、追加開発が必要な範囲、代替運用が許容できない範囲を分けて比較すると判断しやすくなります。1施設・1業務のPoCで利用率と安全性を確かめてから段階展開する方法も有効です。

正式なRFPがなくても相談できますが、候補会社を同じ基準で比較するなら簡易版でも作ることをおすすめします。施設形態、利用者数、拠点数、対象業務、必要な機能、連携先、セキュリティ要件、導入希望時期、予算の考え方、見積に含めてほしい作業を1〜3ページに整理すると、初回提案の精度が上がります。業務フローや帳票のサンプルを添付すると、認識違いも減らせます。

クラウドかオンプレミスかだけで安全性は決まりません。アクセス権、MFA、暗号化、ログ、バックアップ、復旧、委託先と再委託先の管理、インシデント対応、契約終了時のデータ返却を、発注者と受託者の責任分担として確認します。医療機関や薬局では、厚生労働省の医療情報システム安全管理ガイドライン第7.0版を参照し、自社の運用規程や委託契約へ落とし込むことが重要です。

まとめ

服薬管理システムを発注・外注するときは、最初に介護施設、病院・診療所、調剤薬局のどの業務を対象にするかを決めます。そのうえで、現場の服薬フロー、例外運用、既存システム連携、セキュリティとデータ移行をRFPに整理し、SaaS・パッケージ・個別開発を同じ条件で比較します。

費用は、SaaSの初期10万〜50万円・月額1万〜10万円程度、既製品への設定・連携を含めた初期50万〜300万円程度、個別開発の300万〜5,000万円以上という幅で考えられます。ただし、これらは公開相場と類似システムから予算を置くためのレンジです。端末、移行、研修、保守、法改正、障害対応、終了時の移行まで含めたTCOを見積もり、価格だけで委託先を決めないことが大切です。

候補企業には、正常時のデモだけでなく、薬剤変更、臨時薬、拒否、通信障害、認識失敗、権限変更を確認します。まず1施設・1工程で試行し、誤薬件数、記録時間、未服薬の把握率、利用率を測定してから展開すると、現場に定着する服薬管理システムへ近づけられます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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