AgenticGenPlan：コーディングエージェントが未見のロボット作業に使える計画プログラムを生成

タスク・動作計画、略してTAMPは、何をどの順に扱うかという選択と、ロボットがその動きを実行できるかという制約を合わせて解く問題だ。操作対象を選んでも、途中で衝突したり、関節の動きに制約があったりすれば、その手順は成立しない。幾何だけでなく、力や運動に関わる動力学も選択に結び付く。

本研究では、物体の位置や形状、関節配置、速度などが与えられる「完全観測の物体中心状態」を使う。これは、ロボットが必要な状態情報を得られる前提である。それでも、長い行動列を選ぶ難しさは残る。目標達成まで有用な報酬が得られにくい、疎な報酬も計画を難しくする。つまり本論文が問うのは、状態が分かっている条件で、複雑な作業の解き方をどこまで自動で作れるかだ。

汎化計画とは、個別の問題を解くだけでなく、同じ種類の問題に繰り返し使える解き方を得ることだ。従来の汎化TAMPでは、有望な動作候補を作る仕組み、実行可能性を予測する仕組み、探索の優先順位を決める規則、状態や行動の抽象化などを再利用する。ただし、それらには課題に詳しい人による設計が多く必要になる。

本論文の比較対象である手設計プランナーも、条件を表す述語、操作の規則、動作候補を作る部品、動作計画のスキルを使う。そのうえで、評価時には各問題を新たに計画する。AgenticGenPlanが変えるのは、この課題固有の設計を誰が行うかである。コーディングエージェントに説明と実験手段を渡し、複数の問題で使えるプログラムを作らせる。生成コードの構造は、探索、最適化、解析的な制御のどれかにあらかじめ固定されない。

仕組みを追う例として、論文中のSortClutteredBlocksを考えよう。キューブをそれぞれの目標の入れ先に割り当てる課題で、物体数が変わる。再利用したいのは、ある配置で成功した一回の動作列ではなく、キューブの数や状態が変わっても目標を判断し、行動を選べるコードである。

ただし、この論文でいう汎化には範囲がある。生成するプログラムは環境ごとに別で、評価する初期状態は合成時と同じ生成分布から取る。合成中に使わなかった乱数の種、つまり初期状態を決めるseedを使い、物体数を増やした設定も含めて試す。これは同じ環境内での再利用を調べる設計だ。まったく別の作業環境や、想定と異なる状態分布へ、そのまま対応できることまでは示さない。

AgenticGenPlanの第一段階はプログラム合成である。ここでの合成とは、課題を解くコードを生成し、試して改訂する開発過程を指す。エージェントには、課題、観測できる状態、選べる行動、目標、物体数の変化、評価時の制限時間を説明する。シミュレータで初期状態を作り、行動を実行して、その後の状態や報酬、終了の情報を得られる。

エージェントは、どのテストを行うかを自分で選べる。失敗を調べ、コードを実行し、戦略を改訂することもできる。主設定では環境の実装ソースや手設計のTAMP部品は与えない。したがって、説明と観測できる挙動を基に、解き方を作る必要がある。著者はテスト前に改訂履歴を記録し、後から開発過程を分析できるようにしている。

第二段階では、生成したコードを固定する。このコードは途中の履歴や内部状態を保持しながら次の行動を選べるが、評価時にLLMは呼ばない。新しい問題のたびにエージェントが考え直すのではなく、合成段階で得た行動決定の仕組みがどこまで通用するかを測る。この分離が、その場の試行錯誤と、再利用できる成果を区別する。

主設定のエージェントは、Claude CodeのOpus 5と、CodexのGPT-5.6 Sol、GPT-6 Astraの3構成である。推論設定はOpusとAstraがhigh、Solがmediumだった。各環境で5回の独立した合成を行い、各合成実行のモデル利用予算は20ドルとした。

比較には手設計プランナーに加え、LLMGenPlanとOne-shotを使う。LLMGenPlanはOpus 5と環境ソースを使い、同じ20ドル予算でコードを改訂する。ただし、自らツールを使ったり独自テストを実行したりはできず、例外、無効な行動、解けなかった問題のseedという定義済みのフィードバックを受ける。One-shotは、その最初の生成コードである。この比較は、初回の生成や決められた修正経路に対し、自律的な実験を含む開発過程がどう違うかを見るものだ。

さらにOpusとAstraには、環境ソースも与える「+ source」設定を設ける。ここでは目標や成功判定を読めるだけでなく、補助処理を再利用し、任意の状態を設定するなど、シミュレータを直接操作できる。情報と能力が同時に増えるため、結果の差をソースの知識だけの効果と解釈することはできない。

評価対象はKinDERの25環境と、PDDLStreamのPacking、Blocked、Roversという3領域、計28環境である。7つの合成方式を各環境で5回試し、980プログラムを生成した。各プログラムを100の評価インスタンスで試すため、評価は計98,000エピソードになる。KinDERの19環境では物体数を変え、元のベンチマークの評価より多い物体数も含めた。

全方式は環境ごとに共通の100インスタンスを使う。著者は評価用seedが合成中に使われなかったことを事後に確認した。成功率は、インスタンス当たり60秒の制限と、環境が定める行動列の長さの上限であるホライズンの内側で、目標を達成した割合だ。成功判定はシミュレータの目標と報酬に基づく。

