北京大学・シンガポール国立大学・NVIDIAなどの研究チームが、ロボットを動かすAIエージェントのインターフェースを変えることで、成功率とコストを同時に改善した。モデルに動作を一つずつ選ばせる代わりに短いPythonコードを書かせたところ、同じモデル(GPT-6 Astra)と同じロボット動作を使いながら、成功率は63.1%から71.7%に上がり、両方式がともに解けたタスクを基準にすると入力トークンは65%少なくて済んだ。要点は「より賢いモデル」ではなく、「モデルに仕事をさせる窓口」を変えたところにある。
ロボットを動かす近ごろの方式の一つは、視覚言語モデル(VLM、画像と文章を一緒に理解するモデル)にカメラ映像とロボットの状態を見せて、「つかめ」「運べ」といった動作命令(primitive)を選ばせるものだ。問題はコストである。ツール呼び出し(tool-calling)方式では、前の動作の結果によって次が分かれるタスクほど、モデルを何度も呼び出さなければならない。つかもうと接近したあとに「ちゃんとつかめたか」を確認し、つかめていなければ再試行する——この短い判断の一つひとつが、すべてモデル呼び出し一回分になる。
そこに観測データまで積み重なる。著者らが比較基準にしたRPentシステムでは、動作が一つ終わるたびに、カメラ画像を複数枚と状態値がモデルの対話へ自動的に添えられて入ってくる。毎ターン画像が付くので文脈はみるみる膨れ、その膨れた文脈が次の呼び出しでまたトークンとして数えられる。
たとえるなら、料理人が玉ねぎを一度刻むたびに料理長へ電話して「刻みました、次は」と尋ね、そのたびに調理台の写真をまるごと添付して送るようなものだ。判断の要らない細かな手順まで全部を上への報告で処理するので、電話代(トークン)が爆発的に増える。
PyRUA-Lean(Python for Lean Robot-Use Agents)の発想はシンプルだ。モデルに動作を一つずつ選ばせるのではなく、短いPythonコードの断片(cell)を書かせよう、というものである。
ロボットはroboというPythonオブジェクトとして公開され、モデルはpython(code)というツールでコードを投げる。このコードの中で複数の動作をつなぎ合わせ(compose)、ifで途中結果を点検し、失敗すればその場で再試行する。こうした条件分岐と再試行がすべてコード一つのセル内で完結するので、モデルを呼び直さない。セルが終わるときには、モデルが次の計画を立てるのに必要なものだけを返す。
二つめの軸が選択的観測(selective observation)だ。コードが実行されている間に生まれた途中結果はランタイムの中に残っているだけで、自動的に対話へ割り込んでこない。モデルが場面を見たければrobo.showを明示的に呼び出して初めて、その画像が文脈に入る。変数やヘルパー関数は一つのエピソードの中でセルをまたいで生き続けるので(persistent namespace)、途中データを対話に溜めなくても次のセルで使い回せる。
論文が挙げた場面(Figure 2c)がこの構造をよく示している。器を置くタスクで、ツール呼び出し方式なら14〜17番と四回のモデルターンが必要になる区間を、PyRUA-Leanはセル一つで処理する。そのセルは場面の座標情報から器を置く高さを自分で計算し(どの動作命令もその値を直接くれない)、条件に合えば置いて手を開き、タスクがまだ終わっていないときだけ画像を要求する。成功したときに返ってきたのは五行のテキストだけで、画像はない。四回の往復が一回に減ったのである。
巧みな点は、これがまったく新しいロボット能力を作ったわけではない、というところにある。PyRUA-LeanはRPentのロボットスタックと動作実装をそのまま使い、計画を立てるモデルも同じGPT-6 Astraだ。変わったのは、その能力をモデルに差し出すインターフェースだけである。だからこの研究は「より強いモデル」ではなく、「同じモデルに、より良い対話の窓口」を与えた実験として読める。
評価はシミュレーション700件のタスクインスタンスで行われた。LIBERO-PROの撹乱(perturbed)4スイートから40タスク、RoboTwin 2.0の両腕タスク50件、RoboCasa365のTarget50から50タスクを、それぞれ5つの環境シードで回して700ペア、二つのエージェントを合わせて1,400エピソードを得た。
核心の数字は二つだ。同じLLM呼び出し予算のもとで全体の成功率が63.1%から71.7%に上がった(絶対8.6%p、相対でおよそ14%——タイトルの「14%」はこの相対値だ)。そして二つのエージェントがともに解けたインスタンスだけで見ると、PyRUA-LeanはLLM呼び出しを49%、入力トークンを65%少なく使った。成功率は上げてコストは下げた格好で、ふつうこの二つはトレードオフの関係にある点で目を引く。
著者らが追跡したところ、トークン削減の主な出どころはモデル呼び出し回数そのものが減ったことだ。呼び出しが減れば、毎回付いて回っていた文脈と画像も一緒に減るからである。解けたエピソードあたりのコスト(ドル)も、すべてのベンチマークでより低かったと報告している。興味深いのは、この効率がVLAポリシー(学習済みの視覚-言語-行動モデル)や作業ガイド(operating guide)がない条件でも保たれた点だ(RoboCasa365にはガイドがそもそもない)。削減効果が特定の補助装置のおかげではなく、インターフェースそのものから出ているということだ。
正直に押さえておくべき点がある。第一に、すべてシミュレーションだ。700件は仮想環境のタスクインスタンスであり、実機のロボットアームで同じ差が出るかは、この結果だけでは断定できない。
第二に、効率の利得はどこでも同じ大きさではない。著者ら自身、VLAがタスクを主導する(VLA-dominated)課題では削減幅が縮むと明かしている。動作の大半を学習済みのポリシーが一度に処理してしまうと、コードでまとめて節約できる往復そのものが少ないためと読める。
第三に、このインターフェースは、モデルがコードをきちんと書けるという前提に寄りかかっている。座標を計算し条件分岐を組む負担がモデル側へ移るわけだが、コードが間違えば例外が出て、その場で書き直さねばならない。論文は、例外が出ても直前までに割り当てられた変数はネームスペースに残って復旧できるよう設計しているが、これは成否がモデルのコーディング力に乗る、という意味でもある。
第四に、比較はエピソード間の記憶(cross-episode memory)を両方とも切った状態で行われた。公平なインターフェース比較のための選択だが、逆に「経験を積んで再利用したらどちらが有利か」はこの実験の範囲外である。(公開された抜粋は失敗事例の具体的な数字までは含んでいないので、その部分は原文の4.5節を確認する必要がある。)
ONTLEのAI PMが顧客リクエストを一つ処理する場面を思い浮かべてみよう。「連携してある在庫システムから、品切れ間近の品目だけを抜き出して要約して」。小さく見えても、依存する手順がずらりと連なっている。連携が生きているか確認し、データを引っ張ってきて、空なら一度やり直し、基準線を下回った品目だけをふるい分け、それを人が読める要約に変える。
ツール呼び出し式で組むと、この手順ごとにモデルを呼び直しがちだ。「連携を確認しました、次は」「データが来ました、次は」。そしてその合間に、応答の原文(数百行の在庫テーブルのようなもの)が対話にそのまま積み重なり、次の呼び出しのトークンとコストを押し上げる。リクエスト一つがちゃんと処理されても、文脈は散らかって高くつく。
この論文が指す方向ははっきりしている。「連携確認 → 照会 → 再試行 → フィルタ」のように決定が決まりきった区間は、モデルに一段ずつ尋ねず、サーバーで決定論的に実行されるコードの一塊にまとめよ。そしてその塊が終わったら、数百行の原文ではなく「品切れ間近7件、リストはこれ」といった、PMが次の判断にすぐ使える結果だけを文脈に載せよ。ONTLEが朴ソア(パク・ソア)PMを再設計するにあたって「言葉と行動が食い違う広い裁量」を取り払い、共通アクションサービスの上でサーバーが決定論的に実行するように回した選択は、まさにこの論文がロボットで数字として示したその方向だ。モデルは何をするかを判断することだけに使い、どう実行するかはコードで下ろす。そうすれば、成功率を保ちながら呼び出しとトークンを一緒に削る余地が生まれる。
ただし教訓が一つ付く。効率がインターフェースから出るということは、トークンを節約するためにより強いモデルを買うのが第一ではない、という意味だ。PMが顧客リクエストをどんな窓口で処理するよう設計したか——それが先なのである。
いいえ。ロボット動作の実装と計画モデル(GPT-6 Astra)は比較対象のRPentと同じに据え、その能力をモデルへ公開するインターフェースだけをツール呼び出しからPythonコード実行に変えたものです。同じ素材で窓口だけを変えたときに成功率とコストがどう変わるかを測る実験に近いものです。
著者らの追跡では、モデル呼び出し回数が減ったことがトークン削減の主な出どころです。条件点検と再試行をコード内で完結させてモデルを呼ぶ回数を減らし、呼び出しが減れば毎回の呼び出しに付いて回っていた画像や途中結果も一緒に減るからです。二つのエージェントがともに解けたインスタンスを基準に、呼び出し49%、入力トークン65%の削減でした。
いいえ。学習済みのVLAポリシーがタスクを主導する課題では削減幅が縮むと論文は明かしています。コードでまとめて節約できる往復がそもそも少ない状況だからです。逆に、位置確認・移動・復旧を繰り返す必要があるタスクほど利得は大きくなります。
論文そのものが、CodeActなど一般エージェント研究の「コードでツールを組み合わせると文脈が効率的になる」という流れをロボットへ持ち込んだものです。観測が画像で失敗が多いロボットでも同じ原理が成り立ったという点は、複数のAPIをつないで働く業務エージェントの設計にもそのまま参考になります。