ツインは組んだ、データも溜まっている、ではAIをどう載せるのか。この段になると、資産モデルのどの属性が特徴量になるのか、故障が起きた瞬間の設備状態をどう再構成するのか、出てきた予測値をツインのどこへ置くのか、という決めごとが一気に立ち上がります。この記事では、デジタルツインと機械学習をつなぐ接続面を、学習データの作り方、推論結果の書き戻し、シミュレーション由来の合成データ、精度検証の順に分解しました。デジタルツインそのものの定義や導入効果はデジタルツインとは何かを事例と導入判断からまとめた記事に譲り、ここはAI連携に絞ります。
まとめ｜デジタルツインにAIを載せる前に決める5つの論点と着手順序
先に結論を置きます。第1に、AIへ渡す価値があるのは生のセンサー値ではなく、資産モデルが持つ文脈です。どの設備のどの部位か、上流に何がつながっているかという構造情報が特徴量に入るかどうかで、モデルの性能差が出ます。第2に、学習データはイベントタイムで結合する。同期頻度が層ごとに違うツインでは、到着順に並べた時点で相関が壊れます。
第3に、推論結果は実測値と同じプロパティへ書かない。予測は予測として別系統に持ち、どのモデル版がいつ出した値かを添えます。これを怠ると、半年後には「この数字はセンサーの実測か推論か」が誰にも判別できなくなる。第4に、シミュレーション由来の合成データは、故障データが集まらない対象に限って混ぜます。評価用データには一切混ぜません。
第5に、検証はツインを再生装置として使い、時点を戻して答え合わせをする。運用に入ってからは入力分布のずれを見張ります。着手順序は、資産IDの整理、ラベルの起こし方、書き戻し先の設計、この3つを先に固めてからモデルに手を付ける形が安全です。以下、それぞれを設計の変数まで下ろします。
デジタルツインがAIへ渡せるデータの正体｜資産モデルと時系列の役割分担
ツインが持つデータは二層に分かれます。設備の構造と属性を持つ資産モデル側と、計測値が流れ込む時系列側です。AI側から見ると、この二層は担う役割がまったく違います。
資産モデルが持つ文脈情報｜設備属性と接続関係が特徴量として効く場面
時系列だけを見るモデルは、同型機の学習結果を別の号機へ持っていくと精度が落ちます。原因の多くは、設備固有の条件がモデルに入っていないことです。定格出力、設置年、直近のオーバーホール時期、上流工程の設備といった属性は、資産モデル側にあります。AWS IoT TwinMakerでいえば、単一値の非時系列プロパティがエンティティのメタデータとして直接格納され、リレーションシッププロパティが他エンティティへの参照を持つ構造です。この参照をたどれば「このポンプの上流はどのタンクか」が取れる。
実務では、静的属性をカテゴリ変数として入れるところから始め、次に関係性を集約特徴へ落とします。上流3設備の直近1時間の平均負荷、といった形です。逆に、号機が1台しかなく属性差が存在しない対象では、この層を足しても結果は動きません。
時系列側の粒度と欠測｜同期頻度の差が学習データに残す穴の埋め方
ツインの同期頻度は用途ごとに違う値で設計されます。監視系は秒、日次の集計値は1日1回、といった具合です。これを素直に横へ並べると、大半の列が欠測になった疎な表ができあがる。埋め方の判断は3択です。前方補完で保持する、対象の粒度へ集約して落とす、欠測そのものを特徴量にする。
センサー値なら前方補完が自然ですが、稼働フラグのような状態値を前方補完すると、停止中の設備が動いていることになります。ここは集約側へ寄せます。欠測率が5割を超える列は、いったん落として効果を見るほうが早い。なお、どの層をどの頻度で同期させるかという上流の設計そのものは、収集層とデータモデルと同期頻度の決め方を整理した記事で扱っています。
点名と資産IDの対応付け｜AI連携で最初に詰まる識別子の設計
学習データを作ろうとして最初に止まるのは、たいていモデリングの話ではありません。現場の点名（タグ名）とツイン側の資産IDが1対1に対応していない、という地味な問題です。PLCの点表は工事ごとに追記され、同じ設備が別名で2回登録されていることがある。改修で点名が変わっても、過去データは旧点名のまま残ります。
対応表には有効期間を持たせ、ある時点でどの点名がどの資産を指していたかを引けるようにします。この設計を後回しにすると、3年分の履歴を学習に使おうとした瞬間に、途中で意味の変わった列を掴むことになる。着手順序としてここが最初に来る理由です。
学習データセットの作り方｜ツインの履歴から故障時点の状態を再構成する手順
ツインを持っている強みは、過去のある時点における設備全体の状態を復元できる点にあります。学習データの作成は、この復元を繰り返す作業です。
時刻の合わせ方｜イベントタイムで結合しないと壊れるセンサー間の相関
センサーが値を計測した時刻と、その値がクラウドに到着した時刻は一致しません。ゲートウェイのバッファ、通信断からの再送、エッジ側の間引き周期で、到着は数秒から数十分ずれます。到着時刻で結合すると、実際には同時に起きた振動上昇と温度上昇が別々の行に分かれ、モデルは相関を学べません。
結合キーは計測時刻に固定します。そのうえで、遅れて届いた値をどこまで待つかの締切を決める。予知保全のように分から時間の粒度で判断する用途なら、締切を数分取っても実害は出ません。逆に、締切を設けずに全件を待つ設計にすると、バッチが永久に終わらない日が来ます。
ラベルの作り方｜保全記録を資産IDと発生期間で突き合わせる手順
教師ありで学習するなら、正常か異常かの区間を切る必要があります。材料になるのは保全記録、作業伝票、アラーム履歴です。手順は次の順で進めます。
- 保全記録を資産IDへ紐付け、対象設備を確定する
- 作業実施日から遡って、故障が進行していた期間を推定する
- その期間を異常ラベル、直近の計画停止までを正常ラベルとして切る
- 計画保全と事後修理を区別し、計画保全は学習対象から外す
難所は2番です。作業日は「壊れた日」ではなく「直した日」で、劣化はその何日も前から始まっています。遡り期間を7日にするか30日にするかでラベルの意味が変わるため、複数の候補で作って精度を比べる形になります。
特徴量の切り出し｜窓幅と集約の単位をユースケース別に決める判断基準
時系列から特徴量を作るには、どれだけの長さを1件と見るかを決めます。判断軸は、予測したい事象が進行する時間スケールです。ベアリングの摩耗のように週単位で進むものに1分窓は短すぎ、突発的な過負荷に1週間の平均は鈍すぎる。
| 用途 | 窓幅の目安 | 主な集約 | 予測の出力単位 |
|---|---|---|---|
| 異常検知 | 1分〜1時間 | 平均・標準偏差・尖度 | スコア（連続値） |
| 故障予測 | 1日〜30日 | 傾き・変化率・累積稼働 | 期間内の故障確率 |
| 需要予測 | 7日〜52週 | 曜日別平均・季節成分 | 次期間の数量 |
窓を複数持たせて併用する構成が実務では多く見られます。短窓で急変を、長窓で傾向を捉える形です。どの手法でモデルを組むかは用途ごとに別の判断になるため、異常検知の手法選択と需要予測のアルゴリズム選択は、それぞれ独立した論点として切り離してください。
推論結果をツインへ戻す設計｜予測値と実測値を分けて持つプロパティ構成
AI連携がループになるのは、推論結果がツイン側へ返って初めてです。ISO 23247-5:2026（2026年6月発行）が定義するデジタルスレッドも、ライフサイクルを通じた双方向で信頼できる情報の流れとして規定されています。戻し先の設計を先に決めておく理由がここにあります。
予測プロパティの置き方｜TwinMakerのコンポーネントで実測と分ける構成
やってはいけないのは、予測した温度を実測温度と同じプロパティへ上書きすることです。履歴が汚染され、そのデータで次のモデルを学習させると、自分の出力を学び直す循環に入ります。TwinMakerであれば、推論結果を別コンポーネントとして定義し、時系列プロパティが時系列ストアへの参照を持つ性質をそのまま使って、予測値用のストアを指させます。
DTDL v3で記述する場合は、実測値を表す Telemetry と状態を保持する Property がメタモデル上で別概念として定義されているため、予測は Property 側に置き、名前空間で実測と区別する形が扱いやすい。命名規則は最初に決めます。
推論の由来の記録｜どのモデル版がいつ出した値かを残す最小の項目設計
予測値だけを書き戻すと、半年後に「この時期の予測がずれていた原因」を追えなくなります。最小限、次の4項目を予測値に添えてください。モデル識別子、モデルの版、推論実行時刻、入力データの計測時刻範囲。この4つがあれば、精度が落ちた期間とモデル更新の履歴を突き合わせられます。
加えて、予測の確信度を持たせておくと運用が楽になります。確信度が低い予測をアラームに上げない、という制御が現場側の信頼を保ちます。
3Dとアラームへの反映｜どこの設備が危ないかを位置で示す表示設計
ツインの3D表示に予測を載せる価値は、位置の特定にあります。TwinMakerのシーンでは、タグがx,y,z座標に置かれ1つのコンポーネントに対応するため、予測コンポーネントを参照するタグを置けば、異常スコアの高い設備がその場所で色を変えます。組み込みのアラームコンポーネントは外部データソースの時系列アラームを受ける種別なので、推論側でしきい値判定まで済ませてアラームとして流す構成が素直です。
ただし、AWS公式は TwinMaker を危険な環境やクリティカルシステムの運用向けとしては想定せず、物理システムの安全稼働を評価する人の監視の代替にしないことを明記しています。予測表示はあくまで判断材料として置き、安全系のインターロックは別系統に残してください。
シミュレーション結果の学習利用｜実データの穴を合成データで埋める条件
優秀な保全をしている現場ほど故障が起きず、学習させたい故障データが手元にない。この矛盾を埋める手段が、ツイン側のシミュレーションで異常状態を作り出すやり方です。
合成データが効く条件｜故障データが集まらない現場での使いどころ
合成データが有効なのは、対象の物理挙動が式で書ける範囲に収まっている場合に限られます。ポンプのキャビテーション、配管の閉塞、モーターの偏心のように、支配方程式が既知で、パラメータを振れば異常時の挙動が再現できる対象です。逆に、複数要因が絡む品質不良や人の操作が介在する事象では、作った異常が現実の異常と別物になります。
物理解析そのものを機械学習で置き換える話、つまりCAEの解析結果を学習データにしてサロゲートモデルを作る設計は、それ自体が独立した論点です。学習データの調達設計や外挿域での破綻検知については、CAEを機械学習で高速化する仕組みを整理した記事で扱っています。
現実とのずれの扱い｜ドメインランダマイゼーションと転移学習の役割分担
シミュレーションと現実の間には必ずずれが残ります。センサーのノイズ特性、設置ばらつき、環境条件が完全には一致しないためです。対処は二方向あります。ひとつは生成側でばらつきを意図的に振るドメインランダマイゼーション。NVIDIA の Omniverse Replicator は Isaac Sim に内蔵された合成データ生成フレームワークで、物理ベースレンダリングとプログラム可能なドメインランダマイゼーション、自動アノテーションを組み合わせる設計になっています（公開ドキュメントは6.0系・2026年8月時点）。
もうひとつは学習側で寄せる方向で、合成データで事前学習し、少量の実データで微調整する構成です。どちらか一方を選ぶのではなく、併用が前提になります。
混ぜ方の実務｜合成と実測の比率と評価データを分ける際の線引き
比率に唯一の正解はありませんが、決め方の順序はあります。まず評価データを実測のみで固定する。次に学習データ側で合成の比率を段階的に上げ、評価スコアが頭打ちになる点を探します。合成を増やすほど良くなるわけではなく、ある比率を超えるとシミュレーションの癖を学び始める。
絶対に守る線は1本です。評価データに合成を混ぜない。混ぜた瞬間、その数字は現実の性能を表さなくなります。
精度検証の組み方｜過去再現による答え合わせと運用後の入力分布の監視
ツインを持っていると、検証の方法がひとつ増えます。時点を戻して当時の状態を復元し、そこから先の予測を答え合わせできることです。
過去再現による検証｜時点を戻して予測を答え合わせする手順の組み方
やることは単純で、過去のある時点までのデータだけでモデルに入力を作り、その後に実際に何が起きたかと突き合わせます。時点をずらしながら繰り返せば、検証件数を稼げる。注意点は、未来の情報が特徴量に混ざらないことです。集計値を全期間から作ってしまう、保全記録を先に参照してしまう、といった漏れが起きやすい箇所になります。
再現の起点は、資産IDと点名の対応表の有効期間に合わせます。対応が変わった時点をまたぐ再現は、別データセットとして切ってください。
指標の選び方｜不均衡データでROC-AUCを主指標にしない理由
設備の故障は稀事象で、異常ラベルは全体の1%を切ることも珍しくありません。この分布で ROC-AUC を主指標にすると、正常を正しく正常と言えているだけで高い値が出ます。見るべきは適合率と再現率、あるいは PR-AUC です。
そのうえで、現場が受け入れられる誤報数から運用しきい値を決めます。週に何件の点検指示なら回せるか、という制約が先にあり、指標はそれを満たす範囲で選ぶ順序です。故障予測モデルをどの型で組むか、異常検知として組むのか残存寿命の推定として組むのかという選択は、故障予測モデルの型の選び方を整理した記事で扱っています。
運用後の精度劣化｜設備更新と季節でずれる入力分布の継続的な見張り方
本番に載せた後、精度は静かに落ちます。設備の部品交換、制御パラメータの変更、季節変動で、入力の分布が学習時からずれるためです。ツイン側の資産モデルに更新履歴があるなら、それを劣化の説明変数として使えます。改修イベントの直後に指標が動いていれば、原因の特定は早い。
どの統計量でずれを測り、しきい値をどこに置き、再学習をどう起動するかは、それ自体で設計が要る領域です。指標の選定としきい値設計はドリフト検知の指標としきい値設計をまとめた記事に譲ります。
AI連携の採用条件と見送り場面｜ツインなしで足りる境界を設備条件で切る
ここは言い切ります。デジタルツインとAIの組み合わせは、条件がそろわない現場では投資に見合いません。境界を先に引きます。
採用する3条件｜資産構造と故障履歴と戻し先がそろう場合の線引き
採用の条件は3つです。第1に、設備が複数台あり、号機ごとの属性差や上下流の関係が性能に効く構造であること。第2に、教師ラベルの素材になる保全記録が資産IDに紐付いた形で数年分あること。第3に、推論結果を受け取って動く先が決まっていること。表示だけで終わる予測は、3か月で誰も見なくなります。
3つのうち第2条件が欠ける場合は、ラベル整備を先行させる判断になります。モデル開発を先に始めても、学習データが作れず止まるだけです。
見送る場面｜単一設備の異常検知だけならツインが過剰になる条件
対象が1台で、見たい事象が振動や温度の異常だけなら、ツインは要りません。センサーから時系列データベースへ入れて異常検知を回す構成で足ります。資産モデルを作る工数と、3D表示を維持する工数が丸ごと不要になる。
設備間の関係が固定で変化しない場合も同様で、関係性をモデル化する価値は薄いままです。ツインが効いてくるのは、対象が数十台以上あり、構成が変わり続け、どの設備のどの部位かを位置で示す必要がある規模から。ここを見誤ると、維持そのものが目的化した基盤だけが残ります。投資額と維持費を分けて回収年数を見る手順は、製造業のデジタルツインの投資回収の見方を整理した記事にまとめています。
内製と外注の分岐｜モデルとツイン基盤のどちらを外に出すかの判断
役割分担の分岐は、データの理解が誰にあるかで決まります。設備と工程の知識は社内にしかないため、ラベル定義と検証の受け入れ基準は内製側に残す。一方、学習パイプラインの構築、書き戻し先の設計、再学習の自動化はパターン化できる領域で、外に出しても品質が落ちにくい部分です。
手を動かす人員が確保できない場合は、モデル開発と運用設計をまとめて委託する形が現実的になります。一創では設備データからの故障予測や需要予測を対象に、AI予測分析開発・需要予測開発として、学習データの設計から運用後の再学習までを受託しています。
よくある質問
デジタルツインとAIの連携を検討する際に、実装の現場で繰り返し挙がる質問をまとめました。
デジタルツインなしでもAIの予知保全はできますか？
できます。単一設備の振動や温度から異常を検知する用途なら、センサーと時系列データベースと推論基盤があれば成立します。ツインが効いてくるのは、対象設備が多数あって構成が変わり、号機ごとの属性差や上下流の関係を特徴量に入れたい場合、そして予測結果を位置とともに示したい場合です。まず1台で検知を回し、対象が広がった段階でツイン側へ寄せる進め方が、投資の失敗を避けやすい順序になります。
デジタルツインとAIの連携に必要なデータ量はどのくらいですか？
予測したい事象が何回観測できているかで決まります。故障予測なら、対象故障モードの発生が最低でも十数件、季節変動を跨ぐなら2年分以上の履歴が目安です。センサーの点数よりも、ラベルを付けられる事象の件数が制約になります。件数が足りない場合の選択肢は、教師なしの異常検知に切り替えるか、シミュレーション由来の合成データで補うかの二択です。
シミュレーションで作った合成データだけで学習させても問題ありませんか？
実運用では避けたほうが無難です。合成データは物理式で書ける範囲の挙動しか再現できず、実機のノイズ特性や設置ばらつきが抜け落ちます。合成データで事前学習し、少量の実データで微調整する構成が現実的な落とし所になります。評価用のデータは必ず実測のみで構成してください。合成を評価側に入れると、その精度は現実の性能を表しません。
推論結果をツインに戻すと現実の値と混ざりませんか？
同じプロパティへ書けば混ざります。予測値は実測値とは別のコンポーネントやプロパティに置き、名前空間でも区別してください。あわせて、モデル識別子、モデルの版、推論実行時刻、入力の計測時刻範囲の4項目を添えます。この分離を最初にやっておかないと、後で学習データを作る際に、自分の予測を学習し直す循環に気づけません。
デジタルツインと機械学習を同時に始めるべきですか？
同時着手は勧めません。ツイン側の資産IDと点名の対応、保全記録の紐付け、時刻の基準がそろっていない状態でモデル開発に入ると、学習データが作れず手戻りします。順序としては、識別子とラベルの整備、推論結果の戻し先の設計、この2つを固めてからモデルに着手する形です。先行して精度感を掴みたい場合は、1設備分の履歴で小さく試す範囲にとどめます。
関連記事
- デジタルツインとは？意味・仕組み・事例と導入の判断基準を実装目線で解説：定義・業界別の事例・導入効果と、そもそも自社に必要かの判断はこちらで扱っています。
- デジタルツインの設計｜収集層・データモデル・同期頻度の決め方を実装目線で解説：AIへ渡す前段、収集層のプロトコル変換点とデータモデルの持ち方を設計の粒度で整理しています。
- 予知保全のAI導入｜故障予測モデルの型の選び方と実装先の判断基準：異常検知・故障分類・残存寿命推定という3つの型の選び分けと実装先の判断はこちらです。
- 異常検知とは？機械学習の手法・仕組み・製造業での導入判断まで解説：異常検知そのものの手法と仕組みを、製造業の適用例とあわせて解説しています。
- 需要予測アルゴリズムの選び方と実装手順｜時系列・機械学習・Python：ツイン上のデータを需要予測へ回す場合の、アルゴリズム選択と実装手順を扱っています。
