医事会計システムの発注・外注は、製品を先に決めるのではなく、受付からレセプト、入金、返戻管理までの業務と連携範囲を整理し、施設規模に合う発注形態・契約・委託先を比較して進めることが重要です。
医事会計システムは、診療報酬改定やオンライン資格確認、電子カルテ連携の影響を受ける基幹システムです。この記事では、パッケージ・クラウド・スクラッチの選び方、RFPと要件整理、請負・準委任の違い、施設規模別の費用レンジ、見積比較とベンダー選定の確認項目まで、発注前に必要な実務を順番に解説します。
▼全体ガイドの記事
・医事会計システム開発の完全ガイド
医事会計システムの発注・外注は何から始めますか?

結論から言うと、最初に決めるべきものは製品名ではなく、解決したい業務上の問題と、委託する範囲です。医事会計単体を導入するのか、電子カルテや部門システム、自動精算機、会計・経営分析まで含めて再構築するのかで、発注先も予算も大きく変わります。
発注前に課題を業務フローへ落とし込みます
受付、患者登録、資格確認、診療行為入力、外来・入院会計、レセプト作成、返戻・査定、未収金、月次締めという流れを、現在の担当者と一緒に書き出します。「会計が遅い」「算定漏れが心配」といった感覚的な悩みを、会計待ち時間、返戻件数、二重入力の項目数、月末残業時間などの指標に変えると、提案内容と導入効果を比較しやすくなります。
この段階では、医事課だけで要件を決めないことが大切です。医師、看護師、受付、診療情報管理、経理、情報システム担当が関係するため、部門ごとに「必須」「できれば欲しい」「現行運用を変えてもよい」を分けます。現行システムの画面や帳票をすべて残すのではなく、業務上なくせない条件を特定することが、不要なカスタマイズを抑える出発点になります。
内製・外注・共同推進の境界を決めます
医療機関側が担うべきなのは、診療報酬の運用方針、現場の優先順位、承認ルート、データの所有と利用目的です。一方、外部へ委託しやすいのは、製品の設定、連携開発、データ移行、テスト支援、操作研修、保守運用です。院内にIT人材が少ない場合でも、業務判断まで丸ごと任せると、稼働後に変更や障害の判断ができなくなるため注意が必要です。
おすすめは、医療機関側の責任者と現場代表を決め、外部の開発会社や導入ベンダーと共同で進める体制です。週次の定例会議、課題一覧、決定事項、承認期限を最初に設定し、誰が何を決めるかを明文化します。発注者側の意思決定が遅れると、開発会社が待機する期間や仕様変更が増え、見積金額と稼働時期の両方に影響するためです。
発注形態はパッケージ・クラウド・スクラッチをどう選びますか?

発注形態は、費用の安さだけで決めるのではなく、診療報酬改定や制度変更への追随、連携の複雑さ、院内の運用差、将来の拠点追加を見て選びます。標準機能で業務の大部分を吸収できる施設はパッケージまたはクラウドが有力で、特殊な入院・DPC・未収金管理や複数施設の独自業務が競争力に直結する場合だけ、限定的な個別開発を検討します。
パッケージ型は標準機能とカスタマイズ上限を確認します
パッケージ型は、患者情報、保険・公費情報、診療費計算、レセプト、請求書・領収書など、医事会計の基本機能が整っているため、ゼロから作るより制度対応を任せやすい方式です。ただし、標準機能にない画面や帳票を追加するほど、初期費用、テスト工数、改定時の確認範囲が増えます。見積依頼では、標準機能、設定変更、追加開発、将来対応の保留項目を分けて記載してもらいます。
クラウド型は月額料金以外の導入範囲を見ます
クラウド型は、院内サーバーの購入や更新を抑えやすく、バックアップやソフトウェア更新をサービス側へ寄せられる点がメリットです。日本医師会ORCA管理機構のWebORCAクラウド版では、基本サービスが1医療機関あたり月額2,200円(税込)で、TLS1.2サービスは初期費用0円、月額550円(税込)と公開されています(出典:日本医師会ORCA管理機構「日医標準レセプトソフト[WebORCAクラウド版]」、2026年確認)。
ただし、この公開料金はソフトの基本利用料です。端末、院内ネットワーク、接続設定、操作研修、過去データ移行、電子カルテ連携、自動精算機連携、サポート事業所の保守費用まで含むとは限りません。月額だけで比較せず、初年度総額と5年間の総保有コスト、障害時の連絡先、通信障害時の代替運用を確認します。
スクラッチ開発は差別化できる範囲に限定します
スクラッチ開発は、自院特有の算定、複雑な入院運用、複数施設の統合管理などを細かく設計できる一方、制度変更への保守責任を発注者と開発会社で継続して負います。医事会計の基盤すべてを独自開発するのではなく、標準的なレセプト・マスタ機能は実績ある製品を使い、周辺の連携や経営分析だけを追加開発する構成も現実的です。
スクラッチを選ぶ場合は、ソースコード、設計書、API仕様、データベース定義、テスト仕様書、データのエクスポート方法を契約に含めます。開発会社を将来変更できる状態をつくり、診療報酬改定のたびに特定ベンダーへ依存しすぎないことが、長期の発注リスクを抑えます。
RFPと要件整理では何を発注先へ伝えますか?

