Semantic Digital Twinをどう評価するか──Ground Truth、意味、安全性、再現性をつなぐ評価フレームワーク

🎥 YouTubeでも公開しています

Physical AIを支えるSemantic Digital Twin｜現実世界を理解し、安全に判断・行動するための意味基盤

Books:Physical AIを支えるSemantic Digital Twin実践ガイド: Chinoba PFで構築するOntology・Knowledge Graph・DSL・Decision Trace

はじめに

Semantic Digital Twinは、現実世界の設備、業務、空間、人、組織を、単なるデータの複製としてではなく、意味・関係・状態・制約・意思決定を持つ対象として扱うための基盤である。

しかし、Semantic Digital Twinを構築しただけでは価値は保証されない。

Ontologyが存在していても現場の概念とずれているかもしれない。Knowledge Graphが大きくても、必要な判断に使えなければ意味がない。AI Agentがもっともらしい説明をしても、誤った状態を前提に行動すれば、安全性を損なう。

問うべきは、単に「Twinがあるか」ではない。

そのTwinは、現実をどの程度正しく意味づけ、必要な判断を支え、安全に再現可能な形で運用できるか。

本章では、Semantic Digital Twinを評価するための枠組みを整理する。評価は一つの正解率では完結しない。対象の定義、Ground Truth、機能、意味、安全性、性能、再現性という複数の観点を接続する必要がある。

41.1 評価対象の定義

最初に行うべきことは、何を評価するのかを明確にすることである。

Semantic Digital Twinは、3Dモデルや設備台帳だけを指すものではない。少なくとも次の要素が相互に結びついたものとして捉える必要がある。

• Entity：設備、部品、文書、顧客、作業者、場所、イベントなどの対象
• Attribute：型式、温度、稼働状態、所有者、期限などの属性
• Relationship：構成、接続、所属、依存、影響、責任などの関係
• State：現在の稼働・進捗・異常・混雑・承認などの状態
• Event：故障、点検、注文、変更、警告、承認などの出来事
• Rule / Policy / DSL：守るべき条件、制約、権限、実行可能なルール
• Decision Trace：どの根拠で、どの判断が行われ、何が実行され、どの結果になったか

したがって、評価対象を「Knowledge Graphの精度」だけに限定すると不十分になる。評価対象は、以下の四層に分けて定義するとよい。

評価層	問うこと	代表的な対象
表現層	現実を必要な概念で表せているか	Ontology、Schema、Entity、Relation
同期層	現実の変化を適切に反映できるか	State、Event、時刻、鮮度
推論層	状況に応じた意味づけや判断ができるか	Rule、KG推論、LLM、Agent
実行・統制層	安全に行動し、説明・監査できるか	Policy、Human Gate、Trace、Rollback

例えば製造設備のTwinなら、「設備名や部品構成が登録されているか」だけではない。

• センサー値から設備状態を正しく認識できるか
• どの部品・工程・品質指標に影響が及ぶかをたどれるか
• 保全ルールに照らして点検や停止を提案できるか
• 停止判断を自動実行してよい条件と、人に引き継ぐ条件を守れるか
• 後から根拠と実行履歴を説明できるか

を一体として評価する必要がある。

評価目的を先に定める

評価指標は、Twinの利用目的によって変わる。設計レビューのためのTwinと、自律的に現場制御を行うTwinに同じ基準を使うべきではない。

• 現場状況の可視化
• 異常の検知と原因候補の特定
• シミュレーションと予測
• 保全・品質・需給に関する意思決定支援
• AI Agentによる業務支援
• 自律実行のための制約・境界の提供
• 監査・説明責任・学習のためのDecision Trace蓄積

目的が決まれば、許容できない失敗も決まる。安全用途における「設備停止の見逃し」は、販促提案の順位誤差とは同列に扱えない。評価設計は、精度の最大化ではなく、目的に対する有用性と失敗時の影響を明確にする作業から始まる。

41.2 Ground Truth

Semantic Digital Twinの評価で最も難しいのは、Ground Truth、すなわち「正しい現実」をどう定めるかである。

現実世界には、完全で矛盾のない正解データが存在するとは限らない。設備台帳は古いかもしれない。業務手順は文書と実態が違うかもしれない。人の意図や組織の状態は、単一のセンサー値では観測できない。

そのためGround Truthを、単一のマスターデータとみなしてはならない。用途に応じて、複数の根拠を組み合わせた検証可能な真実の集合として設計する必要がある。

