🗂

Physical AI 向け汎用プラットフォーム構想

Iwaki

2026/04/12に公開

 Physical AI 向け汎用プラットフォーム構想
 Microsoft Foundry + Unity ベース
 1. 目的Microsoft Foundry を知能基盤（推論、エージェント、ツール実行、評価、監視）として使い、Unity を現実世界との接点（3D UI / XR / デバイス制御 / 状態可視化）として使うことで、ロボット、XR支援、現場作業支援、設備監視、教育訓練、遠隔操作支援など、さまざまな Physical AI プロジェクトに横展開できる共通基盤について検討してみました。

 2. このプラットフォームの考え方Physical AI を個別案件ごとにゼロから作ると、毎回次のようなものを作り直すことになります。
センサー入力の取り込み
状況理解
AI への問い合わせ
AI の判断結果の可視化
操作 UI
安全制御
ログ / 評価 / 監視
そこで、これらを共通レイヤー化します。

特に Foundry 側では、モデル利用だけでなく、agent が tool を呼ぶ構成や、trace / evaluate / monitor を組み込めるため、単なるチャットAIではなく、現実世界に作用する AI ワークフロー基盤として設計しやすいです。

 3. 想定ユースケース
 3.1 現場作業支援作業員が HMD やタブレット越しに設備を見ると、Unity 上で設備状態・手順・警告を重畳表示し、Foundry 側の agent が「今どの手順を提示すべきか」「異常兆候に対して何を提案すべきか」を判断します。検索や社内ナレッジ照会が必要なら、tool 経由で検索系 API や業務 API を呼び出します。

 3.2 ロボット / AMR / ドローン支援ロボットから位置・障害物・バッテリー・タスク状態を受け取り、Unity で 3D デジタルツインとして表示します。Foundry 側では「次の行動候補生成」「異常時の代替行動」「人へのエスカレーション」を agent が担います。

 3.3 教育 / 訓練シミュレータUnity で訓練空間や装置モデルを再現し、Foundry を使って、受講者の発話・操作・行動ログからリアルタイムに指導コメントを返す構成です。評価結果は trace と dataset に蓄積し、後からシナリオ改善に回せます。

 3.4 設備監視・保守IoT や映像から異常候補を検知し、Unity で設備のどこが怪しいかを 3D 表示、Foundry agent が保守履歴やマニュアルを参照して、点検候補や優先度を提示します。

 4. プラットフォーム全体アーキテクチャ[Physical World]
  ├─ Camera / Depth / Mic / IMU / IoT / Robot State
  ├─ Operator Input (Voice / Gaze / Hand / Controller / Touch)
  └─ External Systems (MES, ERP, Ticket, Manual DB, GIS, CAD, PLC)

        ↓

[Unity Runtime Layer]
  ├─ Device Adapter Layer
  │   ├─ XR Adapter (OpenXR)
  │   ├─ Mobile/Tablet Adapter
  │   ├─ Robot Adapter
  │   └─ Sensor Adapter
  │
  ├─ Interaction Layer
  │   ├─ Voice Command
  │   ├─ Hand / Controller Interaction
  │   ├─ Spatial UI / 3D Annotation
  │   └─ Workflow UI
  │
  ├─ Scene Understanding / Digital Twin View
  │   ├─ Asset Viewer
  │   ├─ Task State Overlay
  │   ├─ Alert Visualization
  │   └─ Replay / Simulation
  │
  └─ AI Gateway Client
      ├─ Request Composer
      ├─ Context Packager
      ├─ Safety Precheck
      └─ Result Renderer

        ↓ HTTPS / WebSocket / Event Bus

[Microsoft Foundry / Cloud AI Layer]
  ├─ Agent Orchestration
  │   ├─ Planner Agent
  │   ├─ Safety Agent
  │   ├─ Retrieval Agent
  │   └─ Action Agent
  │
  ├─ Model Layer
  │   ├─ LLM / VLM
  │   ├─ Speech / Multimodal
  │   └─ Specialized Models
  │
  ├─ Tool Layer
  │   ├─ Search Tool
  │   ├─ Business API Tool
  │   ├─ Robot Command Tool
  │   ├─ Ticket/Workflow Tool
  │   └─ Simulation Tool
  │
  ├─ Knowledge Layer
  │   ├─ Azure AI Search
  │   ├─ Vector / Hybrid Search
  │   ├─ Manuals / SOP / Logs
  │   └─ Operational Memory
  │
  └─ Governance / Ops
      ├─ Tracing
      ├─ Evaluation
      ├─ Monitoring
      ├─ RBAC / Policy
      └─ Content Safety

        ↓

