AIエージェントのツールをコード実行のみに制限するとコストは削減できるのか?
公開日
開発生産性
ソフトウェア開発の自動化に向けてAIコーディングエージェントの導入が進む中、エージェントに「どのような操作権限(ツール)を与えるべきか」という設計論が活発に議論されています。ファイル編集用の専用ツールやシェルコマンドなど、多様な操作手段を提供する設計が主流である一方、インターフェースをシンプルに保つ方が効率的であるという主張もあり、開発現場での最適なツール設計は未だに明らかになっていません。
この疑問に対して、ロチェスター工科大学の研究チームは、2026年に発表した論文「When Does Restricting a Coding Agent to execute_code Help? A Regime × Agent-Design Ablation」において、エージェントの操作権限を「コード実行ツール(execute_code)」のみに制限した場合の影響を多角的に検証しました。
ツール制限を検証する実験設計
研究チームは、エージェントに与える操作ツールの範囲が、タスクの達成率とAPIコストにどのように影響するかを調べるため、厳密な比較実験を行いました。
実験では、以下の3つの「操作画面」を定義し、同一のプロンプトとテスト環境を用いて比較しています。
- baseline:エージェント標準のすべてのツール(ファイルの読み書き、検索、シェル操作など)を使用可能。
- bash_only:ファイル書き換えの専用ツールを禁止し、標準的なシェル操作(bash)と閲覧のみを許可。
- code_only:全ての標準ツールを禁止し、コード実行ツール(
execute_code)のみを使用可能にする。この構成では、ファイルの読み書きや編集も、エージェントがPythonなどの使い捨てスクリプトを生成して実行することで間接的に行います。
これらのツール構成を、2つの開発者向けAIモデル(Claude CodeおよびCodex CLI)と、性質の異なる2つのタスク群(計算処理タスクの「Artifact」と、実際のソフトウェア修正タスクの「SWE-bench Mini」)を組み合わせた4つの環境で評価しました。
パス率は維持され、ツールの制限は能力に影響しない
実験の主要な発見として、操作ツールを「コード実行(code_only)」のみに厳しく制限しても、タスクの達成率(パス率)はほぼ低下しないことが明らかになりました。
すべての検証パターンにおいて、豊富なツールを使える「baseline」と、コード実行のみに制限した「code_only」の間で、パス率の差は3ポイント未満にとどまり、統計的な有意差は認められませんでした。これは、LLMが必要なファイル操作や推論をスクリプト経由で自律的に表現できるためであり、エージェントの能力自体はインターフェースの制約を受けにくいことを示しています。
多くの構成で20%以上の大幅なコスト削減が実現
パス率に差がない一方で、APIの利用料金(コスト)には大きな違いが現れました。検証された4つの環境のうち3つにおいて、操作ツールをコード実行のみに制限した構成が、最もコスト効率が良い、あるいは統計的に同等であることが確認されました。
-per-(benchmark,-agent)-cell,-on-a-10-parity-line.avif)
図1:各実験条件における最安のツール構成に対するcode_only構成のコスト比
具体的には、Claudeモデルを用いた計算処理タスク(Artifact/Claude)で24.6%のコスト削減、Codexモデルを用いたソフトウェア修正タスク(SWE-bench/Codex)で19.9%のコスト削減を達成しています。不要なツールの定義をプロンプトから排除し、ツールの呼び出しステップを減らすことで、入力トークン量が大幅に抑制されたことが主な要因です。
| 評価タスク | モデル・エージェント | パス率の差 (ポイント) | コスト削減率 (%) | 統計的有意差 |
|---|---|---|---|---|
| Artifact (計算) | Claude Code | 0.00 | -24.6% | 有意差あり (p < 0.001) |
| Artifact (計算) | Codex CLI | +2.51 | -6.7% | 有意差なし (傾向のみ) |
| SWE-bench (修正) | Claude Code | -1.67 | +14.4% | 有意差なし (傾向のみ) |
| SWE-bench (修正) | Codex CLI | +0.33 | -19.9% | 有意差あり (p < 0.001) |
表1:デフォルト構成(または最安のライバル構成)に対するcode_only構成の性能変化
例外的なコスト増加とその原因
しかし、唯一の例外として、Claudeモデルを用いたソフトウェア修正タスク(SWE-bench/Claude)では、コード実行のみに制限するとコストが14.4%増加する傾向が見られました。研究チームはこの要因を詳しく分析し、2つの問題を特定しています。
1. 間接的なファイル編集に伴うオーバーヘッド
SWE-benchのような大規模なコード修正タスクにおいて、専用の編集ツール(Edit/Write)が使えない場合、エージェントは1行の修正であっても「ファイルを読み込み、置換処理を行うPythonスクリプト」を書いて実行しなければなりません。この間接的な編集プロセスにより、出力トークン数が39.9%増加し、コストを押し上げる要因となりました。
2. 解決できないタスクでの「失敗コスト」
さらに、このコスト増加はすべてのタスクで一律に発生しているわけではありませんでした。すべてのツール構成で解決できた「成功タスク」のみに絞って分析すると、コストの増加率は14.4%からわずか4.1%にまで縮小しました。
つまり、コスト増の大部分は「エージェントがどうしても解決できない難解なタスク」において、コードの記述と実行を何度も泥沼のように繰り返してしまった、無駄な試行プロセス(失敗コスト)に起因していたのです。
実務におけるエージェント設計
本研究の結果は、自社開発のAIアシスタントや市販のエージェントツールを導入・設計するエンジニアやマネージャーにとって、重要な設計指針を与えてくれます。
1. タスクの性質に応じた「引き算」のツール設計
エージェントを導入する際、あらゆる操作が可能な多機能ツールを揃える必要はありません。データ解析や数値計算、バッチ処理のような「計算・処理が中心のタスク」においては、ファイル編集やブラウジングの専用ツールを廃止し、独立した実行環境(REPL環境など)へのコード実行権限のみを与える設計(Code-as-Action)にするべきです。これにより、タスク成功率を損なうことなく、APIコストを約25%削減できます。
2. 修正タスクには専用編集ツールを残す
一方、リポジトリ全体の複数ファイルにまたがる「コード修正タスク」が中心の場合、完全なコード実行のみへの制限は避けるべきです。行単位での変更を正確に行える専用の編集ツールを残すことで、間接的なスクリプト生成に伴うトークン消費を防ぐことができます。
3. 失敗時の早期離脱(アーリーストップ)の重要性
エージェントの運用コストを管理するうえで最も警戒すべきなのは、解決不可能な問題に対してエージェントが延々と試行錯誤を繰り返す「ドゥームドループ(Doomed-run)」です。解決の見込みがないと判断した段階で処理を打ち切る、あるいは一定回数の実行エラーで強制終了させるなどのガバナンス設計が、APIコストの爆発を防ぐために実務上極めて有効です。
まとめ
本研究は、AIコーディングエージェントの操作インターフェースを「コード実行」に絞り込むアプローチが、コスト効率化において非常に強力な選択肢であることを示しました。
ツールを制限してもエージェントの解決能力(パス率)自体は維持されるため、タスクの種別に応じてツール群を引き算することで、不要なトークン消費を抑えられます。エージェントを自社ツールや開発パイプラインに組み込む際は、単純な多機能化を目指すのではなく、タスク特性とコストのバランスを考慮したインターフェース設計に取り組むことが推奨されます。
開発生産性やチームビルディングにお困りですか? 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるためのさまざまなソリューションを提供しています。ぜひお気軽にご相談ください!
参考資料: