工場を止めたのは誰の設定か

OT・Azure・委託先を一枚の責任分界表にする

2026年7月のOTデータコネクタ対応から考える、製造業の新しいセキュリティガバナンス

※本記事は、2026年7月14日時点のMicrosoft公式情報を基に作成しています。

工場設備は生産技術部が管理する。

社内ネットワークは情シスが管理する。

Azureはクラウド担当者が管理し、セキュリティ監視はSOC、装置の保守は装置メーカーや保守ベンダーに委託する。

製造業では、このような役割分担が珍しくありません。

しかし、工場設備からAzureへ稼働データを送り、Azure上の分析結果を生産計画や保守判断に利用する現在、OTとクラウドを別々の世界として管理することには限界があります。

2026年7月、Microsoft Security Exposure Managementは、Armis、Dragos、ForescoutのOTデータコネクタをサポートしました。

サードパーティのOTセキュリティ製品が把握しているOT資産や脆弱性情報をMicrosoft Defenderポータルへ取り込み、IT資産やクラウド資産と共に確認する方向が示されたのです。

ただし、ここで注意しなければなりません。

リスクが一つの画面に表示されたからといって、修正する権限まで一つになったわけではありません。

Defender上で脆弱性が見えたとしても、実際に修正できるのは誰でしょうか。

装置ベンダーでしょうか。

工場の生産技術担当者でしょうか。

情シスでしょうか。

それとも、Azure担当者でしょうか。

結論：統合すべきなのは管理画面だけではない

OTデータコネクタによって、工場の資産とIT・クラウド資産を横断して確認しやすくなります。

しかし、製造業に本当に必要なのは、単なる「見える化」ではありません。

必要なのは、次の五つを一枚の責任分界表にまとめることです。

┌─────────────────────────────┐
│ ① 誰がリスクを検知するのか                    │
│    SOC・セキュリティ担当                      │
└─────────────────────────────┘
                         ↓
┌─────────────────────────────┐
│ ② 誰が影響を判断するのか                      │
│    生産技術・工場責任者・資産所有部門          │
└─────────────────────────────┘
                         ↓
┌─────────────────────────────┐
│ ③ 誰が修正方法を決めるのか                    │
│    装置ベンダー・保守会社・Azure担当           │
└─────────────────────────────┘
                         ↓
┌─────────────────────────────┐
│ ④ 誰が停止を決めるのか                        │
│    工場長・生産責任者・経営層                  │
└─────────────────────────────┘
                         ↓
┌─────────────────────────────┐
│ ⑤ 誰が修正・復旧を実行するのか                │
│    生産技術・情シス・クラウド担当・委託先      │
└─────────────────────────────┘

一つの脆弱性に対して、

• 見つける人

• 判断する人

• 止める人

• 直す人

• 再開を承認する人

は、必ずしも同じではありません。

1．2026年7月、MicrosoftがOTデータコネクタを追加

Microsoft Security Exposure Managementは、2026年7月の更新で、次の三つのOTデータコネクタをサポートしました。

OTプラットフォーム	主な接続情報	取り込まれる情報の例
Armis	テナントホスト名、クライアントID、クライアントシークレット	デバイスID、種類、ベンダー、モデル、OS、ファームウェア、シリアル番号、サイト、ネットワーク情報
Dragos	ホスト名、APIキー、APIシークレット	ホスト名、IP・MACアドレス、OS、ベンダー、モデル、ファームウェア、センサー、ゾーン、重要度
Forescout	エンドポイント、APIキー	ホスト名、IP・MACアドレス、OS、ベンダー、モデル、ファームウェア、重要度、エッジコレクター

各コネクタから取得できる正確な項目は、OTプラットフォームやコネクタによって異なります。

図1　OT情報がDefenderポータルへ集約される流れ

┌──────────┐
│   Armis    │
└─────┬────┘
      │
┌──────────┐
│  Dragos    │
└─────┬────┘
      │
┌──────────┐
│ Forescout  │
└─────┬────┘
      │
      │ OT資産・ファームウェア・重要度・脆弱性
      ↓
┌─────────────────────────────┐
│ Microsoft Security Exposure Management     │
│          Microsoft Defenderポータル         │
├─────────────────────────────┤
│ ・デバイスインベントリ                     │
│ ・OTコンテキスト                           │
│ ・資産の重要度                             │
│ ・脆弱性情報                               │
│ ・Exposure Graph                           │
│ ・Advanced Hunting                         │
└─────────────────────────────┘
      │
      ├──────────┬──────────┐
      ↓          ↓          ↓
     SOC       情シス      経営・工場
   検知・調査   対応管理    リスク判断

Microsoftの説明では、OTデータコネクタによって、OT資産を他のデバイスと共に表示し、デバイスインベントリへOT固有の情報を追加し、IT・OT環境を横断して脆弱性を調査できるようになります。

2．「一緒に見える」と「一緒に直せる」は違う

ここが、今回の更新を理解するうえで最も重要な点です。

Microsoftの公式文書が説明しているOTデータコネクタの主な役割は、次のとおりです。

• 外部OTプラットフォームからデータを取り込む

• データをExposure Graph内で正規化する

• デバイスインベントリを強化する

• 資産の重要度やOTコンテキストを付加する

• 脆弱性を検索・調査しやすくする

外部データコネクタから取り込まれた情報は、Exposure Graph、デバイスインベントリ、Attack Surface Map、Advanced Huntingなどで利用されます。

しかし、これによって次の権限まで自動的に移転するわけではありません。

Defender上でできること	自動的にはできないこと
OT資産を確認する	PLCや制御装置の設定を変更する
脆弱性を確認する	ファームウェアを更新する
資産の重要度を確認する	装置の停止可否を判断する
OTとITの情報を並べて調査する	工場ネットワークを遮断する
リスクを優先順位付けする	生産ラインを安全停止する
検出元を確認する	ベンダー保証の適用可否を決める
対応状況を追跡する	メンテナンス日時を決定する

つまり、OTデータコネクタは、基本的には判断材料を統合する仕組みとして捉えるべきです。

修正・停止・復旧の実行権限は、工場、情シス、Azure担当、装置ベンダーなどに引き続き分散しています。

図2　可視化権限・変更権限・停止権限は別物

【可視化権限】
Microsoft Defenderで
資産・脆弱性・重要度を見る
       │
       │ ＝同じではない
       ↓
【変更権限】
ファームウェア、設定、
ネットワーク、Azureを変更する
       │
       │ ＝同じではない
       ↓
【停止権限】
装置、ライン、工場を
止めることを決定する

この三つを混同すると、事故対応の際に次のような会話が発生します。

SOC「重大な脆弱性です。至急修正してください」 情シス「その装置は当社では変更できません」 生産技術「メーカーの承認が必要です」 装置メーカー「保守契約の対象外です」 工場長「それで、止める必要があるのですか」

リスクが見えてから責任者を探していたのでは、対応が遅れます。

3．製造業には少なくとも七種類の権限がある

OT・Azure環境の責任分界を整理する際には、「管理者」という言葉を一つにまとめてはいけません。

表1　OT・Azureに存在する主な権限

権限	主な内容	想定される担当者
閲覧権限	Defender上の資産・脆弱性・推奨事項を見る	SOC、情シス、セキュリティ担当
コネクタ管理権限	OTデータコネクタを接続・変更・切断する	セキュリティ管理者、Defender管理者
OTプラットフォーム管理権限	Armis、Dragos、ForescoutのAPIや設定を管理する	OTセキュリティ担当、委託先
OT装置変更権限	PLC、HMI、産業用PC、ゲートウェイを変更する	生産技術、装置ベンダー
ネットワーク変更権限	VLAN、Firewall、IT／OT境界を変更する	情シス、ネットワーク担当
Azure変更権限	Azure VM、IoT、Storage、ネットワーク、IDを変更する	Azure担当、クラウド運用会社
操業停止・再開権限	ラインや工場の停止・再開を判断する	工場長、生産責任者、経営層

外部データコネクタの構成には、Microsoft Entra IDの所定の管理者ロール、またはMicrosoft Defender統合RBACのアクセス許可が必要です。

Microsoftは、可能な限り権限の少ないロールを使用し、グローバル管理者の利用を緊急時などに限定することを推奨しています。

しかし、ここで付与されるのは、Defender上のデータコネクタやExposure Managementを管理する権限です。

その権限を持つ担当者が、OT装置のファームウェアを更新できるとは限りません。

表2　「管理者」という言葉の混同例

呼び方	実際に持っている権限	持っていない可能性が高い権限
Defender管理者	コネクタ、Exposure Management、セキュリティ設定	PLC変更、ライン停止
Azure管理者	Azureリソース、RBAC、ネットワーク、ログ	装置メーカー独自設定
OT管理者	OT監視製品、資産情報、センサー	Azureサブスクリプション変更
生産技術担当	装置設定、工程、保守調整	Defenderの設定変更
SOC担当	検知、分析、エスカレーション	操業停止の最終判断
装置ベンダー	製品保守、対応ファームウェアの判断	工場全体の経営判断

