ISO 23247-4徹底解説：デジタルツインの動的連携を支える「4つのネットワーク」と情報交換技術

どれほど精緻な3Dモデル（Part 3）を設計し、堅牢なシステム構成（Part 2）を整えても、それらの間を流れる「データ」が安全かつリアルタイムに届かなければ、デジタルツインはただの「動かない置物」になってしまいます。

デジタルツインを「生きたシステム」として脈動させるための神経網（通信・データ交換の技術要件）を定義するのが、国際標準規格 「ISO 23247-4: Information exchange（情報交換）」 です。

本記事では、このPart 4が規定する4つの通信ネットワークトポロジー、現場とツインを繋ぐ3つのデータ転送（トランザクション）方式、そしてセキュリティ要件（IEC 62443）などを、網羅的に解説します。

通信インフラのロードマップ：ISO 23247-4が定める「4つのネットワーク」

ISO 23247-4は、物理的な工場床（OME）から最上位のユーザーアプリケーション（User Entity）までの通信経路を、以下の4つのネットワーク層に整理・定義しています。

┌────────────────────────────────────────────────────────┐
│ 【 ユーザーエンティティ (User Entity) 】 │
└───────────────────────────┬────────────────────────────┘
 │ (1) ユーザーネットワーク (User Network)
 │ ➔ REST / HTTP / HTTPS 
 ▼
┌────────────────────────────────────────────────────────┐
│ 【 デジタルツインエンティティ (DT Entity) 】 │
│ ┌────────────────────────────────────────────────┐ │
│ │ [運用・管理SE] ── (2) サービスネットワーク ── │ │
│ │ [アプリ・サービスSE] (Service Network) │ │ ➔ 同一のプライベートシステム内
│ │ [資源アクセスSE] (IPベース有線) │ │ なら物理ネットワークは省略可 
│ └────────────────────────────────────────────────┘ │
└───────────────────────────▲────────────────────────────┘
 │ (3) アクセスネットワーク (Access Network)
 │ ➔ IPベース有線/無線（LAN、WLAN、5G等）
 │ ➔ PULL / PUSH / PUBLISH (MQTTなど) 
┌───────────────────────────┴────────────────────────────┐
│ 【 デバイス通信エンティティ (DCDCE) 】 │
└───────────────────────────┬────────────────────────────┘
 │ (4) プロキシミティネットワーク (Proximity Network)
 │ ➔ 産業用イーサネット (EtherCATなど) 
 │ ➔ デバイス通信層がOMEに「内蔵」なら省略可 
 ▼
┌────────────────────────────────────────────────────────┐
│ 【 観測可能な製造要素 (OME: 物理機械・センサー) 】 │
└────────────────────────────────────────────────────────┘

① ユーザーネットワーク (User Network)

接続対象
最上位の「ユーザーエンティティ（人間、ERP、PLM、MES等）」と「デジタルツインエンティティ（核心層）」を相互接続します。

特性
公開インターネット、または企業内のプライベートイントラネット上で稼働します。

通信プロトコル
基本的にはWeb技術をベースとした標準プロトコル（REST や HTTP/HTTPS）が要求されます。これにより、プラットフォームに依存しない柔軟なアプリケーション開発が可能になります。

② サービスネットワーク (Service Network)

接続対象
デジタルツインエンティティを構成する3つの内部サブエンティティ（運用管理、アプリケーション・サービス、資源アクセス・交換）の間を相互接続します。

特性
通常、IPベースのプロトコルが走る高速な有線ネットワーク（工場内のイントラネットサーバー間など）で構築されます。

💡 設計省略の条件
「もしデジタルツインエンティティ（核心層）全体が、1台のプライベートなPCやサーバーシステムの中に密に実装される場合、物理的なサービスネットワークの構築は不要（省略可能）である」と定義されています。これにより、小規模な実証デモなどでのハードルが下がります。

③ アクセスネットワーク (Access Network)

接続対象
現場のデータを司る「デバイス通信エンティティ」と、「デジタルツインエンティティ」および「ユーザーエンティティ」を橋渡しします。

特性
有線LAN（LAN）、無線LAN（WLAN）、あるいはモバイル（5G等のセルラー）ネットワークなど、多様な物理インフラが採用され、基本的にはIPベースのプロトコルが走ります。

役割
現場から吸い上げたセンサー値の「リアルタイム・ストリーミング」や、ツイン/ユーザー側から現場へ下される「物理制御コマンド」の送信を担う、システム全体の最もダイナミックな通信路です。

④ プロキシミティネットワーク (Proximity Network / 近接ネットワーク)

接続対象
物理現場の「OME（工作機械、産業用ロボット、スマートセンサー等）」と、そのデータを集約する「デバイス通信エンティティ（ゲートウェイやコントローラー）」を直結します。

