MLOpsと運用監視 on Physical AI Hub

Physical AIの再現可能な実験基盤：モデル・データ・機体・環境の来歴管理

Sun, 08 Nov 2026 14:48:33 +0900

Physical AIでは、同じモデルを使っても同じ結果にならないことがあります。差分を追える実験単位の設計が、再現性の前提になります。

結論

Physical AIの実験結果を再現可能にするには、モデルのバージョンだけを保存してはいけません。実験1回を単位とする Run Manifest を作り、モデル、データ、コード、機体構成、実行環境、実行時の動的状態、ログや評価結果を一つの来歴グラフとして結び付けます。各要素には不変IDまたは内容ハッシュを付け、どの入力が、どの活動によって、どの成果物を生成したかを追跡できるようにします。

この設計により、同じソフトウェア環境での再実行、同じ機体での物理的な再実験、異なる機体や環境での統計的再現を区別して検証できます。再現性を「同じモデルをもう一度動かせること」と狭く定義しないことが出発点です。

なぜモデルの版管理だけでは足りないのか

ロボットの挙動は、モデルの重みだけで決まりません。学習に使ったデータと前処理、制御コードや設定、センサー校正、ファームウェア、GPUドライバ、シミュレータのワールド、電源や温度といった状態も結果に影響し得ます。

機械学習システムの技術的負債に関する研究は、未宣言のデータ依存関係、設定の不整合、外部環境の変化、フィードバックループなどが、モデル単体からは見えない再現性・保守性のリスクになると指摘しています。Physical AIでは、これらに機体固有の差や時間変化が加わります。

したがって、保存すべき対象は「完成したモデル」ではなく、「そのモデルが、どの条件で、どの機体上で、どの結果を出したか」という実験全体です。

来歴管理の基本用語

来歴を表す汎用モデルとして、W3C PROV-DMがあります。PROV-DMは、次の三つを基本要素とし、生成、使用、派生、帰属などの関係で情報の流れを表現します。

Entity：データセット、モデル、ログ、動画、設定ファイルなどの成果物
Activity：学習、前処理、制御実行、評価、シミュレーションなどの活動
Agent：人、システム、サービス、実験担当組織などの主体

Datasheets for Datasetsは、データセットの動機、構成、収集方法、前処理、用途、配布、保守を記録する方式です。Model Cardsは、モデルの用途、評価条件、性能、制約、想定外利用などをモデル単位で報告します。これらは記録項目を整理するのに役立ちますが、実験全体の改変検知や自動的な関連付けまで保証するものではありません。

Run Manifestに何を記録するか

Run Manifestは、実験IDと実行時刻だけを持つ台帳ではありません。各要素のIDを参照し、入力から出力までを再構成できるマニフェストです。最低限、次の領域を分けて管理します。

領域	記録対象の例	役割
モデル	モデルID、チェックポイント、Model Card	使用した推論器を特定する
データ	rawデータ、派生データ、分割、前処理、Datasheet	学習・評価入力を再構成する
コードと設定	コミット、学習コード、制御パラメータ、設定ファイル	処理手順と条件を固定する
機体	機体識別子、部品構成、ファームウェア、センサー・アクチュエータ設定	どの機体で実行したかを示す
校正と保守	校正状態、校正値、保守履歴	機体の状態差を確認する
実行環境	OS、依存ライブラリ、コンテナ、GPU、ドライバ、ミドルウェア	ソフトウェア環境を再構成する
シミュレーション条件	シミュレータ、ワールド、マップ、乱数シード	仮想環境と試行条件を固定する
動的状態	電源、温度、負荷、時刻同期、実験時イベント	実行時の状態を記録する
成果物	ログ、軌跡、動画、メトリクス、評価レポート	結果と根拠を保存する

データはraw、派生データ、前処理済みデータを同じ名前で上書きせず、それぞれ独立したIDを付与します。学習済みチェックポイントや評価成果物も同様です。変更されるたびに新しいIDを作り、Run Manifestから参照します。

Physical AIのインターフェース互換性管理：センサーから制御まで変更に強い設計を作る

Sat, 07 Nov 2026 14:46:34 +0900

ロボットの長期運用では、型が一致しているだけで安全に接続できるとは限りません。

先に結論

ロボットを長期間保守するには、インターフェースをデータ型だけでなく、データの意味、単位、座標系、時刻、品質、通信条件、モデル入出力、変更手順まで含む契約として管理します。センサー、認識、計画、制御の各境界で契約を分け、互換性を層別に判定することが基本です。

実装では、バージョン付きスキーマ、旧版と新版の並行運用、変換アダプター、契約テスト、実データのリプレイを組み合わせます。コンパイルが成功しても、単位や座標系の変更、QoSの不一致、モデル前処理の差、制御系の遅延増加までは検出できません。

なぜ互換性管理が難しいのか

Physical AIの処理系は、センサー、通信ミドルウェア、推論モデル、計画器、制御器、アクチュエーターが連鎖しています。一つの変更が複数チームと実行環境に波及するため、「フィールドが同じ型か」だけでは判断できません。

数値型が同じでも、単位がメートルからミリメートルに変われば値の意味は変わります。座標フレームが変われば、受信側は同じ数値を別の位置として解釈します。計測時刻と受信時刻の混同、欠測値と有効性フラグの扱いの違いも、型互換でありながら機能を壊す要因です。

管理すべき契約

ROS 2にはmsg、srv、actionがあり、定義から複数言語向けの型と関連コードが生成されます。ただし通信の可否は型だけでなくQoSにも依存します。reliability、durability、history、depth、deadline、lifespanなどの設定がPublisherとSubscriberの間で互換しなければ、通信が成立しない場合があります。

DDS-XTypesは、型の拡張性、メンバーの識別、型の割り当て可能性などを扱います。しかし、実際の利用可能範囲は、ROS 2の型サポート、RMW実装、DDSミドルウェア、設定に依存します。仕様上可能な拡張を、そのまま対象環境へ適用できるとは限りません。

データ契約には、少なくとも次を記録します。

フィールド名、型、必須性、既定値
単位、値の範囲、精度
座標系、フレーム名、軸の向き、回転表現
計測時刻、生成時刻、受信時刻など時刻の意味
共分散、有効性、欠測、品質の表現
QoS、許容遅延、deadlineなどの通信条件
モデルの入力・出力テンソルの型、形状、前処理、後処理
変更理由、サポート期間、廃止予定日

単位や座標の規約にはREP-103 、モバイルロボットのフレーム関係にはREP-105 を参照できます。

推論モデルもインターフェースである

モデルファイルのバージョンだけでは不十分です。ONNXでは、モデル形式のIRバージョン、演算子セットのバージョン、演算子仕様の変更を区別しています。入力テンソルの形状・型に加え、前処理、量子化、キャリブレーション、後処理も契約として記録します。

テンソル形状や演算子セットが互換でも、前処理や学習データの変更による認識精度、さらに制御性能の維持までは仕様書から保証できません。モデル形式の互換性と、モデルを利用した機能の性能維持は別に検証します。