種類	例	主な検証対象
物理的Ground Truth	実測値、画像、センサー、現地確認	位置、状態、稼働、数量
業務的Ground Truth	承認済み台帳、ERP、作業記録	所有、工程、責任、履歴
規範的Ground Truth	法規、規格、契約、社内規程	許可・禁止、品質、安全条件
意味的Ground Truth	専門家レビュー、用語定義、Ontology合意	概念、分類、関係の意味
結果Ground Truth	実行結果、品質結果、障害記録	判断・行動の妥当性

重要なのは、Ground Truthにも出所・有効期間・信頼度を持たせることである。設備Aの設置場所について、CAD、現地確認、保全台帳の記述が異なる場合がある。そのときTwinは、一つを上書きするだけでなく、矛盾そのものを記録し、確認すべき状態として扱えるべきである。

Ground Truthを作る手順

1. 評価シナリオを定義する
   例：ポンプ異常時に、影響範囲を特定し、停止要否を提案する。
2. 判定対象を分解する
   Entity、状態、関係、制約、期待する判断、許容できない判断を定義する。
3. 根拠ソースを特定する
   センサー、承認済み文書、専門家レビュー、実績ログを紐づける。
4. 時間軸を固定する
   現在の正しさだけでなく、「その時点で何が知られていたか」を再現可能にする。
5. 不確実性を明示する
   未確認、推定、競合、欠損を真偽と混同しない。

Ground Truthは、Twinを採点するためだけのデータではない。Twinの改善優先度を決め、AIの誤りを分析し、組織の知識そのものを更新する基盤になる。

41.3 Functional Benchmark

Functional Benchmarkは、Semantic Digital Twinが必要な機能を実際に果たせるかを評価する。

ここで見るのは、データが格納されているかではなく、Twinを使って問い合わせ、探索、推論、提案、実行統制が成立するかである。

基本的な機能シナリオ

• 指定した設備・顧客・案件の現在状態を取得できるか
• あるイベントから影響を受ける対象をたどれるか
• 条件に合う代替案や担当者を探索できるか
• 必要な制約と承認条件を取得できるか
• 複数の情報源にまたがる問いに、一貫した回答を返せるか
• 状態変化を受けて、必要なアラートやタスクを生成できるか
• 実行前にPolicy違反や権限不足を停止できるか
• 判断後にDecision Traceを記録し、再参照できるか

たとえば「冷却設備の温度異常」というイベントに対して、次を確認する。

1. 異常設備と現在状態を特定できるか。
2. 接続する工程・品質指標・保全責任者を探索できるか。
3. 関連する安全基準、過去事例、停止条件を取得できるか。
4. 点検、負荷低減、停止、エスカレーションという選択肢を生成できるか。
5. 権限とPolicyに従って、提案・人への確認・自動実行を切り替えられるか。

指標例

• Task Success Rate：定義した業務タスクを完了できた割合
• Query Answer Accuracy：状態・関係・規則に関する質問への正答率
• Path Retrieval Accuracy：影響経路や根拠経路を正しく取得できた割合
• Rule Execution Rate：適用すべきルールを正しく実行・提示できた割合
• Trace Completeness：Situation、Evidence、Policy、Action、Resultが記録された割合
• Human Intervention Rate：本来自動で処理できるケースに不要な人手介入が発生した割合

ただし、Task Success Rateだけを追うと危険である。安全上は停止すべき場面で、無理にタスクを完了させるAIは高評価であってはならない。機能評価は必ずSafety Benchmarkと対にして運用する必要がある。

41.4 Semantic Benchmark

Semantic Benchmarkは、Twinが現実世界の概念と関係をどの程度正しく表現・解釈できるかを評価する。

これは単なるEntity Matchingの精度ではない。「ポンプ」「循環系」「保全対象」「停止権限」といった概念が、組織の業務・規則・現場の言葉に照らして整合しているかを問う。

評価する観点

1. 概念の正確性

Entityが正しいクラスに分類されているかを確認する。たとえば「温度センサー」が計測機器であり設備本体ではないこと、「検査工程」が場所ではなくプロセスであることを区別できるかを見る。

2. 関係の正確性

どのEntityが何とどのように関係するかを確認する。

• 部品Aは設備Bの構成要素である
• 工程Cは製品Dの品質に影響する
• 担当者Eは作業Fの承認権限を持つ
• Policy Gは状況Hに適用される

関係は向き、条件、時間的有効性を持つ。過去には接続されていた設備が今も接続されているとは限らないため、時点を無視した関係評価は不十分である。

3. 制約の意味保存

