OTセキュリティ M&A完全ガイド｜工場・制御システムを守る15の必須実務

OTセキュリティ M&Aを成功させる15の必須実務

最初に価格を精緻化するのではなく、「安全に作る、止める、戻す」という事業能力の連続性を確認します。OTでは可用性だけを絶対視しても、安全だけを別組織へ隔離しても不十分です。異常な制御が人、環境、製品、設備、供給先へどの順番で波及するかを起点にし、その経路を遮断・検知・復旧できる証拠を集めます。

15項目を一枚の取引地図にする

完成度ではなく「証拠の連鎖」で比べる

対象工場に最新製品が多いことは、それだけで安全な証拠ではありません。台帳と現物が一致し、通信経路が説明でき、変更が承認され、任意のバックアップを復元でき、事故時の連絡先が応答するという一連の証拠が重要です。旧式機器でも、ネットワーク分離、許可通信、物理統制、監視、予備品、復旧手順を組み合わせてリスクを管理している場合があります。逆に新しい機器でも、初期パスワード、常設遠隔接続、未管理クラウドへ依存していれば脆弱です。

編集部の実務整理では、各論点を「文書あり」「現物一致」「直近実績あり」「第三者・別部門でも再現可」の四段階で評価します。規程の有無だけで満点にせず、現場確認とサンプル追跡を組み合わせます。この評価は法的な規格適合判定ではなく、取引判断のための証拠成熟度です。

公式事実・案件事実・仮説を分ける

OTセキュリティ M&Aでは、ガイドラインの一般原則と対象会社の実態を混ぜると判断を誤ります。経済産業省の工場向けガイドラインやIPAのリスク分析ガイドは、検討手順と対策の参照軸を提供しますが、対象工場が適合していること、あるいは事故が起きないことを証明しません。規格名を記載した提案書も、認証範囲や実装を直接示すものではありません。

三つの箱に情報を分ける

「未確認」を低リスクと置かないことが重要です。開示できない機密情報は、専門家限定閲覧、現地閲覧、画面共有、マスキング、クリーンチームを使えます。証拠を守るため、攻撃手順や認証情報を通常のデータルームへ置かず、閲覧者、複製、保存期間、削除証明を管理します。

OT・ICS・ITの境界を定義する

NIST SP 800-82 Rev.3は、OTを物理環境と相互作用し、機器、プロセス、事象を監視・制御して直接の変化を起こすプログラマブルなシステムや機器を広く含むものとして扱っています。製造業のICSだけでなく、ビル自動化、輸送、物理アクセス、環境監視なども射程に入ります。したがってDDの対象は「工場LAN」という名前で切らず、物理プロセスへ影響する機能から逆算します。

境界表は用途と被害で作る

「工場内」と「取引対象」を分ける

敷地内にある設備でもリース会社、顧客、親会社、設備ベンダーが所有する場合があります。敷地外でもクラウド履歴、ベンダー保守センター、親会社の認証基盤、遠隔SOCは操業へ不可欠です。資産の場所、法的所有者、運用責任者、契約主体、データ管理者を別列にし、株式譲渡後または事業譲渡後に誰が何を利用できるかを決めます。

関連する一般的なサイバーDDの考え方はセキュリティM&Aセンターのコラム一覧も参照できます。本稿ではその中でも、物理プロセス、安全、長寿命設備、停止窓というOT固有の論点に限定します。

安全とセキュリティを同じ変更管理に載せる

OTの安全は、人や環境を危険から守るための設計・運用であり、セキュリティは意図的・偶発的な不正アクセスや改変等から機能を守る取り組みです。両者は同一ではありませんが、サイバー事象が物理挙動を変え、安全対策がセキュリティ機器の設置・更新を制約するため、M&Aでは同じ意思決定表で扱います。NISTもOTセキュリティを固有の性能、信頼性、安全要求とともに扱う必要を示しています。

変更前に五つの問いを通す

1. 変更対象はどの物理プロセス、安全機能、品質条件に接続しているか。
2. 変更失敗、通信遅延、誤検知、自動遮断で最悪何が起きるか。
3. 検証環境、バックアウト、現場監視、手動運転、停止条件はあるか。
4. 誰が安全、制御、IT、ベンダーの各観点で承認するか。
5. 変更後の受入試験と異常時の復旧完了を誰が判定するか。

EDRやネットワークセンサーを導入するだけでも、CPU・メモリ負荷、ドライバ、通信遅延、暗号化、時刻、サポート条件へ影響し得ます。「セキュリティ製品だから安全」という前提を置かず、設備ベンダー情報、検証結果、安全部門の承認を残します。

安全停止とサイバー封じ込めを競合させない

インシデント時にIT側が即時ケーブル切断を求めても、プロセスの安全停止に通信や監視が必要な場合があります。逆に操業継続を優先し過ぎれば被害が拡大します。事前に「誰が、どの兆候で、どの順序で、どこを止めるか」を設備・ラインごとに定め、現場責任者とインシデント責任者の共同判断にします。緊急時は人命・環境保護を最優先し、証拠保全は安全を害さない範囲で行います。

取引目的と承継範囲を決める

取得目的が生産能力、特定工程、地域供給、保守人材、制御技術、顧客認定のどれかで、必要なOT資産は変わります。「会社を買う」では粗すぎます。譲渡企業の親会社が認証、SOC、WAN、クラウド、バックアップ、調達、ライセンスを共有している場合、株式譲渡でもスタンドアロン化が必要です。事業譲渡では、設備は移ってもソフトウェア、回線番号、ドメイン、認証鍵、ベンダー保証が移らないことがあります。

取引形態別のOT論点

TSAを「接続を残す契約」で終わらせない

TSAには、サービス、対象工場、利用時間、運用責任、承認、ログ提供、重大事故通知、変更凍結、復旧、下請、料金、終了試験を入れます。旧親会社ネットワークとの接続を漫然と残すと、双方の攻撃面と責任が曖昧になります。出口日から逆算し、譲受企業環境での平行稼働、復元、権限、緊急連絡をテストしてから終了します。

