金属加工会社M&AのOTサイバーDD｜停止・品質・安全リスクを価格と契約へ反映

OTサイバーDDは、金属加工会社の制御機器、工作機械、工場ネットワーク、遠隔保守、復旧能力を、買収価格と契約条件へつなぐ調査です。情報漏えいだけを数える手続ではありません。停止、誤加工、安全機能、納期、顧客認定への影響を、現物と記録から確かめます。

OTサイバーDDの全体像を最初に確認する

工場のOTは、一般的な社内ITと条件が違います。同時に、十年以上使う装置がある一方、停止できる時間は限られます。メーカー保守に依存する設備もあります。そのため、パッチの新しさだけで安全性を判定すると、取引判断を誤ります。

本稿は2026年8月22日時点の公的資料を参照しています。ただし、制度、脅威、製品サポート、行政資料は更新されます。実際の案件では、OTセキュリティ専門家、設備メーカー、インテグレーター、弁護士、保険者、所管機関へ確認してください。本稿は個別の技術・法律・会計助言を代替しません。

OTサイバーDDの要点を六つに整理する

調査項目を目次から選ぶ

OTサイバーDDの目的は工場停止の不確実性を減らすこと

IT監査の言い換えではない

IT監査は、会計システムや社内端末を中心にする場合があります。一方、工場OTでは、PLC、CNC、ロボット、画像検査、計測器、DNC、産業用PCを見ます。設備が動くこと自体が、評価対象です。

例えば、マルウェア感染がなくても問題はあります。管理者パスワードが全装置で共通かもしれません。復旧媒体が読めないこともあります。これらは、買収後の増産や統合で表面化します。

OTサイバーDDは機密性・完全性・可用性を工程へ戻す

設計図の漏えいは機密性、加工条件の書換えは完全性、ライン停止は可用性の問題です。そのため、三つを同じ重みで評価せず、工程と顧客への影響で優先順位を付けます。

金属加工では、数値の小さな変更が品質へ影響します。送り速度、熱処理温度、検査閾値などです。出荷後に判明すれば、回収や顧客監査へ広がります。そのため、品質保証部門も調査へ参加します。

発見を四つの判断へ変える

第一は、取引を続けるかです。第二は、価格をどう調整するかです。第三は、契約で誰が負担するかです。第四は、買収後に何を先に直すかです。OTサイバーDDの報告書は、この四つへ答えます。

脆弱性一覧だけでは判断できません。具体的には、悪用可能性、侵入経路、検知、停止時間、代替生産を添えます。対策を選ぶ際は、設備保証が失われないかも確認します。

重大度と証拠不足を分ける

深刻な欠陥と、確認できない状態は別です。例えば、ログがない場合、侵害がないとは言えません。一方、侵害があったとも断定できません。OTサイバーDDでは、技術リスクと証拠信頼度を二軸で示します。

証拠不足には、追加確認の方法を付けます。例えば、設定の読出し、保守会社への照会、受動的通信観測があります。生産設備へ影響する試験は、変更承認と復旧手順を先に決めます。

2026年8月22日時点の公的なOTセキュリティ枠組み

工場システムガイドラインVer 1.1は公表済み

経済産業省は、2025年4月11日に工場システムのサイバー・フィジカル・セキュリティ対策ガイドラインVer 1.1を公表しました。本稿では、このガイドラインを基礎資料の一つとして扱います。2026年8月22日時点では、公表済みのガイドラインとして位置付けています。

ガイドラインは、工場システムの特徴を踏まえた対策検討に役立ちます。ただし、それ自体が個別工場への一律な法的義務を定めるとは限りません。契約、業法、顧客基準との関係を別途確認します。

中小規模向け手引きも公表済み

経済産業省は2025年4月11日、中小製造業者向けの専用資料も公表しました。専任者が少ない工場は、この資料から優先順位と実施方法を組み立てられます。会社規模だけを理由に調査項目を削らず、要員に合わせて手順と順序を調整します。

小規模工場でも、顧客の単一供給源なら停止影響は大きくなります。同時に、古い設備ほど復旧部品や技術者も限られます。売上規模とサイバー影響を同一視しないことが重要です。

2026年SCSは構築方針の公表段階を区別する

経済産業省は2026年3月27日に、サプライチェーン強化に向けたセキュリティ対策評価制度、SCSの構築方針を公表しました。具体的には、★3・★4の申請受付を2026年度末頃に始める計画が示されています。

2026年8月22日時点で申請受付済みとは扱いません。★3・★4の要求事項・評価基準は、2026年4月21日に公表済みです。一方、その解説書は、IPAが同年10月頃の公開予定と案内しています。公表済み文書と予定資料を分けて記録します。

OTサイバーDDでSCSと工場ガイドラインを二層にする

SCSの主な対象は、クラウドを含むIT基盤です。工場OTを単独で網羅する制度として使うのは適切ではありません。そのため、企業共通基盤はSCS、工場固有領域は工場ガイドラインを軸に見ます。

メール認証が強くても、工作機械の遠隔モデムが独立して残る場合があります。逆に、OTが分離されても、設計データを渡す端末が弱いことがあります。二つの層の接点を調べます。

脅威一覧は発生予測ではなく仮説材料として使う

IPAは「情報セキュリティ10大脅威 2026」を公表しています。OTサイバーDDでは、ランサムウェアや委託先を含む脅威仮説の入口にできます。ただし、順位を対象会社の事故確率へ直接変換しません。

対象工場の接続、権限、設備寿命、復旧力を調べます。そのうえで、確認の優先順位は、一般的な脅威と固有の弱点が重なる場所から付けます。公的資料は思考の骨格であり、現場証拠の代わりではありません。

OTサイバーDDでは法令・契約・任意指針を同じ欄へ入れない

サイバーセキュリティ基本法、個人情報関係の義務、顧客契約、認証、任意ガイドラインは性質が異なります。OTサイバーDDの要件表では、根拠種別を表示します。

制度資料は、公布済み、施行済み、案、計画を別々の欄へ記録します。海外顧客との契約や輸出品が関係する案件では、適用法域と義務主体を専門家へ確認します。ニュース記事だけから法的結論を出しません。

取引範囲と停止影響から調査範囲を設計する

株式譲渡では過去の運用履歴を追う

株式譲渡では、対象会社の契約、アカウント、事故対応が継続します。具体的には、古い保守契約や個人名義のクラウドも確認します。過去の侵害可能性と、将来の統合作業を同時に評価します。

親会社のネットワークから切り離される案件では、共有認証、共有監視、共通バックアップを洗い出します。そのため、分離日に使えなくなる機能が、生産へ与える影響を確認します。

事業譲渡ではOTサイバーDDで移管できないライセンスを探す

設備を譲り受けても、ソフトウェアライセンスが移らない場合があります。具体的には、CNCのオプション、検査ソフト、DNC、保守ポータルを見ます。契約当事者、端末識別、移管費用を一覧にします。

売り手のドメインやメールに認証が依存することがあります。認証の依存を残すと、Day 1にログインできず、加工プログラムや保守情報へ届きません。再発行期間を案件日程へ入れます。

カーブアウトではOTサイバーDDで共有サービスの分離条件を確認する

共有ファイアウォール、SOC、ID基盤、WAN、バックアップを境界表へ載せます。境界表では「IT一式」の表現を避けます。なぜなら、設備側が固定IPや古い名前解決へ依存する場合があるからです。

なお、移行サービス契約には、対象、性能、連絡、ログ保存、終了条件を入れます。工場の停止可能時間も合意します。終了試験をせずに移行サービスを切らないことが大切です。

重要工程を顧客影響から選ぶ

売上の大きな工程だけが重要とは限りません。代替できない熱処理、最終検査、特殊測定がボトルネックになることがあります。製品別ルートと設備能力から、単一障害点を探します。

自動車や半導体向けでは、顧客承認済み設備の変更が制約になる場合があります。特に、顧客要求の確認には、関連する自動車部品M&Aの記事と半導体装置部品M&Aの記事も参照します。

停止影響をOTサイバーDDで時間帯別に表す

停止一時間と停止一週間では対応が違います。そこで、0～4時間、4～24時間、1～3日、3日超に分け、仕掛品、炉内品、薬液、品質検査、出荷への影響を時系列にします。

復旧時間には再検査も含めます。ただし、機械が動けば生産再開とは限りません。原点出し、条件確認、初品検査、顧客承認が必要な場合があります。

安全影響を金額とは別に判定する

