OT/IT統合の設計パターン｜PLC・SCADAデータ連携のアーキテクチャと安全設計

製造業のDXにおいて、工場のデータ活用は最も期待されるテーマの一つです。PLC（Programmable Logic Controller）やSCADA（Supervisory Control And Data Acquisition）が収集している設備の稼働データ、品質データ、環境データ。これらをIT側のシステムに連携し、予知保全、品質分析、生産計画の最適化に活用したい。この構想を持つ製造業は多い一方で、実際に統合を実現している企業はまだ限られています。

進まない理由は、技術的な難しさだけではありません。

理由1：OTとITの「文化」が違う。OT（Operational Technology）の世界では、最優先事項は「設備を止めないこと」です。24時間365日の可用性、ミリ秒単位の応答性、安全性。これらを担保するために、OTネットワークは外部から厳格に隔離されてきました。一方、ITの世界では、データの共有と流通が前提です。この「隔離」と「共有」の文化的な対立が、統合の最大の障壁になっています。

理由2：「つなげる」ことのリスクが大きい。OTネットワークをIT側に開放するということは、サイバー攻撃のリスクを工場の制御系に持ち込むことを意味します。2021年のColonial Pipeline事件に代表されるように、OTを標的にしたサイバー攻撃は増加しており、「つなげること」のリスクは技術的にも経営的にも見過ごせません。

理由3：設備の更新サイクルが長い。IT機器の更新サイクルが3〜5年であるのに対し、OT設備（PLC、センサー、制御機器）は10〜20年以上使われることが珍しくありません。最新のプロトコルに対応していない旧型PLCが現役で稼働しているのが現場の現実です。

本記事では、これらの制約を前提に、OTデータを安全にIT側で活用するためのアーキテクチャ設計パターンを整理します。ネットワーク分離、データ収集方式、可用性設計、セキュリティ境界の4つの設計領域に分けて解説します。

OT/IT統合のアーキテクチャを設計する際の出発点となるのが、Purdue Enterprise Reference Architecture（Purdue Model）です。ISA-95（国際標準規格）をベースにしたこのモデルは、製造業のネットワークを階層構造で整理するフレームワークとして広く参照されています。

OT/IT統合のアーキテクチャ設計とは、Level 0〜2（OT）のデータを、Level 3〜5（IT）に安全に流すための仕組みを設計することです。Purdue Modelの各レベル間には、原則としてネットワークの境界（セグメンテーション）が設けられており、この境界をどう設計するかが統合の核心です。

特に重要なのは、Level 3とLevel 4-5の間に設置されるDMZ（非武装地帯）です。OTネットワークとITネットワークが直接通信しないよう、DMZが緩衝地帯として機能します。OT/IT統合の設計は、このDMZの構成をどう設計するかに帰結すると言っても過言ではありません。

OTのデータをIT側で活用するためのデータ収集方式は、セキュリティ要件とリアルタイム性のトレードオフに基づいて選択します。

最もセキュリティが高い方式です。物理的にOT→ITの一方向のみのデータ転送を許可するハードウェアデバイス（データダイオード）を使用し、IT側からOTネットワークへのアクセスを完全に遮断します。

適する要件：安全性が最優先の環境（原子力、重化学工業等）。IT側からOTへのフィードバックが不要な場合。データの鮮度はニアリアルタイム（秒〜分単位）。

制約：一方向のみのため、IT側からOT側への制御指令やデータ送信はできない。ハードウェア費用が高い。

OTネットワークとITネットワークの間にDMZ（非武装地帯）を設置し、DMZ内のサーバーがデータの中継を行う方式です。OT側のデータをDMZのHistorianやブローカーに書き出し、IT側がDMZからデータを取得する。OTとITが直接通信しない構造を維持します。

適する要件：多くの製造業で最も現実的な方式。セキュリティと運用のバランスが取りやすい。OPC-UAやMQTTなどの産業用プロトコルとの親和性が高い。