4．典型例：Defenderに重大な脆弱性が表示された

次のようなケースを考えてみます。

工場の製造装置
   ↓
産業用PC／OTゲートウェイ
   ↓
工場DMZ
   ↓
Azure IoT・Storage・分析基盤

OTセキュリティプラットフォームが、産業用PCに重大な脆弱性を検出したとします。

その情報がOTデータコネクタを通じて、Microsoft Defenderポータルに表示されました。

図3　検出から修正までの現実的な流れ

① OTプラットフォームが脆弱性を検出
          ↓
② OTデータコネクタがDefenderへ取り込み
          ↓
③ SOCが重大度・資産重要度を確認
          ↓
④ 生産技術が工程・安全・停止影響を確認
          ↓
⑤ 装置ベンダーが更新可否を確認
          ↓
⑥ 情シス・Azure担当が迂回経路を確認
          ↓
⑦ 工場責任者が停止・変更日時を承認
          ↓
⑧ 生産技術または装置ベンダーが変更
          ↓
⑨ SOCが再検知・ログ・残存リスクを確認
          ↓
⑩ 工場責任者が再開を承認

このケースで、SOCが脆弱性を見つけても、SOCには装置を変更する権限がないかもしれません。

生産技術には変更権限があっても、使用中のファームウェアが装置メーカーの保証対象か判断できないかもしれません。

装置ベンダーは技術的な変更方法を知っていても、ラインを止める経営判断はできません。

情シスやAzure担当は、クラウド側の通信制御や資格情報の停止はできても、OT装置を安全に停止する手順を知らない可能性があります。

したがって、責任分界表には単に「脆弱性対応：情シス」と書くのではなく、工程を分解して記録しなければなりません。

5．OTとAzureを一枚にするRACI表

RACIは、業務ごとに次の四つを整理する方法です。

記号	意味
R：Responsible	実際に作業を実行する担当者
A：Accountable	最終的な説明・承認責任を持つ者
C：Consulted	判断前に協議する相手
I：Informed	結果を報告する相手

以下は、製造業における一例です。

組織、設備、安全管理体制、保守契約によって調整する必要があります。

表3　通常運用時のRACI例

作業	工場長	生産技術	情シス	Azure担当	SOC	装置ベンダー
OT資産の登録	I	A／R	C	I	I	C
資産重要度の決定	A	R	C	C	C	I
OTコネクタの構成	I	C	A	C	R	C
API資格情報の管理	I	C	A／R	C	C	C
Defender上の監視	I	I	C	C	A／R	I
Azure依存関係の登録	I	C	C	A／R	I	I
保守期限の管理	I	A／R	I	I	I	C
脆弱性の一次評価	I	C	C	C	A／R	C
ファームウェア適合確認	I	A	I	I	C	R
定期変更の承認	A	R	C	C	I	C

表4　インシデント発生時のRACI例

作業	工場長	生産技術	情シス	Azure担当	SOC	装置ベンダー
アラートの確認	I	C	C	C	A／R	I
対象資産の特定	I	A／R	C	C	R	C
生産影響の評価	A	R	I	I	C	C
Azure側の封じ込め	I	C	C	A／R	C	I
IT／OT境界の遮断	C	C	A／R	C	C	I
装置変更方法の決定	I	A	I	I	C	R
ライン停止判断	A	R	I	I	C	C
証跡保全	I	C	C	C	A／R	C
修正作業	I	A／R	C	C	I	R
復旧確認	A	R	C	C	C	C
再開承認	A／R	C	I	I	I	C

RACI表だけでは不十分

RACI表に「情シス：R」と書いてあっても、実際の権限がなければ作業はできません。

次の四つを一致させる必要があります。

責任分界表・RACI
        ↓ 一致させる
実際のアカウント・RBAC・API権限
        ↓ 一致させる
保守契約・委託範囲・作業手順
        ↓ 一致させる
ログ・チケット・承認記録

表5　RACIと実態の照合項目

文書上の記載	確認する技術的証拠
SOCがコネクタを管理する	Defender統合RBAC、Entraロール
生産技術が装置を変更する	装置管理アカウント、操作手順
ベンダーがファームウェアを更新する	保守契約、対応機種一覧、作業記録
Azure担当が通信を遮断する	Azure RBAC、Firewall、NSG、ルート設定
工場長が再開を承認する	再開承認書、ワークフロー、議事録
情シスがログを保管する	Log Analytics、SIEM、保存期間設定

