Physical AI 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と転送、モデル入出力、計画・制御コマンド、アクチュエーターのフィードバックまでを連続した契約として捉えます。各境界にスキーマ、座標系、時刻、品質、バージョンを置くと、変更箇所と影響範囲を追跡しやすくなります。

ロボット視覚の語彙設計：オープンボキャブラリー認識とタスク限定認識の使い分け

Thu, 05 Nov 2026 15:22:58 +0900

語彙を広げるほどロボットが賢くなるのか、それとも判断を狭く保つことが安全につながるのかが、このテーマの出発点です。

結論

認識対象が頻繁に変わり、未知物体の発見や自然言語による対象指定が必要なら、オープンボキャブラリー認識を第一候補にする。一方、棚卸しSKUやピッキング対象が固定され、誤検出のコストと再現性が重い場合は、タスク限定認識を基本にするのが妥当だ。

安全性が必要なロボットでは、どちらか一方に任せるより、オープンボキャブラリー方式で候補を発見し、後段のタスク限定モデル、未知拒否、行動ゲートで検証する構成が現実的である。

なぜ語彙設計が重要か

ロボットの視覚認識では、画像中の物体を見つけるだけでは動作を決められない。検出結果が示すのは、主に対象の位置と、指定された語彙との一致である。把持可能性、向き、材質、危険性、作業手順への適合性まで自動的に確定するわけではない。

そのため、認識器の選択は既知クラスの精度だけで決められない。未知物体を誤って受け入れる割合、低信頼度入力を拒否したときのカバレッジ、信頼度の校正、推論遅延、メモリ使用量、カテゴリ追加コスト、最終的な行動成功率を分けて考える必要がある。

用語と仕組み

オープンボキャブラリー認識は、学習時に固定したクラスIDだけでなく、推論時にテキストクエリなどで指定した語彙の対象を認識・検出する方式である。画像と自然言語の対応を学習したモデルでは、テキストラベルを指定したゼロショット分類が可能になる。OWL-ViT、Grounding DINO、ViLDは、この考え方を物体検出へ適用する代表例である。

一方、タスク限定認識は、業務で扱う対象とラベル定義をあらかじめ限定し、その範囲で分類・検出する構成を指す。対象が固定されているなら、必要なクラス、属性、拒否条件を明確に設計しやすい。反復的なピッキングや固定SKUの棚卸しでは、語彙を広げることよりも、定義した対象を安定して扱うことが優先される。

なお、オープンボキャブラリー認識とオープンセット認識は同義ではない。前者は推論時に語彙を拡張・指定する能力であり、後者は既知クラス以外の未知入力を検出し、拒否または未知として扱う能力である。テキストで対象を指定できても、未知物体を必ず安全に拒否できるとは限らない。

オープンボキャブラリー方式の価値と限界

カテゴリ追加のたびに完全な教師データを用意しなくても、長い尾のカテゴリや自然言語で指定した対象を候補化できることが大きな利点である。事前に全カテゴリを列挙しにくい環境理解や、探索段階の棚卸しでは、対象語彙を後から変更できる柔軟性が役立つ。

ただし、ゼロショット性能は、プロンプトの表現、画像ドメイン、照明、視点、遮蔽、対象カテゴリの粒度に左右される。研究論文で示されたベンチマーク結果から、特定の現場でタスク限定モデルを上回ることや、未知物体を適切に拒否することを保証することはできない。同義語、階層カテゴリ、ブランド名、属性語の影響もモデルとデータセットに依存する。

タスク限定方式の価値と限界

対象の種類とラベル定義が安定し、同じ対象を反復して扱うなら、タスク限定認識は評価範囲を明確にしやすい。誤検出が停止、衝突、誤ピッキングにつながる場合には、対象外を受け入れない条件やクラス別しきい値を設けやすい点も有利である。

ただし、限定したモデルでも信頼度をそのまま成功確率として扱ってはいけない。ニューラルネットワークの予測信頼度は、実際の正解率と一致しないことがある。温度スケーリングなどの校正、クラス別しきい値、拒否領域の検証が必要になる。限定方式だから必ず高精度、とは言えない。

flowchart LR
  A["画像入力"] --> B["オープンボキャブラリー候補生成\nテキストクエリで対象を指定"]
  B --> C{"候補の信頼度と対象条件を確認"}
  C -->|"未知・低信頼度、または条件不一致"| D["拒否・再観測・人手確認"]
  C -->|"検証対象として受理"| E["タスク限定分類"]
  E --> F["属性・姿勢・把持可能性を検証"]
  F --> G{"信頼度と安全規則を確認"}
  G -->|"条件を満たす"| H["ロボット動作"]
  G -->|"条件を満たさない"| D

オープンボキャブラリー認識を候補発見に使い、タスク限定の検証と信頼度・安全規則による行動ゲートを後段に置く構成。

選択肢の比較

