医療機器M&AのサイバーセキュリティDD完全ガイド｜SBOM・脆弱性・保守終了を検証

1．医療機器M&AのサイバーセキュリティDDを一般IT監査から分ける

守る対象を患者安全と意図する性能から逆算する

一般的な企業IT監査では、メール、会計、端末、認証基盤の機密性・完全性・可用性が中心です。医療機器では、通信遅延によりアラームが届かない、偽データで治療判断を誤る、更新失敗で装置が停止する、設定改変で意図する性能を外れるといった臨床上の結果まで因果を伸ばします。同じ脆弱性識別子でも、隔離された教育用端末と、集中治療室で複数患者を監視する製品では優先度が異なります。

調査票には資産価値や情報漏えい件数だけでなく、想定使用場所、接続相手、操作者、患者接触、代替手段、停止可能時間、危害の重大度を記載します。サイバーリスクを技術的な攻撃成功率だけで採点せず、安全リスクマネジメント、ユーザビリティ、保守運用の記録と同じ製品識別子で結びます。

企業ネットワークと製品ネットワークの境目を可視化する

開発用Git、ビルドサーバー、署名鍵、アップデート配信基盤は社内ITに見えても、製品の真正性を支える資産です。逆に、病院の電子カルテや無線LANは譲渡企業の所有物でなくても、製品が依存する外部環境です。所有権だけでスコープを切ると、攻撃経路や復旧責任が落ちます。対象一覧には、所有者、運用者、契約者、データ管理者、障害連絡先を別列で持たせます。

医療機器M&AのサイバーセキュリティDDでは、製品そのもの、付属PC、スマートフォンアプリ、ブラウザ管理画面、クラウドAPI、遠隔保守VPN、ログ収集、証明書発行、ソフトウェア供給網までを一枚の構成図へ置きます。図に現れない経路は試験対象にも契約対象にもなりにくいため、販売・設置・保守・苦情対応の担当者への聞き取りで補完します。

脆弱性の数ではなく管理能力と残存債務を評価する

公開CVEがゼロでも、依存部品の版を把握していなければ安全とは言えません。一方、脆弱性が複数あっても、影響判定、臨床リスク評価、修正版、緩和策、顧客通知、規制報告の記録が揃い、期限内に閉じていれば管理能力を評価できます。件数比較は検出力の差を逆に罰することがあるため、受付から終了までのリードタイムと未処理理由を見ます。

買収価値への反映では、発見済み問題の改修費だけでなく、未把握製品の調査、人員採用、コード署名再構築、クラウド契約移管、EOL機器の交換支援、顧客へのフィールド対応を見積もります。これらは一時的なDD調整と、毎年必要になる製品セキュリティ運営費へ分けます。

2．医療機器M&AのサイバーセキュリティDDで日本の公式要件を取引判断へ翻訳する

基本要件基準第12条第3項の適用範囲を品目別に確認する

厚生労働省の適用通知は、プログラムを用い、他の機器やネットワーク等と接続して電磁的情報をやり取りする医療機器を説明し、使用環境に応じた要件特定、危険性の特定・評価、リスク低減管理、検証を求める考え方を示しています。経過措置の期間だけを切り取らず、現在販売する版と変更履歴を品目ごとに確認します。

譲渡企業の一覧に『該当・非該当』だけを書かせず、接続先、外部媒体、保守経路、判断根拠、参照規格、適合を示す資料、承認・認証・届出との関係を記載させます。買い手側は通知の文言を機械的なチェック欄にせず、実際の動作環境と試験証拠が一致するかを技術・薬事・品質の三者でレビューします。

PMDAの通知集を時系列で読み、後発文書を落とさない

PMDAの医療機器サイバーセキュリティ案内ページには、基本要件の適用、導入手引書、医療機関向け手引書、適合性確認、Q&A、不具合等報告の考え方、脆弱性管理等の通知がまとまっています。DD基準日は一覧ページと個別文書の更新日を記録し、社内手順書がどの版へ追随しているかを照合します。

公式資料が示すのは製造販売業者等が満たすべき枠組みであり、株価調整率や買収可否を直接決めるものではありません。M&Aチームは、要求に対応する証拠が欠ける場合の追加作業、販売継続への影響、顧客説明、当局相談の要否を専門家と整理し、経営判断へ変換します。

IMDRF・IPA・FDAは比較材料として位置付ける

IMDRF N60は全製品ライフサイクル、N70はレガシー機器、N73はSBOMの原則を扱います。IPAの手引きはSBOM導入・作成・共有・運用を組織実務へ落とす参考になります。FDAの2026年ガイダンスは米国での市販前提出と品質システムの考慮事項を示すため、米国対象製品では直接的な調査資料になり、日本専売品では成熟度比較の物差しとして使えます。

外国文書の要求を日本法上の義務だと言い換えたり、任意ガイダンスを契約上の保証へ無条件に取り込んだりしません。販売国、申請経路、契約上の準拠基準を特定し、『法的に必要』『当局が推奨』『業界の良好事例』『買い手の統合標準』を別欄にします。

3．買収対象の製品・版・接続・拠点を一つの境界表へする

製品マスターを財務売上から逆引きする

薬事部門の品目一覧だけでは、旧版、保守専用品、海外仕様、販売終了品、OEM供給品が漏れることがあります。売上明細、保守契約、クラウド契約、苦情台帳、アップデート配信、コールセンター分類、部品在庫から製品名を逆引きし、同一製品の販売名・社内コード・UDI・モデル・ソフトウェア版を対応させます。

無償提供や研究用途でも、顧客環境へ残り遠隔接続できる機器は調査対象になり得ます。過去三年の売上がゼロという理由だけで除外せず、設置台数、サポート義務、残存保証、修正配布能力、患者への影響を確認します。境界確定日以後の新リリースは、差分台帳へ追加します。

構成標準と個別導入差分を二層で持つ

設計文書上の標準構成が安全でも、現場では病院指定ウイルス対策ソフト、プロキシ、古いブラウザ、共有端末、追加インターフェース、メーカー外のリモート接続が使われることがあります。代表顧客だけのヒアリングで一般化せず、導入記録と保守ログから差分パターンを抽出します。

