1. 配置が少し変わるだけで、ロボットは失敗する

視覚・言語・行動を一体で扱う VLA モデルや、世界モデルと行動を組み合わせた WAM モデルは、カメラの観測と言葉の指示から、ロボットの動作を直接出力する。この直接さが、方策を学習時の条件に縛りつける、と著者らは指摘する。物の配置や視点がわずかに変わるだけで失敗し、指示の言い回しが変わるとうまく一般化しない。

著者らはその根本原因を表現の問題に求めている。課題の要件、前提となる条件、どこまで進んだか、失敗したときにどう立て直すか。これらがすべて動作の系列の中に暗黙に埋め込まれているため、人が中身を確かめることも、直すことも難しい。一次情報は arXiv に公開されたプレプリントであり、査読は経ていない。[1]

2. 提案の芯は、課題の状態と実行を「コード」で表すこと

著者らが先例として挙げるのは、デジタルの世界のコーディングエージェントである。言語モデルが道具を呼び、結果を確かめ、フィードバックを受けて実行可能なコードとして直す。状態が明示され、実行が管理でき、手順を書き直せる。この働き方が、物理世界での一般化と長い作業の実行にも効くはずだ、というのが出発点である。

提案は Physical Coding と名づけられ、二つの面を持つ。Code as World は、物体、物体どうしの関係、制約、進み具合をコードとして記録する。Code as Policy は、計画、確認、立て直し、実行をコードとして組み立てる。これを実装したのが HexaAnything で、知覚・計画・制御の道具を呼び出し、その中には VLA や WAM の方策も含まれる。外部からのフィードバックを受けて、実行の途中で判断を下す。

確かめられた実行の記録は、データと記憶になる。著者らはこれを足がかりに、道具や周辺の仕組み（Harness）からモデルの重み、さらには構造、最終的にはハードウェアや課題の設計まで、段階的に進化させていく構想を示している。

動作系列に埋め込む方式（VLA・WAM）

観測と指示から動作を直接出力する。何を前提にし、どこまで進み、失敗したらどうするかは動作の中に暗黙に含まれていて、外から読めない。条件が変わると、どこを直せばよいかが分からない。

コードで表す方式（Physical Coding）

物体の位置、制約、進み具合をコードとして持ち、計画・確認・立て直しの手順もコードで書く。VLA や WAM は、その中で呼び出される道具の一つになる。条件が変わったら、該当する記述を直せる。

3. abstract の範囲で示されたこと

RoboCasa365 という評価環境では、HexaAnything が、比較対象の XR-1 という VLA モデルに比べて、未知の組み合わせ課題と全体の成功率を改善したと報告されている。さらに、周辺の仕組みで得た記録を使って学習させた HexaModel は、すべての区分で元のモデルを上回った。著者らはこれを、コードとして残った実行の記録が、物理的な実行の仕方をモデルの中に取り込ませた兆候だと解釈している。

PhyBench と、双腕の AgileX ロボットを使った評価では、エージェントが物理の実験を自律的にやり遂げ、卓上作業の大半を完了したとされる。公開済みの結果より速いことが多かったという。データ・モデル・道具のそれぞれで自己進化が観察された、とも述べている。

ここで注意したいのは、abstract には改善の幅を示す数値が一つも書かれていないことである。「改善した」「上回った」「大半」「速いことが多い」は、いずれも程度を示さない言葉であり、この記事でも程度は補わない。

4. 具体例で見る ── 試験室で試料を並べ替える作業

品質管理の試験室で、ロボットが試料の容器を所定の位置に並べ替える作業を想定する。ある日、容器を載せる台の置き場所が、いつもと少しずれていた。

動作を直接出力する方策の場合

指示:「台の上の容器を、試験の順番どおりに並べて」
ロボット:（学習したときの台の位置を前提に腕を動かし、容器をつかみ損ねる）
担当者:何を前提に動いたのか、どこで判断を誤ったのかが、記録からは読み取れない。