経営・工場・ITの責任を接続する

経済産業省・IPAのサイバーセキュリティ経営ガイドラインは、サイバーリスクを経営課題として扱う枠組みを示しています。OTでは経営、CISO、工場長、安全責任者、保全、品質、生産技術、IT、調達、法務、広報が関与します。誰か一人へ責任を寄せても、現場の操作権限や停止判断が伴わなければ機能しません。

RACIに停止権限と予算を足す

買収前には暫定RACIを作り、クロージング時点の氏名、代理、電話、権限を入れます。組織図上の役職があっても、夜間に設備を止められる人、制御ベンダーへ緊急連絡できる人、バックアップ媒体を取り出せる人が不明ならDay1条件は満たしていません。

資産台帳を操業単位で作る

資産台帳は単なる機器リストではなく、設備と事業被害の索引です。経済産業省の工場向けガイドラインとIPAのリスク分析ガイドを参照しつつ、対象工場のライン、工程、安全、品質、出荷へ結びます。自動探索は便利ですが、古い機器への能動スキャンは影響評価なしに実施しません。受動監視、スイッチ情報、設計図、保全台帳、購買、現場ウォークダウンを組み合わせます。

最低限の台帳項目

• 一意ID、名称、型式、シリアル、場所、盤・ライン・工程
• 所有者、運用責任者、保守会社、契約番号、緊急連絡先
• OS・ファームウェア・アプリ版、設定、サポート期限
• IP・MAC・ポート・プロトコル、通信相手、外部接続
• 安全・環境・品質・生産への重要度と許容停止
• バックアップ場所、最終復元日、予備品、代替運転
• 認証方式、共有ID、鍵・証明書、物理鍵
• 変更履歴、既知脆弱性、補完対策、リスク受容期限

サンプル追跡で台帳の信頼性を測る

重要ラインから任意のPLCを選び、現物ラベルから台帳、ネットワーク図、プログラム版、バックアップ、保守契約、変更記録へ逆追跡します。次に台帳から無作為抽出し、現物が存在するか、責任者が説明できるか、廃棄済み機器が残っていないか確認します。少数サンプルで問題が続くなら対象範囲を拡張し、台帳の「完成率」を自己申告だけで評価しません。

ゾーン・経路・依存関係を可視化する

ネットワーク図は「理想構成」ではなく現在構成を示す必要があります。工場、ライン、セル、安全系、無線、ベンダー接続、IT/OT間、クラウド、他拠点をゾーンとして整理し、許可すべき通信と実際の通信を比べます。物理的に別ケーブルでも、共通認証、共通仮想基盤、共通電源、共通バックアップ、二重接続端末があれば依存関係があります。

通信経路台帳の項目

分離を存在ではなく有効性で見る

ファイアウォールがあるだけでは分離の証拠になりません。ルールの目的、所有者、最終レビュー、未使用ルール、any設定、管理経路、設定バックアップ、ログ、変更承認を確認します。OT-DMZを設けても、管理者がOA端末から直接両側へ入れるなら迂回が残ります。工場停止を避けるため、ルール整理は通信観測と現場承認を経て段階的に行います。

遠隔保守とリモートアクセスを統制する

IPAは制御システムへのリモートアクセスについて、遠隔での操作・設定変更が深い階層へ到達し、対策が事業継続性と安全性に直結する重要な要素だと説明しています。NIST SP 800-82 Rev.3も、必要性を正当化し、業務上必要な範囲へ限定し、安全・セキュリティ統制を迂回させず、MFA、期限、監視、現場への周知等を検討するよう示しています。

全経路を六つの証拠で確認する

1. 回線：VPN、専用線、モデム、携帯、クラウド中継、画面共有を物理・論理で特定する。
2. 主体：会社、ベンダー、個人、下請、海外拠点ごとに実利用者を特定する。
3. 必要性：対象設備、作業、頻度、緊急性、現地代替を記録する。
4. 認証：固有ID、MFA、端末条件、特権、秘密情報保管を確認する。
5. 制御：申請、時間制限、踏み台、録画・ログ、現場立会い、接続元制限を確認する。
6. 遮断：現場が安全に切断でき、切断後も停止・復旧できるかを試験する。

Day1の再承認リスト

緊急用アカウントを常時有効にするのではなく、保管、発行、利用通知、失効、事後レビューを定めます。ベンダーの共有アカウントしか使えない設備では、踏み台側の個人識別、作業申請、画面記録、現場立会いで補い、恒久更新計画へつなげます。

ID・特権・共有アカウントを棚卸しする

OTでは、機器固有の制約から共有アカウントや固定パスワードが残りやすく、操作記録が個人へ結び付かないことがあります。買収で経営者、親会社、委託先が変わると、旧関係者の認証情報が有効なまま残る危険もあります。ディレクトリのユーザーだけでなく、PLC・HMIのローカルID、アプリ内ID、サービスID、APIキー、証明書、無線鍵、保守用物理鍵、金庫内の紙を棚卸しします。

特権アクセスは「発行から失効」まで追う

申請、承認、発行、本人確認、利用、監視、返却・失効、定期レビューという一連の流れをサンプルで追います。退職者一名、異動者一名、ベンダー保守一件、緊急作業一件を選ぶと、台帳と実運用の差が見えます。共有IDを直ちに廃止できない場合は、踏み台で個人認証し、貸出記録とセッションログを保存し、パスワード変更と更新計画を設定します。

クロージング時の認証情報変更を安全に行う

• 変更対象、設備影響、再起動要否、ロールバックを事前に確認する。
• 安全・操業上の変更窓を定め、現場とベンダーを待機させる。
• サービスIDの依存先を洗い出し、連鎖停止を防ぐ。
• 旧親会社・譲渡企業のアクセスを失効し、必要なTSA利用者は別IDにする。
• 新しい秘密情報を通常のデータルームやメールへ記録しない。
• 変更後に操作、監視、バックアップ、緊急ログインを受入試験する。