構成管理では製品BOM、SBOM、ネットワーク図、データフロー、クラウドリージョン、証明書、アカウント、外部サービスを同じリリース番号へ結びます。実態不明な施設は『標準と同じ』ではなく『未確認』として残し、開示制約のある顧客名は匿名IDで管理します。

カーブアウトでは共有基盤の分離可能性を先に試す

事業譲渡や会社分割で一部製品だけを取得する場合、署名鍵、ビルド環境、脆弱性管理システム、顧客ポータル、監視基盤、ドメイン、証明書、ソースコード管理が譲渡企業の他事業と共有されていることがあります。契約上『移管』と書けても、秘密鍵や履歴を安全に分離できるとは限りません。

分離テストでは、買い手環境で再現ビルドし、新しい鍵で署名し、試験端末へ配布し、失敗時にロールバックし、ログを保存する一連の流れを確認します。完了しない項目は移行サービス契約の期間、アクセス権、費用、終了条件へ落とします。

4．文書の有無ではなく証拠の連鎖を再構成する

要求から試験結果まで双方向に追跡する

セキュリティ要求、脅威モデル、リスク分析、設計対策、検証仕様、試験結果、残留リスク、ラベリングを一方向に並べるだけでは、変更時の抜けを見つけにくくなります。代表的な危険シナリオを選び、要求から結果へ、結果から要求へ逆向きにも辿り、版と承認者が一致するかを確認します。

文書がPDFで存在しても、試験対象ビルド、設定、ツール版、例外、失敗ログ、再試験が示されなければ証拠強度は限定的です。DDワークペーパーにはファイル名でなく保管場所、ハッシュまたは文書番号、承認日、対象版、閲覧者、結論、未解決点を記録します。

経営会議と品質会議の意思決定を接続する

重大な脆弱性を技術部門が把握しても、販売停止、顧客通知、フィールド修正、当局報告へ進む権限が曖昧なら対応が遅れます。過去案件を一つ選び、検出時刻から受付、技術評価、臨床評価、品質判断、経営承認、顧客連絡、終了判定までの記録を時系列にします。

議事録に『対応済み』とあるだけでは足りません。誰がどのリスクを受容し、代替策の期限を決め、残る患者影響を説明したかを確認します。責任者が退職している場合は、後任が再現できる根拠と権限移譲の状況も調べます。

不存在資料を即座に違反と決めつけない

製品の年代、一般的名称、申請時期、変更、接続性、販売国により期待される資料は異なります。現在のテンプレートが旧製品にないことだけで法令違反と結論づけず、当時の要求、代替記録、後年のリスク再評価、現在の販売・保守状態を確認します。

一方で『古い製品だから不要』という説明も検証なしに受け入れません。現役設置台数、患者への依存、修正可能性、公開脆弱性、医療機関へ提供した情報を把握し、必要なら薬事・品質・セキュリティの専門家が追加評価します。

5．SBOMを納品ファイルではなく運用能力として検証する

SBOMの対象版と製品BOMを一致させる

SBOMファイルを一つ受け取っても、買収対象のどのモデル、地域、リリース、ビルドへ対応するか分からなければ照合できません。製品マスター、リリースノート、ビルド成果物、コンテナイメージ、ファームウェア、付属PCの構成を使い、SBOMの自己要素と対象版を確認します。

自動スキャンで見える依存だけでなく、手動導入ライブラリ、静的リンク、OSパッケージ、ドライバ、ブラウザ部品、クラウドのマネージドサービス、納入先で追加されるソフトウェアを区別します。対象外は空白にせず、検出方法と除外理由を残します。

作成・照合・判断・共有の四工程を実演する

担当者へ最新SBOMの提示だけを求めると、買収前に一度だけ生成したファイルでも合格してしまいます。任意のリリースを指定し、ソースまたは成果物から生成し、既知脆弱性情報と照合し、製品への到達可能性や危害を評価し、所定の相手へ共有するまでを観察します。

医療機器M&AのサイバーセキュリティDDでは、処理時間、手作業、失敗箇所、例外権限、レビュー担当、版管理を記録します。自動化率が低くても対象が少なく統制できている場合と、ツール導入済みでもアラートが放置される場合を分けて評価します。

第三者へ渡せるSBOMかを契約面から確かめる

部品情報には供給者との秘密保持、再配布制限、輸出管理、セキュリティ上の配慮が関係する場合があります。医療機関が調達・運用のために必要とする情報、規制当局へ示す情報、研究者へ開示する情報を同じ公開レベルにしません。

買収後に買い手名義で顧客へ提供できるか、OEM元から受領した構成を再共有できるか、譲渡企業のポータルをいつまで使えるかを確認します。必要な同意や契約改定がクロージング後になる場合は、暫定配布手段と問い合わせ窓口を決めます。

6．脆弱性の受付から終了判定まで一件を通しで追う

情報源ごとの入口と重複排除を調べる

脆弱性は公開データベース、部品供給者、セキュリティ研究者、医療機関、保守員、社内試験、苦情、不具合報告から入ります。メール一箱だけで受けると休暇・退職・迷惑メール判定で止まるため、受付窓口、当番、緊急連絡、チケット化、重複統合、受領連絡を確認します。

研究者向け方針がある場合は、安全な連絡方法、対象、期待する情報、法的威嚇を避けた協調、公開調整の考え方が実運用と一致するかを見ます。方針がなくても直ちに不適合と決めず、過去の外部申告をどう扱ったかで能力を測ります。

技術スコアと臨床リスクを別々に記録する

CVSS等の技術スコアは入口になりますが、患者危害の結論そのものではありません。攻撃に必要なアクセス、認証、既定設定、到達可能性、検出可能性、機能への影響、利用環境、代替手段を評価し、医療従事者が取る緩和策による新たなリスクも確認します。

技術部門だけで『悪用困難』と閉じず、安全管理、臨床、品質、薬事が関与する条件を手順化します。結論が変わった場合は、初回評価を上書きせず、追加情報、再評価日、承認者、顧客への影響を履歴として残します。

