SoL-Pi：長時間コーディングエージェントのトークン効率を高める自動ハーネス研究

ソフトウェア開発の現場で、バグの修正やテストの自動実行をAIエージェントに自律的に行わせる場面を考えてみます。エージェントはコードを探索し、ファイルを書き換え、ビルドやテストを実行します。このとき、コンパイラやテストツールからは、時に数百行から数千行、数十キロバイトに達する膨大なログが出力されます。

現在のLLMを用いた標準的なエージェントの仕組みでは、これらすべての履歴（過去の指示、推論の道筋、実行したコマンド、そして膨大なテスト結果）を毎回文脈として連結し、次の行動を決めるたびにモデルへ丸ごと送信し直します。作業が10ステップ、20ステップと長引くにつれて、送信されるトークン（AIが文章を処理する単位）の量は雪だるま式に増加します。実際には直前の数行のエラー箇所だけを確認すればよい場面であっても、過去に発生した巨大なログを何度も繰り返しモデルへ送り続けることになり、APIの利用料金と通信帯域を激しく浪費する原因となっています。

生成AIシステムの効率化といえば、より小さなモデルへの切り替え（蒸留や小型モデルの採用）、重みの量子化、あるいは高速な推論エンジンの導入といった「モデル側の工夫」が一般的でした。これらはトークンあたりの単価やモデルの計算時間を引き下げるアプローチです。

しかし、複雑なプログラミング作業において安易にモデルの知能水準を落とすと、推論の正確さが損なわれ、作業そのものが頓挫しかねません。そこで本研究が着目したのが、モデル本体ではなく「エージェントハーネス（実行基盤）」の最適化です。ハーネスとは、モデルに対してどのような形で文脈やツール結果を渡し、どのような順序でコマンドを実行させるかを制御する土台のソフトウェア層を指します。モデルの重みを一切変更・再学習せず、モデルと環境の間を行き来する「情報の渡し方」や「やり取りの往復回数」を賢く制御することで、知能を保ったまま通信量を削る道を探りました。

ハーネスの通信を減らす工夫自体は、人間のエンジニアも手作業で行ってきました。しかし、ログを安易に切り捨てると、後段で必要になる重要なスタックトレースが消失し、エージェントが誤った修正を繰り返してかえってコストが増大するという相互依存の問題が生じます。また、過去のプロンプト改善やプログラム探索の研究では、特定の練習用タスクに最適化しすぎてしまい、初めて見るタスクで全く役に立たなくなる「過適合」が大きな課題でした。

著者らはこの課題に対し、研究用AIがハーネスの変更案を提案・実装・検証する自動研究ループを構築しました。その際、過適合と評価漏洩を防ぐため厳格な規約を設けています。探索を始める前に「能力指標」「許容できる性能低下の範囲（能力許容幅）」「効率指標」をあらかじめ固定しました。そして、すべての能力指標が許容幅内に収まり、かつ少なくとも1つの効率指標を改善した候補だけを「非劣解」として採択する仕組みにしたのです。さらに、最終的な評価ベンチマークであるEdgeBenchは探索から完全に隔離し、探索結果を一切フィードバックしない設計としました。

著者らは文脈管理、進捗管理、ツール利用、タスク委譲、プロンプト方針、評価改善の6系列から152方向の変更案を生成し、535の環境（495件のリポジトリ由来タスクと40件の検証器駆動タスク）において3,000回以上の実行と60,000回以上の相互作用を重ねました。この広域探索から深掘りへのファネルを経て、最終的に既存基盤「Pi」へ統合されたのが以下の4つの機構です。

第1に「Action Fusion」です。これはファイルの変更と、その直後に行われるテストやビルドの実行を1回のツール要求に統合する仕組みです。該当する作業経路において、モデルと環境の往復回数を3回から2回へ減らします。ただし、変更結果の観測を待ってから次のコマンドを決める依存関係がある場合はコマンドを分離します。

第2に「Online Context Compact」です。計画ステップの完了時に、残存ステップ数や過去の要求数、文脈の増加率から、古い文脈を要約・短縮した際の将来の入力削減量を見積もります。この推定削減量がキャッシュ再書き込みコストを上回る場合、または文脈上限に近づいた場合に限り短縮を実行します。なお、要約呼び出し自体の費用は判定ゲートで個別に価格付けされていません。