安全インターロックや炉温制御へ関わる設備は、売上だけで順位を下げません。特に、安全評価では、人身影響と環境影響を独立させます。サイバーと安全の境界は、設備設計者を含めて確認します。

機能安全を推測で断定せず、診断目的でも安全機能を無効化しません。そのうえで、変更試験は、承認済み手順と安全責任者の管理下で行います。

工場システムの統治と資料依頼を確認する

責任分界を組織図へ重ねてOTサイバーDDを始める

情報システム部、製造技術、保全、品質、設備メーカーの役割を並べます。特に、統治評価では、障害時に誰が停止を決めるかも確認します。肩書と実際の権限が一致しないことがあります。

工場ごとに運用が異なる場合は、責任分界を拠点別に作ります。ただし、本社規程があっても、現場が対象外と思っていることがあります。規程の配布、教育、承認記録まで見ます。

経営会議の議題から実効性を読む

年次方針だけでなく、予算、事故、老朽化を議論した記録を確認します。指摘に期限と担当があるかを見ます。毎年同じ課題が繰り越される場合は、実行力を評価します。

なお、OTサイバーDDでは、投資を却下した理由も重要です。停止リスクを理解して延期したのか、情報が上がっていないのかで、買収後の対策が変わります。

資料依頼は資産・接続・復旧の順に出す

最初に工場、ライン、設備の一覧を求めます。次に、ネットワーク図、遠隔接続、アカウントを求めます。そして、バックアップ、復旧、事故記録を依頼します。順序があると欠落を特定できます。

セキュリティ製品の一覧だけを先に集めても、保護対象が分かりません。そのため、資産母集団を先に作り、その上に対策を載せます。未接続装置も母集団から外しません。

データルームの機密性をOTサイバーDDで守る

ネットワーク図や管理者情報は、攻撃へ悪用され得ます。そのため、アクセス者を絞り、透かし、閲覧履歴、持出し制限を設定します。パスワードや秘密鍵そのものは通常の資料として置きません。

買い手側でも、専門家への再共有範囲を決めます。さらに、案件終了後の削除や返却も合意します。調査のために新たな漏えい経路を作らないことが前提です。

インタビュー回答をOTサイバーDDの証拠へ接続する

「外部接続なし」という回答だけで閉じません。ルーター、通信契約、ベンダー請求、通信ログを確認します。回答が正しい場合も、裏付けを残します。

回答者の誤解を不正と決めつけません。背景には、OT特有の複雑な担当境界があります。現場呼称を確認し、質問を具体化します。例えば「VPN」だけでなく、「メーカーが工場外から入る方法」を尋ねます。

変更凍結と緊急対応のルールを決める

取引中に重大な弱点が見つかる場合があります。その場合、証拠保全を優先しつつ、切迫した危険には対応します。誰が変更を承認し、買い手へ通知するかを先に決めます。

応急的に回線を切ると、保守や生産に影響することがあります。変更前の設定を保存し、戻し方を用意したうえで作業します。調査チームだけで運用変更を命じません。

資産・通信・依存関係をOTサイバーDDで可視化する

資産母集団は五つの台帳から作る

固定資産、保全、IPアドレス、ソフトウェア、設備配置の各台帳を集め、現場観察で補います。ただし、一つの台帳だけでは、償却済み機器や未接続機器が漏れます。

資産キーには、拠点、ライン、設備番号、メーカー、型式、製造年を入れます。具体的には、OS、ファームウェア、通信、所有者、保守期限も付けます。不明値を空欄にせず「未確認」とします。

受動的発見を優先する

稼働中の制御ネットワークへ能動スキャンをかけると、古い機器へ影響する場合があります。まず、スイッチ情報、通信記録、設定、現場資料から把握します。試験方法は設備責任者が承認します。

能動確認が必要なら、対象、速度、時間帯、停止条件を決め、メーカーへ影響を確認します。ただし、調査会社の標準手順を無条件で適用しません。

ネットワーク図は現状と目標を分ける

規程にある理想図ではなく、現在の配線を描きます。図面には、スイッチ、ルーター、無線、セルラーモデム、保守PCを含め、通信方向、プロトコル、管理者も示します。

将来の改善図は現況図と分けて作ります。現状と目標を一枚に重ねると、未実施の対策が実装済みと読まれるおそれがあります。そのため、両方の図面に基準日、確認者、確認方法を付けます。

設備間の非ネットワーク依存も調べる

USBメモリ、CFカード、携帯PCによるデータ移送があります。非ネットワーク経路には、工程をつなぐ紙の加工票やバーコードも含まれます。IP通信だけを見ると、感染経路と復旧手段を落とします。

設計データの流れは、図面・CAD/CAM管理の記事も参照します。具体的には、受注図、CAM、DNC、工作機械まで、ファイル形式と承認を追います。

時刻同期と名前解決を単一障害点として見る

認証、ログ、品質追跡は正しい時刻に依存します。具体的には、NTPの参照先と、外部切断時の動作を確認します。基盤サービスでは、DNSやディレクトリが止まった場合の設備挙動も見ます。

ログ時刻がずれると、事故調査が難しくなり、品質記録との対応も崩れます。そのため、OTサイバーDDでは、時刻ずれの監視と補正手順を確認します。

サポート終了を日付と代替策で示す

古いOSの存在だけで即時撤去としません。メーカー支援、ネットワーク分離、交換部品、復旧媒体を見ます。その上で、許容期間と更新計画を決めます。

なお、設備本体より、内蔵PCの交換が難しい場合があります。制御ソフトの互換性や顧客再認定も確認します。更新費だけでなく、停止と検証の期間を積算します。

遠隔接続・認証をOTサイバーDDで洗い出す

遠隔接続母集団を四方向から照合する

ネットワーク図、通信契約、ベンダー契約、現場機器から母集団を作ります。対象にはVPNだけでなく、リモートデスクトップ、クラウド中継、セルラー回線、家庭用ルーターも含めます。

通常図面から抜けやすい緊急時専用の接続を探すため、保守担当へ聞き取ります。停止中の回線も、再開可能なら記録します。

ベンダー接続を申請・接続・終了で分ける

誰が申請し、誰が承認し、どの時間だけ接続できるかを確認します。同時に、運用証拠として作業中の立会いと記録も見ます。作業後にアカウントと通信を終了できることが必要です。

なお、常時接続が必要と説明された場合は理由を確かめます。予知保全や設備監視かもしれません。その場合でも、通信先、権限、異常検知を明確にします。

共有アカウントの実態をOTサイバーDDで突き止める

現場の共通IDは、迅速な復旧のため残ることがあります。しかし、利用者と操作が追えません。個人IDへ移行できる範囲と、非常用IDの管理を分けます。

パスワードを閲覧して確認する必要はありません。変更周期、保管、退職時処理、初期値の残存を確認します。秘密情報は、適切な方法で専門家が検証します。

多要素認証だけで十分としない

多要素認証は重要です。ただし、接続先が管理者権限なら影響は大きいままです。踏み台、時間制限、接続元制限、操作記録と組み合わせます。

緊急時の迂回手順を確認します。ただし、例外運用では、多要素認証を無効にする共有手順が日常化していないかを見ます。例外には期限と承認が必要です。

退職者・保守終了者の権限を追う

人事台帳、ベンダー名簿、アカウント一覧を照合します。照合では、退職後も使えるIDや、契約終了会社の証明書を探します。設備内蔵アカウントは中央管理から漏れやすい点に注意します。

削除によって設備が停止する可能性がある場合は、無断で消しません。そのため、依存関係を確認し、代替アカウントを試験します。権限整理を安全な変更として計画します。

無線と持込み端末を遠隔経路に含める

工場Wi-Fi、Bluetooth、保全タブレット、テザリングも対象です。無線経路では、アクセスポイントの設置場所とSSIDを確認します。来訪ベンダーが使う端末の条件も見ます。

私物端末の禁止規程があっても、現場で代替手段がなければ迂回が起きます。そのため、業務上の必要を確認し、安全な貸与端末や転送経路を設計します。

ネットワーク分離と通信許可を現場で検証する

ゾーンとコンジットをOTサイバーDDで現場の言葉へ翻訳する

重要度と機能が近い資産をゾーンへまとめます。ゾーン間の通信経路をコンジットとして整理します。用語を並べるだけでなく、どの工程がどこと話すかを示します。

検査装置と品質サーバーの通信に加え、DNCから工作機械への転送があります。ただし、目的が説明できない通信は、確認対象にします。

物理配線と設定をOTサイバーDDで両方見る