RFPは、開発会社へ「何を作ってほしいか」だけを伝える文書ではありません。施設の背景、対象業務、利用者、既存システム、連携先、データ量、希望時期、予算の考え方、提案に含めてほしい保守範囲をそろえ、各社から同じ前提で提案を受けるための比較資料です。要件を曖昧にしたまま相見積もりを取ると、安い会社ではなく、含めていない項目が多い会社が安く見えるためです。
現行フローと必須機能を一枚にまとめます
RFPには、施設の種類、病床数、診療科、外来・入院の比率、月間レセプト件数、医事課の人数、拠点数、稼働希望日を記載します。機能要件は、患者登録、保険・公費、オンライン資格確認、診療費計算、入院定期請求、DPC、レセプト点検、返戻・査定、未収金、統計・経営分析などを一覧化し、必須か任意か、現行の問題は何かを添えます。
「できること」の説明だけでなく、「できない場合の代替案」も提案してもらいます。例えば、特定の公費処理を標準機能で扱えない場合に、設定変更、追加開発、運用変更のどれで対応するのかを分けます。現場が慣れた帳票を残すことが目的化すると、不要な開発が増えるため、帳票の利用目的と出力頻度も記載します。
連携とデータ移行は別項目で具体化します
電子カルテ、オーダリング、検査、薬剤、放射線、透析、予約・受付、自動精算機、会計、病院経営DWHなど、接続先を一覧にします。連携方式がAPI、CSV、標準規格、個別インターフェースのどれか、連携方向が片方向か双方向か、リアルタイムか日次か、障害時に再送できるかまで確認します。厚生労働省は医療情報を標準的な形式のメッセージやコードで設計する必要性を示しているため、将来の接続先を含めて標準対応の有無を質問します(出典:厚生労働省「医療分野の情報化の推進について」、2026年確認)。
データ移行では、患者基本情報、保険・公費、過去の診療履歴、未収金、返戻、マスタ、帳票を対象にするかを決めます。全履歴を移すと費用と検証工数が増えるため、法定保存、現場の参照頻度、監査対応をもとに、オンライン移行、参照用アーカイブ、紙・PDF保管を分けます。移行リハーサルを本番前に少なくとも一度行い、件数照合とランダム抽出による内容確認を受け入れ条件にします。
非機能要件と導入後KPIを先に決めます
医事会計では、画面機能だけでなく、応答時間、同時利用者数、稼働時間、バックアップ、復旧目標、操作ログ、権限、暗号化、多要素認証、脆弱性対応、再委託先、データセンターの所在地をRFPへ入れます。厚生労働省の医療情報システム安全管理ガイドラインは2026年6月に第7.0版へ改訂され、概説編、経営管理編、企画管理編、システム運用編、保守委託機関編に分けて整理されています(出典:厚生労働省「医療情報システムの安全管理に関するガイドライン第7.0版」、2026年)。
また、導入後の評価指標を発注時に決めます。会計待ち時間、返戻率、算定漏れの疑い、窓口の入力時間、月末残業、未収金の回収状況、障害から復旧するまでの時間などです。数字を測れないと、稼働後に「便利になった気がする」という感想だけで終わります。ベンダーには、KPIの取得方法と、稼働後何か月で評価するかまで提案してもらいます。
契約形態は請負と準委任のどちらを選びますか?

