🤖 AI

When Does Restricting a Coding Agent to execute_code Help? A Regime $\times$ Agent-Design Ablation

本論文は、コーディングエージェントを単一の `execute_code` ツールに制限することが、ツール豊富な環境を使用するのと同等に効果的であることが多く、かつ頻繁により安価であることを実証しており、最適なツールの表面（tool surface）は、いずれか一方の要因のみによってではなく、タスクのレジームと特定のエージェント設計との相互作用によって共同で決定されることを明らかにしている。

原著者： Hong Yang, Qi Yu, Travis Desell

公開日 2026-07-14

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Hong Yang, Qi Yu, Travis Desell

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

想像してみてください。あなたの手元には、壊れたコードを直したり、数学のパズルを解いたりするのが仕事の、超スマートなロボット助手がいるとします。今、テック業界では、このロボットが仕事を完遂するために、どのようにコンピュータと対話すべきかについて、大きな論争が起きています。

ある人々は、「あらゆるタスクのための専用ボタンを備えた、フル装備のツールボックスを与えよ！」と言います（豪華なIDEのようなもの）。
他の人々は、「ただコマンドラインを与えて、シェルコマンドを打ち込ませればいい！」と言います（映画に出てくるハッカーのようなもの）。
第三のグループは、「いや！ただPythonスクリプトを書かせて、一度にすべて実行させるんだ！」と言います（execute_code アプローチ）。

この論文は、どの方法が実際にコストを節約し、仕事を完遂できるかを競わせる、巨大で公平な審判のようなものです。彼らは単に推測したわけではありません。全く同じロボット（ClaudeとCodexという2つの異なるモデル）を、全く同じタスクに対して走らせましたが、その際、ロボットに許可された「道具」だけを変更しました。

以下に、その結果を分かりやすいストーリーとして分解して説明します。

主な発見：それはロボットと仕事次第である

最大の驚きは何でしょうか？それは、「最高のツール」というものは一つも存在しないということです。勝者は、誰が、何をしているかによって変わります。

このように考えてみてください：

「数学のパズル」の仕事（Artifact タスク）： もしロボットが計算やデータ処理を行っているなら、「スクリプトを書いて実行する」方法（code_only）が明確な勝者です。これは、完璧なレシピを一つ書き上げ、一度に料理を完成させるシェフを雇うようなものです。
- Claude ロボットの場合、この方法でコストを 24.6% 削減できました。
- Codex ロボットの場合、約 6.7% の削減となりました（ただし、論文によれば、これはコイン投げのように少し不安定な結果です）。
- 結論： 数学やデータに関しては、スクリプト方式の方が安上がりであり、かつ問題解決能力も同等です。
「乱れたコードベースの修正」の仕事（SWE-bench タスク）： これはより複雑な作業です。これらのタスクは、複雑なプロジェクト内の多くのファイルを編集することを伴います。
- Codex ロボットを使用する場合： スクリプト方式が依然としてチャンピオンです！これにより、コストを 19.9% 削減できました。なぜなら、スクリプト方式は、多くの小さなリクエストを一つの大きなパッケージにまとめることができるからです。例えるなら、50回歩いて荷物を運ぶのではなく、50個の荷物を積んだ配送トラックを使うようなものです。
- Claude ロボットを使用する場合： おっと。スクリプト方式の方が、実は高くなってしまいました（14.4% 増）。ただし、論文ではこれは統計的に「証明された」差ではなく、あくまで強い傾向であると注記されています。なぜでしょうか？ Claudeにとって、ファイルを編集するためにスクリプトを書くことは、タイヤを交換するために新しい車を組み立てるようなものです。編集内容をコードで説明するためにあまりにも多くの言葉（トークン）を消費してしまい、「編集の摩擦（edit friction）」を生んでしまうのです。

この論文が否定したもの

この論文は、「一つのツール表面が常にすべての人にとって優れている」という考えに対し、明確に反論しています。

否定されたこと： 「特別なIDEボタンが常に必要である」（Codexがスクリプト方式で勝利したため）。
否定されたこと： 「Bashコマンドだけで十分である」（数学タスクにおいてスクリプト方式がより安価だったため）。
否定されたこと： 「コード実行が常に最も安価である」（複雑なコード修正において、それがより高価になったため）。