観点	オープンボキャブラリー認識	タスク限定認識	ハイブリッド構成
語彙	推論時にテキストなどで変更・追加	事前に対象を定義	発見は広く、検証は限定
向く場面	未知物体の探索、環境理解、変動するカテゴリ	固定SKU、反復ピッキング、固定部品	安全性と柔軟性を両立したい場面
未知物体	候補化できるが、未知拒否は別機能	対象外として定義しやすいが、未知発見は弱い	候補生成後に拒否・検証できる
データ追加	カテゴリ追加時の教師データ負担を抑えやすい	アノテーションや再学習が必要になりやすい	追加対象だけを段階的に検証できる
主な注意点	プロンプト、視点、照明、遮蔽への依存	校正不良、対象外の誤受理、語彙外への対応	段数増加による遅延と設計複雑化
評価	未知誤受理率、候補再現、拒否性能	既知精度、校正、拒否性能	最終行動成功率と各段の失敗率

実装での使い分け

探索フェーズでは、画像入力に対してテキストクエリを変えながら候補を生成し、未知または低信頼度の候補をそのまま行動へ渡さない構成が考えられる。運用フェーズでは、候補に対してタスク限定の分類、属性確認、姿勢推定、把持可能性判定を行い、最後に信頼度と安全規則による行動ゲートを置く。

ロボットの遠隔操作と自律制御を安全に切り替える：人間への引き継ぎ設計

Fri, 30 Oct 2026 14:33:57 +0900

自律制御と遠隔操作の境界では、切り替えの速さよりも権限の重なりをどう防ぐかが設計上の焦点になります。

先に結論

ロボットの自律制御と遠隔操作の切り替えは、単一の信頼度スコアや「人間を常に優先する」という規則だけで決めるべきではない。安全包絡への接近、認識・自己位置推定の不確実性、タスク例外、通信状態、人間からの介入要求を組み合わせたリスクベースの状態遷移として設計する。

運動指令を発行できる主体は、常に一つに限定する。自律系と遠隔操作者の指令経路から分離した安全監視層を設け、必要な場合には双方の指令を拒否・遮断できるようにする。通信断、端末の無応答、許容遅延の超過、制御権の期限切れでは、遠隔操作を継続せず、検証済みの安全停止または最小リスク状態へ移行させる。

なぜ引き継ぎ設計が難しいのか

引き継ぎは、単にモード名を書き換える処理ではない。自律系が指令を出し続けたまま遠隔操作者の指令を受け付ければ、切り替え境界で指令が競合する。逆に自律系を先に停止すると、操作者が状況を把握する前にロボットが別の状態へ移る可能性がある。

そのため、設計対象はトリガーだけではない。旧制御主体がいつ指令権を失ったか、新しい主体がいつ取得したか、操作者がどの状態を見ているか、引き継ぎに失敗した場合にどこへ遷移するかまでを、制御契約として定義する必要がある。ISO 12100:2010も、意図する使用と合理的に予見可能な誤使用を含むリスクアセスメントとリスク低減を示しており、モード切替もその対象として扱うのが妥当である。ISO 12100:2010

前提となる用語

自律制御は、ロボット側の方策やプランナーが運動指令を生成する状態である。遠隔操作は、通信経路を通じて操作者が指令を入力する状態を指す。共有自律は、人間の方策とロボットの方策を組み合わせる設計で、意図検出、制御権の裁定、状態や意図の伝達が主要な論点になる。

共有自律には、人間とロボットの指令を連続的に混合するpolicy blendingと、明示的な裁定によって一方へ制御権を渡す方式がある。すべての用途で優れた単一方式が定まっているわけではないため、責任主体と安全制約を明確にできるかで選ぶべきである。

引き継ぎ条件の設計

引き継ぎトリガーは、次の観測項目を個別に評価し、論理条件として組み合わせる。

予測軌道が安全包絡に接近、または違反する
認識や自己位置推定の不確実性が許容範囲を超える
予定外の物体、作業対象、経路、タスク状態が現れる
遠隔操作者が介入を要求する
通信の期限、ハートビート、遅延などに異常がある

数値閾値は一般化できない。安全包絡、信頼度、通信遅延、タイムアウトの値は、ロボットの速度や質量、環境、作業対象、運用地域、適用規格によって変わるため、対象機のリスク分析と検証で定める。NIST AI Risk Management Frameworkは役割・責任、リスク測定、継続的監視、リスク対応を扱うが、具体的なロボットの切替閾値は規定していない。NIST AI RMF

状態機械と操作権限

実装では、少なくとも「自律制御」「引き継ぎ要求」「引き継ぎ待ち」「遠隔操作」「安全停止」「復旧」を明示した状態機械にする。引き継ぎ要求が発生しても、直ちに操作者へ運動指令を許可するのではなく、ロボット状態、通信品質、操作者の準備状態、停止が必要かどうかを確認する。

旧制御主体のアクチュエーション権限が失われたことを確認してから、新しい主体へ権限を渡す。制御権をリースまたはトークンとして扱い、期限切れ、二重取得、明示的な解放を検出できるようにすると、境界上の異常を追跡しやすい。

