調剤薬局システム開発の進め方/やり方/流れや方法/手法/工程/手順

導入は、業務を整理し、製品を選び、段階的に開発・導入する順で進めます。この順で進めると、安全な運用と薬剤師の対人業務の時間確保につながります。

工程は6段階で、費用と見積もりの確認点も後半で扱います。システムの全体像は、調剤薬局システム開発の完全ガイドもご覧ください。

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

調剤薬局システム開発の全体像

調剤薬局システムが扱う患者・保険資格情報、処方入力、電子薬歴、会計を4枚のカードで示す図。
受付で扱う情報から記録や会計まで、業務の範囲を見渡せます。

調剤薬局システムは、患者・保険資格情報から処方入力、監査、電子薬歴までを扱う業務基盤です。

この業務基盤の範囲には、会計、請求、在庫、在宅業務も入ります。

構成は、レセコンと電子薬歴を一体にした型、別ベンダー製品との連携、既存システムへの周辺機能の追加の3つに分かれます。そのため、発注側と開発会社は、業務フローと法令・請求要件に合う形を選びます。

まず押さえるべき主要機能

必須機能と薬局ごとの追加要件を分けると、必要な範囲を判断できます。

  • 基本業務:患者登録、保険資格確認、処方入力、薬剤・用法用量の確認を扱います。さらに、調剤録と電子薬歴、薬袋・薬情の出力、会計、請求も含みます。
  • 店舗業務:在庫、発注、棚卸、店舗間融通、ピッキング監査の支援。
  • 患者対応:在宅訪問、服薬フォロー、オンライン服薬指導、経営分析などの追加。

二次元コード読取やOCRも、業態によっては要件になります。

紙と電子の処方箋が混在する日でも、受付から調剤結果登録まで同じ運用で処理できるかを、発注側が確認します。

一体型、クラウド型、別製品連携、スクラッチの使い分け

店舗数や独自業務に合わせて構成を選び、導入後の運用責任まで見通しておきます。

  • 一体型:標準的な1店舗の業務に合わせやすく、短期導入にも適しています。
  • クラウド型:複数店舗、本部管理、在宅訪問、タブレット利用がある場合の候補です。
  • 別製品連携:機能を選びやすい一方、連携仕様と障害時の受け持ち範囲、データ移行の担当を決める必要があります。
  • カスタム開発:独自の本部業務やM&A後の統合に使えます。

クラウド型を選ぶ場合は、通信断のときにどう業務を続けるか、データをどこに保管するかを確認します。

カスタム開発では、法改正、薬価マスター、監査、バックアップを長期にわたって運用する責任も増えます。

ポイント

構成は、業務フローと法令・請求要件に合うかで選びます。店舗数や独自業務に加え、導入後の運用を誰が担うかまで見て判断します。

調剤薬局システム開発の進め方・流れ

調剤薬局システム開発の要件整理、選定、設計開発、テスト、稼働と定着を左から順に並べた図。
現場の要件を固めてから試験へ進み、稼働後の定着までつなげます。

導入は、要件整理、選定、設計開発、テスト、稼働、定着の順に進みます。

パッケージを使う場合も、業務を洗い出す作業、移行、教育、受入テストが必要です。

スクラッチ開発では、請求や薬歴など止められない機能を優先します。

全機能を一度に作らず、段階的に広げると、現場の負担を抑えやすくなります。

フェーズ1:要件整理・企画で決める業務と優先順位

現場の代表者とともに、業務の流れ、優先順位、導入効果の測り方を決めます。

  • 業務の洗い出し:受付から患者フォローまでを時系列で一覧にします。
  • 担当者の選出:薬剤師、医療事務、在宅担当、本部、情報システムのそれぞれから代表を立てます。
  • 要件の振り分け:「必須」「優先」「保留」の3つに分類し、利用者と受入条件も記録します。
  • 指標の設定:薬歴確定時間、未記載件数、棚卸時間、発注漏れ、返戻・査定、待ち時間を導入前に測ります。

現場の担当者が加わらないまま経営者だけで決めると、繁忙時の入力、処方箋の例外、薬歴の確認者、紙に戻す手順が抜けてしまうおそれがあります。