著者たちは非常に明確に述べています。ツールそのものに基づいてツールを選ぶことはできません。「ロボットの脳」と「仕事の種類」の組み合わせを見なければならないのです。

「合格率」の驚き

ここが最も重要な部分です。コストは変わりましたが、成功率は変わりませんでした。

二人のランナーを想像してください。一人は重いブーツを履いて走り（高価なツール）、もう一人はスニーカーを履いて走っています（安いツール）。論文の結果、両方のランナーは全く同じ速さでゴールに到達しました。

ロボットが豪華なツールボックスを使おうが、Bashコマンドを使おうが、あるいはスクリプト方式を使おうが、正しく解決できたタスクの割合はほぼ同一でした（3パーセント以内の差）。
「スクリプト」方式は、ロボットを賢くも愚かにもしませんでした。それは単に、ゴールへの「歩き方」を変えただけなのです。その歩みがスプリント（安価）になることもあれば、つまずき（高価）になることもありました。

なぜコストが変わったのか？

論文は、スクリプト方式がなぜ安くなったり高くなったりしたのかを掘り下げています。

「編集の摩擦」税（Claude の場合）： Claudeがスクリプト方式を使ってファイルを修正しなければならないとき、「5行目を変更せよ」と言うためだけに長いPythonスクリプトを書く必要がありました。これは、大量の「出力トークン（ロボットがタイピングしなければならない言葉）」を消費しました。まるで、ページをめくるたびに通行料を支払っているようなものです。これは主に、ロボットが失敗したり苦戦したりしたタスクで発生し、それらの特定の実行を非常に高価なものにしました。
「バッチ処理」ボーナス（Codex の場合）： Codexがスクリプト方式を使用すると、多くの小さなコマンドを一つのスクリプトに詰め込むことができました。コンピュータに対して「ファイルAを読め」、「次にファイルBを読め」、「次にファイルCを読め」と（3回の別々の往復で）頼む代わりに、「A、B、Cを一度に読め」と頼むことができました。これにより、膨大な量の「入力トークン（ロボットが読む言葉）」を節約できました。
「失敗する実行」の影響： コード修正タスクにおけるClaudeの追加コストは、主にロボットがすでに失敗する運命にあったときに発生しました。それは、車がぐるぐる回っている間にガソリン切れになるようなものです。スクリプト方式が失敗を引き起こしたのではなく、失敗した試行のコストを高くしただけなのです。

どれほど確かなのか？

著者たちは、数学タスクとCodex ロボットの結果については非常に自信を持っています。彼らは、結果が単なる偶然ではないことを確認するために、これらに対して3つの「シード（ランダムな開始点）」を用い、93 個の数学タスクと 100 個のコード修正タスクでテストを行いました。コード修正タスクにおけるCodexの節約は、統計的に有意でした（19.9% の減少、p値は 2.0 × 10⁻⁹ であり、これは事実上ゼロの確率、つまり偶然である可能性がほぼないことを意味します）。

しかし、コード修正タスクにおける Claude ロボットについては、結果は少し曖昧です。コストは 14.4% 上昇しましたが、統計テストによれば、これは「決定的な証拠（slam dunk）」とは言えませんでした（p値は 0.12）。著者たちはこれを「方向性を示すもの（directional）」と呼んでいます。つまり、傾向は見られるものの、それが偶然の紛らわしいものではないと100%確信するためには、もっと多くのテストを行う必要があるということです。

まとめ

もしあなたがコーディングエージェントを作っているなら：

推測してはいけません。 「最高の」ツールは、あなたの特定のロボットと、特定の仕事によって決まります。
数学／データに対して： 「スクリプトを書く」方法を試してください。その方が安く、性能も同等です。
コード修正に対して： それによります。Codexを使うなら、スクリプト方式は素晴らしいものです。もしClaudeを使うなら、標準的な編集ツールを使い続ける方がよいかもしれません。特に難しい問題においては、スクリプト方式だと「編集の摩擦」に足を取られてしまう可能性があるからです。
知能については心配しないでください： ツールを変えても、ロボットを賢くしたり愚かにしたりすることはありません。それは単に、旅の「価格設定」を変えるだけです。

論文は次のように結論づけています。「最も安価な」エージェントの動かし方は普遍的なルールではありません。それは、ツールをロボットとタスクに適合させなければならないパズルなのです。