自然言語の規程を取り込んだ場合、重要なのは文章を検索できることではない。条件・例外・責任・禁止事項が意味として保持されていることである。

たとえば「不良率が5%を超えた場合は品質保証部へ通知する。ただし、測定値が未検証の場合は再測定を優先する」という規程なら、閾値、対象、通知先、例外条件、優先順位を分解して扱える必要がある。

4. 推論の妥当性

明示されていないがOntologyやRuleから導ける関係を正しく推論できるかを評価する。一方で、導けないことを勝手に補完しないことも同様に重要である。

指標例

指標	内容
Entity Precision / Recall	Entity抽出・同定の正確性と網羅性
Relation Precision / Recall	関係抽出・リンク予測の正確性と網羅性
Ontology Consistency Rate	型・階層・制約に矛盾しないデータの割合
Constraint Parsing Accuracy	規程・ルールの条件、例外、義務の抽出精度
Temporal Validity Accuracy	関係・状態の時点整合性
Unsupported Inference Rate	根拠なく推論・補完した割合

Semantic Benchmarkでは、正答だけでなく「根拠をたどれるか」を見るべきである。AIが正しい回答を出しても、その概念と関係がどう導かれたか追跡できなければ、運用時に修正・監査・学習ができない。

41.5 Safety Benchmark

Semantic Digital Twinが実行や意思決定に接続されるほど、安全性は中心的な評価項目になる。

ここでいう安全性は、物理的な安全だけではない。品質、法令、プライバシー、権限、顧客影響、事業継続も含む。

何を安全とみなすか

Safety Benchmarkでは、まず禁止すべき状態と行動を明示する。

• 権限のないAIが設備停止を実行しない
• 根拠が不足する状態で、重大な医療・安全判断を確定しない
• 個人情報を必要な範囲を超えて参照・出力しない
• 古いPolicyを用いて現在の判断を実行しない
• 不確実性が大きい場合に、人間の確認なしで不可逆な操作をしない
• 例外条件を無視して通常ルールを適用しない

安全性の評価は、「正しい行動を選べたか」だけではない。

実行すべきでないときに止まれたか。人に引き継げたか。復旧可能な形で実行できたか。

を測る必要がある。

テストすべき失敗条件

• 欠損データ：必要なセンサー値や承認情報が存在しない
• 矛盾データ：台帳、現場、センサーで情報が一致しない
• 古い知識：廃止済みの規程や設備構成が混入する
• 敵対的入力：誤誘導する文書、プロンプト、イベントが与えられる
• 権限逸脱：Roleにない操作を要求される
• 連鎖障害：一つの誤認が別のAgentや工程へ伝播する
• 緊急状態：通常時と異なるPolicy・Human Gateが必要になる

指標例

• Unsafe Action Rate：禁止された行動を実行・提案した割合
• Policy Compliance Rate：適用すべきPolicyに従えた割合
• False Allow / False Deny：本来止めるべき行為を許可した割合／本来許可できる行為を不必要に止めた割合
• Escalation Precision / Recall：人間へ引き継ぐべきケースを適切に検出できたか
• Recovery Success Rate：失敗後に安全な状態へ戻せた割合
• Data Exposure Rate：不要または権限外の情報を露出した割合

Safety Benchmarkでは、想定外の失敗をあえて作る。正常系だけで高い精度を示しても、現実の運用には足りない。Failure InjectionとAdversarial Scenarioを継続的に行い、Boundaryが機能することを確認しなければならない。

41.6 Performance Benchmark

Performance Benchmarkは、Twinが必要な規模・速度・コストで運用できるかを評価する。

Semantic Digital Twinでは、Entity数や文書量だけでなく、関係の密度、時系列イベント、推論深度、同時接続するAgent数が性能を左右する。

主な測定対象

• Ingestion Latency：イベントや文書を取り込んでからTwinに反映されるまでの時間
• State Freshness：Twinの状態が現実とどの程度ずれているか
• Query Latency：状態・関係・影響範囲の問い合わせ応答時間
• Reasoning Latency：Rule、Graph、LLMを含む推論に要する時間
• Throughput：単位時間あたりに処理できるイベント、更新、問い合わせ数
• Graph Scalability：Entity・Relation・履歴が増えたときの性能劣化
• Cost per Decision：一回の状態推定・判断・Trace記録にかかる計算・運用コスト
• Availability：必要なときにTwinが利用可能である割合

性能は平均値だけで評価してはならない。現場運用では、p95やp99の遅延、ピーク時の劣化、障害時の縮退動作が重要になる。

