SoL-Piは、コーディングエージェントを包む「ハーネス(harness。エージェントがツールを使い、コンテキストを管理するための実行の骨組み)」そのものを自動で改善する研究だ。人が手でチューニングする代わりに、複数の環境で自動研究ループを反復的にスケールアップし、良い改善策だけをふるい分けた。その結果、51個のタスクからなるEdgeBench評価で記録されたトークントラフィックを44.7〜49.0%削減し、API費用を約3分の1削減した。ただしこれはタダではなく、平均スコアは既存の強力なハーネス(Pi)と比べて約5〜6%低下している(詳しい数値は後述の「結果と意味」節を参照)。
かつてのコーディングAIは、そのほとんどが「オートコンプリート」の補助役だった。人がコードを打つと次の行を予測してくれる、という具合で、一度の予測がそのまま一つの仕事だった。ところが最近のコーディングエージェントは、性格がまるで違う。人が見張っていなくても、夜通し、一日中、自らコードベースを探索し(unattended, around-the-clock exploration)、推論し、ツールを使い、実行結果というフィードバックを受けて再び判断する。
問題は、こうなることでエージェントの作業が「一度の予測」から「長く続く軌跡(trajectory)」へと伸びた点だ。推論 → ツール使用 → フィードバック → 再び推論、が数十、数百ステップにわたって続く。料理に例えるなら、以前は「次の材料を一つ取って」というレベルだったのが、今は買い出しから調理、味見、再び調理までまるごと任せるようなものだ。この長い過程でやり取りされるテキスト(トークン)が爆発的に増える。
だからこそトークン効率(token efficiency)が核心的なボトルネックになる。とりわけ、エージェントが自らを反復的に改善する「再帰的自己改善(RSI, Recursive Self-Improvement)」を大きくスケールさせようとするなら、一回まわすのにかかるコストが低くなければ何度もまわせない。コストが高ければ、自己改善ループそのものを多く回せなくなる。
既存のアプローチの限界は、改善の焦点が主に「モデル」側に当てられてきた点にある。この論文はモデルではなく、その外側を包むハーネス層(harness layer)に手を入れる。同じモデルでも、ハーネスをうまく組めば、はるかに少ないトークンで同じ仕事をこなせる、という観点だ。
この研究の手法をひと言でいえば「ハーネスを、人ではなく自動研究ループに自ら発見させる」ということだ。
アプローチはRSIから着想を得つつ、その対象をハーネス層に置く。著者らは自動研究ループ(auto-research loop)を、ますます多く多様な環境(increasingly numerous and diverse environments)にわたってスケールさせながら、ハーネス候補を実際に走らせてみる(harness rollouts)。ここで「多様な環境」が重要になる。一つの状況でしか通用しないコツは、その状況を外れると役に立たなくなるからだ。
例えるなら、一人の料理人を一つの厨房だけで訓練するのではなく、数多くの異なる厨房に送り込み、あらゆる条件で働かせたうえで「どの厨房でも通用する習慣」だけを残すのと同じだ。特定の厨房でしか効かない小手先の技はふるい落とされ、どこでも再利用可能な(reusable)改善策だけが生き残る。論文は、こうして得られた改善が「開発した環境を越えて(transfer beyond their development setting)」転移(transfer)し、自動ハーネス発見を実運用水準の成果(production-level outcomes)に近いところまで引き上げる、と述べている。
この選択(selection)の過程を最後まで生き残り、SoL-Piを構成するメカニズムは四つだ。アブストラクトが挙げる各軸は次のとおり。
| メカニズム | 扱う領域 | やさしい説明 |
|---|---|---|
| Action execution | 行動の実行 | エージェントがツール・コマンドを実際に実行するやり方 |
| Context compaction | コンテキスト圧縮 | 長くなった対話・履歴を押し込めてトークンを節約するやり方 |
| Observation handling | 観測(結果)の処理 | ツール実行結果のような観測値を扱うやり方 |
| Delegated reading | 委譲された読み取り | 読み取り作業を別に委譲して処理するやり方 |
ここで一つ注意したい点がある。アブストラクトは、この四つがそれぞれ「何を扱う軸なのか」は明かすものの、各メカニズムの具体的な実装がどう動作するのかまでは述べていない。上の説明のうち「やさしい説明」欄は、軸の名前から自然に推測した概念的な補足であり、正確なアルゴリズムの詳細は本文(論文全体)を確認する必要がある。
直観的に見れば、四つの軸はいずれも「長い軌跡から漏れ出すトークンを、どこで削れるか」という一つの問いの、異なる局面だ。実行のやり方、履歴の圧縮、結果の処理、読み取りの委譲——エージェントが長く働くときにトークンが膨らむ代表的な分岐点である。
中心となる評価は、51個のタスクからなるEdgeBench(51-task EdgeBench evaluation)で行われた。比較対象は既存の強力なハーネスであるPiだ。モデルとしてはGPT-5.6 SolとOpus 5が併せて使われた。
成果とその代償は次のとおり。
意味を整理すると、「スコアを約5〜6%差し出す代わりに、トークンと費用を大きく下げた」というのがこの研究の核心的なメッセージだ。性能の損失がまったくないわけではないが、その幅が大きくないという点で、削減の代償として受け入れられる水準だ、という主張である。とりわけ削減額を「時間あたり(hourly)」に換算して示した点が印象的だ。夜通し休まず回るエージェントを前提とすれば、時間あたりの削減がそのまま運用コストの構造的な差として積み上がるからだ。1日24時間、1か月を掛けてみれば、なぜハーネス層の効率が「スケールアップの前提条件」なのかがはっきりする。
もう一つ注目すべき点は、改善策の転移可能性(transfer)だ。互いに異なる複数の環境で生き残ったメカニズムなので、開発した特定の設定を越え、ほかの状況でも再利用される、という主張である。これは「一度うまくチューニングすれば終わり」ではなく「発見した改善が資産として残り、使い続けられる」という意味に近い。
正直に指摘すると、アブストラクトだけでは確認しづらい部分がいくつもある。
要するに、方向性と成果の骨格は明確だが、再現と一般化を判断するには、アブストラクトの先にある本文の根拠が必要だ。
ONTLEは「AIプロジェクトマネージャー派遣型SaaS」だ。AI PMが人の代わりに長く、自律的にプロジェクトを見守り、ツールを使い、判断する構造である点で、この論文が扱う「監視なしに長く回り続けるエージェント」と問題意識がぴたりと重なる。
示唆を三つに整理する。
ハーネスがそのままコスト構造だ。 ONTLEのようにAIが常駐して働き続けるプロダクトは、モデルを替えなくても、エージェントを包む実行の骨組み(コンテキスト圧縮・観測処理・読み取り委譲のやり方)に手を入れるだけで費用を大きく下げられる余地がある。スコアをわずか(約5〜6%)差し出す代わりにトークンを半分近くまで削減するという結果は、運用マージンと料金競争力に直結する。ただし、このとき受け入れる性能低下が自社サービスの品質基準を越えないかは、別途確認する必要がある。
コンテキスト管理が自律性の上限を決める。 AI PMが長く働くほど、対話・履歴・ツール結果が積み重なってトークンが急増する。SoL-Piの四つの軸のうちコンテキスト圧縮(context compaction)と観測処理(observation handling)は、RAGで知識をつなぎ、長いプロジェクト履歴を扱うプロダクトでとりわけ重要な設計のポイントだ。何を残し、何を押し込めるかが、そのままどれだけ長く自律で回せるかを決める。
「改善の自動発見」という方法論。 人がハーネスをひとつひとつチューニングする代わりに、多様な実環境で走らせてみて生き残るものだけを採用するアプローチは、複数のプロジェクトに派遣されるAI PMの運用にそのまま対応する。いくつもの現場で通用する運用習慣だけを標準として残し、特定の現場にしか合わない小手先の技はふるい落とす、というわけだ。
ただし導入にあたっては、上記の限界をそのまま抱えて進む必要がある。自社のドメインはEdgeBenchとは異なるので、削減効果とそれに伴う性能低下の幅は、実際のONTLEのワークロードで小規模に合わせて測定し、確認するのが順序だ。アブストラクトの数値は「期待値の根拠」であって「自社環境での保証」ではない。
いいえ。この研究の焦点はモデルではなく、その外側を包むハーネス層です。同じモデル(アブストラクトではGPT-5.6 Sol、Opus 5)を使いながら、実行の骨組みを改善してトークンと費用を減らしました。
落ちています。アブストラクトは「見劣りしない(comparable)」性能だと表現しますが、本文の表(§3.1)を見ると、平均スコアはGPT-5.6 Solで44.833→42.003(約6.3%低下)、Opus 5で44.756→42.224(約5.7%低下)と下がっています。「性能損失なし」ではなく「わずかなスコア低下を受け入れたうえでの削減」と理解すべきです。
行動の実行(action execution)、コンテキスト圧縮(context compaction)、観測処理(observation handling)、委譲された読み取り(delegated reading)です。アブストラクトは各軸が扱う領域だけを明かしており、具体的な実装は論文本文を見る必要があります。
アブストラクトはAPI費用を約3分の1削減したとしています(削減後も元の費用の約3分の2が残る計算で、本文の表§3.1ではGPT-5.6 Solが$1,339→$894、Opus 5が$1,741→$1,158)。あわせて時間あたりの削減額を、ネイティブのCodex・Claude Codeと比べて約8.75〜13.50ドル、Piと比べて約4.36〜5.71ドルと「推定」で提示しています。比較基準や使用パターンによって変わりうる推定値です。