責任分界表は、法令上または契約上の責任を自動的に確定する文書ではありません。

しかし、実際の運用権限、連絡先、判断者を明確にし、監査やインシデント対応時の混乱を減らす重要な基礎資料になります。

6．「止める」の意味を分ける

OTインシデント対応では、「止める」という言葉が非常に危険です。

人によって、意味している操作が違うからです。

表6　六種類の「停止」

停止の種類	実際に止まるもの	注意点
コネクタの切断	Defenderへのデータ取り込み	攻撃や装置動作は止まらない
アラートのクローズ	SOC上の対応チケット	脆弱性や侵害は解消しない
クラウド資格情報の停止	Azureへの認証・APIアクセス	OT装置は動作を続ける可能性がある
IT／OT境界の遮断	ネットワーク通信	生産監視、時刻同期、遠隔保守へ影響する可能性
装置の安全停止	特定装置・制御工程	製造工程と安全手順に従う必要がある
ライン・工場停止	生産活動	経営・安全・納期への重大な影響がある

図4　セキュリティ封じ込めと設備停止は別の判断

【SOC・情シスが判断しやすい領域】
・アカウント無効化
・クラウド通信遮断
・リモート接続停止
・Firewallルール変更
              │
              │ 影響確認が必要
              ↓
【生産技術・工場が判断する領域】
・装置の安全停止
・工程の停止
・ライン停止
・復旧順序
・再稼働

特に重要なのは、ネットワークを遮断することが、必ずしも安全停止を意味しないという点です。

通信遮断によって、監視不能、制御不能、データ欠損、フェイルセーフ動作などが発生する可能性があります。

NIST SP 800-82 Revision 3も、OTのセキュリティを考える際には、一般的なIT環境だけでなく、性能、信頼性、安全性というOT固有の要件を考慮する必要があると説明しています。

7．推奨する停止判断フロー

図5　OT・Azureインシデントの停止判断

① Defender／OT製品で異常を検知
              ↓
② SOCが誤検知・対象資産・重大度を確認
              ↓
③ 資産台帳から以下を確認
   ・工場、ライン、工程
   ・装置所有者
   ・Azure依存関係
   ・保守ベンダー
   ・停止権限者
              ↓
④ 生産技術が安全・操業影響を確認
              ↓
⑤ 装置ベンダーが技術的影響を確認
              ↓
⑥ 一時封じ込め案を比較
   A：Azure資格情報停止
   B：外部接続のみ遮断
   C：IT／OT境界遮断
   D：装置単体停止
   E：ライン停止
              ↓
⑦ 事前基準に基づき停止を承認
              ↓
⑧ 実行前の証跡を保全
              ↓
⑨ 停止・変更を実行
              ↓
⑩ 復旧試験・監視強化
              ↓
⑪ 再開承認

緊急時に工場長や装置ベンダーと連絡が取れない可能性も考える必要があります。

そのため、少なくとも次の二段階を規程化します。

段階	権限
緊急一時封じ込め	SOC・情シスが、事前に許可された範囲で認証や外部通信を一時停止する
設備停止・恒久対応	工場責任者、生産技術、装置ベンダーが安全性と操業影響を確認して決定する

8．アラート対応基準を作る

Defenderに表示されるすべてのリスクを、同じ優先度で処理することはできません。

資産の重要度、攻撃可能性、生産への影響、Azureとの接続状況、変更可能時期を組み合わせて判断する必要があります。

表7　OTアラート対応基準の例

区分	事象例	初動	主な判断者
S1：重大	不正な制御操作、認証情報侵害、安全への影響、複数ラインへの拡大	緊急連絡、証跡保全、一時封じ込め、停止判断	工場長、生産技術、SOC、経営層
S2：高	重要装置の悪用可能な脆弱性、外部接続された旧ファームウェア	通信制限、ベンダー照会、臨時保守計画	生産技術、情シス、ベンダー
S3：中	代替策がある脆弱性、限定されたネットワーク内のリスク	変更計画、監視強化、保守日程調整	生産技術、情シス
S4：低	情報不足、重要度の低い資産、直ちに悪用困難	台帳更新、定例レビュー	資産所有者

表8　優先度を決める評価軸

評価軸	確認する内容
資産重要度	止まった場合に生産・安全・品質へ影響するか
接続範囲	インターネット、社内IT、Azure、他工場へ接続しているか
操作能力	読取りだけか、制御・書込みが可能か
脆弱性	悪用方法や攻撃コードが知られているか
代替策	通信制限、監視強化、機能停止などで軽減できるか
修正可能性	ベンダーが修正版を提供しているか
停止影響	保守のために装置やラインを止める必要があるか
復旧可能性	バックアップ、予備機、ロールバック手順があるか
契約	保守範囲、作業費、緊急対応条件が明確か

