合成データ on Physical AI Hub

ロボット学習のアクティブラーニング：実機データ収集を不確実性とカバレッジで最適化する

Tue, 13 Oct 2026 15:39:47 +0900

実機データを増やすほど学習が良くなるとは限らない点が、このテーマで特に気になるところです。

先に結論

ロボット学習で次に収集する実機データは、単に失敗回数が多いものや、モデルの不確実性が高いものから選ぶべきではありません。タスク、状態、作業フェーズ、環境条件ごとに、不確実性、条件付き失敗リスク、既存データのカバレッジ不足、多様性、安全性、収集コストを組み合わせて判断します。

実装の出発点としては、候補となる状態や時間窓ごとに、次のような獲得スコアを計算します。

S(x)=w_uU(x)+w_fF(x)+w_cC(x)+w_dD(x)-w_kK(x)

ここで、Uは不確実性、Fは条件付き失敗リスク、Cはカバレッジ不足、Dは多様性・新規性、Kは収集コストまたは安全リスクです。スコア上位をそのまま大量収集するのではなく、似た候補が集中しないよう多様性制約を加え、収集後は固定した層別ホールドアウトで効果を検証します。

なぜ収集対象の選択が必要か

実機データには、ロボットの稼働時間、操作者の作業時間、設備の占有、安全監視などのコストがあります。データ量を増やしても、すでに十分観測された状態ばかりが追加されれば、未経験の初期条件や失敗直前の状態は埋まりません。

ロボットの模倣学習では、デモンストレーションの総量だけでなく、品質、タスクや状態の多様性、初期条件のばらつきが性能に関係します。したがって、全体の平均的な成功率だけでなく、どの条件が不足しているかを把握する必要があります。

判断に使う用語

不確実性は、モデルが入力に対してどれほど確信を持てないかを表します。たとえばMC dropoutでは、dropoutを有効にした確率的推論を複数回行い、予測の分散からモデル由来の不確実性を近似します。ただし、これは成功確率や失敗確率そのものではありません。センサー雑音、接触の偶然性、物体の滑りやすさのようなデータ固有の不確実性とは一致しない場合があります。

条件付き失敗リスクは、全体の失敗件数ではなく、特定の条件における失敗確率です。対象には、タスク、物体、初期姿勢、作業フェーズ、環境、操作者、ロボット構成などが含まれます。頻出する失敗でも、すでに十分な例が集まっていれば、追加収集の情報価値は低い可能性があります。

カバレッジ不足は、既存データで十分に観測されていない領域です。タスク・フェーズ別のヒストグラム、表現空間の近傍密度、クラスタ占有率、環境・物体・操作者の組み合わせなどで確認できます。全体平均ではなく、どの条件の組み合わせが空いているかを見ることがポイントです。

アクティブラーニングの仕組み

候補を作る単位は、エピソード全体に限りません。失敗直前の時間窓、接触イベント、タスクの初期状態、リカバリ操作などを候補にできます。各候補について、モデルの予測、過去ログ、状態分布を参照して指標を正規化します。

不確実性の選択には、MC dropout、アンサンブル分散、モデル間の行動不一致、予測エントロピー、価値関数の分散などが考えられます。失敗については、生の件数よりも条件付き失敗確率、失敗の重大度を加味した期待損失、回復可能性を考慮した優先度が適しています。

そのうえで、期待値の高い候補をバッチで選びます。不確実性上位だけを選ぶと、外れ値や互いに似たサンプルばかりになることがあります。代表性や多様性を組み込み、異なるクラスタ、作業フェーズ、環境条件が同じバッチに含まれるようにします。