特性
EtherCATやRAPINetなどの「産業用イーサネット」、あるいはフィールドバス、非IPプロトコルを用いた特殊な専用接続（有線・無線）が想定されます。現場の機械を低遅延で同期・制御するために、きわめて高いリアルタイム性が要求されます。

💡 設計省略の条件:
「もし物理機械（OME）の内部コントローラー自体に、データ収集や制御命令を仲介するソフトウェア（デバイス通信エンティティ）が物理的に内蔵されている場合、プロキシミティネットワークの物理的な構築は省略可能である」と規定されています。

現場とツインを繋ぐ「3つのデータ転送方式」

アクセスネットワーク（現場 ➔ デジタルツイン間）において、データをどのようなタイミングや方向性でやり取りすべきでしょうか。
ISO 23247-4は、以下の3つのトランザクション方式をサポートし、適切な設計を行うことを規定しています。

PULL方式（要求・応答型）

• データの流れ
  • デジタルツイン（核心層）が要求者となり、デバイス通信層に対して「今のデータをください」と要求し、それに対して現場がデータを返します。
• 特徴
  • ツイン側が必要なタイミング（オンデマンド）でデータを取りに行くため、通信帯域を節約できますが、突発的な異常検知などには不向きです。

PUSH方式（送信型）

• データの流れ
  • デバイス通信層が送信者となり、新しいデータが発生したり、値が変化したりした瞬間に、デジタルツイン（核心層）に対して能動的にデータを送りつけます。
• 特徴
  • 現場の変化が即座にツインに伝わるため、リアルタイムな状態更新や異常アラームの送信に適しています。

PUBLISH（パブリッシュ・サブスクライブ型）方式

• データの流れ
  • 現場のデバイス通信層が「パブリッシャー（配信者）」として特定のトピック（例：factory/line1/temp）にデータをパブリッシュし、デジタルツイン核心層が「サブスクライバー（購読者）」としてそのトピックを講読（サブスクライブ）します。
  • データは「ブローカー」と呼ばれる中継サーバーを介してやり取りされます。
• 💡 規格（ISO 23247-4）の強い推奨
  • 規格書では、「もし複数の独立したデジタルツインシステム（例：監視用ツイン、予兆保全用ツイン、ERPの在庫管理など）が、現場の同一のデバイス通信層を同時にリスン（監視）するようなマルチクライアントのシナリオにおいては、PUBLISH方式（MQTTなど）を強く推奨する」と規定しています。通信のバッティングや現場コントローラーへの負荷集中を劇的に軽減できるためです。

情報交換に求められる高度なシステム要件

Part 4では、通信を行うためのネットワーク帯域やプロトコル要件だけでなく、データの正確性や安全性を守るための厳しいシステム要件が課されています。

A. データ検証とセマンティクスの確認

やり取りされるデータは、単に「エラーなく届いた」だけでは不十分です。規格では、送受信されるデジタルモデルの「構文（シンタックス）」と「意味（セマンティクス）」が正しいかを検証・検証（Verification & Validation）する機能を含めるべきであると推奨されています。

これに適合する実装モデルの代表例として、幾何・公差データを厳密に検証できる STEP (ISO 10303) や、検査計測データのセマンティクスを完全に定義できる QIF (Quality Information Framework) が挙げられています。

B. セキュリティ要件

デジタルツインは工場の制御に直接関わるため、セキュリティ侵害は重大な物理事故（火災や設備の損壊）を招きます。そのため、ユーザーネットワークおよびアクセスネットワークにおいては、デジタルツインのセキュリティとプライバシーを厳格に維持することが義務とされています。

規格書では、産業用自動化・制御システムのセキュリティ標準規格である 「IEC 62443」 シリーズに準拠したセキュアな通信（暗号化、証明書認証など）を実装することが明記されています。

【実践】身近な例で見る通信ネットワーク設計

ISO 23247-4の「4大ネットワーク」と「PUBLISH方式」の推奨、そしてセキュリティ要件を、身近な2つのシステムに具体的に適用してみましょう。

事例1：家庭向け植物栽培工場（スマートプランター）の通信インフラ設計

1台のRaspberry Piと各種センサー、小さな水やりポンプ、スマホアプリで構成されるスマートプランターを例に挙げてみます。

プロキシミティネットワーク
Raspberry Pi本体に、センサーやポンプがジャンパ線で直接接続（オンボード組み込み）されているため、「プロキシミティネットワークは不要（省略）」となります。

アクセスネットワーク（重要）
Raspberry Pi（デバイス通信層）と、ローカルPCや自宅サーバー（デジタルツイン核心層）との通信です。家庭内の無線LAN（WLAN / Wi-Fi）を使用します。

トランザクション
規格の推奨に従い、オープンソースのMosquittoを用いたMQTT（PUBLISH方式）を採用します。プランターが「planter/sensor/humidity」というトピックで土壌水分データをパブリッシュし、ツイン側のPythonスクリプトがそれをサブスクライブしてリアルタイムに水やり判定を行います。

