公開2026.08.24更新2026.09.27 シミュレーション

デジタルツインの設計｜収集層・データモデル・同期頻度の決め方を実装目線で解説

デジタルツインを作れと言われて最初に詰まるのは、どのデータをどの粒度でどこへ置くか、という決めごとです。概念の説明はいくらでも見つかる一方で、実装者が手を動かす段になると、収集層のプロトコルをどこで変換するか、資産の構造をどの記述方式で持つか、同期をどこまで速くするかといった変数が一気に立ち上がります。この記事では、デジタルツインの設計を意思決定の連なりとして分解し、ISO 23247が示す責務分割から、収集層・データモデル・3D紐付け・遅延予算の順に、判断の根拠まで含めて整理しました。デジタルツインそのものの定義や導入効果はデジタルツインとは？意味・仕組み・事例と導入の判断基準を解説した記事に譲り、ここは設計に絞ります。

まとめ｜デジタルツイン設計で先に決める5つの論点

先に結論を置きます。設計で最初に固めるべきは次の5点です。第1に、責務の分割はISO 23247の4エンティティをそのままモジュール境界に使う。収集・モデル・利用を混ぜないだけで、後から用途を足せる構造になります。第2に、収集層では現場プロトコルの意味付けをエッジ側で終わらせ、上位へはMQTTのような疎結合の伝送で渡す。

第3に、資産モデルと時系列データは必ず別々に持ち、資産側は時系列への参照だけを抱える。現在値をモデルに書き込む設計にすると、履歴が持てず保持設計も破綻します。第4に、3Dは、どこの何が異常かを位置で示す必要があるときだけ入れる。CADは表示用と解析用に分け、表示用をglTFへ落として座標にタグを置きます。

第5に、同期頻度は用途別の許容遅延から逆算する。監視は秒、予知保全は分から時間、制御へ戻すならクラウド往復を諦めてエッジで閉じる、という配分です。以下、この5点をそれぞれ設計の変数まで下ろします。

参照アーキテクチャの4層｜ISO 23247が示す責務の分け方

設計の出発点として、既存の参照アーキテクチャを踏み台にすると議論が速く進みます。製造業向けにはISO 23247シリーズがあり、基幹となるPart 1からPart 4が2021年に発行されました。その後もシリーズは伸びており、デジタルスレッドを扱うPart 5が2026年6月、ツインの合成を扱うPart 6が2026年に加わっています（2026年8月時点）。

観測対象と装置通信の境界｜OT側から値を取り出す責務の置き方

ISO 23247の参照アーキテクチャは4つのエンティティで構成されます。最下層が観測可能な製造要素で、現場でモデル化の対象になる設備や工程そのものです。その上に装置通信エンティティが立ち、観測対象の状態変化を集約し、必要なら制御プログラムを現場へ送り返す役割を担います。

実装に落とすとき、この境界はゲートウェイの責務境界と重ねるのが素直な整理でしょう。現場プロトコルの方言を吸収し、値に意味を与えて上位へ渡すところまでを装置通信側に閉じ込める。逆に、この層でビジネスロジックを持たせると、設備が増えるたびにゲートウェイのコードが膨らみます。

ツイン本体と利用側の責務分離｜モデル更新と表示機能を切り離す理由

3層目のデジタルツインエンティティは、集約されたデータを読んでモデルを更新し続ける部分です。4層目のユーザーエンティティは、そのモデルを使って何かをするアプリ群を指します。監視ダッシュボード、異常検知、シミュレーション、既存の生産管理システムなどが該当します。

ここを分ける実利は、表示要件の寿命がモデルの寿命より短いことにあります。可視化ツールは数年で乗り換わりますが、資産の構造と履歴は残す。モデル側にAPIを置き、アプリはそれを読むだけにしておけば、ダッシュボードを差し替えてもツインは生き残ります。

層をまたいで作ると詰まる箇所｜可視化と一体で組んだ現場の失敗例

よく見る失敗は、可視化ツールの都合に合わせてデータ構造を決めてしまう組み方です。ダッシュボードのパネル単位でテーブルを作ると、後から異常検知やシミュレーションを足すときに、同じ値を別の形でもう一度集める羽目になります。

ISO 23247のPart 6は、ツインの合成を統合型・統一型・連合型の3種に分けて規定しています。複数のツインを後からつなぐ余地を残したいなら、最初から層をまたがない構造で作っておく。ここは後戻りのコストが最も大きい部分だと考えてください。

