【DL輪読会】CaP-X: A Framework for Benchmarking and Improving Coding Agents for Robot Manipulation

“CaP-X: A Framework for Benchmarking and Improving Coding Agents for Robot Manipulation” Hiroaki Honda, Matsuo-Iwasawa Lab M1 1

書誌情報 ■ タイトル： CaP-X: A Framework for Benchmarking and Improving Coding Agents for Robot Manipulation ■ 著者：Letian Fu ⋅ Justin Yu ⋅ Karim El-Refai ⋅ Ethan Kou ⋅ Haoru Xue ⋅ Huang Huang ⋅ Wenli Xiao ⋅ Li Fei-Fei ⋅ Guanya Shi ⋅ Jiajun Wu ⋅ S. Sastry ⋅ Yuke Zhu ⋅ Ken Goldberg ⋅ Jim Fan ■ 出典：ICML 2026 poster https://icml.cc/virtual/2026/poster/66369 ■ 選書理由 • Code-as-Policy の性能や設計判断などに興味があったため 特に記載がない限り、本資料の図表は上記論文からの引用です 2

• https://icml.cc/virtual/2026/poster/66369

背景①：ロボット制御の 2つのパラダイム 明示的プログラムと VLAは、それぞれに一長一短 • 古典的なプログラム制御（TAMP など）：知覚・幾何・計画・制御を人手で構造化 – 解釈性と幾何精度は高いが、職人による知識・設計に依存し、タスク特化で randomization に対して弱く、スケールしにくい • VLA（Vision-Language-Action）：大規模な視覚・運動データから直接学習 – 布折りなどの接触の多いタスクに強いが、解釈性は低い – 新しい身体や長いタスクへの汎化には、再学習が必要 3

背景②： Code-as-Policy と本論文の問い • LLM コーディングエージェントが、知覚・制御 API を組み合わせて実行コードを生成 • 従来の Code as Policies は、stack_objs_in_order() のような高レベルな API を前提としている – 性能がエージェントの実力なのか、人手で用意した足場のおかげなのか切り分けられない • 本論文の問い – 人手設計のタスク特化な高レベル API を用いず低レベル API を用いると、LLM はどれだけロボット操作ができるのか – 高レベル API を再導入せずに、test-time compute などで性能を向上できるか 4

CaP-X 全体像 「環境・評価・学習なしでの改善・ RLでの改善」の 4部構成 • CaP-Gym：コード生成と実行でロボットを直接制御する対話環境 • CaP-Bench：抽象度・対話・視覚グラウンディングの3軸で12モデルを評価 • CaP-Agent0：学習不要の改善フレーム（VDM＋スキルライブラリ＋並列推論） • CaP-RL：コーディングエージェント自体を強化学習で後訓練 5

CaP-Gym コード実行を 1ターンとする REPL 環境 • Gymnasium 準拠：低レベルの環境ループ（物理シミュ・実機）とコード実行ループを連結 • 187タスクを統合 ：RoboSuite / LIBERO-PRO / BEHAVIOR • 認識：SAM3（言語条件セグメンテーション）, Molmo2（open vocab pointing）, OpenCV, Open3D • 制御：関節への直接指令ではなく、IK・モーションプランナ（PyRoki）を呼ぶ – Task space で推論し、実行可能性はコントローラに委ねる 6

CaP-Bench 評価デザイン • 7タスク・12モデル、各段階100試行 Zero-Shot Pass@1 7

評価①： Takeaway 1 — フロンティアモデル vs 人間 低レベル API を用いた Single turn（S4）では人間のプログラム性能に及ばない • クローズドモデル ＞ オープンモデル、新しいモデル ＞ 古いモデル、という傾向は一貫 • ただし Zero-Shot Pass@1 では、人手で作成したプログラムの成功率に到底届かない • 他ドメインのベンチマークでは人間並みでも、ロボット制御のコード生成は依然として差が残る 8

