エージェントを走らせる隠れたコスト

AIコーディングエージェントの経済性は、単一の質問に答えるのをやめ、自律的に作業を始めた瞬間に変わる。ワンショットの予測は安い。しかし、長く監視されない実行は安くない。推論ステップがツール呼び出しに積み重なり、それがフィードバックループに積み重なり、トークン課金はサイクルごとに膨らんでいく。Nvidiaの研究者たちは、その課金に意外な角度から切り込むシステムについての論文を発表した。基盤モデルの実行コストを下げるのではなく、それを取り囲む足場(スキャフォールディング)を書き換えるというアプローチだ。

研究者たちによれば、SoL-Piと呼ばれるこの手法は、性能をほぼ変えずにトークン消費をほぼ半減させる。この研究はThe Decoderによって報じられ、システムがモデルそのものではなく、ハーネスとして知られる制御レイヤーを対象としていると指摘している。

ハーネスが実際に担う役割

ハーネスとは、モデルとそれが動作する環境の間に位置するソフトウェアのレイヤーである。エージェントに自分がどのような状態にあるかを示し、アクションがどのように実行されるかを決め、その後にモデルへ返されるフィードバックを決定する。Codex、Claude Code、OpenClawといった馴染みのある製品は、この種のハーネスに依存して、言語モデルをファイル編集やテスト実行、反復作業ができるものへと変えている。

このレイヤーがループの多くを統制しているため、コストへの影響は極めて大きい。冗長なツール呼び出し、大きすぎるコンテキストウィンドウ、発火が遅すぎる検証ステップの一つひとつが、厳密には不要だったトークンを積み増す。これまで効率化の取り組みの大半は別の場所に集中してきた。高速なアテンションカーネルやサービング基盤による単一トークンあたりの価格低減、量子化によるモデル圧縮、あるいはより小さく安価なモデルへの作業のルーティングなどである。

ハーネス最適化が難しい理由

ハーネスを手作業でチューニングするのは難しい。その責務が緊密に絡み合っているからだ。ツール使用、コンテキスト管理、検証ルーチン、中断ロジックはすべて相互作用する。ある段階でトークンを削る変更が、別の場所で障害を引き起こしたり、単にコストを実行の後半フェーズへ移し、見えにくくしたりする。

Diagram of the SoL-Pi auto-research loop showing research environments, a research AI, an idea pool, and four retained mechanisms, alongside bar charts comparing score and API costs for Codex, Claude Code, Pi, and SoL-Pi on EdgeBench.
A research AI analyzes agent traces, proposes harness changes, and keeps only those that maintain performance while cutting costs. SoL-Pi saves 50 percent compared to Codex and 54.3 percent compared to Claude Code on EdgeBench. | Image: Nvidia

実際には、エンジニアが長い実行トレースを読み、繰り返し現れる失敗パターンを見つけ、その観察をコード変更へと翻訳する。これは遅く手作業の多い仕事であり、誰かが同じミスに10回目で気づくことに依存している。

SoL-Piが探索を自動化する仕組み

SoL-Piは、その人間のループを自動化する。研究エージェントが別のエージェントによって生成されたトレースを観察し、ハーネスへの変更を提案し、その提案を準備された環境内でテストする。候補となる変更は能力チェックと効率チェックの両方で選別され、性能を維持しつつコストを削減する変種だけが保持される。

著者たちはこのアプローチを、再帰的自己改善を活用したものだと説明している。つまり、あるAIシステムが別のAIシステムの動作条件を実質的に改善しているのだ。重要な詳細は、最終結果を判断するために使われる評価が、ハーネスが凍結された後にのみ行われ、そのホールドアウト評価が探索にフィードバックされないという点である。この分離は重要だ。なぜなら、最適化プロセスが最終的に直面するテストに合わせて自己調整できる度合いを制限するからである。

実験の規模

探索は広範囲に及んだ。535の実行可能な環境にわたり、SoL-Piは152の異なる方向性を探索した。タスクの構成は以下を含む:

  • GitHubのissueとpull requestのペアから構築された495のタスク
  • 評価用に設計された40の合成テストケース
  • 合計3,000回を超える実行
  • 60,000回を超えるエージェントと環境の相互作用

研究者たちはこの量を、システムがいかに広く探索したかの証拠として提示しているが、より多く探索することが自動的により良い結果を生むわけではないとも警告している。広さは有用なハーネス構成を見つける可能性を高めるが、それが保証されるわけではない。

測定された削減効果

主要な数字は相当なものである。研究者たちによれば、EdgeBenchにおいてSoL-PiはCodexと比較してトークンを50%削減し、Claude Codeと比較して54.3%削減した。一方で性能はほぼ横ばいだった。論文は全体のトークン削減を最大49%とし、タスク能力の変化はほとんどないとしている。

Flowchart of the search pipeline from trajectory rollouts through map-reduce analysis, mechanism proposal, candidate implementation, independent review, and development validation to a separate held-out evaluation.
The held-out evaluation happens only after the harness is frozen and doesn't feed back into the search process. | Image: Nvidia

この枠組みは重要である。エージェントがより頻繁に失敗したり、検証をスキップしたり、正当なタスクで早々に中断したりすることが許されれば、トークン使用量を削るのは簡単だ。ここでの主張は異なる。削減は挙動の劣化ではなく、より無駄のない制御ロジックから生まれている。だからこそ、選択プロセスでは効率チェックと並んで能力チェックが置かれている。

過学習の問題

この研究分野にはよく知られた危険がある。以前の研究は、自動最適化されたハーネスが過学習しやすく、チューニング対象のトレース上では非常に効率的になる一方、新しい状況への汎化が乏しくなる傾向があることを示している。Nvidiaの著者たちはこれを認識しているようであり、だからこそ最終評価は凍結されたハーネス上で、探索ループから切り離して実施されている。

それでもなお、この注意点は持ち続ける価値がある。ここで使われた環境は数が多いとはいえ、コーディングエージェントが遭遇する混沌とした現実の有限のサンプルにすぎない。535の環境で洗練されたハーネスが、真に未知のリポジトリ、不安定なテストスイート、曖昧なバグ報告に対して持ちこたえるかどうかは、より広範な展開によってのみ答えが出る未解決の問題である。

エージェント経済にとっての意味

もしこの結果が実験室外でも成り立つなら、その含意は哲学的というより実用的である。自律型コーディングエージェントを運用するチームはトークン単位で支払い、エージェントを有用にする長い無監視セッションこそが、まさに高コスト化の原因である。能力を失わずにワークフローからほぼ半分のトークンを絞り出せれば、予算で維持できるセッション数が変わる。

この研究はまた、最適化の労力をどこに費やす価値があるかという点での転換も示唆している。モデルレベルの効率は長年デフォルトの目標であり、それは確かに今も重要だ。しかしハーネスこそが、コンテキスト、検証、リトライに関する決定が下される場所であり、この論文が示すように、無駄の大きな割合はそうした決定に蓄積する。モデルと環境の間のギャップは、残された最も生産的な探索先かもしれない。

この記事はThe Decoderの報道に基づいています。元の記事を読む。

Originally published on the-decoder.com