データ収集層の設計｜変換点とエッジの責務を通信要件別に分ける基準

収集層で決めるのは、どこで意味付けをし、どこから先を共通の伝送に乗せるかという1点に尽きます。現場側はプロトコルもデータの持ち方もばらつくため、ここを上位へ持ち込むと、アプリ側に現場知識が染み出していきます。

現場プロトコルからの取り出し｜OPC UAとModbusで異なる前提

OPC UAはアドレス空間に型と階層を持つため、資産モデルへ写す際の手間が小さくて済みます。ノードに名前と型があり、機器の構造がそのまま読み取れるからです。一方でModbusはレジスタ番号と値しか持たず、どのレジスタが何を意味するかは仕様書の外にあります。

この差が設計に効きます。Modbus系の設備を含む場合、点表（レジスタと物理量の対応表）を成果物として管理対象に含めてください。表計算ファイルで現場に置かれたままにすると、機器更新のたびに対応が失われ、ツイン側の値が静かに壊れます。

MQTTとSparkplug B｜再接続時の整合をどう担保するかの選択

上位への伝送はMQTTのPub/Subに寄せる構成が扱いやすく、機器とアプリを疎結合にできます。仕組みとQoSの詳細はMQTTの仕組みとQoSを実装者向けに整理した記事で扱っているため、ここでは設計上の分かれ目だけ挙げます。

素のMQTTはトピック設計もペイロード形式も自由なので、機器が数百点を超えると解釈の負担がアプリ側へ寄ります。産業用途で規約を持ち込むならSparkplug Bが選択肢になり、トピックの名前空間と、接続・切断・現在値再送といった状態遷移が規定されます。Sparkplug 3.0は2022年12月に公開され、2023年11月にISO/IEC JTC 1のPAS手続きで国際標準へ移りました。規約の中身はSparkplug BとMQTT上の状態管理を解説した記事を参照してください。

spBv1.0/{group_id}/NBIRTH/{edge_node_id}
spBv1.0/{group_id}/DBIRTH/{edge_node_id}/{device_id}
spBv1.0/{group_id}/DDATA/{edge_node_id}/{device_id}
spBv1.0/{group_id}/NDEATH/{edge_node_id}

エッジで間引くか生で上げるか｜通信費と再解析の余地の折り合い

振動や電流波形のような高周波データを生のままクラウドへ上げると、通信量と保存費が対象設備の台数に比例して膨らみます。エッジ側で実効値やピーク値などの特徴量にしてから上げれば、桁で圧縮できるでしょう。

ただし一度捨てた波形は戻りません。異常検知のモデルを後から作り直すとき、手元に生波形がないと打つ手が減ります。折衷案として、生データはエッジまたは低コストのオブジェクトストレージに短期だけ残し、上位には特徴量を送る二段構えを勧めます。どこまで残すかは、異常の発生頻度と再学習の想定間隔から決めてください。

データモデルの設計｜資産モデルと時系列を用途別に分けて持つ理由

ここがデジタルツイン設計の中核です。扱う情報は性質の異なる2種類に分かれます。資産の構造・属性・関係を表す静的寄りのモデルと、時々刻々と増える時系列の観測値です。この2つを同じ入れ物に入れようとすると、どちらの要件も満たせなくなります。

資産モデルの記述方式｜AAS・DTDL・NGSI-LDの性格差と選び方

資産モデルの記述には既存の方式がいくつかあり、想定する交換範囲が異なります。用途が近いものを選ばないと、後から社外連携や分野横断で行き詰まります。

方式	基準と版	想定する範囲
AAS	IEC 63278-1:2023	企業間の資産情報交換
DTDL	v3・JSON-LDベース	Azure上のツイン記述
NGSI-LD	ETSI GS CIM 009 V1.9.1	都市・分野横断の連携

AASはIEC 63278-1:2023として2023年12月14日に発行され、ソフトウェア間で資産情報を信頼できる形で交換する目的を掲げています。取引先やメーカーと資産情報をやり取りする要件があるならここが基準です。DTDL v3はJSON-LDベースで、Interface・Property・Telemetry・Relationship・Component・Commandというメタモデルを持ち、Azure上で完結する構成に向きます。NGSI-LDはETSI GS CIM 009 V1.9.1（2025年7月）が現行で、都市やインフラのように主体をまたぐ連携に強い方式です。