パスワード一斉変更を完了条件にするだけでは不十分です。変更による停止が危険な設備は、ネットワーク側の許可元限定、物理隔離、監視、現場鍵管理を暫定措置にし、期限と責任者を経営が承認します。

脆弱性・パッチ・補完対策を評価する

脆弱性の深刻度スコアが高くても、対象機器が隔離され攻撃経路がなければ優先度は変わります。逆に公表スコアが中程度でも、安全機能や単一障害点へ到達し、復旧手段がなければ事業リスクは大きくなります。IPAのリスク分析ガイドが示す資産ベースと事業被害ベースの両面を使い、脆弱性、経路、脅威、物理影響、既存対策、復旧を結び付けます。

パッチ可否を二択にしない

安全なセキュリティテストを計画する

テストの目的、対象、禁止操作、許容負荷、連絡、監視、停止条件、復旧を文書化します。本番PLCへ認証総当たりや大量パケットを送るのではなく、設計・設定レビュー、受動観測、オフラインイメージ、検証設備、ベンダー試験情報を優先します。必要な本番試験は、設備所有者の許可と現場立会いを得て、事業停止リスクを評価して実施します。未許可の侵入試験は法務・安全上の問題にもなり得ます。

保守端末と外部記憶媒体を管理する

エンジニアリング端末は、制御ロジックを読み書きできる強い権限と特殊ソフトウェアを持つため、単なるPC在庫として扱いません。OAメールやウェブ閲覧との兼用、個人端末、ベンダー持込み端末、更新停止したOS、管理者常用、無許可ソフトを確認します。USB等の媒体は、隔離環境での検査、許可、識別、利用記録、保管、廃棄を一連で管理します。

クリーン保守の実務チェック

• 用途別の専用端末を定義し、資産IDと責任者を付ける。
• 承認されたソフト、ドライバ、ライセンス、版を基準化する。
• 端末イメージを保存し、再構築とライセンス再認証を試す。
• 持込みファイルは隔離端末で検査し、ハッシュや申請番号を記録する。
• 作業前後のロジック・設定差分を保存し、現場が承認する。
• ベンダー端末は接続先・時間・操作を限定し、終了後に権限を失効する。
• 不要な無線、Bluetooth、モデム、クラウド同期を無効化または統制する。
• 媒体紛失、感染、誤接続時の隔離・報告・証拠保全を決める。

買収時には端末の所有権だけでなく、ソフトウェア利用権、ドングル、署名証明書、ベンダーポータル、更新権、バックアップ媒体を確認します。旧社員名義のライセンスや親会社契約は、端末が手元にあっても利用できないことがあります。

バックアップを復元能力として検証する

「毎日バックアップしている」という回答だけでは、OTの復旧を評価できません。PLCロジック、HMI画面、SCADA設定、サーバイメージ、レシピ、ヒストリアン、ネットワーク設定、証明書、ライセンス、アプリ、データベース、作業手順、機器ファームウェアを対象にし、整合する版をそろえます。バックアップ作成時刻と設備の構成変更がずれると、復元後に異なる制御となり得ます。

復元テストの記録項目

RTO・RPOを工場単位で鵜呑みにしない

一つの工場でも安全監視、ボイラー、ユーティリティ、主要ライン、品質データで許容停止と許容データ損失は異なります。編集部の実務整理では、最小安全機能、限定生産、通常生産の三段階で復旧目標を置き、必要要員、予備品、ベンダー移動時間を測ります。将来の復旧時間は保証ではなく仮説なので、実測と感応度を示します。

監視・ログ・時刻同期を設計する

OT監視は大量のアラートを作ることではなく、物理プロセスと通信の異常を現場が判断できる形で届けることです。ファイアウォール、スイッチ、踏み台、VPN、サーバ、HMI、認証、クラウド、保守申請、設備警報のログを、保存期間、時刻、責任者とともに確認します。機器制約で詳細ログが取れない場合は、ネットワーク側や踏み台側で補完します。

アラートから行動までを試す

最近の代表アラートを選び、発生、受信、一次判定、現場照会、封じ込め、復旧、記録、再発防止まで追います。SOCが「通知済み」としても、夜間の工場担当者が受信していない、設備名が台帳と違う、遮断判断者が不明なら運用は完成していません。誤検知率だけでなく、重要な異常を見逃さない検知範囲を評価します。

時刻同期を証拠品質として見る

設備、監視、入退室、IT、クラウドの時刻がずれると攻撃経路や操作順を再現できません。時刻源、同期方式、未同期機器、タイムゾーン、ログ変換を確認します。ただし時刻設定変更が制御や履歴へ影響する設備もあるため、影響評価と変更管理を経て是正します。

制御系インシデント対応を準備する

JPCERT/CCは、国内の制御システムやプラントを対象と考えられるインシデントの報告窓口を設け、制御系SIRTの機能を備えるための手引きも公開しています。買収DDでは、一般的なCSIRT手順の有無だけでなく、設備・安全・品質・環境・顧客・規制へつながる制御系の対応機能を確認します。

制御系プレイブックの骨格

1. 検知・受付：サイバーアラートだけでなく、誤動作、品質逸脱、保守異常、物理侵入を受け付ける。
2. 安全確保：人命、環境、設備の危険を評価し、安全部門と操作を決める。
3. トリアージ：影響設備、プロセス、拠点、顧客、外部接続、継続可否を整理する。
4. 封じ込め：通信遮断、アカウント停止、設備停止を物理影響とともに選ぶ。
5. 証拠保全：安全を妨げず、ログ、メモリ、設定、ロジック、写真、作業記録を保全する。
6. 除去・復旧：信頼できる版へ戻し、安全・品質・通信の受入試験を行う。
7. 通知：経営、従業員、顧客、委託先、保険、当局、支援機関へ基準に従い連絡する。
8. 改善：原因、対策、残余リスク、他拠点展開を期限・責任者付きで管理する。

机上演習に必ず物理判断を入れる

