調剤薬局システム開発の発注/外注/依頼/委託方法について

調剤薬局システムの発注・外注は、単にレセコンを購入する手続きではなく、受付から調剤、薬歴、会計、請求、在庫、在宅対応までの業務をどこまで標準化し、どの会社にどの責任範囲で委託するかを決めるプロジェクトです。

本記事では、1店舗の個人薬局から複数店舗のチェーン本部までを想定し、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積書の比較、導入後の運用までを順番に解説します。価格だけでなく、5年間の総保有コストと薬剤師が患者対応に戻れる時間を基準に判断できるようにします。

▼全体ガイドの記事
・調剤薬局システム開発の完全ガイド

調剤薬局システムの発注・外注は何から始めますか？

結論から言うと、最初に決めるべきことは製品名ではなく、解決したい業務上の課題と、システムに任せる範囲です。現行業務を見える化しないまま製品比較を始めると、デモで見栄えのよい機能に引っ張られ、実際の繁忙時間帯や在宅訪問で使えないシステムを選ぶ可能性があります。

受付、処方入力、監査、調剤、薬歴、服薬指導、会計、レセプト請求、在庫発注、患者フォローの順に、誰がどの端末で何を入力しているかを記録します。たとえば、処方箋の二次元コードを読み取った後に薬剤師が手入力している項目、監査時に紙と画面を見比べている項目、在庫の発注点を経験だけで決めている項目は、発注時に改善効果を測りやすい部分です。

課題は「薬歴入力を短くしたい」のような希望だけでなく、「ピーク時間帯に1処方あたり何分かかるか」「薬歴の確認・修正を誰が行うか」「在庫確認のために何度バックヤードへ移動するか」といった測定可能な表現にします。導入前の時間と導入後の目標を記録しておくと、費用対効果とベンダーの提案内容を比較しやすくなります。

1店舗の薬局では、レセコンと電子薬歴を一体型で導入し、教育と保守の窓口を一本化すると運用しやすい傾向があります。数店舗の地域チェーンでは、店舗ごとの処方箋枚数、在庫、売上、加算、スタッフ権限を本部で確認できることが重要です。数十店舗以上の本部やM&Aを進める会社では、店舗統合、マスター統一、卸や会計システムとの連携、データ分析まで含めて考える必要があります。

在宅対応が多い薬局は、訪問先での参照・入力、通信が不安定な場合の一時保存、帰局後の同期を確認します。電子処方箋、オンライン資格確認、マイナンバーカード、HPKI、リフィル処方箋への対応は、今すぐ使わない機能でも将来の改修費に影響するため、標準機能なのか追加開発なのかを発注前に区別します。

発注形態はパッケージ・クラウド・スクラッチのどれが適していますか？

発注形態は、標準パッケージ、一体型またはクラウド型、複数製品の連携、スクラッチ開発の順に、独自性と責任範囲が大きくなります。多くの薬局では、請求や薬価マスターのように制度改定の影響が大きい領域は実績のある製品を使い、店舗独自の分析や患者フォローだけを追加開発する段階的な構成が現実的です。

標準パッケージは、調剤報酬、薬価、レセプト請求、薬歴、処方箋入力など、薬局に共通する業務を早く整えたい場合に向いています。レセコンと電子薬歴を同じベンダーから発注する一体型は、患者情報や処方内容の連携に関する責任分界が分かりやすく、問い合わせ先もまとめやすい点が利点です。

一方で、独自の在庫評価や本部分析を標準機能に無理に合わせると、現場がExcelへ戻ることがあります。デモでは主要機能の有無だけでなく、薬局固有の例外処理を標準設定で吸収できるか、追加開発するときの費用と納期、ベンダーの法改正対応の範囲を確認します。

クラウド型は、複数店舗の情報を本部で確認したい場合や、タブレットを使って在宅訪問したい場合に適しています。サーバー機器の保有や更新作業を抑えやすく、初期費用を月額へ平準化しやすい一方、通信回線に依存するため、通信断時に受付・調剤・薬歴・会計をどこまで継続できるかが重要です。

契約前には、データの保管場所、バックアップ頻度、障害時の復旧目標、解約時のデータ返却形式、店舗追加時の課金単位を確認します。厚生労働省が2026年6月に公開した医療情報システムの安全管理に関するガイドライン第7.0版と関連チェックリストも参照し、クラウドだから安全と決めつけず、発注者と委託先の対策を分けて要件化します（出典: 厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」、2026年）。

