AIにコーディングやターミナル作業を任せてみると、不思議なことが起きる。同じAIなのに、ある日はすらすらこなし、ある日は同じ場所で足踏みする。性能を引き上げようと手を加えても、いつも同じ壁の前に立たされる。今直したものは本当に実力を伸ばしたのか、それともこの問題だけに効く小手先の技を一つ覚えただけなのか。
ModularRSIはこの問いから逃げない。核心となる発想はこうだ。AIが自ら直した実力が本物かどうかを知りたければ、頭脳の役割を担うAIモデルをまるごと差し替えてみればいい。小手先の技ならモデルと一緒に蒸発し、実力なら残る。この「乗り移る性質」（モデルや課題を変えても性能が維持される汎化可能性）が、この論文の中心だ。そこへどうたどり着いたのかを追ってみよう。
まず用語を一つ。エージェントハーネス（harness）とは、AIの中核エンジンであるLLM（人の言葉で問いかけ答えるAIモデル）そのものではない。そのエンジンを包んで実際に仕事をさせる「実行装置」だ。どんな順序で考え動くか、どの道具をいつ取り出すか、観察した結果から何を汲み取るか、仕事が終わったかをどう判断するか——この「働き方の骨組み」がすべてハーネスである。
厨房にたとえるとわかりやすい。LLMは料理人、ハーネスは厨房の動線と道具の配置だ。料理人がどれほど腕利きでも、動線がこんがらがり包丁が見当違いの引き出しに入っていれば、料理は遅くなる。エージェントの実質的な性能は、料理人の腕と同じくらい厨房の設計にかかっている。
再帰的自己改善（RSI）とは、まさにこの厨房をエージェントが自ら手直しすることだ。自分の実行記録から失敗を拾い出し「このやり方が問題だった」を突き止め、次の動線を自ら変える。人ではなくエージェントがやる、というのが肝心な点だ。最近の研究は、長い呼吸のコーディング・ターミナル作業でこれを実際に試し始めている。
問題は、この自己改善が見当違いの場所を直しやすいことだ。論文は三つの落とし穴を指摘する。
| 従来方式の落とし穴 | なぜ「本物の改善」と取り違えるのか |
|---|---|
| 試験問題（ベンチマーク）でハーネスを直すと | その試験の点数だけが上がり、初めて見る仕事には通じない「小手先の技」かもしれない |
| 一度の試行だけを見て直すと | 骨組み自体の欠陥なのか、その仕事一つの特殊な事情なのかが入り混じる |
| 一体化したハーネスをまるごと直すと | どの変更が効いたのか突き止められず、無関係な機能同士がもつれ合う |
三つの落とし穴は結局一つに集まる。直すべき場所と根拠をぼやけさせる、ということだ。的が見えなければ、命中したかどうかもわからない。
ModularRSIは落とし穴一つに処方箋を一つずつ貼り付ける。
第一に、練習問題と試験用紙の出どころをそもそも切り分ける。外部で実行可能な練習用タスク2,000個を集めつつ、後で性能を測るベンチマークとは重ならないようにした。練習帳と本番試験が同じ出どころなら、点数が上がってもそれが実力なのか漏れた答えを覚えただけなのか判別できない。出どころを引き離してこそ、その区別がつく。
さらに、成功した試行と失敗した試行を並べて比較する方式を通じて、たまたま一度の失敗ではなく身についた「悪い癖」を見分ける。二つの記録の差を見れば「このタスクだけにあった事情」はふるい落とされ、「働き方そのものの欠陥」が際立つ。成功した対がない失敗は単独でも診断し、すべて成功したタスクでも、より速く終える余地があれば効率に手を入れる。そして、どの修正を受け入れるかを選ぶときは、複数のタスクでともに支持される修正案を優先する。一つのタスクにだけ当てはまる修正より、複数の場所で通じる修正のほうが「小手先の技」より「実力」である公算が大きいからだ。
そして、骨組みを五つの部品に切り分けて別々に直すという点が最大の特徴だ。まるごと直すと何が効いたのかわからないので、ハーネスを五つのモジュールに分ける。
各モジュールは定められた範囲の中だけで独立に手を入れる。直す部品を隔離するので、どの変更が何の効果を生んだのかが追跡でき、無関係な機能が巻き添えでもつれることが減る。別々に仕上げたモジュールは、最後に一つのハーネスへ束ねる統合段階で互いの衝突を調整する。
実験は二つの試験台で回った。SWE-Bench Verifiedは実際のソフトウェアのバグを見つけて直すコーディング能力を、TB2.0はターミナルでコマンドを組んで仕事を終える能力を測る標準ベンチマークだ。
改善されたハーネスは、三つの方向すべてで利得が残った。何を変えてみて、それが何を証明するのかを表に整理するとこうなる。
| 変えてみたもの | 何を試すのか | 結果が語ること |
|---|---|---|
| 同じ分野の初めて見るタスク | 覚えた答えではないか | 練習になかった問題にも通じる |
| 別分野の初めて見るタスク | 一分野に閉じた小手先の技ではないか | 分野を越えて乗り移る |
| 基盤モデル（料理人）を交換 | 特定モデルの癖に合わせたものではないか | モデルが変わっても利得が残る |
最後の行がこの論文の心臓だ。ある改善が特定モデルの癖だけに合わせたものなら、料理人を差し替えた瞬間に一緒に消える。ところがModularRSIが仕上げた厨房は、別の料理人を立てても一層よく回った。直しておいたものが「このモデル、この試験用の小手先の技」ではなく「働き方そのもの」だった、という意味だ。
正直に断っておくべきこともある。この結果は「どれだけ」良くなったかではなく「どこまで乗り移るか」を語る。向上の幅が何点なのかは原文の数値表を覗き込まねばならず、この記事だけでは判断できない。それでも自己改善の研究がずっと証明したかったのは、そもそも幅ではなくこの一般性だった。幅が大きくても一つのモデル・一つの試験に閉じれば「小手先の技」であり、幅が小さくてもモデルと分野を越えて残れば「実力」だ。ModularRSIが示したのは後者のほうだ。
この悩みは、私たちONTLEがつくる「AIプロジェクトマネージャー」の日常とほぼ重なる。AI PMは典型的な長い呼吸・多段階のエージェントだ。複数の道具を呼び、観察したものを汲み取り、狭い文脈の中で状態を握り、「この仕事は終わったか」を自ら判断する。論文が切り分けた五つのモジュールが、そのまま私たちの悩みの一覧でもある。
一つの場面を最後まで追ってみよう（まだ設計段階の仮定だ）。顧客が作業の途中で納期を前倒ししてほしいと言ってくる。AI PMがこの変更を日程にだけ反映し、すでに進行中だった成果物の範囲には手をつけないまま「反映完了」を宣言したとしよう。変わった納期に合わせるなら範囲も調整し直すべきだったのに、そこまでたどり着けなかったのだ。
プロンプトをまるごと作り直したい衝動をまず抑える。先に的を絞る。この失敗は「タスク完了の判断」モジュールの問題に見える——変わった条件をすべて反映する前に終わりを宣言する癖だ。だが一件で決めつけはしない。論文の筋に倣い、複数の顧客・複数のセッションログを掘って、同じ「性急な終了」が別の場所でも現れるかどうかから見る。一度きりならその顧客だけの事情かもしれず、複数の場所で重なればそのモジュールに手を入れる根拠がより固くなる。直した後は、今回手をつけていない別の顧客業務で同じ失敗が減ったかどうかで効果を測る。自分の試験で自分の厨房を仕上げればいつもうまくいくように見えるので、検証は手をつけていない仕事でやらねばならない。
ただし論文をそのまま写しはしない。五つのモジュールはコーディングエージェントに合わせて分けられたものであり、AI PMには筋の違う部品が必要かもしれない。たとえば「顧客意図の把握」（言葉の裏にある本当の要求を読み取る段階）や「中間報告の生成」（進行状況を顧客の言葉でまとめて送り出す段階）といったモジュールは、コーディングのベンチマークにはないが私たちの現場にはある。
論文がくれたのはコーディング用のハンマーだ。私たちはその握り方——モジュールに切り分け、複数の場所で重なる修正を優先し、手をつけていない仕事で検証するという筋——を持ち帰り、PM業務用のスパナを別に鍛え上げる番だ。
論文が練習用のタスクを「実行可能な」ものとして選んだ理由がここにあります。コードが動いてテストが通るか、ターミナルのコマンドが狙った結果を出したかは、機械が客観的に判別します。人が一つひとつ採点しなくても成功と失敗がはっきり分かれるので、その差から「悪い癖」を自動で抜き出せるのです。
その危険を減らすために、設計そのものが保守的です。直す修正を選ぶとき、複数のタスクでともに支持されるほうを優先し、性能は練習と重ならない試験用紙で測るので、一度の運に振り回されて見当違いの場所に手を入れる余地が小さいのです。ただし、すべての退行を防げると論文が保証したわけではありません——だからこそ、手をつけていない仕事で改めて確かめる検証段階が最後に残されています。
そうではありません。より良い料理人を立てれば、同じ厨房でも料理はもっとうまく仕上がります。この論文が言っているのは「モデルはどれも同じ」ではなく、厨房をよく直しておけばその改善分が料理人を変えても乗り移っていく、ということです。良いモデルと良いハーネスは、二つのうち一つを選ぶ問題ではなく足し算なのです。