「保守ベンダーの認証情報が悪用され、夜間にHMIへ不審接続があり、製品条件が変更された疑い」というように、サイバーと操業を結ぶシナリオを用います。参加者は工場長、設備、安全、品質、IT、法務、広報、経営、主要ベンダーです。判断時刻、情報不足、承認、代替生産、顧客出荷保留まで記録し、連絡先が実際に応答するか確認します。

マネージドサービスと委託先を承継する

OT環境は、設備メーカー、システムインテグレーター、通信会社、クラウド、MSSP、保守会社へ広く依存します。IEC 62443-2-4はIACSサービス提供者が資産所有者へ統合・保守時に提供するセキュリティ関連プロセスの要件を扱います。これは個別契約が自動的に適合することを意味しませんが、委託先の役割を質問する軸になります。

サービス契約のDD項目

「24時間監視」の中身を分解する

24時間受信、24時間分析、24時間顧客連絡、24時間現地対応は同じではありません。一次応答時間、重大度定義、言語、休日、担当者のOT知識、対象プロトコル、現場への連絡、誤遮断防止を確認します。サービス売上の継続性を見る場合は、契約期間、更新、前受、最低利用、外部ツール原価、技術者配置、顧客集中も財務DDへ渡します。

IEC 62443を役割分担に使う

IECの公式説明では、IEC 62443シリーズは産業用オートメーション・制御システムのセキュリティについて、組織面と技術面をシステムのライフサイクルにわたり扱います。シリーズは一般概念、資産所有者やサービス提供者の方針・手順、システム、コンポーネントなど複数の群に分かれます。DDでは規格番号を合否ラベルにせず、対象会社が資産所有者、インテグレーター、保守提供者、製品供給者のどの役割を持つか整理します。

役割ごとの証拠へ変換する

認証・準拠・参考利用を区別する

認証書がある場合は、発行機関、規格部、版、対象組織・製品・サイト、有効期間、除外、サーベイランス、未解決事項を確認します。「準拠」「準拠を目指す」「参考にした」は認証と同じではありません。広告表示と契約上の保証が一致するか、買収後の組織・開発・拠点変更で追加手続が必要かを専門家と確認します。

日本の公的ガイダンスをDDへ落とす

経済産業省の「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」は、工場の規模・性質によって必要な対策が異なることを前提に、工場システムのセキュリティ対策を整理しています。IPAの「制御システムのセキュリティリスク分析ガイド 第2版」は、分析対象と評価指標の準備、資産ベースと事業被害ベースの詳細分析、結果活用、テストを扱います。これらをチェック欄だけにせず、案件の証拠要求へ変えます。

公的資料から質問票を作る手順

1. 対象工場と守るべき安全・品質・供給を定義する。
2. 公式資料の目的・適用範囲・版を確認し、案件に関係する項目を選ぶ。
3. 各項目を「方針がありますか」ではなく「誰が、何を、いつ実施した証拠は何か」へ変える。
4. 原資料、現物、ログ、面談、サンプル試験のいずれで確認するか指定する。
5. 欠落を安全、停止、顧客、費用、契約、Day1のどこへ反映するか決める。

業種別ガイドがある場合は追加します。半導体、電力、医療、ビル、化学等では守る対象や規制が異なります。一般ガイドだけで個別業法・顧客要求を満たすとは判断しません。最新版、施行日、経過措置、契約で固定された版を確認します。

技術・サイバーDDを実施する

技術DDは、文書閲覧、経営・現場面談、現地確認、構成・ログサンプル、限定テストを段階化します。初期段階では重要拠点、重大事故、親会社依存、外部接続、サポート終了、主要委託先を把握します。独占交渉後に詳細な設備・設定を確認し、クロージング前にDay1変更を準備します。機密性と工場安全に応じて閲覧権限を限定します。

データルーム要求資料

• 工場、ライン、主要プロセス、重要度、停止・事故・品質逸脱一覧
• OT方針、組織、RACI、リスク台帳、監査、是正計画
• 資産台帳、ネットワーク図、データフロー、外部接続・回線一覧
• ID、特権、ベンダーアクセス、物理鍵、定期レビュー記録
• 脆弱性、パッチ、例外、サポート終了、更新投資計画
• バックアップ、復元試験、事業継続計画、予備品、手動運転手順
• アラート、インシデント、演習、保険・当局・顧客通知
• 設備・SIer・MSSP・クラウド契約、SLA、下請、出口条項
• 認証・規格・顧客セキュリティ要求と最新の維持証拠
• 過去・将来のOT運用費、保守費、更新CAPEX、停止損失資料

現地確認の進め方

安全教育、撮影・持込み規則、作業許可に従い、現場の操業を妨げません。盤、保守端末、遠隔装置、無線、物理入退室、バックアップ保管、緊急連絡を確認し、設計図・台帳と照合します。説明者だけでなく、実際に夜間対応する保全担当者やオペレーターへ復旧・異常時の手順を聞きます。制御情報は攻撃に悪用され得るため、報告書には不要なIP、認証、詳細トポロジーを載せません。

赤旗を「即断」と「追加検証」に分ける

商業・財務DDで継続費用を測る

OTセキュリティはコストセンターだけではありません。顧客認定、稼働率、品質、製品トレーサビリティ、保険、供給契約の維持に関わります。商業DDでは、主要顧客が求めるセキュリティ条項・監査、停止や事故による解約・賠償、セキュアな遠隔サービスを競争力としているかを確認します。ただし「安全な工場だから売上が増える」という因果を資料なしに置きません。

正常化すべき費用と投資

• 旧親会社が負担していたSOC、WAN、ID、バックアップ、ライセンスの独立費用
• 設備メーカー・MSSP・回線・クラウドの更新価格と為替影響
• サポート終了機器、検証環境、予備品、ネットワーク分離の維持CAPEX
• OT責任者、現場セキュリティ人材、夜間対応、教育・演習の人件費
• 事故調査、復旧、顧客対応、保険免責、未引当の是正費
• 工場停止、試験、再認証、品質確認に伴う機会費用

停止損失は範囲で示す