[Execution / Actuation Layer]
  ├─ Suggest only
  ├─ Human approval required
  └─ Auto-execute allowed (bounded actions only)
この構成のポイントは、Unity を「表示アプリ」ではなく Physical AI のフロント実行基盤にすることと、Foundry を「LLM呼び出し先」ではなく agent / tool / evaluation / governance を含む知能中枢にすることです。

 5. レイヤー別の役割
 5.1 Unity 側の役割Unity は以下を担当します。
センサーや操作入力の統合
3D / XR UI の提示
空間内オブジェクトや設備の可視化
AI判断結果の人にとって分かりやすい表現
現場での即応性が必要な軽いローカル判定
クラウドへ送るコンテキストの整形

 Unity 共通モジュール案/Runtime
  /Core
    AppStateManager
    EventBus
    ConfigManager
    SessionManager

  /Devices
    OpenXRAdapter
    HandTrackingAdapter
    ControllerAdapter
    CameraAdapter
    MicrophoneAdapter
    RobotStateAdapter

  /AI
    FoundryClient
    ContextAssembler
    PromptProfileManager
    SafetyClient
    ResponseInterpreter

  /Visualization
    SpatialHUD
    AnnotationRenderer
    AlertRenderer
    DigitalTwinRenderer
    TimelineReplayView

  /Workflows
    TaskGuideFlow
    InspectionFlow
    TrainingFlow
    RemoteAssistFlow

  /Safety
    ActionGuard
    ApprovalUI
    EmergencyStopBridge

 5.2 Microsoft Foundry 側の役割Foundry 側は以下を担当します。
モデル選択
agent orchestration
tool 呼び出し
検索 / 業務データ参照
推論の trace
オフライン / オンライン評価
監視
安全制御ポリシー

 Foundry エージェント分割案1. Perception Agent
   - Unityから来た観測情報を整理
   - 状況ラベル化
   - 異常候補抽出

2. Retrieval Agent
   - Azure AI Search から SOP / 過去事例 / 図面 / FAQ を検索
   - ベクター検索 + キーワード検索のハイブリッド検索

3. Planning Agent
   - 今取るべき次の行動候補を生成
   - リスク / 優先度 / 必要確認事項を整理

4. Safety Agent
   - 危険操作の抑制
   - human approval 必須判定
   - policy check

5. Action Agent
   - 業務API、ロボットAPI、チケット発行APIなどを tool として実行

 6. Knowledge / Retrieval 基盤Physical AI では、単に「賢く会話する」よりも、現場文脈に grounded した応答が重要です。

そのため、Foundry の agent から Azure AI Search を接続し、以下のデータを検索対象にします。
マニュアル
保守手順書
作業標準書
設備台帳
エラー履歴
過去チケット
CAD / BOM のメタデータ
教材 / 訓練シナリオ

 検索インデックス設計例{
  "asset_id": "EQ-1024",
  "asset_name": "Hydraulic Pump A",
  "document_type": "maintenance_manual",
  "section": "pressure abnormality",
  "text_chunk": "圧力低下時はまずシール摩耗を確認する...",
  "vector": "[embedding]",
  "tags": ["pump", "pressure", "maintenance"],
  "risk_level": "medium",
  "language": "ja",
  "updated_at": "2026-04-01T09:00:00Z"
}

 Retrieval の考え方普段は hybrid search
図や写真が多い場合は将来的に multimodal index 拡張
機械ID・作業ID・位置情報でフィルタ
Unity から送る現在状態をフィルタ条件に使う

 7. 「汎用プラットフォーム」にするための抽象化ポイント個別案件化しないためには、以下を固定化せず、差し替え可能な抽象インターフェースにします。

 7.1 入力抽象化public interface IPhysicalInputSource
{
    string SourceId { get; }
    PhysicalContextSnapshot GetSnapshot();
}

 7.2 AI 呼び出し抽象化public interface IAIOrchestrator
{
    Task<AIActionPlan> EvaluateAsync(PhysicalContextSnapshot context);
}

 7.3 出力抽象化public interface IPhysicalActionTarget
{
    Task<ActionResult> ExecuteAsync(ActionCommand command);
}

 8. 動作モード安全性のため、最初から fully autonomous にしない方が実務向きです。

 Mode A: AdvisoryAI は提案だけ行い、人が判断して操作する。

最も導入しやすく、安全監査もしやすいです。

 Mode B: Human-in-the-loopAI が候補行動を出し、人が承認したものだけ実行する。

現場支援や保守に向いています。

 Mode C: Bounded Autonomy「この条件を満たす時だけ自動実行」を許可する。

