ヒューマノイドロボットのニュースは、動画だけで追うと見誤りやすい。
階段を上る。洗濯物を畳む。箱を運ぶ。映像は強い。フィジカルAIで見たいのは、1回できた動きより、失敗をどう集め、どう直し、どう全体へ戻すかだ。
2026年4月29日、Figureは Ramping Figure 03 Production を公開した。Figure 03の生産速度を1日1台から1時間1台へ引き上げ、第3世代ロボットを350台以上生産したという発表だ。
このニュースは、生産台数そのものより、ロボットを「学習データを生むfleet」として扱い始めた点が面白い。
Figureが出した数字
Figureの発表に出てくる主な数字は次の通り。
| 項目 | 発表値 |
|---|---|
| Figure 03の生産速度 | 1日1台から1時間1台 |
| 改善幅 | 120日未満で24倍 |
| 生産済みFigure 03 | 350台超 |
| BotQのworkstation | 150台超 |
| in-process inspection | 50点超 |
| end-of-line first pass yield | 80%超、改善中 |
| battery line first-pass yield | 99.3% |
| shipped battery packs | 500超 |
| actuators | 9,000超、10 SKU超 |
| sign-off前のfunctional verification | 80項目超 |
これはFigure自身の発表値だ。第三者が監査した稼働実績やタスク成功率とは分けて読む。
Figureは、量産、検査、fleet management、field service、OTA、Helixの学習を同じ発表の中でつないでいる。
fleet managementは、複数台のロボットの状態、場所、稼働時間、更新状態を管理する仕組みを指す。
OTAはover-the-air updateの略で、現場の機体へソフトウェア更新を配る仕組みだ。field serviceは現地保守を意味する。
ロボット企業がこの3つを語り始めると、話は研究デモから運用へ移る。
実機が増えると、珍しい失敗が見える
ロボットの学習は、現場で動かして初めて見える差に左右される。
床材、照明、摩耗、センサーのずれ、バッテリー残量、人間の動き、部品のばらつき、現場ごとの運用差。こうした要素は、綺麗なデモ環境では出にくい。
台数が少ないうちは、成功例が目立つ。台数が増えると、珍しい失敗が見えてくる。
Figureは今回、次の運用要素を挙げている。
- robust diagnostics
- fallback ladders
- long-tail failures
- field service management
- fleet-wide upgrades
- recall campaigns
- OTA software update infrastructure
robust diagnosticsは、故障原因を短時間で絞る仕組みだ。
fallback ladderは、異常時に性能を段階的に落として安全側へ戻す設計を指す。long-tail failuresは、頻出する不具合を潰した後に残る、低頻度で現場では避けにくい失敗群だ。
この並びは、ロボットを製品として運用する会社の言葉になっている。
VLAサーベイと同じ問題を見ている
2026年4月24日に、VLAサーベイ Vision-Language-Action in Robotics: A Survey of Datasets, Benchmarks, and Data Engines が出た。
この論文は、ロボティクスAIのボトルネックをデータ基盤として整理している。
VLAはVision-Language-Actionの略だ。画像や映像、言語指示、ロボットの行動をつないで扱うモデル群を指す。たとえば「赤いカップを取って」と言われたとき、視覚で対象を見つけ、言語指示を理解し、ロボットの動作へ変換する。
このサーベイは、今後の進歩がdatasets、benchmarks、data enginesの設計に強く依存すると整理している。
datasetは学習に使うデータの集まり。benchmarkは性能を比べるための評価条件。data engineは、実機、シミュレーション、動画再構成、自動タスク生成などを使い、学習と評価に必要なデータを継続的に作る仕組みだ。
Figureの発表とVLAサーベイを合わせると、追う数字が変わる。
| 確認する項目 | 理由 |
|---|---|
| 実機台数 | 失敗データの母数になる |
| fleet hours | どれだけ現場で動いたかを確認する |
| 失敗ログ | どの条件で失敗したかを確認する |
| 人間の介入ログ | 自律性が切れた場所を確認する |
| OTA履歴 | 修正を全台へ戻せるかを確認する |
| benchmark | 条件つきで進歩を比較する |
「何ができたか」に加えて、「失敗をどの形で保存し、次の訓練や検査へ戻しているか」を確認する。
Helix S0はなぜ出てくるのか
Figureは今回、HelixのSystem 0にperception-conditioned whole-body controlを追加したと説明している。
perception-conditionedは、カメラなどで見た外界の情報を条件として使うという意味だ。whole-body controlは、腕や脚だけでなく身体全体の動きをまとめて制御することを指す。
以前のS0は、関節状態や姿勢など、自分の身体内部の情報であるproprioceptionを中心にしていた。
新しいS0では、head cameraのRGB画像をstereo modelで3D表現へ変換し、それをpolicyへ渡す。policyは、観測から次の行動を決める制御モデルだ。
Figureは、シミュレーション上のrandomized terrainsで強化学習し、同じnetwork weightsを実機へzero-shotで移したと主張している。
zero-shotは、その実機環境専用の追加学習なしに動かすという意味だ。
確認する質問は、動画の見栄えから一段深い。
- どの地形で成功したか
- どの地形で失敗したか
- 照明や床材の違いにどこまで耐えるか
- 人間オペレーターの介入はどれだけあるか
- fallback ladderは安全に作動するか
- 失敗データは次の訓練へ戻るか
この質問に答えられる会社ほど、ロボットを増やしたときに強くなる。台数が増えるほど、データが増える。データが増えるほど、失敗の修正が進む。その修正をOTAで全台へ戻す。このループが回ると、ロボットは個別の機械からfleetへ変わる。
日本の製造業なら何を確認するか
日本企業は、産業ロボット、現場保守、品質管理、量産技術に強い。フィジカルAIの時代でも、この強みは残る。
足りなくなりやすいのは、現場の失敗をAIの学習資産として扱う設計だ。
確認する問いは、ヒューマノイドを作るかどうかに限らない。
- 設備やロボットの失敗を、センサー、行動、環境条件つきで保存しているか
- 人間が介入した瞬間を、後から学習に使える形で残しているか
- 品質検査のデータが、モデル改善や制御改善へつながっているか
- OTAやfleet-wide updateで修正を戻せるか
- シミュレーションで作った制御を、どの条件なら実機へ移せるか
フィジカルAIの競争は、モデル名の競争から、失敗を集めて直す運用基盤の競争へ移っていく。Figure 03の量産ニュースは、その変化を見るための材料になる。
次に見る数字
Figure 03の発表を「ヒューマノイドが量産された」というニュースで終わらせると、確認できない点が多い。
量産された実機がfleetになり、fleetが失敗データを生み、そのデータがHelixや制御系の改善へ戻るかを見る。VLAサーベイが指摘するデータ基盤の問題と、Figureが語るfleet運用は同じ方向を向いている。
フィジカルAIを追うなら、次に見る数字はfleet hours、失敗ログ、人間の介入率、OTA履歴、条件つきbenchmarkだ。