評価②： Takeaway 2 — 抽象度のトレードオフ 抽象度を上げると成功率は上がるが、汎化に天井ができる • S4→S1 と抽象度を上げると、成功率は単調に増加（探索空間が縮小し、 タスクの順序付けに集中できる） • これはコードの正答率の差だけでは説明できない（Figure 4） • 高レベル化＝人間の事前知識で行動空間を制約 → 表現力が落ち汎化 性能の上限が規定されてしまう • →高レベル API に頼らず、エージェント自身が低レベルな API を組み 合わせて構造（スキル）を獲得できるようになるべき 9

評価③： Takeaway 3 — Multi turn と Visual Grounding テキスト化した Visual 差分（Visual Differencing Module）が有用 • M1（stdout/stderr のフィードバック） ：全モデルで改善 • M2（RGB 画像）：直感に反して性能が低下 ○ 「ソフトウェアのコード生成」と「物理タスク実行の画像」を同時に推 論するようには訓練されていないので、コード合成の最中に生のピ クセルを統合するのが苦手なのではないか？ • M3（Visual Differencing Module ＝ テキスト化された Visual の差 分）：M1・M2 を一貫して上回る ○ 他論文（Hu et al., 2025; Wang et al., 2026）でも同様の状況が発 生している • M4（低レベル＋ Multi turn）：高レベル Single turn（S2）を超え、高レベ ル Multi turn（M3）とも遜色ない性能 10

CaP-Agent0（training-free） CaP-Bench での評価結果をもとに作成した training-free の CaP 構成 11

CaP-Agent0（training-free） CaP-Bench での評価結果をもとに作成した training-free の CaP 構成 12

CaP-Agent0（training-free） CaP-Bench での評価結果をもとに作成した training-free の CaP 構成 • 3つの要素を含めている（ Ablation = Figure 8） – VDM：毎ターンの観測を Gemini で構造化テキストに – 自己合成スキルライブラリ：成功例から汎用関数を抽出・蓄積 , 9関数 ■ – rotation_matrix_to_quaternion, depth_to_point_cloud, pixel_to_world_point など 基本的な汎用関数 並列推論：9候補を生成し、 Gemini が統合 ■ 1M 構成: Gemini-3-Pro × 9 ■ 3M 構成: Gemini-3-Pro × 3, GPT-5.2 × 3, Claude Opus × 3 • 結果：低レベル API のみで、7 タスク中 4 タスクで人間と同等かそれ以上 • CaP-Bench++：LIBERO-PRO で π0/π0.5 と同等〜上回り、指示の摂動に頑健であるこ とが観測された。BEHAVIOR では、対象物体が視界から隠れた際などもrepositioning を行なって recover するなどした 13

CaP-RL 抽象化された API 上で推論するため、 Sim2Real ギャップがほぼゼロ Single turn & 高レベル API (S2) での性能向上を目指す • GRPO（RLVR）で Qwen2.5-Coder-7B を post train。学習は S1 (noiseless perception) を用いることで、認識誤差による間違った報酬を 防いでいる →「grasp せずにいきなり置こうとして、もう掴んでいると hallucination する」などのロジック間違いを RL で防げている • Sim2Real： 抽象的な知覚 API を推論するため、視覚的なギャップが小さい （あくまでも CaP-Gym が RL にも使えることを示すためのセクション？） 14

まとめ・所感 • まとめ：CaP の包括的な検証 – ① Single turn & 低レベル API では人間のプログラムの性能には達していない – ② 抽象的な高レベル API だけでは汎化性能に天井がある – ③ CaP-Agent0: Visual Differencing Module (VDM) ＋ Multi turn＋test time scaling で、低レベル API を用いたまま人間のプログ ラム並の性能 – ④ Single turn では RL で性能向上が可能 • Future work： – 接触の多いタスク（挿入・注ぎ）は依然難しい → VLA とのハイブリッド: CaP–VLA（高レベルは CaP、低レベル実行は VLA）などが考えられる • 所感： – multi-turn の性能向上方法については検証がなかった ■ RL における long-horizon な credit assignment の問題に帰着するため、さらなる検証が必要 15