1. この論文は何を問題にしているか

問題は、自分で自分を改善する AI システムの「伸び」が本当に能力の向上なのか、それとも評価に使った場面に合わせ込んだだけなのかを、いまの評価では見分けられないことである。著者らが対象にするのは再帰的自己改善（RSI）と呼ばれる仕組みで、システムが自らの作業手順を書き直し、さらにその書き直しを導く戦略そのものも改善していく。著者らによれば、こうした仕組みは汎用人工知能への進歩を早める手段として期待を集めており、改善が未知の場面にも広がることを目指している[1]。

ところが評価の側には三つの不足があると、著者らは指摘する。能力の向上と場面への適合を区別する信頼できる指標が無いこと。未知の課題や難しさに向けて、持続的に拡張できる評価手順が無いこと。そして、改善を進化の過程のどこに帰属させるかを細かく分析する手段が無いことである[1]。つまり、点数が上がっても、その理由が学習なのか慣れなのかを区別する手段が無い。本記事が扱うのは arXiv に公開された査読前のプレプリントであり、以下は著者らの主張として読む。

2. 何を提案しているか

芯は、改善が訓練時の条件からどこまで離れても保たれるかを、段階に分けて測ることである。著者らは SelfImprove-Bench という評価枠組みを提案し、この段階を「汎化のはしご」として G0 から G4 までの水準に整理した。課題ごとの点数とは別に、得られた改善がどの水準まで転移するかを見る設計である[1]。

課題は三つの基本能力、すなわち探索（Exploring）、計画（Planning）、推論（Reasoning）に分けられ、それぞれがモデルの進化を導く場面として使われる。課題はゲームの上に実装されている。著者らはその理由を、条件を制御しやすく、結果を再現しやすいからだと述べる。さらに、課題のひな形と難易度の係数によって課題を生成・編成するしくみを組み合わせ、評価を広げられるようにしたという[1]。各水準が具体的にどのような条件の違いに対応するのかは、abstract には書かれていない。

3. 何を示したか ── abstract に書かれた範囲だけ

abstract が報告する結果は一つである。既存の再帰的自己改善の手法が得た進化上の改善は、汎化の水準をまたぐと一貫しなかった[1]。

この一文から読み取れることと、読み取れないことを分けておく。読み取れるのは、訓練の条件に近い水準で見えた改善が、条件を離した水準でも同じように現れるとは限らなかった、という方向の所見である。読み取れないのは、どの手法をいくつ比べたのか、どの水準で改善が消えたのか、逆に改善が残った手法はあったのか、そして差の大きさがどれほどか、である。abstract には数値が一つも示されていない。したがって「既存手法の改善は見かけだけだった」とまでは言えない。著者らの言葉は「一貫しない」であり、それ以上の強さで読むべきではない。

三つの能力のうち、どれで不一致が目立ったのかも書かれていない。能力を三つに分けた設計の価値は、能力ごとの違いが示されて初めて評価できる。abstract の範囲では、その判断材料が無い。

4. 具体例で見る

自己改善するエージェントを業務で試すとき、評価の担当者と開発の担当者の間で起きうるやりとりを考える。以下は説明のための仮定であり、論文の実験ではない。

開発担当:「改善を何度か重ねた結果、試験用の文書の束で、記載の不備を指摘する精度が上がりました」
評価担当:「その試験用の文書は、改善の途中でエージェントが参照したものと同じ種類ですか」
開発担当:「同じ種類です。様式も書き手も共通しています」
評価担当:「では、様式が違う文書、書き手が違う文書、扱う論点が違う文書の順に、条件を離して試してください。どこまで改善が残るかを見たいのです」
開発担当:「条件を離すほど、改善の幅は小さくなるかもしれません」
評価担当:「それなら、どこから小さくなるかが、このエージェントに任せられる範囲の目安になります」

課題ごとの点数だけで見る

改善の前後で点数が上がったかは分かる。しかし、上がった理由が能力の向上なのか、評価に使った文書への適合なのかは区別できない。

転移の段階で見る

訓練の条件からの距離ごとに改善が残るかを確かめるので、任せてよい範囲を条件の言葉で書ける。ただし、段階の区切り方で結論が変わるおそれがあり、区切り方そのものの妥当性を別に確かめる必要がある。

SelfImprove-Bench の G0〜G4 は、この「条件を離していく」考え方を、ゲームの課題の上で段階として定めたものと読める。ゲームでの段階と業務での段階が同じ意味を持つかは、別の問題である。

5. 何が新しくないか／限界はどこか

訓練と異なる条件で性能を測るという発想そのものは新しくない。機械学習では、学習に使った分布の外でどれだけ性能が保たれるかを調べる研究が長く続いてきた。この論文の新しさは、その考え方を、手順や戦略を自分で書き換える再帰的自己改善の評価に、段階のある形で持ち込んだ点にあると読める。ただし、既存の汎化の評価と比べて何が加わったかは、abstract では論じられていない。

6. この主題が今なぜ束になっているか

選定の記録では、この論文は大きさ 2 の束の代表である。束に入ったもう一本は、身体を持つエージェントの物理的な知能を評価する TriPhysBench である[2]。TriPhysBench は、映像の観察、物理の知識の想起、量についての推論を組み合わせられるかを試すベンチマークを示し、検索・計算・道具からの返答を連携させる学習方法によって、訓練に使っていない映像での正答率が上がったと報告している[2]。立った系統は論文を書く研究者の側だけで、upvote も GitHub のスターも 0 だった。読者の票や実装の追随は、選定の時点では見られない。upvote やスターは話題性の目安であって正しさの目安ではないが、その話題性すらまだ立っていない段階である。

二本に共通する keywords は evaluating、generalization、agents などである。どちらも、エージェントが「できた」と言える範囲を、訓練で見た条件の外まで含めて確かめようとしている点で重なる。再帰的自己改善については、改善が本物であること、制約を守ること、監督できることを保つ観点から整理したサーベイも先に出ている[3]。SelfImprove-Bench は、その中の評価の部分に具体的な道具を出した一本として位置づけられる。ただし、束は語彙の近さで機械的にまとめたものであり、二本が同じ問いに答えているわけではない。この束から研究の流れの強さを判断することはできない。

7. 製薬・規制の現場から見ると何が接続するか

接続するのは、システムを使ってよい範囲を、検証した条件の言葉で書くという要請である。製薬の業務でコンピュータ化システムを使う場合、意図した用途に対してシステムが期待どおりに動くことを確かめ、その範囲を記録に残すことが求められてきた。自分の手順を書き換えるエージェントは、確かめた時点の状態から変わっていく。そのため、一度の評価で得た点数は、そのまま使用範囲の根拠にはなりにくい。

この論文から立てられる確認項目は三つある。改善を評価した条件と、実際に使う条件はどれだけ離れているか。条件を離していったとき、どこで改善が失われたか。そして改善が起きたとき、それを手順のどの書き換えに帰属できるか。三つ目は変更管理の考え方に近い。何が変わって結果が変わったのかを説明できなければ、変更を承認する根拠が立たない。エージェントを動かす仕組みの側についても、実行の記録から失敗の原因を特定する評価が別に提案されている[4]。

ただし、この論文は製薬や医療の課題を扱っておらず、規制上の要件も検討していない。ここから言えるのは、自己改善するシステムを評価するときの観点の立て方までである。SelfImprove-Bench を通ったエージェントであれば業務に使ってよい、とは言えない。

改善したかではなく、どの条件まで改善が残ったか、そしてその改善がどの書き換えから来たかを確かめる。