未解決案件を年齢ではなく理由で分類する

長期間開いている案件には、修正開発中、供給者回答待ち、影響なし確認中、顧客環境でのみ再現、次期版へ統合、EOL製品で補完策のみなど異なる状態があります。単純な件数や平均日数では、重大案件の停滞と合理的な監視を区別できません。

未解決一覧には患者影響、設置台数、最古受付日、次の判断日、阻害要因、責任者、暫定策、顧客通知、規制評価を置きます。買収契約では一覧の完全性を表明させるだけでなく、重大案件の閉鎖条件と費用負担を個別に扱います。

7．試験報告書の範囲・再現性・修正確認を読む

脅威モデルと試験項目の対応を確かめる

侵入テスト報告書に多数の項目があっても、製品固有の資産、信頼境界、攻撃者、誤用、更新経路を前提にしていなければ重要経路が漏れます。脅威モデルの各シナリオが設計対策と試験ケースへ対応し、対象外とした理由が承認されているかを確認します。

通信暗号、認証、権限、秘密情報、入力処理、ログ、更新、ロールバック、物理ポート、デバッグ機能、可用性、復旧を製品特性に合わせます。スキャナ結果だけでなく、手動検証、アーキテクチャレビュー、コード解析、ファジング等を採用した理由を読みます。

第三者試験の独立性より前提条件を検証する

外部会社のロゴがあるだけで試験品質は保証されません。対象版、設定、認証情報、期間、人数、手法、除外範囲、制約、発見事項の再現手順、証拠、重大度基準を確認します。試験後に製品が更新されていれば、差分が結果へ与える影響を評価します。

譲渡企業が重大事項を『受容』した場合は、受容権限、臨床的根拠、補完策、期限、再評価契機を確認します。修正済みなら、元の試験者または別担当による再試験と、修正が別機能を壊していないことの回帰試験を見ます。

本番環境を壊さない検証手順を合意する

DDで実機試験を急ぐと、病院稼働中の装置、患者データ、クラウドサービスへ影響を与えるおそれがあります。検証環境、合成データ、許可された時間、停止条件、ログ保全、緊急連絡、成果物の取扱いを定め、無断スキャンを避けます。

再現環境がないこと自体が統合リスクです。買い手がクロージング後に安全な試験を行えるよう、テスト機、ライセンス、匿名化データ、模擬接続先、ビルド手順、担当者支援を引渡対象または移行支援へ含めます。

8．更新・署名・配布・ロールバックを一本の供給鎖として試す

署名鍵と証明書の所有・保管・交代を確認する

コード署名鍵が個人端末、外部委託先、共有USB、譲渡企業親会社のHSMにあると、買収後の更新が止まるか真正性が損なわれます。鍵を閲覧する必要はなく、生成、保管、利用承認、監査ログ、バックアップ、失効、証明書更新、事故時ローテーションを証拠で確認します。

株式譲渡でも管理者やドメインが変わればアクセスを再設計します。事業譲渡では新しい署名系へ切り替えた更新を既存装置が受け入れるか、信頼チェーンをどう移行するかを実機で確認し、旧鍵の失効時期と緊急修正版の配布能力を両立させます。

配布経路ごとの成功率と取り残しを測る

自動更新、医療機関管理者による承認、保守員の現地作業、USB媒体、装置交換では到達率と所要時間が異なります。インターネット非接続施設、長期休止装置、貸出機、在宅利用者、海外代理店の旧版を把握し、重大修正が何日で何％へ届くかを過去記録から求めます。

成功件数だけでなく失敗理由、再試行、サポート連絡、最終的に更新不能だった台数を確認します。買い手の統合KPIには、配布開始ではなく、対象母数の確定、成功確認、残存リスクの受容、顧客記録の更新を含めます。

安全な失敗と復旧を実機で確認する

停電、通信断、容量不足、互換性不良、署名検証失敗、部分更新が起きたとき、装置が危険な状態で動作しないかを確認します。ロールバックが可能でも、古い脆弱版へ戻ることによるリスク、患者データや設定の整合性、監査ログの保持を評価します。

復旧手順が特定技術者の記憶に依存する場合、夜間・遠隔地・退職後に対応できません。必要工具、部品、管理者資格、連絡網、復旧時間、代替機、顧客説明を手順化し、買収後のサポート網で再現できるかを確認します。

9．レガシー機器とEOL・EOSを将来キャッシュフローへ反映する

販売終了・保守終了・サイバー支援終了を分ける

EOLやEOSという略語は会社ごとに意味が違います。新規販売を止める日、修理部品を保証する日、通常ソフトウェア更新を終える日、重大脆弱性だけ対応する日、クラウドを停止する日、顧客データを返却・消去する日を別々に定義します。

契約書、添付文書、顧客通知、営業説明、保守見積、製品ロードマップで日付が違う場合は、法的・実務的に最も重い約束を専門家と確認します。経営計画が想定する保守収益期間より、基盤OSや通信サービスの終了が先なら改修・交換費を織り込みます。

修正不能な製品へ補完策を設計する

署名更新機能がない、部品供給者が消滅、性能上OS更新できない、認証済み構成を大きく変える必要がある製品では、パッチだけが回答ではありません。ネットワーク分離、ポート停止、監視、利用制限、代替ワークフロー、交換、回収等の選択肢を患者影響とともに評価します。

補完策を医療機関へ押し付けず、導入費、運用負担、教育、検証、残留リスク、終了期限を明確にします。買収後に交換キャンペーンを行う場合は、対象台数、原価、訪問能力、代替機、売上減、評判影響を下振れシナリオへ置きます。

設置台帳の不確実性を価格モデルへ入れる

古い機器ほど、移設、転売、廃棄、病院統合、連絡先変更が台帳へ反映されていないことがあります。全台確認できない状態で対象数をゼロ扱いせず、販売台数、最終保守、消耗品注文、クラウド接続、修理履歴から存在範囲を推定します。