flowchart LR
  A["自律制御\n運動指令の主体: 自律系"] -->|"安全包絡への接近・認識不確実性・タスク例外・人間要求"| B["引き継ぎ要求"]
  B --> C["引き継ぎ待ち\n状態・通信・認証・準備状態を確認"]
  C -->|"旧主体の権限喪失を確認\n制御権リースを解放"| D["遠隔操作\n運動指令の主体: 操作者"]
  C -->|"確認失敗・承認失敗・危険状態"| E["安全停止または\n最小リスク状態"]
  D -->|"ハートビート途切れ・端末無応答\n許容遅延超過・リース期限切れ"| E
  D -->|"自律系への復帰条件を確認\n制御権を明示的に解放"| F["復旧"]
  E -->|"原因除去・安全確認・復旧承認"| F
  F -->|"新しい制御権を単一主体へ付与"| A
  S["独立した安全監視層\n速度・位置・侵入・停止条件を監視"] -.->|"必要時に指令を拒否・遮断"| A
  S -.->|"必要時に指令を拒否・遮断"| D
  S -.->|"通常の権限裁定とは分離"| E

引き継ぎ条件の評価、旧制御主体の権限喪失確認、新しい主体への制御権付与、通信異常時の安全遷移を状態機械として示す。

方式	指令の扱い	使いどころ	主な制約
自律制御	自律系が運動指令を発行	通常運転の自動化	想定外状態での引き継ぎ条件が必要
遠隔操作	操作者が運動指令を発行	例外状態への人間の介入	通信遅延、端末障害、状況認識が制約になる
共有自律	指令を混合または裁定	人間と自律系の協調	責任主体と指令競合の明確化が必要
安全監視・停止	指令を監視し拒否・遮断	危険状態の抑制	通常の操作権限とは分離して検証する

基本形として採用しやすいのは、単一オーナー方式である。自律系、遠隔操作者、保守・設定系のうち、運動指令を発行できる主体を常に一つにする。アクセス強制と最小権限の考え方は、主体ごとの権限分離に利用できるが、NIST SP 800-53自体はロボット安全規格ではない。NIST SP 800-53 Rev. 5

ロボットの長期記憶アーキテクチャ：エピソード・意味・手続き記憶をどう設計するか

Mon, 26 Oct 2026 13:28:05 +0900

長時間タスクでは、記憶を増やすことより、記憶をどう疑いながら使うかが設計上の焦点になります。

先に結論

ロボットの長時間タスクでは、エピソード記憶・意味記憶・手続き記憶を、異なる役割を持つ層として分離する設計が妥当です。エピソード記憶は時系列の経験証拠、意味記憶は検証・抽象化された環境知識、手続き記憶は条件付きで再利用できるスキルを担当させます。

オンライン実行では、現在のタスクとセンサー情報から過去の記憶を検索し、現在の状態と照合してから手続きを選択します。実行結果は新しいエピソードとして保存し、反復的に確認された事実や、検証済みで再利用価値のある行動だけを上位の記憶へ昇格させます。過去の記憶を、現在の環境の代わりに無条件で使わないことが設計の基本です。

なぜ記憶を分けるのか

長時間タスクでは、過去の観測や成功した操作を再利用できると、毎回ゼロから推論する必要を減らせます。一方、全履歴をVLMやVLAのコンテキストに入れ続ける方法は、履歴の増加と検索負荷を招きます。MemGPTは、モデルの主要コンテキストと外部アーカイブ記憶を分離し、必要な情報を関数呼び出しで移動・検索する構成を示しました。ロボットでも、実行モデルと長期記憶を分ける際の参考になります。

ただし、3分類はロボット研究で統一された標準仕様ではありません。メモリーストリームと反省を中心に扱う構成や、コンテキストとアーカイブの階層を扱う構成もあります。ここでの3分類は、保存対象、検索条件、更新条件、実行系との接続を整理するための設計上の枠組みです。

3種類の記憶の役割

エピソード記憶：経験の証拠

エピソード記憶には、時刻、場所、対象、観測、行動、成否、環境からのフィードバックを、一つの経験ログとして保存します。現在と似た状況を探す用途に向きますが、検索結果をそのまま事実や命令として扱ってはいけません。現在の知覚と照合するための状況証拠として利用します。

検索キーは意味的な類似度だけでなく、場所、対象、タスク、時刻、成功履歴などを組み合わせます。Inner Monologueが示すように、物体検出やシーン状態、行動の成功・失敗を推論へ戻せば、実行中の計画を更新できます。

意味記憶：抽象化された知識

意味記憶には、複数の経験から抽象化された安定的な事実を保存します。物体と場所の関係、ユーザーや施設の好み、環境の制約などが対象です。個別の観測をそのまま蓄積するのではなく、再利用しやすい知識として扱います。

各項目には、出典、信頼度、有効期限を付与します。単一の観測だけで固定せず、反復確認や他の観測との整合性を経て更新する方針が適しています。必要な反復回数や信頼度のしきい値に、一般的な数値基準は確立していません。

