- Authors
- Name
- Youngju Kim
- @fjvbn20031
- はじめに
- ジェネラリスト方策とは
- 大規模ロボットデータ: Open X-Embodiment
- クロスエンボディメント: 異なる体を一つに
- VLAとの関係
- スケーリングの観点
- 課題: データ・安全・評価
- 配備と推論: 実機で動かす
- 安全を改めて見る
- 小さな事例で見る: 「テーブルの片付け」
- 展望
- 人の映像から学ぶ
- 評価のための努力
- 言語モデルとロボット方策: 何が同じで何が違うか
- ロボット基盤モデルをめぐる誤解
- オープンモデルの意味
- おわりに
- 参考資料
はじめに
言語モデルは、一つの大きなモデルが翻訳、要約、コーディング、対話をすべてこなします。画像モデルも一つのモデルが多様な画像を生み出します。このように「一つの大きなモデルが多くの仕事を幅広くこなす」基盤モデルの成功は、自然とロボットにも同じ問いを投げかけました。
ロボットにも基盤モデルは可能か? 一つの方策が複数のロボット、複数の作業を広くこなせるか?
伝統的なロボット学習は、おおむね「一つのロボット、一つの作業」に特化していました。コップをつかむ方策、ドアを開ける方策、引き出しを閉じる方策を別々に作り、ロボットが変わればゼロから学習し直す必要がありました。ロボット基盤モデルは、この壁を越え、一つの**ジェネラリスト方策(generalist policy)**で多くの状況を扱おうとする試みです。
本記事では、ジェネラリスト方策とは何か、それを可能にする大規模ロボットデータ(特にOpen X-Embodiment)、異なるロボットを一つで扱うクロスエンボディメント、視覚・言語・行動を一緒に扱うVLAとの関係、そしてスケーリングと残る課題を整理します。この分野は非常に速く変化するため、具体的な性能・構造は発表や世代によって異なることがある点を先に断っておきます。
ジェネラリスト方策とは
**方策(policy)**は、ロボットが観測を入力に受け行動を出力する関数です。カメラ画像と指示を見て、次に腕をどこへ動かすかを決めるものです。
従来のスペシャリスト方策は、特定の作業一つに最適化されます。よく働きますが、拡張性に欠けます。作業が100個なら方策も100個必要で、ロボットの種類が増えればその分だけ掛かります。
ジェネラリスト方策は違います。一つの方策が複数の作業と(場合によっては)複数のロボットを扱います。何をするかは主に言語指示で伝えます。
┌──────── スペシャリスト(作業ごとに別々) ────────┐
│ 方策 A: コップをつかむ │
│ 方策 B: ドアを開ける │
│ 方策 C: 引き出しを閉じる ... 作業数だけ増える │
└──────────────────────────────────────────────────┘
┌──────── ジェネラリスト(一つで) ─────────────────┐
│ │
│ 指示: 「赤いコップをつかんで引き出しに入れて」 │
│ 観測: カメラ画像 + ロボット状態 │
│ │ │
│ ▼ │
│ [ 一つの大きな方策 ] ──▶ 行動(腕・グリッパ目標) │
│ │
│ 同じ方策が数十〜数百の作業を処理しようとする │
└──────────────────────────────────────────────────┘
核心となる考えは言語モデルと同じです。規模(データ・モデル)を大きくし多様性を確保すれば、個々の作業をいちいちプログラムしなくても、一つの方策が幅広く汎化することを期待するのです。
大規模ロボットデータ: Open X-Embodiment
基盤モデルの燃料はデータです。言語モデルはインターネットの膨大なテキストを食べて育ちました。ところがロボットデータはインターネットに転がっていません。実際のロボットが物をつかんで運ぶ実演データは、いちいち人が集めなければならず、ロボットごとに形式がまちまちです。
この問題への重要な試みがOpen X-Embodiment(arXiv 2310.08864)です。複数の研究機関がそれぞれ持つロボットデータセットを一つの共通形式に集め、多数のロボットと作業をまたぐ大規模なデータの集まりを作りました。
複数機関・複数ロボットのデータセット
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ロボットA│ │ロボットB│ │ロボットC│ │ ... │
│ データ │ │ データ │ │ データ │ │ │
└───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘
└──────────┴──────────┴──────────┘
│ 共通形式に統合
▼
┌──────────────────────────────┐
│ Open X-Embodiment データ │
│ (多様なロボット・作業の軌道集) │
└──────────────┬───────────────┘
│ この上で一つの方策を学習
▼
複数のロボットを扱うジェネラリスト方策
このデータの上で学習した方策(例: RT-X系)は、複数のロボットのデータを一緒に学習したとき、個々のロボットだけで学習したものよりよく汎化する傾向を見せました。異なるロボットの経験が互いに役立ちうるという信号です。
データの三つの種類
ロボット方策を学習するデータは、どこから来るかによって性格が大きく異なります。
| 出所 | 長所 | 短所 |
|---|---|---|
| 実機の遠隔操縦 | 本物の物理、本物の接触 | 収集が高価で遅い |
| シミュレーション | 大量・安価・安全 | sim2realの隔たり |
| 人の映像 | 膨大で多様 | ロボットの体と不一致 |
実務ではこの三つを組み合わせます。シミュレーションで基礎を大量に身につけ、実機データで現実の隙間を埋め、人の映像から幅広い常識を得るという具合です。どれか一つだけでは十分でないため、データをどう混ぜるかが実戦の核心的な設計問題です。
データの多様性の重要性
基盤モデルの汎化は、データの量と同じくらい多様性に左右されます。同じ物体を同じ環境で百万回つかむデータより、多様な物体を多様な環境でつかむデータの方が、はるかに幅広い方策を作ります。
狭いデータ 広いデータ
┌───────────────┐ ┌───────────────┐
│ コップ · 明るい部屋│ │ コップ·瓶·工具·布 │
│ 一つのロボット │ │ 複数のロボット·照明│
└───────────────┘ │ 多様な背景 │
│ └───────────────┘
▼ │
見たものだけ得意 ▼
(見慣れない状況に弱い) 見慣れない状況にも汎化の可能性 ↑
これがOpen X-Embodimentのような努力が重要な理由です。一つの研究室のデータだけでは多様性が足りませんが、複数の機関のデータを集めれば、物体・環境・ロボットの多様性が大きく増えます。多様性こそ汎化の燃料です。
なぜ一緒に学習が役立つのか
直観的には「ロボットごとに体が違うのに、データを混ぜるとかえって混乱しないか?」と思えます。しかし実際には一緒に学習が役立つ場合が多いです。理由は、異なるロボットが共有する共通構造にあります。
ロボットAの経験 ロボットBの経験 ロボットCの経験
「物をつかむ」 「物をつかむ」 「物をつかむ」
│ │ │
└────────┬────────┴────────┬────────┘
▼ ▼
共有される「つかむ」の本質(接近・把持・持ち上げ)
│
▼
どれか一つのロボットのデータが足りなくても
他のロボットの経験でその概念を補強
物体をつかみ、運び、置く課題の本質は、体が違ってもかなりの部分が共有されます。だから一つのロボットで多く見た状況を、別のロボットが少なく見ていても、共有された概念で埋められます。これが大規模・多様なデータを一緒に学習する基盤アプローチが個別学習に勝る根本的な理由です。
クロスエンボディメント: 異なる体を一つに
**クロスエンボディメント(cross-embodiment)**は、異なる「体(embodiment)」を持つロボットたちを一つの方策で扱うことを指します。腕が一つのロボット、二つのロボット、グリッパの異なるロボット、関節数の異なるロボット — これらは物理的に異なりますが、「物をつかんで運ぶ」という課題の本質は共有します。
クロスエンボディメントの難しさは明白です。
- 行動空間が異なる: ロボットごとに関節数と制御方式が異なり、同じ「行動」でも表現が違います。
- 観測が異なる: カメラの位置、数、視野がまちまちです。
- 物理が異なる: 腕の長さ、力、速度が異なります。
これを扱う一つの方法は、行動と観測をできるだけ共通の抽象表現にそろえることです。たとえばグリッパ先端の目標位置・方向のように、複数のロボットに共通する表現で方策を定義すれば、各ロボットの具体的な関節命令は裏で変換できます。
共通方策 (抽象行動: グリッパ目標の位置・姿勢)
│
┌────┴──────────────┬──────────────────┐
▼ ▼ ▼
ロボットA用変換 ロボットB用変換 ロボットC用変換
(関節命令) (関節命令) (関節命令)
│ │ │
▼ ▼ ▼
実機ロボットA 実機ロボットB 実機ロボットC
こうすれば、一つの方策が学習した「概念的な技能」を複数のロボットが分け合えて、あるロボットで得たデータが別のロボットの性能も引き上げられます。
VLAとの関係
ロボット基盤モデルの話で欠かせないのが**VLA(Vision-Language-Action)**モデルです。VLAは視覚(カメラ)と言語(指示)を入力に受け行動を出力する方策で、言語・ビジョンモデルの成果をロボット行動へつなぎます。
- RT-2(Google DeepMind, arXiv 2307.15818): すでにウェブデータで学習された視覚言語モデル(VLM)をロボットデータでファインチューニングします。行動を離散化(discretized action)されたトークンとして扱い、言語モデルの出力方式と統合しました。ウェブの視覚・言語の知識がロボット行動へ転移しうる点が印象的です。
- OpenVLA(arXiv 2406.09246): 約97万件の実ロボット実演で学習した7B規模のオープンVLAモデルです。DINOv2・SigLIPの視覚エンコーダとLlama 2言語モデルを組み合わせ、オープンモデルなので研究・再現に大きく役立ちます。
- π0(Physical Intelligence): フローマッチング/拡散方式で連続的な高周波の行動を生成し、離散化トークンとは異なる方向から精密な操作を狙います。
- GR00T N1(NVIDIA): 速い反応のSystem 1(拡散系)と計画のSystem 2を組み合わせた二重構造を掲げます。
- Helix(Figure AI): ヒューマノイドを狙った汎化VLAの流れの事例として言及されます。
ここでよく使われる技法がco-fine-tuningです。ウェブの視覚言語データとロボット軌道データを一緒に学習し、ウェブから得た幅広い常識とロボットの具体的な操作能力を一つのモデルに収めようとします。また、LoRAのような効率的なファインチューニング技法で、大きなモデルを少ないコストで特定のロボット・作業に適応させる方法も一緒に使われます。
行動をどう表現するか
VLAモデルの核心的な設計判断の一つは「行動をどんな形で出力するか」です。大きく二つの筋があります。
- 離散化(discretized)行動: 行動空間を複数の区画に分け、言語モデルが単語を選ぶように行動トークンを一つずつ選びます。RT-2が代表的です。言語モデルの構造をそのまま再利用できるという大きな利点があります。
- 連続(continuous)行動: 行動を実数値で直接生成します。π0のようにフローマッチング/拡散を使えば、滑らかで高周波の精密な動きを作れます。
離散化方式(RT-2系)
行動 = [トークン1][トークン2][トークン3]... ← 言語モデルのように一つずつ選択
│ 単純・再利用しやすい、ただし解像度が区画数に制限される
連続方式(π0系)
行動 = 実数ベクトルを拡散/フローで生成
│ 滑らかで精密、ただし学習・推論がより複雑
どちらが良いかは課題によります。粗いピックアンドプレースには離散化でも十分ですが、精密な組立や柔軟な動きには連続行動が有利な傾向があります。これは依然として活発に探究される設計空間です。
VLAの内部構造
典型的なVLAは、おおよそ次の部品から成ります。
カメラ画像 ──▶ [ビジョンエンコーダ] ──┐
├──▶ [言語・融合バックボーン] ──▶ [行動ヘッド] ──▶ 行動
言語指示 ──────▶ [テキストエンコーダ] ─┘
(ロボット状態) ────────────────────────┘
· ビジョンエンコーダ: DINOv2·SigLIPなど (画像を特徴へ)
· バックボーン: Llama系など大型言語モデル (視覚・言語の融合・推論)
· 行動ヘッド: 離散トークンまたは連続行動を生成
OpenVLAがDINOv2·SigLIPのビジョンエンコーダとLlama 2を組み合わせたと先に述べたのが、まさにこの構造です。ウェブで事前学習された強力なビジョン・言語の部品を持ってきて、その上にロボット行動を出すヘッドを付け、ロボットデータで学習します。事前学習された部品のおかげで、ロボットデータが相対的に少なくてもウェブの知識を活用できます。
スケーリングの観点
言語モデルの教訓の一つは、「規模を大きくすれば能力が予想以上に幅広く向上する」ということでした。ロボット基盤モデルも同じ期待を抱いています。
データ規模・多様性 ↑ モデル規模 ↑
│ │
└───────────┬───────────┘
▼
より広い作業・ロボットへの汎化(期待)
│
┌───────────┴───────────┐
▼ ▼
見たことのない物体にも対応 指示だけ変えて新作業を実行
(期待であり保証ではない) (期待であり保証ではない)
ただし言語とロボットの間には決定的な違いがあります。テキストはインターネットに事実上無限にありますが、ロボットデータは物理世界で実際に体を動かして集めなければなりません。データ収集の費用がはるかに大きく遅いです。そこでシミュレーションデータの活用、人の映像からの学習、データ効率のよい方法などが、スケーリングを補完する方向で活発に研究されています。スケーリングがロボットでも言語ほど滑らかに通用するかは、まだ開かれた問いです。
言語モデルの教訓、そして限界
言語モデルで観測されたスケーリング法則(データ・モデル・計算を大きくすれば損失が予測可能に減少する)は、ロボットにも示唆を与えます。しかしいくつかの理由で、そのまま移るとは限りません。
- データのボトルネック: ロボットデータは物理的に集める必要があり、テキストのように無限に増やしにくいです。
- 評価の曖昧さ: 言語には次トークン予測という綺麗な目標がありますが、ロボットの「成功」は定義が複雑です。
- 物理的制約: どれほど良い方策でも、ハードウェアの物理限界を超えられません。
それでも方向性は有効です。より多く多様なデータ、より大きなモデル、より良い学習方法がロボット方策の汎化を広げる傾向は、複数の研究で観測されます。ただし「どれほど、どのように」通用するかは、言語ほど綺麗に整理されていません。
課題: データ・安全・評価
ロボット基盤モデルは、約束と同じくらい課題も大きいです。
データ
先に述べたように、ロボットデータは集めるのが高価です。実際のロボットを人が遠隔操縦したり実演でデータを積み上げたりする必要があり、多様性(複数の物体・環境・ロボット)を確保するのが特に難しいです。シミュレーションが助けになりますが、sim2realの隔たりという代償が伴います。
安全
物理世界で実際に動くロボットは、間違えれば物を壊したり人を傷つけたりしかねません。言語モデルが誤った文を出すことと、ロボットが誤った力で動くことは、危険の性質が異なります。だから力・速度の制限、非常停止、接触安全の設計が、方策そのものと一緒に必ず考慮されなければなりません。
評価
「この方策がどれほど良いか」を公正に測ることも難しいです。言語モデルのように決まったベンチマークで点をつけにくく、実機ロボットの実験は再現が厄介です。標準化された作業セット、成功率の定義、再現可能な評価プロトコルを作ることが、この分野の成熟に非常に重要です。
┌──────── ロボット基盤モデルの三つの課題 ────────┐
│ │
│ データ ──▶ 高価で遅い収集、多様性確保が困難 │
│ 安全 ──▶ 物理的危険、力・接触・非常停止の設計│
│ 評価 ──▶ 再現が難しい、標準ベンチマーク未成熟│
│ │
│ この三つをともに解いてこそ実用的な汎化に到達 │
└──────────────────────────────────────────────────┘
配備と推論: 実機で動かす
大きな基盤モデルを実際のロボットで動かすには、現実的な制約が伴います。ロボットはリアルタイムで動かなければならないため、モデルがどれほど賢くても推論が遅ければ意味がありません。
┌──────────── 実機配備の制約 ────────────┐
│ │
│ リアルタイム性 ──▶ モデルが制御周期内に応答│
│ 計算資源 ──▶ ロボットに載る計算機の限界 │
│ 遅延 ──▶ 観測→行動の遅延が小さいほど安定│
│ 安全 ──▶ 異常出力への防御が必要 │
│ │
└──────────────────────────────────────────┘
そのため実務では複数の折衷が使われます。大きなモデルを蒸留(distillation)して小さく速いモデルにしたり、遅い高レベル計画と速い低レベル実行を分離したり(先に見た階層構造)、量子化でモデルを軽量化したりします。GR00T N1が掲げるSystem 1/System 2の構造も、この文脈で理解できます。速い反応が必要な部分と、遅い計画が必要な部分を分離するのです。
安全を改めて見る
ロボット基盤モデルの安全は、言語モデルの安全とは質的に異なります。言語モデルの誤った出力はテキストですが、ロボットの誤った出力は物理的な動きです。
- 出力の検証: 方策が出した行動が物理的に安全な範囲か(速度・力・関節限界)を実行前に検査します。
- 非常停止: いつでも人がロボットを即座に止められなければなりません。
- 接触安全: 人や物体との接触で過度な力が出ないよう、ハードウェア・ソフトウェアがともに防ぎます。
- 分布外の認識: 学習で見たことのない見慣れない状況に出会えば、無理に行動するより止まるか助けを求める方が安全です。
核心は、方策の知能だけで安全を保証できないという点です。方策の上・下に別途の安全層を置き、方策が誤っても物理的被害につながらないようにする二重の安全網が必要です。
小さな事例で見る: 「テーブルの片付け」
抽象的な話を一つの絵に絞ってみます。「テーブルの上の物を片付けて」という指示を、ジェネラリスト方策がどう扱うか想像してみます。
指示: 「テーブルを片付けて」
│
▼
[基盤方策が場面を理解]
│ コップ·皿·スプーンを認識、それぞれの目的地を推論
▼
逐次実行:
コップをつかみ ──▶ シンクへ (触覚で把持を維持)
皿をつかみ ──▶ 定めた位置へ (滑りを監視)
スプーンをまとめ ──▶ 入れ物へ (精密な操作)
│
▼
場面を再確認 ──▶ 残った物があれば繰り返す
ここに基盤モデルの力が現れます。「片付ける」という抽象的な言語指示を、具体的な物体と目的地に解きほぐす常識はウェブデータから来ます。そして各物体を実際につかんで運ぶ操作能力はロボットデータから来ます。この二つの結合が、ジェネラリスト方策が目指す絵です。ただしこれは理想的なシナリオであり、実際にこの水準の信頼性に到達することは依然として難しい課題です。
展望
ロボット基盤モデルはまだ初期です。しかし方向は明確です。大規模・多様なデータを共通形式に集め、クロスエンボディメントで複数のロボットの経験を共有し、VLAで言語・ビジョンの成果を行動へつなぐ流れは、ますます強くなっています。
近い未来の現実的な絵は、おそらく「完全な万能ロボット」よりも、広く汎化しつつ特定の作業には少量のデータで素早く適応する方策でしょう。ウェブの知識で広い常識を備え、ロボットデータで操作を身につけ、新しい現場では少しの実演で微調整する、という具合です。その組み合わせが、実用性と汎化の間の現実的な均衡点に近いです。
人の映像から学ぶ
ロボットデータが貴重なら、インターネットにあふれる人の映像を活用できないでしょうか。人が料理し、組み立て、物を扱う映像は膨大です。この映像から操作の知識を取り出せれば、データのボトルネックを大きく緩和できます。
人の映像(膨大) ──▶ 「何をどうするか」の知識
│
▼ ロボットの体へ移す橋(bridge)が必要
│
ロボット実行データ(少量) ──▶ 体の違いを埋める補正
│
▼
人の幅広い知識 + ロボットの具体的な実行
難しさは明確です。人の手とロボットのグリッパは異なり、映像には力の情報がなく、視点もロボットとは違います。だから人の映像をそのまま方策として使うことはできず、「何をするか」の上位知識を取り出してロボットデータと結合するアプローチが研究されます。人の映像はデータのボトルネックの有望な突破口ですが、体の違いを埋めることは依然として開かれた問題です。
評価のための努力
先ほど評価が難しいと述べました。これを改善しようとする方向を、もう少し具体的に見ます。
- 標準課題セット: 複数のロボット・環境で共通に使える課題の集まりを定義します。
- 成功基準の明確化: 「成功」が何か(例: 物体が目的地に置かれたか)を曖昧でなく規定します。
- 再現可能なプロトコル: 照明・物体・初期配置まで記録し、他のチームが同じ条件を再現できるようにします。
- シミュレーションのベンチマーク: 実機実験の再現負担を減らすため、標準化されたシミュ環境での評価も併せて行います。
こうした共用の評価基盤が整えば、「我々のモデルが優れている」という主張を公正に検証できるようになります。視覚・言語の分野がベンチマークのおかげで速く発展したように、ロボットでも評価の標準化が成熟の鍵です。
言語モデルとロボット方策: 何が同じで何が違うか
ロボット基盤モデルは言語モデルのアイデアを借りましたが、重要な違いがあります。これを一つの表に整理します。
| 観点 | 言語モデル | ロボット基盤モデル |
|---|---|---|
| データ | ウェブに事実上無限 | 物理世界で苦労して収集 |
| 出力 | テキスト(無害) | 物理的な動き(危険の可能性) |
| 評価 | ベンチマークで比較的明確 | 標準・再現が難しい |
| 誤りの代償 | 誤った文 | 物の損傷・安全の危険 |
| フィードバック | 次トークン予測 | 物理的な成功/失敗 |
これらの違いのため、言語モデルの成功の公式をロボットにそのまま複写することはできません。それでも「大規模・多様なデータで一つの大きなモデルを学習し、幅広く汎化する」という核心的な哲学は、ロボットでも有効な方向に見えます。違いを理解し、ロボットに合わせて調整することが、この分野の課題です。
ロボット基盤モデルをめぐる誤解
速く発展する分野だけに、誇張と誤解も多いです。いくつかを押さえて均衡を取ります。
- 「まもなく万能ロボットが来る」: デモは印象的ですが、見慣れない環境・物体への信頼できる汎化は依然として難しいです。
- 「データを増やせばよい」: 量だけでなく多様性と品質が重要で、データ収集そのものが大きなボトルネックです。
- 「シミュレーションで十分」: シミュレーションは強力ですが、sim2realの隔たりが残り、実機データが依然として必要です。
- 「一つのモデルがすべてのロボットを代替する」: 現実的には、広く汎化しつつ現場で少量のデータで適応する形が有力です。
技術を正確に理解するには、印象的なデモと堅牢な実用性の間の距離を冷静に見る視点が必要です。
オープンモデルの意味
OpenVLAがオープンモデルであるという点は、この分野に特別な意味を持ちます。言語モデルの分野でオープンモデルが研究・再現・応用を大きく加速したように、ロボットでもオープンな方策とオープンなデータは発展の触媒です。
オープンデータ(Open X-Embodiment) + オープンモデル(OpenVLA)
│
▼
誰でも再現・検証・改善が可能
│
▼
研究コミュニティ全体の発展を加速
ロボットデータの収集が高価なだけに、データとモデルを共有する文化は特に貴重です。一つの機関がすべてを独りでやるより、データを集めモデルを共有してともに発展する方式が、この分野を速く成熟させてきました。もちろん商用・非公開の流れも強く存在し、二つの流れは互いを刺激しながら進みます。
オープンとクローズドのどちらが優勢になるかを断言するのは早計です。言語モデルの分野でも両者が併存し、互いに競い合いながら全体を押し上げてきました。ロボットでも同じように、公開された共通基盤が研究を底上げし、その上で各社が独自の工夫を積み重ねる、という構図が続く可能性が高いです。重要なのは、どちらの流れも「大規模で多様なデータをどう集め、どう活かすか」という同じ根本の問いに向き合っているという点です。
おわりに
「一つの方策で多くの仕事を」という目標は、ロボット工学に言語モデル式の思考をもたらしました。ジェネラリスト方策、大規模データ、クロスエンボディメント、VLAは、その流れの核心となる部品です。データ・安全・評価という三つの課題は依然として大きいですが、その壁を少しずつ低くしていく過程が、まさにこの分野の現在です。
いつか一つのロボット方策が、一つの言語モデルがそうであるように、私たちが言葉で頼むことを幅広くこなす日 — その方向へ、研究は着実に進んでいます。
参考資料
- Open X-Embodiment (arXiv): https://arxiv.org/abs/2310.08864
- RT-2: Vision-Language-Action Models (arXiv): https://arxiv.org/abs/2307.15818
- OpenVLA: An Open-Source Vision-Language-Action Model (arXiv): https://arxiv.org/abs/2406.09246
- LoRA: Low-Rank Adaptation (arXiv): https://arxiv.org/abs/2106.09685
- Physical Intelligence (π0): https://www.physicalintelligence.company/
- Google DeepMind Robotics: https://deepmind.google/discover/blog/
- NVIDIA Isaac / GR00T の文脈: https://developer.nvidia.com/isaac
- Hacker News (ロボット基盤モデルの議論): https://news.ycombinator.com/