確定台数、推定稼働、所在不明を分け、単価と対応率を変えた感応度を作ります。所在不明分は偶発債務の断定ではなく、調査・通知・引当判断に必要な不確実性として投資委員会へ示します。

10．医療機関・在宅利用者との共同責任を契約と現場で照合する

安全な導入条件が調達資料まで届いているかを見る

設計部門が要求するネットワーク分離、時刻同期、認証、ログ保管、バックアップ、ウイルス対策、管理者権限が、営業提案、設置チェック、取扱説明、保守契約へ一貫して反映されているかを確認します。病院の標準設定に合わせた例外は、承認者と残留リスクを記録します。

MDS2等の顧客向けセキュリティ資料を使う場合は、対象版と回答日を明示し、営業担当が古い回答を再利用しない仕組みを見ます。質問票の回答と実機設定が違うと、買収後の契約紛争や信頼低下につながります。

共有アカウントと遠隔保守の実態を調べる

緊急保守のための共通ID、メーカー既定パスワード、病院側管理者IDの借用、常時接続VPN、個人用リモートツールが残ると、退職者や委託先のアクセスを制御できません。代表拠点の設定、認証ログ、保守チケットを突合します。

是正では多要素認証を導入するだけでなく、患者対応を止めない緊急アクセス、承認、時間制限、録画・ログ、終了確認、定期棚卸を設計します。買い手のID基盤へ統合する日までの暫定統制も必要です。

脆弱性通知を読める相手へ届ける

通知先が購買担当だけでは、臨床工学、医療情報、診療科、在宅支援へ伝わらない場合があります。製品ごとに安全管理情報、技術手順、患者向け説明、交換日程を分け、誰が受領・実施・完了確認するかを決めます。

公開の早さだけでなく、悪用を助長しない情報量、修正版の準備、医療機関の変更管理、規制当局や研究者との調整を考えます。過去通知の開封率、問い合わせ、未完了施設、誤解を分析し、連絡網の品質を評価します。

11．クラウド・開発委託・OEMの責任空白をなくす

契約一覧をデータフローと重ねる

経理の取引先一覧では、無料OSS、研究機関、再委託先、海外親会社のサービス、顧客が契約するクラウドが漏れます。構成図の各ノードとデータフローへ契約番号を付け、契約がない依存、契約はあるが未使用の依存を分けます。

機密保持や個人情報条項だけでなく、脆弱性通知期限、ログ提供、インシデント協力、修正優先度、SBOM、監査、再委託、事業継続、終了支援、規制当局対応、費用を確認します。一般的なSaaS規約で交渉不能な場合は、技術的な代替策と移行時間を評価します。

チェンジ・オブ・コントロールと譲渡制限を先に読む

株式譲渡でも支配権変更通知・解除権がある契約、事業譲渡では相手方同意が必要な契約があります。重要なクラウド、署名、ソースコードエスクロー、OEM、通信契約が承継できなければ、製品サポートを継続できません。

同意取得の相手、開示時期、競合制限、代替候補、移行期間を一覧化します。同意前に顧客名や脆弱性情報を出す場合の守秘範囲を法務と確認し、クロージング条件と移行サービスを重複なく設計します。

委託先停止を仮定した代替運転を試す

契約上のSLAがあっても、サイバー事故、倒産、輸出規制、買収、サービス終了で支援が止まる可能性があります。重要委託先ごとに、何時間で患者・顧客へ影響し、どの機能を手動化でき、データをどう回収し、代替先へ移せるかを確認します。

代替運転が未検証なら、移行費をゼロにしません。エクスポート形式、暗号鍵、API、履歴、設定、テスト環境、担当者の知識を引渡項目へ追加し、買収後の訓練日を100日計画へ置きます。

12．事故・苦情・不具合報告を同じ時系列で再評価する

セキュリティ事故と品質苦情の別台帳を突き合わせる

ログイン不能、データ欠落、再起動、通信切断、表示遅延は、当初は通常の品質苦情や操作ミスとして処理され、後にサイバー要因が判明することがあります。情報システムのインシデント台帳だけでなく、苦情、不具合、修理、コールセンター、返品、フィールドサービスを検索します。

同一時刻・同一版・同一地域の事象を束ね、患者影響、再現性、外部アクセス、設定変更、マルウェア、供給者障害の可能性を見直します。原因不明をサイバー事故と断定せず、再評価の判断と限界を記録します。

報告要否の判断記録と期限管理を確認する

PMDAは医療機器サイバーセキュリティに関する不具合等報告の基本的考え方や脆弱性管理等の通知を掲載しています。個別事象の報告要否・期限は、事実と最新の規制情報を基に安全管理・薬事が判断し、必要に応じ当局へ相談します。

DDでは報告件数が少ないことを良い兆候とせず、どの情報が安全管理へ上がり、誰が要否を判断し、根拠・時刻・追加情報を保存したかをサンプル確認します。買収交渉中に新事象が出た場合の通知義務と開示更新も定めます。

演習で連絡網と意思決定速度を測る

机上演習では、広く設置された製品の認証回避が公表され、修正版は十日後、悪用の有無は不明という場面を設定します。技術、品質、安全、薬事、法務、広報、営業、保守、経営が、最初の四時間・二十四時間・七十二時間で何を決めるかを観察します。

演習の目的は担当者を責めることではなく、連絡先不備、権限待ち、顧客台帳不足、ログ不足、翻訳遅延、休日対応の欠陥を見つけることです。改善項目には責任者、期限、検証方法を付け、買収後に引き継ぎます。

13．発見事項を価格・投資計画・収益予測へ変換する

一時改修費と恒常運営費を分ける

コード修正、外部試験、顧客訪問、機器交換、当局相談、契約移管は案件固有の一時費用です。PSIRT運営、脆弱性監視、SBOM更新、署名基盤、ログ保管、年次試験、人材教育は買収後も続く恒常費です。両者を同じ『IT費』へ入れるとEBITDA調整と統合予算が混線します。

費用見積には対象台数、版数、作業時間、外注単価、移動、代替機、再試験、規制資料、予備費、為替を置きます。譲渡企業の過去費用が低くても、単に必要活動を行っていなかった可能性があるため、将来の適正運営費はゼロベースで考えます。