停止一時間当たりの粗利だけを掛けると、仕掛品廃棄、再立上げ、品質検査、納期違約、代替生産、ユーティリティ、安全確認を落とします。一方、最大被害をそのまま期待損失にするのも不適切です。頻度を捏造せず、複数の停止時間と復旧段階でキャッシュ影響を示し、価格のベースケースとストレスケースを分けます。

法務・契約・保険DDをつなぐ

法務DDでは、顧客・供給・設備・ソフトウェア・クラウド・保守・回線・ライセンス・秘密保持・個人情報・輸出管理・保険を技術構成へ結びます。設備上は使えても契約上の利用者や地域が限定され、譲受企業の関連会社では使えない場合があります。インシデント通知期限、監査権、下請制限、損害賠償、支配権変更、契約終了時のデータ返却を確認します。

契約と技術の対応表

既知事故と未知事故を同じ条項に押し込まない

既知の侵害疑い、未閉鎖の是正、顧客請求、規制照会は個別に事実・費用・責任を特定し、特別補償、エスクロー、価格調整、前提条件を検討します。未知の一般リスクは表明保証と一般補償の枠で扱います。保険回収、引当、価格減額、補償を二重に受け取らない調整も必要です。

企業価値と是正投資を分ける

対象会社の価値は「セキュリティ点数」で直接決まりません。正常収益、成長、運転資金、維持投資、リスク、相乗効果を分け、OT是正費をどこへ反映したかを明示します。通常運用に必要な継続費は正常利益へ、サポート終了設備の維持更新は維持CAPEXへ、譲受企業固有の高度化は相乗効果投資へ置きます。同じ費用をEBITDA調整と価格控除へ二重計上しません。

価値ブリッジの例

仮説は反証可能にする

「監視統合でコストが下がる」という仮説には、対象契約、人員、ツール、終了違約金、新運用費、移行期間、サービス品質を置きます。「事故を防げる」という便益は確率を作らず、検知時間、復元実測、未管理接続数など測定可能な先行指標で確認します。上振れ相乗効果を単独価値へ先取りせず、達成に必要な投資を同じ表に載せます。

最終契約へリスクを翻訳する

DD報告書に「脆弱性あり」と書くだけでは、クロージング後の責任は決まりません。対象資産、事実、期限、証拠、費用、救済へ変換します。クロージング前に無理な一斉更新を課すと安全を損なう場合があるため、前提条件にするもの、誓約で段階是正するもの、価格・補償で配分するものを分けます。

条項へ落とす例

• 前提条件：重要保守契約の同意、未知回線の特定、重大事故の封じ込め、Day1アクセス確保。
• 表明保証：開示した資産・接続・事故・通知・ライセンス・認証の正確性と重要な欠落。
• 誓約：通常運用、重大変更の事前同意、新規遠隔接続の凍結、事故の即時通知、証拠保全。
• 特別補償：特定の既知事故、未解決請求、特定ライセンス欠落等。
• TSA：親会社SOC、WAN、認証、クラウド、バックアップの範囲と出口。
• 情報管理：制御構成・脆弱性・認証情報の限定閲覧、削除、漏えい時の対応。

開示例外を読める形にする

「データルームに開示済み」という包括例外では、譲受企業が重大リスクを認識できたか争いになり得ます。重要事故、サポート終了、共有アカウント、親会社依存、規格例外は、設備・契約・日付・影響を特定した開示表へまとめます。譲渡企業は秘密情報を過度に広げず、譲受企業は必要な判断情報を索引で追えるようにします。

Day1の最低安全条件を整える

Day1の目的は、譲受企業の標準をすべて導入することではありません。誰が所有し、誰が運転・停止・連絡でき、旧関係者の不要アクセスを止め、必要サービスを継続し、重大異常へ対応できる状態を作ることです。制御ロジック、ネットワーク、監視ツールの大規模変更は、安定化後に検証して行います。

Day1最低条件チェックリスト

• 工場・ライン別の経営、操業、安全、OT、IT、ベンダー責任者と代理が確定している。
• 重大事故・新規異常を譲渡企業が直ちに通知するブリッジ期間の窓口がある。
• 重要外部接続を継続・条件付き・停止へ分類し、譲受企業が再承認している。
• 譲渡企業・旧親会社・退職者の不要な論理・物理アクセスを安全に失効できる。
• 重要設備の信頼できるバックアップ、復旧手順、連絡先、予備品へアクセスできる。
• SOC・MSSP・設備ベンダー・クラウド・回線の契約主体と料金支払が途切れない。
• 重大インシデントの安全判断、封じ込め、経営報告、顧客・当局・保険通知が決まっている。
• TSAの対象、利用者、ログ、変更、終了基準が運用チームへ引き渡されている。
• 未解決リスクに期限、責任者、暫定対策、停止権限、予算枠が付いている。
• 変更凍結の例外手続と緊急保守の承認・記録方法が周知されている。

クロージング前後の変更カレンダー

100日統合準備を段階実行する

OTセキュリティ M&Aの統合準備は、可視化、安定化、統制、最適化の順で進めます。最初の30日は台帳、接続、事故、復旧、キーパーソンを確かめます。31〜60日は高リスク遠隔接続、特権、バックアップ、委託契約を是正します。61〜100日はネットワーク、監視、標準、教育、投資ロードマップを承認します。日数は目安で、定修や生産計画、安全承認に合わせます。

100日ロードマップ

KPIを売上相乗効果より先に置く

• 重大安全事象、セキュリティ起因の停止・品質逸脱、未閉鎖重大事故
• 重要資産の現物照合率、所有者不明資産・外部経路の件数
• 期限超過の特権・ベンダーアクセス、MFA・時間制限の適用状況
• 重要バックアップの復元成功率と実測復旧時間
• サポート終了資産のリスク受容期限と更新進捗
• 重大アラートの確認・現場連絡時間、訓練の改善完了率
• TSA出口テスト、委託契約再締結、キーパーソン代替者の進捗

件数が増えたから直ちに悪化とは限りません。可視化が進み、未報告だった事象が記録された可能性があります。定義、母数、基準線、データ元を固定し、良いニュースを作るために分類を変えません。