例えば、異常検知から30秒以内に停止判断を支援する用途では、通常時の平均応答が1秒でも、混雑時に数分かかるなら要件を満たさない。逆に、日次の経営分析では、より詳細な推論を優先し、多少の処理時間を許容できる。

性能評価の設計原則

1. 実運用に近いデータ形状を使う
   Entity数だけでなく、関係分布、更新頻度、欠損、履歴の長さを再現する。
2. 推論を分解して測る
   検索、Graph traversal、Rule評価、LLM呼び出し、Trace記録を分けてボトルネックを特定する。
3. 鮮度と正確性のトレードオフを明示する
   常に最新である必要がある状態と、バッチ更新でよい知識を分ける。
4. 安全な縮退を評価する
   外部データやLLMが利用できない場合に、どの機能を止め、どの機能をルールベースで継続するかを確認する。

性能とは単なる高速性ではない。必要な場面で、必要な意味と安全性を保ったまま応答できる能力である。

41.7 Reproducibility Benchmark

AIを含むSemantic Digital Twinでは、同じ入力に対して常に同じ出力が得られるとは限らない。データ更新、モデル更新、外部サービス、LLMの非決定性、時刻依存のContextが結果を変える。

だからこそ、再現性は研究上の問題だけでなく、運用・監査・改善の前提となる。

Reproducibility Benchmarkが問うのは、過去の判断を完全にコピーできるかだけではない。

その時点で何を知り、どのRule・Policy・Model・Prompt・Contextを使い、なぜその結論に至ったのかを、必要な精度で再構成できるか。

記録すべき要素

• 入力データとそのバージョン
• Ontology、Knowledge Graph、Rule、DSL、Policyのバージョン
• 参照した文書・Evidenceと有効時点
• Context、Goal、Constraint、Role
• モデル、プロンプト、ツール、パラメータ
• 候補となった選択肢と判断理由
• 実行内容、結果、評価、Human Gateの記録

これらをDecision Traceとして残すことで、「再現できないAIの出力」を「検証可能な意思決定プロセス」へ変えられる。

指標例

• Replay Success Rate：保存された入力と構成から、過去の判断を再実行・再構成できた割合
• Trace Completeness：再現に必要な要素がTraceに含まれる割合
• Version Pinning Rate：判断時点の知識・モデル・Policyが固定・参照可能な割合
• Evidence Recoverability：判断根拠の文書・データへ再到達できる割合
• Outcome Explainability Rate：結果と根拠を人が確認可能な形で説明できた割合
• Change Impact Coverage：OntologyやPolicyの更新時に、影響する判断・Entity・業務を特定できた割合

再現性を高めることは、変化を止めることではない。むしろ、何がいつ変わり、その変化が判断へどう影響したかを管理できるようにすることで、安全に進化できる。

評価を一つの循環として設計する

ここまでの六つのBenchmarkは、独立したチェックリストではない。

Semantic Benchmarkで発見されたOntologyの曖昧さは、Functional Benchmarkの失敗につながる。Safety Benchmarkで見つかった越権実行は、PolicyとRoleの表現を見直す契機になる。Performance Benchmarkの遅延は、Stateの更新方式やGraph設計を変える必要を示す。Reproducibility Benchmarkの不足は、Decision Traceの設計を改善する必要を示す。

評価の循環は、次のように考えられる。

Ground Truthの整備
        ↓
Functional / Semantic / Safety / Performance評価
        ↓
失敗・差異の分析
        ↓
Ontology・Knowledge・Rule・Policy・実装の改善
        ↓
Decision Traceへの記録
        ↓
再現性の検証
        ↓
次のBenchmarkへ

この循環によって、Twinは静的なモデルではなく、現実との照合を通じて成熟する知識・判断基盤になる。

おわりに

Semantic Digital Twinの価値は、現実を美しく可視化することだけにあるのではない。

現実の状態、関係、制約、変化を意味として扱い、より良い判断と安全な行動につなげられることにある。

そのため評価も、単一の精度指標に閉じてはならない。

• 評価対象を目的とリスクから定義する
• 複数の根拠からGround Truthを設計する
• 実務タスクを完了できるかを測る
• 概念・関係・制約の意味が正しいかを確かめる
• 危険な行動を止め、人に引き継げるかを検証する
• 必要な速度・規模・鮮度で運用できるかを測る
• 過去の判断を説明・再構成できるかを確認する

これらを継続的に評価することで、Semantic Digital Twinはデータ統合の仕組みを超え、AIと人が現実を共有し、協調して判断するためのTrust Infrastructureへと進化していく。