売上維持と製品終了の二つのケースを作る

改修で販売を続ける場合は、承認・認証への影響、開発期間、供給、顧客受入、競合、価格を見ます。終了する場合は、保守義務、通知、交換、返金、在庫、減損、顧客離反、関連消耗品売上への波及を見ます。最も安い技術策が最も高い事業価値を生むとは限りません。

不確実性が大きいときは、基本、改修遅延、重大事故、製品撤退のシナリオへ確率を置き、期待値だけでなく資金の最大下振れを示します。確率は精密な予言ではなく、判断前提を可視化する道具として版管理します。

顧客信頼と技術資産の上振れも評価する

成熟したPSIRT、再現可能なビルド、完全な設置台帳、迅速なパッチ、顧客との連絡網は、リスク低減だけでなく新規受注、海外展開、統合後の共通基盤へ寄与します。問題件数が多い企業でも、透明に管理し改善している能力は価値になり得ます。

上振れを評価するときは、『安全だから売れる』という抽象論ではなく、質問票回答時間、更新到達率、保守更新率、入札要件充足、開発リードタイム、再利用可能な部品管理基盤といった測定可能な指標へ置き換えます。

14．最終契約・クロージング条件へサイバー発見事項を落とす

表明保証は『安全である』という絶対表現を避ける

将来の脆弱性が存在しないことを保証するのは現実的ではありません。表明保証を検討する際は、適用法令、方針・手順、既知の脆弱性・事故、当局・顧客通知、提供情報、契約違反、重要な未解決事項など、事実と知識限定を法務が具体化します。

技術チームのリスクスコアをそのまま契約用語にせず、『重大』『既知』『製品』『インシデント』の定義を一致させます。開示資料の場所と版を固定し、データルーム更新後に古い一覧を参照しないよう開示例外表を管理します。

直すべき事項を成果物と試験で定義する

『重大脆弱性を解消する』だけでは、対象版、許容する残留リスク、試験方法、顧客展開、当局対応が曖昧です。修正版コード、ビルド、試験報告、リスク評価、リリースノート、配布計画、対象台帳更新など完了証拠を定めます。

クロージング前に顧客へ展開できない場合は、修正完成、限定環境での検証、責任者承認、配布資金の留保など段階を分けます。買い手が統合後に変更する設計と、譲渡企業が是正すべき既存問題を混同しません。

人・鍵・契約・履歴を同日に引き渡す

ソースコードだけ受け取っても、ビルド担当、署名権限、クラウド管理者、脆弱性チケット、顧客連絡先、外部研究者との調整履歴がなければ対応できません。クロージングチェックリストを技術資産と運用権限の二列にします。

退職予定者の知識移転は録画だけで済ませず、買い手担当が実際にビルド、署名、試験配布、チケット検索、顧客通知案作成を行い、譲渡企業が確認します。移行サービス期間中の緊急対応と承認権限も明記します。

15．Day1から100日まで患者安全を優先して統合する

Day1は接続を増やさず可視性を確保する

買収初日に買い手の全社ネットワーク、ID、監視、開発基盤へ一斉統合すると、製品構成や規制資料との不整合を生むおそれがあります。まず管理者アカウント、緊急連絡、ログ保全、バックアップ、変更凍結範囲を確認し、未承認の新規接続を止めます。

重大な未解決案件は担当・次回判断・顧客影響を引き継ぎ、休日連絡をテストします。買収公表文にセキュリティ上不要な詳細を含めず、顧客が保守窓口を見失わないよう連絡先と法人名変更を案内します。

30日で母集団と優先順位を再確定する

最初の一か月で、製品・版・設置・SBOM・脆弱性・契約・鍵の一覧を買い手環境で再照合します。赤信号は患者危害と悪用可能性、黄信号はEOLや証拠不足、青信号は統合効率化とし、単一の技術スコアへ潰しません。

予算、製品責任者、薬事・品質レビュー、顧客連絡、外部試験の順序を経営会議で承認します。統合目標は件数を早くゼロにすることではなく、重大な不確実性を減らし、対応不能な製品を経営判断へ上げることです。

100日で繰り返せる運営サイクルを完成させる

百日までに、SBOM再生成、脆弱性監視、受付、臨床評価、修正、署名、試験配布、顧客通知、終了判定を少なくとも一度通しで実行します。買い手標準へ変更した手順はQMS文書、教育、権限、記録様式へ反映します。

KPIは検出件数だけでなく、製品母集団把握率、SBOM版一致率、一次評価時間、重大案件の意思決定時間、更新到達率、EOL通知完了率、演習改善完了率を用います。達成できない指標は原因と次の投資判断を取締役会等へ報告します。

15補遺．サイバーセキュリティ実査ワークブック

次の表は資料請求リストではなく、証拠を見た後に何を疑い、どの経営判断へつなげるかを記録するための作業票です。全四十項目を機械的に同じ深さで行うのではなく、製品の接続性、患者影響、販売国、取引手法に応じて担当・期限・サンプルを決めます。

発見事項は『問題あり・なし』で閉じず、未確認、事実確認済み、患者影響評価中、是正計画承認済み、顧客展開中、終了確認済みなど状態を付けます。次の判断表は、技術部門の報告を投資委員会・最終契約・統合予算へ運ぶ際の論点です。

15詳説．製品類型別に作る六つの判定調書

輸液ポンプ群：無線更新と治療継続を同時に評価する

複数病棟で使う輸液ポンプと中央管理サーバーの案件では、モデル、ファームウェア、無線モジュール、薬剤ライブラリ、ドッキングステーション、保守端末を同じ製品群として捉えます。調書の一枚目には、薬剤投与へ影響する設定、通信が切れたときの自律動作、アラーム、看護師による代替手順、更新中の使用可否を書きます。サーバーだけを試験してポンプ本体の物理ポートや旧無線方式を外すと、実際の攻撃経路を見落とします。