手続き記憶：実行可能なスキル

手続き記憶には、再利用可能なスキル、プログラム、ポリシー、行動スキーマを保存します。前提条件、引数、期待効果、実行後の検証方法も併せて管理します。

Voyagerは、環境からのフィードバックを用いて、実行可能なコード形式のスキルを蓄積・再利用する構成を示しました。これは手続き記憶の実装例として解釈できます。ただし、未知の物体、照明、配置、摩擦条件へ安全に一般化できる範囲は、スキル表現とロボットに依存します。

読み出しと書き込みの流れ

flowchart LR
  A["現在のタスクとセンサー入力"] --> B["メモリールータ"]
  B --> C["エピソード記憶\n経験証拠"]
  B --> D["意味記憶\n制約・環境知識"]
  C --> E["現在の状態との照合"]
  D --> E
  E --> F["手続き記憶\n前提条件付きスキル"]
  F --> G["実行可能性の再検証"]
  G --> H["実行器"]
  H --> I["行動結果・新しい観測"]
  I --> C

現在の知覚を起点に過去の記憶を検索し、手続きを再検証して実行した結果をエピソード記憶へ保存する流れ。

読み出しでは、現在のタスクと知覚情報をメモリールータへ渡します。エピソード記憶から類似する経験を、意味記憶から関連する制約や環境知識を検索し、それらを条件として手続き記憶から候補スキルを選びます。

SayCanは、言語モデルによる行動選択と、ロボットが各スキルを実行できる可能性を表すアフォーダンスを組み合わせます。この考え方は、手続きの検索と実行可能性の検証を分ける設計に対応します。実行後は、成功・失敗や環境からのフィードバックを取得し、継続または再計画します。

書き込みでは、まず全試行をエピソードとして保存します。反復・整合性・信頼度を確認し、安定した事実を意味記憶へ、再利用価値と安全性を検証できた行動系列を手続き記憶へ昇格させます。

記憶層の比較

記憶	保存対象	検索キー	更新	実行系との接続
エピソード	観測・行動・結果・時刻・場所	類似状況、場所、対象、タスク	試行ごとに保存	状況証拠として提供
意味	事実、関係、制約、好み	対象、場所、関係、制約	反復確認後に更新	手続き選択の条件
手続き	スキル、プログラム、ポリシー	タスク、前提条件、実行可能性	検証済みのものを登録	実行器へ渡すが再検証する

環境再訪での判断基準

再訪時は、場所・対象・タスクで候補を検索し、時刻、位置、信頼度、有効期限で絞り込みます。その後、現在のセンサー情報や状態推定と照合します。整合すれば手続きを候補にできますが、過去の成功履歴だけで実行を確定してはいけません。不一致なら、再観測や再計画へ分岐させます。

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

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時刻は一時停止、速度変更、時刻ジャンプの影響を受けるため、受信時刻や単調増加する経過時間と混同しない設計が必要です。

異種ロボットを同じ現場で動かすフリート連携：タスクAPI・交通管制・設備接続の分離

Mon, 12 Oct 2026 14:44:01 +0900

異なるメーカーのロボットを同じ現場で動かすとき、標準プロトコルだけで全てが解決するのかが設計上の焦点になります。

先に結論

複数メーカーのAMRや搬送ロボットを同じ現場で運用するには、単一の巨大なAPIへ機能を集約するのではなく、業務タスク、フリート・交通管制、ロボット固有の実行、設備接続を別レイヤーに分けることが基本です。VDA 5050などの標準は、上位の制御システムとロボットを接続するアダプターの境界で使い、メーカー差分をアダプター内に閉じ込めます。

ドア、エレベーター、コンベヤーなどは、タスク層からPLCやメーカー固有コマンドを直接呼び出さず、設備アダプターを介して共通リソースとして公開します。通路や交差点を複数フリートが共有する場合は、予約と交通管制の権限を一つの調停主体へ集約する構成を有力な候補として検討します。

なぜインターフェースを分けるのか

WMSやMESなどの業務システムが扱うのは、搬送、ピッキング、充電といった業務要求です。ロボットの走行には、機体の能力、地図、経路、状態、手動介入などの情報が必要になります。さらに複数フリートが同じ空間を共有する場合は、通路、交差点、ステーション、エレベーターの予約と交通協調が必要です。

設備も単純な「開ける」「呼び出す」コマンドではありません。利用要求、予約またはリース、使用開始、完了、解放、タイムアウト、異常という状態を持つ共有資源です。業務アプリケーションと機器を直結すると、メーカー変更や設備更新の影響が上位の業務ロジックまで及びます。

標準技術の役割

VDA 5050は、上位のMaster ControlとAGV・AMRの間の通信インターフェースを定義し、MQTTを介してJSON形式のメッセージを交換します。2.0.0相当の仕様では、NodeとEdgeによる経路表現やAction、注文識別子を含むOrder、State、InstantActions、Visualization、Factsheetなどを扱います。ただし、現場全体で誰が最終的な交通管制権限を持つかまでは一律に決めません。

