Physical AIを企業で使える形にする：IoT・LLMからSemantic Digital TwinとGoverned Agentへ

🎥 YouTubeでも公開しています

Physical AIを企業で使える形にする｜IoT・LLMからSemantic Digital TwinとGoverned Agentへ

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

工場や物流現場、保全業務でAIを使うとき、多くの取り組みは二つの形から始まる。

一つはIoTである。温度、振動、稼働率、電力、画像などを収集し、ダッシュボードで可視化し、閾値を超えたらアラートを出す。

もう一つは、LLMを使った対話型の支援である。担当者が「なぜこの設備は止まったのか」「どう対処すべきか」と質問し、AIがマニュアルや過去報告を参照して回答する。

どちらも有用である。しかし、実際の現場で必要なのは、センサー値の表示でも、もっともらしい文章の回答でもない。

手元に、以前使っていたRaspberry Piが数台ある。これをあらためて眺めながら、単なる小型IoT端末としてではなく、Semantic Digital TwinとPhysical AIの文脈で何ができるのかを考えてみた。設備や工程の近くで物理世界を観測する小さなAsset Twinと、中央で知識・統制・LLM利用を担う層を組み合わせれば、企業で使えるPhysical AIの最小構成を作れるのではないか。

いま何が起きているのか。どの知識がこの状況に適用できるのか。何を実行してよいのか。誰が承認すべきか。そして、その判断を後から説明できるのか。

この問いに応えるためのアプローチが、Semantic Digital Twin と Governed Agent である。本稿では、複数のAsset Twin、中央のKnowledge Twin、Governance / Decision Twin、そしてEnterprise AI Gatewayを組み合わせたPhysical AIの構成を考える。

Physical AIは「AIが機械を動かすこと」だけではない

Physical AIという言葉から、ロボットの自律制御を思い浮かべることが多い。しかし企業で重要なのは、LLMに設備を自由に操作させることではない。

Physical AIは、物理世界を観測し、その状態を意味として理解し、根拠・制約・権限を確認したうえで、人や設備に安全な行動を促し、結果を再び観測する閉ループとして捉えられる。

Observe → Contextualize → Reason → Govern → Act → Verify

たとえば、温度センサーが213.8℃を返しても、それだけでは判断できない。それが「どの設備の、どのゾーンの、どの製品を生産している最中の値か」、設定変更後か、金型交換直後か、材料ロットは何か、許容範囲はどこにあるかによって意味が変わる。

この意味付けを担うのがAsset Twinであり、過去知識との照合を担うのがProcess / Knowledge Twin、実行可否と責任を担うのがGovernance / Decision Twinである。

従来のIoT＋LLMとの違い

従来型が役に立たないわけではない。むしろ、センサー接続、監視、異常検知、文書検索は必要な土台である。違いは、それらを「判断可能な状態」に接続するかどうかにある。

Asset Twin：センサーの代理ではなく、現場状態の意味モデル

Asset Twinは、設備のデジタルコピーを作るだけではない。設備の状態と文脈を統合し、他のシステムが利用できる意味付きの事実として返す。

Asset Twinが持つべき機能は、次の五つに整理できる。

1. Observe：温度、振動、稼働、アラーム、保全作業、設定変更を取得する。
2. Contextualize：値を設備、部品、工程、製品、材料、設定、時刻に結び付ける。
3. Detect：閾値超過だけでなく、傾向変化、異常な組合せ、構成変更を検出する。
4. Explain：何が、いつから、通常とどう違うのかをイベントとして表現する。
5. Remember：状態遷移、保全、変更、対応、結果を履歴として保持する。

例えば、Asset Twinは生データではなく、次のような状態を返す。

成形機A / Zone 3 / 製品Xの生産中。
温度は標準上限より3.8℃高く、30分間上昇傾向が続く。
金型交換後12時間。過去30日の同条件では未発生。

この時点では、Asset Twinは「温度を下げるべきだ」と最終判断しない。現場の事実を、判断可能な粒度と意味で提示することが責務である。

複数のAsset Twinと、中央の知識・統制層

実装としては、各設備や工程の近くに複数のAsset Twinを置き、知識と統制は中央化する構成が扱いやすい。

Asset Twin群（現場エッジ）
  ├─ 成形機の状態・保全履歴
  ├─ 検査機の品質イベント
  └─ 梱包装置の停止・消耗品状態
          ↓
Process / Knowledge Twin（中央）
  └─ 標準書、仕様書、品質記録、過去障害、適用条件
          ↓
Governance / Decision Twin（中央）
  └─ 権限、承認経路、禁止事項、リスク閾値、Decision Trace
          ↓
Enterprise AI Gateway / Orchestrator
  └─ LLM利用統制、Agent呼出し、説明可能な提案

Asset Twinを現場に近い小型コンピュータに置く理由は、計算性能ではない。IoTネットワークとの接続、低遅延の状態把握、ネットワーク断時の最低限の運転、設備ごとの責任境界を持たせるためである。

一方、文書知識や承認ルールは、拠点ごとに分裂させない方がよい。Process / Knowledge Twinは、標準書の版、対象設備、材料、工程、適用条件、例外をSemantic Chunkとして管理する。Governance / Decision Twinは、「誰が何を実行できるか」「どの条件で承認が必要か」を全社で一貫して扱う。