同じ問題と制限時間で比べる点は、方式間の比較を支える。また5回の合成は、一つの生成コードだけに依存した評価を避ける。ただし、エピソード数が多くても実機評価になるわけではない。目標達成率から、動作の望ましさや実機での安全性まで読み取ることもできない。

計算時間として測るのは、固定したプログラムの計画と行動決定に費やす時間である。プログラムを生成する時間と、評価環境の状態を更新する時間は除かれる。したがって、短い計算時間は実行段階の性質を表すが、開発から実行までの総所要時間や総費用を示さない。

比較する環境集合にも注意が必要だ。手設計プランナーとの成功率比較は、プランナーがある16環境に限る。物体数を変えた場合のプランナーとの時間比較は14環境である。さらに行動当たりの時間を示す別の比較では、4方式すべてに完全成功の合成実行がある15環境を選び、各方式自身の完全成功実行だけを平均している。同じ実行群を比べた値ではない。こうした条件を外すと、全28環境での成功率と、選ばれた成功例の速さを一つの性能として扱ってしまう。

著者の報告では、プランナーがある16環境の平均成功率は、主設定Solが56%、Opusが82%、Astraが95%、手設計プランナーが47%だった。各環境の共通100インスタンス、5回の合成、60秒制限という条件で、3構成ともプランナーを上回った。ただし、この95%を全28環境の主設定Astraの成績として読むことはできない。

全28環境では、ソース追加によりOpusは74%から84%へ、Astraは86%から95%へ上がった。増加はそれぞれ10、9パーセントポイントである。同じOpus 5、環境ソース、20ドル予算を使うLLMGenPlanは28%で、Opus + sourceは28環境中27環境でこれを上回った。固定フィードバックだけで改訂する方式との差は大きいが、推論設定やツール能力も異なるため、自律テストだけの効果を測った厳密な切り分けではない。

物体数を変える14環境の平均計算時間は、インスタンス当たりOpusが2.1秒、Astraが0.5秒、プランナーが29秒だった。一方、完全成功実行を選んだ15環境の行動当たり時間では、ソース利用版の平均は主設定より長かった。ソースを増やせば成功率も速度も一緒に改善する、という結果ではない。

SortClutteredBlocksの分析は、平均値だけでは見えにくい失敗を示す。主設定Astraのコードは、状態に並ぶ順序を基にキューブの入れ先を割り当てていた。この規則は4キューブでは働いたが、20キューブの全インスタンスで失敗した。問題は動作の難しさだけでなく、何を目標にすべきかという解釈にもあった。

+ sourceでは各キューブの目標の入れ先を参照し、この環境の平均成功率は43%から95%へ、52パーセントポイント上がったと著者は報告する。小さい例に適合した規則が、物体数を増やすと破綻する。この事例は、生成コードが動くことと、課題を正しく解釈していることを分けて評価する必要を示す。

ただし、ソース追加は目標情報だけを変える実験ではない。補助処理の再利用や操作能力も増えるので、改善のどこまでが正しい目標情報に由来するかは、この比較だけでは切り分けられない。目標解釈の失敗という観察は具体的だが、ソースを渡すことを一般的な解決策とするには追加の検証が要る。

全体の成績が高くても、難しい動的な3次元操作には大きな弱点が残った。Dynamic3DのScoopPourでは、平均成功率が主設定Opusで9%、Astraで14%。SweepSimpleではOpusが0%、Astraが3%だった。Astra + sourceでも、前者は42%、後者は44%にとどまる。これらも100評価インスタンス、5回の合成、60秒制限での著者の報告値である。

ソース追加が逆効果になる例もある。ShelfのOpusは、主設定の60%に対し、+ sourceでは43%だった。多数の小物体の掃き込みや注ぎ込みを含む課題が、平均値の改善だけで解決されたわけではない。適用判断には、対象環境の成績と失敗の内容を見る必要がある。

こうした結果から、本方式の候補は、完全な状態情報とシミュレータを用意でき、同じ環境内の多くの問題を繰り返し解く設定になる。難しい動的操作や、知覚誤差を伴う実機運用の性能保証へ、そのまま広げる根拠はない。

著者は、エージェントのログに独自テスト、内部モデルの校正、操作戦略の改訂が現れたと報告する。これは、完成した解を単純に思い出しただけという説明に反する材料になる。しかし、モデルの学習データは非公開であり、ベンチマークコードに事前接触していなかったことは確認できない。開発中の試行錯誤が見えることと、データ汚染がないことは別の問題である。

また本研究はarXivのプレプリントであり、ここで述べた数値は著者によるシミュレーション評価だ。知覚の不確実性がある条件や実機の性能は確立していない。未使用seedを使ったことは合成中の問題の再利用を避けるが、同じ初期状態分布での評価という範囲は変わらない。

次に注目すべき証拠は、対象課題で物体数や目標の解釈を変えたときの失敗、合成費用を含めた比較、知覚の不確実性や実機での検証である。それらがそろうまでは、本結果を同じ環境内で使う計画プログラムの開発手段として評価するのが妥当だ。