ロボットの失敗を研究に変える——ASPIREとENPIREの自己改善を読む

ロボットが失敗から学ぶという言葉の中に、異なる二つの仕事がある。動作のどこが間違ったかを調べてプログラムを直す仕事と、その修正が本当に良くなったかを同じ条件で試す仕事だ。NVIDIA GEARのASPIREとENPIREは、コーディングエージェントをこの循環へ入れる研究である。ASPIREは細かな実行記録から修復の知識を蓄積し、ENPIREは実機の初期化、判定、記録を整えて方策や学習コードを改良する。両者を並べると、「自己改善」の核心が、モデルに何でも任せることよりも、変更できる対象と変えてはいけない評価条件の設計にあると見えてくる。以下は論文の著者報告と公開コードの静的読解に基づく分析であり、独自にロボット実験を追試したものではない。^[1,11]

ASPIREは「失敗した」を、直す場所の分かる証拠に変える#

ASPIREの基盤モデルは凍結されている。試行のたびに大規模言語モデル自身の重みを更新するのではなく、そのモデルが書くPythonの制御プログラムと、将来の課題へ渡す文章の技能集を更新する。課題を受け持つactorが実行、診断、修復を繰り返し、coordinatorが課題の割り当てと共有技能集を管理する。actor同士で会話履歴や生の動作記録を丸ごと交換せず、再利用できる知識を技能へ圧縮する構成である。^[1]

プログラムが扱うのは、あらかじめ公開された知覚と運動のAPIだ。get_observation()から画像とロボット状態を取得し、localize_object()で対象の位置や形状を推定する。把持や移動には逆運動学、軌道計画、手先の目標姿勢、グリッパー操作を組み合わせる。位置だけでなく座標系と姿勢表現を型として渡し、各処理は成功を表す.okと診断情報を返す。文章の「技能」はこのAPIを使いこなす知識であり、下位の認識器や制御器そのものとは別の層にある。^[3]

公開実装のProgramExecutorをたどると、生成コードを構文木で検査し、公開関数と限られた構築子を実行空間へ注入してから動かす経路が確認できる。許されるimportはmathに限定され、非公開属性へのアクセスなどを拒否する。シミュレータ内部の正解状態や報酬をそのまま方策へ渡さないための制約もある。ただしコード自身が、信頼できないプログラムにはプロセスの隔離が必要と注意している。APIを制限することと、実行環境全体の安全性を証明することは異なる。^[2,3]

改善を支えるのは、その実行をどこまで観察できるかだ。運動APIの前後で画像を取り、呼び出しの引数、返り値、所要時間を記録する。内部で呼ばれた知覚や計画の処理も、親子関係を持つ記録として残す。認識マスクを重ねた画像、手先の移動前後、失敗コードを結び付ければ、物を見失ったのか、届かない姿勢を命令したのか、移動後に落としたのかを切り分けられる。実行結果を一個の成功・失敗ラベルに縮めないことが、修正の手掛かりになる。^[2,4]

論文のラジオを拾う例は、この仕組みをよく示す。ロボットはラジオを検出できたのに接近できず、ナビゲーションが繰り返し計画エラーを返した。ログから、設定した目標が机の周囲の衝突回避領域に入っていたと診断する。そこで認識を作り直すのではなく、ラジオの周囲で接近方向を変える処理を追加した。到達できる側へ回り、再観測して把持する。原因の層を特定できるからこそ、失敗と関係の薄い部分を変更せずに済む。^[1]

記録は試行ごとの新しいディレクトリに保存され、プログラム、APIの実行履歴、画像、最終評価を分離する。最終成果物にはファイルのハッシュも付く。一方、点群の全座標や認識の全マスクを永続化する設計ではなく、候補や画像を選んで記録する。これは調査に必要な証拠を扱える量へ収める判断だが、すべての生データから実験を完全に再構成できるという意味ではない。記録の契約を読むことは、再現可能性の限界を読むことでもある。^[4]

実機では、エージェントはMCPを通じて永続するCAP実行環境へ接続する。入力はJSONのschemaで検査され、動作は一件ずつjobとして実行される。実行中に別の動作を入れるとbusyとして拒否し、終端状態と画像を返して次の判断へ進む。会話が新しくなっても実行環境を維持できる一方、画像には取得時刻や古さの情報を付ける。LLMが毎制御周期の運動を直接生成するのではなく、下位の実行器が動作を所有し、上位のエージェントがその結果を読む構成だ。^[8,9,10]

修復を文章に残しても、転移は別に確かめなければならない#

成功したプログラムを保存するだけでは、次の課題で何を再利用すればよいか分からない。ASPIREの技能集には、失敗が現れる条件、適用する状況、修復戦略、必要ならコードの例を残す。ラジオの例なら、対象物の名前や固定座標ではなく、障害物の近くで計画が失敗するときに接近方向を変える知識となる。coordinatorはactorの報告を受けて技能を採用するが、課題の成績評価と技能の採否は独立した工程として管理する。^[1,5]

公開されたverifierの指示は、この採用に重要な限定を置く。新しいagentが提案された技能だけを手掛かりに同じ課題を解き直し、提案者の解答コードや過去のdebug出力を読まない。公開templateでは五つのseedで最大二つのプログラムを試し、四つ以上の成功を合格条件にする。それでも確認できるのは、文章が修復の知識を他のagentへ伝えられることまでだと明記する。元の課題での再現と、別の課題への汎化を混同しない点は、この研究を評価するうえで欠かせない。^[6]

同じ戦略の小修正に閉じこもる場合は、進化探索で別案を増やす。公開runbookのLIBERO向け設定は一世代八候補、開発用seed十五個、最大五世代で、開発側の最高成功率が80%以上なら停止する。既存の修正版を候補の一つとして残し、上位三つの案と失敗の履歴を次世代へ渡す。何でも書き換え続ける無制限な探索ではなく、候補、試験集合、予算、採用基準を持つプログラム探索である。最後に選んだ一案を、探索に使わなかったseedで評価する。^[1,7]

著者のOpus 4.6による主実験では、LIBERO-ProのObject、Goal、Spatialを位置変更と課題変更の二条件で測り、各課題五十のheld-out seedを用いた。六つの条件をまとめた平均は、比較するCaP-Agent0の18%に対しASPIREが72%だった。実行engineと進化探索を除いた比較では14%、engineを加えて62%、進化探索まで加えて72%と報告する。改善の大きな部分を診断可能な実行環境が担うという著者の解釈を支える。ただし比較側はseedごとの再生成と再試行を行い、ASPIREは課題ごとに一つのコードを適用するなど、実行方式は同一ではない。^[1]

文章技能の転移を直接見る実験もある。LIBERO-90の零、二十五、五十、九十課題から得た技能を使い、未見の長い課題で一度だけプログラムを生成する。評価時の追加debugや再試行をせず、位置変更と課題変更それぞれ十課題の平均を測ると、Opus 4.6で総合4.7%、13.7%、21.5%、30.5%と上がった。ここで増やしているのは元の課題数で、技能ファイルの数ではない。経験が役立つ証拠であると同時に、最も大きい技能集でも大半の評価は成功に至らなかったという結果でもある。^[1]

実機への転移では、Frankaを使う模擬環境で得た知識を、別の二腕YAMと別APIで作業するGPT-5.5へ渡す。制御方策の直接移植ではなく、実機のfeedbackを使ってコードを書き直す際の助言である。缶を持ち上げる課題は各条件二十試行で、技能なしの13成功から、技能ありの19成功へ上がった。最初の成功プログラムまでの総tokenは61.94百万から6.58百万へ減ったが、皿に椀を置く課題は両条件20成功、引き出しは技能があっても11成功にとどまる。転移の効果は課題に依存する。^[1]

ENPIREは、実機の採点器を固定してから改良を始める#

ASPIREが失敗の読み解きと知識の蓄積を詳しくしたのに対し、ENPIREが前面に置くのは、実機で研究を繰り返せる環境である。環境構築、方策改善、ロボットによる試行、仮説や学習基盤の改良を組み合わせる。最初に人とagentがresetや成功判定、安全範囲を整え、次の段階ではそれらを固定して方策側を改善する。学習者が採点の定義まで都合よく変更すれば、成績は上がっても仕事は上達していない。この循環を避ける境界が設計の中心にある。^[11,15]

その第一段階には人の仕事が残る。論文では、成功と失敗の短いデモや、判定器に求める精度・遅延の条件を人が与える。公開workflowでも、機器の同定、校正板の配置、カメラ校正の残差確認、現物での確認を必要とする。resetも単に腕を原点へ戻すことではない。部品を次の試行が始められる状態へ運び、準備ができたと判断する必要がある。精密挿入の難しい局面の直前までresetが担当する設定では、学習方策の成功率に作業の全準備工程が含まれるとは限らない。^[11,17]

判定器は仕事に合わせて作る。pin挿入では視覚的な位置合わせに加え、関節状態から分かる挿入深さや力・トルクの情報を使う。結束バンドの例では頭部と帯のmaskから通過を判定し、上と横の二視点を合わせて一視点の誤認を抑える。論文は認識処理をONNX化し、複数対象の処理をまとめて150ミリ秒以下という遅延予算を満たしたと報告する。ただし速い判定器であることと、誤った成功を見逃さないことは別であり、判定精度そのものの検証が必要だ。^[11]

ENPIREの変更対象には二層ある。手続き的な方策なら、対象検出、空間移動、把持、グリッパー操作を組み合わせたPythonを編集する。ニューラル方策なら、模倣学習や強化学習のコード、batch size、actorとcriticの更新頻度、模倣による正則化などを改める。後者ではlearnerが方策の重みを学習し、その学習手順をコードagentが変更する。LLM自身の重みが試行ごとに学習されるのでも、すべての改善が強化学習で起きるのでもない。^[11,23]

手続き方策の公開実行経路では、agent側からscript runnerを別processとして起動し、runnerがrobot adapterを通じて環境とtool群を組み立てる。カメラと制御は環境が所有し、重い認識や計画は外部サービスへ渡す。run_script.pyはコードを実行し、画像、debug event、標準出力を記録したうえで、環境のget_task_info()から成功や報酬を読み、result.jsonへ保存する。方策が何を言ったかではなく、環境側の判定を成果物へ落とす具体的な経路がある。^[12,13]

学習側ではepisode directoryがデータの受け渡し点になる。ロボットが観測、行動、動画を保存し、DiskBufferIngestorが完成済みepisodeを取り込む。rlの行動はonline replay bufferへ、人の介入や手動操作はdemo bufferへ分ける。由来が不明な行動を拒否するstrict modeもある。人に助けてもらった経験を学習に使えることと、評価時に人なしで成功したことは別なので、データの出自を残す必要がある。ここは学習アルゴリズムと同じくらい重要な実装箇所だ。^[14,16]

実験を始める手順にも状態の境界がある。bridgeの稼働を確かめ、停止し、restartで新しい出力先を作り、learnerが正しいdirectoryを読んでいると確認してから試行を再開する。古いデータを読むrun、resetや成功条件を変更したrun、人の行動を純粋なRLとして数えたrunは無効とする。各iterationに仮説、差分、source commit、設定、データとcheckpoint、予算、結果、採否を残し、失敗も保存する契約だ。ただし公開autoresearch.py自体は小さなHTTP clientであり、この契約のすべてを自動強制する研究エンジンではない。^[15,24]

99%と八台の成果を、再試行と研究時間の単位で読む#

ENPIREの公式ページが掲げる99%は、失敗の履歴を見ながら一つの作業内で各subtaskを最大八回試すpass@8の報告である。一回で99%成功するという意味でも、独立な八候補から最良を選ぶだけの評価でもない。公開ページの文言から、全展示課題について同一の分子・分母を持つ99%の一覧までは確認できない。したがって99回成功した百試行といった件数を補うべきではない。繰り返し直して達成する能力を評価した数字として読む必要がある。^[18]

試行回数の数え方は公開集計コードにも現れる。episodeの終了eventから成功を数え、全episodeと人の介入を除いた純粋なRLを別に集計する。累積成功率、最後の一定区間、最も良かった一定区間も区別し、窓が満杯になる前はその値を出さない。壊れたmetadataを除外する処理があるため、欠損した件数も分母の監査に関わる。最良区間だけを取り出した数字を、長期運転の平均や、未知の部品に対する信頼性へ置き換えることはできない。^[16]

並列化の実験は、研究時間の短縮を示す。著者らは一、四、八組のagentとロボットを使い、同じ環境interface、報酬、resetで比較した。Push-Tが正規化score 1.0へ到達する経過時間は、一組の約五時間から八組の約二時間へ、pinがほぼ完全な成功へ到達する時間は一時間半超から約四十分へ短縮したという。これは研究開始後に解へ到達する時間であり、設備設置を含む導入時間でも、一個の部品を処理するcycle timeでもない。^[11]

各stationは双腕YAMと専用workstationを持ち、ローカルAPIがhardware操作を受け持つ。agentは同じbaselineから分岐し、Gitで有効だったcodeや設定を共有する。ところが台数を増やすと、研究時間に対して実機が試行している比率は下がった。ログを読む、コードを直す、モデルの返答を待つ、仲間のbranchを要約する時間が生じるからだ。論文は八agentでtoken消費の増加が線形を上回ることも報告する。早く答えに届くことと、合計資源を少なく使うことは同じ指標ではない。^[11]

経験の移転も、何を持ち越したかで意味が変わる。ENPIREのpinからGPU挿入への転移実験では、過去の研究をまとめたMarkdownを追加する一方、生のtrajectoryやcheckpointなどは除去する。これは前の研究の要点を次のagentに伝える実験であり、LLMの重みに経験が定着した証拠ではない。ASPIREの技能集と比較できるのはこの文章を通じた伝達の層で、強化学習方策の重みの転移や、実機の形状差への対応とは分けて論じる必要がある。^[11]

ASPIREのRubik実機実験も、同じ慎重さで読むと意義が明確になる。人の初期助言とsymbolic solverを使える一つのAstra sessionで三episodeを続け、最初は未解決、二回目と三回目は解けた。完成した面回転は三、五、二十五回で、失敗と回復を含むepisode時間を回転数で割ると約十七分、八分、三分へ短縮した。ただし三回目の総時間は約七十七分で二回目より長い。文章技能と文脈の蓄積に伴う効率改善の観測であって、独立な多数回の成功率や技能だけの因果効果を測る試験ではない。^[1]

自己改善を導入する前に、編集権限と証拠の寿命を決める#

ここから得られる工学上の見取り図は、改善を三層に分けることだ。現在の課題のコードを直すこと、経験を文章やデータとして次の課題へ持ち越すこと、そして改善を生む学習手順や実行基盤自体を改めること。ASPIREは主に最初の二層を実装し、ENPIREは方策を学習するコードの改良まで対象にする。ただしどちらも、基盤LLMの知能が自動的に高まることを実証したわけではない。「自分を改善する」の自分がどの層なのかを決めなければ、比較は成り立たない。^[1,11]

改善器そのものの改善を主張するなら、新しい研究手順が、未見の課題でも、同じモデルと資源予算で、従来より良い修正を生むと測る必要がある。これは両研究の実験境界から導かれる筆者の評価基準だ。学習者が採点器や失敗の除外条件まで書き換えられるなら、自己評価の向上を仕事の上達から切り離せない。更新を認めるファイル、評価を所有するprocess、採用する人または独立した判定器、元へ戻す条件までを一組で設計することが重要になる。^[6,15,16]

日本の製造現場へ読み替えるなら、まず必要なのは対象工程の成功を測れることだろう。挿入の深さ、把持の安定、部品の損傷、reset後の状態をどう記録し、異なる試行で同じ意味に保つか。これは導入効果の実測値ではなく、ENPIREの環境所有とASPIREのtrace設計から導く実装上の論点である。校正や部品のばらつきが変われば、過去の技能が成立する条件も変わる。成功した知識を保存するだけでなく、その知識を再検証する入口が必要だ。^[1,4,17]

公開物の範囲も、研究の完成度と分けて確認したい。今回読んだASPIREは2026年10月15日のcommit、ENPIREは9月9日のcommitに固定した。ENPIREにはpin向けのlearnerとactorがあるが、実機側bridge launcherやGPU・結束バンドの内部操作scriptなど未収録の部分も明記される。Push-Tの環境があっても、専用learner presetまで保証されるわけではない。論文が実験を報告したこと、公開treeに部品があること、利用者が同じstationで再現できることは別の到達点だ。^[17,23]

両プロジェクトの本体ライセンスはApache License 2.0だが、外部SDK、モデル重み、データを一括して同じ条件で使えるとは限らない。ASPIREの依存台帳には研究用途に制限された部品やBEHAVIORデータの条件があり、ENPIREもAnyGraspのSDKやcheckpoint等を配布に含めない。これは確認した公開物の条件の説明であって、全stackの法務監査ではない。コードの公開を、商用stationの完成品の配布と読み替えないことが再現計画の出発点になる。^{[19,20,21,22]}

ASPIREの著者は技能の陳腐化、重複、過度な特殊化と、実世界の成功判定や安全なresetを未解決として挙げる。ENPIREも環境を構築する人の仕事と、研究中に守る契約を必要とする。両者から読み取れる前進は、ロボットが無条件に自律したことではなく、失敗を修復案へ、修復案を比較可能な試行へ、試行を次に使える知識へ渡す接続が具体的になったことだ。現場で価値を測る単位も、「自己改善するか」という呼称から、どの失敗を減らし、その改善をどの証拠で維持できるかへ移る。^[1,11,15]

関連する技術解説：ARTEXの記憶・証拠管理と、自己改善の実装範囲