契約形態は、成果物と責任範囲を確定できる工程には請負、要件を詰めながら専門家の稼働を得る工程には準委任を使い分けるのが基本です。医事会計システムでは、要件定義から本番稼働までを一つの契約で固定するより、企画・要件定義、設定・開発、移行・テスト、保守の段階に分けると、変更の影響を管理しやすくなります。
請負契約は成果物・検収・変更条件を定義します
請負契約は、合意した仕様に基づくシステムや設定、連携機能などの完成を受託者が約束し、発注者が検収する契約です。RFPの時点で要件が十分に固まっている場合に向きますが、医療現場の運用差を後から発見すると、変更が追加費用や納期延長になりやすい点に注意します。
契約書や個別契約には、納品物、検収基準、瑕疵や不具合の扱い、追加開発の単価、仕様変更の承認手順、再委託、知的財産権、データの返却、損害賠償の上限を記載します。特に「標準機能の設定」と「個別開発」を分け、診療報酬改定への対応が保守に含まれるかを確認することが重要です。
準委任契約は役割と稼働範囲を管理します
準委任契約は、特定の成果物の完成ではなく、要件定義支援、プロジェクト管理、設計支援、データ移行支援などの業務を専門家が遂行する契約です。業務を見ながら要件を深める工程に適していますが、成果物の品質を自動的に保証する契約ではありません。発注者側の責任者、会議体、作業時間、報告方法、成果物のレビュー方法を別途定めます。
請負と準委任を組み合わせる場合は、工程ごとに責任の境界を表にします。例えば、要件定義は準委任、確定した機能の開発は請負、移行と稼働支援は準委任とする方法です。契約方式だけでリスクが消えるわけではなく、変更管理と意思決定を機能させることが重要です。
SLAと稼働後の引き継ぎを契約に含めます
稼働後は、障害の重要度ごとの受付時間、一次回答、復旧目標、計画メンテナンス、診療報酬改定やマスタ更新の対応、問い合わせ窓口、教育の追加料金をSLAに落とし込みます。経済産業省は、医療情報を扱うサービス提供事業者向けガイドライン第2.0版と、サービス仕様適合開示書・サービスレベル合意書の参考例を公開しています(出典:経済産業省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」、2025年公表)。
また、納品後に院内で運用できることを検収条件にします。管理者向け研修、医事課向けの操作研修、障害時の手順書、バックアップからの復旧訓練、設定変更の申請方法、データ抽出の手順をそろえます。担当者が異動しても運用を続けられるよう、特定の担当者だけが知っている設定を残さないことが大切です。
医事会計システムの費用相場はいくらですか?

医事会計システムの費用は、ソフト本体だけでなく、初期設定、端末・ネットワーク、連携、データ移行、研修、並行稼働、保守を含めて考えます。公開された医事会計固有の統計は限られるため、以下はリサーチノートで確認した公開料金と、医療業務・基幹システムの類似案件から整理した目安です。実際の金額は施設規模、病床数、診療科、連携数、移行対象によって変わります。
小規模診療所は初期10万〜50万円が一つの目安です
小規模診療所がクラウド型レセコンを標準構成で導入する場合、初期費用は10万〜50万円程度、月額・保守・周辺サービスを合わせて月2万〜5万円程度が目安になります。院内の端末やネットワークを既存設備で使えるか、電子カルテや自動精算機との連携があるかで変わるため、レンジ内の上限だけを見て判断しません。
オンプレミスやハイブリッドでサーバー、端末、設定、連携を含めると、初期費用は300万〜500万円程度、連携設定や移行を含めて450万〜700万円程度まで広がる場合があります。これは定価ではなく、機器と作業範囲を含む導入モデルの目安です。月額だけでなく、5年間の保守、機器更新、バックアップ、障害対応を足して比較します。
中小病院は1,500万〜4,000万円程度から個別化します
中小病院で電子カルテ、入院会計、DPC、部門システム、レセプト、未収金、自動精算機などを連携する場合、初期費用は1,500万〜4,000万円程度が一つの目安です。月額・保守は10万〜30万円以上を含む個別見積もりになりやすく、病床数や同時利用者数、24時間運用、既存データの量で差が出ます。医事会計単体の価格と、病院情報システム全体の価格を混同しないことが重要です。
大病院、複数拠点、DPC・経営DWH連携、個別のBCPやSLAまで含める場合は、4,000万円〜1億円超のレンジになることもあります。高額になる理由は機能数だけではなく、業務停止できない時間帯の移行、複数システムとの接続、データ検証、教育、並行稼働、復旧設計が積み上がるためです。必ず見積書で「ソフト」「連携・移行」「ハード・ネットワーク」「教育・保守」を分解します。
見積書は初期費用とランニング費用を分けます
見積比較では、要件定義、設計、設定・開発、テスト、データ移行、研修、稼働支援、保守を分けます。一般的な工程比率の参考として、要件定義が総額の約10%、設計が10〜20%、開発が40〜60%、テストが10〜20%程度とされる考え方があります。ただし、医療機関では移行・並行稼働・制度対応の比率が高くなるため、比率をそのまま正解とせず、各社へ工数の根拠を質問します。
ランニング費用には、ライセンスやクラウド利用料、保守、法改正・マスタ更新、監視、バックアップ、セキュリティ対策、問い合わせ、端末・ネットワーク更新が含まれます。初年度だけ安い提案ではなく、3年・5年・10年の総額と、契約終了時のデータ返却費、追加連携の単価まで確認すると、発注後の予算超過を抑えられます。
委託先の選定と見積比較では何を確認しますか?