Open-RMFは、複数のロボットフリートや建物設備を協調させる枠組みです。ベンダーごとのFleet ManagerをFleet Adapterで接続し、RMF側の要求や交通協調の情報を各フリート固有APIへ変換するとともに、ロボットの状態や進捗をRMFへ戻します。

MassRobotics AMR Interoperability Standardは、AMRの位置、状態、バッテリーなどを、他のAMRや周辺システムと共通形式で共有することを主な対象とします。注文を送り実行させるVDA 5050と、完全に同じ範囲ではありません。

MQTTは軽量なPublish/Subscribe型プロトコルで、トピックやQoSなどの配送機能を定義しますが、ロボットタスクや設備占有の意味論は定義しません。OPC UAは情報モデル、サービス、クライアント・サーバー通信、PubSubなどを定義するため、設備側の共通インターフェースを構築する基盤候補です。ただし、設備が必要な情報モデルや仕様を実装しているかは個別確認が必要です。

推奨アーキテクチャ

最上位にWMS、MES、または業務オーケストレーターを置き、その下にタスク正規化層を設けます。ここではタスク識別子、搬送元・搬送先、必要な能力、優先度などを扱います。

次に交通・リソース調停層を配置します。共有通路、交差点、ステーション、エレベーターの予約を管理し、各フリートへ利用許可や交通上の要求を伝えます。ローカル制御だけで共有資源を扱う場合は、競合解決の方法と責任境界を明示します。

その下にメーカー別Fleet Adapterを置き、共通タスクや交通上の要求をVDA 5050、ベンダー独自API、または対象フリートの実装へ変換します。ロボット固有の走行制御、状態、Action、手動介入の差は、この境界で吸収します。

設備側には設備リソースAPIと設備アダプターを置きます。設備リソースAPIは、ドアやエレベーターを共有資源として公開し、その下でOPC UA、MQTT、PLC接続、メーカー独自インターフェースを設備ごとに扱います。

flowchart TB
  subgraph business["業務層"]
    WMS["WMS・MES・業務オーケストレーター"]
  end

  subgraph common["共通制御・正規化層"]
    TASK["タスク正規化層\nタスクID・搬送元/先・能力・優先度・期限"]
    TRAFFIC["交通・リソース調停層\n共有通路・交差点・ステーション・エレベーター"]
    RESOURCE["設備リソースAPI\n要求・予約・占有・完了・解放・異常"]
  end

  subgraph fleet["ロボット連携層"]
    FA1["メーカー別Fleet Adapter A"]
    FA2["メーカー別Fleet Adapter B"]
    VDA["VDA 5050またはベンダー独自API"]
    ROBOT1["ロボットフリート A"]
    ROBOT2["ロボットフリート B"]
  end

  subgraph equipment["設備接続層"]
    EA["設備アダプター"]
    CONNECT["OPC UA・MQTT・PLC接続・設備固有インターフェース"]
    DEV["ドア・エレベーター・コンベヤーなど"]
  end

  WMS --> TASK
  TASK --> TRAFFIC
  TASK --> FA1
  TASK --> FA2
  TRAFFIC --> FA1
  TRAFFIC --> FA2
  FA1 --> VDA
  FA2 --> VDA
  VDA --> ROBOT1
  VDA --> ROBOT2
  TRAFFIC --> RESOURCE
  TASK --> RESOURCE
  RESOURCE --> EA
  EA --> CONNECT
  CONNECT --> DEV

業務タスク、共有空間の交通・リソース調停、メーカー別ロボット実行、設備接続を別レイヤーに分離した推奨構成。

設備利用の流れは、要求、予約またはリースの取得、ロボットの到着、使用開始、完了、解放です。到着できない、設備が応答しない、通信が切れるといった場合は、タイムアウトや異常として通知し、占有をいつ解放するかを定義します。

人協働ロボットの近接安全設計：人の動きを推定して速度制限へつなげる方法

Fri, 09 Oct 2026 14:54:15 +0900

人の動きを予測できても、安全判断では予測の不確実性をどう扱うかが問われます。

先に結論

人と協働するロボットの近接安全は、「人を検知したら停止する」か「AIの予測に任せる」かの二択ではない。人体の占有領域をロボットの危険源と同じ座標系で扱い、検出遅延、遮蔽、位置誤差、相対速度、ロボットの停止距離を含めて保護分離距離を継続評価することが基本になる。

分離距離を保証できる間は通常速度または制限速度で運転し、制限速度でも境界を維持できない場合は保護停止へ移行する。センサー故障、追跡断絶、通信・同期異常などで保証が失われた場合は、最後の推定値や予測値で運転を継続しない。予測軌道は先回りした速度制限の補助には使えるが、それだけを安全バリアとして扱うべきではない。

なぜ動的な評価が必要か

協働ロボットでは、人が作業領域に入ること自体が直ちに異常とは限らない。ロボットの速度、工具の形状、人体との距離、制動性能に応じて、通常動作、速度制限、保護停止を使い分ける必要がある。一方、検出から制動開始までに時間がかかれば、検知時点では安全に見えても、ロボットはその間に人体へ接近する。