第3に「ObservationPack」です。10 KiBを超えるツール出力が発生した場合、原文をローカルに保存します。最初の2回のリクエストでは全文を提示し、3回目以降は安定ハンドル、元サイズ、完全な先頭行と末尾行を含む約1 KBの抜粋へ置き換えます。必要時にはハンドルから原文ページをオンデマンドで再取得できます。

第4に「Evidence-Preserving Reducer」です。所定コマンドによる4 KiB以上のビルド・テストログを、安価な小型モデルGPT-5.6 Lunaで「証拠レシート」へと圧縮します。スキーマ、原文ハッシュ、終了状態、完全一致引用、サイズを決定論的に検証し、検証失敗や秘密情報の疑い、サイズ非削減時には原文へフォールバックします。ファイル読み取りや検索結果は対象外です。

これらは順序制御されており、ReducerがObservationPackより先に処理され、検証済みレシートを再梱包しません。また、補助モデルは証拠抽出のみを担い、診断や行動選択は主エージェントが保持します。開発現場の比喩で言えば、修正とテストを1回で指示し、長大なテスト結果は証拠だけを抜き出して保管庫へ回し、机の上（文脈）には小さな控え番号だけを残すような連携です。ただし、人間の大雑把なメモとは異なり、完全一致引用やハッシュ照合による機械的検証が必須である点が実運用上の境界となります。

提案手法の評価にあたり、著者らは4つの機構のソースコード、設定パラメータ、評価指標、能力許容幅、採択ルールをすべて事前に凍結しました。主評価には公開ベンチマーク「EdgeBench」の51タスクを使用しています。このうち11タスクは凍結された候補の中から一方向に採択を行うために使われ、残る40タスクは探索による影響を完全に排除した汎化性能の最終測定用として予約されました。

評価では、目的に応じた2つの運用点が比較されています。4つの機構をすべて有効化して最大のトークン削減を狙う完全構成「SoL-Pi [Efficiency]」と、出力退避機構のみを有効化した「SoL-Pi [Performance]」です。比較の基準には、改善元の基盤であるPiが用いられました。測定指標としては、タスクの平均スコア（達成度）、記録されたトークン通信量、および2026年8月17日時点のAPI価格に基づく利用料金が同時に記録されました。

SoL-Piの探索プロセスは、すべてOpenAIの「GPT-5.6 Sol」から得られた実行軌跡のみを用いて行われました。そこで著者らは、得られたハーネスの仕組みが他のモデルにもそのまま通用するかを確かめるため、一切の追加探索やパラメータ調整を行わずに、Anthropicの「Opus 5」へ同じ完全構成を適用する転移評価を実施しました。

さらに、ソフトウェア開発ベンチマーク以外の多様な環境における挙動を確かめるため、外部評価として3つの実験が追加されました。第1に、CPU環境に限定した実務的な63件の端末操作タスクである「Terminal-Bench 4」。第2に、定理証明支援言語Lean 4による厳密な正当性検証を伴う国際数学オリンピック（IMO 2026）の6問（GPT-5.6 Sol xhigh、各問150分上限）。第3に、20体のエージェントを同時に稼働させて同一の初期状態から開始する2時間のカーネル最適化スウォーム実験です。これにより、単一モデルの枠を超えた幅広い作業環境での耐久性とコスト削減効果が測定されました。

GPT-5.6 Solを用いたEdgeBench（51タスク）の評価において、ベースラインのPiは平均スコア44.833、トークン通信量2.1538 B（十億）トークン、API費用1,339ドル（スコア1点あたり0.5855ドル）を記録しました。これに対し、完全構成のSoL-Pi [Efficiency]は平均スコア42.003、トークン通信量1.0990 Bトークン、API費用894ドルとなりました。

著者らの計算によると、SoL-PiはPiに対して平均スコアを93.7％維持（絶対値で2.830ポイントの低下）しつつ、トークン通信量を49.0％削減し、API費用を33.2％削減しました。時間あたりの推定節約額としては、Pi比で毎時4.36〜5.71ドル、ネイティブのCodexやClaude Codeの実行基盤比では毎時8.75〜13.50ドルの削減に相当すると報告されています。また、未探索のOpus 5にそのまま適用した場合でも、Piの平均スコア44.756、2.3697 Bトークン、1,741ドルに対し、SoL-Piは平均スコア42.224（94.3％維持、2.532ポイント低下）、通信量1.3101 Bトークン（44.7％削減）、API費用1,158ドル（33.5％削減）となり、削減の方向性が別のモデルでも再現することが示されました。