委託先は、知名度や見積総額だけでなく、対象施設と同じ規模・診療科・運用条件での実績、導入体制、連携力、稼働後の保守を合わせて評価します。完成済みの医事会計製品を導入するベンダーと、周辺連携や個別開発を担う開発会社では役割が異なるため、1社にすべてを任せるのか、製品ベンダーと開発会社を分けるのかも比較対象にします。
医療機関との実績は規模と業務の近さで確認します
実績を聞くときは、導入社数だけで満足しません。診療所か病院か、病床数、DPCの有無、入院・外来の比率、電子カルテや部門システムの種類、移行したデータ範囲、稼働までの期間、稼働後の障害件数と対応体制を確認します。可能であれば、同じ規模の導入先へ、提案時の説明と実際の運用に差がなかったかをヒアリングします。
診療報酬改定への追随も重要です。直近の改定で、マスタ更新、算定ロジック、レセプト点検、帳票変更をどのように提供したかを確認し、更新費用が保守に含まれるか、利用者側のテストが必要かを質問します。医療DXでは全国医療情報プラットフォーム、電子カルテ情報の標準化、診療報酬改定DXの三本柱が進められているため、現在の機能だけでなく、標準仕様や将来接続への対応方針も比較します(出典:厚生労働省「医療DXについて」、2026年確認)。
見積は同じ前提・同じ粒度で横並びにします
相見積もりでは、各社へ同じRFPと質問票を渡し、標準機能、設定、追加開発、外部製品、移行、研修、稼働支援、保守を同じ項目で回答してもらいます。見積金額が低い場合は、何が含まれていないのかを確認します。特に、連携先ごとの接続費、データクレンジング、旧システムの参照環境、休日・夜間の切り替え、現場立ち会いが別料金になっていないかを見ます。
評価は、価格だけでなく、要件適合度、連携・移行の実現性、導入スケジュール、体制、セキュリティ、保守、データの可搬性で点数化します。例えば、価格25点、機能・業務適合25点、連携・移行15点、体制・実績15点、保守・SLA10点、セキュリティ・契約10点のように、院内で重視する項目を先に合意します。点数配分は施設ごとに変えてよく、重要なのは選定理由を後から説明できることです。
提案会では担当者と障害時の動きを確認します
提案会には、営業だけでなく、導入責任者、医事会計に詳しい担当者、連携担当、移行担当、保守責任者が参加してもらいます。質問への回答をその場で断定できない場合に、いつ誰がどの資料で回答するかも確認します。提案段階で技術担当が見えない会社は、稼働直前に確認事項が集中する可能性があるため、体制図と担当者の役割を提出してもらいます。
障害時には、まず誰へ連絡し、どの情報を渡し、どの程度で暫定復旧するのかを聞きます。クラウド障害や院内ネットワーク停止、資格確認の停止、連携データの欠落、レセプト送信前の不具合など、ケース別の代替運用を確認します。医療情報を扱う委託先には、操作ログ、権限管理、暗号化、バックアップ、インシデント連絡、再委託先の管理を含む説明を求め、契約書とSLAの内容が提案資料と一致しているかを確認します。
医事会計システムの発注で起きやすい失敗をどう防ぎますか?

