医療SaaSのM&Aでは、ARRやプロダクト機能だけでなく、医療情報を扱う責任分界、3省2ガイドライン第2.0版、個人情報保護、BCP、買収後PMIまで一体で確認する必要があります。
本記事は、実在企業の個別M&A事例ではなく、医療SaaSの譲渡・買収で共通して問題になる制度・実務論点を整理した解説です。個別案件では、法務・税務・医療情報セキュリティの専門家確認が必要です。
医療SaaSのM&Aで評価軸が変わった理由
医療SaaSのM&Aは、一般的なSaaSの買収よりも確認すべき範囲が広い。ARR、MRR、解約率、粗利率、開発速度、カスタマーサクセス体制といったSaaS共通の指標だけでは、買収判断を支えきれない。医療機関、薬局、介護事業者、検査会社、医療機器メーカー、自治体、保険者などが関係し、患者情報や診療関連データに近い領域を扱うため、サービス停止、情報漏えい、委託先管理、本人同意、役割分担の不備がそのまま事業価値を毀損するからである。
2025年3月28日に経済産業省が公表した「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第2.0版」は、医療SaaSのM&A実務にも大きな影響を与えている。改定のポイントは、対象事業者の明確化、医療機関等との合意内容の明確化、リスクコミュニケーションの実効化である。これは単なるコンプライアンス資料ではなく、買い手が「このSaaSは買収後も医療現場に説明できるか」を判断するための実務フレームになりつつある。
本記事では、実在企業の個別M&A事例ではなく、医療SaaSの譲渡・買収を検討する際に共通して問題になる制度・実務論点を整理する。電子カルテそのもの、オンライン診療、予約、問診、検査連携、薬局向け業務支援、介護記録、医療機関向けCRM、医療データ分析、セキュリティ支援など、対象サービスの種類は異なっても、買い手が見るべき根本は共通している。つまり、医療情報をどの範囲で扱い、誰がどの責任を負い、障害やサイバー攻撃のときに何を説明できるかである。
直近の当サイトでは、SBOM・脆弱性管理SaaS、公共向けSaaS、監査ログ・証跡管理SaaSを扱った。今回はそれらと重ならない切り口として、医療SaaSのM&Aにおける3省2ガイドライン第2.0版、医療情報安全管理、要配慮個人情報、契約・SLA、BCP、PMIを中心に解説する。売り手にとっては譲渡準備の優先順位、買い手にとってはDDの質問設計と買収後100日の統合計画に使える内容を意識している。
3省2ガイドライン第2.0版は買収判断のどこに効くか
医療情報システムの安全管理に関する実務では、厚生労働省の医療機関向けガイドラインと、総務省・経済産業省のサービス提供事業者向けガイドラインが参照される。一般に3省2ガイドラインと呼ばれる領域であり、医療SaaSが医療機関等に提供される場合、売り手のサービス仕様、クラウド構成、委託先管理、契約書、説明資料、障害対応手順は、これらの考え方と整合している必要がある。
買収DDでは、ガイドラインに「準拠している」と書かれているかだけを確認しても十分ではない。第2.0版で特に意識すべきなのは、医療機関等との合意内容が具体的に説明されているか、対象事業者としての責任範囲が整理されているか、リスクコミュニケーションを継続する仕組みがあるかである。買い手は、売り手の営業資料だけでなく、SLA、サービス仕様適合開示書、障害報告テンプレート、セキュリティ質問票回答、委託先一覧、サポート履歴まで確認したい。
この論点は価格にも直結する。たとえば、機能は優れていてARRが伸びていても、医療機関との契約で責任分界が曖昧なまま運用されていれば、買収後に顧客説明や契約再整備のコストが発生する。障害時の通知期限、ログ保存期間、バックアップ、復旧目標、外部委託先の変更通知、データ消去、解約時のデータ返却、二次利用の可否が曖昧であれば、買い手は追加投資や表明保証、補償条項、価格調整を検討することになる。
一方で、売り手がこれらの資料を平時から整えている場合、医療SaaSの価値は上がりやすい。医療機関の稟議や監査に耐える説明ができるSaaSは、単なる便利ツールではなく、医療現場の業務基盤として扱われる。買い手にとっても、買収後に既存顧客へ横展開しやすく、セキュリティや法務の審査を通しやすい。医療SaaSのM&Aでは、売上の伸びと同じくらい「説明できる運用」が価値の源泉になる。
買い手が最初に確認すべき対象範囲
医療SaaSのDDで最初に行うべきことは、サービスが何を扱っているかを言語化することである。診療録、検査結果、画像、処方、予約、問診、決済、チャット、勤怠、在庫、患者向け通知、地域医療連携、介護記録、薬歴、オンライン資格確認周辺の情報など、医療と関係するデータは幅が広い。すべてを一律に危険視するのではなく、医療情報、要配慮個人情報、個人データ、匿名加工情報、統計情報、システムログのどれに当たるかを分けて確認する必要がある。
特に注意したいのは、売り手が「当社は医療情報を直接保存していない」と説明する場合である。直接保存していなくても、API連携で一時的に処理している、通知本文に診療関連情報が入る、ログに患者IDや予約内容が残る、サポート対応時に画面共有で閲覧する、バックアップやエラーログにデータが残るといったケースがある。医療SaaSのDDでは、データベース本体だけでなく、ログ、分析基盤、メール配信、問い合わせ管理、監視ツール、開発環境、バックアップを含めてデータフローを確認する。
対象範囲の整理が不十分だと、契約、セキュリティ、価格交渉、PMIのすべてが曖昧になる。買い手は、まずサービスごとのデータフロー図、システム構成図、委託先一覧、利用規約、医療機関との契約書、個人情報保護方針、サポート手順、ログ保存方針を入手し、どの情報がどこを通り、誰が閲覧でき、いつ削除されるのかを確認する。これは技術DDだけでなく、法務DDとビジネスDDの共通土台である。
売り手側は、M&Aを検討する前からこの整理を進めておくべきである。譲渡プロセスに入ってから慌ててデータフローを作ると、実運用との差分が出やすい。医療SaaSでは、買い手が求める資料の粒度が高く、回答の遅れがそのまま信頼低下につながる。逆に、利用データの範囲、医療機関との役割分担、委託先、アクセス権限、ログ保存、障害時対応を資料化していれば、初期打診からLOIまでのスピードが上がりやすい。
医療情報と要配慮個人情報のDD
医療SaaSのM&Aでは、個人情報保護法上の整理が重要になる。医療に関する情報は、病歴や診療内容など要配慮個人情報に該当し得る情報を含む。要配慮個人情報は、本人の差別や不利益につながるおそれがあるため、取得、利用、第三者提供、委託、共同利用、越境移転、研究利用、広告利用の判断を慎重に行う必要がある。買い手は、売り手が本人同意や利用目的の特定をどのように設計しているかを確認する。
ここで問題になるのは、SaaS事業者が医療機関の委託先として処理しているのか、事業者自身の目的でデータを利用しているのかである。委託先として処理するだけであれば、医療機関との契約や委託先管理の枠組みが中心になる。一方、サービス改善、AI学習、広告、統計分析、新規プロダクト開発、第三者提供に近い利用を行う場合は、利用目的、同意、匿名化、仮名加工、契約上の許容範囲をより厳密に確認しなければならない。
買い手は、プライバシーポリシーや利用規約だけで判断せず、実際のデータ利用ログと照合する必要がある。プロダクトチームが分析基盤でどの項目を見ているか、営業やCSが顧客別の患者数や診療科別データをどの範囲で閲覧しているか、問い合わせ対応で患者情報がチケットに転記されていないか、障害調査時に本番データが開発環境へコピーされていないか。こうした運用実態が、買収後のリスクを大きく左右する。
売り手は、個人情報保護方針を整えるだけでは足りない。アクセス権限の棚卸し、データ持ち出し制限、サポート時のマスキング、ログ閲覧の承認フロー、退職者アカウントの停止、委託先との契約、データ削除証跡を準備しておくとよい。買い手から見れば、医療情報を扱うSaaSで一番怖いのは、悪意ある不正よりも、日常運用の曖昧さである。小さな曖昧さが買収後に顧客説明コストとなって現れる。
契約・SLA・責任分界の読み方
医療SaaSの買収DDでは、顧客契約の読み込みが欠かせない。一般的なSaaS契約では、利用規約、申込書、SLA、サポートポリシー、データ処理条項、秘密保持条項、反社会的勢力排除条項、知的財産権、解約条項などを確認する。医療SaaSではこれに加え、医療機関等との責任分界、障害時通知、セキュリティ事故時の報告、バックアップ、データ返却、委託先管理、監査協力、保守時間、計画停止、事業譲渡時の扱いを重点的に見る。
買い手が注意すべきなのは、契約書の文言と営業現場の説明が一致しているかである。契約書ではベストエフォートのサポートにしているのに、営業資料では24時間365日の安心運用と表現している。利用規約ではデータ返却を限定しているのに、実務では顧客ごとに個別対応している。SLAに稼働率を明記していないのに、大口顧客とのメールでは復旧目標を約束している。こうした非公式な約束は、買収後に予想外の引継ぎ負担になる。
第2.0版ガイドラインで強調される合意内容の明確化は、M&Aでは顧客継続性の評価に直結する。医療機関は、患者サービスを止めないために、ベンダーの変更や買収に敏感である。買い手は、チェンジオブコントロール条項、解約権、再委託制限、クラウドリージョン、サポート窓口、セキュリティ監査権限、通知義務を確認し、買収後に顧客説明が必要な契約を分類する必要がある。
売り手側の譲渡準備では、契約一覧を単なる売上台帳としてではなく、リスク台帳として整えることが重要である。標準契約、個別契約、覚書、見積条件、営業資料、サポート合意、セキュリティ質問票回答を顧客ごとに紐づける。医療SaaSの価値は、契約が標準化され、例外が少なく、例外があっても理由と対応方針が明確であるほど高く評価されやすい。
サイバーセキュリティとBCPは価格調整の対象になる
医療機関等におけるサイバーセキュリティ対策は、厚生労働省の医療情報システム安全管理ガイドラインや令和7年5月のチェックリストでも重視されている。医療SaaSのM&Aでは、買い手はSOC2やISMSの有無だけでなく、実際の運用証跡を見る必要がある。脆弱性診断、ペネトレーションテスト、パッチ管理、監視、インシデント対応訓練、バックアップ復旧テスト、管理者権限の棚卸し、委託先の監査結果が確認対象になる。
セキュリティDDで重要なのは、脆弱性がゼロかどうかではなく、見つけ、優先順位を付け、修正し、顧客へ説明する仕組みがあるかである。医療SaaSは、現場業務に入り込むほど停止時の影響が大きい。買い手は、復旧目標時間、復旧目標時点、バックアップの保管場所、復旧手順のテスト頻度、ランサムウェアを想定した隔離バックアップ、クラウドアカウントの権限管理、障害時の顧客通知フローを確認する。
BCPは買収価格にも影響する。たとえば、データベースのバックアップは取っているが復旧演習を行っていない、障害通知テンプレートがない、医療機関向けの説明責任者が決まっていない、外部委託先の障害時に誰が顧客へ通知するか不明である。このような状態では、買い手は買収後にセキュリティ投資や体制再構築を見込むため、価格調整やクロージング条件、表明保証でリスクを織り込むことになる。
売り手が評価を高めるには、セキュリティ施策を「やっている」と説明するのではなく、証跡で示すことが有効である。診断報告書、是正管理表、アカウント棚卸し記録、インシデント対応訓練の議事録、復旧テスト結果、委託先管理表、脆弱性対応SLA、顧客向けセキュリティ資料を準備する。特に医療SaaSでは、セキュリティ資料の整備が営業力にもM&A価値にも効く。
プロダクトDDで見るべき技術資産
医療SaaSのプロダクトDDでは、コード品質やインフラ構成だけでなく、医療現場の業務プロセスに対する理解が実装に反映されているかを見る。予約や問診であれば、患者導線、診療科、初診再診、保険証確認、キャンセル、リマインド、代理入力、受付業務との接続が論点になる。薬局向けであれば、薬歴、服薬指導、在庫、電子処方箋周辺の運用、レセコン連携が論点になる。介護記録であれば、介護報酬、職員権限、多職種連携、家族共有が論点になる。
買い手は、ソースコードの綺麗さだけでなく、変更容易性を評価する。医療制度や診療報酬、行政手続、個人情報保護、セキュリティ要件は変わる。設定で変えられる項目と、コード改修が必要な項目を分ける。顧客ごとの個別カスタマイズがどれだけ存在するか、標準プロダクトに戻せるか、API連携が顧客別に分岐していないか、テストが医療業務の例外をカバーしているかを確認する。
技術負債は、医療SaaSでは単なる開発効率の問題ではない。権限設計が粗ければ個人情報リスクになる。ログが不十分なら障害や問い合わせに説明できない。設定変更の履歴が残らなければ医療機関の監査に耐えにくい。テナント分離が弱ければ重大事故になり得る。買い手は、アーキテクチャレビューで、可用性、機密性、完全性、追跡可能性、設定管理、監査ログを重点的に見るべきである。
売り手は、プロダクトDDに備えて、システム構成図、データモデル、API一覧、権限設計、監査ログ仕様、障害履歴、技術負債リスト、ロードマップ、セキュリティバックログ、主要な設計判断の経緯を整理しておく。医療SaaSでは、コードを見せる前に、なぜその設計にしたのかを説明できることが信頼につながる。買い手が不安に感じるのは、古い技術そのものではなく、判断の根拠が残っていないことである。
売上品質と顧客継続性の評価
医療SaaSの売上品質は、一般的なSaaSと同じくARR、MRR、NRR、チャーン、ARPA、粗利率、CAC、LTV、回収期間で評価される。ただし、医療分野では導入サイクルが長く、現場定着まで時間がかかり、解約の意思決定も複数部門にまたがることが多い。そのため、単純な月次数字だけでなく、導入後の利用率、部門別利用状況、問い合わせ傾向、トレーニング実績、現場リーダーの関与度を見る必要がある。
買い手は、医療機関の契約主体を確認する。法人本部契約なのか、施設単位契約なのか、診療科単位なのか、院内のどの部門が予算を持っているのか。これにより、買収後のアップセル余地と解約リスクが変わる。大口顧客が少数に偏っている場合、売上は大きく見えても、契約更新時のセキュリティ審査や価格交渉で一気にリスクが顕在化する可能性がある。
医療SaaSでは、顧客の利用停止がすぐに解約として表れないこともある。現場では使われなくなっているが、契約は残っている。担当者が変わり、操作習熟が落ちている。連携先システムの更新で一部機能が止まっている。こうした「静かなチャーン」を見逃すと、買収後にNRRが急に下がる。買い手は、ログイン頻度、主要機能の利用率、サポート問い合わせ、研修参加、ヘルススコアを顧客別に確認する。
売り手は、医療機関向けのカスタマーサクセスを資料化しておくべきである。導入プロセス、院内説明資料、操作マニュアル、障害時連絡先、定例会議、利用促進施策、更新前レビュー、セキュリティ質問票対応を整理する。医療SaaSの買い手は、プロダクト単体ではなく、現場定着を支える運用力を買う。CS体制が属人的であれば、買収後の継続性に疑問が残る。
医療機関とのリスクコミュニケーション
第2.0版ガイドラインの文脈で重要になるのが、リスクコミュニケーションである。医療SaaS事業者は、医療機関等に対して、サービス仕様、リスク、役割分担、残存リスク、対応策を説明し、合意形成を進める必要がある。M&Aでは、買い手がこの説明責任を引き継げるかが重要になる。買収後に会社名、サポート体制、委託先、インフラ、開発方針が変わる場合、顧客説明が必要になることがある。
買い手は、売り手がこれまでどのような説明資料を使ってきたかを確認する。セキュリティホワイトペーパー、サービス仕様適合開示書、SLA、FAQ、障害報告書、監査対応資料、契約更新時の説明資料が整っているか。顧客からのセキュリティ質問票に誰が回答し、回答内容が最新化されているか。過去の回答と現在の運用に差分がないか。これらは買収後の顧客維持に直結する。
リスクコミュニケーションが弱いSaaSは、プロダクトの品質が高くても、医療機関の稟議で止まりやすい。逆に、完璧ではなくても、リスクと対応策を正直に説明し、改善ロードマップを示せる事業者は信頼されやすい。M&Aの売り手にとって、説明資料の整備は単なる事務作業ではない。買い手に対して、事業を引き継げる状態にしていることを示す価値証明になる。
買い手は、クロージング前後のコミュニケーション計画をDD段階で作るべきである。どの顧客にいつ通知するか、通知が必要ない顧客はどこか、契約上の事前承諾が必要な顧客はどこか、セキュリティ質問票の再提出が必要な顧客はどこか、FAQで説明する項目は何か。医療SaaSでは、買収そのものよりも、買収後の説明不足が解約や稟議停滞の原因になりやすい。
医療SaaSの譲渡・買収を検討している方へ
SaaS業界M&A総合センターでは、売り手手数料0円で、SaaS事業の譲渡可能性、買い手候補、DD準備、PMI論点を整理します。医療情報や個人情報を扱うSaaSでも、初期段階から匿名性に配慮して相談できます。
AI・データ分析機能を持つ医療SaaSの注意点
医療SaaSの中には、AIやデータ分析を組み込むものが増えている。問診内容の要約、予約枠の最適化、診療支援、患者コミュニケーション、画像解析、レポート作成、経営分析、離脱予測など、利用場面は広い。買い手は、AI機能が医療行為に関わる判断をどの程度支援しているか、医療機器プログラム該当性や表示表現のリスクがないか、学習データの権利と同意が整理されているかを確認する必要がある。
AI機能がある場合、データの二次利用が特に問題になる。医療機関から預かった情報をモデル改善に使っているのか、使っているなら契約上許容されているのか、本人同意や匿名化はどう設計されているのか、学習済みモデルから個人情報が再識別されるリスクをどう評価しているのか。生成AIを外部APIで利用している場合、プロンプトに患者情報が入っていないか、送信先と保存ポリシーはどうなっているかも確認する。
買い手は、AI機能を成長余地として評価する一方で、説明責任の負債を見落としてはいけない。医療現場では、なぜその提案が出たのか、誤った出力が出た場合に誰が責任を負うのか、医療従事者が最終判断する設計になっているかが問われる。AI機能の利用ログ、プロンプト管理、モデル更新履歴、検証データ、精度評価、誤出力時の対応手順を確認することが重要である。
売り手は、AI機能を過度に大きく見せるよりも、適用範囲と限界を明確にしたほうが評価されやすい。医療SaaSの買い手は、夢のある説明よりも、現場で安全に使える説明を求める。AI機能がある場合は、利用目的、データ処理、外部サービス利用、医療従事者の確認、監査ログ、顧客向け説明文を整理しておきたい。AIは価値にもなるが、説明できなければDDで止まりやすい。
事業譲渡・株式譲渡で変わる論点
医療SaaSのM&Aでは、株式譲渡か事業譲渡かによって、契約やデータの扱いが変わる。株式譲渡では契約主体が変わらないことが多いが、支配権変更条項や顧客通知義務が問題になることがある。事業譲渡では、契約移転、データ移管、委託先変更、利用規約の再同意、個人情報の移転、従業員や開発者の引継ぎがより前面に出る。買い手は、スキーム選択の段階で医療機関との契約条件を確認すべきである。
事業譲渡で特に難しいのは、顧客契約とデータ移管のタイミングである。医療機関の承諾が必要な契約が多い場合、クロージングまでにすべての承諾を取得できるとは限らない。データ移管を伴う場合、移管方法、暗号化、検証、旧環境の削除、移管後の責任分界、顧客通知を具体化する必要がある。医療SaaSでは、形式的な契約移転だけでなく、現場が翌日も使える状態を保つことが重要である。
株式譲渡でも安心はできない。買収後にクラウド基盤を統合する、サポート窓口を変える、委託先を変更する、開発チームを再編する、料金体系を変える場合は、医療機関への説明が必要になることがある。買い手は、クロージング後の変更予定をDD段階で棚卸しし、契約やガイドライン上の説明義務と照合する。PMI計画と法務DDを切り離してはいけない。
売り手は、スキームごとの制約を早めに把握しておくと交渉が進めやすい。顧客承諾が必要な契約、通知で足りる契約、標準規約で移転可能な契約、個別覚書で制限される契約を分類する。医療SaaSでは、買い手候補がどれだけ魅力的でも、顧客承諾の実務が読めなければ条件が固まりにくい。契約台帳の整備は、譲渡価格を守るための準備でもある。
PMIで最初の100日にやるべきこと
医療SaaSのPMIでは、最初の100日で顧客の不安を抑え、説明責任を引き継ぎ、セキュリティと運用を安定させることが重要である。買収後すぐに機能統合やブランド変更を急ぐより、まず顧客契約、サポート、障害対応、セキュリティ資料、データ管理、開発リリースの責任者を明確にする。医療機関にとって重要なのは、買収によりサービス品質や説明窓口が不安定にならないことである。
Day 1からDay 10では、緊急連絡網、顧客通知方針、インシデント対応責任者、サポート窓口、管理者権限、決裁権限を整理する。医療SaaSでは、管理者アカウントやクラウド権限の引継ぎが曖昧なまま進むと重大なリスクになる。買い手は、売り手の主要メンバーが一定期間残る契約を設計し、障害対応や大口顧客対応の知識を確実に移す必要がある。
Day 11からDay 30では、契約・セキュリティ・データの棚卸しを進める。顧客ごとの例外契約、セキュリティ質問票回答、SLA、個人情報関連条項、委託先、障害履歴、復旧テスト結果を統合管理する。買い手の既存セキュリティ基準と売り手の運用に差分がある場合、すぐにすべてを統一するのではなく、医療機関への影響とリスクの大きさで優先順位を付ける。
Day 31からDay 60では、顧客説明と改善ロードマップを固める。大口顧客やセキュリティ審査が厳しい医療機関には、買収の目的、サービス継続、サポート体制、データ取扱い、セキュリティ改善計画を説明する。ここで曖昧な回答をすると、更新時に不信感が残る。医療SaaSのPMIでは、顧客説明資料を法務、セキュリティ、CS、営業が共同で作成することが望ましい。
Day 61からDay 100では、プロダクト統合やクロスセルを検討する。ただし、医療SaaSでは拙速な統合が障害や説明不足を生みやすい。データ連携、認証統合、請求統合、ブランド変更、サポート移管は、顧客影響を評価したうえで段階的に進める。PMIの成功は、買収後すぐに大きな変更を出すことではなく、医療現場に安心して使い続けてもらえる状態を作ることである。
売り手が譲渡前に整えるべき資料
医療SaaSの売り手が譲渡を検討するなら、まず財務資料だけでなく、医療情報とセキュリティに関する資料を整えるべきである。具体的には、顧客契約一覧、個別契約差分、SLA、サービス仕様適合開示書、プライバシーポリシー、データフロー図、システム構成図、委託先一覧、セキュリティ対策一覧、障害履歴、インシデント対応手順、バックアップ復旧テスト結果、権限棚卸し記録を準備する。
これらの資料は、買い手のDDを早めるだけでなく、売り手自身の事業改善にも役立つ。資料を作る過程で、契約例外、委託先の未更新契約、古いセキュリティ回答、不要な管理者権限、ログ保存期間の不統一、バックアップ復旧テストの不足が見つかることがある。M&Aの前に是正できるものは是正し、すぐに是正できないものは改善計画として提示することで、買い手の不安を下げられる。
財務面では、医療機関ごとの売上、契約期間、更新月、解約通知期限、導入費、月額費、オプション、カスタマイズ収入、サポート工数、粗利、未請求作業を整理する。医療SaaSでは、個別対応の多さが利益率を圧迫することがある。買い手は、ARRの大きさだけでなく、そのARRを維持するためにどれだけの専門対応が必要かを見る。CSや導入支援の工数が見える資料は、評価の透明性を高める。
人材面では、医療業務を理解するメンバー、セキュリティ責任者、インフラ担当、主要顧客を知るCS、契約交渉を担った営業の関与期間を整理する。医療SaaSは、ドメイン知識の属人性が高くなりやすい。創業者や特定メンバーが抜けると顧客説明が弱くなる場合、買い手はアーンアウトや引継ぎ期間を条件に入れる可能性がある。譲渡前にナレッジを文書化しておくことが重要である。
買い手が質問すべきDD項目
買い手は、医療SaaSのDDで質問票を一般的なSaaS用のまま流用しないほうがよい。医療情報を扱う範囲、医療機関との責任分界、3省2ガイドラインへの対応、要配慮個人情報、セキュリティ、BCP、委託先、顧客説明、PMIを独立した論点として設計する必要がある。質問票が浅いと、売り手の回答も抽象的になり、買収後の問題を見逃す。
データ関連では、どのデータ項目を保存、処理、転送、ログ化しているか。患者を識別できる情報がどの環境に存在するか。開発環境や分析基盤に本番データが入っていないか。データ削除依頼にどう対応しているか。バックアップからの削除方針はどうなっているか。AIや分析機能にデータを二次利用していないか。これらを具体的に確認する。
契約関連では、医療機関との標準契約と例外契約、支配権変更条項、再委託制限、事業譲渡時の承諾要否、障害通知、SLA、データ返却、解約時の協力義務、監査権限、個人情報条項を確認する。医療SaaSでは、契約書以外の営業資料やメールで実質的な約束がなされていることもあるため、過去のセキュリティ質問票回答と顧客向け説明資料も見るべきである。
セキュリティ関連では、認証、権限、ログ、暗号化、脆弱性管理、インシデント対応、バックアップ、復旧演習、委託先管理、監視、開発プロセス、秘密情報の管理を確認する。医療SaaSで重要なのは、対策の有無だけでなく、証跡の有無である。買い手は、運用記録があるか、誰が責任を負うか、顧客に説明できる粒度かを見なければならない。
PMI関連では、買収後に何を変える予定か、変えることで顧客説明が必要になるか、主要顧客に誰が説明するか、売り手の主要メンバーがどれだけ残るかを確認する。DDは、過去を調べる作業であると同時に、買収後の失敗を防ぐ設計作業でもある。医療SaaSでは、クロージング後の100日を想定したDDこそが実務的である。
価格交渉と表明保証で押さえるポイント
医療SaaSの価格交渉では、売上倍率だけでなく、医療情報に関するリスクが条件に反映される。契約例外が多い、セキュリティ証跡が弱い、バックアップ復旧テストがない、個人情報の利用目的が曖昧、AI学習データの権利が不明、委託先契約が古い、顧客説明資料が不足している場合、買い手は買収価格の調整、エスクロー、補償、クロージング条件、買収後改善費用の控除を検討する。
表明保証では、法令遵守、個人情報保護、契約違反不存在、知的財産権、第三者権利侵害、セキュリティインシデント、障害履歴、データ利用、委託先管理、未開示の顧客クレーム、行政対応の有無が論点になる。医療SaaSでは、過去に重大インシデントがないことだけでなく、軽微な障害や顧客からの懸念への対応履歴も確認されやすい。
売り手は、リスクを隠すよりも、把握して改善計画を出すほうがよい。買い手が最も嫌うのは、問題そのものよりも、問題の存在を経営陣が把握していない状態である。医療SaaSでは、課題がゼロであることはほとんどない。重要なのは、課題が台帳化され、優先順位が付き、責任者と期限があり、顧客影響を説明できることである。
買い手は、リスクを理由に単純に価格を下げるだけでなく、買収後に価値を高める投資計画も作るべきである。セキュリティ資料の整備、SLAの標準化、契約更新時の条項統一、顧客ヘルススコアの導入、バックアップ復旧演習、権限管理の強化、AIデータ利用の見直しは、リスク低減であると同時にアップセルや大口顧客開拓の基盤になる。
まとめ：医療SaaSのM&Aは説明できる運用を買う取引
医療SaaSのM&Aでは、買い手は機能、売上、成長率だけを見てはいけない。3省2ガイドライン第2.0版、医療情報システム安全管理、個人情報保護、契約・SLA、セキュリティ、BCP、リスクコミュニケーション、PMIを一体で確認する必要がある。医療現場に入り込んだSaaSほど、買収後に説明できる運用が価値の中心になる。
売り手にとって重要なのは、M&Aの直前に見栄えのよい資料を作ることではない。日常運用の証跡を残し、顧客との合意内容を整理し、データフローを把握し、契約例外を台帳化し、セキュリティとBCPの改善計画を持つことである。これらは譲渡価格を守るだけでなく、医療機関から選ばれ続けるための経営基盤にもなる。
買い手にとって重要なのは、DDを欠点探しで終わらせないことである。医療SaaSのリスクを正しく見極め、買収後100日のPMI計画に落とし込み、顧客説明、契約整備、セキュリティ改善、プロダクト統合を段階的に進める。そうすれば、医療SaaSのM&Aは単なるARRの取得ではなく、医療現場に信頼される業務基盤を拡張する取引になる。
内部リンク：あわせて読みたいSaaS M&A記事
- SBOM・脆弱性管理SaaSのM&A｜SCS評価制度時代のDD・PMIと買収判断
- 自治体・公共向けSaaSのM&A｜ガバメントクラウド・ISMAP・個人情報DDの実務
- 【SaaS M&Aモデル事例】監査ログ・証跡管理SaaSの譲渡検討と買収後PMIの進め方
- 【SaaS M&Aコラム】個人情報とデータ移行とは？譲渡・買収前に確認したい実務ポイント
- 【SaaS M&Aコラム】デューデリジェンス準備とは？譲渡・買収前に確認したい実務ポイント
- 【SaaS M&Aコラム】PMIで失敗しない準備とは？譲渡・買収前に確認したい実務ポイント