状態と手順をコードで持つ場合

状態の記述:台の位置、各容器の識別、並べる順番、いまどこまで終わったか
確認:カメラで台の位置を測り直し、記述と違うことを検出する
立て直し:台の位置の記述を更新し、つかむ動作の目標を置き直してから再開する
担当者:どの記述が更新され、どの手順が再実行されたかを、コードと記録で追える。

後者でも、実際に腕を動かす部分には VLA のような方策が使われうる。違いは、前提と進み具合と立て直しの手順が、動作の外に書き出されている点にある。この書き出しがあるから、ずれを検出し、直し、何が起きたかを後から確かめられる。

5. 何が新しくないか、限界はどこか

言語モデルにロボットの手順をプログラムとして書かせる発想は、この論文が初めてではない。abstract 自身も、デジタルのコーディングエージェントを先例として挙げている。この論文の主張の重心は、個別の手法よりも、物理世界での実行の記録をコードとして蓄え、道具から重みへと段階的に取り込んでいく循環の全体像にある。

そのぶん、abstract で示された結果と、示された構想との間には距離がある。第一に、先に述べたとおり改善の程度を示す数値が abstract に無い。XR-1 との比較がどの条件で行われたか、公開済みの結果との速さの比較が同じ条件かどうかも、abstract の範囲では条件が示されていない。

第二に、「卓上作業の大半」の母数や、失敗した作業の内訳は書かれていない。現場への導入を考えるなら、成功した作業よりも、失敗した作業がどう失敗したかのほうが判断材料になる。

第三に、構造・言語・表現・課題の自律的な設計し直しや、製造と科学の現場への配備は、abstract の中で明示的に今後の課題とされている。これらは結果ではなく見通しである。

第四に、自分で書いたコードを自分で進化させるロボットを物理世界で動かすことには、ソフトウェアの世界とは違う危険がある。書き直されたコードをいつ誰が確かめるのか、その仕組みについて abstract は触れていない。

6. この主題が今なぜ束になっているか

同じ時期に、LEGO-Anything という論文が arXiv に出ている。題名から読み取れる範囲では、コーディングエージェントを三次元の場面の再構成に使う研究である。[2]画面の中で働いてきたコーディングエージェントを、物理世界や三次元空間へ持ち出す、という方向で二本が並んでいる。束の大きさは 2 である。

この論文は、論文共有の場で 99 件の支持票を集め、実装リポジトリには 45 件の star が付いている。[4][3]読み手の票、実装者の関心、別グループの論文という三つの動きが同時に立っていることが、今回取り上げた理由である。ただし、支持票や star の多さは、読む価値があると感じた人や使ってみたいと思った人の数であって、主張が正しいことの根拠にはならない。abstract に数値の裏づけが無い点は、注目度とは別に確かめる必要がある。

7. 製薬・規制の現場から見ると何が接続するか

製薬の試験室や製造現場では、機械の動作は決められた手順に従い、その手順はバリデーションで確かめられ、変更は変更管理の手続きを通る。この前提から見ると、Physical Coding には二つの面がある。

一つは、読める形で状態と手順を持つことの価値である。動作の系列に暗黙に埋め込まれた方策は、なぜその動きをしたのかを説明しにくい。状態と手順がコードとして書き出されていれば、何を前提に動いたか、どこで立て直したかを記録として残し、後から確かめられる。規制下の業務が求める「説明できること」「追跡できること」と、方向は合っている。

もう一つは、自己進化との相性の悪さである。確かめた記録から道具や手順を自分で更新していく、という循環は、手順を固定して検証し、変更のたびに承認を取る運用とそのままでは両立しない。書き換えられたコードのどこまでを人が確認し、どの時点で承認するのかを決めない限り、試験や製造の現場には持ち込めない。査読前の段階の研究として、ロボットの手順を「読める形」で持つことの意味を考える材料として読むのが妥当である。