そのため設計対象は人体検出器だけではない。センサー、推定器、通信、制御器、ドライブ、ブレーキを含む安全機能全体を、リスクアセスメントと安全関連制御系の要求に結び付ける必要がある。ISO/TS 15066は速度・分離監視などの協働運転方式を扱い、ISO 12100は危険源の同定、リスク低減、妥当性確認を含む設計プロセスを示している。

位置・速度・予測軌道の扱い

人体の位置は一点ではなく、人体または身体部位の占有領域として表現する。人体、ロボットの危険点、工具、周辺設備を共通座標系へ変換し、センサーの位置誤差、時刻同期と検出の遅延、遮蔽、複数人の識別不確実性を危険側に評価する。

安全レーザースキャナなどが保護フィールドへの侵入状態だけを出力する場合、その出力から連続的な位置や速度を直接得られるとは限らない。連続トラッキングを利用する場合は、時刻付きの位置推定から危険源への相対速度、つまり接近速度を算出する。平滑化や外れ値除去を行う場合も、更新遅延、推定誤差、トラッキング断絶を考慮し、瞬間値をそのまま安全入力にしない。

予測軌道は、将来位置を示す一本の確定線ではない。人の動きは周囲の人、物体、環境、相互作用、作業意図に依存し、予測ホライズンが長いほど不確実性が増す。したがって短時間先の複数の軌道候補を包絡する占有領域として扱い、最大接近速度と位置不確実性を含めてロボットの停止包絡との重なりを評価する。遮蔽、信頼度低下、追跡断絶、想定外の加速度が起きた場合は、予測を無効化して保守側へ遷移させる。

flowchart LR
  A["センサー入力\n時刻付きデータ"] --> B["時刻同期・共通座標系への変換"]
  B --> C["人体・身体部位の\n占有領域を推定"]
  C --> D["追跡・接近速度・\n不確実性を推定"]
  D --> E["短時間の複数軌道を\n占有包絡として評価"]
  E --> F["ロボットの停止包絡と\n保護分離距離を評価"]
  F --> G{"分離距離を\n保証できるか"}
  G -->|"余裕がある"| H["通常動作"]
  G -->|"制限速度なら保証可能"| I["速度制限"]
  G -->|"保証できない"| J["安全関連の保護停止"]
  D --> K{"追跡・同期・検出系に\n異常があるか"}
  K -->|"いいえ"| E
  K -->|"はい"| L["保守側へ遷移"]
  L --> I
  L --> J
  E -.-> M["予測は補助情報\n安全バリア単独ではない"]
  M -.-> F

人体の位置・接近速度・不確実性とロボットの停止性能を継続的に評価し、分離距離を保証できる範囲で速度を制限し、保証できない場合は保護停止へ移行する概念フロー。

分離距離から速度制限へ

保護分離距離の考え方では、人体の接近速度、システム全体の応答時間、ロボットの停止距離、人体または身体部位の侵入距離、センサーと位置推定の不確実性を考慮する。ISO 13855の基本関係は、接近速度をK、総応答時間をT、侵入距離をCとして S=K×T+C で表される。

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

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システムの概念化、開発、検証・妥当性確認、導入、運用、保守、廃止を含むライフサイクルプロセスを扱います。

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を併記します。

Physical AIの評価設計：タスク成功率だけでなく安全性と再現性を測る方法

Sat, 04 Jul 2026 01:25:33 +0900

成功率の高さだけで、ロボットAIの実用性を判断してよいのかという疑問から、評価軸を整理しました。

はじめに

Physical AI、特にロボットAIは、画像認識や単回のタスク成功率だけでは実運用への適性を判断できません。安全に動作したか、同じ条件で安定して再現できるか、環境やロボット個体が変わっても性能を保てるかを分けて測る必要があります。

先に結論

評価は「タスク有効性」「安全性」「再現性」の三軸で設計します。成功率は、事前に固定した主成功条件を満たした試行の割合として算出し、部分達成、所要時間、手動介入、リカバリ回数は別指標で報告します。

安全性は、接触、衝突、保護停止、非常停止、安全制約違反、人間の介入、ニアミスをイベントとして記録し、重大度と試行回数または稼働時間で正規化します。再現性は、同一条件での反復性と、乱数種、環境、操作者、ハードウェアなどを変えた再現性に分けます。総合スコアを使う場合も、重み、最低限の安全条件、失敗時の扱いと下位指標を公開します。

なぜ成功率だけでは足りないのか

RLBenchやLIBEROのようなベンチマークは、タスク集合やタスク変動を定義し、タスク成功を主要指標にしています。手法比較には有用ですが、成功条件、試行回数、タスクごとの重み、評価環境、介入の扱いが違えば、異なるベンチマークの数値は単純比較できません。