VLAN設定があっても、別の未管理スイッチで直結されることがあります。一方、図面上は接続でもケーブルが外れている場合があります。図面と現物の差は、配線、ポート設定、通信記録を合わせて確かめます。

ファイアウォールの成熟度は、ルール数だけで決めません。具体的には、送信元、宛先、サービス、理由、期限、所有者を確認します。広い許可には、業務根拠と改善計画を求めます。

ITからOTへの入口を列挙する

設計端末、資産管理、監視、バックアップ、ウイルス対策が入口になります。入口には、メール端末から加工データを渡す経路も含めます。単純な「分離済み」の表示を疑い、実データの流れを追います。

ただし、完全分離が常に最適とは限りません。更新や監視が止まる可能性があります。必要通信を限定し、障害時の代替を用意します。

OTからインターネットへの出口を確認する

ライセンス確認、時刻同期、クラウド分析、メーカー監視で外部通信が起きます。具体的には、通信ごとに、宛先が固定か、プロキシを通るかを確認します。DNSログも手掛かりになります。

出口制御で止める前に、設備への影響を調べます。例えば、ライセンス失効で起動しない装置があるかもしれません。段階的な観測と試験が必要です。

工場間・海外拠点間の横移動をOTサイバーDDで評価する

複数工場が同じWANに接続される場合、一拠点の侵害が広がる可能性があります。ルート、認証、共有サーバーを確認します。各工場を個別に止められるかも見ます。

なお、海外拠点では、保守時間、言語、規制、通信品質が異なります。現地手順を本社基準だけで推測しません。拠点責任者への確認を行います。

一時接続を恒久設定にしない

設備導入やトラブル対応のため、一時ルールが作られ、終了日を過ぎても残ることがあります。そのため、変更チケットとファイアウォール設定を照合します。

一時接続には、自動失効または定期確認を設けます。特に、統制の実効性は、過去一年の緊急変更から読み取ります。

端末・脆弱性・変更管理を評価する

パッチ未適用を一律の欠陥にしない

脆弱性の深刻度だけでなく、悪用状況、到達経路、代替統制、設備保証を合わせて判断します。メーカー未承認の更新は制御や保証へ影響し得るため、適用判断に互換性試験も含めます。適用を見送る場合は、理由、補完策、再評価日を記録します。

一方、「止められない」を恒久的な免除にしません。具体的には、分離、許可リスト、監視、交換計画を見ます。補完策がなければ、残余リスクは高くなります。

脆弱性母集団をOTサイバーDDの照合表へ載せる

OS、アプリ、ファームウェア、ライブラリを対象にします。具体的には、製品名だけで誤判定しないよう、正確な版を確認し、設備メーカーの情報と公的情報を照合します。

脆弱性スコアは入口です。対象環境で到達可能かを見ます。悪用に認証が必要か、工程停止へつながるかも評価します。

マルウェア対策の適合性を見る

一般的なエージェントが古い産業用PCへ適さない場合があります。そのため、適用前にスキャン負荷や互換性を確認します。代わりに、アプリ許可、ゲートウェイ検査、オフライン媒体検査を使うこともあります。

定義ファイルが各端末へ届く経路と更新頻度も確認します。USBで搬送する工場では、媒体の保管、持出承認、検証、廃棄までを追います。そのため、管理画面の「成功」表示は端末別の反映結果と照合します。

USB・可搬媒体の流れを追う

持込み、検査、貸出、使用、消去の各段階を確認します。各段階では、専用媒体があるか、識別番号が付くかを見ます。加工プログラムと保守ツールでは、必要な運用が違います。

媒体禁止だけでは、現場が困る場合があります。そこで、実務上は、安全な受渡し端末や転送サービスを用意します。例外の実態を把握し、実行できる統制へ直します。

設定変更をOTサイバーDDで品質変更と同じ重さで扱う

PLCロジック、CNCパラメータ、検査閾値の変更は、製品品質へ影響します。そのため、変更統制では、申請、レビュー、試験、承認、戻し方を確認します。誰が直接編集できるかも見ます。

変更前後の差分が保存されていると、事故調査が容易です。保存がなければ、バックアップ時点の比較を検討します。OTサイバーDDは品質変更管理と連携します。

保守用ノートPCを独立した資産として見る

一台のPCが複数ラインや顧客工場を回る場合は、感染の橋になり得ます。具体的には、利用者、接続先、更新、媒体、保管場所を確認します。

設備メーカー所有の端末でも、対象工場へ接続すれば影響します。そのため、契約面では、対策、事故通知、証拠提供を見ます。工場側が何も確認できない状態は、契約リスクです。

廃棄・返却時のデータ消去をOTサイバーDDで追跡する

工作機械や検査装置には、図面、加工履歴、資格情報が残ります。そのため、売却、返却、廃棄の手順を確認します。記憶媒体だけを取り外せない機器もあります。

消去証明の内容と対象番号を照合します。そのうえで、設備更新前には必要データを保全し、安全な消去と復旧可能性を両立させます。

OTサイバーDDでバックアップと復旧可能性を試す

バックアップ対象を工程復旧から逆算する

サーバーだけでなく、PLCロジック、CNCパラメータ、ロボットプログラム、検査レシピを含めます。具体的には、設備ごとに、復旧に必要なファイルと工具を一覧にします。

復旧にはライセンスキー、ドライバー、通信設定も必要です。ただし、保存ファイルがあっても、実行環境がなければ戻せません。技術者の連絡先も復旧資産です。

取得成功より復元試験を見る

バックアップジョブの成功表示だけでは不十分です。そのため、検証環境または安全な停止時間に、復元できるかを確かめます。試験日、対象版、所要時間、問題を記録します。

本番設備で無断試験はしません。予備機、シミュレーター、メーカー試験を使える場合があります。試験できない場合は、理由と代替証拠を示します。

オフライン・変更不能の保管を確認する

なお、ランサムウェアが同じ認証でバックアップを消す可能性があります。オンライン、オフライン、遠隔保管を分けます。保管先へ誰が変更権限を持つかを見ます。

隔離し過ぎると更新されません。更新漏れを避けるため、バックアップ日と設備変更日を照合します。重要変更後に保存する運用が必要です。

OTサイバーDDで復旧時間目標を実績と照合する

目標時間と、訓練・障害時の実績を比較します。実績時間には、部品調達、メーカー到着、品質再承認を含めます。ITサーバーの復旧だけで工場再開時間を決めません。

OTサイバーDDでは、工程ごとにRTOを置き、失ってよいデータ量も決めます。さらに、手入力で補える期間と、追跡不能になる境界を確認します。

紙・手動運転の実効性を試す

BCPに「手作業へ切替」とあっても、訓練していない場合があります。具体的には、必要な帳票、権限、測定器、要員を確認します。安全上、手動化できない工程もあります。

代替運転の能力と品質を数値化し、通常の何割を生産できるか、どの製品だけかを示します。そのうえで、顧客への通知条件も確認します。

予備品と復旧技術者の集中を調べる

予備PLCがあっても、プログラムを書き込める人が一人だけかもしれません。人的依存については、退職予定や外注依存を見ます。設備別に、部品、工具、技術者を対応させます。

旧型部品は中古市場だけに頼る場合があります。その場合、真正性、納期、保管状態を確認します。更新計画では、予備品枯渇の時点を考慮します。

災害復旧とサイバー復旧を分ける

火災や水害では設備自体が損傷します。これに対し、サイバー事故では、機器が動いても設定を信頼できないことがあります。復旧前の安全確認と完全性確認を追加します。

汚染されたバックアップを戻す可能性もあります。そのため、復元点は、いつ侵害されたかを考えて選びます。必要に応じて専門家のフォレンジックを行います。

監視・ログ・インシデント対応をOTサイバーDDで読み解く

事故母集団を広く作る

「サイバー事故」と登録された事象だけでは足りません。事故母集団には、通信不良、原因不明停止、設定消失、品質逸脱、アカウント異常を含めます。保全日報、品質記録、ヘルプデスクも検索します。

同じ時刻の出来事を束ねます。例えば、検査端末の停止とネットワーク障害が別部署に記録されます。共通原因がないかを確認します。

ログの有無より判断可能性を見る

大量のログを保存しても、時刻がずれ、機器名が不明なら調査できません。重要資産について、何を、どこへ、何日保存するかを確認します。ログの所有者と閲覧権限も見ます。

古い装置がログを出さない場合は、スイッチ、ファイアウォール、踏み台で補います。その場合、代替監視が工程影響を捉えられるかを評価します。

検知ルールを工程仮説へ結ぶ

一般的なマルウェア検知だけでなく、制御領域への新規通信、時間外の設定変更、未知端末を見ます。そのため、検知評価には通常通信の基準が必要です。繁忙期と保全停止で基準が変わる点にも注意します。

アラート件数だけで成熟度を測りません。そこで、成熟度の判断では、重大アラートの確認時間、誤検知、見逃しを調べ、対応記録から実際に使われているかを見ます。

事故対応計画に工場の判断を入れる

誰がラインを止め、誰が再開を承認するかを決めます。事故対応表には、工場長、安全、品質、法務、広報の役割を並べます。IT部門だけで設備停止を判断できない場合があるためです。

隔離の手順も工程別にします。ただし、ネットワークを切ることで制御が不安定になる設備があるかもしれません。安全状態への移行方法を設備設計者と確認します。

連絡網を休日・夜間で試す

連絡先が最新でも、夜間に到達できるとは限りません。そのため、夜間対応は、訓練記録と応答時間で確認します。海外ベンダーの時差や言語も考慮します。

なお、保険会社、顧客、行政、捜査機関への連絡条件は、契約と法令で変わります。誰が判断するかを事前に決めます。憶測で対外説明を行わない手順も必要です。

証拠保全と早期復旧の衝突をOTサイバーDDで管理する

現場は早く再起動したい一方、調査には記録が必要です。そこで、優先順位と承認者を決めます。揮発情報、ディスク、ネットワーク記録の保全方法を用意します。

安全な操業再開が最優先になる場面があります。全てを保存できない場合は、判断と理由を記録します。専門家の連絡先を手順へ載せます。

訓練を成功報告だけで評価しない

訓練のシナリオ、参加者、想定外、改善を見ます。ただし、毎年同じ机上訓練では、設備固有の課題が見えません。ランサムウェア、遠隔保守侵害、誤設定などへ題材を変えます。

訓練で残った改善事項を次回までに閉じたか確認します。未完了項目には、停滞理由、予算、責任者、期限を対応台帳で求めます。OTサイバーDDの評価対象は訓練当日の成否ではなく、その後の是正までです。

設備メーカー・委託先・クラウドを調べる

サプライヤー母集団を支払先から再構築する

契約台帳にない保守会社が、スポット請求で作業する場合があります。そのため、母集団の再構築には、買掛明細、入退場、設備保全を使います。ソフトウェア再販会社や通信会社も含めます。

各社について、接続、データ、権限、代替可能性を記録します。そのうえで、優先順位は、売上規模ではなく工場への依存度で付けます。

契約上の対策をOTサイバーDDの証拠へ変える

アクセス制御、事故通知、再委託、ログ提供、脆弱性対応を見ます。さらに、契約終了時のアカウント削除とデータ返却も確認します。一般的な秘密保持だけでは足りない場合があります。

契約に書かれていても、運用されているとは限りません。運用の実態は、接続記録とチケットで確かめます。反対に、良い運用が契約へ反映されていない場合は、更新時の課題にします。

再委託先と国外支援を追う

なお、設備メーカーが遠隔保守を別会社へ委託することがあります。実際に接続する法人と国を確認します。データの保存場所と支援時間も見ます。

契約上の承認が必要かを確認します。その場合、国外移転や輸出管理の論点があれば、弁護士等へ相談します。関連する輸出管理DDの記事も参照できます。

クラウド停止時の工場動作をOTサイバーDDで試す

予知保全、設備監視、ライセンス、品質分析がクラウドへ依存します。回線またはサービスが止まった場合、設備が動き続ける時間を確認します。

一方、サービスレベルの数字だけで判断しません。具体的には、対象工場から見た復旧、データ取戻し、終了支援を見ます。代替手順を一度試しているかも重要です。

ソフトウェア部品表と更新通知の受け口を見る

SBOMが提供される設備では、版と対象番号を確認します。ただし、一覧があるだけで対策済みとは限りません。脆弱性情報を誰が受け、誰が影響判断するかを見ます。

メーカー通知が個人メールへ届く場合があります。このため、組織アドレスと設備台帳へ通知先を結び、退職による情報の断絶を防ぎます。

代替できないベンダーを価格リスクとして示す

一方、特殊設備で、メーカーしか復旧できない場合があります。具体的には、契約期間、応答時間、技術者数、部品在庫を確認します。関係悪化や事業撤退もシナリオにします。

代替困難性は、直ちに取引中止を意味しません。例えば、予備品、技術移転、長期契約、設備更新で緩和できます。費用と時間を取引モデルへ反映します。

安全・品質・顧客要求を一つの調査へ統合する

安全機能の境界をOTサイバーDDの設備図で確認する

非常停止、安全PLC、インターロックが、通常制御とどう分かれるかを確認します。そのうえで、境界評価では、ネットワーク共有や共通電源も見ます。図面と現物が一致するかを設備担当者と確かめます。

OTサイバーDDの担当者が機能安全認証を代替することはできません。その場合、安全評価が必要なら、該当分野の専門家へ依頼します。

品質データの完全性を検証する

測定値の生成、転送、承認、保存を追います。ファイルが手動編集できる場合は、承認と履歴を見ます。検査装置の時刻と校正も確認します。

なお、検査の論点は検査工程のM&A記事と接続します。サイバー対策と測定保証を別の担当だけに閉じません。

加工プログラムの改訂と配布を追跡する

マスター、承認版、機械内の実版を比較します。実版照合では、USBやDNCで配布した記録も見ます。再加工用の古い版が現場に残る場合もあります。

一方、変更者、承認者、適用設備、適用日を追えることが重要です。ハッシュ等を使うときは、運用が継続しているかを確認します。

熱処理・表面処理の連続記録を確認する

炉温、時間、薬液、排水等の記録が同一システムへ依存する場合があります。その場合、停止時に品質証明を作れるかを見ます。欠測時の扱いも顧客要求と照合します。

OT停止は、炉温、薬液、排水の記録を同時に失わせる可能性があります。環境手順との接点は、熱処理会社M&Aの記事や表面処理・めっきM&Aの記事でも確認できます。そのため、両担当は非常時の記録、代替測定、再開承認を共通化します。

顧客のサイバー質問票をOTサイバーDDで実装証拠と照合する

顧客へ「実施済み」と回答した項目を抽出します。規程、設定、記録で裏付けます。将来計画を現在対策として回答していないかを確認します。

回答の不整合は、契約、監査、信用へ影響します。ただし、直ちに虚偽と断定せず、質問の定義と回答時点を見ます。必要なら法務と顧客対応を検討します。

トレーサビリティ停止の出荷判断を定める

追跡システムが止まった場合、紙で代替できるかを確認します。その場合、復旧手順には、ロット、設備、材料、検査を後から再入力できる仕組みも必要です。

出荷を継続できる条件は、品質責任者が決めます。ただし、納期だけで例外を許可しません。顧客通知が必要な条件も手順へ載せます。

労働安全DDと発見事項を共有する

設備防護、ロックアウト、非常時対応は、サイバー対策と交差します。そのため、安全面では、労働安全衛生DDの記事と論点番号を合わせると、二重対応を避けられます。

例えば、ネットワーク隔離のため制御盤を開ける作業があります。電気安全と停止許可が必要です。技術試験を安全手順の外で行いません。

工場ウォークスルーの手順

訪問前に禁止事項と観察目的を合意する

撮影、端末接続、盤開放、通信観測の可否を決めます。保護具と立入区域も確認します。生産を止めずにできる観察と、停止が必要な確認を分けます。

持込みPCや媒体は工場ルールへ従わせ、調査者が感染源にならないようにします。加えて、使用機材の識別番号も記録します。

受注データの入口からOTサイバーDDの現地確認を始める

データ経路として、顧客図面の受領、設計、CAM、DNC、工作機械まで追います。経路上のどこで形式変換し、誰が承認するかを質問します。途中の共有フォルダーや私物媒体を見落としません。

サンプル製品を一つ選び、実際の経路を再現します。その場合、規程の標準経路と違えば、理由を確認します。急ぎ品だけの例外も重要です。

制御盤・機械背面・天井を確認する

正面画面だけでは接続を把握できません。そのため、盤内スイッチ、背面ケーブル、天井の無線機器を安全な範囲で見ます。未使用ポートや私設ルーターを探します。

封印や安全カバーを無断で外しません。その場合、見えない箇所は図面と保守会社の説明で補います。必要なら別日に有資格者が確認します。

保全室・予備品庫・廃棄待ち置場を見る

