この論文の核心は、役割を分けたことにある。AI(コーディングエージェント)は開発段階でロボットを動かすコードを作り、ロボットは実行段階でそのコードをそのまま辿るだけだ。実行ループの中にニューラルネットワークは存在しない。代わりにカメラ映像と関節センサーから、ロボット・環境・課題の状態をコードで直接測定して変数に入れ、その変数だけを見てすべての動作をコードのロジックで決める。
これが成り立つには前提が一つ要る。物体の3次元形状、カメラ位置、ロボットの形、テーブルの高さといった値があらかじめ与えられ、変わらないことだ。ベンチマークはこれらの値を公開しているので、コードは「どの物体が今どこにあるか」だけを映像から突き止めればよい。
著者らはこの方式をCode-Only-as-Policy(COAP)と呼び、RoboDojoの両腕操作42課題で、実行時点にモデルなしで70.24%の成功率を報告した。
いまのロボット方策の主流は、「モデルを制御ループの中に居続けさせる」という前提を共有している。VLA(Vision-Language-Action、映像と言語を受け取って動作を出力するニューラルネットワーク)は、観測を動作へ直接マッピングする。エージェントハーネス(モデル呼び出しとツール実行を管理する構造)は、一瞬ごとに映像・言語モデル(VLM、映像と文章を一緒に理解するモデル)に「次に何をするか」を尋ねる。
この構造の不便さは、三つの箇所から同時に出てくる。第一に、モデルが何を見てその動作を選んだのかを覗き込めない。VLAの決定は重みの中に隠れており、ハーネスが使うモデルも推論テキストは見せてくれるが、実際の選択過程は制御できない。第二に、毎ステップごとにモデルを呼ぶので遅く高価であり、同じ入力でも呼び出しごとに結果にランダム性が混じる。第三に、新しい課題を学ぶにはデータを集め直して再学習する必要があるが、一つの課題を追加で教える過程で以前の課題の性能が削れること(いわゆる忘却)がよく起きる。
まずは単純な場面から見よう。カップを一つ掴む仕事だ。COAPは二つのものをコードに書いておく。一つは状態変数 — カップの位置と向き、両腕の関節角、今が何番目のステップか。もう一つは動作ルール — 「カップの位置へ腕先を動かす → グリッパーを閉じる → 持ち上げる」。実行するとき、ロボットは映像からカップの位置を読んで状態変数を埋め、ルールはその変数を見て次の動作を選ぶ。カップが別の場所に置かれてもルールはそのままだ。変わるのは変数の値だけである。
この区別がCOAPを他の方式と分ける。方策を「状態から動作へ向かう関数」とみなすと、この関数がどれだけ外に現れているかが要点になる。VLAは関数が重みの中に隠れている。エージェントハーネスは一部をテキストのメモリとして表に出すが、中核のモデルは依然としてブラックボックスだ。COAPは関数の全体をコードとして取り出す。状態はコードの変数に、ルールはコードのロジックに書く。どちらも目に見えるので、実行時点ではモデルが要らない。
著者らはこの構造をチューリングマシンになぞらえる。変わる状態は記号を書き留めるテープに、固定されたルールはテープを読み書きする機械の動作ルールに相当する。テープだけを差し替えれば、同じルールで新しい入力を処理できる — 物体の配置だけが変わった新しい状況で同じコードがそのまま回るのと同じだ。名前はEmbodied Turing Machine(身体化チューリングマシン)である。
状態は三つの部分に分かれ、課題が違っても形は同じだ。
知覚も特別なニューラルネットワークではなく、NumPy・OpenCVで書いたごく普通のコードだ。大きく三段階で動く。
カメラ位置、ロボットの形、物体の形状、テーブルの高さは、エピソードごとに変わらない定数、すなわちルールの一部だ。変わるのは「どの物体がどこにあるか」だけで、それが状態である。ミリメートル精度が必要な課題は、掴む直前に手首カメラでもう一度測定する。
すべての課題が同じ形の状態を使うため、一つの課題用に書いたモジュールを別の課題がそのまま持ってきて使える。コードは下方向にだけ依存する層構造だ。課題コードが物体別コードを呼び、それが掴む・置く・押す・注ぐといった操作コードを呼び、それがさらに知覚・モーションコードを呼ぶ。上層は「何を」(順序、課題ごとの判断、復帰条件)を決め、下層が「どうやって」を担う。その結果、新しい課題が回すコードの83%が共有ライブラリから来ることになる。
新しい課題がライブラリを広げる道は三つある。
三つめが重要な理由は互換性だ。新しい引数を渡さない既存の課題は、単体テストの入力範囲の中では実行の軌跡がそのまま保たれるよう条件を課す。ただしこの条件はテストした入力範囲に限られるので、拡張が既存の課題を絶対に壊さないと全面的に保証するものではない。設計の意図は、新しい引数を使う課題だけが変わるように範囲を狭めることにある。
コードで方策を書くという発想そのものは新しくない。論文が整理した流れと並べて置くと、違いが鮮明になる。Code-as-Policies・ProgPrompt・VoxPoser系は、モデルに知覚・制御APIを呼ぶコードを書かせる。PyRUA-Leanはエピソードが回っている最中にモデルが少しずつコードを書き、Skill2Realは決定のステップごとに、保存されたスキルから新しいプログラムを組み立てる。共通点は二つだ。モデルが実行中にプログラムを書くこと、そして状態は外部の学習済み知覚モデルが持ってくることである。
オフラインでプログラムを一度だけ書くRHO・EmbodiedSWEもあるが、ここでも状態はコードの外から来る(RHOは学習済み知覚モデルから、EmbodiedSWEはシミュレータが教える正解値から)。これらの知覚モデルはブラックボックスなので、その不確実性をコードが制御できない。
COAPの違いは、状態をコードが自ら測定するところにある。測定が間違っていればコーディングエージェントが測定コードを直し、その分だけ状態は時間とともに正確になる。ロボット側の自己改善研究であるRoboRSIは、複数の役割のエージェントのループに「性能が削れたら止める」ゲートを置くが、実行中の決定は依然としてモデルが下す。ゲートを通過した変更もブラックボックスを操るだけなので、テストした挙動と実際の実行の挙動がずれることがある。COAPは状態が明示的なコードなので「テストした挙動がそのまま実行の挙動」であり、ソフトウェアを直すように方策を直す。
ベンチマークはRoboDojoだ。42の両腕課題が五つの軸にまたがっている。記憶(Memory、6個)、精密(Precision、8個)、開かれた指示(Open instruction、8個)、汎化(Generalization、12個)、長期操作(Long-Horizon、8個)。各課題は50個のレイアウトを3つのシードで評価する。汎化課題はレイアウトの半分がランダム化され、新しい物体、新しい部屋・テーブルの外観、最大20個の邪魔物まで登場する。すべての数値は公式の評価クライアント・判定器・要約スクリプトで算出される。
方策が受け取る入力は、3つのRGBカメラ映像(頭1 + 両手首2)、関節角・エンドエフェクタ姿勢・グリッパー命令といった関節センサー値、そして指示文だ。成功率(SR)は課題全体が成功したエピソードの割合であり、スコア(Score)はベンチマークの進捗スコアだ。この設計が測るのは「方策が状態をどれだけうまく維持・測定し、それに合わせて行動するか」である。とりわけ記憶・精密課題が、状態維持と測定精度を直接狙っている。
ここで必ず区別すべき点がある。COAPのコードライブラリはオフラインで開発される。 Claude Opus 5.5コーディングエージェントが、人の介入なしに閉じた自己改善ループの中でコードを書き、デバッグする。「一つのエピソードでしか通用しない小細工は禁止」「テスト時点に正解の状態を参照するのは禁止」といった固定ルールの下で回る。開発にはベンチマークのテストセットを使わず、完成したコードはテストレイアウトを含むすべてのエピソードでそのまま実行される。
改善ループは四歩で回る。
この採択ルールは検証セットでの大きな性能低下をふるい落とし、改善をおおむね累積させる。ただし付録A.2が明かすように、回帰検査は大きな低下を排除するだけであり、すべての変化を防ぐわけではないので、各歩が性能をまったく下げないとまで保証するものではない。
表2でCOAPの全体成功率は70.24%、進捗スコアは75.45だ。比較対象のうち全体成功率が最も高かったベースラインは、エージェントハーネス系のPhysicalRSI(エージェント+VLA)で31.38%だった。両者の差は約38.9%ポイントだ。アブストラクトと本文が言う「state-of-the-art比38.9%」は、この全体成功率の差を指している。
次元別に見ると、成功率と「最高ベースラインとの差」は別の数字だ。二つを分けて書くとこうなる。
| 次元 | COAP成功率 | 最高ベースラインとの差 |
|---|---|---|
| 記憶(Memory) | 89.9 | +39.6 |
| 精密(Precision) | 75.1 | +41.6 |
| 開かれた指示(Open) | 64.1 | +33.1 |
| 汎化(Generalization) | 65.7 | +35.2 |
| 長期操作(Long-Horizon) | 56.4 | +13.0 |
注意すべき点。各行の「最高ベースライン」は行ごとに別の手法でありうる。一人の競合をあらゆる面で上回ったと一括りにしてはいけない。
実験が見せたのはこうだ。差が最も大きい次元は精密(+41.6)で、記憶(+39.6)がその次だ。記憶課題は「前で見た情報を後のステップまで持っていかなければ」解けない。COAPはその情報を課題の状態変数にそのまま書いておくので、前のステップの事実が次の決定まで消えない。逆に長期操作は差が+13.0で最も狭い。
ここで筆者の仮説を付け加えると、課題が長くなるほど測定誤差と復帰失敗が毎ステップ積み重なるためだと見える。一度間違えた位置推定が次の動作を狂わせ、その狂いが後のステップへ累積する。長い課題ほどコードのロジックがこの累積に耐えなければならない、という意味だ。ただしこれは差のパターンを見て立てた解釈であって、数値が直接証明する結論ではない。
まとめると、この結果は実行中のモデル呼び出しを無くせることを示している。開発に必要なコストと現場への適用可能性は別に評価しなければならない。この成果はあくまでオフラインでコーディングエージェントが課題ごとのロジックを磨いて得たものだからだ。著者らは、このコードが特定のエピソードに縛られないので、一つの方策で複数のエピソードから成功軌跡を安定して取り出し、VLA・エージェントハーネスの学習データとして使えると提案する。
著者らが自ら認めた弱点は汎化だ。COAPは課題ごとのコードロジックを少量必要とするため、汎化に主に弱いと明言する(ただしエージェントハーネス系も課題レベルのメモリを使い、一部はエピソードレベルのロジックに依存すると付け加える)。そしてCOAPの上限は結局「状態をどれだけ正確に表現するか、コードのロジックがどれだけ頑健か」にかかっていると明記する。測定が間違えば決定も間違う、という意味だ。
ここに筆者の観察を加えると、この方法が通用する前提はかなり強い。カメラ位置・ロボットの形・物体の形状・テーブルの高さがあらかじめ与えられ、変わらないからこそ、知覚コードは仮想の線と形状合わせで姿勢を復元できる。ベンチマークはこれらの値を公開するが、現場のロボットは物体の形状を知らないことが多い。また「状態を正確に測定できる」という仮定が、照明・遮蔽・初めて見る物体を前にしてどれだけ持ちこたえるかは、この範囲だけでは断定しがたい。接触が多く形が変わる操作へ行くほど、この仮定は緩む余地がある。
COAPの教訓を業務自動化へ移すとき、まず引くべき境界がある。担当者や締め切りのような値はコードではっきり読めるが、メッセージに込められた意図は解釈が要る。 すべてをコードへ移せるわけではない。
狭い事例を一つ見よう。「担当者が空いている締め切り間近のタスクを見つけて再割り当てする」という仕事だ。ここで「担当の空席」と「締め切りまで残った時間」は、チケット・スケジュールからコードで正確に読んで変数に入れられる。すると「締め切り間近 + 担当の空席 → 再割り当て通知」といったルールはコードに固め、毎回モデルに「誰に何をさせるか」を尋ねる必要がなくなる。逆に「この再割り当てが今のチーム状況に合っているか」といった判断は、メッセージの文脈を読まなければならないので、モデルの持ち分として残す。
ONTLEが目指す「反復業務の軽減」のキメがここにある。測定でき反復される決定は検証済みのコードへ降ろし、高価なモデル推論はコードがまだ担えない境界にだけ使う。ただしはっきりさせておくと、これはCOAPが見せた原理をONTLEの設計に照らして見た方向であって、今そう実装されているという意味ではない。自然言語の業務の状態は、ロボットの物体姿勢ほどきれいには測定されないので、現実的な出発点は「すべてコード」ではなく、測定できる部分からコードに固めるハイブリッドだ。
結局、実務の判断基準は一つに収束する。どの状態とどの決定をコードへ移すか。 はっきり測定でき繰り返されるものからコードへ降ろし、残りはモデルに残せばよい。
前提から確認する必要があります。COAPは、物体の形状・カメラ位置・ロボットの形といった値があらかじめ公開されているという条件の上で動きます。現場のロボットはこうした形状を知らない場合が多いです。ですから丸ごと移すよりも、状態をはっきり測定できる反復課題からコードに固め、残りはモデルに任せるほうが現実的です。
実行(テスト)時点では、VLA・VLMといったモデルは要りません。ただしコードライブラリを作るオフラインの開発段階では、Claude Opus 5.5コーディングエージェントがコードを書いてデバッグします。また著者らは、こうして作ったコードが安定して成功軌跡を取り出すので、逆にVLA・エージェントハーネスを学習させるデータを量産するのにも使えると見ています。「実行時はモデルフリー」であって、「開発まで無料」ではありません。