版分布は購買台数ではなく、資産台帳、保守訪問、中央サーバー接続、交換履歴を突き合わせます。院内ネットワークから隔離されているという説明は、VLAN設定、保守VPN、持込PC、USB、ベンダー既定アカウントで検証します。薬剤ライブラリ更新が署名されているか、誤ったライブラリを受信した際に装置がどの状態になるか、更新失敗時に投与が継続するかを安全担当と確認します。

重大な認証問題を直す場合、すべての装置を同時停止できません。病棟単位の更新、予備機、臨床工学部門の受入確認、旧版装置のネットワーク制限を日程へ置きます。修正版の完成日と施設への展開完了日は別のマイルストーンです。買収価格では開発工数だけでなく、現地要員、代替機の拘束、夜間作業、教育、未更新装置の監視を見積もります。

契約調書には、既知問題の対象版、設置母数、患者影響評価、暫定策、修正版の受入基準、施設通知、更新完了証拠を記載します。『パッチ提供済み』を完了とせず、対象施設が受領し、装置版を確認し、残存台数が合意水準まで減ったことを終了条件にします。病院の変更管理が遅れる事情は譲渡企業の責任と決めつけず、協力義務と連絡記録を分けます。

画像診断ワークステーション：OS依存とDICOM接続を解きほぐす

画像診断ワークステーションでは、装置アプリだけでなく、OS、GPUドライバ、画像処理ライブラリ、DICOMノード、PACS接続、ライセンスサーバー、読影用モニターの校正ソフト、遠隔保守を構成に含めます。性能検証済みの組合せを確認し、単純なOS更新が画像表示、計測、互換性、承認内容へ与える影響を薬事・品質と評価します。

病院ごとにAE Title、通信先、TLS対応、プロキシ、時刻同期、ローカル保存、共有フォルダが違うため、標準構成図だけでは到達経路を判断できません。代表施設の設定バックアップと通信ログを匿名化して確認し、送信元偽装、未認証ノード、古い暗号、不要サービス、保守用ポートの実態を把握します。患者画像の閲覧は必要最小限にし、検証用データを用います。

OSの保守終了が近い場合、アプリを移植する、付属PCを一式交換する、ネットワークを制限して期限付き保守する、次世代製品へ移行する案を比べます。GPUや専用ボードの供給、性能試験、医療機関の予算年度、読影停止時間、データ移行を考えると、ライセンス費だけの比較では足りません。施設別の更新窓口と受入試験を運転資金計画へ反映します。

買収後に買い手の共通PACS連携部品へ変更する計画があっても、既存顧客への修正義務と将来統合投資を分けます。譲渡企業が解決すべき未修正脆弱性、買い手がシナジーのために行う再設計、供給者EOLにより不可避となる交換を三つの費用箱へ分け、価格で二重計上しません。

在宅モニタリング：家庭環境とコールセンターを製品境界へ入れる

在宅モニタリング製品は、患者宅のセンサー、スマートフォン、家庭Wi-Fiまたは携帯回線、クラウド、医療者画面、コールセンターを経由します。利用者がOS更新やパスワード管理を十分に行えないこと、家族共用端末、通信圏外、機種変更、アプリストア配布遅延を前提にします。理想的な家庭ネットワークだけでリスクを評価しません。

患者IDと機器IDの紐付け、ペアリング、本人確認、端末紛失、通知先変更、再登録、介護者アクセスをサンプルで追います。測定値が届かないときに医療者画面が『正常』に見えるのか『欠測』を明示するのか、コールセンターが誰へ何分以内に連絡するのかを確認します。機密性だけでなく、欠測が臨床判断へ与える影響を扱います。

通信規格やSIM契約が終了する場合、郵送交換だけで完了するとは限りません。高齢者等への設定支援、旧機器回収、データ移行、同意、医療機関への説明、未接続期間の代替観察が必要です。対象住所の正確性と連絡不能率を調べ、交換原価、コール時間、再発送、訪問支援を下振れ予算へ置きます。

事業譲渡ではアプリストア開発者アカウント、プッシュ通知証明書、携帯回線契約、コールセンター番号、プライバシー通知、患者同意を新主体へ移せるか確認します。ストア審査や証明書更新に遅延が出ても緊急通知を維持できる暫定策を作り、クロージング日の名義変更だけで患者支援が途切れないようにします。

AI画像解析クラウド：モデル版とサービス版のずれを管理する

AI画像解析では、学習済みモデル、前処理、推論コード、閾値、参照データ、Web画面、クラウド基盤を一つのリリースとして特定します。モデルのハッシュや版が同じでも、前処理ライブラリ、入力機器、解像度、クラウド設定が変われば出力が変わる可能性があります。承認対象機能と研究用・補助機能を画面とAPI単位で線引きします。

サイバー調査ではモデル窃取、入力改変、再送、権限逸脱、学習データ漏えい、API濫用、依存ライブラリ脆弱性を扱いますが、AIの性能評価やバイアス一般をサイバー問題へ混ぜません。ただし攻撃や設定変更で性能が意図せず変わる経路は、臨床評価とセキュリティ評価の共同範囲です。ログがモデル版、入力、出力、操作者、時刻を追跡できるか確認します。

クラウドの自動更新やマネージドサービス変更は、譲渡企業の明示的リリースがなくても構成を変えます。インフラ構成管理、承認、ステージング検証、ロールバック、地域別展開、障害時のモデル固定を調べます。供給者の認証報告だけでは、自社テナントの権限、秘密情報、ネットワーク、監視が適切か分かりません。

価値評価では、モデル精度の上振れとは別に、継続的なクラウド費、監視、SBOM、依存更新、侵入試験、顧客質問票、各国変更管理を正常運営費へ入れます。買い手が自社クラウドへ移す場合は、性能再検証、データ所在、停止時間、顧客契約、再申請可能性を確認し、単なるインフラ節約として扱いません。

医療機器修理・販売会社：メーカー権限と保守端末を監査する

製造販売業者でない修理・販売会社でも、メーカーの診断ソフト、管理者パスワード、遠隔保守、顧客ネットワーク情報、装置ログを扱うことがあります。メーカー別に、付与権限、利用者、講習、端末、保存データ、再委託、退職時回収を一覧化します。営業担当の個人PCへ保守ツールが残っていないかもサンプル確認します。