保全室には、古いノートPC、USB、予備PLC、設定紙が集まります。管理状況は、保管、鍵、更新、所有者から確認します。廃棄待ち設備にデータが残る場合もあります。

一方、予備品は復旧力を支える資産です。ただし、古いことだけを問題にせず、動作確認と適合設備を見ます。棚の番号を資産台帳へ結びます。

遠隔保守の実演を依頼する

可能なら、申請から切断までを説明してもらいます。実演では、承認、認証、接続先、操作記録を確認します。実演できない場合は、過去チケットで追います。

本番への不要な接続は行わず、画面共有や記録閲覧で代替します。したがって、調査目的でも弱い設定を一時的に有効化しないことが重要です。

異常時の最初の十分をOTサイバーDDで聞き取る

「画面が固まったら何をするか」と具体的に質問します。再起動、回線切断、上司連絡の順を確認します。手順書と現場回答の差を見ます。

面接の目的は正解を試すことではなく、現場の実態を把握することです。そこで、危険な習慣があれば、その場で責めず、安全な代替と教育計画へつなぎます。

写真・メモを資産番号へ結ぶOTサイバーDDの証拠管理

写真には撮影日時、場所、方向、設備番号を付けます。撮影前に画角を確認し、パスワードや顧客図面を写しません。保存後は案件の機密区分を設定します。

観察事実と推測を分けてメモします。具体的には、「ケーブルあり」は事実ですが、「外部接続」かどうかは追加確認です。OTサイバーDDの証拠精度を保ちます。

具体的な照合ワークペーパーをOTサイバーDDで作る

次の表は、口頭回答、設定、契約、現物を交差確認する例です。案件ごとに設備安全と操業影響を考慮し、無理のない照合方法を選びます。差異は直ちに違反と決めず、運用上の原因と停止・品質への影響を調べます。

論点	起点資料	照合先	判断へ変える質問
資産母集団	固定資産・保全台帳	スイッチ情報・現場・予備品庫	重要設備の漏れと所在不明はあるか
遠隔接続	通信契約・ベンダー契約	ルーター・ログ・入退場	常時接続と終了済み接続を分けたか
アカウント	ID一覧	人事・委託先・設備設定	退職者と共有IDを追跡できるか
バックアップ	ジョブ成功記録	復元試験・設備変更票	必要版を目標時間内に戻せるか
事故	サイバー事故台帳	保全・品質・停止・保険記録	原因不明停止を含めたか
変更	変更申請	現行ロジック・加工版・品質承認	本番版と承認版が一致するか

照合1：固定資産から未管理装置を探す

固定資産から制御装置と産業用PCを抽出します。保全台帳へ設備番号で結びます。次に、ネットワーク観測と現場写真を重ねます。

固定資産にあり、現場にない資産は移設・除却を確認します。現場にあり、台帳にない資産は所有者と保守を特定します。償却済みでも稼働中なら評価します。

照合2：通信請求から隠れた回線を探す

回線、SIM、ルーターの月額請求を集計します。そこで、契約番号を設置場所へ対応させます。利用明細があれば通信時期を確認します。

一方、解約予定だけで除外しません。解約後も機器が残って再接続できる可能性があるためです。現物撤去と設定無効化まで確認します。

照合3：ベンダー入場と遠隔ログをOTサイバーDDで結ぶ

保守チケット、入退場、VPNログを日付で合わせます。日付照合では、現地作業と遠隔作業を分けます。作業内容が変更申請へつながるかも見ます。

ログがあるのにチケットがなければ、緊急作業か未承認かを確認します。反対に、チケットがあるのにログがなければ、別経路の可能性を調べます。

照合4：人事異動と設備アカウントを結ぶ

退職・異動者の一覧を基準日で確定し、ディレクトリ、VPN、踏み台、設備ローカルIDへ突き合わせます。人事上の異動日と権限終了日が一致するか比較します。

職務変更後も管理者権限が残る場合があります。必要性を再承認します。共通IDは、利用者名簿と保管方法を確認します。

照合5：バックアップ版と変更版を結ぶ

設備変更の日付とバックアップ取得日時を並べ、変更後に保存されているかを確認します。さらに、ファイル名だけでなく、内容差分やチェック値も使います。

最新だけを残す運用では、侵害前へ戻れない場合があります。そのため、世代数と保管期間は、検知までの想定時間から検討します。

照合6：停止記録とOTサイバーDDのアラート仮説を結ぶ

設備停止、品質異常、ネットワークアラートは、時計ずれと時差を補正して共通時刻へ並べます。時間帯が重なる事象について、同じ端末、通信経路、変更作業が関係するかを調べます。

時刻が一致しただけでは因果関係を確定できません。保全故障、電源障害、操作ミスなどの代替仮説も比較し、複数の証拠で絞り込みます。

照合7：顧客回答と実装を結ぶ

顧客質問票から重要項目を抽出します。具体的には、回答日当時の設定、規程、訓練を探します。現在の改善を過去へ遡って当てはめません。

差があれば、顧客影響、是正、通知を法務と検討します。そのうえで、顧客説明は技術チームだけで決めません。

サイバーリスクを費用・企業価値・契約へ反映する

OTサイバーDDの費用を七つに分ける

資産把握、ネットワーク、認証、監視、復旧、設備更新、運用人員に分けます。費用範囲には、製品費だけでなく、設計、試験、教育、停止を含めます。

投資目的は、必須是正、リスク低減、統合、成長投資に区別し、同じ投資へ二度値引きをかけないようにします。

見積りに停止と再認定を入れる

設備更新の見積りは工事費だけでは足りません。具体的には、停止中の限界利益、仕掛品、立上げ、初品検査、顧客承認を含めます。休日工事の割増も見ます。

停止損失は売上全額ではありません。算定には代替生産、在庫、挽回生産を反映します。原価計算DDの記事と計算前提をそろえます。

確度と時期を別々に表示する

確定発注、専門家概算、レンジ、不明を区分します。続いて、実施時期は、署名前、Day 1、100日、一年、更新時へ分けます。資金需要の山が見えるようにします。

不明をゼロへ置きません。一方、最悪値だけを採用しません。追加確認でレンジを狭められるかを示します。

停止シナリオを期待損失だけに閉じない

発生確率と損失の積は一つの参考です。しかし、稀でも会社存続へ影響する停止があります。顧客の単一供給、罰則、品質回収を別に表示します。

確率に十分な根拠がない場合は、定性幅を使います。そのため、数値の精密さで不確実性を隠しません。取締役会が前提を理解できる形にします。

価値診断へ正常収益力と将来投資を渡す

現在の保守不足で利益が高く見える場合があります。そのため、必要な運用費を正常化します。一方、一時的な更新費は継続費と分けます。

売却価格の検討は企業価値診断へ接続します。費用の時期、税務、資産価値は、公認会計士や税理士と確認します。

一般的なサイバー表明保証だけに頼らない

表明保証では、重要工場、対象ネットワーク、既知事故、遠隔接続、バックアップの範囲を定義します。「合理的な対策」という抽象語だけでは、売り手と買い手の期待がずれます。

一方、案件ごとに設備構成と既知事実が違うため、表明文言を共通雛形だけで決めません。調査で確認した事実と未確認範囲を弁護士へ渡し、法的な文言へ落とし込みます。

クロージング前後の是正をOTサイバーDDで分ける

切迫した外部接続や退職者IDは、前に直す候補です。一方、大規模分離は生産試験が必要です。買収後の計画へ置く場合があります。

クロージング前に是正する項目には、完了証拠を定めます。具体的には、設定画面だけでなく、通信停止、権限試験、運用開始を確認します。応急対策の期限も付けます。

価格調整・特別補償・留保を使い分ける

近く発生する設備更新は価格へ反映しやすい項目です。一方で、過去事故に起因する不確定請求には、特別補償を検討できます。証拠不足には留保や追加条件も考えます。

二重回収を防ぐため、補償上限、期間、通知、損失定義を整合させます。そのうえで、最終設計は法務・税務の助言を得ます。

サイバー保険の範囲を事故シナリオと照合する

なお、事業中断、復旧、第三者請求、身代金、専門家費用の扱いを確認します。OT設備や特定の古いシステムが除外される場合があります。

保険があるだけで残余リスクが消えるとは限りません。具体的には、待機期間、免責、通知、対策条件を見ます。保険者へ開示した内容との一貫性も確認します。

移行サービスの終了をクロージング条件から逆算する

認証、SOC、回線、バックアップを売り手が一時提供する場合があります。性能、事故対応、ログ、料金、終了支援を決めます。