9．IT／OT資産台帳に必要な項目

OTデータを取り込めば、すべての資産が自動的かつ正確に統合されるとは限りません。

Microsoftは、MACアドレス、クラウドリソース識別子などの十分な識別属性がない場合、デバイスが統合インベントリ上で正しく照合・表示されない可能性があると説明しています。

その場合でもAdvanced Huntingに情報が表示される可能性がありますが、これは現時点の正規化・オンボーディング処理における既知の制限です。

したがって、IT／OT資産台帳には、表示名だけでなく、照合に使える識別情報を記録する必要があります。

表9　IT／OT統合資産台帳のひな型

分類	記録項目
基本情報	資産管理番号、資産名、工場名、建屋、ライン、工程
識別情報	ホスト名、IPアドレス、MACアドレス、シリアル番号、装置ID
製品情報	ベンダー、型番、OS、ファームウェア、導入日
OT情報	ゾーン、セル、センサー、制御対象、プロトコル
重要度	生産影響、安全影響、品質影響、停止許容時間
管理者	資産所有部門、技術管理者、代替担当者
委託先	装置ベンダー、保守会社、SIer、緊急連絡先
クラウド依存	Azureサブスクリプション、リソース、IoT接続、API
ネットワーク	VLAN、Firewall、IT／OT境界、外部接続
権限	読取り、変更、制御、停止、再開
保守	保守契約、更新可否、メンテナンス時間帯
復旧	バックアップ、予備機、ロールバック手順
ログ	OT製品、Defender、Azure、装置ログの保存先
ライフサイクル	サポート終了日、更新予定、廃止予定
コネクタ	検出元、コネクタ名、最終同期時刻

台帳記載例

項目	記載例
資産名	第2工場・組立ラインA・産業用PC
資産所有者	生産技術部長
技術管理者	第2工場設備保全担当
装置ベンダー	○○装置株式会社
Azure接続	IoT Hub経由で稼働データを送信
書込み制御	Azureからの直接制御なし
重要度	高・停止すると組立ライン全体が停止
停止権限者	第2工場長
緊急遮断者	情シスネットワーク当番
ファームウェア更新	ベンダー立会い必須
保守可能時間	日曜8時から12時
ロールバック	予備SSDから復旧
ログ	Dragos、Defender、Azure Activity Log
次回レビュー	2026年9月30日

10．OTコネクタの資格情報も重要資産になる

OTコネクタを構成するためには、各OTプラットフォームのAPIキー、クライアントシークレットなどが必要です。

これは単なる初期設定用の文字列ではありません。

外部OTセキュリティ製品とMicrosoft Defenderを結ぶ、重要な機械ID・資格情報です。

表10　コネクタ資格情報の管理項目

管理項目	決める内容
所有者	誰が資格情報の利用を承認するか
管理者	誰が発行・更新・失効を実行するか
権限範囲	読取りに必要な最小権限になっているか
保存場所	パスワード管理、シークレット保管場所
有効期限	いつ更新するか
ローテーション	定期更新と緊急更新の手順
利用記録	誰がいつ接続を作成・変更したか
退職・委託終了	担当変更時に失効できるか
障害時	API停止時の代替確認方法
切断時	取り込み停止を誰へ連絡するか

データコネクタを切断した場合、Defenderへの可視性が低下します。

それはOT装置の安全性が向上したことを意味しません。

むしろ、リスクが見えなくなっただけという可能性があります。

11．委託先へ求める証跡を事前に決める

OT環境では、工場だけで原因調査や修正を完結できないケースが多くあります。

装置ベンダー、保守会社、OT監視サービス、ネットワークSIer、Azure運用会社などから証跡を受け取る必要があります。

インシデント発生後に「何を提出してください」と相談し始めるのでは遅すぎます。

表11　委託先への証跡提出要求例

証跡	確認する内容
資産一覧	型番、シリアル、OS、ファームウェア、設置場所
脆弱性情報	CVE、検出日時、検出元、対象バージョン
対応可否回答	修正版の有無、暫定対策、適用条件
互換性確認	更新後も装置・アプリが正常動作するか
作業計画	作業者、日時、手順、停止時間
バックアップ証跡	取得日時、保存先、復元確認
変更記録	変更前後の設定、ファームウェア
接続ログ	遠隔保守の接続者、日時、操作内容
APIログ	コネクタによる取得日時、エラー、最終成功時刻
障害報告	原因、影響、復旧、再発防止策
再委託情報	再委託先、担当範囲、アクセス権
サポート期限	製品・OS・ファームウェアの終了日