修理受付から現地作業、部品交換、ソフト更新、動作確認、製造販売業者への連絡までを一件追跡します。現場判断でセキュリティ設定を弱める、共有IDを教える、未承認USBを使う、ログを私物媒体へ保存する慣行がないかを聞き取りと証跡で確かめます。違反と断定する前に契約、メーカー手順、適用制度を専門家が確認します。

会社買収後、買い手の従業員が既存メーカー権限を当然に使えるとは限りません。支配権変更、資格・研修、指名技術者、保守地域、顧客同意、競合制限を契約で確認し、再発行までの業務継続策を作ります。重要メーカーの同意が取れないシナリオでは、対象売上、在庫、技術者稼働、顧客離反を試算します。

この類型の上振れは、正確な設置台帳、迅速な現地対応、顧客との信頼、複数メーカー横断の障害知識です。買い手がそれを自社製品の脆弱性通知や更新展開へ活用できるかを評価します。ただしメーカー秘密情報を買い手の別事業へ流用できるとは限らず、情報隔離と契約目的を守ります。

長期使用プログラマ：交換不能期間と鍵寿命を設計する

植込み機器等を設定するプログラマのように、患者が長期間旧製品へ依存する場合、販売終了後も臨床現場で支援が必要です。プログラマ本体、テレメトリ、認証情報、患者データ、アップデート媒体、交換部品、校正、病院ごとの設置を把握し、植込み機器世代との互換表を作ります。

古い暗号やOSの問題を見つけても、即時停止が患者フォローを妨げることがあります。利用場所の制限、ネットワーク切断、物理管理、監視、専用端末化、段階交換を臨床担当と比較します。サイバーリスクを下げる措置が診療アクセスや緊急時対応を悪化させないかを必ず評価します。

証明書・鍵の有効期限が機器の残存使用期間より短い場合、更新可能性、信頼チェーン、時刻依存、オフライン装置、失効確認を試験します。鍵を更新できない装置について、保守終了日だけを通知しても患者支援は完了しません。代替プログラマの配備、医療機関教育、旧機器の回収と安全廃棄までを計画します。

買収モデルでは、新規販売収益がない製品群でも、保守契約、規制上・契約上の責任、評判、後継製品との関係を考慮します。必要費用を偶発的な例外扱いせず、残存患者数と支援年数に基づくライフサイクル予算へします。引渡しでは旧版資料、部品、試験治具、専門家連絡、事故履歴を失わないことが価値保全になります。

16．M&A相談事例：サイバーDDで整理した五つの課題

以下の相談事例は、当社に実際に寄せられたM&A・事業承継のご相談をもとに、相談者や企業を特定できないよう、内容の一部を加工・再構成して掲載しています。相談時の課題や検討内容をご紹介するものであり、個別案件の成約や同様の結果を保証するものではありません。

相談事例1：遠隔監視装置のOSサポート終了と保守継続

相談背景。医療機関へ納入した遠隔監視装置について、付属PCのOSサポート終了と保守継続の条件を整理したご相談です。現行アプリの新OSでの検証状況や、設置台帳に不足している版情報が確認の論点となりました。

検討事項。製品マスターと保守履歴から対象装置を把握し、新OS移行、ネットワーク分離、付属PC交換、製品終了の選択肢を比較するための資料を整理しました。薬事上の変更評価、検証工数、訪問能力、代替機、顧客予算周期を確認し、保守を継続する場合と終了する場合の条件を検討します。台帳整備や移行試験を取引の前提条件とするか、必要な予算をどちらが負担するかも確認事項です。

個別の法的結論を示すものではありません。契約、製品、設置環境、最新の公式資料を確認し、薬事・品質・法務・セキュリティの担当者が共同で判断する必要があります。

相談事例2：SBOMと稼働中の製品版の不一致

相談背景。SBOMの生成対象と、病院に設置されている製品版との対応が明確でない点についてのご相談です。旧版に含まれる商用ライブラリ、旧ビルド環境の再現性、供給者契約の状態を含め、引継ぎに必要な情報を確認することが課題でした。

検討事項。SBOMの存在だけで判断せず、成果物解析、旧リリース媒体、保守端末、購入記録から依存部品を確認する方法を整理しました。重大な脆弱性との照合、修正可能性、旧版の交換費用、顧客への通知も検討対象です。再現環境の復旧を引渡し条件とする案と、旧版を段階的に廃止する案について、必要な条件を比較します。

この場面では、技術問題の有無だけで価格を機械的に動かさず、患者影響、是正可能性、必要期間、顧客との約束、取引後の実行主体を一枚の判断記録へ集約します。

相談事例3：OEM元と製造販売業者の通知責任の整理

相談背景。海外OEM製品を国内で製造販売する事業について、品質問題の連絡とサイバーセキュリティ情報の通知責任を整理したご相談です。脆弱性、SBOM、情報公開の調整、緊急パッチに関する契約条件や、営業担当者のメールに依存する情報伝達が確認の論点でした。

検討事項。メール、苦情、アップデート、供給者通知を時系列で確認し、安全管理部門への情報伝達を確かめることを整理しました。契約改定や補足合意で通知内容・期限・窓口・費用・各国対応を明確にする必要性と、相手方の同意を取引の前提条件又は移行課題として扱うかを検討します。国内側の法的責任をOEMへ丸ごと転嫁できるとは決めつけず、専門家が役割を確認します。

検討結果は、採用しなかった選択肢と理由も含めて保存し、後に前提が変わった場合に再評価できる形へします。

相談事例4：事業譲渡に伴うコード署名基盤の分離

相談背景。親会社が複数事業の製品を共通の署名基盤で管理する中で、譲渡対象製品の更新機能をどう引き継ぐかというご相談です。既存装置が信頼する証明書チェーンを踏まえ、鍵の切替えによる更新への影響と、親会社から分離する条件を整理しました。