flowchart LR
  A["既存データ・実機ログ"] --> B["タスク・状態・フェーズ・環境ごとに分割"]
  B --> C["候補状態・時間窓・接触イベントを作成"]
  C --> D["モデル推論"]
  C --> E["既存データ分布の分析"]
  C --> F["安全性・収集コストの確認"]
  D --> G["不確実性を推定"]
  D --> H["条件付き失敗リスクを推定"]
  E --> I["カバレッジ不足・新規性を計算"]
  G --> J["獲得スコアを統合"]
  H --> J
  I --> J
  F --> J
  J["S(x)=w_uU+w_fF+w_cC+w_dD-w_kK"] --> K["多様性制約付きバッチ選択"]
  K --> L{"安全確認を通過したか"}
  L -->|"はい"| M["人間デモ・自律試行・リカバリ試行を割り当て"]
  L -->|"いいえ"| N["候補を除外または条件を再設計"]
  M --> O["実機データを収集"]
  O --> P["モデルを再学習"]
  P --> Q["固定した層別ホールドアウトで評価"]
  Q --> R["未観測条件・成功率・回復率・安全性を確認"]
  R --> C
  N --> C

不確実性や条件付き失敗リスクだけでなく、カバレッジ不足、多様性、安全性、収集コストを統合して実機データを選択する反復ループです。

指標と選択方法の比較

観点	代表的な方法	優先しやすいケース	誤選択のリスク
不確実性	MC dropout、アンサンブル分散、行動不一致	モデルが判断に迷う状態	外れ値やノイズを選びやすい。不確実性は失敗確率を直接示さない
失敗	条件付き失敗確率、期待損失、回復可能性	特定条件で失敗が集中する状態	生の件数だけでは露出回数や既存データ量を反映しない
カバレッジ	フェーズ別分布、近傍密度、クラスタ占有率	未観測の初期条件や環境	密度を広げてもデモ品質や接触ダイナミクスが不足する場合がある
多様性	クラスタ別層化、代表性制約	バッチ内の重複を避けたい場合	代表性を優先しすぎると高リスク条件を取り逃す可能性がある
コスト・安全	監視コスト、損傷リスク、収集時間	実機試行に制約がある場合	低コストだけを選ぶと重要な危険状態を学べない

実装の流れ

まず、ログにタスク名だけでなく、物体、初期姿勢、作業フェーズ、環境、照明、操作者、ロボット構成、成功・失敗、失敗の重大度、リカバリ結果を記録します。次に、既存データを条件別に分割し、状態ごとの露出回数と失敗確率を推定します。

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

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または環境固定条件を持たせます。「未確認」「確認済み」「再学習投入」「テスト化」「解消」「再発」といった状態を管理すれば、改善サイクルのどこにあるかを追跡できます。

ロボット学習の合成データ戦略：実機データとの境界をどう設計するか

Wed, 15 Apr 2026 00:45:58 +0900

合成データを増やせば実機データを減らせる、という単純な関係ではない点が気になるテーマです。

先に結論

ロボット操作向けの合成データは、実機データを一律に置き換えるものではない。視覚的なばらつきや、シミュレータで正確に生成できる状態・ラベルが成否を左右するなら、視覚認識の事前学習や一部の方策学習で実機データを代替できる。一方、摩擦、接触順序、柔軟性、センサー雑音、アクチュエータ遅延などが支配的な操作では、実機の成功・失敗例を基準データとして残し、合成データで拡張したうえで実機微調整と独立評価を行うべきだ。

したがって、設計の単位は「合成データ何％」ではなく、視覚・物理・センサー・ラベルという要因ごとの再現可能性である。タスクを分解し、実機で固定すべき分布と、シミュレーションで広げる分布を決めることが出発点になる。

なぜ代替条件の切り分けが必要か

合成データは、実機では収集しにくい大量の画像、状態、軌道を生成できる。しかし、生成量が増えても、シミュレータに含まれない失敗要因は学習できない。反対に、現実の一例へ過度に合わせたシミュレーションは、別の照明、背景、物体配置、物理条件で性能を落とす可能性がある。

また、先行研究の「合成データ」は同じものではない。画像のドメインランダム化、物理パラメータのランダム化、実機デモンストレーションから生成した合成軌道など、方式と目的が異なる。そのため、研究間の性能値を単純に並べて、普遍的な混合比率を導くことはできない。

