NVIDIA、南洋理工大学、MITなどの研究チームは9月17日付のプレプリントで、コーディングエージェントの実行を効率化する「SoL-Pi」を報告した。Pi向けの拡張機能もGitHubで公開している。
モデルそのものを再学習するのではなく、AIがコードを編集し、テスト結果を確認し、次の操作を決めるまでの一連のやり取りを効率化する研究だ。長時間の作業では、モデルとツールの往復や、過去に出力された長いログの再送が何度も積み重なる。研究チームは、同じモデルを使う通常のPiと比較し、SoL-Piによって総トークン量を最大49.0%削減できたと報告している。
ただし、トークンを半分近く減らしながら、課題の成績を完全に維持できたわけではない。「49%削減」が何を基準に計算された数字なのか、また公開されている拡張機能でどこまで再現できるのかを分けて見る必要がある。
トークンは49%減ったが、平均スコアも低下
論文の中心となる比較は、長時間のコーディング作業を含むEdgeBenchの公開51課題を使って行われた。GPT-5.6 Solを同じ高い推論設定（xhigh）で動かし、通常のPiと、4つの機能をすべて有効にしたSoL-Piを比較している。
著者らが記録した入力トークン、キャッシュの読み書き、出力トークンを合計すると、Piの2.1538BからSoL-Piでは1.0990Bまで減った。Bは10億を意味する。API料金を基に計算したモデル利用費も、1,339ドルから894ドルへ下がった。
| EdgeBench公開51課題、GPT-5.6 Sol | Pi | SoL-Pi（4機能すべて有効） |
|---|---|---|
| 記録された総トークン量（10億単位） | 2.1538 | 1.0990 |
| API料金換算のモデル費用 | 1,339ドル | 894ドル |
| 平均スコア | 44.833 | 42.003 |
GPT-5.6 Solで4機能すべてを有効にしたSoL-Piは、Piと比べて総トークン量を49.0%削減した一方、平均スコアは6.3%低下した。費用の削減率は33.2%だった。
ここでいう49.0%は、Piの総トークン量を基準に両者の差を計算した数字だ。また、費用は2026年8月17日時点のAPI料金を使った試算であり、実際の利用者の請求額を比較したものではない。
平均スコアについてはPiの93.7%を維持したことになるが、すべての課題で同等の結果を出したという意味ではない。
研究チームは、改善案を探すために使う課題とEdgeBenchの評価課題を分け、採用する仕組みを決めてから最終評価を行った。ただし、公開51課題のすべてが最終評価まで完全に未使用だったわけではない。11課題は、仕組みを決めた後に採用可否を確認するため一度だけ使用し、残る40課題を最終評価に使っている。
さらに、GPT-5.6 Solの実行履歴を基に作られた仕組みを、開発段階では使っていなかったOpus 5へそのまま適用した試験も行った。この場合もPiと比べて総トークン量は44.7%減り、平均スコアはPiの94.3%だった。
別のモデルでも同様の傾向が確認された一方、論文で検証されたモデルはGPT-5.6 SolとOpus 5の2つに限られる。
4つの仕組みは何を削ったのか
研究チームは152の改善案を考案し、535の実行可能な環境で候補を試した。内訳は、GitHubのIssueと修正PRを基に作られた495課題と、実際に実行して成功・失敗を判定できる40の合成課題だ。
3,000回を超える試行を経て残ったのが、4つの仕組みだった。なお、この152案や535環境という数字は、49%というトークン削減率の計算対象ではない。あらかじめ設定した性能水準を大きく損なわず、効率も改善した案だけを採用する方法を取っている。
最初の「Action Fusion」は、ファイルの編集や書き込みと、その直後に行うテストやビルドを一つのツール呼び出しにまとめる。
編集後に何をするかがあらかじめ決まっている場合、間にモデルをもう一度挟む必要がないためだ。一方、編集結果を確認してから次のコマンドを決める必要がある作業には使わない。
省くのはテストや検証そのものではなく、結果を確認する必要のない操作同士の間に発生するモデルとの余分な往復だ。
「ObservationPack」は、10KiBを超えるツールの出力をローカルに保存する仕組みだ。最初の2回はモデルへ全文を送るが、それ以降は短い抜粋と参照用の識別子だけを渡す。必要になれば、元の内容をページ単位で再び読み込める。
長いログやファイル内容が、その後のすべてのターンで繰り返しコンテキストに含まれることで発生するトークン消費を抑える。
すでに終わった作業の内容が会話履歴に残り続ける問題には、「Online Context Compact」が対応する。
作業計画の節目ごとに、コンテキストを圧縮するために必要なコストと、その後の入力を短くできる効果を比較し、メリットが上回る場合にPiの圧縮機能を利用する。キャッシュを作り直すコストも判断材料に含める。
GPT-5.6 Solの比較では、4機能すべてを有効にしたSoL-Piのキャッシュ読み込みトークンはPiのおよそ半分まで減った。一方で、キャッシュへの書き込みトークンは増えている。したがって、キャッシュの一部分だけを見ても全体のコストは判断できない。
最後の「Evidence-Preserving Reducer」は、指定されたビルドやテストから出力された4KiB以上の診断ログを、低コストの補助モデルに先に読ませる仕組みだ。
補助モデルが作成した短い記録について、元ログのハッシュ、終了状態、引用部分が原文と完全に一致しているかなどを機械的に確認する。検証に失敗した場合には、要約ではなく元のログをそのままモデルへ渡す。
単純に長いログを切り捨てるのではなく、要約内容を検証し、必要ならいつでも原文へ戻れるようにした点が特徴だ。
公開版はPi用の拡張機能、4つとも初期状態では無効
GitHubで公開されているSoL-Piは、Piが提供する拡張機能向けAPIを利用して動作する独立した拡張機能だ。Pi本体を変更せずに追加できる。論文で検証されたPiのバージョンは0.85.1で、Node.js 22.19以降を必要とする。
ここで注意したいのは、論文でAI自身が改善案を探した「自動研究ループ」と、一般利用者がGitHubから導入できるSoL-Pi拡張機能は別のものだという点だ。
SoL-Piをインストールしたからといって、利用者が使うCodexやClaude Codeまで自動的に同じ仕組みへ切り替わるわけではない。
また、4つの機能はいずれも初期状態では無効になっている。
公式READMEでは、追加のモデル呼び出しを必要とせず、通常の作業を妨げにくいAction FusionとObservationPackだけを有効にする、比較的慎重な設定例を紹介している。
一方、論文で報告された最大49.0%の削減は、4つすべてを有効にした場合の結果だ。このため、Action FusionとObservationPackだけを有効にしても同じ削減率が得られるとは限らない。
実際、論文の別設定では、GPT-5.6 SolでObservationPackだけを追加した場合、平均スコアは44.833から47.208へ上がった一方、総トークン量の削減は6.1%にとどまった。
つまり、トークン削減を最大化するのか、それとも性能への影響を抑えるのかによって、適した設定は変わる。
企業で利用する場合には、ログの取り扱いも重要になる。
公式のセキュリティ文書によれば、SoL-PiはPiのプロセスと同じファイル、コマンド、ネットワークへの権限で動作し、独自のサンドボックスや隔離環境は提供しない。
ObservationPackなどは元の出力をセッション内に保存する。またReducerを有効にした場合、対象となるログが設定した補助モデルへ送信されることがある。
秘密情報とみられる文字列を検出して送信を避ける仕組みも用意されているが、完全な情報漏えい防止策ではない。外部サービスへ送信できない診断ログを扱う環境では、Reducerを有効にしない運用が公式にも推奨されている。
導入判断では「解けた課題数」と「総費用」の両方を見る
EdgeBench以外の評価では、効率と課題達成率のトレードオフがさらに明確に表れている。
Terminal-Bench 4のうち、CPUのみで実行できる63課題を使った試験では、PiとCodexはそれぞれ18課題を解決したのに対し、SoL-Piは15課題だった。
一方、PiとSoL-Piのモデル利用費は、それぞれ286.45ドルと211.12ドルで、SoL-Piの方が安かった。成功1件当たりの費用も低下しているが、解決できた課題数そのものは減っている。GPUを必要とする課題は、この試験には含まれていない。
したがって、「長時間のコーディング作業でトークン使用量を減らせた」という論文の結果を、「どんな開発作業でも品質を維持したまま安くできる」という意味に広げて解釈することはできない。
導入を検討する場合は、自分たちが実際に扱う課題を使い、まず解決できた課題数や回帰テストの成功率など、品質を判断する基準を決める必要がある。そのうえで、総費用や成功1件当たりの費用を比較するべきだ。
加えて、ログをどこに保存できるのか、どのモデルや外部サービスまで送信してよいのかという運用ルールも決めておく必要がある。
こうした条件を満たしたうえで、モデルとツールの不要な往復や、同じログの繰り返し送信を減らせて初めて、SoL-Piによる効率化が実際のコスト削減につながる。