レセコン、電子薬歴、在庫、監査機器、POS、患者アプリを別々の得意な製品でそろえる方法は、機能を選びやすい反面、連携試験と障害時の責任分界が複雑になります。PDFやCSVの受け渡しだけでなく、どの項目をどの形式で、どのタイミングに同期するかを確認します。レセコンと電子薬歴の連携では、厚生労働省が公開するデータ連携資料とJAHIS仕様、薬局向けのNSIPSなど、標準に沿った方式を優先します（出典: 厚生労働省「レセコンと電子薬歴システム間で連携するデータについて」、2025年）。

スクラッチ開発は、複数店舗の統合、特殊な卸連携、M&A後のマスター統合、独自の在庫最適化など、標準製品では事業上の差別化を実現できない場合に検討します。ただし、レセプト、薬価、薬歴、監査、電子署名、法改正対応をゼロから作ると、機能開発だけでなく試験と保守の負担も発注者側に積み上がります。最初から全面的に作り込まず、標準製品とAPI連携で代替できない範囲を先に証明します。

RFPと要件整理はどのように進めますか？

RFPは、ベンダーに希望を伝える資料ではなく、同じ条件で提案と見積もりを比較するための発注仕様書です。業務フロー、対象店舗、処方箋枚数、既存システム、移行データ、必須機能、非機能要件、納期、予算の考え方、提案依頼の回答形式をそろえると、会社ごとの見積もりの違いを説明しやすくなります。

業務要件には、受付から投薬までの流れ、薬剤師・事務員・本部担当者の役割、在宅訪問、疑義照会、分割調剤、リフィル処方箋、オンライン服薬指導、店舗間融通などを記載します。そのうえで、患者・保険資格情報、処方入力、二次元コード読取、重複投薬・併用禁忌チェック、薬歴、会計、レセプト、在庫、分析、電子処方箋を「必須」「できれば必要」「将来検討」に分けます。

AI薬歴や処方箋読取を入れる場合は、機能名だけを書かないことが大切です。AIが下書きを生成するまでの時間、参照するデータ、薬剤師が確認・修正して確定する画面、誤記録を防ぐ警告、生成履歴の保存を要件にします。AIの自動生成をそのまま薬歴として確定できる仕様は避け、最終責任を担う薬剤師の確認を必須にします。

薬剤服用歴や保険資格情報を扱うため、権限管理、職種ごとの閲覧範囲、MFA、通信・保存時の暗号化、操作ログと閲覧ログ、バックアップ、脆弱性対応、委託先の再委託管理をRFPに含めます。厚生労働省の安全管理ガイドラインは改訂されるため、RFPには「契約締結時および稼働中の最新版に適合すること」と記載し、適合方法と証跡の提出者を決めます。

電子処方箋では、直近の処方・調剤情報の参照や重複投薬等のチェックに加え、調剤結果の登録、HPKIによる電子署名、タイムスタンプ、紙運用へ切り替えた場合の後追い登録も確認します。厚生労働省資料では、2025年2月23日時点で電子処方箋を運用する薬局は41,030施設、オンライン資格確認導入施設を母数とした導入率は67.9％でした（出典: 厚生労働省「第4回電子処方箋推進会議 資料1」、2025年）。2026年5月時点では厚労省が薬局の9割以上への導入を公表しているため、未対応の製品を選ぶと短期間で追加投資が発生しやすくなります。

提案を受けるときは、ベンダーに同じ業務シナリオを実演してもらいます。処方箋の二次元コードを読み取り、患者情報を確認し、疑義照会を記録し、監査を経て薬歴を確定し、会計とレセプトへつなげる一連の操作を、通常処方だけでなく、分割・リフィル、在宅、疑義照会、薬剤変更、通信断のケースでも確認します。

受入基準は「導入できた」ではなく、「指定した業務を指定時間内に完了でき、誤操作時に戻せ、ログが残り、担当者が説明できる」と書きます。1店舗または代表的な1業務でPoCを実施し、処方箋枚数、入力時間、薬歴の確認時間、在庫発注に要する時間を測定すると、導入効果を感覚ではなく数字で判断できます。

契約形態は請負と準委任をどう使い分けますか？