譲渡企業の準備

譲渡企業は「弱点がない」と見せるより、事実を管理し、是正優先度を説明できる状態を作ります。OTの詳細構成は機密性が高いため、資料の分類、閲覧者、段階開示、ログを決めます。重要な事故や未管理接続を隠すと、価格だけでなく交渉信頼、表明保証、クロージング確度を損ないます。

90日前からの譲渡企業チェック

1. 工場、ライン、主要OT資産、外部接続、委託先の索引を作る。
2. 任意資産の現物・台帳・通信・バックアップ・契約を逆追跡する。
3. 重大停止、事故、品質逸脱、保険通知を部門横断で照合する。
4. 親会社共用サービスを洗い出し、TSAと独立費を試算する。
5. サポート終了・更新・安全承認を複数年投資計画へまとめる。
6. キーパーソンと代替者、留任・引継ぎ、緊急連絡を整える。
7. 規格・認証・顧客表示の範囲と最新版を確認する。
8. 未解決事項は影響、暫定対策、期限、責任者を付けて開示する。

売却検討の全体像はセキュリティ会社の売却相談とM&A事例一覧も参照できます。OT資料は通常の財務資料よりアクセスを絞り、案件不成立時の削除・返却を確認します。秘密保持・段階開示の基本方針は中小M&Aガイドライン遵守方針にも掲載されています。

譲受企業の判断手順

譲受企業は「自社標準との差分」だけで対象会社を評価しません。対象工場の物理プロセス、法規・顧客、設備制約を理解し、自社標準の適用が安全かを検証します。初期意向表明前は重大な価値毀損要因を絞り、独占交渉後に現地・詳細設定・契約を深掘りし、最終契約とDay1へ接続します。

譲受企業の十の問い

• 取得目的に不可欠な工場・ライン・制御能力は何か。
• 最悪の安全、環境、品質、供給被害は何か。
• 未知資産・未知接続・未知事故をどの証拠で減らせるか。
• 買収により切れる親会社・ベンダー・クラウド依存は何か。
• Day1に必ず継続する接続・契約と、停止する接続は何か。
• 復元は誰がどの媒体・端末・ライセンスで実行できるか。
• 恒常運用費、維持更新、譲受企業固有投資を分けたか。
• 表明保証、誓約、補償、TSAが具体的な設備・事実へ対応しているか。
• 統合責任者に停止権限、予算、現場信頼があるか。
• 条件が満たされない場合の構造変更・撤退基準を守れるか。

Go・条件付きGo・No-Go

セキュリティ成熟度が低いから自動的にNo-Go、高いから自動的にGoではありません。取得目的、被害、是正可能性、時間、費用、契約、譲受企業能力を合わせます。ただし安全な運転・停止・復旧を検証できず、重要な事実も取得できない場合は、価格を下げるだけでは解決しません。

最終判断表

15実務の証拠パックとレビュー質問

最後に、OTセキュリティ M&Aの各論点を担当者の説明で終わらせないため、レビュー会議へ持ち込む証拠パックを整理します。以下は認証審査の合否基準ではなく、買収判断、契約条件、統合準備の優先順位を同じ事実で決めるための編集部による実務整理です。すべてを一度に集めるのではなく、重要度と取引段階に応じて開示範囲を広げます。

実務1：取得目的と境界の証拠パック

法人・敷地・工場・ライン・工程・設備・ソフトウェア・データ・人・契約を一枚の境界図へ置き、取得対象、除外、共有、TSAへ色分けします。レビューでは「このラインを明日運転するため、対象外の会社から何を借りる必要があるか」を聞きます。回答がネットワークだけに偏る場合は、電源、蒸気、圧縮空気、品質試験、認証、購買、予備品、夜間要員まで広げます。境界図の版と基準日を固定し、交渉中の組織変更も差分管理します。

実務2：安全との整合を示す証拠パック

危険源分析、安全機能一覧、インターロック・SISの責任分界、変更許可、直近の安全試験、緊急停止・再起動手順を集めます。サイバー対策の変更票を一件選び、安全・品質・設備の承認と実施後確認があるか追跡します。「ファイアウォール変更はIT作業なので安全審査外」という説明なら、通信喪失や遅延時の設備挙動を追加確認します。譲受企業の標準製品を入れる場合も、対象工場の安全承認を省略しません。

実務3：資産と依存関係の証拠パック

資産台帳、現行構成図、通信マトリクス、保守・購買記録、現地写真または限定閲覧記録を紐づけます。重要設備から上流の電源・制御、下流の品質・出荷、外部のクラウド・ベンダーへたどり、単一障害点を表示します。レビューでは「このサーバを失った際、どのラインが何分後に影響を受け、手動代替を誰が開始するか」を問い、抽象的な重要度ランクを具体的な業務判断へ変えます。

実務4：遠隔接続の証拠パック

回線・装置・VPN・クラウド中継・モデムの一覧、実利用者、契約、申請、MFA、接続ログ、緊急遮断手順を一組にします。設定上の許可と実際の利用を分け、直近90日など合理的な期間で接続者と作業内容をサンプル確認します。利用履歴がない常設回線は必要性を再評価し、利用履歴があるのに申請がなければ統制不備として扱います。遮断試験は設備安全と保守保証への影響を確認して実施します。

実務5：ID・特権の証拠パック

ディレクトリ、機器ローカルID、サービスID、共有ID、ベンダーID、物理鍵を同じ台帳へ載せ、所有者、権限、最終利用、失効条件を示します。退職・異動・委託終了のサンプルから、依頼日と実失効時刻の差を測ります。緊急IDについては保管場所、二者承認、取出記録、利用後変更を確認します。資格情報そのものをDD資料へ複製せず、存在と管理証拠だけを限定閲覧する設計も重要です。

実務6：脆弱性と変更管理の証拠パック

