エージェントのなかでモデルが担う仕事は、思ったより狭い。次に何を言うか、どの道具を呼ぶかを「提案」するだけだ。その提案を実際の実行に移すのは、モデルを包むソフトウェアである。このソフトウェアが、モデルにどんな情報を見せるか、どの道具をどんな順番で使わせるか、いつ止めるかを決める。これをハーネス(harness)と呼ぶ。モデルが同じでも、ハーネスが違えばエージェントはまるで別物のように動く。
だからエージェントをより賢くする道は二つしかない。モデルそのものを学習し直すか、モデルを包むハーネスを直すか。この論文は二つ目の道だけを掘る。モデルの重みには一切手を触れず、プロンプト・メモリ・ワークフロー・実行コードだけを実行結果を見て自ら直し、その修正版を次の実行にそのまま引き継がせる過程を、きちんと定義する。
驚くのは、ハーネスをうまくいじるだけで、小さいモデルが大きいモデルを追い抜く場面が出てくることだ。だが、この論文が本当に力を注いだのはその反対側である。自ら直し続けていると、直したものが本物の改善なのか、それともその評価問題だけに小器用に合わせただけなのかが区別しづらくなる。良さそうに見える修正が、実は過去にうまく動いていたものを静かに壊しているかもしれない。この錯覚をどう濾し取るか — それがこの記事を最後まで引っ張っていく問いだ。
性格をあらかじめ断っておくと、この論文は新しいシステムを作ってベンチマークをなぎ倒すたぐいのものではない。「自己進化するハーネス」という分野を定義し、散らばった手法を分類し、信頼性の条件をPAC-learning(少ない標本からでも高い確率で、初めて見るデータでも通用することを保証しようとする統計的学習理論)から導く、66ページの総合的な議論である。後半に出てくる実験の数値も、著者らが自分で回したものではなく、先行研究から持ってきて例として添えた事例だ。数字は「こういうことが観測された」という事例として読むべきだ。著者らはこの分野を「ハーネスRSI(recursive self-improvement、再帰的自己改善)」と呼びながらも、名前に「改善」が入っているからといって、修正のたびに役立つと前提しているわけではない、という但し書きをはっきり付けている。
デプロイを終えたエージェントは止まっていない。扱う業務が変わり、環境が変わり、評価基準も変わる。最初に設計したプロンプトとワークフローが三か月後も最善だという保証はない。ここで適応の選択肢が分かれる。
一つはモデルの重みをもう一度いじる道だ。性能は上がりうるが、再学習のコストがかかり、チェックポイントが積み上がり、モデルがなぜ変わったのかを追うのが難しい。商用APIの裏にあるモデルは、そもそも重みへのアクセスが閉ざされている。もう一つがハーネスを直す道だ。固定されたモデルの振る舞いを実際に形づくるのは結局ハーネスであり、既存のデプロイをそのまま使い回すので再学習もチェックポイントも要らない。何より、指示文・メモリ・コードは人が目で開いて読み、バージョンを比較し、変更を追える。重みのdiffとは違う。
この道そのものは新しくない。ルーツが二つある。一つはEURISKOで、経験に従ってルールを直していった。もう一つはGödel Machineで、「利得が証明されたときだけ」自分のコードを書き直させた。近ごろの手法(Reflexion、ExpeL、Voyager、AFlow、GEPA、Promptbreedのような系統)は、おおむね前者寄りだ。経験フィードバックでプロンプトを直し、メモリを固め、ワークフローを探索する。柔軟だ。ところが、まさにその柔軟さが空席を残す。経験で直した修正が本物の改善なのか、運よく当たっただけなのかを保証する方法がない。修正のたびに証明を要求すれば(Gödel Machine寄り)、現実のエージェントは一歩も踏み出せない。
しかも手法ごとに、何を直すのか、候補をどう作るのか、どんな基準で受け入れるのかがばらばらだった。だからこの論文は、まず共通の言語を立て、空いていた信頼性保証を「証明」の代わりに「統計的保証」で埋めようとする。経験の柔軟さは活かしつつ、どんな修正でも受け入れはしない、という線を引くのだ。
言葉より一つの場面が早い。エージェントがスプレッドシートの課題をこなしていて、出力チェックを飛ばして間違った結果を出したとしよう。その失敗がフィードバックとして残る。更新を担う側が原因を診断し(「出力チェックの段がない」)、修正案を提案し(チェックの段を追加)、新しいデータで評価し、良くなっていれば採択する。採択された修正は保存され、次の実行でロードされる。受け入れるに値する修正がなければ、既存のハーネスをそのまま置いておく。
これが一周だ。現在のハーネスが何度も実行(rollout)を回して、それぞれの軌跡・結果・フィードバックを集め、更新オペレータが診断・提案・評価・採択をまとめて行い、採択版が次の周へ渡る。二つの条件 — 自分の実行フィードバックから修正を作り、そのメカニズムを回し続けること、そして採択版が次の実行へ継承されること — この二つが満たされるときだけ「ハーネスの自己進化」と呼ぶ。固定のルールでログを足したりコンテキストを圧縮したりするのは、ここには入らない。自ら学ぶのではなく、決められた通りに回っているだけだからだ。
ハーネスそのものは七つのランタイム機能に分かれるが、暗記するより三つの束で掴んでおけばいい。
自己進化がいじるのは、結局このどこかだ。
論文は「何を直すのか」を二つに分ける。一つは解釈される状態(interpreted state) — 指示文、保存された経験、固定された能力の上で回る課題レベルの調整だ。もう一つは実行可能な修正(executable revision) — 能力の実装そのもの、リポジトリレベルの制御ロジック、プラグインとして束ねられるサービス構成を変えることだ。
たとえるなら、前者は料理人に渡すレシピカードを書き直す仕事で、後者は厨房の調理器具と配管を取り替える仕事だ。このたとえが教えてくれるのはただ一つ。指示を変えるのか、その指示を実行する装置を変えるのか。基準は、編集したファイルが何の言語で書かれているかではなく、その成果物がシステムで担う役割だ。同じワークフローの修正でも、固定されたインターフェースの上で順番だけ変えれば解釈される修正であり、その調整を実際に執行するランタイムのメカニズムに手を入れれば実行可能な修正になる。
一つだけはっきり切り分けておくべきことがある。修正の「種類」と「影響範囲」は同じ話ではない。レシピを一枚直しても、そのレシピが複数の店舗で共有されていれば、影響は店舗全体に広がる。影響範囲は、この修正が共有されているか、どこに適用されるかを別に見て判断しなければならない。実行可能な修正のほうが遠くまで広がりやすいのは確かだが、解釈される修正だからといって狭いところに留まる保証はない。
この論文の中心軸は理論だ。ところが、理論を名前で暗記する必要はない。原理を一つだけ手に握れば、残りはついてくる。
原理はこうだ。同じ評価問題を見ながら修正を重ねると、その修正はだんだんその問題だけに合っていく。試験を先に見て、その試験紙だけに合わせて勉強したようなものだ。だから採択の判定は、修正を作るときに使ったデータではなく、手つかずで新鮮な独立の検証データで行わなければならない。そこでも高い確率で改善が確認されたときだけ受け入れる — これが「高確率採択ルール」だ。評価データ上でだけ良さそうに見える修正を濾し取る網である。
二つ目は回帰(regression)の予算だ。回帰とは、過去に動いていた機能が静かに壊れることを言う。修正が一つずつ積もると、この壊れも積もる。だから「許容する既存機能の性能低下の上限」をあらかじめ決めておき、その範囲内でだけ修正を受け入れる。たとえば新しい業務の正答率は上がったのに、既存業務で動いていた一部が壊れたなら、その壊れた幅が決めておいた上限を超えた瞬間、その修正は保留する。新しい性能が良くなったという事実だけでは、採択の根拠にはならない。維持(retention)バウンドは、まさにこの累積回帰が予算の中で制御されるときだけ意味を持つ。ここに、明示された仮定の下での期待汎化バウンドまで、三つの結果が、候補探索を進化的最適化(evolutionary optimization、複数の候補を作り、良いものだけ残して次の世代へつなぐ探索)に対応させて導かれる。
最後に設計の原則を一つ。候補ハーネスは、内部の批評者や途中のチェックは直せるが、最終の採点・検証を担う評価者そのものには手を出せないように塞ぐ。採点表を握る手が受験者であってはならないからだ。この隔離がなければ、上の二つの網はまるごと無力になる。
ここで数字を見る番だが、先に言ったとおり、著者らの自前の実験ではなく、先行研究から持ってきた事例だ。どの研究のどの条件なのかを、特に注意して見るべきだ。
最初の事例は、SpreadsheetBench(スプレッドシート課題のベンチマーク)でのHarnessOptだ。スキル編集に留まっていたSkillOpt-Liteをランタイムの修正へ拡張し、スプレッドシートのプレビュー・出力チェック・道具の失敗後の復旧を改善した方法だ。先行研究(shen2026skilloptlite)の比率を換算した数値が、論文のTable 2にある。
| モデル | Initial | SkillOpt | SkillOpt-Lite | HO only | HO + skill |
|---|---|---|---|---|---|
| GPT-5.4-nano | 29.89 | 51.60 | 66.19 | 76.51 | 77.58 |
| GPT-5.4-mini | 28.21 | 47.50 | 73.31 | 81.14 | 82.56 |
| GPT-5.4 | 39.86 | 61.50 | 79.36 | 83.63 | 85.05 |
| GPT-5.5 | 37.37 | 76.20 | 79.72 | 83.63 | 85.77 |
ここに、記事の冒頭で話した場面がある。いちばん小さいGPT-5.4-nanoにHarnessOptとスキルを付けた条件(77.58%)が、より大きいGPT-5.5にSkillOptだけを付けた条件(76.20%)を上回る。四つのモデル全体で、HarnessOpt+スキルはSkillOpt-Liteより5.69〜11.39%p高かった。小さいモデルに良いハーネスを着せるほうが、大きいモデルに弱いハーネスを着せるよりマシになりうること — モデルとハーネスの組み合わせが、モデルの大きさと同じくらい結果を分ける、という信号だ。
ただし、この逆転が「同じコストでの優位」を意味するわけではない。小さいモデルが勝ったとしても、ハーネスを最適化するのにかかった計算コストまで合わせて比較した結果ではない。この数値が測っているのは特定の条件での正確度であって、コスト対効率ではない。
二つ目の事例は「Everything Is a Plugin(EIP)」だ。Codexプラグインが、実行の途中で必要な道具を自ら作り、その後の課題に再利用する。模擬の事務作業では、地域別のスプレッドシートは言語と内容は違っても計算は似ていて、Codexは一括照会・要約の道具を作り出した。そのおかげで最初の課題の道具呼び出しが13回から3回に減った。代わりに道具を作るぶん、最初の課題ではトークンと時間が余計にかかった — 初期投資というわけだ。その投資は二つ目の課題から回収され、五つの課題を累積すると、トークンと時間を節約する側へと転じる。ただし著者らは、最初の課題の集計と累積の集計の数字が互いに食い違っていて、両者を一本の費用の軌跡としてつなげて語ることはできない、と明示している。^1 道具を作る初期費用と、その後の再利用の利得が核であり、その二つを一本の線で描くことはできない、という但し書きまでが、この事例から持ち帰れるすべてだ。
ONTLEは、人を増やして雇えず反復業務が積み上がる小企業や、一人で起業した人に向けて、その反復業務をAIが代わりにこなすよう付けてあげるサービスだ。一つの場面を最後まで追ってみよう(実運用ではなく、適用のシナリオだ)。
ONTLEのAI PMが、複数の顧客企業で「週次の進捗報告の作成」を担っているとする。A社から「報告が長すぎる」というフィードバックが返ってくると、PMは報告テンプレートのプロンプトを「要点3行＋リスクのセクション」に直す。論文の用語でいう解釈される状態の修正だ。さらに進んで、進捗データを引っ張ってくる照会の道具を新しく作り、報告生成のパイプラインに差し込めば、それは実行可能な修正、なかでもプラグイン構成に近い。
この論文が変える地点は「その修正をいつ信じて、ほかの顧客企業へ広げるか」だ。A社のフィードバックで作った修正版は、A社で使ったまさにそのデータではなく、手つかずの別の週ぶんで検証を通してから採択する。そしてB社へ渡す前に、その修正がB社の既存の報告品質を削らないかを、回帰の予算の中で確認する。A社に合わせて短く縮めたテンプレートが、規制報告が重要なB社ではかえって必須の項目を抜け落とさせる回帰になりうるからだ。
だからこの事例が残すのは「ONTLEはうまくやる」という結論ではなく、いますぐ解くべき設計の問いだ。顧客企業ごとに「抜かしてはいけない必須項目」は、誰が決めて誰が評価するのか。すべての顧客企業に共有される共通テンプレートの修正と、一社だけに適用する修正は、どこで分けるのか。評価基準が顧客企業ごとに違うなかで、「新鮮な独立の検証データ」は現場ごとにどう確保するのか。この問いに答えを持つ組織だけが、自己進化を実際にオンにできる。
この論文の成果は、特定のスコアではなく枠組みにある。散らばっていた手法を「何を直すのか(更新の対象)」と「どう提案・採択するのか」という二つの軸に分け、経験的な選択だけでは汎化も維持も保証されないという点を、統計的保証で受け止めたことだ。
限界も同じ場所にある。理論のバウンドはすべて明示された仮定の下でだけ成り立ち、実験は先行研究から借りてきた事例なので、この枠組みが統制された条件で再現した結果ではない。SpreadsheetBenchの逆転は同じコストでの優位ではなく、EIPの費用報告は先に見た食い違いを抱えている。そして、評価者の分布が変わり続ける環境で、新鮮な独立の検証データを安定して確保すること自体が、たやすくない宿題として残る。枠組みを立てた功績は大きいが、その枠組みが実際のデプロイでどれだけ予測力を持つかは、後続の実証の仕事だ。
実務に持ち帰るなら、このチェックリストがすべてだ。
いいえ。自己進化は、システムが自分の実行フィードバックから自ら修正を作り出し、その修正メカニズムが回り続けながら採択版が次の実行へ引き継がれる場合を指します。人が直接直すのは別の作業です。ただし、人が直す場合でも、新鮮な検証データで採択を判定し、回帰の予算を管理するという原則は、同じように適用できます。
発想は似ています。複数の候補を作って評価し、良いものだけ残して次の世代へつなぐ構造だという点で。論文はこの構造に、安定性・集中不等式のような古典的な統計の結果を引き入れてバウンドを導きます。核心はアルゴリズムの名前ではなく、「複数の候補を評価して選ぶ」という枠組みが、統計的保証を載せられる形だという点です。
重みへのアクセスが閉ざされているというのは、ハーネスを選ぶ複数の理由のうちの一つにすぎません。開けられても、再学習のコストがかからず、変更を人が読んでバージョンを比較できるという利点はそのままです。どこがなぜ変わったのかを追う必要のある運用環境なら、重みを開けられても、ハーネス側の修正のほうが扱いやすい場合が多いです。
論文は「予算で管理せよ」という役割だけを与えます。許容する低下の幅をいくつに取るかは、数値から導かれるのではなく、その機能が壊れたときの事業上のリスクに応じて組織が決める政策判断です。規制報告のように抜けが致命的な領域は上限をきつく、内部メモのように余裕のある領域はゆるく取る、というふうに、業務ごとに別々に設定するのが自然です。