必須要件には、電子処方箋、オンライン資格確認、改定対応を含めます。このほか、権限管理と監査ログを入れます。

バックアップと障害時の紙運用も、必須要件に含めます。

調剤結果登録も必須要件に加えます。要件表には、利用者、入力項目、外部連携を書き出します。さらに、エラー時の処理、受入条件、担当者も記録します。

導入効果については、何を何分短縮するか、誰が確認するかまで決めます。

フェーズ2:製品・開発会社の選定と、デモ・契約条件の確認

デモと契約条件は、同じ要件表を使って確認し、候補を比べます。

  • 業務を通して試す:代表的な処方箋を使い、デモで実際に操作します。
  • 連携仕様を見る:XML、連携項目、更新、再送、API利用料を確かめます。
  • 保守の範囲:月額料金に何が含まれるかどうか。
  • 見積条件をそろえる:標準機能、追加開発、移行、教育、保守を分けて依頼します。

受付から会計までの流れを通して、処方入力から監査、薬歴作成へつながるかを確かめます。

在宅入力やリフィル、分割調剤は、業務どおりに再現します。また、疑義照会、紙と電子の混在、通信断も試します。

実際に使うスタッフが、入力の速さ、確認箇所の見つけやすさ、戻る操作のしやすさを評価します。

厚生労働省は、処方・調剤情報などをPDFではなくXML形式で連携し、JAHISの連携仕様書を確認するよう案内しています。

出典は、厚生労働省「レセコンと電子薬歴システム間で連携するデータについて」です(2025年確認)。

保守では、薬価・点数改定と制度変更、OSやブラウザの更新が月額に含まれるかを確かめます。さらに、端末故障と夜間障害、データ返却も、月額に含まれるかを見ます。

店舗追加や解約時の移行支援の扱いも、併せて確かめます。

フェーズ3:設計・開発での標準機能と追加開発の境界

業務フローと画面、帳票を具体的に決めます。そのうえで、権限や連携、障害時の運用を決めます。また、マスターやログ、バックアップも定めます。

  • 機能の境界:標準機能に合わせる範囲と、設定・帳票変更・連携開発で補う範囲を分けます。
  • 移行の範囲:患者基本・保険情報、薬歴、処方・調剤履歴、在庫、取引先、薬品マスターから対象を選びます。
  • 安全管理:職種・店舗・役割ごとの権限、二要素認証、暗号化、操作ログを定めます。バックアップ、脆弱性対応、委託先監査も含めます。

独自仕様が多いと、法改正や更新のたびに追加費用が生じ、将来ベンダーを変更することも難しくなります。

移行元の項目定義が曖昧だと、氏名表記や保険者番号、薬品コード、履歴日付の変換で誤りが出やすくなります。そのため、移行対象と除外対象、変換ルールを文書にまとめます。さらに、件数照合、薬剤師によるサンプル確認、移行後の訂正方法も書いておきます。

薬剤服用歴や処方情報は要配慮情報として扱います。

第6.0版関連Q&Aは、薬局のレセコンや電子処方箋の管理も対象です。

出典は、厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版 関係Q&A」です(2025年5月版)。

2026年5月には、第7.0版案の検討も公表されています(出典:厚生労働省「医療等情報利活用ワーキンググループ」、2026年)。

制度改定時の対応方針は、契約で確認できるようにしておきます。

フェーズ4:通常ケースと例外ケースを分けたテスト

薬局側も受入テストを行い、機能と実際の業務の両方を確かめます。

  1. 単体テストで画面や計算を確認します。
  2. レセコン、電子薬歴、在庫、会計、外部サービスの結合テストを行います。
  3. スタッフが業務シナリオを実施し、結果を受入条件と照合します。

シナリオには、通常の新患受付に加えて、例外の場面も入れます。保険変更、負担割合変更、疑義照会を含めます。

さらに、重複投薬アラートと分割・リフィル処方箋、在宅患者を加えます。薬品不足や返品、レセプト返戻も含めます。