{
  "@id": "dtmi:example:Pump;1",
  "@type": "Interface",
  "contents": [
    { "@type": "Telemetry", "name": "vibrationRms", "schema": "double" },
    { "@type": "Property",  "name": "assetId",      "schema": "string" },
    { "@type": "Relationship", "name": "installedIn", "target": "dtmi:example:Line;1" }
  ]
}

時系列側の保持設計｜解像度の段階を分けて長期保存コストを抑える基準

資産モデルには現在値を書き込まず、時系列ストアへの参照だけを持たせます。AWS IoT TwinMakerもこの方式で、時系列プロパティは時系列ストアへの参照を保持し、既定では最新値を返す作りです。マネージド側の機能詳細はAWS IoT TwinMakerの概要を解説した記事にまとめています。

保存側は解像度を段階化しておくと費用が読めるようになります。生データは1から3か月、1分平均は1年、1時間平均は5年、といった具合に用途ごとの寿命を決める設計です。圧縮方式や保持ポリシーの具体は時系列データベースの圧縮・保持設計と製品選定を扱った記事へ委ねます。

識別子の設計｜タグ名と資産IDを分離して設備更新に耐えさせる基準

見落とされがちですが、識別子の設計は寿命を左右します。現場のタグ名はPLCのアドレスや工事時の命名に引きずられ、機器更新や盤の入れ替えで変わるものです。この名前をそのままツイン側の主キーにすると、更新のたびに履歴が分断されます。

資産IDは現場の命名から独立して発番し、タグ名との対応表をバージョン管理下に置いてください。対応表に有効期間を持たせておくと、過去データを当時のタグ名で遡れます。設備台帳や保全システムのIDと突き合わせる列も、この表に持たせておくと後が楽になるはずです。

3Dモデルとの紐付け｜CADからglTFへ落として座標にひも付ける

3Dは目的がはっきりしているときだけ効きます。位置を示して非専門家に伝える必要があるか、という基準で入れるかどうかを決めてください。計器値の集合を専門家が読む用途なら、一覧と時系列グラフのほうが速く判断できます。

CADデータの軽量化｜表示用と解析用で用途別モデルを分けて持つ理由

設計用のCADモデルをそのままブラウザで開くのは現実的ではありません。AWS IoT TwinMakerも、Web表示向けに軽量化して.gltfまたは.glb形式へ変換したモデルを取り込む前提を置いています。ポリゴン数を落とし、内部構造を省いた表示用モデルを別に作る工程が要ります。

一方で、寸法や物性を持つ解析用モデルは元のCADのまま残します。2つを別物として管理し、どちらが正でどちらが派生かを決めておく。表示用を手直しして寸法がずれ、解析結果と食い違う事故は、この区別が曖昧なときに起こります。

3D要素とプロパティの結び方｜参照をIDで通して差し替えに耐える

シーン上の座標にタグを置き、そのタグからエンティティのプロパティを参照する形にします。TwinMakerではタグは1つのコンポーネントに対応し、シーンの特定座標に付ける注釈として扱われます。3Dファイル側にデータを埋め込まないのが要点です。

この作りなら、レイアウト変更で3Dを差し替えても、タグの座標を打ち直すだけで紐付けが復元できます。逆に3Dのメッシュ名に意味を持たせると、CADを出し直した瞬間に対応が壊れる。参照は必ずIDで通してください。

同期頻度とレイテンシの設計｜用途別の許容遅延と処理配分の決め方

すべてを秒単位で同期させる必要はありません。むしろ全体を最短の要件に合わせると、通信費も基盤コストも跳ね上がります。用途ごとに許容遅延を決め、そこから頻度を逆算するのが設計の順序です。そもそも同期を仕様として持つかどうかが従来の解析との分かれ目になる点は、デジタルツインとシミュレーションの違いを同期の要件から整理した記事で扱っています。

用途別の許容遅延｜監視・予知保全・制御で桁が変わる要件の比較

監視とアラートは秒から十数秒あれば足ります。異常が起きてから人が動き出すまでの時間を考えれば、それ以上速くしても価値は増えません。予知保全は劣化の傾向を見る用途なので、分から時間の粒度で十分に成立します。この粒度で集めたデータを機械学習へ渡す側の設計は、デジタルツインとAIの連携｜学習データの作り方と推論結果を戻す設計で扱っています。