表12　委託契約・運用合意で整理する事項

分類	整理する事項
通知	重大な脆弱性や侵害を、誰へどの方法で報告するか
初動	夜間・休日を含む連絡方法
調査	ログや設定情報をどこまで提供するか
変更	誰の承認で装置設定を変更できるか
停止	委託先が単独で停止できる範囲
再開	復旧確認と再開承認の方法
証跡	提出形式、保存期間、時刻同期、タイムゾーン
資格情報	発行、保管、ローテーション、失効
再委託	再委託先の管理と報告
終了時	アカウント削除、データ返却、証跡引渡し

NIST CSF 2.0では、サイバーセキュリティガバナンスをIT部門だけに閉じず、組織全体やサプライチェーンへ適用することが重視されています。

役割と責任の定義、外部サービス提供者との期待事項の共有、委託先を含めたリスク管理は、Govern機能の重要な考え方です。

12．Microsoft Defenderに表示されるまでの遅延も考慮する

データコネクタを構成しても、取り込まれたデータがすべての画面に反映されるまで、数時間かかる場合があります。

そのため、Defenderの表示だけを、工場のリアルタイム安全制御や即時停止判断の唯一の情報源にしてはいけません。

図6　情報の時間軸を分ける

【秒・ミリ秒単位】
装置制御、インターロック、安全停止
        ↓
現場設備・安全制御の領域

【秒・分単位】
OT監視、ネットワーク検知、SOCアラート
        ↓
検知・初動の領域

【分・時間単位】
データコネクタ、Exposure Management、
脆弱性・資産情報の統合
        ↓
調査・優先順位付け・ガバナンスの領域

【日・月単位】
経営報告、リスク受容、保守計画、
予算化、設備更新
        ↓
経営管理の領域

Exposure Managementは、工場設備のリアルタイム制御装置ではありません。

目的は、資産・脆弱性・重要度などの情報を統合し、組織としてリスクを把握し、優先順位を決めることにあります。

13．2026年7月時点のプレビューと制限

技術記事として、ここは明確に書いておく必要があります。

Microsoft Security Exposure Management本体は、2024年11月に一般提供が発表されています。

一方、外部データコネクタは、2026年7月時点でプレビューとして案内されています。

表13　提供状態と注意点

対象	2026年7月時点の整理
Microsoft Security Exposure Management本体	一般提供
Armis OTデータコネクタ	サポート開始
Dragos OTデータコネクタ	サポート開始
Forescout OTデータコネクタ	サポート開始
外部データコネクタ機能	プレビュー
プレビュー期間の利用料金	Microsoft公式文書上は無料
一般提供後	従量課金が予定されているため再確認が必要
OTコネクタによる攻撃パス	現時点では未サポート
資産の統合照合	識別属性が不足すると表示・照合できない場合がある
データ反映	数時間かかる場合がある

Microsoftの一般的なデータコネクタ文書では、現時点でOTデータコネクタは攻撃パスをサポートしていないと明記されています。

したがって、

「OT、オンプレミス、Azureを横断した攻撃経路が、OTコネクタを接続するだけですべて自動表示される」

と理解するのは正確ではありません。

OT資産のインベントリや脆弱性を統合して確認できることと、OTを含む攻撃パス全体が自動生成されることは分けて説明すべきです。

公式文書間の表示説明にも注意

2026年7月14日時点では、OTコネクタ固有の公式文書は、OT脆弱性をDefenderポータルの脆弱性エクスペリエンスへ取り込み、CVEや影響資産を確認できると説明しています。

一方、一般的なデータコネクタの公式文書には、データコネクタから取得された脆弱性は現時点ではExposure Graphに表示され、Attack Surface MapまたはAdvanced Huntingで調査すると記載されています。

文書の更新時期、段階的なロールアウト、コネクタ種別による違いなどが考えられるため、導入時には次を確認することが適切です。

確認項目	確認方法
実際の表示場所	検証テナントで確認
対象コネクタ	Armis、Dragos、Forescoutごとに確認
対象資産	テスト用OT資産で照合
脆弱性表示	CVE、デバイスページ、Exposure Graphを確認
ライセンス	契約内容とMicrosoft公式情報を確認
提供状態	Microsoft Learnと管理画面のプレビュー表記を確認
本番利用判断	変更リスク、代替手順、撤退条件を記録

