Physical AI

LeRobotDataset v3.0の変更点：ParquetとMP4の連結、区切りの移動

2026/9/17 （更新: 2026/11/1）

🤖 AIを使用して執筆

何が変わったか：区切りがファイル名からメタデータへ移った

v2では、エピソードを一つずつ別のファイルに収め、ファイル名そのものが区切りだった。v3.0では、状態・行動・タイムスタンプのような低次元で高頻度の信号を、複数エピソード分まとめてParquet（列指向のデータファイル形式）に入れる。カメラのフレームも複数エピソード分を連結してMP4に入れる。どのエピソードが共有ファイルのどこからどこまでかは、メタデータに開始と終了の位置として書く²。設計した側は文書でこれを「エピソードの境界と参照は、ファイル名を介さずメタデータを介して解決される」と述べている²。

利用者から見た読み方は変わらない。ライブラリのAPI（Application Programming Interface）を通せば、エピソードは相変わらずエピソード単位で取り出せる。文書はこの分離を中心の原則として置く。「v3の中心的な原則は、ストレージ（保存の仕組み）を利用者向けAPIから切り離すことにある。データは効率よく（少数の大きなファイルとして）保存される一方、公開されるAPIはエピソード単位の直感的なアクセスを提供する」²。保存の都合と利用者からの見え方を別々に決める設計である。同じ文書は、保存層だけをLance（別のデータ形式）に置き換えた実装をLeRobotDatasetのサブクラスとして挙げ、読み出しを速めうると書く²。v3.0を含む安定版は2025年10月にPyPIへ出ている⁴。

なぜ変わったか：数百万エピソードへの拡大を見込んだ

開発チームは、形式を変える理由にデータセットの規模を挙げる。v2について「データセットの規模を数百万エピソードまで広げようとすると、ファイルシステムの限界にぶつかった」と述べ、連結する狙いを「データセットに含まれるファイルの数を大きく減らし、現代のファイルシステムにとってより効率がよい」と説明している⁵。設計の文書は利点として、ファイルの数が減ることで初期化が速くなり規模が大きくなったときの問題が減ることを挙げ、Hubから直接読むストリーミングも同じ版で新しくなった点に数える²。

規模の要求は、データを出す側から実際に来ている。自動運転データセットL2Dを公開するyaakは、100エピソードの最初の版から段階的に広げ、2026年9月12日時点で公開中の版は10万エピソードを収める⁶。同社とLeRobotの共著による発表記事は、最大のオープンソース自動運転データセットを目指すと書き、「ロボットAIモデルの性能は、訓練集合に含まれるエピソードの質によって上限が決まる」として、質を確かめながら段階的に公開している⁷。10万エピソード規模のデータセットはv2の1エピソード1ファイルでも配られてきたが⁸、設計側が見込むのはその先の数百万である。

何を失うか：外のツールが区切りを読めなくなる

代償は、ライブラリのAPIを通さずに読むツールの側に出る。ふつうのParquet読み出しでこの形式を扱うと、処理の途中で同じエピソードのフレームが散らばればエピソードの番号で集め直す作業と、区切りのメタデータを相対パスから自前で読み込む作業が読む側へ移る³。土台のParquet自体は「多くのプログラミング言語と分析ツールで対応されている」形式なので⁹、外のツールが対応していないのはファイル形式ではなく、区切りをメタデータに置く規約のほうである。

書く側も、記録の終わりを明示的に宣言する手順を負う。段階的にParquetへ書き出す変更が入り、メモリの消費は全フレーム数に比例する量からエピソードごとのフレーム数に比例する量へ減ったが、finalize()を呼ばなければファイルは不完全なまま残る¹⁰²。

区切りをファイルから外した分だけ、外部のツールは読み方を実装し直す必要がある。データ処理ライブラリDaftの場合、形式の公開（2025年9月）から対応まで9か月ほどで、その経過は公開の議論に残っている。DaftのGitHub上の議論に、社外の技術者がv3形式向けの読み出しを提案し、提案の中心を「DataFrameの一行がエピソード一つ分のデータに対応するようにし、あるエピソードに属するフレームのデータが散らばらないようにすること」と書いた³¹¹。議論に加わったLeRobotの開発者は、訓練ではエピソード単位ではなく単一フレームのバッチ単位でデータを読み込むため、フレームの読み出しが要になると書いていた³。Daftは議論の開始（2026年2月）からおよそ4か月後の2026年6月に、この議論におおむね基づく読み出しを実装し、8月にはv2系のレイアウトにも対応した。実装はエピソードのメタデータを1行1エピソードで、データを1行1フレームで返す。手作業だったメタデータの読み込みとフレームの遅延取得は、Daftの関数が行うようになった¹²。

一方で、LeRobot形式のデータで基盤モデルを微調整する学習用のソフトウェアには、まだv3を読まないものがある。NVIDIAのGR00Tは、多くの上流のデータセットがv2で公開されていることを理由にv2形式を使い続け、v3のデータセットはv2へ変換するよう文書で指示している。v2とv3の両方を直接読む対応は、今後の版で予定するとしている¹³。Physical Intelligenceのopenpiは、v3の公開より前のlerobotのコミットに固定したままである¹⁴。

これらのソフトウェアが読むデータの側では、同じデータが二つの形式で並んでいる。LeRobotの組織が配るDROIDは形式の発表より前の2025年7月からv3.0だが、1エピソード1ファイルのv2.1の版も別の名前空間に残っている⁸。v3の公開後に出たデータにもv2系のものがあり、2026年3月にHubへ置かれたAgiBot World 2026は1エピソード1ファイルのv2.1形式である¹⁵。Daftが8月にv2系へ対応したのも、こうしたv2系で配られ続ける多数のデータセットを読むためだった¹²。

どこへ向かうか：区切りはメタデータとAPIへ

大規模に配るデータは、区切りをメタデータに書き、エピソード単位の読み出しはライブラリのAPIを通す形へ進むと本稿は見る。1エピソード1ファイルのままでは数百万の規模でファイルシステムの限界に当たると設計した側は書き、連結してファイルの数を減らす道を選んだ⁵。データを出す側は10万エピソードをこの形で公開し、汎用の読み出しライブラリは追随した。L2Dの発表記事は設計側との共著だが、Daftの対応は社外の技術者の提案から始まっている。

速さの面で何を得たかは、公開された計測からは決まらない。著者の一人がコメント欄で示す追補が比べているのは、v3のストリーミング版と非ストリーミング版であり、v3とv2ではない⁵。

ほかのロボット学習データの形式を読むときも、ファイルの数と取り出す手順の比べ方がそのまま使える。問うのは二つである。一つのエピソードの区切りがファイルの境界に書かれているのか、別のメタデータに書かれているのか。後者なら、手持ちのツールがその区切りの表を読む規約を知っているか。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。