契約形態は、成果物と完成条件を明確にできる工程は請負、要件を一緒に探索する工程や専門人材の支援は準委任とする組み合わせが使いやすいです。契約名だけで判断せず、要件定義、設定、追加開発、データ移行、試験、教育、保守を工程ごとに分け、成果物・責任・検収の条件を明記します。

準委任契約は、発注者と受託者が協力して業務整理、要件定義、製品選定、現場ヒアリング、移行計画を進める場合に適しています。まだ業務の優先順位が定まっていない段階で、完成物と固定価格だけを先に約束すると、後から変更要求が増え、見積もりと納期の調整が難しくなります。

ただし、準委任だから成果が不要になるわけではありません。月次の作業報告、決定事項一覧、課題管理表、要件定義書、次工程への移行条件を成果物として設定し、稼働時間だけでなく、どの判断をいつまでに行うかを合意します。

請負契約は、追加画面、API連携、帳票、データ移行ツールなど、作るものと完成条件を確定できる工程に向いています。検収では、画面が存在することではなく、RFPに記載した業務シナリオを処方箋の種類別に実行できること、異常時のエラー表示とログが確認できること、マスタ更新後の請求結果が期待値と一致することを条件にします。

制度改定や外部サービスの仕様変更で要件が変わる可能性がある部分は、変更管理の方法を契約に入れます。変更依頼の起票者、影響範囲、再見積もり、承認者、納期変更のルールを決めておくと、口頭依頼が積み重なって予算超過するリスクを抑えられます。

契約書と別紙の仕様書には、薬局データの所有権、バックアップ、復旧、再委託、インシデント発生時の連絡期限、個人情報の取扱い、監査ログの保存期間、法改正対応の費用負担を記載します。レセコンと電子薬歴を別会社に委託する場合は、どちらが患者情報の正本を持ち、どの会社が連携不具合を切り分けるかを明確にします。

解約やベンダー変更の条件も、導入前に確認します。患者・処方・薬歴・在庫・請求のデータを、機械判読できる形式で、いつ、いくらで、どの範囲まで返却するかを定めます。返却データを別システムへ移行できるか、サンプルデータで確認してから契約すると、将来の乗り換えコストを見積もりやすくなります。

調剤薬局システムの費用相場はいくらですか？

調剤薬局システムの費用は、店舗数、処方箋枚数、レセコンと電子薬歴の構成、端末・周辺機器、電子処方箋、データ移行、教育、保守の範囲で大きく変わります。公開情報から計画用の目安を置くなら、標準導入は初期50万〜200万円、月額3万〜8万円、クラウド型は初期10万〜50万円、月額5万〜15万円程度のレンジです。ただし、これは相場の目安であり、見積書に含まれる範囲を確認する前提です。

標準パッケージでは、ソフトウェア、初期設定、端末、バーコードリーダー、処方箋スキャナ、薬袋・帳票の印刷機器、設置、データ移行、操作研修、保守を分けて確認します。モイネットシステムの公式価格ページでは、電子薬歴一体型レセコン「Pharmy Connect」の税抜83万円という価格例が示されていますが、通信回線、端末、設置、訪問支援、店舗追加まで含む総額とは限りません（出典: 株式会社モイネットシステム「Pharmy」公式価格ページ、確認時点）。

月額には、利用料、保守、法改正・薬価改定対応、クラウド基盤、バックアップ、サポート窓口が含まれる場合があります。月額が安く見えても、改定対応や問い合わせが従量課金の場合は総額が変わるため、初期費用だけでなく、5年間の利用料と一時費用を同じ条件で比較します。

複数店舗の本部管理、店舗間在庫、患者アプリ、卸連携、経営BIなどを追加する中規模カスタマイズは、計画段階では500万〜1,500万円程度を仮置きし、要件定義後に再見積もりする考え方が現実的です。本部機能と複数の外部連携まで含める場合は1,500万〜5,000万円以上、レセプトや薬歴などの基盤をゼロから開発するスクラッチでは5,000万円を超える可能性もあります。

これらは医療・業務システムの類似案件と公開相場をもとにした計画用のレンジで、公的に統一された価格表ではありません。開発費だけでなく、要件定義、UI設計、連携開発、データ移行、テスト、教育、並行稼働、セキュリティ診断、法改正時の保守までを工程別に見積もり、各項目の前提を明記してもらいます。