検討事項。買い手用の信頼鍵を追加する橋渡し更新、親会社による期限付き署名サービス、装置交換の各案を、安全・日程・費用の面から比較することを検討しました。テスト機での更新とロールバックの検証、親会社のアクセス権、ログ、承認、終了条件を移行サービス契約でどう扱うかが確認事項です。鍵素材そのものの不適切な複製を前提にせず、暗号担当と法務が方式を検討します。

クロージングを優先して検証を省略すると、買収直後の更新不能へつながります。完了条件と暫定統制を分けて管理します。

相談事例5：認証回避の可能性と取引の公表・実行条件

相談背景。取引の公表や実行を検討する中で、遠隔管理画面の認証回避の可能性にどう対応するかというご相談です。技術的な確認、顧客環境への修正配布、情報開示の順序と、取引日程との関係を整理する必要がありました。

検討事項。技術評価と患者安全評価を分け、接続停止等の暫定策、当局報告・顧客連絡の要否を最新情報と個別事情に基づいて確認することを整理しました。売買契約を締結している場合には、中間期通知、通常運営、重大悪化条項、クロージング条件との関係を確認し、当事者と専門家が延期・是正・条件変更を検討します。事実未確定の段階で事故の有無を断定せず、記録の保全と開示資料の更新を検討事項に含めます。

安全上の対応と取引上の権利行使を同じ担当者の即断にせず、それぞれの責任者と記録経路を保ちます。

17．医療機器M&AのサイバーセキュリティDDに関するFAQ

Q1．医療機器M&AのサイバーセキュリティDDは全案件で必要ですか

接続性、ソフトウェア、遠隔保守、クラウド、患者影響がある案件では重要度が高まります。単純な消耗品卸でも、顧客ポータルやメーカー保守権限を持つ場合があります。最初に簡易スクリーニングを行い、対象がなければ根拠を記録して深度を調整します。

Q2．SBOMがあれば脆弱性管理は十分ですか

十分ではありません。SBOMは構成を把握する基盤であり、対象版との一致、情報源との照合、製品への影響評価、修正・緩和、顧客共有、更新が必要です。ファイルの有無より運用を通しで確認します。

Q3．CVE件数が多い会社は買収すべきでないですか

件数だけでは判断できません。検出範囲、到達可能性、患者影響、対応速度、未解決理由、設置台数、修正可能性を確認します。積極的に検出・公開する会社ほど件数が多く見えることもあります。

Q4．侵入テストは譲渡企業の許可なく実施できますか

実施すべきではありません。対象、権限、環境、時間、停止条件、患者データ、成果物を当事者と合意し、契約と適用法令を確認します。本番医療機関への無断スキャンは避けます。

Q5．基本要件基準の適合をDDチームが判定できますか

DDチームだけで規制当局の判断を代替しません。品目・版・変更・申請資料を確認し、薬事と品質の専門家が最新通知を基に評価し、必要ならPMDA等への相談を検討します。

Q6．古い製品はサイバー要件の対象外ですか

年代だけで一律に外せません。現在の販売・保守、接続性、患者影響、設置台数、当時と現在の要求、後発通知、修正可能性を確認します。レガシー機器にはパッチ以外の補完策や交換も検討します。

Q7．クラウド契約は株式譲渡なら確認不要ですか

不要とは限りません。支配権変更条項、名義、管理者、データ所在、再委託、侵害通知、終了支援を確認します。法人が同じでも、親会社共通契約や個人名義の管理者は統合時に問題になります。

Q8．サイバー事故がなければ表明保証は簡単ですか

事故認識がないことと、脆弱性や未報告事象がないことは別です。定義、知識限定、調査範囲、既知案件、通知、契約違反、開示例外を法務が具体化します。将来の脆弱性不存在を絶対保証する表現は慎重に扱います。

Q9．EOL製品の保守売上は評価から除くべきですか

一律には除きません。契約上の保守期間、部品、サイバー支援、顧客更新、代替品、交換費、粗利を調べます。継続可能な収益と、将来の改修・交換負担を同じモデルで比較します。

Q10．買収後すぐ全社SOCへ統合すべきですか

製品ログの意味、規制記録、患者データ、遅延、既存監視を理解せず一斉統合するのは危険です。Day1は可視性と連絡を確保し、検証済みの接続から段階的に移します。

Q11．サイバー発見事項はすべて価格減額ですか

減額だけが手段ではありません。是正前提条件、特定補償、資金留保、移行支援、アーンアウト、買い手投資として扱う場合があります。患者安全と実行可能性を先に決め、二重調整を避けます。

Q12．公式資料はどの時点で再確認しますか

初回スコープ設定、重要発見、最終契約案、クロージング前、主要アップデート前に再確認します。医療機器のサイバー領域は通知や国際ガイダンスが更新されるため、確認日と版をワークペーパーへ残します。

18．参照した一次資料・公式ガイダンス

日本の法令適用は厚生労働省・PMDAの最新資料を優先し、IMDRF、IPA、FDAの文書は販売国と製品に応じた比較・実務資料として使いました。各リンクは記事作成時点の公開ページです。個別品目の申請、報告、変更、契約判断は所管当局と資格ある専門家へ確認してください。医療機器M&AのサイバーセキュリティDDでは、参照した版と確認日を証拠台帳へ残します。発見事項は公式要求と買い手の実務基準を分けて報告し、更新時には設計変更と新しい脆弱性情報を再照合します。

• PMDA「医療機器のサイバーセキュリティについて」
• 厚生労働省「医療機器の基本要件基準第12条第3項の適用について」
• PMDA「医療機器のサイバーセキュリティを確保するための脆弱性の管理等について」
• 国際医療機器規制当局フォーラム「医療機器のサイバーセキュリティに関する原則と実務（N60）」
• IMDRF「医療機器のサイバーセキュリティに用いるソフトウェア部品表の原則と実務（N73）」
• IPA「SBOM導入・運用の手引き」
• 米国食品医薬品局「医療機器のサイバーセキュリティ：品質管理体制の考慮事項と市販前申請資料の内容」
• 国際医療機器規制当局フォーラム「既存の医療機器のサイバーセキュリティに関する原則と実務（N70）」