14．プレビュー機能を本番で使う場合の管理表

表14　プレビュー機能利用管理表

項目	記載内容
機能名	MSEM外部データコネクタ
コネクタ	Armis／Dragos／Forescout
利用目的	OT資産・脆弱性の統合可視化
対象工場	工場名、ライン、サイト
影響範囲	資産情報、脆弱性、重要度
本番判断者	情シス責任者、工場責任者
資格情報管理者	担当部署、代替担当者
仕様変更時の影響	API、画面、項目、料金
代替手順	OT製品側で直接確認
障害時対応	コネクタ状態確認、ベンダー照会
再確認日	月次または四半期
終了条件	一般提供移行、利用停止、別方式移行

15．NIST CSF・ISMSに対応させる

OTデータコネクタの導入を、単なる製品設定で終わらせてはいけません。

NIST CSF 2.0の六機能へ対応させると、必要な管理文書が見えやすくなります。

表15　NIST CSF 2.0と成果物の対応

CSF機能	OT・Azureで行うこと	成果物
Govern	経営方針、役割、リスク受容、委託先管理	責任分界表、RACI、委託先要求
Identify	OT・IT・Azure資産と依存関係を把握	IT／OT資産台帳、構成図
Protect	最小権限、ネットワーク分離、資格情報管理	権限マトリクス、例外管理台帳
Detect	OT製品、Defender、Azureログを監視	アラート対応基準、監視項目表
Respond	エスカレーション、封じ込め、停止判断	連絡網、停止判断フロー
Recover	復元、再開、再発防止	復旧手順、再開判定表

NISTは、CSFをIT部門だけではなく、経営層、各事業部門、外部サプライチェーンを含む組織全体で利用することが効果的だと説明しています。

ISMSの運用でも、資産管理、アクセス制御、供給者管理、変更管理、インシデント管理、事業継続を別々に扱うのではなく、同じ資産と業務を軸に関連付けることが重要です。

16．30日で始めるOT・Azure責任分界整備

最初からすべての工場・設備を対象にすると、台帳作成だけで計画が止まる可能性があります。

まずは、Azureへ接続している設備、外部保守が可能な設備、生産停止影響の大きい設備から着手します。

表16　30日ロードマップ

期間	実施内容	成果物
第1週	OT製品、工場設備、Azure資産、委託先を棚卸し	暫定IT／OT資産台帳
第2週	所有者、管理者、停止権限者、変更権限者を特定	責任分界表、RACI
第3週	アラート基準、停止レベル、連絡先を決定	対応基準、停止判断フロー
第4週	脆弱性発見を想定した机上訓練	訓練記録、改善計画

最初に優先する設備

優先度	条件
最優先	Azureや社内ITと双方向通信する
最優先	遠隔操作・遠隔保守が可能
最優先	停止すると工場全体へ影響する
高	サポート終了OSや旧ファームウェアを使用
高	装置ベンダーしか変更できない
高	資産台帳に識別情報が不足している
中	読取り専用でデータを送信する
低	完全に分離され、生産影響が限定される

17．経営層・工場・情シス向けチェックリスト

表17　責任分界セルフチェック

質問	はい／いいえ
すべてのOT資産について所有部門が分かる
OT資産とAzure資産の依存関係を把握している
Armis、Dragos、Forescoutの管理者が分かる
OTコネクタのAPI資格情報の所有者が決まっている
Defenderでリスクを確認する担当者が決まっている
装置を変更できる担当者が決まっている
ベンダー承認が必要な変更を把握している
IT／OT境界を遮断できる担当者が決まっている
Azure側を封じ込める担当者が決まっている
ライン停止を承認できる責任者が決まっている
夜間・休日の連絡先が登録されている
バックアップとロールバック手順がある
委託先へ提出を求める証跡が決まっている
コネクタ停止時の代替確認方法がある
プレビュー機能の利用を台帳化している

判定の目安

「はい」の数	状態
0～5	OT・IT・Azureの間に重大な責任空白があります
6～10	担当者はいますが、停止・修正・再開の連携が不十分です
11～13	基礎的な統制があります。証跡と訓練を強化します
14～15	責任分界の基礎が整っています。実権限との定期照合が必要です

18．山崎行政書士事務所が支援できること

OTとAzureの責任分界を整理するためには、次の二つの能力が必要です。

工場・Azure・Defenderの技術的理解
                  ×
台帳・規程・責任分界・証跡の文書化

山崎行政書士事務所では、Azure、Microsoft 365、Microsoft Entra ID、Microsoft Defenderなどの技術的な設定やログを確認しながら、情シス、工場、経営層、委託先が同じ説明をできる資料づくりを支援しています。