電子処方箋の調剤結果登録とネットワーク断、端末故障への対応も確認します。また、バックアップからの復旧も確かめます。

AI薬歴では、生成文の誤りや抜けを薬剤師が修正して確定できるかを試します。自動で確定させず、確認者と承認ログを明確にしておきます。

フェーズ5・6:段階導入と改善による稼働と定着

切替の方法と定着の仕組みを先に決め、安全に運用できる状態を確かめます。

  • 切替方式:一斉導入か、1店舗から横展開する方法かを選びます。
  • 稼働準備:旧システムの参照期間、紙帳票、連絡先、復旧基準を決めます。
  • 定着支援:役割別手順書、問い合わせ窓口、週次会議、月次確認を用意します。

業務差の大きいチェーンや初めてのカスタム開発では、代表店舗で2〜4週間検証してから展開します。その際は、受付から請求までの実績を確かめます。

操作研修を一度行うだけでは定着しないため、導入後も指標を継続して測ることが欠かせません。測る項目は、薬歴確定までの時間、未記載件数、在庫差異です。さらに、発注時間や待ち時間、電子処方箋の処理件数も含めます。

そのうえで、未使用機能や二重入力を見つけ、機能を追加する前に負担の大きい手順を減らします。

ポイント

各フェーズで決めた内容は、次のフェーズの前提になります。要件表と受入条件を文書で残し、選定や試験の判断に使える状態にしておくことが目安です。

調剤薬局システムの費用相場とコストの内訳

費用は、店舗数や処方箋枚数、機能によって変わります。また、機器や連携、移行、教育、保守も、費用を左右します。示す幅は、2026年版の公開相場と調査ノートに基づく計画用の目安です。

示す幅は、個別製品の契約価格を保証するものではありません。機器や設置、電子処方箋対応、訪問サポートの有無も、見積条件と合わせて比べます。

パッケージ・クラウド導入の費用相場

公開相場の幅と個別の掲載価格を分けて見ると、初期費用と月額を比べられます。

  • 小規模薬局向け一体型:初期50万〜200万円、月額3万〜8万円程度です。
  • クラウド型:初期10万〜50万円、月額5万〜15万円程度です。
  • 複数店舗向け大規模パッケージ:初期200万〜500万円、月額10万〜30万円程度です。
  • カスタム開発:500万〜2,000万円程度の幅が示されています。

これらは、公開記事による目安で、市場全体の契約価格ではありません(出典:株式会社FUNBREW「調剤薬局システムの導入ガイド|レセコン選び方・費用・電子処方箋対応 2026年版」、2026年3月)。

調査ノートでは、モイネットシステム「Pharmy Connect」について、税抜83万円という公式価格例を確認しています。

単一製品の掲載価格は、端末や通信回線、設置、データ移行、保守、追加店舗を含む総額とは限りません。

初期費用のない月額型も、5年分の利用料やオプション、端末更新を足すと、購入型より高くなる場合があります。

カスタム開発とスクラッチ開発の費用の見積もり方

独自機能の範囲と運用責任が金額を左右します。そのため、要件を固めてから見積もります。

  • 中規模カスタマイズ:1店舗で既存APIや標準連携を使い、本部管理や独自帳票を加える場合、500万〜1,500万円程度を仮置きする例があります。
  • 複数店舗向け:本部管理、店舗間在庫、患者向けアプリ、卸や機器との連携を含む場合、1,500万〜5,000万円以上の想定例があります。

上記は、類似業務システムの相場をもとにした計画用の推定で、確定した相場ではありません。画面数や連携数、移行データ、試験量、保守体制は、要件定義のあとに見積もります。

レセプトや薬価マスター、電子薬歴、監査をゼロから作ると、費用が膨らみます。電子処方箋、権限、監査ログも自前で作る場合は、制度改定やセキュリティ試験の費用が加わります。さらに、移行や障害時運用の費用も膨らみます。

請求や安全機能は簡略化せず、標準製品を活用します。一方で、独自開発は本部業務や差別化機能に絞ると、長期のリスクを抑えやすくなります。

初期費用以外に必要なランニングコスト