例: ログ取得、軽微なパラメータ調整、通知発報。

危険操作や物理移動は原則 approval 必須にします。

 9. Safety / Governance 設計Physical AI は、普通のチャットボットより安全設計が重要です。

そのため、以下の 3 段階を推奨します。

 9.1 生成前・入力時ユーザー指示の危険性判定
作業フェーズに合わない命令の拒否
無関係な命令の抑制

 9.2 生成後・提案時提案内容の危険度スコア化
手順抜け / 根拠不足 / 曖昧命令のチェック
high-risk は human approval 必須

 9.3 実行前装置状態との整合性確認
許可された API / command のみ実行
fail-safe / emergency stop の用意

 10. Trace / Evaluation / Monitoring 設計このプラットフォームの強みは、案件を作ることではなく、案件を回しながら改善できることです。

そのため、すべての推論・検索・tool 実行・承認操作を trace 化します。

 記録すべきもの入力コンテキスト
Unity 上の状況スナップショット
検索クエリ
取得ドキュメントID
モデル応答
提案アクション
承認 / 却下
実行結果
現場 KPI

 評価指標例正答率
指示妥当性
手順逸脱率
危険提案率
人の修正率
タスク完了時間短縮率
教育効果
誤アラート率

 継続改善ループTrace収集
  ↓
失敗ケース抽出
  ↓
評価データセット化
  ↓
Prompt / Agent / Tool設計修正
  ↓
再評価
  ↓
本番反映

 11. Unity 側の推奨技術スタック
 最小構成Unity
OpenXR
Input System
XR Interaction Toolkit
Text / Voice / Networking 基盤
Foundry 接続用 API クライアント

 推奨サブシステム
Interaction: XR Interaction Toolkit

Cross-device XR: OpenXR

State Sync: WebSocket / SignalR / gRPC

Speech: Azure Speech など別サービス連携

Visualization: デジタルツイン / 空間注釈 / 作業フローUI

Logging: trace ID を Unity 側にも保持

 12. API 設計イメージ
 12.1 Unity → Foundry Gateway{
  "session_id": "sess-001",
  "user_id": "operator-a",
  "device_type": "xr_headset",
  "scene_id": "plant-room-3",
  "task_mode": "inspection",
  "context": {
    "asset_id": "EQ-1024",
    "user_utterance": "この異音は危険ですか？",
    "position": { "x": 1.2, "y": 1.6, "z": -0.3 },
    "sensor_state": {
      "temperature": 76.2,
      "pressure": 3.1,
      "battery": 82
    },
    "vision_tags": ["pump", "valve", "warning-light"]
  }
}

 12.2 Foundry Gateway → Unity{
  "trace_id": "trace-789",
  "status": "requires_human_confirmation",
  "summary": "ポンプ周辺の圧力低下と異音が同時に観測されています。",
  "recommended_actions": [
    {
      "action_type": "show_instruction",
      "priority": "high",
      "label": "シール摩耗点検手順を表示"
    },
    {
      "action_type": "create_ticket",
      "priority": "medium",
      "label": "保守チケットを起票"
    }
  ],
  "safety_flags": ["mechanical_risk_possible"],
  "references": [
    "manual:hydraulic_pump_a:sec_4_2",
    "ticket_history:eq_1024:last_maintenance"
  ]
}

 13. プロジェクト適用テンプレートどの案件にも適用しやすくするには、最初から Project Template 化しておくと良いです。

 Template A: XR作業支援HMD前提
空間注釈
音声入力
手順誘導
human approval UI

 Template B: ロボット監視・遠隔支援2D/3D マップ
ロボット状態一覧
行動候補提示
通知・アラート
オペレータ承認

 Template C: 教育訓練シナリオ再生
受講者操作ログ
AI講師コメント
採点
リプレイ評価

 Template D: 設備保守設備3Dモデル
異常箇所マーキング
手順表示
保守履歴検索
チケット起票

 14. 導入ロードマップ例
 Phase 1: Viewer + AI AssistantUnity で現場情報を表示し、Foundry に問い合わせて提案を返す段階。

まだ制御はせず、提案中心にする。

 Phase 2: Retrieval + WorkflowAzure AI Search を接続し、マニュアル・履歴・SOP と連携。

案件ごとの差分は「検索対象データ」と「業務 tool」に閉じ込める。

 Phase 3: Human-in-the-loop Actionチケット発行、点検依頼、ログ保存、軽微コマンド実行まで拡張。

危険動作は approval 必須。

 Phase 4: Bounded Autonomy条件付き自動実行へ拡張。