成功していても、毎回人間の介入が必要、所要時間が長い、危険な接触を伴う、といった問題は残ります。NIST AI RMF 1.0も、妥当性・信頼性、安全性、セキュリティ・レジリエンス、説明可能性・透明性などを区別しています。ロボット評価でも、異なる性質を一つの数値に押し込めない設計が適しています。

用語と成功条件を固定する

タスクごとに、開始状態、対象物、許容操作、主成功条件、失敗条件、最大実行時間を事前に定義します。例えば対象物を指定位置へ移動し、規定姿勢で停止することを主成功条件にするなら、途中まで移動できた試行は部分達成として別に扱います。

成功率 = 主成功条件を満たした試行数 ÷ 予定した全試行数

無効試行を分母から除く場合は、判定基準と理由を記録します。部分達成率、実行時間、介入回数、リカバリ回数、失敗分類も併記し、成功率へ混ぜないことが重要です。

三つの評価軸

タスク有効性

全体の成功率だけでなく、タスク別の成功率、部分達成、所要時間、介入回数、リカバリ回数を記録します。タスクごとの試行数や難易度が異なる場合、平均方法が結果を左右するため、タスク別内訳を公開します。

安全性

安全イベントは成功・失敗とは別のログにします。接触力を測れる構成では接触力も記録し、衝突、予期しない接触、保護停止、非常停止、安全制約違反、介入、ニアミスを分類します。イベントごとに重大度、発生試行、稼働時間、原因、復旧の有無を付与します。

ISO/TS 15066:2016は、協働ロボットシステムと協働運転の安全要求・指針を扱い、パワー・フォース・リミッティングも対象にしています。ただし、これだけで自律移動ロボット、屋外、家庭環境、タスク固有のリスクをすべて評価できるわけではありません。

反復性と再現性

同じモデル、ロボット、環境、手順で複数回試す評価は、同一条件での反復性を見ます。乱数種、学習チェックポイント、初期姿勢、物体配置、照明・背景、操作者、ロボット個体、ソフトウェアやモデルのバージョンを変える試験は、条件変更への再現性を見ます。

ISO 5725-1およびISO 5725-2は、同一条件での反復性と、操作者・装置・場所・時間などを変えた再現性を区別しています。一方、ISO 9283:1998は、産業用マニピュレータの位置姿勢や軌道の精度・反復性、安定時間、オーバーシュートなどを扱います。機構性能の反復性と、学習ポリシーの実験再現性は別の概念です。

flowchart LR
  A["評価対象とタスクを定義"] --> B["開始状態・主成功条件・失敗条件・最大実行時間を事前登録"]
  B --> C["固定条件で複数試行"]
  C --> D["主成功条件を満たしたか判定"]
  D -->|"達成"| E["成功として集計"]
  D -->|"一部達成"| F["部分達成として別集計"]
  D -->|"未達"| G["失敗分類と停止理由を記録"]
  C --> H["安全イベントを独立ログに記録"]
  H --> H1["接触・衝突・保護停止・非常停止・制約違反・介入・ニアミス"]
  H1 --> H2["重大度・発生試行・稼働時間・原因・復旧の有無を付与"]
  C --> I["所要時間・介入回数・リカバリ回数を記録"]
  E --> J["同一条件で反復性を評価"]
  F --> J
  G --> J
  J --> K["乱数種・初期姿勢・物体配置・照明・操作者・個体・バージョンを段階的に変更"]
  K --> L["条件変更後の再現性を評価"]
  J --> M["平均・ばらつきまたは信頼区間を報告"]
  L --> M
  H2 --> M
  I --> M
  M --> N["タスク有効性・安全性・再現性を独立指標として判断"]

タスクの結果、安全イベント、試験条件の変化を別々に記録し、タスク有効性・安全性・再現性の三軸で報告する評価フロー。

評価項目の比較

評価軸	主な指標	条件・ログ	注意点
タスク有効性	成功率、部分達成率、時間、介入、リカバリ	タスク定義、試行数、終了条件	成功率に別指標を混ぜない
安全性	接触・衝突、停止、制約違反、ニアミス	重大度、試行数、稼働時間、原因	成功率と独立集計する
反復性	同一条件での性能のばらつき	同一モデル、個体、環境、手順	機構とポリシーを区別する
再現性	条件変更後の性能維持	乱数種、環境、操作者、個体、版	変更条件を明示する
実機移行	シミュレーションとの差	接触、ノイズ、誤差、物体差	実機結果を別報告する

実機評価プロトコル

最初に、タスク、主成功条件、失敗分類、安全イベント、無効試行の条件を事前登録します。モデル、コード、センサ、ハードウェア、ロボット、環境のバージョンを記録し、同一条件で複数試行します。結果には試行数、成功率、タスク別内訳、所要時間、失敗分類、介入数、停止理由、平均・分散または信頼区間を含めます。

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["継続監視・展開判断"]

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

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

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

AIロボットの安全設計：非常停止とAI判断を分離する理由

Thu, 15 Jan 2026 00:01:44 +0900