移行サービスの終了前に、切替試験と復旧試験を行います。そのため、終了日だけを決めず、合格条件を契約へ置きます。

売り手が譲渡準備の30日で整えるOT資料

準備の目的は、見栄えのよい評価を作ることではありません。売り手は現状を再現できる証拠をそろえ、危険な変更を避けます。次の30日モデルは一例であり、重大な脅威があれば日程より安全を優先します。

準備1日目から3日目：責任者を置く

工場、情報システム、保全、品質、法務から責任者を選びます。その際、責任分界では、質問窓口と技術承認を分けます。外部の設備メーカーにも連絡担当を置きます。

秘密情報の閲覧者を限定します。同時に、緊急是正が必要な場合の承認経路も決めます。担当者個人の判断で設定を変更しないようにします。

準備4日目から6日目：工場とラインをOTサイバーDDの対象として棚卸しする

対象場所は、全拠点、倉庫、試作室、検査室を一覧にします。対象には、休止ラインや移設予定設備も含めます。各場所へ、責任者と稼働時間を付けます。

親会社または関連会社の敷地にある設備は、所有と運用を分け、取引後に使えるかを確認します。そのうえで、共同利用設備も境界へ載せます。

準備7日目から9日目：重要製品の工程を選ぶ

売上、粗利、顧客指定、代替困難性から製品を選びます。選んだ製品について、材料受入から出荷まで、設備と情報システムを結びます。品質記録が生成される地点も示します。

単一設備が複数製品を支える場合があります。逆に、売上上位でも外注へ振替できる工程があります。停止影響を製品別に考えます。

準備10日目から12日目：資産台帳を固定する

固定資産、保全、IP、ソフト、配置図を統合します。空欄には未確認理由を付けます。台帳の基準日時を明示します。

この期間に大規模スキャンを急いで実施しません。既存記録と安全な現場確認を先に使います。追加技術確認は影響評価後に計画します。

準備13日目から15日目：接続台帳を作る

接続経路は、工場内、工場間、外部、無線、可搬媒体に分けます。接続台帳には、回線番号、ルーター、契約先、利用目的、管理者を記録します。停止中の接続にも状態を付けます。

図面にない配線を見つけても、すぐ抜きません。そこで、用途と安全影響を確認し、観察時点の写真とポート情報を保存します。

準備16日目から17日目：OTサイバーDDでアカウントを照合する

従業員、退職者、委託先、共通IDを区分します。特に、権限照合では、管理者権限と遠隔権限を優先します。設備内のローカルIDも対象にします。

秘密情報を守るため、パスワード一覧をデータルームへ置きません。その代わり、存在、管理方式、変更証拠を安全に示します。秘密鍵や回復コードも同様です。

準備18日目から19日目：バックアップを実物確認する

保管先、最終取得日、世代、暗号化、管理者を一覧にします。設備変更後の版があるかを見ます。読めない媒体や所在不明品を分けます。

本番復元を無計画に行いません。そのため、過去の復元試験、メーカー確認、予備機試験を集めます。追加試験には停止と戻し方が必要です。

準備20日目から21日目：事故記録を統合する

IT、保全、品質、保険、顧客対応から記録を集めます。事故母集団には原因不明の停止も含め、発生日、影響、原因、是正、再発確認を並べます。

未確定原因はそのまま表示し、都合のよい原因へ変えません。なお、外部専門家報告には、共有可能範囲と依拠条件があります。

準備22日目から23日目：契約を依存度で並べる

契約台帳には、回線、クラウド、設備保守、監視、ソフトウェアを一覧にします。そのうえで、移管可否、更新期限、終了通知を付けます。個人名義や口頭契約を探します。

依存度が高い契約から原本を確認します。契約書がないままサービスが継続しているときは、権利義務を法務へ確認します。

準備24日目から25日目：顧客回答を集める

サイバー質問票、監査報告、改善依頼を顧客別にします。具体的には、回答した時点と現在を分け、未完了の約束に期限を付けます。

顧客名を必要に応じて匿名化します。ただし、買い手が契約影響を評価できる情報は残します。開示範囲を法務が確認します。

準備26日目から27日目：現地説明を試す

受注データから出荷までの案内順路を確認します。担当者は、知らないことを推測しないようにします。後日回答の方法を共有します。

写真禁止、盤開放禁止、端末接続禁止を明確にします。そのため、安全ルールは買い手と専門家へ事前通知し、調査品質と工場安全を両立させます。

準備28日目：未確認事項を経営へ上げる

未確認事項は、重大度、証拠不足、確認方法、期限で一覧にします。特に、問題と未確認を混ぜません。追加費用と日程への影響も示します。

経営は、取引前に確認する事項と買収後へ送る事項を決めます。そのうえで、決定理由を残します。現場へ判断を押し付けません。

準備29日目：OTサイバーDD直前の危険な即席対策を止める

調査直前に見栄えを整えようとして、無断のパッチ適用や回線切断を行ってはいけません。変更が必要なら、操業・品質への影響、試験方法、戻し方を先に承認します。ただし、切迫した攻撃には、定めた緊急手順で対応します。

応急対策をした場合は、変更前後の証拠を保存し、恒久対応の期限も付けます。変更を隠すと、評価の信頼を損ないます。

準備30日目：開示基準日を固定する

資産、接続、アカウント、事故、契約の版を固定します。その後の変更は、差分台帳へ追加します。事故や重大変更は継続開示します。

この基準日は、表明保証やクロージング条件の参照点になります。ただし、固定したから更新を止めるのではありません。安全運用を継続します。

OTサイバーDDの架空事例

以下の会社名、人物、数値、取引条件は、手順を説明するための架空設定です。実在企業や実在案件を示すものではありません。実務では、専門家が個別事実と適用条件を確認します。

架空事例1：夜間保守ルーターが台帳から消えていた

A社は、自動車向け切削部品を製造しています。売り手は「工場は外部から隔離」と説明しました。しかし、通信請求を照合すると、少額のSIM契約が毎月続いていました。

現地確認で、古い工作機械の背面にセルラールーターが見つかりました。そのルーターは、設備メーカーが夜間障害へ対応するための機器でしたが、契約書には接続時間とログ保存が明記されていませんでした。

調査チームは、直ちに回線を抜きません。まず、設備保証と緊急保守を確認しました。次に、接続先、認証、管理者、直近通信を調べました。侵害の証拠は確認されませんでしたが、追跡性が不足していました。

買い手は、クロージング前に常時接続を停止し、承認制VPNと踏み台へ切り替える計画を条件にしました。そのうえで、移行期間の故障対応も、メーカーと別紙で合意しました。

この例の要点は、月額請求と現物の照合です。ネットワーク図だけを見ていれば、回線を見落としていました。一方、弱点の発見だけで設備を止めると、納期へ影響した可能性があります。

架空事例2：復元試験を欠いたバックアップの落とし穴

B社は熱処理設備を運営し、管理画面では制御サーバーのバックアップが毎日成功していました。そのため、経営陣は、二時間で復旧できると認識していました。

OTサイバーDDで復元手順を確認すると、古いライセンスサーバーが必要でした。しかし、その装置は三年前に故障し、仮想化されていませんでした。炉ごとの最新パラメータも別端末にしか保存されていませんでした。

予備環境で復元試験をした結果、画面は起動しました。ところが、制御通信を再現できませんでした。メーカー技術者の手配にも四営業日が必要でした。

買い手は、想定停止を二時間から五日へ修正しました。そして、予備ライセンス、設定一括保存、年二回の試験費をモデルへ入れました。更新費の一部は価格へ反映しました。

この事例では、取得成功と工程復旧の違いが重要です。ファイルの存在ではなく、設備を安全に再開できる証拠を確認します。

架空事例3：検査閾値の変更者を特定できなかった

C社は半導体装置向けの精密部品を製造する架空会社です。買い手が品質履歴を時系列で比べると、不良率が一週間だけ極端に低い期間が見つかりました。

検査装置の閾値変更と同じ時期でした。しかし、装置は共有管理者IDで使われ、操作ログは七日で消えていました。変更申請も見つかりませんでした。

製品再検査では、出荷品への影響は確認されませんでした。ただし、誰がなぜ変えたかは確定できませんでした。調査チームは、意図的改ざんと断定しませんでした。

買い手は、個人ID、変更承認、ログ延長をクロージング後30日の必須対応にしました。そのうえで、対象期間の顧客対応費をレンジで確保し、契約には既知事項の開示を添付しました。

この例は、サイバーと品質の交点を示します。つまり、攻撃の証拠がなくても、完全性を証明できない状態は取引上の論点になります。