十分な評価データと安全ポリシーを前提に、一部操作のみ自動化する。

 15. この構成の強み
 1: 案件横断で再利用しやすいUnity 側を「入力・可視化・操作」、Foundry 側を「判断・検索・実行・評価」に役割分担すると、案件ごとの差分を限定できます。

 2: XR でも 2D でも展開できるUnity は XR だけでなく PC / モバイル / タブレットにも展開しやすいため、同じ AI バックエンドを複数 UI に再利用しやすいです。

 3: 評価しながら育てられるFoundry は tracing / evaluation / monitoring の導線を持つため、PoC 止まりではなく、改善サイクルを回しやすいです。

 4: 汎用性tool 呼び出しを組み込むことで、検索、API 実行、業務システム更新、ロボット制御などに接続できます。

 16. 注意点
 1 検索品質が全体品質を左右する現場AIは、モデル性能だけでなく、検索対象の整備、chunk 設計、メタデータ設計、フィルタ設計が重要です。

 2 Unity 側は“派手さ”より運用性現場向けでは、
低遅延
わかりやすい注釈
誤操作しにくい導線
trace_id と結びつくログ

の方が重要です。

 17. 原則の取り決めの例
 概要「Unity を身体・空間・現場のフロントエンド、Microsoft Foundry を知能・判断・評価のバックエンドにした、再利用可能な Physical AI 共通基盤」

 コア原則Unity は現場接点
Foundry は知能中枢
Search は現場知識基盤
Tool は実行手段
Safety / Trace / Evaluation は最初から組み込む

 18. 方針検討案Microsoft Foundry を用いて AI エージェント、モデル、ツール実行、評価、監視を担い、Unity を用いて現実空間・設備・ロボット・作業者とのインタラクションを構築する、Physical AI 向け汎用プラットフォームとする。

本プラットフォームにより、XR作業支援、設備保守、ロボット監視、教育訓練など複数の案件に対し、共通アーキテクチャを再利用できる。Unity 側は OpenXR と XR Interaction Toolkit によってマルチデバイス対応し、Foundry 側は agent / tools / tracing / evaluation / monitoring を通じて、PoC から運用改善まで一貫して支援する。

また、Azure AI Search によるベクター検索・ハイブリッド検索を知識基盤とし、現場文脈に grounded した応答を実現する。安全面では、Content Safety、human approval、bounded autonomy を組み合わせ、現実世界へ作用する AI に必要な統制を確保する。

ヘッドウォータース

株式会社ヘッドウォータースのテックブログです。 AIエージェント、生成AI、Azure、GitHub Copilot、IoT、XR系などData&AIとApp modernizeに関して幅広く投稿します！

Physical AI 向け汎用プラットフォーム構想

Microsoft Foundry + Unity ベース

1. 目的

2. このプラットフォームの考え方

3. 想定ユースケース

3.1 現場作業支援

3.2 ロボット / AMR / ドローン支援

3.3 教育 / 訓練シミュレータ

3.4 設備監視・保守

4. プラットフォーム全体アーキテクチャ

5. レイヤー別の役割

5.1 Unity 側の役割

Unity 共通モジュール案

5.2 Microsoft Foundry 側の役割

Foundry エージェント分割案

6. Knowledge / Retrieval 基盤

検索インデックス設計例

Retrieval の考え方

7. 「汎用プラットフォーム」にするための抽象化ポイント

7.1 入力抽象化

7.2 AI 呼び出し抽象化

7.3 出力抽象化

8. 動作モード

Mode A: Advisory

Mode B: Human-in-the-loop

Mode C: Bounded Autonomy

9. Safety / Governance 設計

9.1 生成前・入力時

9.2 生成後・提案時

9.3 実行前

10. Trace / Evaluation / Monitoring 設計

記録すべきもの

評価指標例

継続改善ループ

11. Unity 側の推奨技術スタック

最小構成

推奨サブシステム

12. API 設計イメージ

12.1 Unity → Foundry Gateway

12.2 Foundry Gateway → Unity

13. プロジェクト適用テンプレート

Template A: XR作業支援

Template B: ロボット監視・遠隔支援

Template C: 教育訓練

Template D: 設備保守

14. 導入ロードマップ例

Phase 1: Viewer + AI Assistant

Phase 2: Retrieval + Workflow

Phase 3: Human-in-the-loop Action

Phase 4: Bounded Autonomy

15. この構成の強み

1: 案件横断で再利用しやすい

2: XR でも 2D でも展開できる

3: 評価しながら育てられる

4: 汎用性

16. 注意点

1 検索品質が全体品質を左右する

2 Unity 側は“派手さ”より運用性

17. 原則の取り決めの例

概要

コア原則

18. 方針検討案

Discussion