編集コメント：AIが危険を検知できることと、機械の安全機能を担えることは同じではありません。両者の責任分界を設計段階で明確にする必要があります。

先に結論

Physical AIやAI搭載ロボットでは、非常停止をAIの判断だけに依存させるべきではありません。非常停止入力、保護センサ、安全ロジック、アクチュエータ停止までの安全関連経路を、AIの通常制御・推論経路から機能的に独立させるのが基本です。AIはカメラやセンサから危険を検知し、追加の停止要求を出す補助層として扱います。

ここでいう「分離」は、必ずしも別CPUや別配線を意味しません。必要な安全性能、故障時の安全状態、共通原因故障への耐性をリスクアセスメントで確認できるなら、安全コントローラや安全認証済みネットワークを使った統合も候補になります。ただし、AI系の停止要求が失敗しても、人間の非常停止や保護センサから安全状態へ移行する経路が機能しなければなりません。

なぜAI判断と非常停止を分けるのか

AIの認識や行動計画は、入力データ、推論処理、通信、ソフトウェアの状態に依存します。危険を認識できない場合だけでなく、推論や通常制御が停止した場合にも、安全機能まで失われる構成は避ける必要があります。

機能安全で評価する対象は、AIの認識精度だけではありません。安全関連制御部に要求される性能、故障の検出、故障時にどの安全状態へ移行するか、ソフトウェアを含む設計と統合を確認します。したがって、AIモデルの精度評価やAIリスク管理の文書だけで、非常停止回路の安全妥当性を示すことはできません。

用語を分けて仕様化する

ISO 13850:2015では、非常停止機能は単一の人間の操作で開始される機能として扱われます。すべての運転モードで利用可能かつ作動可能で、他の機能や操作より優先され、リセットだけで再起動してはなりません。また、非常停止は安全防護の代替ではなく、補完的な安全機能です。

一方、AIが自動的に出す停止要求を製品資料などで「E-stop」と呼ぶことがあります。しかし、仕様上は少なくとも次を区別する必要があります。

非常停止：人間の操作で開始され、他の操作より優先される安全機能
保護停止：センサなどが危険条件を検知したとき、安全状態へ移行する機能
通常停止：タスク完了や運用指示に基づく停止
AIによる停止要求：AIの危険検知を起点とする追加の停止要求

AIによる停止要求を、非常停止の代替として扱うのではなく、保護停止や追加のリスク低減層として要件、故障時挙動、検証方法を別途定義することが妥当です。

内部の仕組み

基本構成では、非常停止ボタン、ガードスイッチ、安全スキャナなどを安全ロジックへ接続します。安全ロジックは安全関連の出力を介して、安全対応ドライブやブレーキなどを制御し、機械を定義済みの安全状態へ移行させます。AI側はカメラやセンサを入力として推論し、必要に応じて安全系へ停止要求を入力しますが、AI側から安全系を無効化する経路は設けません。

安全状態がモータトルク遮断、ブレーキ適用、電源遮断、保持状態のいずれになるかは、ロボットの機構、負荷、落下や挟圧の危険によって異なります。対象機械の情報がない段階で、停止カテゴリ、停止時間、制動距離、要求PLやSILを一律に決めることはできません。

flowchart LR
  subgraph SAFETY["安全関連経路"]
    E["非常停止ボタン"] --> SL["安全ロジック"]
    G["ガードスイッチ"] --> SL
    S["安全スキャナ"] --> SL
    SL -->|"安全関連出力"| D["安全対応ドライブ"]
  end

  subgraph AICTRL["AI・通常制御経路"]
    C["カメラ・センサ"] --> INF["AI推論"]
    INF --> P["タスクプランナ"]
    P --> NC["通常コントローラ"]
    NC -->|"通常の駆動指令"| D
    INF -->|"補助的な停止要求"| SL
  end

  D --> A["アクチュエータ"]
  A --> SS["定義済みの安全状態"]

非常停止と保護センサを含む安全関連経路を、AIの推論・通常制御経路から機能的に分けた基本構成。AIは安全系への追加の停止要求を出せるが、安全系を無効化する経路は設けない。

系統ごとの比較

系統・方式	主な開始者	役割	AIへの依存	設計・検証の焦点
非常停止	人間	危険な機能を優先的に停止	依存させない	常時利用可能性、優先性、リセット後の再起動防止
保護停止	保護センサや安全ロジック	検知した危険条件から安全状態へ移行	安全センサを使う場合は安全系として評価	故障検出、安全状態、要求性能
通常停止	運用者やタスク制御	通常の動作終了	通常制御に依存	停止手順と運用上の再開条件
AIによる停止要求	AIの危険検知	追加のリスク低減層	認識・推論に依存	未検知、誤検知、停止要求失敗時の挙動

物理分離か、機能的な分離か

設計判断では、まず「別CPUかどうか」ではなく、安全機能がAI系の故障に妨げられないかを確認します。AIの通常制御と安全関連制御を別の機能として定義し、入力、処理、出力、故障時挙動、検証責任を分けることが出発点です。