PhysEvoというロボット研究は、モデルには手をつけないことにした。ロボットを操作するモデル(本記事ではAstraと呼ぶ)は、学習で得た内部の設定値、すなわち重みまで丸ごと凍結しておく。その代わり、モデルとロボットアームのあいだに挟まったシステムだけを、失敗の記録を読んで自ら作り直す。
結果から見よう。まったく同じモデルの同じ能力を三つの方式で組み立て、同じ課題10個に当てた。ロボットを直接操作させると成功率26%。行動だけを専任させるよう別に学習させた方策に任せると48%。経験で直したその中間システムを経由させると68%だった。モデルは一文字も変えていないのに、この方式が最も高かった。
先に一本の線を引いておこう。この68%は「課題ごとに別々に育てて固定したバージョン」の成績だ。どんな仕事でもすぐ任せられる汎用ロボットを一つ作ったわけではない。何を実証し、何は実証していないのか——この区別が記事の最後まで重要になる。
その「中間システム」を、論文はハーネス(harness)と呼ぶ。モデルの命令を実際のロボット動作へと移し替える層だ。熟練した料理人が不慣れな助手に渡す「食材の下処理の手順」や「調理台の使い方のルール」のようなものだと考えればいい。料理の腕前(モデル)そのものではなく、その腕前が厨房で実際の一皿になって出てくるようにする手続きだ。
モデルを凍結したまま周辺だけを直すという発想自体が、まったく新しいわけではない。PhysEvoが違うのは、ロボットに命令を下す行動インターフェースはもちろん、「何がなぜ間違ったのかを覗き込む診断ツール」までを編集範囲に入れつつ、モデルただ一つだけは最後まで凍結したという点にある。
水を注いでいたロボットが、ふと止まる。手に持った瓶が手首のカメラを覆ってしまい、水がコップに入っているのか床にこぼれているのか見えないのだ。このロボットの頭脳は賢い。物体を分類する課題では100%正解する。目で見て判断することはほぼ完璧だ。ところが、手を使った瞬間に崩れる。
なぜよりによって、自分の目を塞ぐような姿勢が出てくるのか。ロボットに「あそこへ行け」と指示するとき、普通は指先が到達する目標地点を一つ指定するだけだ。これをTCP(ツール先端点制御)と呼ぶ。そこまでアームをどう折りたたんで持っていくかは、ロボットが自分で逆算する。この自動計算が逆運動学だ。問題は、目標点だけを指定した瞬間、「どんな姿勢で行くか」を選ぶ権限がまるごとその自動計算に渡ってしまう点にある。だから瓶がカメラを覆う中途半端な姿勢が出てきても、モデルには「関節をこう置け」と割り込む手段すらない。
だから著者らの診断は「モデルが愚かだから」ではない。ボトルネックは頭脳ではなく、その間のインターフェースにあった。同じやり方でもう一度試しても意味がない。必要なのは、使える視界を確保するか、姿勢を自分で選ぶ権限を取り戻すこと——インターフェースそのものを変えることだ。
ここがこの研究で最も不思議なところだ。失敗を防げなかったまさにそのモデルが、どうやってその失敗を直すのか。
答えは「いつ見るか」にある。行動を選ぶ瞬間にはなかった証拠が、すべて終わったあとで振り返るときには残っている。実行が終わると、モデルがどんな命令を下し、ロボットが実際にどう動いたかが、すべて記録として残る。その事後の記録を見れば、どこで足を滑らせたかを指摘できる。実際、水注ぎでは、この記録を見て「空いた腕で横から場面を見守れ」とスキルを一つ直したところ、次の試行が成功した。ここでいうスキルとは、ロボットが特定の状況でどう動くかを書き留めた指針のことだ。
権限を返した効果は、数字にも表れる。モデルもスキルも初期状態も予算もすべて同じにそろえ、三つの方式(指先目標のみ・関節を直接・両方)を二つの配置にわたって並べて比較した(合計6回)。指先目標だけを与える制御は平均40点、関節を直接選ばせた制御は100点だった。面白いのは、両方を使えるように開放したときが55点で、関節だけを与えたときよりむしろ低かった点だ。道具を多く握らせるのが得策ではない。「正しい権限」を与えることこそが肝心だ、という信号である。
そこでPhysEvoは、一つのモデルに二つの役割を交互に担わせる。一つは観察してロボットを操作する作業エージェント。もう一つは、その実行を分解して道具とスキルを直し、修正案を試して使えるものだけを残すメタエージェントだ。二つは同じモデルだが、与えられる文脈と手をつけられる道具が異なる。
同じ人間が、レース中はハンドルを握り、終われば整備士になって車に手を入れるようなものだ。運転の腕前(モデル)はそのままだが、車(ハーネス)はレースを重ねるほど良くなっていく。
境界ははっきりしている。メタエージェントが手をつけられるのは、行動・観察ツール、実行ロジック、スキル、さらには自身の診断ツールまでだ。逆に最後まで触れられないのは三つ——モデルの重み、ロボットが従う物理法則、そして課題を採点する基準である。
ループそのものは単純だ。実行し、記録を見て原因を仮説として立て、道具やスキルを直し、直したものを試し、通過したものだけを次の試行へ渡す。採択の基準は厳しい。動作が変わる修正なら、同じ課題・同じ初期場面で今のハーネスと並べて走らせ、点数が上がるか、少なくとも下がらずに、詰まっていた地点を越えたときだけ受け入れる。下がれば捨てる。道具を変えたら、その使い方まで一緒に直して渡す。そうしてこそ、次の番が新しい能力と使い方を一度に引き継げる。
ここにもう一枚ある。あるラウンドで作った道具が、まったく別のラウンドの修正を助けることもある。荷造りの課題がそうだった。メタエージェントは、前のラウンドで自分が作っておいたレビュー用ツールをふたたび取り出し、箱が押し出される現象を、その手前の衝突——立てておいた箱のフタが手首と挟持部にぶつかった瞬間——までさかのぼって追跡した。そして箱を回す前に、フタの上に余裕のある空間を確保せよとスキルを直した。車を直すだけにとどまらず、より良いレンチを作り、次の整備ではそのレンチを使うようなものだ。改善が複利で積み上がる。著者らが「物理的な再帰的自己改善」と呼ぶ核心がこれだ。
このスコアが本当の実力なのか、それとも開発中に見た問題の「過去問」を丸暗記した結果なのか、どうやって見分けたのか。
目標は公正な試験だ。だから採点に使う物体配置は、開発し修正するあいだ一度も見せなかった。初見の五つの配置を採点時にだけ取り出して一度ずつ走らせ、その結果を平均する。自己改善で作った修正案も開発中にだけ試し、この採点用の配置には手をつけない。課題ごとに「デプロイ版」を一つ固定したうえで、そのバージョンで五回を行う。さらに厳しく、採点の直前にセッション文脈と過去の画面記録、修正可能なメモリをすべて空にする。一回の試行のなかでその都度立て直すことは許すが、いったん固定した道具とスキルが採点の途中で変わることはないようにした。そうしてこそ、初見の状況でも通用する改善だけが点数に残る。
PhysEvoの成功率は62%だ。ただしこの62%は、42個の課題をそのまま平均した値ではなく、以下の五つの能力別成功率を同一の重みで平均した値である——42個の課題を同一の重みで平均すると58.57%になる。著者らが最も強い公開ベースラインとして挙げた相手(RoboDawn one-shot)の47.17%を、能力平均の基準で14.83%p 上回る。ただし、すべての能力で勝ったわけではない。自己改善は特定の能力に集中的に働いた。
| 能力 | 最も強いベースラインとの比較 |
|---|---|
| 記憶 | 大きく上回る(+46.67%p、スコア・成功率ともに満点) |
| オープンな指示の遂行 | 上回る(+17.50%p) |
| 精密さ | 上回る(+15.00%p) |
| 長期実行 | 互角 |
| 汎化 | やや劣る |
ここで「なぜ」を問うべきだ。よりによって「記憶」が満点をつけたのは、偶然には見えない。ここからは結果ではなく、その結果を読む解釈だ。失敗の記録を振り返ってスキルを直すというメカニズムそのものが、過去の失敗を文書として残し、次に参照させる営み——つまり「記憶」をシステムに植え込む過程だからだ。同じ論理で読めば、汎化が劣り(スコア51.08 対 55.08)、長期実行が足踏みなのも説明がつく。ハーネスの修正は、「この状況でこう失敗したから、こう直す」という局所的な修正に強い。初めて出会う型へ広げたり、長い段階を最後まで引っ張り切る力は、この方式だけでは大きくは伸びない。
インターフェースこそがボトルネックだという診断が、最も鮮明に浮かび上がる場がもう一つある。直接操作だけではなかなか終えられない、難しい操作課題8個だ。
| 難しい操作課題8個 | 成功率 |
|---|---|
| PhysEvo | 55.00% |
| Simate-beta | 50.83% |
| Liber-0 Preview | 46.44% |
| RoboDawn | 45.00% |
| 公式Astraベースライン | 1.25% |
同じモデルを直接操作だけさせた公式Astraベースラインは1.25%にとどまった。ハーネスを直したPhysEvoは55%。53.75%pの差だ。覆われた視界や折りたたまれた姿勢のようなインターフェースの問題が成否を分ける領域では、モデルではなくその周辺が道をふさいでいた、という診断が数字として最も大きく開く。もちろんこの中でも課題ごとのばらつきはある。全方位での優勢ではなく、特定の失敗の型に強い改善だ。
シミュレーションだけで通じる話でもない。進化させたハーネスを実際のロボットアーム(AgileX PiPER)に載せ、同じ実行-修正ループを続けた。5個の課題をそれぞれ5回ずつ、合わせて25回試行し、平均90.60点、成功率84%を記録した。ブロック積み・器の積み重ね・ペン置きは100%、水注ぎと「PhysEvo」の文字書きはそれぞれ60%だった(書字はスコア93)。注目すべきは、シミュレーションでは見えなかった現実の隙間を、同じループが埋めたという点だ。流れる水が前方へ寄る力でコップからあふれると、瓶の口をコップより少し後ろへ引くよう注ぎのスキルを直した。物体の位置も、形状計算だけで捉えていたものを、まずカメラでおおよそ近づいてから、近くであらためて測り直して微調整する順序に変えた。
良い数字がすべてではない。噛みしめておくべき限界が二つある。
第一に、冒頭で引いておいた線が、ここで本当に効いてくる。「初見の物体配置」に対する汎化は実証された。しかし、開発の過程なしに「初見の課題の型」をそのまま解く能力は、この実験が示したものではない。この二つは区別して読む必要がある。
第二に、この方式が回るためには、「同じ状況で二つのバージョンを並べて比較できる、信頼できる成果の信号」が必ずなければならない。シミュレーターの採点器や実環境での課題ごとの成功基準が、その信号の役割を果たす。そうした信号を設計しにくい領域では、この方法をそのまま持ち込むのは難しい。評価そのものがロボット操作という物理的な領域に限定されている点も、あわせて覚えておこう。
そのまま真似できる研究ではない。これはロボット操作の話であり、ONTLEはソフトウェアのPMだ。持ち越せるのは設計パターンだけだ。一つの場面に当てはめてみよう。
顧客がプロジェクトの途中で、納期を前倒ししてほしいと要望する。AI PMエージェントがこれを受けてスケジュールを組み直し、連携したシステムへ変更を押し込む。問題は、実行が終わったあとになって初めて露わになる。見落としていた依存関係のせいで成果物が一つ食い違い、今は人間がそれに気づいて手で元に戻している。さらに悪いのは、同じ類いのミスが、次の顧客の納期変更でまた繰り返される点だ。
PhysEvoの処方をこの場面に当てると、こうなる。実行するPMと、終わったあとにログ・変更履歴・結果を読んで失敗を診断し、PMが使う道具とプレイブックを直す役割を分ける。そして直したものを、次のプロジェクトが引き継ぐようにする。PMが使うそのプレイブックとアクションツールこそが、冒頭で述べたハーネスのソフトウェア版だ。成果を、より賢いモデルからではなく、この中間層を直し・検証し・保存する規律から引き出すという点で、エージェントの振る舞いを共通規格へと狭め、サーバーがその実行を検証するように変えてきたONTLEの方向と重なる。
ただし、そのまま持ち込んではいけない点が一つある。PhysEvoは採点用の配置を修正から徹底的に外した。ONTLE流に移すと、アクションツールやプレイブックを自己改善で直すとき、その検証は開発用の事例だけで回し、実際に顧客が結果を受け入れる受け入れ基準はチューニングの対象から外すべきだ、ということになる。顧客の受け入れ基準に合わせて道具を削り始めると、その顧客の案件は通っても、初見の次のプロジェクトで通用する保証が消える。「点数が上がるか、少なくとも下がらないときだけ採択する」というルールは、そのままPMツール改善の基準として使える。
だからこの研究が残す一行は、こうだ。より賢い天才モデルを一つ待つよりも、失敗を記録として残して資産に積み上げ、その記録で自らの道具と手順を自ら直していくシステムを設計するほうが——少なくともONTLEが立つ場所では——より速い道になりうる。
本記事でのAstraは、論文が扱う「最後まで固定された単一の基盤モデル」を指す名前として読めば大丈夫です。要点はそのモデルの正体が何かではなく、凍結したまま周辺システムだけを変えるという設計にあります。
モデルは、関数を呼び出すように行動ツールと観察ツールを選んで使います。基本の制御は両腕に対応し、物体を握った状態でも使えます。観察ツールは、環境を進めないまま証拠だけを取ってきたり、形状を計算したりします。実行器は実際のアクチュエータの物理的な限界を強制し、ロボットが命令どおりに動いたかを点検します。
直訳すると「Astraは行動できる、だからそうさせよ」です。モデルにはすでにロボットを操作する能力があり、信頼できる操作を阻んでいるのはモデルではなく、その行動が通り抜けるシステムのほうだ——という主張を凝縮したタイトルです。そのシステムを自ら直して使わせることで、「行動させよ」を実現する、という意味に読み取れます。