一方で、機構を一つだけ使ったSoL-Pi [Performance]（ObservationPack単独）は、GPT-5.6 Solで平均スコア47.208、2.0224 Bトークン、スコアあたり0.5280ドルを記録しました。Piと比較してスコアが相対的に5.3％向上し、通信量も6.1％減少したため、効率指標は9.8％改善しています。つまり、4つの機構をすべて投入することが常に最高スコアをもたらすわけではなく、「最大効率を狙う完全構成」と「高スコアを維持する単一構成」という異なる運用点が存在することが明らかになりました。

EdgeBench以外のタスクに目を向けると、効率化の代償として生じる能力低下の側面がより明確になります。

Terminal-Bench 4（63タスク）の評価では、総モデル費用がPiの286.45ドルからSoL-Piでは211.12ドルへ、解決1件あたりの費用も15.91ドルから14.07ドルへと低下しました。しかし、実際に解決できたタスク数はPiの18件（Codexも18件）から、SoL-Piでは15件へと減少しました。トークンを節約した結果、解けるはずだったタスクを取りこぼす事態が生じており、通信削減が無条件の品質維持を意味しないことが実証されています。

また、IMO 2026の6問においては、SoL-PiはPiと同じ3問を通過し、総費用を75.95ドルから62.69ドル（1問あたり20.90ドル）へ抑えました。しかし、比較対象であるCodexは5問を通過（総費用114.47ドル、1問あたり22.89ドル）しており、高度な数学的推論において絶対的な正答力を引き上げるものではないことが示されています。

さらに、20体による2時間のカーネル最適化スウォーム実験では、SoL-Piスウォームが1,127サイクル・60.11ドルとなり、Piスウォーム（1,366サイクル・82.12ドル）より少ないサイクル数と低費用で完了しました（全候補が正当性検査に合格）。しかし、同じタスクを単独のCodexエージェント1体で実行した結果は39.20ドル（1,333サイクル）であり、スウォーム構成のいずれよりも安価でした。多数のエージェントを並行して走らせる構成自体が、単独実行に対して常に費用対効果で勝るわけではない点に注意が必要です。

著者らは本研究の限界についても率直に記述しています。第1に、探索と最適化がGPT-5.6 Solの作業軌跡だけに依存して行われた点です。Opus 5へ転移させた際、通信削減の方向性は維持されたものの、各機構が実際に作動する頻度（発火率）や削減規模（発火強度）はSolに比べて低下しました。著者自身、未見バックエンドへの一般化は予備的な証拠（preliminary evidence）にとどまるとしており、複数モデルでの共同探索が今後の課題です。

第2に、Online Context Compactの費用モデルの不完全さです。過去文脈を圧縮するかどうかを判断するゲートでは、プロンプトキャッシュの再書き込みコストは見積もられていますが、要約を作成するために小型モデルを呼び出すAPI費用自体は個別に価格付けされていません。

第3に、検証の再現性とスケーリング則です。スウォーム実験は各構成1回のみの試行であり、ばらつきや初期値依存性が検証されていません。また、自動研究ループ自体の計算負荷が非常に高く、限られた計算予算の中で探索の広さと深さをどう配分すべきかというスケーリング則は未確立です。論文タイトルの「recursive scaling」も、現時点で自己改善が複利的に積み重なる効果を実証したわけではなく、将来の研究構想と位置付けられています。

これらを踏まえると、SoL-Piの適否は業務の特性によって明確に分かれます。巨大なテストログやビルド出力が頻繁に発生し、文脈の肥大化が主要なコストとなっている長時間のコーディング業務には適しています。また、ローカル保存や決定論的検証が可能な実行基盤が前提となります。一方で、短い対話で完結するタスク、毎回ログの全文を文脈内に直接提示しなければならない運用、そして数ポイントの平均スコア低下やわずかなタスク失敗も許容できないミッションクリティカルな用途には適合しません。