flowchart LR
  S["センサー"] --> SC["センサー契約\n意味・単位\n座標系・時刻\n品質・バージョン"]
  SC --> M["ROS 2 msg / srv / action\n型・必須性・既定値"]
  M --> QC["通信契約\nQoS・転送条件\n遅延・deadline・lifespan"]
  QC --> I["認識モデル\n入力・出力テンソル\n形状・型・前処理・後処理"]
  I --> PC["計画・制御契約\nコマンド・制約\n許容遅延・欠測・ジッター"]
  PC --> A["アクチュエーター"]
  A --> F["フィードバック\n計測値・時刻・品質"]
  F -. "契約テスト・リプレイ・影響追跡" .-> SC
  B1["各境界で管理する項目\nスキーマ\n座標系\n時刻\n品質\nバージョン"] -. "境界横断の契約" .-> M
  B1 -. "境界横断の契約" .-> I
  B1 -. "境界横断の契約" .-> PC

センサーからアクチュエーターまで、データの意味、通信条件、モデル入出力、制御条件を連続したインターフェース契約として管理する流れを示します。

センサーの意味・単位からROS 2の型、QoSと転送、モデル入出力、計画・制御コマンド、アクチュエーターのフィードバックまでを連続した契約として捉えます。各境界にスキーマ、座標系、時刻、品質、バージョンを置くと、変更箇所と影響範囲を追跡しやすくなります。

ロボットのオンラインシステム同定：実機の変化を制御モデルへ反映する設計

Sun, 18 Oct 2026 13:15:09 +0900

実機の変化を追従する仕組みほど、更新しない経路の設計が安全性を左右します。

結論

ロボットのオンラインシステム同定は、推定モデルを制御器へ直接書き込む機能ではなく、監視・検証・更新を担う監督層として組み込むべきです。まずシャドーモードで入力・出力、残差、推定共分散、物理的なパラメータ範囲を確認し、条件を満たした場合だけ、非安全系の限定されたパラメータを段階的に反映します。

安全停止、速度・トルク上限、保護領域、フォールバック制御は推定器から分離します。更新に失敗した場合は、直前の有効モデルまたは保守的な安全モデルへ戻せる構成にします。オンライン同定の採用判断では、追従性だけでなく、推定の確からしさ、安定性の仮定、変更管理まで確認する必要があります。

なぜオンライン同定が必要か

ロボットの動特性は導入時のモデルから変化します。積載物、温度、摩擦、減速機の状態などが変われば、同じ入力に対する速度やトルクの応答も変わり得ます。固定モデルとの不一致が大きくなると、追従性能や外乱・接触検出の信頼性に影響します。

一方、観測された変化が摩耗によるものとは限りません。接触、外乱、負荷変化、センサーずれ、モデル誤差も似た残差を生みます。したがって、同定器は原因を自動的に断定する装置ではなく、変化の兆候と推定の不確かさを継続的に評価する仕組みとして扱います。

前提となる用語と仕組み

システム同定とは、入力と出力のデータから対象の動特性を表すモデルやパラメータを推定することです。オンライン同定では、データを逐次処理して推定値を更新します。再帰的最小二乗法や予測誤差法は、その代表的な考え方です。

忘却係数を使うと、古いデータの影響を相対的に小さくし、時間変化する動特性への追従を狙えます。ただし、忘却を強くすると変化への追従性が高まる反面、ノイズへの感度や推定バイアスが増える可能性があります。十分な励起、信号品質、推定不確かさの監視が欠かせません。

残差は、測定トルクとモデルから予測したトルクとの差のように、実測値とモデル出力の差を示します。外力や衝突の検出に利用できますが、残差だけで劣化、負荷変化、接触を一意に識別できるわけではありません。励起が不足した運転では、異なる原因が同じ残差を生む可能性があります。

推奨アーキテクチャ

高速の制御ループと、低速の推定・保全ループを分離します。高速ループは既知の安定モデルと安全制約で動作させ、低速ループは温度、負荷、摩擦、残差、推定パラメータを蓄積します。候補モデルは妥当性検証を通過した場合だけ、非安全系の制御パラメータへ反映します。

検証項目は、少なくとも次の通りです。

推定に必要な励起が確保されているか
残差が想定範囲に収まっているか
推定共分散または信頼区間が過大でないか
パラメータが物理的な範囲にあるか
一回の更新幅と更新頻度が制限内か
独立した安全監視が介入していないか

flowchart LR
  subgraph DATA["観測・入力データ"]
    S["センサー値"]
    U["制御入力"]
  end

  subgraph EST["低速の推定・検証ループ"]
    P["データ前処理"]
    I["オンライン推定器"]
    V["妥当性検証\n励起・残差・共分散・物理範囲"]
    C["更新候補モデル"]
    G["更新ゲート"]
  end

  subgraph CTRL["制御系"]
    M["既知の安定モデル"]
    K["制御器"]
    R["非安全系のモデル補正"]
  end

  subgraph SAFE["独立した安全系"]
    L["安全監視"]
    T["速度・トルク上限"]
    E["非常停止"]
    F["フォールバック制御\n直前の有効モデルまたは安全モデル"]
  end

  S --> P
  U --> P
  P --> I
  I --> V
  V --> C
  C --> G
  G -->|"検証済みの場合のみ"| R
  M --> K
  R -.->|"非安全系に限定"| K
  K -->|"制御出力"| T
  T -->|"許可された出力"| ROBOT["ロボット"]
  L --> T
  L --> E
  L --> F
  G -.->|"失敗時は反映しない"| F
  F -.-> K

オンライン推定の結果を直接制御器へ書き込まず、妥当性検証と更新ゲートを経て非安全系に限定して反映する。安全監視とフォールバック制御は推定器から独立させる。

モデル更新は、BASELINE_MODEL → SHADOW_ESTIMATION → VALIDATING → CANDIDATE_MODEL → ACTIVE_MODEL のような状態で管理できます。励起不足、残差異常、共分散の過大化、物理範囲からの逸脱、安全監視の介入があれば候補モデルを有効化せず、ベースラインまたは安全モデルへ戻します。ROS 2のライフサイクル状態は、Inactive状態で更新を準備し、遷移時に有効化する実装パターンの参考になります。ただし、それだけで機能安全が保証されるわけではありません。

ロボットのデジタルツイン実装：実機状態とシミュレーションを同期する設計原則

Sat, 17 Oct 2026 13:08:07 +0900

デジタルツインの同期を「高頻度にすればよい」と考えると、ログの再現性や安全境界を見落としやすい点が気になります。

結論：同期周期は一つに統一しない

ロボットのデジタルツインでは、すべてのデータを同じ周期で同期するのではなく、データクラスごとに同期粒度、更新トリガー、許容遅延、欠損時の動作を定義するのが基本です。

関節位置・速度・トルク、ベース姿勢・速度、インターロックなど、制御や安全に直結する状態は、実機の制御・計測周期または状態変化イベントに近い粒度で扱います。環境・シーン、ロボット形状、質量や摩擦などのモデルパラメータ、劣化・保全情報は、状態変更、再キャリブレーション、保全イベント、モデル再同定などを契機に更新します。運用ログは最新値への上書きではなく、後から時系列を再現できる記録として保存します。

つまり、問うべきなのは「何Hzで同期するか」だけではありません。何の時刻を表すデータか、どの値を正当な実機状態とみなすか、遅延や欠損が起きたときどう扱うかを、データクラス別の同期契約として明文化することが重要です。

なぜ同期粒度が重要か

ISO 23247は、製造要素、デジタルツイン、サービスや利用者の関係を整理する参照枠組みを示しています。一方で、すべてのロボットやデータに共通する同期周期を規定しているわけではありません。ロボットの制御周期、通信構成、シミュレータ、利用目的によって適切な粒度は変わります。

また、文献によってデジタルモデル、デジタルシャドウ、デジタルツインの区分も異なります。一般には、実体からデジタル側への一方向のデータ連携と、デジタル側から実体への自動反映を含む双方向連携を区別します。監視のための読み取りと、実機へ影響を与える書き戻しを同じ経路で扱うと、権限や安全性の境界が曖昧になります。

四つのデータクラスに分ける

制御・安全状態

関節状態、ベース状態、インターロックなどは、シミュレーションの状態推定や安全判断に直接影響します。値には取得時刻とシーケンス番号などの順序情報を付け、受信時刻だけで実機状態の時刻を表さないようにします。

OPC UAのデータモデルにあるSourceTimestampとServerTimestampのように、値が生成された時刻とサーバーが受け付けた時刻を分ければ、通信遅延や到着順を分析できます。

環境・シーン情報

周囲の物体、作業空間、配置、経路などは、制御状態と同じ周期で送る必要があるとは限りません。配置変更やシーン再構成をイベントとして同期し、シミュレーション側では、どの時点の環境を表す情報かを保持します。

モデル・保全情報

ロボットの形状、質量、摩擦などのパラメータ、再キャリブレーション結果、劣化状態、保全履歴は、モデル再同定や保全イベントを更新トリガーにします。高頻度に送るより、変更理由、適用範囲、バージョンを管理する方が、検証と保全に向いています。

運用ログ

運用ログには、実機側の取得時刻、受信時刻、クロックの種類、シーケンス番号、通信状態、モデル・設定バージョンを残します。シミュレーション入力用のデータと、改変しない原記録を分離すれば、再生検証と監査に利用できます。

flowchart LR
  subgraph Physical["実機"]
    Sensor["センサー・計測"]
    Controller["制御器"]
    RobotState["関節・姿勢・トルク・安全状態"]
    Scene["環境・シーン情報"]
    Model["モデル・保全情報"]
    Events["イベント・運用ログ"]
    Sensor --> RobotState
    Controller --> RobotState
    Scene --> Events
    Model --> Events
    RobotState --> Events
  end

  subgraph Ingest["収集・記録"]
    Collector["データ収集"]
    Timestamp["時刻・順序付与\nSourceTimestamp / ServerTimestamp / シーケンス番号"]
    RawLog["不変の原記録\n取得時刻・受信時刻・通信状態・版情報"]
    Collector --> Timestamp
    Timestamp --> RawLog
  end

  subgraph Gate["同期契約・判定"]
    Contract["データクラス別の同期契約\n更新トリガー・鮮度上限・欠損時動作・権威性"]
    QoS["QoS判定\nReliability・Deadline・Durability・History・Liveliness"]
    Freshness["鮮度・順序・版の検査"]
    Contract --> QoS --> Freshness
  end

  subgraph Twin["シミュレーション"]
    SimInput["シミュレーション入力"]
    SimTime["シミュレーション時刻"]
    Sim["デジタルツイン"]
    SimInput --> SimTime --> Sim
  end

  RobotState --> Collector
  Scene --> Collector
  Model --> Collector
  Events --> Collector
  Timestamp --> Contract
  Timestamp --> RawLog
  Freshness --> SimInput
  RawLog --> Replay["再生・監査・再現検証"]
  Sim --> CommandGate["コマンドゲート\n認証・認可・妥当性検査・範囲制限・監査"]
  CommandGate -. "双方向反映が必要な場合のみ" .-> Controller

データクラスごとに時刻、順序、鮮度、QoS、権威性を検査し、シミュレーション入力と改変しない原記録を分離する同期構成。

時刻と実行方式を分ける

シミュレーション時刻は壁時計時刻と同一ではありません。ROS 2ではシステム時刻、安定した経過時間を扱う時刻、ROS時刻を区別でき、シミュレーション時には/clockでROS時刻を提供できます。ROS時刻は一時停止、速度変更、時刻ジャンプの影響を受けるため、受信時刻や単調増加する経過時間と混同しない設計が必要です。

ロボットソフトウェアの安全なOTA設計：互換性・段階展開・ロールバックの実践

Wed, 07 Oct 2026 14:41:10 +0900

ロボットの更新では、配布できたことと安全に復旧できることを分けて考える必要があります。

結論

ロボットのOTAを安全にするには、イメージの署名検証だけでは不十分です。機体互換性をマニフェストで定義し、サーバーと機体の双方で適用可否を確認したうえで、少数のカナリアから段階展開します。さらに、起動後のセンサー、アクチュエータ、通信、バッテリー、制御ループなどをヘルスゲートとして監視し、異常時には許可された既知の正常版へ戻せるようにします。

復旧方式としては、対応するブートローダーとストレージ構成がある場合、A/Bまたはデュアルバンクが有力です。ただし、運用上のロールバックと、脆弱な旧版へのダウングレードを防ぐアンチロールバックは別の制御として設計しなければなりません。

なぜ機体互換性が難しいのか

同じ製品系列のロボットでも、ハードウェアリビジョン、接続されたセンサーやアクチュエータ、MCUファームウェア、OS、ブートローダーが異なることがあります。アプリケーションが起動しても、通信プロトコルやファームウェアABIが合わなければ、制御系全体を正常に動かせるとは限りません。

また、アプリケーションだけを旧版へ戻しても、設定・データスキーマの移行、ブートローダー更新、他ECUとのプロトコル変更が残れば復旧は不完全です。OTAの単位は単一バイナリではなく、依存関係と適用順序を含むリリースとして定義する必要があります。

互換性契約をマニフェスト化する

更新マニフェストと機体インベントリを比較し、適用対象を限定します。契約に含める項目は、少なくとも次のように整理できます。

製品系列、機体モデル、機体識別子
ハードウェアリビジョン、センサー・アクチュエータ構成
ブートローダー、OS、カーネル、ファームウェアABI
接続ECUと通信プロトコル
更新対象コンポーネント、依存関係、適用順序
設定・データスキーマ
シーケンス番号、最低限必要なセキュリティバージョン

RFC 9124は、ベンダーID、クラスID、コンポーネント、依存関係、シーケンス番号、条件、検証アルゴリズムなどをマニフェストで表す情報モデルを定義しています。Uptaneは、一般的な更新情報と、個別の車両やECUに対する適用指示を分離する構成を示しています。

サーバー側では属性やインベントリによって対象を絞り込み、機体側でも受信後に再検証します。サーバーの選定だけに頼ると、古いインベントリや誤登録による誤配布を止められません。

flowchart LR
  A["更新イメージとマニフェストを生成"] --> B["署名・ハッシュ・メタデータを検証"]
  B --> C["サーバー側で対象機体を選定"]
  C --> D["機体側でインベントリと互換性契約を再検証"]
  D -->|"不一致"| X["インストール拒否"]
  D -->|"一致"| E["更新前の安全条件を確認"]
  E --> F["カナリア機へ展開"]
  F --> G["起動後ヘルスゲート"]
  G --> H{"異常があるか"}
  H -->|"いいえ"| I["次のコホートへ拡大"]
  I --> J{"全コホート完了か"}
  J -->|"いいえ"| F
  J -->|"はい"| K["展開完了"]
  H -->|"はい"| L["新規展開を停止"]
  L --> M["許可された既知の正常版へロールバック"]
  M --> N["復旧状態を確認"]
  N -->|"復旧"| O["再開または中止を判断"]
  N -->|"未復旧"| P["リカバリー手順へ移行"]

署名検証だけでなく、互換性契約、更新前後の安全条件、段階展開、ヘルスゲート、ロールバックを組み合わせるOTAの全体フロー。

署名だけに依存しない検証

安全なOTAは、未承認変更を防止する、変更を検出する、信頼できる状態へ復旧する、という多層構成で考えます。NIST SP 800-193は、プラットフォームファームウェアの保護をprevent、detect、recoverの三機能で整理しています。これはロボットの物理安全全体を直接規定するものではありませんが、更新設計の基本的な分解として利用できます。

学習ベースのロボット機能を説明可能にする安全ケースの作り方

Thu, 01 Oct 2026 14:38:11 +0900

学習モデルの評価結果を、現場で成立する安全の説明へどう接続するかが気になるテーマです。

結論

学習ベースのロボット機能の安全ケースは、AIモデル単体の精度を証明する文書ではありません。最上位に「定義した運用範囲と制約の中で、対象機能が許容可能な安全性を満たす」という主張を置き、危険源、安全目標、安全要求、実装上の防護、検証結果、残留リスク、運用監視へ分解します。

各主張は、要求仕様、データセット、モデル、ソフトウェア構成、テスト条件、判定結果、運用記録へ追跡できるようにします。学習モデルを安全機能上の唯一の防護層とせず、異常時に停止、減速、退避などの安全側状態へ移行できる仕組みを含めることが基本です。

なぜモデル単体の評価では不十分か

ロボットの危険は、認識モデルの出力だけで決まりません。対象物、人との距離、作業空間、速度、力、照明、センサー、通信、ソフトウェア構成などが組み合わさって、実際のリスクになります。平均精度やテストデータ上の結果だけでは、どの環境で、どの失敗が起こり得て、失敗時に何が動作を制限するのかを説明できません。

ISO 12100:2010は、意図する使用と合理的に予見可能な誤使用を含む機械の限界を定め、危険源の同定、リスクの見積もり・評価、リスク低減を反復する一般原則を示しています。学習機能を含む場合も、まずこの分析を出発点にし、AI固有の不確実性、データやモデルの変更、導入後の監視をライフサイクルへ接続します。

安全ケースを構成する枠組み

安全ケースとは、安全性に関する主張と、それを支える論拠・証拠を構造化したものです。GSN（Goal Structuring Notation）では、ゴール、戦略、コンテキスト、前提、証拠などを用いて、主張がどの条件で成立するかを表します。ただし、GSN自体はモデル精度や残留リスクの合格値を定めません。

参照する枠組みの役割は分けて扱います。ISO 12100は機械の危険源分析とリスク低減、IEC 61508は安全関連の電気・電子・プログラマブル電子システムの安全ライフサイクルや検証、ISO 10218-1:2011は産業用ロボットの安全要求を扱います。NIST AI RMF 1.0はGovern、Map、Measure、Manageの4機能でAIリスク管理を整理し、ISO/IEC 23894:2023はAIのリスク特定、分析、評価、処置、監視のガイダンスを示します。

これらは同じ適用範囲の規格ではありません。AIリスク管理の文書は一律の合格閾値や認証を定めず、ISO 10218-1もサービスロボットや移動ロボット、特定の学習機能へそのまま適用できるとは限りません。対象機械、用途、法域、国内採用版との対応を確認する必要があります。

最上位主張から証拠まで分解する

実務では、次の順に整理するとレビューしやすくなります。

運用範囲と前提：許容される環境、対象物、人との距離、速度・力の上限、センサー状態、通信条件、モデルの適用範囲を定める。
危険源と安全目標：誤認識、制御の逸脱、センサー異常、通信断、適用範囲外の入力などを危険源として整理し、避けるべき危害や安全目標へ結び付ける。
安全要求：機能要求、性能要求、環境制約、フェイルセーフ要求、監視要求、変更管理要求を記述する。
実装上の防護：学習モデル、制限器、監視器、安全関連制御系、停止・減速・退避などが、どの要求に対応するかを明確にする。
検証と妥当性確認：要求ごとに方法、条件、合格基準、結果を記録する。解析、単体試験、シミュレーション、シナリオ試験、実機試験、故障注入などを要求の性質に応じて使い分ける。
残留リスクと運用監視：残った前提、監視指標、インシデント対応、再評価条件、変更時の停止条件を明示する。

これは各規格が定める一律の文書一覧ではなく、対象システムに合わせた実務上の構成方法です。

flowchart TD
  G["最上位主張：定義した運用範囲と制約の中で、機能が許容可能な安全性を満たす"]
  C["運用範囲・前提：環境、対象物、人との距離、速度・力、照明、センサー、通信、モデル適用範囲"]
  H["危険源と安全目標：誤認識、制御逸脱、センサー異常、通信断、適用範囲外入力"]
  R["安全要求：機能、性能、環境制約、フェイルセーフ、監視、変更管理"]
  P["実装上の防護：学習モデル、制限器、監視器、安全関連制御系、停止・減速・退避"]
  V["検証・妥当性確認：単体試験、シミュレーション、シナリオ試験、実機試験、故障注入、解析"]
  L["残留リスクと運用監視：前提、監視指標、インシデント対応、再評価条件、変更時の停止条件"]
  E["証拠：試験結果、解析記録、要求との対応、構成管理情報"]
  G --> C
  G --> H
  H --> R
  C --> R
  R --> P
  R --> V
  P --> V
  V --> E
  V --> L
  L --> E

安全ケースを、成立条件と防護、検証、残留リスク、証拠まで追跡可能な形に分解した構造です。GSN風の概念図であり、特定の合格基準を定めるものではありません。

トレーサビリティを証拠の中心に置く

検証結果を安全ケースの証拠として利用するには、その結果を生んだ構成を固定できなければなりません。要求仕様、データセット、ラベル、モデル、ソフトウェア、推論ハードウェア、テスト条件、判定結果をライフサイクル成果物として版管理し、相互に追跡可能にします。ISO/IEC 5338:2023は、AIシステムの概念化、開発、検証・妥当性確認、導入、運用、保守、廃止を含むライフサイクルプロセスを扱います。

ロボットAIの検証パイプライン：シミュレーションからHIL・実機試験へ移す方法

Sat, 05 Sep 2026 09:21:36 +0900

実機を使わずに検証できる範囲を広げるほど、実機でしか分からない差分を見落とさない設計が重要になります。

先に結論

ロボットAIの検証は、シミュレーション、Hardware-in-the-Loop（HIL）、管理された実機試験の順に段階化するのが基本です。シミュレーションで大量のシナリオを反復し、HILで実時間性やI/O、ドライバ、計算負荷を確認し、その後に実機でセンサー較正、接触、電源、通信、安全挙動を検証します。

ただし、これは一方向に進む固定工程ではありません。変更がハードウェアや安全機能に関係する場合はHILや実機試験を前倒しし、失敗時にはシミュレーションやソフトウェア統合テストへ戻るフィードバックループを設けます。判断の軸は、変更のリスク、実機との差分、再現性、安全要求です。

なぜ三つの段階を分けるのか

実機だけで全テストを行うと、設備を占有し、再現性のある大量試験や並列実行が難しくなります。一方、シミュレーションだけでは、実機の遅延やジッタ、センサーの較正状態、機械的な接触・摩擦、電源状態、通信障害を十分に再現できません。

そこで、検証対象を分解します。ソフトウェアの論理や制御方策はシミュレーションで広く確認し、実際の制御ハードウェアとリアルタイムの入出力はHILで確認します。最後に、シミュレーションモデルで表現しにくい物理条件と安全挙動を、管理された実機環境で確認します。

用語と役割

**SIL（Software-in-the-Loop）**は、制御ソフトウェアや複数ノードの統合を、シミュレーション環境で検証する段階です。ROS 2のlaunch_testingのように、複数ノードを起動してプロセス間の相互作用を検証する方法は、CIで実行するソフトウェア統合テストに利用できます。

シミュレーションでは、物理条件、環境、センサー入力を変化させ、再現可能なシナリオを大量に実行します。視覚・環境パラメータを変えるドメインランダム化や、質量、摩擦、遅延などを変えるダイナミクスランダム化は、シミュレーションと現実の差に対するロバスト性を高める手法です。ただし、これらは実機性能や安全性を保証するものではありません。

HILは、少なくとも制御ソフトウェアまたは対象ハードウェアを実機側で動かし、プラント、センサー、アクチュエータなどの一部をシミュレータで置き換える構成です。実際の制御ハードウェアとリアルタイムシミュレーションを接続するため、実時間性、通信、I/O、ドライバ、計算資源を、実機投入前に検証できます。資料によってHILの範囲は異なり、実フライトコントローラを中心に指す場合と、制御ECU、I/O、リアルタイムのプラントモデルを含む全体を指す場合があります。

推奨する検証フロー

変更を起点に、まず高速な単体テストとSILスモークテストを実行します。ここでは、プルリクエストやコミット単位で、制御ロジック、ノード間連携、代表的な異常処理を確認します。次に、広いシナリオ集合を使ったSIL回帰を、夜間または定期的に実行します。環境やセンサー入力を変えたケースを含めることで、単一の正常系だけでは見つけにくい問題を調べられます。

そのうえで、実時間性やハードウェア依存コード、通信プロトコル、センサー・アクチュエータI/O、故障処理、計算資源に影響する変更をHILへ送ります。HILでは、シミュレータからセンサー入力を与え、実際の制御ハードウェアから出力を取り出し、タイミング、通信、I/O、故障注入への応答を確認します。

HILを通過した変更、またはセンサー較正、接触、安全機能、電源、実環境の通信に関係する変更は、実機ベンチへ進めます。安全に関わる試験では、通常の機能回帰とは別のテストスイートとして管理し、保護機構、中止手順、低速・低エネルギー条件、段階的な運用範囲の拡大を紐付けます。

flowchart LR
  A["コミット・変更"] --> B["単体テスト"]
  B --> C["SILスモーク"]
  C --> D["SIL回帰\n大量シナリオ"]
  D --> E["HIL\n実時間性・通信・I/O・故障処理"]
  E --> F["実機ベンチ\n較正・接触・電源・安全挙動"]
  F --> G["限定環境試験\n段階的な運用範囲"]
  B -. "失敗・修正" .-> H["修正・再テスト"]
  C -. "失敗・修正" .-> H
  D -. "失敗・修正" .-> H
  E -. "失敗・修正" .-> H
  F -. "失敗・修正" .-> H
  H --> A
  A -. "変更リスクに応じて前倒し" .-> E
  A -. "安全・接触・実環境に関係" .-> F

検証はSIL、HIL、実機試験へ段階的に進めるが、失敗時やリスクの高い変更時には前段階へ戻るフィードバックループを設けます。

段階ごとの使い分け

段階	主な検証対象	推奨トリガー	強み	主な制約
SILスモーク	制御ロジック、ノード連携、基本的な異常処理	コミット、プルリクエスト	高速、反復可能、CIに組み込みやすい	実機のI/O、遅延、接触を確認できない
SIL回帰	多様な環境・物理条件・センサー入力	夜間、定期実行、リリース前	大量シナリオを低コストで実行できる	モデル誤差が結果に影響する
HIL	実時間性、通信、ドライバ、I/O、計算負荷、故障処理	ハードウェア依存変更、定期実行、リリース前	実制御ハードウェアを含めて再現性を保てる	設備構築が必要で、SILより実行コストが高い
実機ベンチ	センサー較正、遅延・ジッタ、電源、接触、摩擦	リリース候補、安全・接触・実環境に関わる変更	実際の機械・電気条件を確認できる	実行時間、設備、人的安全管理が必要
限定環境試験	実環境での安全挙動と運用範囲	実機ベンチ合格後、段階的に実施	現場条件での挙動を確認できる	リスク管理と中止手順が不可欠

実機へ進める出口条件

実機試験への移行条件は、単一の性能値で決めるのではなく、検証目的ごとに定義します。少なくとも次の項目を記録します。

ロボット失敗ログの活用設計：再学習と回帰テストへつなぐデータループ

Sat, 15 Aug 2026 09:17:15 +0900

失敗ログを保存するだけで、次のモデルやテストへ自然に生かせるのかが気になるテーマです。

先に結論

ロボットの失敗ログを活用する中核は、件数を増やすことではなく、どの条件で何が起きたかを追跡できる形にし、同じ失敗を再学習用データと回帰テストへ分岐させることです。改変しない生ログを起点に、エピソード、失敗イベント、失敗パターン、データセット、テストケースをIDで結びます。

候補モデルの評価では、固定ホールドアウトや失敗リプレイ、シミュレーション、必要に応じた実機試験をゲートの例として用います。ただし、どこまで試験すればよいか、自動昇格を許すかは、対象タスクと安全要求に応じて決める必要があります。

なぜデータループが必要か

多くの実機システムでは、失敗時にセンサ入力、ロボット状態、制御指令、環境条件、方策やソフトウェアの版が関係します。必要な信号や版情報を欠くと、原因の切り分けや再現が難しくなり得ます。また、同じシーンのログを大量に追加しても、未見条件を評価できるとは限りません。

そのため、失敗ログは単なるデバッグ記録ではなく、検出、確認、パターン化、選別、評価へ渡す入力として設計します。失敗事例を再学習に使う場合も、効果は失敗ラベル、負例の扱い、学習目的によって変わるため、改善を保証するものとして扱ってはいけません。

前提となるデータ層

ROS 2のrosbag2は、トピックデータの記録と再生を行う仕組みです。センサ、状態、指令を時系列で保存し、後から再生する基盤に利用できます。MCAPはスキーマ、チャネル、メッセージ、メタデータ、添付データなどを持つ時系列データ形式です。

一方、RLDSはエピソードとステップの階層でデータを表し、観測、行動、報酬、終了状態などを扱います。rosbag2やMCAPが主に保存・再生を担うのに対し、RLDSは学習・評価向けの論理表現です。両者を同一スキーマとみなさず、正規化処理で変換します。

層	役割	主な情報
生ログ	原記録の保存・再生	rosbag2またはMCAP、時刻、スキーマ
エピソード	学習・評価単位への正規化	episode_id、観測、行動、終了状態
失敗イベント	失敗区間の記録	event_id、時間窓、検出器、重大度、確認者
失敗パターン	類似失敗の集約	pattern_id、再現条件、代表例
データ・テスト	改善サイクルへの反映	dataset version、テストケース、結果

episode_id、event_id、pattern_id、policy_version、software_version、hardware_idで各層を相互参照し、データと処理の版を管理します。DVCのように、データをGitのコードやメタデータと対応付ける仕組みも利用できます。データセットの動機、構成、収集方法、前処理、用途、制約は、Datasheets for Datasetsの考え方に沿って記録すると判断を追跡しやすくなります。

失敗をパターンへ変換する流れ

最初に、停止理由、安全イベント、タイムアウト、タスク判定など、確認可能なルールで失敗候補を抽出します。失敗した瞬間だけでなく、成功・失敗境界の前後を含む時間窓を切り出し、センサ、行動、環境条件、モデルとソフトウェアの版を付与します。次に、人手で失敗の有無と種類を確認します。

確認済みの事例は、特徴量や埋め込みで類似例を集約し、共通する再現条件を調べます。学習中の正解率、信頼度、予測の変動を使い、典型的・曖昧・困難なデータ例を分析するDataset Cartographyの考え方も診断材料になります。ただし、これはロボットの物理的な重大度や安全リスクを直接測るものではありません。

flowchart LR
  A["生ログを変更せずに収集\nrosbag2 / MCAP"] --> B["エピソードへ正規化\n時刻・モデル・ソフトウェア・ハードウェアの版を付与"]
  B --> C["ルールベースで失敗候補を抽出"]
  C --> D["時間窓・環境条件・センサ・行動を付与"]
  D --> E["人手で失敗の有無と種類を確認"]
  E --> F["類似事例をクラスタリング\n失敗パターンへ集約"]
  F --> G["重大度・未見性・不確実性・代表性・テスト状況で優先順位付け"]
  G --> H["版管理された学習データセット"]
  G --> I["回帰テストケース\n元ログ・再現条件・期待動作・閾値"]
  H --> J["候補モデルを学習"]
  J --> K["固定ホールドアウトと失敗リプレイで評価"]
  I --> K
  K --> L["シミュレーションまたは実機の安全評価"]
  L --> M["段階導入"]
  M --> N["導入後の監視"]
  N --> A
  E -. "未確認・追加確認" .-> D

失敗ログをパターンへ集約し、再学習と回帰テストに分岐させて、導入後の新しいログを再び収集する閉ループを示します。

失敗パターンには、元ログへの参照、再現条件、期待する動作、許容閾値、乱数seedまたは環境固定条件を持たせます。「未確認」「確認済み」「再学習投入」「テスト化」「解消」「再発」といった状態を管理すれば、改善サイクルのどこにあるかを追跡できます。

Physical AIの可観測性設計：センサー・推論・制御を横断して失敗を追跡する方法

Wed, 29 Jul 2026 09:10:27 +0900

ロボットの「遅い」「失敗した」という記録を、原因の追跡につながる観測へ変えるには何が必要かを整理します。

先に結論

ロボットの遅延や失敗を再現可能な形で調べるには、単一ノードのログではなく、センサー取得からアクチュエータ応答までを一つの実行単位として記録します。各境界に run_id、trace_id、span_id、親子関係、メッセージのシーケンス番号、複数の時刻、処理状態を付与し、分散トレースとメッセージ記録を組み合わせるのが基本です。

遅延は推論時間だけでなく、センサー取得、通信、キュー待ち、前処理、推論、制御計算、出力送信まで分解します。コード、モデル、設定、キャリブレーション、QoS、ファームウェア、乱数種、クロック設定も同じ調査単位に保存します。これにより、認識誤り、通信遅延、制御逸脱、安全停止の発生箇所と条件を追跡しやすくなります。

なぜ横断的な観測が必要か

Physical AIでは、センサー、ROS 2通信、前処理、推論、計画、制御、ドライバ、アクチュエータが別々の処理として動きます。「入力を受けた」というノードの記録は、センサーの露光時刻を示すとは限りません。同様に、制御コマンドをpublishした時刻と、アクチュエータが実際に受け付けた時刻も異なる可能性があります。

そのため「推論が遅い」という症状だけでは、原因が通信、executorの待ち時間、キュー滞留、前処理、推論、出力送信のどこにあるか分かりません。処理経路を共通の相関情報で結び、区間ごとの時間と状態を比較できるようにします。

前提となる仕組み

OpenTelemetryのトレースは、処理経路を複数の span の集合として表します。spanには開始・終了時刻、属性、イベント、ステータスを付けられます。ログが個別の出来事、メトリクスが集計値を扱うのに対し、トレースは一回の処理経路を表します。

W3C Trace Contextは、trace-id や parent-id などを分散コンポーネント間で伝播する標準形式を定義しています。ただし、ROS 2のDDS通信でこのコンテキストが自動的に伝播するとは確認できません。ROS 2ノード、メッセージ、middleware、またはブリッジ側で接続方法を設計する必要があります。

ROS 2には、LTTngとROS 2固有のtracepointを使い、ノード、通信、コールバック、executorなどを時系列で観測する ros2_tracing があります。アプリケーション固有の前処理、推論、制御には追加の計測点を設けます。rosbag2 はROS 2のトピックメッセージを記録・再生する仕組みで、トレースとは異なり、入力や中間メッセージを再利用するための記録系です。

計測する境界とデータフロー

個別のspanまたはイベントとして、次の境界を計測します。

センサー取得、ドライバ内のcapture
middlewareへのpublishと受信
キューへの投入・取り出し、callbackの開始・終了
前処理、推論、計画またはポリシー出力の開始・終了
制御計算、制御出力の生成
アクチュエータへの送信と応答

各記録には、ノード名、トピック名、入力・出力時刻、成功・失敗・期限超過などの状態も含めます。高頻度センサーのペイロードをトレースへ常時埋め込むのではなく、参照ID、ハッシュ、要約統計を置き、完全なデータは別の記録系で保持する構成が扱いやすくなります。

flowchart LR
  A["センサー取得・ドライバcapture"] --> B["middleware publish"]
  B --> C["middleware受信"]
  C --> D["キュー投入・取り出し"]
  D --> E["callback開始・終了"]
  E --> F["前処理"]
  F --> G["推論"]
  G --> H["計画・ポリシー出力"]
  H --> I["制御計算・出力生成"]
  I --> J["アクチュエータ送信"]
  J --> K["アクチュエータ応答"]
  M["共通の相関情報\nrun_id または episode_id\ntrace_id・span_id・親span\nシーケンス番号・処理状態"] -.-> A
  M -.-> B
  M -.-> C
  M -.-> D
  M -.-> E
  M -.-> F
  M -.-> G
  M -.-> H
  M -.-> I
  M -.-> J
  M -.-> K
  T["時刻の併記\nSteady Time: 経過時間\nROS Time: 再生・シミュレーション\nSystem Time: ホスト間相関"] -.-> A
  T -.-> K

センサーからアクチュエータ応答までの各境界を、run_id、trace_id、span_id、シーケンス番号、処理状態、複数の時刻で相関させる設計を示します。

時刻を用途別に分ける

遅延や経過時間の計測には、単調増加を前提とするSteady Timeを使います。シミュレーションや再生上の時系列にはROS Timeを使いますが、外部クロックやシミュレーション時間を扱える一方、クロック更新や時間のジャンプが起こり得ます。複数ホストの相関や人間向けの記録にはSystem Timeを併記します。

ROS 2 Lifecycle Nodeの実践設計：起動順序・停止処理・異常復旧を状態機械で管理する

Tue, 16 Jun 2026 08:57:52 +0900

実機では、ノードの状態とアクチュエータの物理状態を同じものとして扱わない設計が特に気になります。

先に結論

ROS 2の実機システムでは、Lifecycle Nodeを単なる起動・停止フラグではなく、設定、実行、安全停止、再初期化を分ける状態機械として設計します。基本の起動経路は Unconfigured → Inactive → Active、通常停止は Active → Inactive → Unconfigured、最終終了は Finalized へ進める構成です。遷移中の失敗や例外は ErrorProcessing に分離します。

ただし、Lifecycle Node単体が複数ノードの依存関係やプロセス再起動を管理するわけではありません。実機ではLifecycle Managerなどの外部オーケストレータで順序と監視を管理し、物理的な安全停止はハードウェアやコントローラ側にも実装します。

なぜ状態遷移が必要か

通常のNodeでは、プロセス起動後に処理や通信が始まり、設定未完了のセンサーや、依存先が準備できていない制御器が動き出す可能性があります。Lifecycle Nodeは「設定済みだがまだ処理・出力を有効化していない状態」と「実際に動作する状態」を分離します。これにより、起動順序、段階的なアクティベーション、停止後の再初期化を外部から明示できます。

状態照会と遷移要求には、ChangeState、GetState、GetAvailableStates、GetAvailableTransitions などの標準インターフェースを利用できます。

状態と標準遷移

Lifecycle Nodeの主要状態は次の4つです。

Unconfigured: 設定前、またはクリーンアップ後
Inactive: 設定済みだが、処理や出力は未有効化
Active: 処理と出力が有効
Finalized: 終了処理後で、通常の再利用経路から外れた状態

移行中には Configuring、CleaningUp、Activating、Deactivating、ShuttingDown、ErrorProcessing があります。Configureは Unconfigured から Inactive へ、Activateは Inactive から Active へ進めます。Cleanupは Inactive から Unconfigured へ戻し、Shutdownは主要状態から Finalized へ移します。

遷移コールバックは成功、失敗、エラーの結果を返します。成功なら次の状態へ進み、失敗なら原則として遷移前の主要状態へ戻ります。エラーの場合は ErrorProcessing に進み、エラー処理の結果で再初期化または終了へ分岐します。

flowchart LR
  U["Unconfigured"] -->|"Configure"| C["Configuring"]
  C -->|"成功"| I["Inactive"]
  I -->|"Activate"| AT["Activating"]
  AT -->|"成功"| A["Active"]
  A -->|"Deactivate"| D["Deactivating"]
  D -->|"成功"| I
  I -->|"Cleanup"| CL["CleaningUp"]
  CL -->|"成功"| U
  U -->|"Shutdown"| S["ShuttingDown"]
  I -->|"Shutdown"| S
  A -->|"Shutdown"| S
  S -->|"完了"| F["Finalized"]
  C -.->|"エラー"| E["ErrorProcessing"]
  AT -.->|"エラー"| E
  D -.->|"エラー"| E
  CL -.->|"エラー"| E
  S -.->|"エラー"| E
  E -->|"復旧成功"| U
  E -->|"処理失敗・継続不可"| F
  classDef main fill:#e8f1ff,stroke:#3674c5,color:#111;
  classDef transition fill:#fff4d6,stroke:#c28a00,color:#111;
  classDef error fill:#ffe5e5,stroke:#c33,color:#111;
  class U,I,A,F main;
  class C,AT,D,CL,S transition;
  class E error;

Lifecycle Node単体の起動、段階的な停止、遷移エラー時の復旧経路を示す。通常の遷移失敗では遷移前の主要状態へ戻る場合があるため、ErrorProcessingへの分岐はエラー結果を表す。

コールバックの責務を分ける

コールバック	主な責務	設計上の注意
`on_configure`	設定読み込み、デバイス接続、リソース確保	通常出力はまだ有効化しない
`on_activate`	処理・出力の有効化	設定済みの機能だけを実行状態にする
`on_deactivate`	処理・出力の停止	Activeから安全に停止する
`on_cleanup`	確保済みリソースの解放	再Configureできる境界を作る
`on_shutdown`	終了処理	ノードを終了状態へ移す
`on_error`	異常処理	再利用可能性を判定する

センサーの設定や通信資源の確保は on_configure、データ処理や出力の開始は on_activate に置きます。停止時は on_deactivate で処理と出力を止め、再利用しない場合は on_cleanup または on_shutdown で資源を解放します。役割を混在させないことが、再初期化のしやすさにつながります。

Physical AIのモデル更新を監視する：評価・カナリアリリース・ロールバック設計

Sun, 05 Apr 2026 00:41:46 +0900

ロボットAIの更新では、精度の改善がそのまま安全な運用を意味するのかが気になります。

先に結論

Physical AIのモデル更新は、オフラインの認識精度だけで合否を決めてはいけません。更新前に固定シナリオ、シミュレーション、実機リプレイなどで基準性能と安全限界を記録し、更新後はタスク結果、安全イベント、入力変化、推論・通信の健全性を継続的に比較します。リリースはシャドー実行から低リスクのロボットや作業へ段階的に広げ、異常時には独立した安全系で停止またはフォールバックしたうえで、モデルだけでなく関連する実行環境を含む既知の正常版へ戻します。

なぜモデル更新の監視が難しいのか

Webサービスなら、エラー率やレイテンシーをリクエスト単位で追跡しやすい一方、ロボットの性能は環境、個体、作業シナリオ、センサー状態、通信状態に左右されます。入力分布が変わってもタスク結果が維持される場合があり、反対に入力変化が小さくても制御遅延やキャリブレーションのずれが危険動作につながる場合があります。

NISTのAI RMF 1.0も、AIのリスクと性能はデプロイ前だけでなく運用中も測定・監視し、問題への対応や変更管理を行う考え方を示しています。したがって、更新を「モデルファイルの交換」ではなく、変更を観測し、止め、戻せる運用プロセスとして設計する必要があります。

前提となる用語

データセットシフトは、学習時と運用時でデータの分布が変わる現象です。共変量シフト、事前確率シフト、概念シフトなどに分けられます。ただし、入力や予測の分布変化を検出しただけでは、タスク性能の低下や安全リスクを直接証明できません。

カナリアリリースは、新版を一部の対象に限定して投入し、旧版との差を確認してから展開範囲を拡大する方法です。ロボットでは、単純なリクエスト比率ではなく、ロボット個体、拠点、作業シナリオ、危険度を単位にするほうが安全側です。

シャドー実行は、新版を判断や制御への作用なしに動かし、出力や遅延を観測する段階です。実際の作業へ影響を与えない構成にできるなら、低リスクな初期評価になります。

監視すべき指標は一層では足りない

監視項目は、少なくとも次の層に分けて設計します。

入力層：センサー分布、欠損、異常値、OOD（学習分布外）兆候
モデル層：信頼度、予測分布、アクションの飽和や異常な偏り
タスク層：タスク成功率、完了時間、人手介入率
安全層：衝突、ニアミス、接触力や軌道の制約違反
システム層：推論遅延、通信欠落、QoSのdeadline違反、liveliness

これらは更新前の基準値および既知の正常版と比較します。成功率が維持されていても、介入率や推論遅延が増えていれば、将来の失敗や安全余裕の縮小を示す可能性があります。逆に入力ドリフトだけを理由に直ちにロールバックするのではなく、タスク、安全、システムの観測と組み合わせて判断します。共通の閾値や必要サンプル数は製品ごとに異なるため、固定の標準値として扱ってはいけません。

flowchart LR
  subgraph input["入力層"]
    I1["センサー分布"]
    I2["欠損・異常値"]
    I3["OOD兆候"]
  end
  subgraph model["モデル層"]
    M1["信頼度"]
    M2["予測分布"]
    M3["アクションの飽和・偏り"]
  end
  subgraph task["タスク層"]
    T1["タスク成功率"]
    T2["完了時間"]
    T3["人手介入率"]
  end
  subgraph safety["安全層"]
    S1["衝突"]
    S2["ニアミス"]
    S3["接触力・軌道の制約違反"]
  end
  subgraph system["システム層"]
    Y1["推論遅延"]
    Y2["通信欠落・Deadline違反"]
    Y3["Liveliness"]
  end
  I1 --> G["旧版・基準値との比較"]
  I2 --> G
  I3 --> G
  M1 --> G
  M2 --> G
  M3 --> G
  T1 --> G
  T2 --> G
  T3 --> G
  S1 --> G
  S2 --> G
  S3 --> G
  Y1 --> G
  Y2 --> G
  Y3 --> G
  G --> H["リリース・安全ゲート"]
  H --> D["継続監視・展開判断"]

入力分布やモデル出力だけでなく、タスク結果、安全イベント、システム健全性を旧版および更新前の基準値と比較する。

更新から全体展開までの流れ

まず、モデル、前処理・後処理、設定、制御ソフト、依存ライブラリ、キャリブレーション、実行環境を識別できる形で記録します。その組み合わせで固定シナリオと実機・シミュレーションの評価を行い、品質ゲートと安全ゲートを分けて判定します。スループットやコストの改善があっても、衝突、危険動作、安全制約違反を防ぐゲートを通過しなければ展開しません。

ロボット学習データの収集設計：実機デモの記録形式と品質検証

Sun, 08 Mar 2026 08:24:51 +0900

実機デモは動画として残すだけで十分なのか、という疑問から整理しました。

先に結論

ロボット学習用の実機デモは、動画だけでなく、episodeの中に時系列のstepを持つデータとして収集するのが基本です。各stepには、観測、行動、時刻、終了状態を紐づけ、episodeにはタスク、ロボット、センサー、キャリブレーションなどのメタデータを付与します。

品質検証は、保存後に一度だけ行うのでは不十分です。まずスキーマ、配列、欠損、時刻系列を自動検査し、次に行動値や関節状態の物理的妥当性、タスク成功ラベルを確認します。最後に、episode単位でデータを分割し、同じセッションや環境が学習・検証・テストにまたがるリークを防ぎます。

なぜ収集形式が重要なのか

模倣学習やVLAでは、画像だけでなく、ロボットの状態と操作指令の対応を学習します。映像、関節状態、エンドエフェクタの状態、操作コマンドの時刻関係が崩れると、モデルは誤った因果関係を学習する可能性があります。また、成功デモだけを残すと、停止、失敗、やり直しといった実環境で起きる状態を扱いにくくなります。

そのため、収集時点では失敗や中断も含めて保存し、後から終了理由やタスク結果を明示する設計が扱いやすくなります。ただし、成功・失敗ラベルの自動判定と人手判定のどちらが常に優れるかについて、全タスクに共通する基準はありません。タスクごとに判定方法を定義する必要があります。

基本用語とデータ単位

episodeは、タスクの開始から終了までの一つの試行です。stepは、episode内のある時刻における観測と行動の組です。RLDSはepisodeとstepの階層を採用し、stepにobservation、action、reward、discount、is_first、is_last、is_terminalなどを持たせます。

一方、robomimicはHDF5内のdemo単位に、actions、observations、rewards、donesなどを格納します。終了状態を表すフィールド名や意味は実装によって異なるため、単にdoneという名前を合わせるだけでは不十分です。時間制限による終了と、タスクの成功・失敗による終了を区別するかを仕様に記録してください。

推奨する収集スキーマ

最低限、次の情報をepisode・stepに分けて保持します。

観測：カメラ画像、深度、関節位置・速度、エンドエフェクタ状態などのraw値と前処理済み値
行動：指令値と実行値。関節位置・速度・トルク、エンドエフェクタ姿勢、デルタ動作などの表現を明記
時刻：センサーごとのtimestamp、フレーム番号、制御周期、episode開始・終了時刻
終了情報：報酬または評価値、discount、is_first、is_last、is_terminal、成功・失敗・中断の理由
メタデータ：タスクID、ロボット構成、センサー構成、単位、座標系、カメラとロボットのキャリブレーション
再現性情報：収集ソフトウェア、データスキーマ、前処理、設定のバージョン

複数のロボットやデータセットを統合する場合は、共通の論理スキーマを使いながら、元の行動空間、単位、座標系、制御周期、観測モダリティをメタデータとして残します。同じactionというフィールドでも、関節指令なのかエンドエフェクタの相対動作なのかで意味は変わるためです。

flowchart TB
  D["Dataset"] --> E["Episode：1回の試行"]
  E --> EM["Episodeメタデータ：タスクID、ロボット構成、センサー構成、キャリブレーション、単位、座標系、バージョン"]
  E --> S["Step：episode内のある時刻の観測と行動"]
  S --> T["timestamp・フレーム番号・制御周期"]
  S --> O["observation：画像、深度、関節状態、エンドエフェクタ状態"]
  S --> A["action：指令値・実行値、行動表現"]
  S --> R["reward・評価値・discount"]
  S --> F["is_first・is_last・is_terminal"]
  E --> X["終了情報：成功・失敗・中断・時間制限などの理由"]

実機デモはepisodeとstepの階層で管理し、各stepに観測・行動・時刻・終了状態を、episodeにタスクやセンサーなどのメタデータを付与します。

保存形式は学習基盤で選ぶ

保存形式は一つに固定されません。重要なのは、論理的なepisode・step構造と、原仕様を失わないメタデータです。

形式	構造・特徴	向いている場面	注意点
RLDS	episodeとstepを中心に、観測、行動、終了状態などを表現	step中心の学習基盤、複数データセットの統合	`is_last`や`is_terminal`の意味を実装間で確認する
robomimic HDF5	demo単位にactions、observations、rewards、donesなどを格納	robomimicを利用するロボット操作学習	HDF5内のキーとデータ型、終了状態の意味をそろえる
Parquet・MP4系	低次元データやメタデータを表形式、映像を動画チャンクとして分離	映像と状態データを分けた運用、I/Oや管理単位を重視する場合	圧縮方式やフレーム欠落の影響をタスクごとに確認する

実務では、変更しないrawログ層、学習向けに正規化した層、品質検証結果とprovenanceを管理するmanifest層の三層構成が扱いやすい設計です。rawを上書きせず、変換元と変換処理のバージョンを追跡できるようにします。