テクニカル・サマリー：コーディングエージェントを `execute_code` に制限することが有効となるのはいつか？

問題提起

コーディングエージェントの分野は、現在、最適な「ツール・サーフェス」（エージェントに公開されるインターフェースの集合）に関して、互いに相容れない3つの主張の下で動いています。

特化型IDEプリミティブが必要である： SWE-agentが主張するように、構造化されたインターフェース（Agent-Computer Interface: ACIなど）は、生のシェルアクセスよりも大幅に優れた性能を示す。
Bashだけで十分である： 最小限のbashのみの足場があれば、IDEプリミティブなしでもソフトウェアエンジニアリングのベンチマークにおいて競争力のある性能を達成できる。
コード実行（Code Execution）が最適である： エージェントのアクションを単一の execute_code ツール（Model Context Protocol: MCP経由）にルーティングすることで、ネイティブツールを直接呼び出す場合に比べてトークン使用量を劇的に削減できる。

先行研究がこれらの矛盾を解決できなかったのは、既存の研究が特定の変数（例：特定のモデルにおけるACI vs. シェルの比較）のみを固定しており、タスク・レジーム（計算 vs. コード修正）とエージェント設計（異なるモデルファミリー）を交差させて検証していないためです。その結果、フィールドには、どの条件がどのツール・サーフェスを支持するかについての統一的な理解が欠けています。

メソドロジー

著者らは、整合性が保たれた3アームの切断（ablation）研究を用いて、「欠落した交差比較」を実施しています。実験デザインは $3 \times 2 \times 2$ の要因構造となっています。

3つのツール・サーフェス:
- ベースライン (Baseline): エージェントのデフォルトのツール・サーフェス（例：Read, Grep, Edit, Write, Bash）。
- Bashのみ (Bash_Only): ネイティブなbashと読み取り専用のブラウジング（Read, Glob, Grep）に限定。すべてのファイル編集プリミティブ（Edit, Write）は削除される。
- コードのみ (Code_Only): 全てのネイティブ・サーフェスを、永続的なPython+Bash REPLを実行する単一のMCPツール（mcp__codebox__execute_code）に置き換える。すべてのネイティブな組み込み機能は禁止される。
2つのエージェント: Claude Code (モデル claude-sonnet-4-6) と OpenAI Codex CLI (モデル gpt-5.5)。
2つのタスク・レジーム:
- 計算 (Computation): ワークスペース、隠されたグレーダー、および参照出力によって定義される自己完結型のタスクからなる、新しい「Artifact」スイート ( $n=93$ )。
- 修正 (Modification): リポジトリ修正タスクの精選されたサブセットである SWE-bench Mini ( $n=100$ )。

実験コントロール:

整合性 (Integrity): ハーネスは、エージェントの終了後にテストパッチが適用されるという厳格なSWE-benchプロトコルを強制する。ファイルシステムのステートは、相互汚染を防ぐために fuse-overlayfs を使用してアーム間で隔離される。
コスト会計: サーバー側のプロンプトキャッシュの変動に対処するため、著者らは「キャッシュ調整済みコスト」指標を採用している。これは、完全なキャッシュ隔離を主張することなく、最初のターンにおける入力トークンにメディアン・フロア調整を適用し、「ウォーム/コールド」キャッシュの抽選を正規化するものである。
統計的厳密性: 推論の単位はシードではなくタスクである。結果は、3つの独立したシードにわたるタスクごとの差分に対して、ペア・ウィルコクソン符号付順位検定を用いて分析される。

主要な貢献

1. 4セルのエージェント条件付きコスト構造

本研究は、エージェントを execute_code に制限することのコスト効率性は普遍的なものではなく、タスク・レジームとエージェント設計によって共同で決定されることを明らかにしています。

4つのセルのうち3つが code_only を支持:
- Artifact/Claude: 大幅なコスト削減（ $-24.6\%$ , $p=7.4 \times 10^{-14}$ ）。
- Artifact/Codex: 方向性のあるコスト削減（ $-6.7\%$ , 有意ではない）。
- SWE-bench/Codex: 有意なコスト削減（ $-19.9\%$ , $p=2.0 \times 10^{-9}$ ）。
1つのセルが傾向を逆転させる:
- SWE-bench/Claude: code_only は方向性としてコスト高（ $+14.4\%$ , 有意ではない）。