LLMは判断の唯一の主体ではない

この構成でLLMが担うのは、問いの分解、状態の要約、根拠候補の解釈、対応案の生成、説明の作成である。

一方で、権限、禁止事項、承認条件、操作上限、安全閾値は、決定的なルールとしてGovernance / Decision Twinに置く。重要な操作を、LLMの文章出力だけで許可してはならない。

Enterprise AI Gatewayは、この境界を守るための入口となる。

• 外部LLMへ送る情報を最小化・マスキングする
• モデルごとの利用条件、コスト、レイテンシを管理する
• 通常は低コストモデル、重要な検証だけ高性能モデルに振り分ける
• プロンプト、モデル、出力、ポリシー判定をDecision Traceへ残す
• 将来、外部LLM、社内モデル、ローカルモデルを切り替え可能にする

ここでLLMは、企業の知識や権限の保管場所ではなく、Gateway管理下の交換可能な知能資源となる。

multi-agent化は必須ではない

この構成をすぐmulti-agentと呼ぶ必要はない。Asset Twinが状態を提供し、中央が一つのワークフローで処理するだけでも、十分に価値のあるSemantic Digital Twinソリューションになる。

multi-agentの価値が出るのは、異なる主体の判断を協調させる必要が生まれたときである。

たとえば、次の問いはAsset Twin単独では答えられない。

• この設備を止めるべきか。
• 他ラインへ生産を振り替えるべきか。
• 過去の対策を今回も適用してよいか。
• 設定を変更する権限は誰にあるか。
• 品質保証の承認なしに試験生産を始めてよいか。

この段階で、Asset Agent、Knowledge Agent、Governance Agent、Orchestrator Agentという責務分離が効いてくる。各Agentは、別々の根拠と制約を持ち、互いの出力をそのまま信じずに照合できる。

ただし、Agentを増やすこと自体が目的ではない。役割、データ所有権、失敗時の振る舞い、責任境界が明確なときにだけ、Agentとして分離するべきである。

具体例：温度逸脱から承認付きの試験生産まで

成形機AのZone 3で温度逸脱が発生した場面を考える。

1. Asset Twinが、温度超過、継続時間、金型交換後の経過時間、材料ロットを含むイベントを発行する。
2. Process / Knowledge Twinが、類似障害、成形標準書、適用条件を検索する。
3. Knowledge Twinは「温度を3℃下げる対策は存在するが、今回の材料ロットは過去事例と異なる」と返す。
4. Governance / Decision Twinが「計測強化は現場責任者で可、温度設定変更と試験生産には品質保証の承認が必要」と判定する。
5. Orchestratorが、LLMを使って根拠付きの提案を整形し、品質保証責任者へ承認依頼を出す。
6. 承認後にのみ、許可された試験生産モードへ移る。
7. 結果をAsset Twinが再観測し、Decision Traceに実行結果を追記する。

最終的な画面に必要なのは、派手なAIの会話ではない。

判断：条件付きで試験生産を推奨
根拠：標準書 v3.2 / 過去障害 #142
差分：材料ロットが異なる
リスク：中
必要承認：品質保証責任者
実行：承認後に10個の試験生産
検証：寸法・外観検査の結果で再評価

この形式なら、現場担当者、品質保証、保全、情報システムのいずれも、AIが何を根拠にどこまで判断したかを確認できる。

実装を始める順序

最初から大きなプラットフォームを作る必要はない。

1. 複数のAsset Twinで、状態・イベント・履歴を意味付きで返す。
2. Process / Knowledge Twinに、小規模な手順書・障害報告・品質基準をSemantic Chunkとして取り込む。
3. Governance / Decision Twinに、承認マトリクスと禁止ルールを実装する。
4. Enterprise AI Gatewayを経由して、LLMに状態要約と許可済み根拠だけを渡す。
5. Decision Traceで、観測から承認・実行・結果までを一つのケースとして残す。

最初はセンサー値も操作も疑似データでよい。大切なのは、物理イベントが、知識・統制・実行・検証のループに接続されていることを示すことである。

結び：Physical AIを「統制された行動の基盤」へ

企業に必要なのは、物理世界を見て文章を生成するAIではない。現場の状態を意味として理解し、適用可能な根拠を探し、権限と安全制約を確認し、人と協調して行動し、その結果を説明可能な形で残すAIである。

Semantic Digital Twinは、そのための状態と関係の基盤になる。Asset Twinは現場の事実を捉え、Knowledge Twinは利用可能な知識を限定し、Governance / Decision Twinは判断の境界を守る。Enterprise AI Gatewayは、外部LLMを便利だが統制可能な知能資源として接続する。

Physical AIの価値は、自律的に動くことそのものではない。根拠・制約・責任を持って、物理世界に安全に関与できることにある。

まずは、複数のRaspberry PiをAsset Twinとして動かし、Mac上にProcess / Knowledge Twin、Governance / Decision Twin、Enterprise AI Gatewayを置く最小構成から、この方向で近々実装してみようと思う。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance