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から参照します。

実験管理 on Physical AI Hub

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

結論

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

来歴管理の基本用語

Run Manifestに何を記録するか