この発見は、先行文献における3つの主張が矛盾しているのではなく、特定の（レジーム, エージェント）の組み合わせにおいてのみ真であることを示しています。

2. 3つのメカニズムによる因果分解

著者らは、観察されたコストの分散を3つの明確なメカニズムに分解しています。

パス・コスト (編集摩擦 / Edit Friction): SWE-benchにおけるClaudeの場合、code_only ではすべてのファイル編集がPythonスクリプトとして表現される必要がある。これにより、編集量に応じて出力トークンが増大する（Spearman $\rho=0.488$ ）、いわゆる「税金」が発生する。
失敗コスト (Failure-Cost): ClaudeにおけるSWE-benchのコスト超過は、「破滅的な実行（doomed-run）」の軌跡（すべての構成要素が失敗するインスタンス）に局在している。全会一致でパスしたインスタンスのサブセットでは、コスト差は $+14.4\%$ から $+4.1\%$ （有意ではない）へと縮小する。
価格の非対称性 (バッチ処理 / Batching): CodexにおけるSWE-benchでは、code_only は主に入力トークンの削減（ $-24.8\%$ ）を通じて、有意な節約（ $-19.9\%$ ）を達成している。これは、ツール呼び出しのバッチ処理（1つのPythonスクリプトが複数のネイティブツール呼び出しを代替する）と、プログラムによる出力抑制（エージェントが出力量を制御し、ネイティブツールのハードな出力上限を回避する）によって駆動されている。

3. 能力の不変性 (Capability Invariance)

4つのセルすべてと3つのツール・サーフェスにわたり、合格率（pass rates）は統計的に同等である（差は3パーセントポイント未満であり、すべて有意ではない）。

合意行列は、大多数のインスタンス（多数決の下で $\ge 91\%$ ）において、すべてのアームが共にパスするか、あるいは共に失敗することを示している。
これは、ツール・サーフェスの選択がタスクを解決するための「経路」と「コスト」を変えるが、「解決能力」自体は変えないことを裏付けており、「能力重複の原則（Capability Overlap Principle）」と一致している。

結果の要約

本論文は、いつ code_only が有益であるかを示す「一目でわかる」マップを提供している。

計算タスク (Artifact): エージェントを execute_code に制限することは、両方のエージェントにとって安価であり、Claudeにおいて顕著な勝利となる。
修正タスク (SWE-bench) + Codex: 入力トークンのバッチ処理と出力制御により、code_only に制限することは大幅に安価である。
修正タスク (SWE-bench) + Claude: code_only に制限することは、方向性としてより高価になる。これは「編集摩擦」（編集による出力トークンの増加）と「失敗コスト」（高価な失敗軌跡）によるものであり、成功した編集に対するペナルティによるものではない。

意義と主張

本論文は、単一のツール・サーフェスがあらゆる文脈において最適であるわけではないことを示すことで、この分野の「3つの矛盾する主張」を解決することを目的としている。

コスト vs. 能力: ツール・サーフェスの選択における主要なシグナルは、合格率ではなくコストである。合格率は不変であるため、サーフェスの選択は能力の向上ではなく、コスト・エンジニアリングの決定事項となる。
共同決定: 最適なサーフェスは、タスク・レジーム（計算 vs. 修正）と、特定のエージェントの実装（バッチ処理、出力制限、および編集プリミティブの扱い方）の交差によって決定される。
経験的受領: 本研究は、コーディングエージェントにおける「ツール使用税（tool-use tax）」の不等式を支持する最初の経験的証拠を提供する。すなわち、ツール・サーフェスが純利益をもたらすのは、そのタスク固有の能力向上が、呼び出しごとの定義コストを上回る場合のみである。

著者らは、自らの知見はコスト・エンジニアリングの主張であり、能力の主張ではないことを明示している。彼らは code_only が普遍的に優れていると提案しているわけでも、さらなる検証なしに自らの結果がすべてのモデルや外部のMCPツールに一般化できると主張しているわけでもない。その意義は、エージェントのデザインとレジームの効果を判別することを可能にする方法論的フレームワークにあり、分野を逸話的な業界レポートから、制御された交差切断研究へと進化させることにある。