表18　支援成果物

支援項目	内容
IT／OT資産台帳	工場設備、ネットワーク、Azure資産、委託先の統合整理
責任分界表	工場、情シス、Azure担当、SOC、装置ベンダーの役割整理
RACI表	検知、判断、停止、修正、復旧、再開の責任明確化
権限マトリクス	Defender、Azure、OT製品、装置の実権限整理
アラート対応基準	資産重要度と生産影響を踏まえた優先順位付け
停止判断フロー	クラウド遮断、境界遮断、装置停止、ライン停止の区別
委託先確認表	保守範囲、緊急連絡、証跡提出、資格情報管理
証跡提出要求表	ログ、変更記録、脆弱性回答、作業報告の明確化
ログ確認手順	Defender、Azure、OT製品、装置ログの関連付け
プレビュー管理台帳	提供状態、仕様変更リスク、代替手順の記録
監査説明資料	経営層、取引先、監査人向けの説明整理
机上訓練シナリオ	OT脆弱性・クラウド侵害を想定した連絡・停止訓練

単に「装置ベンダーが対応する」「情シスが監視する」と文書へ記載するだけではありません。

実際の、

• Defender統合RBAC

• Microsoft Entra IDの管理者ロール

• Azure RBAC

• OT製品のAPI資格情報

• ネットワーク変更権限

• 保守契約

• 工場の停止承認手順

• ログ保存状態

を確認し、文書上の責任と技術上の権限を照合します。

工場を守るのは、Defenderの画面だけではない

2026年7月のOTデータコネクタ対応は、製造業のセキュリティ管理を大きく前進させるものです。

OT資産、脆弱性、ファームウェア、重要度、IT・クラウド資産を、同じDefenderポータルで確認する方向が明確になりました。

しかし、管理画面が統合されても、責任は自動的には統合されません。

Defender上でリスクが見えても、修正権限を持つのは誰ですか。 装置ベンダーですか。工場ですか。情シスですか。 そして、工場を止める最終判断をするのは誰ですか。

この問いに答えられない状態で、OTデータコネクタだけを接続すると、見えるリスクが増える一方で、誰も対応できない課題が増える可能性があります。

工場OTとAzureを別々に守る時代は終わりました。

ただし、それはすべての権限を一か所へ集めるという意味ではありません。

OT、IT、Azure、SOC、委託先の異なる権限を、同じ資産台帳と責任分界表で結ぶ。

それが、製造業に必要な次のセキュリティガバナンスです。

技術上の脚注

脚注1：提供状態についてMicrosoft Security Exposure Management本体は一般提供されていますが、外部データコネクタは2026年7月時点でプレビューです。プレビュー機能は仕様、表示、課金条件などが変更される可能性があります。

脚注2：攻撃パスについて一般的な外部データコネクタではExposure Graphや攻撃パスへの統合が説明されていますが、OTデータコネクタについては、現時点で攻撃パスがサポートされていないと明記されています。

脚注3：資産照合についてMACアドレス、シリアル番号などの識別情報が不足している場合、統合インベントリへ正しく表示されない可能性があります。

脚注4：反映時間についてコネクタ設定後、データがすべての画面に反映されるまで数時間かかる場合があります。

脚注5：料金についてプレビュー期間中のデータコネクタ利用は無料と案内されていますが、一般提供後は従量課金が予定されています。実際の導入時には、最新の料金・ライセンス条件を再確認する必要があります。

本記事に関する注意事項

本記事は、2026年7月14日時点のMicrosoft公式情報、NIST公式情報などを基にした一般的な情報提供です。

Microsoft Security Exposure Management、Microsoft Defender、Azure、OTデータコネクタの提供状態、表示内容、必要ライセンス、料金、制限事項は変更される可能性があります。実際の導入時には、Microsoft Learn、管理画面、契約内容、メッセージセンター、リリースノートを改めて確認してください。

本記事で示したRACI表、停止基準、権限分界は一般的なひな型です。実際の工場設備、労働安全、製造物、契約、保守条件、業界規制に応じて個別に調整する必要があります。

責任分界表は、運用上の役割を可視化する資料であり、法令上または契約上の責任を自動的に確定するものではありません。個別具体的な法的判断、損害賠償、紛争対応、相手方との交渉または代理については、弁護士等の適切な専門家への相談が必要です。

山崎行政書士事務所はMicrosoftとは独立した事業者です。本記事はMicrosoftによる公式見解、保証または認定を示すものではありません。