問題は制御へ戻す場合です。ミリ秒から秒の応答が要る制御ループにクラウド往復を挟むのは無理があり、そこはエッジ側で閉じた制御系として作る。設計・検証目的のシミュレーションは、そもそもバッチで回せば足ります。

遅延予算の割り付け｜通信区間ごとに分解して上限を洗い出す手順

要件が決まったら、区間に分解して予算を配ります。センサーの取得周期、ゲートウェイのバッファ、通信、取り込み、集計、描画までを並べ、それぞれに上限を割り当てる進め方です。

区間	設計変数	詰まりやすい点
取得	サンプリング周期	機器側の上限に張り付く
伝送	送信間隔とQoS	再送で遅延が伸びる
取り込み	バッチサイズ	まとめすぎて鮮度が落ちる
表示	更新間隔	ポーリング周期が支配的

実務で頻出するのは、センサーを1秒周期にしたのにダッシュボードの更新が30秒ポーリング、という組み合わせです。実効の鮮度は最も粗い区間で決まるため、この構成の鮮度は30秒でしかありません。予算表を先に作れば、こうした無駄な作り込みは避けられます。

双方向制御を入れるか｜現実側へ戻す場合に追加される3つの要件

仮想側の判断を現実の設備へ戻す構成にすると、要件が一段増えます。誰がどの権限で指示を出せるかの認可、いつ何を送ったかの監査ログ、通信断や異常値のときに安全側へ倒すフェイルセーフが必須になります。

マネージドサービスの前提も確認してください。AWS IoT TwinMakerの公式ドキュメントには、危険な環境やクリティカルシステムの運用での使用は想定しないこと、収集データは用途に応じて正確性を評価すべきこと、物理システムが安全に動いているかを判断する人の監視の代替にはしないことが明記されています。可視化のツインと制御系は別物として設計するのが妥当だと考えます。

設計の採用条件と見送り場面｜着手範囲をデータ要件で決める基準

最後に判断を言い切ります。デジタルツインは対象を選べば効きますが、条件が揃わないまま着手すると、可視化だけが残って費用が積み上がる結果です。着手の線引きを条件の形で示します。

小さく始める単位の決め方｜設備1台から広げるための3つの前提条件

最初の単位は設備1台、計測点10から30点で足ります。ここで3つの前提を確認してください。1つ目はセンサーが既にあるか後付けできること。2つ目は比較対象になる正常時のデータが3か月以上取れること。3つ目は効果を数値で測る指標が決まっていることです。

この3点が揃うなら着手して構いません。逆に、正常時データが貯まる前にモデルを組み始めると、異常の定義が主観になり、後で作り直しになります。センサー設置から3か月は素直に待つほうが結果的に速い、というのが実務的な結論です。

見送りが妥当な場面｜データ源と効果測定が揃わないときの判断基準

見送りを勧めるのは次の場合です。データ源が人手入力中心である、対象の状態が月単位でしか変わらない、効果指標が見える化にとどまり金額や時間へ換算できない。いずれかに当てはまるなら、ツインではなくBIとセンサー可視化で足ります。

この判断を先に済ませておくと、投資対効果の説明も楽になります。導入判断そのものの考え方は親記事側で整理しているため、事業側の合意形成が先だという段階なら、そちらを参照してください。製造業の工場が着手順序と投資回収をどう置くかは、製造業のデジタルツインの着手順序と投資回収を整理した記事で扱っています。

マネージドか自前か｜TwinMakerを採る条件と外れる条件の整理

マネージドを採る条件は明快です。データが既にAWS上にあり、3D可視化まで含めて短期に立ち上げたいならTwinMakerが向きます。エンティティとコンポーネントで資産を表し、時系列は外部の参照として持ち、Grafanaへプラグインで出す構成が既に用意されているためです。

外れる条件も明快で、オンプレとクラウドが混在する、資産情報を社外と交換する要件がある、複数拠点のツインを後から連合させたい場合は、AAS準拠などの標準に寄せて自前で組むほうが後の自由度が残ります。どちらを採るにせよ、収集層と時系列基盤の設計は共通して必要です。設備データの収集から基盤構築までを含めて相談したい場合は、データ分析基盤構築・MLOps構築支援で受け付けています。