5年TCOは、初期費用に60か月分の月額、端末・周辺機器の更新、追加店舗、データ移行、教育、保守、法改正対応、連携利用料を加え、補助金がある場合は適用条件を分けて計算します。たとえば標準導入の初期費用が50万〜200万円、月額が3万〜8万円なら、ソフトウェア関連だけの5年間はおおよそ230万〜680万円となりますが、機器や移行費を含めれば変わります。

費用対効果は、削減できる入力時間だけで判断しません。薬歴の確認品質、在庫切れや過剰在庫の抑制、請求ミスの減少、教育期間、患者への説明時間、障害復旧までの損失も含めます。薬剤師の時間を患者対応へ戻すことが目的なら、導入前後の処方箋処理時間と残業時間を測定する指標を契約や運用計画に入れます。

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

委託先は、知名度や価格だけでなく、調剤業務への理解、同規模薬局での導入経験、データ移行、法改正対応、導入後の支援体制を総合的に評価します。製品を提供するベンダーと、独自開発を請け負う会社では得意分野が異なるため、RFPの課題に対してどの形態を提案しているかを見ます。

実績は「薬局に何社導入したか」だけでなく、自社に近い処方箋枚数、店舗数、在宅比率、既存機器、レセコンと薬歴の構成を確認します。個人薬局なら現場での操作教育と問い合わせ対応、チェーンなら本部マスターと店舗権限、在宅中心なら訪問先入力と通信断、M&Aを予定する会社ならデータ統合の事例を聞きます。

候補先には、導入後に現場で起きた障害と、その解決方法も質問します。成功事例だけでなく、移行が遅れた理由、旧システムとの併用期間、現場教育に必要だった時間、追加費用が発生した条件まで説明できる会社は、提案の前提を開示する姿勢があると判断しやすくなります。

見積比較では、ソフトウェア、ライセンス、クラウド利用料、端末、周辺機器、初期設定、追加開発、API、移行、教育、保守、法改正対応、現地訪問、店舗追加を同じ項目に並べます。A社の見積もりが安く見えても、B社では標準に含まれる移行や研修が別料金になっていることがあります。含む・含まない・条件付きの3区分で確認し、合計金額だけを比べないようにします。

見積もりの数量も重要です。対象店舗数、端末数、月間処方箋枚数、患者データ件数、薬歴の移行年数、外部連携数、教育回数、稼働立会い日数を記載します。単価だけでなく、数量が増えたときの追加単価と上限、キャンセル時の精算、納期が延びた場合の費用をあらかじめ確認します。

薬局は営業時間中にシステムを止めにくいため、問い合わせ窓口の時間、一次回答の目標、重大障害のエスカレーション、遠隔対応と訪問対応の条件、代替機の有無を確認します。調剤報酬や薬価の改定、電子処方箋の仕様変更、OS更新への対応費用が月額に含まれるか、別途契約になるかも比較項目です。

選定時には、機能点、費用点、導入期間、セキュリティ、操作性、支援体制を重み付けして評価します。価格を最優先にすると、移行や教育が不十分で現場が旧運用へ戻るリスクがあります。逆に高機能でも使われなければ投資効果は出ないため、代表薬剤師、事務担当、本部、情報システム担当がそれぞれ評価し、合意理由を記録します。

発注後の導入・移行・運用定着で失敗を防ぐには？

発注後は、要件定義、設定・開発、データ移行、テスト、教育、並行稼働、本番切り替え、安定稼働の順に進めます。標準パッケージは1〜3か月、データ移行や複数店舗展開を含む場合は3〜6か月、中規模カスタムは6〜12か月を計画上の目安とし、試験と教育の期間を削らないようにします。

移行対象は、患者基本情報、保険資格、処方・調剤履歴、薬歴、アレルギー・副作用、在庫、仕入先、薬品マスター、請求に関する情報に分けます。何年分を移すか、旧システムで欠損や表記揺れをどう扱うか、移行後に誰が照合するかを決め、サンプル移行と本番前のリハーサルを実施します。

データ移行費が安い場合でも、発注者が抽出・整形・照合を担う条件になっていることがあります。旧ベンダーから受け取れるデータ形式、返却費用、移行できない項目、履歴をPDFで保管する場合の検索性を確認します。薬歴のように業務継続と説明責任に関わるデータは、移行後の閲覧と訂正履歴まで試験します。

