RSIHub：エージェントの自己改善手法を共通基盤で比較するフレームワーク

ここでいう自己改善は、エージェントが実行結果を手掛かりに、プロンプト、スキル、ツールや処理の組み合わせを改訂することだ。モデルの学習だけを指す言葉ではない。どの失敗を調べ、何を直し、どの候補を次の改善の出発点にするかが、研究対象になる。

ところが、手法ごとに候補の作業領域、実行、評価、中断からの復旧、履歴管理まで作り直すと、改善方針と実験基盤が一体化する。成績差が改訂方針によるものか、実行や評価の違いによるものかを追いにくい。RSIHubが扱うのは、この比較の土台である。

銀行業務のベンチマークで、エージェントの指示文やスキルを改訂する実験を考える。新しい候補の点数が上がっても、どの変更を評価したのか、評価条件まで変わっていないかが分からなければ、改善の意味を判断しにくい。以下ではこの状況を手掛かりに読む。ただし、ベンチマークでの成功を実際の金融判断への適性と読み替えることはできない。

RSIHubの中心は、改善方針を「レシピ」と交換可能な「オペレーター」で表し、評価と記録を共通基盤に置く設計だ。レシピは各段階の処理や設定を宣言する。オペレーターは候補選択や改訂など、それぞれの役割を担う。

もう一つの重要な指定がsurface、つまり変更を許す資源の範囲である。指示文を直す実験なら、何を指示文として編集できるのかを定め、実際の変更と照合する。評価器や保護された結果記録は、この変更範囲から切り離される。改善の途中で採点の仕組みまで書き換わることを防ぐためだ。

これにより、何を変えてよいかと、どう成績を確定するかを区別できる。ただし、記録が保護されることと、測定対象が広く有用であることは別の問題だ。評価器を保護しても、ベンチマークへの過適合や、評価仕様の広い意味での悪用まではなくならない。

タスクは三つに分かれる。trainは改善のための実行、gateは候補を採用するかの判断、sealedは改善へのフィードバックから外した未見評価に使う。sealedの結果は親候補の選択に使わない補助的な証拠として扱われる。銀行業務の例なら、改訂に使った課題への適応と、改訂に使わなかった課題への転移を分けて見るための構成だ。

主指標のpass@1は、各タスクを1回試した成功を集計する。総合値は全タスクに対する成功率だ。一方、論文の主結果表にある分割別の値は、その分割の成功数を全ベンチマークのタスク数で割った「寄与」である。

この違いは結論に直結する。sealedの値が下がったとき、それは未見分割の成功数が総合成績に占める寄与の低下を意味する。その数値を、そのままsealed内の成功率の低下幅として読むことはできない。総合点だけでは、どの分割で改善し、どの分割で悪化したかも見えなくなる。

改善の一巡は、記録済みの適格な親候補を選ぶところから始まる。その親から分岐し、訓練タスクの実行を証拠として改訂する。基盤は実際の差分がsurface内かを調べ、必要に応じた検証や重複除去を経て、候補の確定版を保存する。

次に、作業途中の変更が混ざらない状態で保護された評価を行い、その結果を認証する。ここでの認証は、結果を候補と評価条件に対応付けて確定する役割を持つ。その後、Gateという採否判断の処理が、次世代の親として使えるかを決める。評価未完了や判断待ちの候補は親にできない。

来歴には候補と親、レシピ、評価器、タスク集合、モデルや実行条件、試行、スコア、費用、成果物が結び付く。補助注釈も保護された結果欄とは分離する。したがって、銀行業務の候補が高得点になった場合に、その点数を生んだ指示文や条件へ戻って調べる経路が残る。

著者らはAHE、Hyperagents、A-Evolve、GEPAの四つを適応した。AHEは実行証拠に基づく対象エージェントの改訂、A-Evolveはプロンプトとスキルの改訂を扱う。GEPAは実行の振り返り、候補選択、小さなタスク集合による改善検証を組み合わせる。Hyperagentsでは対象エージェントに加え、選択された改善処理自体も変更する。

つまり、共通基盤に載せても、各手法が編集する範囲や改善方針は異なる。これは原実装の完全再現でも、一つの要素だけを変えて効果を切り分ける包括的なアブレーション実験でもない。原手法との一致には、プロンプト、モデル、予算、依存関係、実行の接続方法も関係する。

著者らは4手法とも基盤本体を変更せず構成し、各手法の統合テストが通ったと報告した。ただし手法固有コードは必要だった。共通化できたことを示す証拠ではあるが、別の基盤と比べて開発時間や工数を削減できたという比較ではない。

主実験はMiniSWEとCodexという二つの対象エージェントを使う。Terminal Bench 2は89タスクで、train、gate、sealedの順に50、19、20。τ³ Bankingは97タスクで、同じ順に50、20、27へ分けた。比較の基準は、それぞれの未進化エージェントであるseedだ。

対象モデルはGPT-5.4のhigh設定、改訂役はCodexを使うGPT-5.4のxhigh設定に固定した。MiniSWEは2.4.5、Codexは0.143.0を使用する。訓練タスクのサンプリングは静的にし、各世代に1候補、最大10世代、各タスク1試行のpass@1で評価した。