月額以外の支出も洗い出し、初期費用ではなく5年間のTCOで比べます。

  • 機器・環境:端末、モニター、バーコードリーダー、スキャナーの費用が生じます。プリンター、カード関連機器、回線、バックアップも対象になる場合があります。
  • 運用・連携:電子署名・証明書、外部API、追加店舗・ユーザー、訪問サポートを確認します。
  • 導入・保守:改定対応、移行、研修、夜間切替、旧システムとの並行稼働も見積もります。

TCOは、初期費用と月額60か月分に、端末更新、オプション、連携を加えて計算します。さらに、移行、教育、保守外の対応も入れます。一方で、補助金や既存機器の継続利用分は差し引きます。

業務の効果は、薬歴入力や棚卸、発注、レセプト修正、待ち時間の変化で測ります。そのうえで、費用と並べて効果と安全性を判断します。

ポイント

費用は、初期費用と月額だけでなく5年間のTCOで比べて判断します。公開相場は計画用の幅として扱い、見積条件と除外事項をそろえてから金額を比べます。

調剤薬局システムの見積もりを取る際のポイント

見積依頼書に記載する薬局の条件、既存環境、機能の優先度、受入条件をチェック項目として示す図。
条件を共通化すると、候補会社ごとの回答を並べて検討できます。

条件を具体的に決め、候補会社へ同じ資料を渡すと、機能、工数、成果物、前提、除外事項を比べられます。

選ぶ際は安さだけでなく、追加費用になりうる項目と薬局側の作業範囲を確認します。

要件と見積依頼書の記載内容

薬局の規模、既存環境、機能の優先度、完成判定の条件を依頼書に記します。

  • 薬局の条件:店舗ごとの処方箋枚数、スタッフ数、営業時間、在宅件数を記載します。
  • 既存環境:既存システム、端末・機器、外部連携、データ量、希望時期、研修対象を示します。
  • 機能の優先度:受付、処方入力、監査、薬歴、会計、請求を基本業務として分類します。在庫、発注、患者対応、分析も分けて示します。

受入条件には、電子処方箋の処理、薬歴の確認・修正、店舗間の閲覧制限、指定時間内の復旧を記載します。

旧システムと移行後のデータ件数の一致も条件にできます。基準が曖昧なままだと、納品時に完成かどうかを判断できません。

複数社を比較するときの評価軸

機能の適合だけでなく、制度対応や連携、安全性を見ます。さらに、移行、支援、費用、将来性も比べます。

  • 業務適合性:代表処方箋を使うデモで操作性を確かめます。
  • 制度・連携:改定方法、XMLや標準仕様、APIの公開範囲、障害時の再処理を確認します。
  • 支援と費用:移行、保守、導入支援と追加費用の条件を比べます。

自社に近い薬局の事例を聞き、導入社数も合わせて確認します。個人薬局では、少人数で受付・薬歴・請求が回るかを見ます。一方で、地域チェーンでは、薬歴の共有や本部分析、在庫融通、店舗追加の条件を確かめます。

数十店舗以上なら、権限、マスター、監査、障害対応、M&A時の統合を見ます。また、近い事例の担当者に運用を聞けるかも評価します。

見積の抜けと開発リスクへの備え

見積の範囲とリスク時の対応を契約や運用ルールに明記し、後からの認識違いを防ぎます。

  • 見積項目:機器、移行、教育、店舗追加を確認します。法改正対応、外部利用料、テスト用データ、稼働後支援も含めます。
  • 費用条件:区分、数量、単価、成果物、担当範囲を記録します。
  • リスク対応:変更管理、追加費用の算定、遅延時の判断、復旧訓練、障害時の紙運用を決めます。

口頭で「含まれる」とされた内容は、契約書や仕様書に反映します。要件が未確定なら、先に要件定義を行い、その成果物をもとに開発費を再見積もりできます。

連携先の仕様変更や通信障害、端末故障、攻撃、習熟不足にも備えます。そのため、復旧訓練、応答時間、データ返却形式を決めます。

AI機能を含む場合は、入力データの目的、学習利用、保存期間、生成結果の確認者、誤りの報告方法も定めます。