失敗の多くは、製品選定の時点ではなく、発注範囲と責任分担の曖昧さから起こります。機能一覧だけで決める、現場の代表が要件定義に参加しない、移行と連携を後回しにする、稼働日から逆算したテストがない、といった状態では、導入後に追加費用と現場負担が生まれます。
追加費用は変更管理と除外項目を明確にして防ぎます
発注時点で仕様を完全に確定することは難しいため、変更を禁止するのではなく、変更の扱いを決めます。追加要望が出たら、目的、影響する画面、連携、テスト、納期、費用、代替案を記録し、院内承認を経て着手します。提案書の「別途見積」「要相談」「想定外」という表現は、対象範囲と算定方法を質問し、見積書の除外項目一覧へ落とし込みます。
移行・テスト・切り替えを本番業務に合わせます
テストは、画面が開くかを確認するだけでは不十分です。保険・公費・限度額認定、外来・入院、各種加算、返戻、未収金、月次締め、レセプト作成、オンライン請求、電子カルテからの連携、自動精算機まで、実際の業務シナリオで確認します。正常系だけでなく、資格情報が不一致の場合、連携データが欠落した場合、停電や通信断が起きた場合の手順もテストします。
切り替え日は、診療を止められる時間、月末・請求時期、職員の勤務、旧システムの参照方法を踏まえて決めます。旧システムをすぐ停止せず、一定期間は参照できる状態を維持し、最初の請求締めまで支援担当を配置する方法が安全です。稼働判定の条件を「移行件数の照合」「重大障害ゼロ」「主要業務の完了」「職員研修完了」のように事前に決めます。
ベンダーロックインとBCPを契約前に確認します
ロックインを避けるには、データの所有者、標準形式でのエクスポート、APIやCSVの仕様開示、契約終了時のデータ返却、移行支援の料金を契約に入れます。独自コードや専用端末が増えるほど、将来の乗り換えが難しくなるため、標準マスタや一般的な連携方式を優先し、独自仕様は採用理由を記録します。
BCPでは、クラウドかオンプレミスかだけで判断しません。院内ネットワーク、端末、電源、認証、プリンター、資格確認、レセプト送信、バックアップのどこが止まると業務が止まるのかを洗い出します。復旧目標であるRTO、復旧時点目標であるRPO、代替入力、後日再入力、ベンダーの連絡体制をRFPとSLAに記載し、年に一度は復旧訓練を行える契約にします。
医事会計システムの発注・外注でよくある質問

医事会計システムの発注では、費用、導入期間、外注範囲、既存システムとの連携について同じ質問が寄せられます。ここでは、発注前に判断しやすいよう、特に確認が多い項目へ直接回答します。
医事会計システムの発注は何社に見積依頼すべきですか?
候補を2〜4社程度に絞り、同じRFPと質問票で依頼する方法が現実的です。候補数を増やしすぎると提案評価の負担が増えるため、施設規模や連携実績、導入後の保守体制で一次選定してから、最終候補を比較します。
医事会計システムはクラウドとオンプレミスのどちらがよいですか?
短期間で始めたい診療所や、院内サーバーの運用負担を抑えたい施設はクラウドが比較しやすいです。一方、既存設備や特殊な連携、院内ネットワークの制約、独自の運用要件が大きい場合はオンプレミスやハイブリッドが候補になります。どちらを選んでも、通信障害、バックアップ、復旧、データ返却を含むBCPを確認する必要があります。
医事会計システムの発注前に院内で準備する資料は何ですか?
現行業務フロー、利用者と権限、画面・帳票一覧、連携先一覧、端末・ネットワーク構成、過去データの種類と件数、希望稼働日、予算の上限、保守の連絡体制を準備します。加えて、返戻、未収金、算定漏れ、会計待ち時間など、改善したいKPIを決めておくと、提案の良し悪しを機能数ではなく業務効果で比較できます。
医事会計システムの発注・外注方法まとめ

医事会計システムを発注・外注するときは、製品の機能数や初期費用だけでなく、施設の業務、連携、移行、保守、BCPを一つの計画として比較します。小規模診療所は標準機能を活用して導入負担を抑え、中小病院や大病院は、入院・DPC・部門連携・経営分析まで含めた総額と体制を確認します。
発注成功につながる五つの確認を行います
第一に、現行業務と改善KPIを整理します。第二に、パッケージ・クラウド・個別開発の境界を決めます。第三に、RFPへ機能、連携、移行、セキュリティ、SLAを記載します。第四に、請負と準委任を工程ごとに使い分け、変更・検収・データ返却の条件を契約します。第五に、同じ前提の見積を総額と5年間の運用費で比較し、稼働後の責任者と評価方法を決めます。
最初の一歩は現場を含む要件整理です
発注前に、医事課だけでなく受付、診療部門、経理、情報システム、経営層が参加する小さな検討チームをつくり、現行フローと困りごとを一枚にまとめます。その資料をもとに複数の委託先へ相談し、提案内容、見積の除外項目、導入後の支援体制を確認すれば、安さだけに引っ張られず、自院で使い続けられる医事会計システムを選びやすくなります。
▼全体ガイドの記事
・医事会計システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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