買い手・売り手のOTサイバーDDチェックリスト

買い手が署名前に確認するOT項目

• 対象拠点、重要製品、重要設備を取引範囲と一致させたか。
• 固定資産、保全、通信、現場から資産母集団を作ったか。
• 全ての遠隔接続、SIM、無線、可搬媒体を確認したか。
• 管理者、共有、退職者、委託先の権限を照合したか。
• ネットワーク図が現在の物理配線と一致するか。
• 重要設備のサポート終了と代替策を把握したか。
• バックアップを復元試験または代替証拠で確認したか。
• 工程別の復旧時間に品質再開時間を含めたか。
• 事故台帳を保全、品質、停止記録から再構築したか。
• 設備メーカーとクラウドへの依存を契約で確認したか。
• 顧客質問票の回答と実装が一致するか。
• 安全機能と通常制御の境界を専門家が確認したか。
• 是正費に設計、試験、停止、教育を含めたか。
• 価格、補償、前提条件、100日計画へ論点を渡したか。

売り手が準備するOT項目

• 工場、ライン、設備の責任者と基準日を明確にしたか。
• 償却済み、休止中、予備の装置を台帳へ入れたか。
• ネットワーク図と現地配線の差を一覧にしたか。
• 遠隔保守の契約、回線、ログを対応させたか。
• 退職者と契約終了ベンダーの権限を点検したか。
• PLC、CNC、検査、ロボットの復旧資産を整理したか。
• 原因不明停止を除外せず、事故履歴へまとめたか。
• 顧客監査の未完了事項へ期限と担当を付けたか。
• 個人名義のクラウドやライセンスを特定したか。
• 質問へ推測で回答しないルールを共有したか。
• パスワードや秘密鍵を通常のデータルームへ置いていないか。
• 評価目的の無断スキャンや即席変更を止めたか。
• 未確認事項を経営へ報告し、追加確認方法を示したか。
• 重大事故と変更を継続開示する経路を決めたか。

買い手の現地訪問当日チェック

• 持込み機器と撮影範囲を承認したか。
• 現場案内者だけでなく、保全・品質担当へ質問したか。
• 受注データから工作機械まで実経路を追ったか。
• 機械背面、保全室、予備品庫を安全に確認したか。
• 遠隔保守の開始と終了を証拠で確認したか。
• 異常時の最初の行動を夜勤担当にも聞いたか。
• 観察事実と追加仮説を別々に記録したか。

売り手のクロージング前チェック

• 合意した是正の完了条件を満たしたか。
• 基準日後の新規接続と事故を追加開示したか。
• ライセンス、回線、保守の移管同意を得たか。
• Day 1の管理者権限と緊急連絡先を引き渡したか。
• 共有サービスの終了日と切替試験を確認したか。
• バックアップの最新版と復旧手順を封印管理したか。
• 退職予定者から重要知識を移管したか。

Day 1と100日計画へ調査結果を引き継ぐ

Day 1：OTサイバーDD後も停止権限を変え過ぎない

買収直後に全権限を一括変更すると、設備へ入れない可能性があります。そのため、先に重要IDを確認し、緊急アクセスを確保します。変更は設備ごとに試験します。

売り手側の不要権限は計画的に停止し、誰が残す判断をしたかを記録します。ただし、期限のない例外を作りません。

Day 1：重大事故の連絡網を再確認する

重大事故の連絡網には、工場長、IT、安全、品質、経営、外部専門家を載せます。また、保険会社や顧客への連絡条件を役割表へひも付け、休日に到達テストを行います。

各連絡先には判断権限を記し、技術者が単独で対外説明しない承認経路を定めます。初動記録の様式は、夜勤者を含む関係者へ事前配布します。

1日から10日：資産と接続を固定する

台帳には調査時点からの差分を反映します。そのうえで、新たな接続を承認制にし、重要設備の設定とバックアップを確保します。

直ちに全てを統合しません。現状を安定させ、観測します。切迫した経路だけを安全に封じます。

11日から30日：遠隔保守と権限を整える

ベンダーごとに申請、時間制限、記録を導入します。同時に、退職者と不要権限を閉じ、非常用IDには保管と監査を設けます。

変更後、保守を実施できるかを試します。そのため、セキュリティ向上で復旧力を落とさないことが重要です。

31日から50日：OTサイバーDDの復旧訓練を行う

31日から50日には、重要工程を一つ選び、安全な予備環境で復元します。復旧に必要なファイル、ライセンス、予備部品、要員を実物でそろえ、完了までの時間を測ります。

失敗項目には責任者と期限を付け、再試験の条件も決めます。実測結果でRTOを更新し、想定との差を経営へ報告します。

51日から70日：ネットワーク改善をOTサイバーDD後に段階実施する

必要通信を定義し、広い許可を縮めます。同時に、重要ゾーンへの入口を監視し、変更ごとに工程試験と戻し方を用意します。

一度に全工場へ展開せず、代表ラインで確認した学びを反映します。ただし、設備メーカーの保証条件も守ります。

71日から90日：顧客・契約を整合する

顧客質問票と現在対策を更新します。同時に、未完了項目の説明を統一し、保守・クラウド契約へ事故通知等を反映します。

誇張した回答を避け、計画は計画として期限を示します。そのうえで、必要な顧客承認を法務と品質が管理します。

91日から100日：OTサイバーDDの残余リスクを取締役会へ上げる

完了、進行中、受容、不明へ分類します。費用、停止、顧客、安全への影響を示します。受容には期限と再評価日を付けます。

なお、100日計画は終点ではありません。継続監査と投資計画へ移します。統合作業は金属加工M&AのPMI記事とも接続できます。

譲渡相談とM&Aの進め方へ接続する

売り手は全課題の解消を待たずに相談できます。早い段階なら、調査範囲、資料の開示方法、危険な即席変更を避ける手順を先に決められます。売却の全体像は会社売却の案内とM&Aの流れで確認できます。

個別の開示方法や取引日程は、売り手向け相談窓口から相談できます。また、制度や実務を調べるときはコラム一覧を、取引イメージを確認するときはM&A事例一覧を参照できます。

調査成果物を意思決定へ引き継ぐ

経営要約は五ページ以内にする

経営向けには、重要工程、侵入経路、停止影響、費用幅、推奨条件を示します。特に、解消できなかった不明点は独立表示します。技術用語には、操業上の意味を添えます。

短くするために前提を消しません。そのため、各結論から詳細資料へ戻れる番号を付け、投資委員会が最悪ケースとベースケースを比較できる形にします。

技術台帳は証拠リンクを持たせる

各資産へ、図面、設定、写真、契約、バックアップを結びます。そのうえで、確認日と確認者も記録します。推測値と実測値を分けます。

台帳の更新責任者を決めます。取引時だけ精密でも、買収後に陳腐化すれば役立たないからです。保全変更と台帳更新を同じワークフローへ入れます。

発見事項を一件一葉にするOTサイバーDDの成果物

事実、証拠、攻撃仮説、工程影響、対応案、費用を分けます。現在の侵害と潜在的な弱点も区別します。証拠不足は、確度欄へ表示します。

古いOSだけで「重大」としません。到達可能性、補完策、復旧力を示します。ただし、安全影響があれば金額と別に優先します。

是正台帳は完了条件を具体化する

「多要素認証を導入」のような作業名だけでは足りません。具体的には、対象接続、利用者、例外、ログ、試験を完了条件にします。運用開始日も必要です。

証拠として設定、接続試験、教育記録を残し、製品を購入しただけで閉じません。そのうえで、残る例外には期限を付けます。

契約別紙は資産範囲を定義する

対象範囲は、工場名、建屋、ライン、ネットワーク、クラウド、共有サービスで定義します。具体的には、設備番号と基準日を使い、「対象システム一式」の曖昧な表現を避けます。

ただし、最終的な法的文言は弁護士が作成します。技術報告と契約で名称がずれないよう、用語表を共有します。

Day 1資料は最初の行動を書く

Day 1資料の冒頭には、管理者への連絡、事故連絡、重要設備の停止権限を記します。長期構想より、最初の一日に誰が何を判断するかを優先します。また、夜勤担当者向けには短縮版を用意します。

その後、100日計画、年間投資、継続監査へつなぎます。引継ぎの受領者と受領日を記録し、報告書の置き忘れを防ぎます。

残余リスク受容を期限付きにする

直せない事項は、経営が受容する場合があります。その際は、理由、補完策、監視、再評価日を記録し、永久的な例外へしません。