対象版、脆弱性情報、攻撃経路、ベンダー見解、適用可否、検証結果、補完対策、残余リスク、期限を一行で結びます。単純な未パッチ件数ではなく、安全・供給影響が大きく、到達可能で、既存対策が弱く、復旧困難な組合せを優先します。直近の更新作業について、バックアップ、作業許可、設定差分、受入、ロールバックの有無を追い、文書化されたプロセスが現場で再現されているか確かめます。

実務7：保守端末・媒体の証拠パック

端末台帳、標準イメージ、許可ソフト、管理者、媒体貸出、検査記録、直近のPLC変更記録をそろえます。端末がオフラインでも、更新ファイルを受け取る別端末や媒体が管理外なら経路は残ります。ベンダー端末を一件選び、入場、端末確認、接続許可、作業立会い、設定差分、退場まで追跡します。作業証跡が請求書だけの場合は、操作対象と変更内容を再構成できるか追加確認します。

実務8：バックアップ・復旧の証拠パック

重要資産ごとのバックアップ対象、媒体、暗号鍵、保管、担当者、最終復元日、実測時間、受入結果を一覧にします。「取得成功」のログと「安全に生産再開できた」証拠を区別します。任意の重要設備について、予備機または検証環境へ復元し、通信、I/O、警報、インターロック、品質条件を確認します。実機試験ができない場合は理由と代替証拠を示し、未試験という残余リスクを経営判断へ上げます。

実務9：監視・インシデント対応の証拠パック

ログソース、保存期間、時刻、検知ルール、連絡先、プレイブック、演習、直近事象の記録をまとめます。アラートの画面だけでなく、誰が何分後に確認し、現場へ何を聞き、操業判断がどう下されたかをタイムライン化します。品質異常や設備故障として閉じた事象も横断確認し、サイバー関連性を検討する入口があるか見ます。演習の課題が期限内に閉じたかを追い、実施回数だけで成熟度を評価しません。

実務10：委託先・サプライチェーンの証拠パック

契約、SOW、SLA、RACI、再委託、アクセス、事故通知、事業継続計画、終了支援をサービス単位でそろえます。設備メーカーが別会社のクラウドや国外保守センターを使う場合、対象会社が把握・承認できているか確認します。主要委託先一社が停止した場合の代替、予備品、内部技能、契約上のデータ返却を質問します。ベンダー評価表の点数より、事故時連絡や復旧演習の実績を重視します。

実務11：標準・規制・顧客要求の証拠パック

適用法令、業種ガイド、顧客契約、社内標準、認証を要求源ごとに並べ、対象サイト・製品・版・有効期間を記します。IEC 62443の番号があっても、資産所有者の運用、サービス提供者のプロセス、製品能力のどれを示すか明確にします。未閉鎖の監査指摘、例外承認、顧客への改善約束を期限付きで確認し、クロージングで責任主体が変わる際の通知・再審査を契約条件へ反映します。

実務12：商業・財務の証拠パック

OT関連契約、要員、更新、予備品、停止、事故、保険、顧客要求の費用を過去実績と将来計画へ分けます。親会社配賦がゼロでも、独立後にSOCや認証基盤が無償で提供されるわけではありません。見積書は数量、対象、停止作業、為替、保守期間をそろえ、楽観・基準・ストレスの範囲を作ります。将来事故確率は根拠なく数値化せず、復旧時間や未管理経路など測定可能な前提で感応度を示します。

実務13：法務・保険の証拠パック

重大契約のセキュリティ、監査、通知、支配権変更、責任制限、下請、データ返却と、実際の技術サービスを対応付けます。サイバー保険だけでなく、財物、利益、賠償、リコール、環境、役員賠償との重なり・除外を確認します。既知事象は発生日、発見日、通知日、損害、引当、保険、顧客交渉を時系列化し、二重回収を避けた価格・補償設計を行います。具体的適用は必ず弁護士・保険専門家へ確認します。

実務14：Day1の証拠パック

当日の責任者名簿、継続サービス、再承認接続、失効対象、変更カレンダー、事故連絡、バックアップ所在、TSA、未解決リスクを一冊へまとめます。完了欄には会議資料ではなく、設定ログ、承認記録、テスト結果、契約同意など客観証拠を置きます。クロージング直前に重大な構成変更が起きた場合は差分を再評価し、署名済み計画があることを理由に古い前提で実行しません。

実務15：100日統合準備の証拠パック

DD指摘、契約義務、Day1課題、各工場の投資を一つの課題台帳へ統合し、重複と抜けを防ぎます。各課題には被害、暫定対策、恒久対策、責任者、予算、変更窓、受入基準、残余リスク承認者を付けます。完了件数だけを追わず、復元成功、未知経路縮減、特権期限、演習改善など成果指標を見ます。100日で終わらない設備更新は、定修・顧客承認・資金計画と結び、暫定対策の失効日を放置しません。

取引シナリオ別の実装例

同じ15実務でも、対象会社の状況により順序は変わります。以下は特定案件の事実や推奨結論ではなく、DDで得た情報を条件へ変換する方法を示す仮想シナリオです。停止時間、費用、期限をそのまま実案件へ転用せず、対象工場の安全・品質・顧客・定修計画で検証してください。

シナリオ1：旧親会社のネットワークから工場を切り出す

対象会社の工場は法人として独立していても、認証、メール、WAN、SOC、バックアップ、DNS、ライセンスが譲渡企業親会社へ依存しているとします。譲受企業はクロージング日に一斉分離せず、まず依存サービスと通信を現物で確定し、TSA中の責任、ログ提供、変更、事故、出口を契約化します。新環境では重要ラインを代表する端末と通信を使って平行試験し、認証、時刻、監視、復元、緊急連絡を確認します。出口判定は「新回線が開通した」ではなく、旧環境を止めても安全運転・停止・復旧できることです。

シナリオ2：設備ベンダーの常設VPNが多数残る

DDで工場ごとに異なるルーターやベンダー共有IDが見つかった場合、危険だからと即時撤去すると保守や保証が止まる可能性があります。回線、設備、契約、直近利用、緊急性、代替を一件ずつ紐づけ、不要・必要・不明へ分類します。必要経路は譲受企業管理の踏み台、固有ID、MFA、時間制限、現場承認、ログへ段階移行し、ベンダーの作業責任と事故通知を再契約します。不明経路は新規利用を止めて調査し、安全確認後に撤去または正式化します。改善完了まで現場が物理的に切断できる方法も確認します。

