GPT-6-Astraは、ロボットに「身体性知能」を問うたモデルだ。身体性知能とは、身体で周囲を感じ取り、自ら動いて仕事をやり遂げる能力を指す。この分野では課題ごとに専用モデルを個別に学習させるのが常識だったが、GPT-6-Astraは汎用モデル一つで前例のない成績を叩き出した。SenseNovaらが集まったJoint Research Teamは、このモデルを12のベンチマークで統一されたルールのもとに走らせて能力の上限を測り、8種の実機ロボットに載せて、その成績が現実にどれだけ転写されるかを確かめた。結果を一言でまとめると、試験環境で「解けるか」はおおむね通過したが、現場の時間・コスト・安全の制約のなかで「使えるか」はまだ、ということだ。研究陣は前者の閾を身体性能力(embodied competence)、後者の閾を実用的身体性知能(practical embodied intelligence)と呼ぶ。ロボットを作らなくても、汎用モデルを現実の作業に投入しようとする人なら同じギャップに出くわす — デモでは動くのに、現場では時間・コスト・検証が立ちはだかる。
ロボットに「カップを掛けろ」「布を畳め」といった仕事をさせるには、これまではロボットのデータでポリシー(policy、観測を受け取ってどんな行動をとるかを決める仕組み)を学習させるのが定石だった。VLA(ビジョン・言語・行動モデル)が代表例だ。こうしたポリシーも複数の課題に汎化できる — たとえばπ0.5は多様なデータをまとめて学習し、訓練時に見ていない家庭環境でも作業できるよう設計されたVLAだ。ただし新しいロボットや分布へ広げようとすると、たいていその分だけデータを集めて学習し直す必要があるという共通点がある。
GPT-6-Astraはこの前提を揺さぶる。重みに手を触れないまま、汎用モデル一つが卓上のロボットアームからヒューマノイド・移動プラットフォーム・精緻な多関節ハンドまで幅広く扱う。専用モデルを新たに学習させる代わりに、すでに賢いファウンデーションモデルの上に「どう走らせるか」を乗せる方式だ。そこで三つの問いがついて回る。このモデルの本当の上限はどこまでなのか? ベンチマークでの成功が実機ロボットへどれだけ転写されるのか? これだけの能力が出たのなら、これからのベンチマークは何を測るべきなのか? レポートはこの三つの問いを順に掘り下げる。
評価の核心をなす仕掛けは二つだ。
一つめは 文脈内学習(ICL、in-context learning) だ。重みを変えずに、参考資料をその都度入力(文脈)として差し込み、課題に適応させる方法である。既存の特化ポリシーが学習に使っていたまさにその実演データを、GPT-6-Astraはテストの前に見ておき、自ら「ナレッジパッケージ(knowledge package)」を一つ書き留める。新人にその業務の作業マニュアルを自分で作らせたうえで、現場ではそのマニュアルだけを参照させるのと同じだ。このパッケージはテストが始まる前に凍結され、その課題を一度ずつ遂行するすべてのエピソードに同じものが提供される。中身は大きく、課題の説明、動作の例(実演から抜き出した姿勢・動き)、再利用できる補助コード、失敗を点検して巻き戻す手順、といったところだ。何を入れるかはモデル自身が選ぶが、ベンチマークが違ってもこうした項目が共通して現れた、というのが著者らの観察だ。
二つめは 実行予算の拡張 だ。行動を一回とるのを1ステップとすると、各ベンチマークが定めた公式のステップ上限(標準予算、1×)に加えて、最大10倍(10×)までステップを許す。GPT-6-Astraは失敗した動作を自ら気づいて戦略を直し、やり直すのだが、きつすぎるステップ上限はその復旧が終わる前にエピソードを打ち切ってしまう。時間を多めに与えれば、失敗を正して成功へ向かう過程が完結する、という仮説だ。
一方、別のRoboDojo実験では、ハーネス(harness、モデルを実際に走らせる実行構造)を介した協業を切り離して試す。遅いが丁寧な System 2(GPT-6-Astra)が「何をするか」を決め、速い System 1 コントローラ(ここではRoboDojoにファインチューニングされたπ0.5)が「関節を実際にどう動かすか」を担う。核心は「閉ループ(close-loop)」協業だ。System 1が行動を提案するとSystem 2が検討・修正して実行し、その結果をまた観測して次の判断に反映する。提案 → 検討 → 実行 → 結果の観測 → 次の判断が一巡ずつ回る構造だ。ただしこの協業構造は評価全体の共通枠ではない — LIBERO系をはじめとする主要な結果は、このVLAコントローラをオフにしてGPT-6-Astraが直接制御した方式から出ている。
12の設定は性格に応じて五つの筋に束ねられる — 卓上操作、精緻なハンド操作、歩きながら物を扱うヒューマノイドのロコ・マニピュレーション、長い息の家事活動、指示に従って移動するビジョン・言語ナビゲーションだ。個別のベンチマーク名は下の表にまとめた。すべての評価でGPT-6-Astraの重みは固定される。
| 課題タイプ | 個別ベンチマーク |
|---|---|
| 卓上操作 | RoboDojo, RoboLab, LIBERO-Long++・LIBERO-Ultra-Long, LIBERO-PRO |
| 精緻なハンド操作 | Bench2Dex, DexJoCo |
| ヒューマノイド・ロコ・マニピュレーション | SIMPLE |
| 長期の家事活動 | BEHAVIOR |
| ビジョン・言語ナビゲーション | VLN-CE(R2R・RxR), LHPR-VLN |
評価ルールは「準備」と「テスト」を分ける。準備段階でICLのナレッジパッケージを作って凍結し、テストのエピソードは毎回新しいセッションで、課題の指示・凍結されたパッケージ・許された観測/行動のインターフェースだけを受け取って始める。一つのエピソード内の相互作用の記録は保持され、モデルがミスを診断して復旧を試みられるが、エピソード間では情報が持ち越されない。拡張予算はリセットではなく、同じエピソードを続ける方式なので、積み上がった結果(こぼした水、落とした部品)まで抱えたまま進む。
比較対象は各設定の最良の公開成績(SOTA)と最良の公開エージェント手法(Agentic SOTA)で、SOTAの基準日は2026年10月12日だ。この設計が測るのは「実演が与えられ、時間を十分に与えたときの能力の上限」である。逆に測れないものもはっきりしている。実演がないときの汎用性、そして推論にかかる実際の時間(遅延)はステップ予算に入らない。あとで見るように、この二つが現場で足を引っ張る。
ICLだけをオンにした標準(1×)予算でも、GPT-6-Astraはほとんどの設定で最良の公開成績に並ぶか上回り、LIBERO-Ultra-LongとDexJoCoでは最良の公開成功率をほぼ倍に引き上げた。
実演の効果。 SIMPLE実験はICLの効果を切り離して見せてくれる。共通の4課題で、課題レベルのICLは標準予算の成功率を70.8%から90.8%へ上げ、成功したエピソードの長さも縮めた。ただしこの利得は、学習データがテスト課題をどれだけ近く覆っているかに左右される。LIBERO系・SIMPLE・VLN-CEのように分布が近ければ飽和に近づくが、遠ざかると弱まる。
やり直しの効果。 予算を10×に増やすと、精密・両手操作が必要なRoboDojoで成功率がおよそ三倍になり、1×で終えられなかったエピソードの約四分の三が完了した(Bench2Dexも倍以上に上がった)。
時間を足しても解けない課題。 長期ナビゲーションのLHPR-VLNは拡張予算でもわずかな上昇にとどまり、全設定のなかで最低に居座った。時間を多く与えれば解ける問題と、構造的に解けない問題とに分かれる。
追加の試行がなぜある失敗には効いて、ある失敗には無力なのかは、RoboDojoのマグ掛けで露わになる。モデルはカメラでシーンを見て、取っ手とフックが重なって見える画面を「掛かった」という信号として読む。課題が終わっていないという信号が来れば姿勢を直すが、成功判定を最初から読み違えているため、同じ誤判断を繰り返す。ここまでがレポートに記録された観察だ。
ここから一つの解釈が導かれる(レポートの観察ではなく、筆者の推論である)。やり直しが復旧につながるには、三つがそろっていなければならない。第一に、失敗を識別できること — マグの事例のように成功判定がずれていれば、時間を足しても同じ失敗が積み上がるだけだ。第二に、正す行動が残っていること。第三に、修正できる状態が残っていること — すでに水をこぼしたり部品を落としたあとなら、巻き戻す余地がない。RoboDojoの精密グループがやり直しで復旧したのはこの三つがそろった場合であり、以下で見る三つの残存失敗は、この条件が一つずつ崩れる場合だ。
ICLと拡張予算を一緒にオンにした最終成功率は、課題の性格に応じてこう分かれる。
| 設定 | ICL + 拡張予算(10×)成功率 |
|---|---|
| LIBERO系 · SIMPLE | 95%超(飽和に近い) |
| VLN-CE | 約90% |
| DexJoCo | 87.3% |
| RoboDojo | 81.9% |
実機ロボット8種の検証は、タイトルの「現実」を直接突く。GPT-6-Astraは多様なロボットボディで動作したが、成功率は課題に大きく左右された。卓上グラスピング(物をつかむこと)はうまくこなした一方、布のような変形体の操作・精密な接触・長期課題は依然として難しかった。必要なシーンを見ようとカメラを自ら動かす能動視覚(active vision)を見せ、遅いSystem 2が高周波のロコモーションコントローラ(ここでは「System 0」と呼ぶ)と直接協業してヒューマノイド操作をやり遂げることもあった。しかし現実では、安全の制約・機械的な限界・リアルタイムの要求のために「ステップを多く使って成功率を買う」戦略が通じず、シミュレーションICLの前提だった成功実演も、収集が高くつくか、そもそも存在しない。
最大の制約はコストだ。著者らは消費トークンの約98%がキャッシュされた入力トークンだとして、「100万トークン ≈ 1ドル」を目安の規則として使う。問題はトークン代ではなく時間だ。標準予算で成功率がすでに97%を超えるLIBERO-Long++でさえ、エピソード一つに約100万トークンと、ほぼ一時間の推論・ツール使用がかかる。成功率が高くても、一件を終えるのに一時間近くかかるということだ。LIBERO-Ultra-Longは約900万トークンにほぼ二時間へ跳ね上がり、予算を拡張するとRoboDojoの一エピソードは平均で三時間を超える。
このコストはハーネス設計と直結している。閉ループ協業は単独実行や開ループよりも性能を大きく上げるが、System 2を頻繁に呼ぶほどトークンと時間が一緒に膨らむ。著者らは、より長い行動シーケンスを一度に検討するとこのトレードオフが改善し、閉ループとICLを合わせれば性能は最も高いがコストも最も大きい、と報告する。行動の表現の仕方も効いてくる。関節の角度を一つひとつ直接制御すると性能が落ち、アーム先端のハンド・グリッパ(エンドエフェクタ)に「何をするか」を意味の単位で指示するほうがよい。複数の動作をまとめて一度に検討する適応的な行動チャンキングは、性能を上げながら不要なモデル呼び出しを減らす。要するに、推論能力に見合った行動空間を開いてやりつつ精密な実行は下位コントローラに任せ、検討の頻度で正確さとコストを秤にかけるのが設計の核心だ。同じ頭脳でも、ハーネスをどう組むかが性能を左右する — 同じGPT-6-Astraを使う最新のエージェント手法(Agentic SOTA)さえ、この方式が上回る。
著者らが自ら認めた残存失敗は三つの筋があり、先の「やり直しの三条件」が一つずつ崩れる場所と噛み合う。
第一に、物理的な成功を検証できない。 課題が終わっていないことには気づいても、どの物理条件が合っていないのかを突き止められず、修正が収束しない。Bench2Dexのジグソーパズルで、四つのピースが正方形をなしたと報告しながら、エピソードが終わっていないのを見て間隔を調整し続け、かえってピースをまた広げてしまう。
第二に、取り返しのつかない失敗から復旧できない。 序盤に水をこぼしたり部品を落とすと、その事故が以降のサブタスクを丸ごと崩す。
第三に、長期課題で進行状態を保てない。 後の段階が依存する「開けておいた蓋」や「置いておいた物」といった進行が消えて、課題が詰まる。
転移にも限界がある。ICLパッケージはおおむね課題特化なので、出所の課題から遠ざかると利得が弱まる。専用の実演がないRoboDojo Openグループは、他グループで作ったパッケージに頼るが、追加の相互作用の恩恵は受けるものの、全グループのなかで成功率が最も低い。そもそも学習セットがないRoboLabでは、並べられたベースラインは上回るものの、絶対的な成功率は中程度にとどまる。
それなら、これからのベンチマークは何を測るべきか。レポートは三つの原則を提案する。
三つめが特に現実的な理由は、家事のプロトタイプで、モデルが自分で開けた冷蔵庫を忘れたり、考えているあいだに観測が古くなってしまう限界がそのまま露呈したからだ。
ONTLEは、小さな企業が人を雇えずに溜まっていく反復業務を引き受けて処理するAIエージェントを作り、その中心に課題を最後までやり遂げる「AI PM」を置く。一つの場面で見てみよう。AI PMがある小企業の「月末の取引先精算」を任された。取引先10社の請求書を集めて精算表を更新し、未収金が残っている先には案内メールの草案を上げて社長の承認を得る、という仕事だ。ロボットアームとはまるで違う仕事だが、この論文の長期課題と三つを共有する。複数のサブタスクを順に踏み(多段実行)、途中の状態を保ち(状態保存)、各段階が本当に終わったかを確認しなければならない(完了検証)という点だ。違いもはっきりしている。業務システムはロボットと違って記録を再照会でき、間違った修正を巻き戻すこともできるので、「こぼした水」がそこまで致命的ではない。
設計が分かれる地点は「完了検証」だ。モデルが「精算が完了しました」と報告しても、セルの値は間違っているかもしれない。この論文の一つめの残存課題である「物理的な成功の検証失敗」は、事務業務ではこの姿で現れる。だからAI PMの精算段階は、更新を終えたあとに精算表をもう一度読み込み、取引先ごとの元帳と合計を突き合わせ、ずれていれば完了へ進めない(実装済みの機能)。進行状態もモデルの記憶ではなく外部テーブルに記録し、各段階ごとに読み戻させて、「10社のうち7社まで処理して8社目で先の未収金の状態を忘れる」という失敗を構造で防ぐ(実装済みの機能)。新規の取引先が入ってきて会社専用の作業マニュアルが覆えないときに性能が落ちるかどうかは — ロボットのベンチマークで観察されたICLの限界にすぎず、我々の精算業務で確認された結果ではないので — 実データで検証すべき仮説として置く(設計の提案)。
まとめると、いま汎用モデルは「解ける」までは来た。その能力を信じられ(検証)、最後まで追跡でき(状態保存)、コストが合う(ハーネス)製品へ翻訳することが、AI PM設計のやる仕事だ。
精算の事例をあなたの製品に当てはめて、三つを点検してほしい。
いいえ。レポートは全評価でGPT-6-Astraの重みを固定したと明記しています。性能は重みの更新ではなく、文脈内学習(ICL) — 実演で作ったナレッジパッケージを文脈に差し込む方式 — と拡張された実行予算から出ています。