ポイント

見積は、候補会社に同じ要件表を渡して条件をそろえると比べやすくなります。安さだけで選ばず、追加費用になりうる項目と薬局側の作業範囲を見ます。

調剤薬局システム開発のよくある質問(FAQ)

費用や期間は要件によって変わります。導入を検討する際の目安と、その確認方法をまとめます。

調剤薬局システムの導入にはどのくらいの期間がかかりますか?

標準パッケージかカスタム開発か、移行や店舗展開を含むかによって、導入期間は変わります。

  • 標準パッケージ:1〜3か月が目安です。
  • データ移行・周辺機器・複数店舗展開を含む場合:3〜6か月が目安です。
  • 中規模カスタム:6〜12か月が目安です。
  • 本部機能や多数連携を含む場合:12〜24か月が計画上の目安です。

期間は、仕様や店舗数、移行データ、テスト体制をもとにした推定で、確定値ではありません。

要件定義と移行、受入試験は工程別に見積もります。設定・開発、教育、並行稼働も、工程ごとの内訳に含めます。

工程ごとに見ると、短縮できる部分と短縮してはいけない部分が分かります。

AI薬歴は導入すれば自動で業務が完了しますか?

AI薬歴は、会話の録音や文字起こしからSOAP形式の下書きを作り、薬剤師の記載を支援します。下書きは、患者ごとの処方・指導内容と一致するかを薬剤師が確認・修正してから確定します。そのため、確認と確定の作業は薬剤師の側に残ります。

日本調剤は、2024年11月に50店舗で先行検証したサービスを2025年に全763店舗へ導入すると公表しました(出典:日本調剤「AI薬歴作成支援サービスcorteを全店舗に導入へ」、2025年5月)。

導入時は、時短だけでなく、確認時間や誤記録の防止、権限、データ保存も評価します。

電子処方箋対応は要件定義で何を確認すればよいですか?

受取から処方確認、重複投薬チェック、調剤結果登録、電子署名、タイムスタンプまでの流れを確認します。

周辺の医療機関では、紙の処方箋を扱う場合もあります。そのため、紙と電子が混在するときの患者説明や待ち時間、後追い登録、障害時の紙運用も試します。

厚生労働省の薬局向けスターターキットや導入状況ダッシュボードは、地域の導入状況と準備の確認に使えます(出典:厚生労働省「電子処方箋」、2026年確認)。

1店舗の小規模薬局でもカスタム開発を検討すべきですか?

薬局の業務に応じて、標準製品と周辺機能の開発を比べます。

  • 標準的な業務:受付・調剤・薬歴・請求が標準的なら、法改正や薬価更新に対応しやすい標準パッケージやクラウド型から比べます。
  • 独自業務:在宅訪問や独自の患者フォローが多く、標準機能で回らない場合は周辺機能だけを開発する選択肢があります。
  • 既存システム連携:在庫や会計、医療機関のシステムと深く連携したく、標準機能で業務が回らない場合は、周辺機能の開発が選択肢になります。

レセプトや安全管理の中核をゼロから作る前に、既製品を組み合わせて解決できないかを検討します。

まとめ

最初に取り組むべき業務フローの整理

開発は、要件整理、選定、設計、テスト、稼働、定着の順に進めます。まず、現場業務と処方箋の例外を洗い出し、法令・請求・安全の必須要件を定めます。

製品や会社は機能一覧だけでなく、代表処方箋のデモ、XML連携、移行、障害時運用、保守、制度改定対応まで確認して選びます。

初期費用ではなく5年TCOと定着効果による判断

公開相場では、小規模薬局向け一体型は初期50万〜200万円、月額3万〜8万円です。クラウド型は初期10万〜50万円、月額5万〜15万円、カスタム開発は500万〜2,000万円程度が目安です。

端末、移行、連携、教育、保守、追加店舗を含む5年TCOで比べ、見積条件と除外事項を確認します。そのうえで、導入後も指標を測り、患者対応の時間と安全性の向上につなげます。

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

会社紹介

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

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

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

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

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

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