シナリオ3：サポート終了機器が主要ラインにある

主要PLCやHMIのサポートが終了していても、即交換が品質認定や安全検証を壊すなら段階計画が必要です。対象版、故障率、予備品、バックアップ、開発端末、ライセンス、通信、代替運転、交換時の停止を確認し、短期は分離、許可通信、端末・媒体統制、監視、予備品で守ります。中期は検証設備で移行・バックアウトを試し、定修と顧客承認へ合わせます。評価では通常の設備維持投資と譲受企業固有の高度化を分け、未更新期間の残余リスクを経営が期限付きで受容します。

シナリオ4：事故疑いが故障記録に埋もれている

不審な設備停止が保全上の故障として閉じられ、サイバー調査がない場合、攻撃だったと断定も、問題なしと断定もしません。保全チケット、SCADA・認証・VPNログ、ロジック差分、入退室、ベンダー作業、品質・出荷、保険通知を時系列で保全し、専門家の限定調査へ回します。進行中の危険があれば安全を優先して接続・資格情報を制御します。最終契約では、既知の事実、調査範囲、未判明、費用、顧客・当局通知の責任を個別化し、一般表明だけで曖昧に処理しません。

シナリオ5：OT向けMSSPを買収する

対象が工場所有者ではなく監視・保守サービス会社の場合、顧客環境への特権、技術者力量、ベンダー認定、24時間体制、ツール契約、顧客別SOW、下請、事故責任が価値の中心です。顧客数や年間経常収益だけでなく、監視対象資産、一次応答、現地連携、継続粗利、更新、解約権、支配権変更を確認します。クロージング時に全顧客の認証情報を一斉移動せず、保管主体、アクセス権、通知・同意、ログ、緊急連絡を顧客契約に沿って移します。譲受企業のSOC統合は、OT判断能力とSLAを維持できることを受入条件にします。

シナリオ6：複数国の工場を同時に取得する

複数国取引では、共通質問票だけでは現地回線、言語、委託慣行、データ移転、輸出管理、事故通知、休日対応の差を落とします。グループ共通の最低条件と国・工場別の追加条件を分け、現地責任者、専門家、主要ベンダーが確認します。集中監視や共通IDを直ちに導入せず、現地の安全・操業が単独で継続できるかを先に見ます。統合準備では共通KPIの定義を合わせつつ、規制・顧客要求・設備世代に応じて更新順序を変えます。公表されていない事故率や国別成熟度を推測し、価格へ機械的に織り込みません。

シナリオ7：制御ロジックが特定技術者へ集中する

重要ラインの変更・復旧を一人だけが担う場合、留任契約だけでは知識承継になりません。設備ごとのソース、実行版、開発環境、ライブラリ、パスワード保管、変更理由、ベンダー連絡、手動代替を索引化し、別担当者が検証環境で復元・限定変更を再現します。技術者本人の秘密情報や私物媒体へ依存しないよう、会社管理の保管とアクセスを整えます。契約では引継ぎ成果物、期間、競業・秘密、インセンティブを法的助言の下で設計し、統合準備では複数名の力量評価と訓練を追います。本人の退職意思や将来行動は資料なしに推定しません。

シナリオ8：譲受企業標準と対象工場の運用が衝突する

譲受企業が全端末へのEDR、毎月パッチ、集中認証、自動隔離を標準とし、対象工場が設備保証や連続運転を理由に適用できない場合、例外を放置するか一律適用するかの二択にしません。まず標準が達成したい目的を特定し、対象機器の制約と事業被害を検証します。技術的に適用できない部分は分離、許可通信、踏み台、受動監視、専用端末、変更窓で同等の目的を補い、残余リスクと期限を承認します。新設備の調達仕様には将来の管理要件を入れ、更新時に例外を減らします。例外数だけで工場責任者を評価せず、対策の実効性と復旧能力を確認します。

この調整過程では、安全・品質部門の反対を単なる抵抗と扱わず、どの検証・承認・停止窓があれば実装できるかを具体化します。反対理由が設備ベンダーの口頭説明だけなら、正式なサポート回答、試験条件、保証への影響を取得します。譲受企業側も、自社標準の根拠、対象範囲、例外承認者を示します。両者の要求を「守る目的」「技術制約」「補完対策」「残余リスク」「更新期限」に分解すれば、文化論ではなく証拠に基づく統合判断ができます。

まとめ

OTセキュリティ M&Aの成否は、診断ツールのスコアではなく、対象会社が安全に運転し、異常を止め、信頼できる状態へ戻し、その判断根拠を次の組織へ渡せるかで決まります。15の必須実務は、取得目的と境界、安全、資産、接続、ID、脆弱性、端末、復元、監視、事故、委託、標準、財務、契約、統合準備を一つの証拠鎖へまとめるための順序です。

実務を始める際は、重要工場を一つ、重要ラインを一つ、外部接続を一つ、復元対象を一つ選び、経営説明から現物・ログ・契約・作業者まで同じ識別子で追跡してください。その小さな検証で台帳の不一致、責任空白、親会社依存、手順の再現不能が見つかれば、サンプルを広げます。逆に文書・現物・実績が一致すれば、その方法を他拠点へ展開できます。網羅的な質問票を配るだけでなく、少数の証拠鎖を最後までつなぐことが、限られた取引日程で重大な不確実性を減らす現実的な方法です。

譲渡企業は弱点を隠さず、現物と一致する台帳、復元実績、責任と期限を整えます。譲受企業は自社IT標準の一斉適用を避け、物理プロセスと安全に沿って変更します。公式ガイドは共通言語として活用しつつ、対象会社固有の事実、未確認事項、将来仮説を明確に分けます。具体的な案件相談はセキュリティM&Aセンターへのお問い合わせから行えます。