前提となる用語

ドメインランダム化は、テクスチャ、照明、姿勢、背景、物体配置などをシミュレーション中に変化させ、実環境の見え方に対する頑健性を学習させる方法である。シミュレーション画像だけで学習した物体認識モデルを実環境へ移転した実証がある。

ダイナミクスランダム化は、質量、摩擦、遅延などの力学パラメータを変化させる方法である。単一の物理モデルへ過適合することを避け、複数の条件に対応する方策を学習する。研究対象となったロボット制御タスクでは、追加の実機学習なしで実機へ移転した例も報告されている。

実機アンカーとは、実際のカメラ、物体、治具、ロボットで取得した成功・失敗データを、学習や評価の基準として使う考え方である。シミュレーションの分布を広げる場合でも、現実にどのような見え方や接触が起きるかを判断する基準になる。

合成データが機能する仕組み

視覚認識では、実運用で起こり得る照明、背景、姿勢、物体配置を広くランダム化することで、特定の画像条件への依存を抑える。物体の位置や形状をシミュレータが管理していれば、認識対象のラベルも一貫して生成できる。この領域では、実機画像を使わずに学習したモデルの実環境移転が示されている。

制御では、質量や摩擦、遅延といったパラメータを一つに固定せず、分布として扱う。さらに、接触を伴う器用な手内操作についても、視覚と物理ダイナミクスをランダム化して学習した方策を実機で評価した事例がある。ただし、これらは特定のロボット、タスク、ランダム化設定での実証であり、別の構成にそのまま一般化できるとは限らない。

別の方法として、少数の実機による人間デモンストレーションを種データにし、シミュレーション内で物体配置や軌道を変換してデモンストレーションを増やす方式がある。これは実機データを排除するのではなく、現実の操作構造を保ったまま合成データで規模と多様性を補う設計である。

flowchart LR
  A["タスクを要因に分解"] --> B{"シミュレータで再現・ラベル生成しやすいか"}
  B -->|"比較的しやすい"| C["視覚認識・照明・背景・姿勢・状態ラベル"]
  C --> D["合成データ中心を検討"]
  B -->|"一部は再現可能"| E["質量・摩擦・遅延を含む制御"]
  E --> F["ダイナミクスランダム化と実機移転確認"]
  B -->|"再現しにくい要因が支配的"| G["接触順序・柔軟性・センサー雑音・固有差"]
  G --> H["実機アンカーと実機微調整を重視"]
  D --> I["独立した実機評価"]
  F --> I
  H --> I
  I --> J["失敗モードと未カバー領域を確認"]

合成データの比率ではなく、視覚・物理・センサー・接触など各要因の再現可能性でデータの役割を判断する。

要因別に見る選択基準

対象要因・タスク	合成データの役割	実機データの扱い	初期判断
視覚認識、照明・背景・姿勢のばらつき	ドメインランダム化で広く拡張	独立した実機評価に使用	合成中心を検討
物体配置や状態ラベル	状態とラベルを大量生成	実機分布との対応を確認	代替可能性が比較的高い
質量・摩擦・遅延を含む制御	ダイナミクスランダム化で条件を拡張	実機の移転性能と失敗を確認	タスク依存で併用
接触豊富な把持・手内操作	視覚・物理条件をランダム化	成功・失敗例をアンカーにする	混合を基本にする
柔軟物、摩擦、接触順序が支配的な操作	稀な条件や失敗条件を補う	実機データと実機微調整を重視	実機併用が必要
実機デモからの軌道生成	配置や軌道を変換して拡張	少数の種データを保持	ハイブリッドを検討

この表は固定的な処方箋ではない。特に、カメラの視野・ノイズ、アクチュエータの遅延、物体や治具の公差、柔軟性をシミュレータがどの程度表現できるかで判断は変わる。