この条件固定は、共通基盤上での比較を支える。一方、異なるモデルや業務でも同じ順位になるかは調べていない。また、基盤には外側のエージェントが反復間にレシピを改訂する経路もあるが、主実験で評価したのは固定レシピだけだ。改善手続きまで適応的に組み替える効果は、この結果からは分からない。

基盤をそろえても、基盤を通すことで挙動が変わる可能性は残る。そこで著者らは、未変更のseedを「直接実行A、RSIHubの初期世代、直接実行B」の固定順で動かし、これを3反復した。Avg@3はpass@1の平均で、直接実行側は各反復のAとBを平均する。

Terminal Bench 2では、MiniSWEが直接実行59.6%に対してRSIHub56.9%、Codexが64.0%に対して61.4%だった。著者報告の差はいずれも−2.6パーセントポイントである。τ³ BankingではMiniSWEが24.6%対22.0%、Codexが29.6%対33.0%となり、差の方向も一様ではなかった。

タスク単位でも、Terminal Bench 2のCodexでは直接実行同士の一致率88.0%に対し、直接実行とRSIHubの平均は82.0%だった。直接実行同士にも全設定で12.0〜18.9%の不一致がある。これは実行の変動と差を記述する対照であり、実行モードの同等性や、主実験の改善幅の統計的有意性を確立するものではない。

著者らの主評価では、Terminal Bench 2のMiniSWEはseedの総合pass@1が56.2%だった。AHEは65.2%、HyperagentsとA-Evolveは69.7%、GEPAは64.0%で、4手法ともseedを上回った。最大改善は13.5パーセントポイントである。これは成功率の差であり、相対的に13.5%増えたという意味ではない。

同じベンチマークでも、Codexのseedは69.7%だった。AHEは71.9%、HyperagentsとA-Evolveは70.8%、GEPAは69.7%となった。出発点が変われば改善幅も順位も変わる。

τ³ Bankingでは、MiniSWEのseed27.8%に対してHyperagentsが33.0%だった。Codexではseed24.7%に対してAHEが34.0%、GEPAが33.0%となった。これらは固定条件下で観測された結果であり、特定手法が常に最良だという証拠にはならない。特に近い差は、反復なしでは安定性を判断できない。

銀行業務の例で最も判断に効くのは、総合点とsealedのずれである。τ³ BankingのMiniSWEでは、Hyperagentsによって総合値が27.8%から33.0%へ5.2パーセントポイント上がった。一方、sealedの寄与は9.3%から7.2%へ2.1パーセントポイント下がった。AHEとGEPAでも、sealedの寄与差はそれぞれ−4.1、−2.1ポイントだった。

このsealed値の分母は全97タスクであり、未見分割だけの成功率ではない。それでも、総合成績の上昇が未見タスクでの改善を保証しなかった、という観察は残る。改善に使う課題で成果が出ても、その成果が別の課題へ同じように移るとは限らない。

ただし、この観察だけで悪化の原因を特定することはできない。主結果は各タスク1試行の記述的な点推定で、手法ごとに変更範囲も異なる。特定の改訂方針が未見性能を下げたと断定するには、反復と、変更要素を切り分ける比較が必要になる。

成績以外に、基盤が不適切な状態を受け入れないかも試した。著者らは中断3種、評価器改変、許可範囲外の編集、保護証拠へのアクセス、記録偽造という7シナリオを、二つのベンチマークで各30回実行した。計420試行すべてで要求状態に到達し、破損状態の受理は0件だったと報告する。復旧後の状態は、中断なしの対照と比較した。

これは、試した境界で復旧や記録保護が働いた証拠である。あらゆる環境や攻撃に対する保証ではない。証拠の信頼性は、フレームワーク、ホストとファイルシステムの保護、Gitやダイジェスト操作、外部サービス、有効な評価器への信頼に依存する。

RSIHubは監査とロールバックを支えるが、敵対的コードを封じ込める仕組みではない。編集可能な改善処理などはホスト上で動き得る。高いpass@1や銀行ベンチマークの成功と、安全な本番運用の証明は区別する必要がある。

RSIHubが向くのは、信頼できる実行環境で、候補の差分、実行の軌跡、採否、評価条件を追跡する実験だ。同じ条件を保ち、親選択など一つの改善方針を別実験で差し替えれば、成功や失敗の理由を調べやすくなる可能性がある。今回の4手法比較そのものは、その一要素比較を完了したわけではない。

次に見るべき証拠は、近い成績差やsealedの悪化が反復でも続くか、変更範囲をそろえても方針の差が残るかである。実行モード間の違いが残る理由と、適応的にレシピを改訂する経路の効果も未確定だ。

本論文の成果は、最大改善幅に加え、改善候補と測定条件を結び付けて検査できる共通の経路を示した点にある。その経路があっても、未測定のモデルや業務への効果、一般的な手法の優劣、安全性は別途確かめる必要がある。