1. 補助付きで解けた記録は、そのままでは学習に使いにくい

コマンドを打ってファイルを操作し、ソフトウェアを組み立てる端末作業のエージェントは、課題が難しくなるほど失敗が増える。難しい課題を解けるようにするには、実際にその課題を解いた作業記録（軌跡）を集めて学習させるのが近道である。

問題は、難しい課題の成功の多くが、専用のハーネスの助けを借りていることである。ハーネスとは、モデルの周りに置く道具立てのことで、課題に合わせた手順の誘導、追加の道具、途中での介入などを含む。著者らが指摘するのは、こうした専用ハーネスの介入は、実際に使う場面では用意されていないことがあるという点である。補助ありきで成功した記録をそのまま学習させても、補助のない本番で同じ振る舞いができるとは限らない。[1]

この論文は、成功した記録の価値を残しながら、補助への依存を取り除く方法を問題にしている。一次情報は arXiv に公開されたプレプリントで、査読前の段階にある。

2. 提案の芯は、成功を手順書にして、一般的な環境でやり直させること

RSR の芯は一つに絞れる。専用ハーネスで見つけた成功を、一般的なハーネスの下での作業記録として作り直すことである。発見から書き直しまで、使う基盤モデルは Qwen-3.8-27B の一つだけである。

作り直しは三つの役割で進む。計画役（planner）は、成功した記録から手順を抜き出して手順書（runbook）にまとめる。点検役（critic）は、その手順書に検証器の中身や解答そのものが漏れていないかを調べ、問題があれば手順書を書き直させる。これを繰り返すのが「再帰的」の意味である。実行役（executor）は、点検を通った手順書に従って、新しいサンドボックスで一般的なハーネスの下で作業をやり直す。

点検役の役割が重要なのは、手順書に答えや採点の仕組みが混ざると、やり直しの成功が見かけだけのものになるからである。手順書を経由させることで、補助の効果は手順として残しつつ、補助そのものは本番と同じ条件から外す、という設計になっている。

3. abstract の範囲で示されたこと

著者らは、自分たちで集めた約 3K の端末作業の課題を使った。三つのハーネスを合わせると 759 の課題が解け、これは記録された中で最も強い単独のハーネスより 34.3% 多かった。複数のハーネスを使うこと自体が、成功の幅を広げたことになる。

RSR は 2,001 の成功した元の記録を、11,094 の書き直した記録に広げ、教師あり微調整に使った。この記録で学習したモデルは、元の基盤モデルよりも、元の記録をそのまま微調整に使った場合よりも良かったと報告されている。

評価には、端末作業のベンチマークである Terminal-Bench の系列が使われている。[4]基盤モデルとの比較では、pass@3 が Terminal-Bench 2 で 57.0% から 74.2% に、Terminal-Bench 4 で 1.5% から 9.1% に、著者ら自作の Terminal-Bench Hard で 39.0% から 63.0% に、同じく自作の Software Terminal-Bench で 3.0% から 6.0% に上がった。Long-Horizon Terminal-Bench での過程報酬は 0.21 から 0.29 に上がった。元の記録をそのまま微調整に使った場合との差の大きさは、abstract には書かれていない。

4. 具体例で見る ── 社内システムの作業を任せるエージェント

社内のデータ処理基盤で、決められた変換と検証の作業をエージェントに任せる場面を考える。

開発担当：評価環境では難しい作業もかなり成功しています。専用の誘導と追加の道具を付けた設定だと、うまく解けるんです。

品質保証：本番の環境にも、その誘導と道具は入りますか。

開発担当：入りません。本番は標準の道具だけです。だから成功した記録を学習させて、標準の道具だけでも解けるようにしたいと考えています。

品質保証：その記録に、評価用の正解や検証の仕組みが紛れ込んでいないかは確かめましたか。混ざっていれば、学習したモデルは正解を見ながら解く癖を覚えるだけです。それと、学習後の評価は、学習に使った課題と同じ出どころの課題だけで済ませないでください。

この会話は、RSR の三つの役割に対応している。成功を手順として抜き出すこと、正解や検証器の漏れを点検すること、標準の環境でやり直させること。最後の指摘は、次の節で述べる限界とも重なる。

5. 新しくない部分と、abstract から読み取れない限界

モデルが自分で出した成功例を集めて学習し直す考え方は新しくない。推論の分野では、正しい答えに至った自分の推論を集めて学習する方法が以前から知られている。[5]複数の候補から成功したものを選んで教師データにするやり方も、広く使われている。この論文の寄与は、補助付きの成功と本番の条件のずれに焦点を当て、手順書を経由して書き直し、漏れを点検する工程を組んだ点にある、と読める。

限界はいくつかある。第一に、学習に使った課題は著者らが自分で集めたもので、評価に使った四つのベンチマークのうち二つも自作である。学習と評価の課題が同じ出どころに偏ると、改善が実際以上に大きく見えるおそれがある。第二に、漏れの点検は点検役のモデルが担っており、その見落としがどの程度あるかは abstract には示されていない。第三に、Terminal-Bench 4 や Software Terminal-Bench のように、元の成功率が低い課題では、上がった後の値も低い。難しい課題を解けるようになった、と言えるほどの水準ではない。第四に、比較は主に一つの基盤モデルについてであり、他のモデルで同じ効果が出るかは分からない。公開の実装も、abstract の範囲では確認できない。

6. この主題が、いま束になっている理由

この論文は、Hugging Face の Daily Papers で 74 の upvote を集めた。[2]当サイトの選定では、読者の票の系統と束の系統の二つが立ち、同じカテゴリの論文 2 本が一つの束にまとまった。upvote は読者が「読む価値がある」と投じた票であって、正しさや重要さを保証するものではない。

束に入ったもう一本は VeriHarness である。こちらは、長い作業をこなすエージェントの出力を、参照解答や採点基準なしでどう検証するかを扱い、生成に使うのと同じ LLM に作業場と証拠を集める道具を与えて検証役にしている。[3]RSR が学習データを作る側、VeriHarness が出力を確かめる側という違いはあるが、どちらも同じ基盤モデルのまま、周りの道具立てを工夫して長い作業の質を上げるという問いに立っている。当サイトでも直近、端末エージェントやハーネスの設計を扱うプレプリントを続けて取り上げており、この問いが複数のグループから同時に出ていることは確かである。ただし束の大きさは 2 で、主題として厚いとまでは言えない。

7. 製薬・規制の現場から見ると

製薬企業の中でも、データ処理や文書作成の定型作業をエージェントに任せる検討は進んでいる。この論文が扱う「評価の時の条件と本番の条件のずれ」は、そうした導入の妥当性確認で必ず問われる点である。

持ち帰れる点は二つある。一つは、評価で成功した時の環境と、本番の環境が同じかを確かめることである。評価時だけ特別な誘導や道具を付けていれば、その成績は本番の性能を表さない。もう一つは、学習データに正解や検証の仕組みが漏れていないかを点検し、その点検を記録に残すことである。学習に使ったデータの出どころと点検の結果を残しておけば、後からモデルの振る舞いを説明する必要が生じた時に役立つ。手順書を経由して書き直すという RSR の設計は、作業の手順を文書として残す点で、標準作業手順書に基づく運用とも相性がよい。

この論文はプレプリントであり、ここで述べた運用上の示唆も、この論文の範囲から読める範囲にとどまる。