制約：DMZ内のサーバーの可用性が全体のボトルネックになるため、冗長化設計が必要。DMZの管理をOTチームとITチームのどちらが担うかの責任分界を明確にする必要がある。

OTネットワーク内、またはDMZにエッジデバイス（エッジゲートウェイ）を設置し、データの前処理・集約・フィルタリングをOT側で行った上で、必要なデータのみをIT側に転送する方式です。

適する要件：OT側のデータ量が大きく、すべてをIT側に転送するとネットワーク帯域やストレージコストが課題になる場合。エッジ側でリアルタイム処理（異常検知等）を行いたい場合。

制約：エッジデバイスの運用管理が必要。ファームウェアの更新、セキュリティパッチの適用など、OT環境でのIT機器管理のノウハウが求められる。

OTデバイスからクラウド（AWS IoT Core、Azure IoT Hub等）に直接データを送信する方式です。最もシンプルで導入が速いですが、OTネットワークの外部接続が前提になるため、セキュリティ上のリスクが最も高い方式でもあります。

適する要件：新規設備で、最初からクラウド接続を前提に設計する場合。小規模なPoC（概念実証）の段階。OTネットワークの既存構成に影響を与えない独立した検証環境。

制約：既存のOTネットワークに外部接続を追加することは、セキュリティポリシー上許可されないケースが多い。本番環境への適用には、DMZ経由またはエッジコンピューティングとの併用が現実的。

OTデータをIT側に流す際のプロトコル選定も重要な設計判断です。主要なプロトコルの特性を整理します。

実務上の推奨は、OT/IT境界の通信にはOPC-UAを基本とし、エッジ→クラウドの通信にはMQTTを使い、旧型設備との通信にはModbusをゲートウェイ経由で変換する構成です。すべてを1つのプロトコルで統一するのではなく、各区間の特性に応じて使い分ける設計が現実的です。

OT/IT統合のセキュリティ設計においては、IEC 62443（産業用オートメーションおよび制御システムのセキュリティに関する国際規格）が最も重要な参照フレームワークです。

IEC 62443が定義する「ゾーン＆コンジット」モデルは、OTネットワークをセキュリティ要件の近いグループ（ゾーン）に分割し、ゾーン間の通信経路（コンジット）を明示的に制御する考え方です。Purdue Modelの階層構造と組み合わせ、各レベルをゾーンとして定義し、ゾーン間のコンジットにファイアウォールやアクセス制御を適用します。

原則1：OTネットワークへのインバウンド通信を原則禁止する。IT→OTの方向の通信は、原則として許可しません。データの流れは「OT→DMZ→IT」の一方向を基本とし、IT側からOT側への制御指令が必要な場合は、厳格な認証と監査ログを前提とした例外設計とします。

原則2：DMZを必ず設置する。OTとITの直接通信を許可しない。すべてのデータ交換はDMZを経由させます。DMZ内のサーバーは、OT側とIT側の両方から接続を受けるため、最もセキュリティ設計が求められるポイントです。

原則3：ネットワークセグメンテーションを細分化する。「OT全体を1つのネットワーク」として扱うのではなく、製造ラインごと、設備グループごとにセグメントを分割します。ある設備が侵害されても、他の設備への横方向の展開（ラテラルムーブメント）を防ぐための設計です。

原則4：認証と監視を多層化する。ネットワークレベルのセグメンテーションに加えて、アプリケーションレベルの認証（OPC-UAの証明書認証等）、ユーザー認証（多要素認証）、通信の暗号化（TLS）を多層的に適用します。

原則5：OTセキュリティの監視体制を構築する。IT側のSOC（Security Operations Center）がOTネットワークの異常を検知できる仕組みを整備します。OT専用のIDS（Intrusion Detection System）を導入し、通常の通信パターンからの逸脱をリアルタイムに検知する体制が必要です。

OT/IT統合の設計において、「IT側の障害がOT側の稼働に影響を与えない」ことが絶対条件です。データ活用のために設けた仕組みが原因で生産ラインが停止する事態は、許容されません。