サービスネットワーク
デジタルツイン核心層（状態同期、植物成長シミュレーション、データベース）がすべてローカルの1台のPC内でプロセスとして稼働しているため、「サービスネットワークは不要（省略）」となります。

ユーザーネットワーク:
あなたが手にするスマートフォンのStreamlitダッシュボード（User Interface FE）と、デジタルツインPCを繋ぎます。
家庭内Wi-Fi経由で、セキュアな HTTPS（REST/HTTP） 通信を使用して状態表示や手動水やりコマンドのやり取りを行います。

事例2：オフィスメール返信遅延対策 DTO（組織のデジタルツイン）の通信インフラ設計

次は、社員のメール往復ログからボトルネックを自律解消するオフィスシステムの場合を考えてみましょう。

プロキシミティネットワーク
メールシステム（Office 365やGoogle Workspace）のクラウドサーバー自体がOMEであり、ログ吸い出しプログラム（DCDCE）もクラウドAPIを介して動くため、物理的な配線（プロキシミティ）は存在せず、API連携として省略されます。

アクセスネットワーク
メールAPIから定期的にログデータを吸い上げるコレクタープログラムと、社内のAWS（デジタルツイン核心層）との通信です。

トランザクション
複数の分析エンジン（返信遅延予測モデル、組織負荷ロードバランサーなど）が同じメールデータストリームを並行して監視するため、PUBLISH方式（Apache Kafkaなど）を用いてイベント駆動型のログ配信トポロジーを構築します。

サービスネットワーク
AWS上の「予測シミュレーションサーバー（Simulation FE）」と、「タスク移管実行バッチ（Controlling FE）」を、AWSのプライベートVPC（仮想有線ネットワーク）上で高速なIP通信で接続します。

ユーザーネットワーク
経営陣や各リーダーが触る管理ダッシュボードと、AWS上のデジタルツイン核心層を接続します。公開インターネット経由となるため、IEC 62443 に基づく認証や、TLS1.3を用いた厳格な HTTPS（REST/HTTP） で完全に暗号化されたユーザーネットワークを構築します。

まとめ

Part 4（情報交換技術）は、物理世界のデータをデジタル空間に引き込み、解析された価値ある制御コマンドを再び物理世界に還元するための「双方向の架け橋（アクセスネットワークやプロキシミティネットワーク）」を定義する、実装の最終段階に欠かせないインフラ構築のルールです。

これでISO 23247シリーズの解説は「最後」ですか？

結論からお伝えしますと、「オリジナルの基本構成としては最後ですが、現在進行形の最新規格としては、まだ次があります」。

ISO 23247シリーズが2021年に最初に制定された際、規格は以下の4部構成（Part 1〜4）で完結していました 。

• Part 1: 概要と一般原則（司令塔）
• Part 2: 参照アーキテクチャ（23の機能要素）
• Part 3: 製造要素のデジタル表現（データ構造）
• Part 4: 情報交換技術（4つの通信ネットワーク）

したがって、システムを1つ「ゼロから構築する」ための技術仕様としては、今回のPart 4でパズルはすべて完成（最後）となります。

しかし、2026年に追加された「真の最終章：ISO 23247-6」

しかし、スマート製造がさらに進化した結果、「自社が作ったデジタルツインと、隣の工場が作ったデジタルツインを合体させたい」「異なるベンダーが作ったツイン同士を繋げたい」という新しいニーズが生まれました。

これに応えるため、2026年7月31日に、シリーズの最新拡張規格として「ISO 23247-6: Digital twin composition（デジタルツインのコンポジション）」が正式に発行されました。

Part 6は、構築された複数のデジタルツインを、

• Integrated（統合型）
• Unified（統一型）
• Federated（連合型）

という3つの形態で「合体・相互運用」させるための原則や、サプライチェーンを跨ぐ壮大なユースケースを定めています。

つまり、「単体のデジタルツインを作るための技術ルール」としては今回のPart 4で最後ですが、「それらを合体させて、地球規模のスマートサプライチェーンへと進化させる最終フェーズ」として、もうひとつの砦である「Part 6」が存在するのです。

現場の通信インフラとプロトコル要件（Part 4）を完璧に理解した今、私たちはついに、複数のツインが自律的に協調し合う「デジタルツインの合体（Part 6）」という、デジタルツイン開発の最先端にして究極の頂点に立つ準備が整いました。

この壮大な標準化ロードマップを武器に、自社に最適な、そして将来スケールアップ可能なデジタルツインシステムの構築へと歩みを進めましょう。

本記事は、一般に公開されている情報をもとに、ISOについて学べる内容を整理したものです。正式な仕様や要件については、ISO規格本文をご確認ください。