研修は管理者向け説明会だけで終わらせず、受付担当、薬剤師、在宅担当、本部担当ごとに実際の役割で行います。操作マニュアルには通常処方だけでなく、処方箋の読み取り失敗、患者情報の重複、疑義照会、分割・リフィル、在庫不足、返戻、通信断を含めます。現場でよく使う操作を短い手順書にし、質問の回答を蓄積します。

複数店舗へ一度に展開するより、代表店舗で先行導入し、業務フローとマスターを調整してから段階展開する方がリスクを抑えやすくなります。先行店舗では、処方箋処理時間、薬歴確定までの時間、エラー件数、問い合わせ件数、在庫発注の所要時間を測定し、次店舗へ展開する条件を決めます。

システム障害や通信断が起きたとき、受付を止めるのか、紙で処方情報と調剤結果を記録して後から登録するのかを、薬局の業務継続計画に落とし込みます。紙の様式、記入者、薬剤師の確認、患者への説明、復旧後の二重入力防止、調剤結果の登録、ログの残し方を決めておくと、緊急時に判断がぶれません。

発注者は、ベンダーのバックアップがあることだけで安心せず、復旧目標時間と復旧時点、連絡先、代替端末、データの整合性確認まで実地訓練します。厚労省のガイドラインとサイバーセキュリティ対策チェックリストに沿って、権限の棚卸し、MFA、端末更新、脆弱性情報の確認、ログ監視、委託先への監査も定期的に行います。

調剤薬局システムの発注・外注でよくある質問

調剤薬局システムの発注では、費用だけでなく、既存データ、電子処方箋、現場の操作性、保守の責任範囲について質問が集まります。ここでは、発注前に特に確認しておきたい質問へ直接回答します。

費用を抑えるには、標準機能で対応できる業務と追加開発する業務を分け、不要なカスタマイズを減らすことが基本です。複数社へ同じRFPを渡し、初期費用だけでなく5年TCO、データ移行、教育、法改正対応、店舗追加を含む条件で比較します。補助金が使える場合は、対象機能、申請期限、導入期限、実績報告の条件を確認したうえで計算します。

移行できる範囲は、旧ベンダーが提供する出力形式、契約条件、移行先の取込仕様によって異なります。患者基本情報や処方履歴を移せても、薬歴の全履歴、添付ファイル、訂正履歴、在庫ロットまで完全に移せるとは限りません。発注前にサンプルデータで移行テストを実施し、移行できないデータを検索可能な形式で保管する方法まで決めます。

データの保管場所、暗号化、権限管理、MFA、バックアップ、復旧目標、障害連絡、解約時のデータ返却形式を確認します。加えて、通信断時の受付・調剤・薬歴・会計、端末故障時の代替手段、サポート窓口の対応時間を実際の業務シナリオで確認します。契約書には、セキュリティ対策の役割分担と、インシデント発生時の報告期限を明記します。

不要にはなりません。AIは薬歴や服薬指導記録の下書き作成を支援できますが、薬剤師が内容を確認し、必要な修正を行って確定する運用が前提です。発注時には、生成根拠の参照、確認者の記録、修正履歴、誤った提案を報告する仕組み、患者情報を学習へ利用するかどうかを確認し、時短効果と安全性を同時に評価します。

まとめ

調剤薬局システムの発注・外注では、最初に店舗規模と業務課題を整理し、標準パッケージ、クラウド、複数製品連携、スクラッチの中から独自性と責任範囲に合う形態を選びます。RFPには、処方箋受付から請求・在庫・在宅までの業務要件と、電子処方箋、標準連携、セキュリティ、障害時運用、データ移行を記載します。

費用は、標準導入の初期50万〜200万円・月額3万〜8万円、クラウド型の初期10万〜50万円・月額5万〜15万円を目安にしつつ、端末、移行、教育、保守、法改正、追加店舗を含めて比較します。カスタム開発は500万円以上を起点に、機能と連携の数に応じて再見積もりします。特定の金額だけで発注先を決めず、同じ条件の見積書と実データに近いデモで判断します。

最後に、代表薬剤師、事務担当、本部、情報システム担当が、必須要件、評価配点、受入基準、契約上の責任分界を合意します。稼働後は処方箋処理時間、薬歴確定時間、エラー、在庫発注、問い合わせ、障害復旧を測定し、導入効果を確認します。調剤薬局システムは、導入した時点ではなく、現場で安全に使われ、患者対応の時間が増えた時点で成果になります。

▼全体ガイドの記事
・調剤薬局システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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