設備更新や顧客再認定の日程で対応時期が決まることがあります。したがって、技術部門だけでなく、営業、品質、財務が承認へ参加します。

買収後のOTサイバーDD効果を行動で測る

脆弱性件数だけでは改善を測れません。具体的には、未知接続の解消率、復元試験の成功、権限失効時間、重大アラート確認時間を使います。工程停止を伴う変更の成功率も有用です。

なお、指標を達成するために事故を少なく記録してはいけません。報告件数の増加が、初期には検知改善を示す場合もあります。経営は背景とともに読みます。

OTサイバーDDに関するFAQ

Q1．OTサイバーDDと通常のITデューデリジェンスは何が違いますか。

対象と損失の出方が違います。OTサイバーDDは、制御機器、工作機械、復旧、停止、安全、品質を中心にします。一方、認証やメール等のIT基盤との接点も調べます。

Q2．インターネットへ接続していない工場なら調査は不要ですか。

不要とは限りません。たとえば、USB、保守PC、工場間回線、セルラーモデムが外部との経路になります。さらに、設定消失や内部誤操作からの復旧力も評価対象です。

Q3．小規模な町工場にもOTサイバーDDが必要ですか。

必要性は工程と取引影響で決めます。人員が少なくても、顧客の単一供給源なら停止影響は大きくなります。そのため、手順を現実的に絞り、重要設備から確認します。

Q4．稼働中の設備へ脆弱性スキャンを実施してよいですか。

古い制御機器では、能動スキャンが通信や処理へ影響する可能性があります。そのため、無計画な実施は避けます。まず、受動情報を使い、必要な試験はメーカーと設備責任者の承認下で行います。

Q5．古いOSが一台あれば重大リスクですか。

OS名だけで判定しません。具体的には、到達可能性、悪用状況、分離、監視、復旧、更新計画を見ます。ただし、外部へ直接露出し補完策がなければ、優先度は高くなります。

Q6．買収前に全てのパッチを適用する必要がありますか。

一律適用が適切とは限りません。たとえば、メーカー未承認の更新は設備保証や制御動作へ影響します。そのため、互換性、停止影響、試験可否を確認します。適用しない項目には、補完策、責任者、再評価日を置きます。

Q7．VPNと多要素認証があれば遠隔保守は安全ですか。

重要な対策ですが、それだけでは十分とは限りません。具体的には、接続時間、権限、踏み台、操作ログ、作業後の終了を確認します。さらに、委託先端末の管理状態も確かめます。

Q8．ISO/IEC 27001認証があればOTサイバーDDを省略できますか。

認証範囲に工場OTが含まれない場合があります。そのため、認証取得だけを根拠とする省略は勧められません。個別設備の復旧力と遠隔接続は別途確認します。

Q9．工場システムガイドラインVer 1.1は法的義務ですか。

公表資料は対策検討の重要な参照先です。ただし、個別会社に生じる義務は、法令、業法、契約、顧客要求で確認します。ガイドラインだけで法的結論を断定しません。

Q10．2026年8月時点でSCSの★3・★4評価は運用済みですか。

経済産業省の構築方針は、★3・★4の申請受付を2026年度末頃に始める計画を示します。したがって、2026年8月22日時点で申請受付済みとは扱いません。また、開始時期はIPAの更新情報で確認します。

Q11．SCSだけで工場OTを評価できますか。

SCSは、一般的なIT基盤に該当しない製造環境等のOTシステムを直接の対象としていません。そのため、工場ガイドライン等を併用し、制御、停止、安全、品質を追加確認します。

Q12．SCSの要求事項・評価基準の解説書は公表済みですか。

★3・★4の要求事項・評価基準は、2026年4月21日に公表済みです。一方、その解説書はIPA公式ページで同年10月頃の公開予定とされ、2026年8月22日時点では未公表です。したがって、要求事項・評価基準と解説書を分けて確認します。

Q13．バックアップの成功ログがあれば十分ですか。

十分ではありません。必要な設定、ライセンス、工具、技術者をそろえ、復元できることを確認します。そのため、安全な予備環境での試験を計画します。さらに、失敗時の記録と再試験条件も残します。

Q14．復元試験は本番ラインで行いますか。

無断実施は避け、予備機、シミュレーター、計画停止を優先します。ただし、本番ラインでの試験が不可欠な場合もあります。その場合は、変更承認、安全・品質確認、戻し手順を事前に整えます。

Q15．過去に事故がなければOTサイバーDDの評価は高くなりますか。

事故ゼロだけでは判断できません。検知やログが弱い工場は、事故を把握できていない可能性があります。そのため、停止記録、品質異常、保全記録も照合します。

Q16．ログが残っていない場合は侵害ありと判断しますか。

直ちに侵害ありとは断定しません。ログ不足は、侵害がなかったことの証明にはなりません。したがって、侵害を示す証拠不足と、不在を示す証拠を分けます。さらに、追加調査、契約保護、買収後監視で不確実性を扱います。

Q17．共有アカウントを例外なく廃止しますか。

個人IDを基本にします。ただし、非常用などで共有IDを残す場合は、利用者、保管方法、操作記録、認証情報の変更を管理します。また、廃止前には設備依存を試験します。

Q18．OTサイバーDDは何週間かかりますか。

必要期間は、拠点数、設備数、資料の整備状況、現地確認の範囲で変わります。安全な技術確認やベンダー照会には時間を要します。そのため、案件日程から逆算し、重要工程を先に見ます。

Q19．売り手は弱点を全て修正してから相談しますか。

全課題の完了を待つ必要はありません。早期に相談すれば、切迫項目、開示方法、価格への反映、買収後計画を整理できます。そのため、未完了項目には証拠と改善期限を付けます。ただし、評価目的の危険な即席変更は避けます。

Q20．買収後に過去の侵害が分かったらどうしますか。

まず、安全確保、封じ込め、証拠保全を行います。次に、侵害時期と影響範囲を調べます。そのうえで、契約通知、顧客・行政対応を確認し、専門家の評価前に責任を断定しません。

Q21．サイバー保険があれば設備更新費も補償されますか。

設備更新費の補償可否は保険契約によります。たとえば、老朽更新、改善投資、事故復旧は別に扱われる場合があります。そのため、対象事故、除外、待機期間、免責、通知期限を保険専門家へ確認します。

Q22．設備メーカーが対策済みと言えば十分ですか。

メーカーの説明は有力な証拠ですが、対象型式、版、設定を確認します。一方、工場側のネットワークと認証は別論点です。また、声明の発行日と適用範囲を見ます。

Q23．SBOMを受領すれば脆弱性管理は完成しますか。

ただし、受領だけでは完成しません。対象設備との対応、更新、影響判断、対策決定が必要です。メーカー通知を継続して受ける窓口を設け、SBOMと設備台帳の版も対応させます。

Q24．安全PLCへセキュリティ試験を直接行えますか。

安全PLCへの無断試験は行いません。誤動作が人身安全へ影響し得るためです。そのため、設備メーカーと安全専門家の管理下で計画します。可能なら本番設備ではなく試験環境を使います。

OTサイバーDDの一次資料と更新確認先

• 経済産業省「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドラインVer 1.1」
• 経済産業省「中小規模製造事業者向け工場セキュリティ資料の公表」
• 経済産業省「工場サブワーキンググループ」
• 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度」
• IPA「セキュリティ対策評価制度の詳細」
• IPA「SCS評価制度の要求事項・評価基準」
• IPA「情報セキュリティ10大脅威 2026」
• 経済産業省「中小企業の情報セキュリティ対策ガイドライン」
• 経済産業省「サイバーセキュリティ経営ガイドライン」
• JPCERT/CC「制御システムセキュリティ」
• e-Gov法令検索「サイバーセキュリティ基本法」

公的資料は、OTサイバーDDの確認項目を設計する入口です。そのうえで、対象会社の契約、顧客要求、設備仕様、所在地、取引時点の最新版を別に確認してください。SCSの要求事項・評価基準は公表版を保存し、未公表の解説書は公開後に版と内容を再点検します。

まとめ：OTサイバーDDで工場を安全に再開できる証拠を作る

OTサイバーDDの質は、脆弱性の件数だけでは決まりません。全資産から母集団を作り、接続、権限、変更、復旧を照合します。そして、停止、安全、品質、顧客への影響を経営判断へ変えます。

一方、買い手は、古い設備を一律に切り捨てず、補完策と更新時期を見ます。他方、売り手は、不明点を隠さず、証拠と改善計画を示します。両者が停止条件を共有すると、買収後の混乱を減らせます。