1. データ収集の障害がOTに波及しない設計。DMZのサーバーやエッジデバイスが障害を起こした場合でも、OT側のPLCやSCADAの動作に影響がないことを保証する。データ収集は「OT側からのPush」ではなく「DMZ側からのPull」で設計するか、非同期のキューイング機構を挟むことで、データ収集の停止がOTの動作を阻害しない構造にします。

2. DMZの冗長化。DMZが単一障害点にならないよう、サーバーの冗長化（Active-Standby or Active-Active）を設計します。特にHistorianサーバーは、データの欠損が分析の品質に直結するため、冗長化の優先度が高い。

3. ネットワーク変更のリスク管理。OTネットワークに変更を加える際は、必ず計画停止の時間枠（メンテナンスウィンドウ）を確保し、変更前後の動作確認手順を事前に定義します。IT側の「アジャイル」なネットワーク変更の感覚をOTに持ち込むと、重大な事故につながるリスクがあります。

OT/IT統合を一度にすべて実現するのは、技術的にも組織的にもリスクが高い。段階的に進めるアプローチを推奨します。

Phase 1：可視化（3〜6か月）。まず、限定された範囲（1ライン、1設備グループ）のOTデータをIT側で可視化する。DMZ経由のデータ中継を構築し、BIツールやダッシュボードでデータを見える化する。この段階ではリアルタイム性は求めず、バッチ処理（分〜時間単位）で十分です。

Phase 2：分析（6〜12か月）。可視化で得たデータの品質と量を確認した上で、分析のユースケース（品質異常の傾向分析、設備稼働率の分析等）に取り組む。データ量の増加に伴い、エッジコンピューティングの導入やストレージの拡張を検討します。

Phase 3：予測・最適化（12か月〜）。蓄積されたデータを基に、予知保全、品質予測、生産計画最適化といった高度なユースケースに着手する。MLモデルの構築と運用が含まれるため、データ基盤とMLOpsの整備が前提になります。

Phase 4：自律制御（要件次第）。AIの判断をOT側にフィードバックし、設備制御に反映する段階です。「IT→OT」の方向のデータフローが発生するため、セキュリティ設計の追加的な検討が必要です。すべてのプロジェクトがこのフェーズに進む必要はなく、事業要件に応じて判断します。

段階的に進める最大のメリットは「学習」です。Phase 1で「OTデータの品質はこの程度」「現場からの抵抗感はこういう形で出る」「セキュリティポリシーの運用ルールはこう設計すべきだった」という知見が得られます。この知見をPhase 2以降の設計に反映することで、手戻りとリスクを最小化できます。

本記事では、OT/IT統合のアーキテクチャ設計を4つの領域（ネットワーク構造、データ収集方式、セキュリティ、可用性）に分けて整理しました。

• Purdue Modelの階層構造を理解し、OT（Level 0-2）とIT（Level 4-5）の間のDMZの設計が統合の核心
• データ収集は4パターン（データダイオード/DMZ中継/エッジ/クラウド直接）。セキュリティとリアルタイム性のトレードオフで選択
• プロトコルはOPC-UAを基本に、MQTT/Modbusを区間に応じて使い分け
• セキュリティはIEC 62443のゾーン＆コンジットモデルをベースに、OTへのインバウンド原則禁止、DMZ必須設置、セグメンテーション細分化を徹底
• 可用性は「IT障害がOTに波及しない」を絶対条件とし、DMZの冗長化とネットワーク変更のリスク管理を設計
• 段階的なロードマップ（可視化→分析→予測→自律制御）で進め、各フェーズの知見を次に活かす

OT/IT統合の難しさは、個々の技術要素よりも「OTとITという異なる文化・優先度を持つ世界を、安全に接続する設計」にあります。OTの安全性と可用性を損なわずに、データの価値を引き出す。このバランスを実現する設計力が、製造業DXの成否を分ける核心的な能力です。