AIエージェント

コーディングエージェントのツール設計：見せ方で成功率は変わるか

2026/8/25 （更新: 2026/10/7）

🤖 AIが執筆しています

「できること」を変えずに、「見せ方」を変える

著者らの出発点は、ツールをめぐる研究の偏りにある。エージェントのツールに関する工夫の大半は、何ができるようになるかという能力の側を広げることに向かってきた。一方で、その能力がどう組織され、モデルにどう提示されるかという設計次元には、体系的な注意が払われてこなかった。著者らはこの後者を tool architecture（ツールアーキテクチャ） と呼ぶ¹。

実験の作り方が、この定義をそのまま形にしている。著者らは 6種類のツールアーキテクチャを比べ、基盤となる情報と行動は同等に保っている。どのアーム（実験条件）でも、エージェントが触れる情報も、起こせる行動も同じだ。違うのは、それをどんな単位に束ね、どんな形で目の前に出すかだけである。

そこに 3種類の actor を通した。ここでの actor は、与えられたツールを使って実際に issue を解きにいくエージェント本体を指す。著者らが集めたのは合計 11,700 のトラジェクトリで、トラジェクトリとは、エージェントが課題を受け取ってから終えるまでの行動と観測の一続きの記録である。課題はリポジトリ規模の issue 修正だ。単発の関数を書かせる問題とは違い、既存のコードベースの中で報告された不具合を直す仕事である。

11,700 という数は、課題の多さではなく繰り返しの多さを表している。著者らは SWE-bench Live の100リポジトリから25を無作為に抜き、1リポジトリあたり最大5件を残して 65の課題を作った。それを6アーム × 3種類の actor × 10回ずつ解かせた総数が 11,700 である¹。以下に出てくる数字は、すべてこの65課題の上に立っている。ただし効いた三つについては、原典がこの外側でも確かめている。SWE-bench Verified（issue 修正）、SWE-bench Pro（機能実装）、issue にスタックトレースが付いたものを集めたデバッグ課題の三つを使い、合わせて23リポジトリ72課題で、全体では同じ向きの結果が出る（課題別には揃わない升目もある）ことを付録で報告している。そちらは actor を2つに絞り、比較も三組に絞った著者ら自身による縮小版の追試で、効かなかった一つ（認知的足場）はこれに入っていない¹。

効いた三つは、別々の代償を払う

一つ目は、構造化された低水準インタフェースである。比較の基準になったのは、エージェントが bash ツールしか持たない構成だ。bash ツールとは、シェルのコマンド行をそのまま実行させる汎用の口で、これさえあればファイル閲覧も検索も編集も原理的にはできる。何でもできるかわりに、どう使うかは毎回モデルが決める。ここに、読む・書く・探すといった操作を個別の口として切り出した低水準インタフェースを置くと、繰り返し試行にわたる一貫性が最大4.7倍改善した¹。ここでいう一貫性は、原典が pass^k と呼ぶ指標、すなわち同じ課題を k 回解かせて k 回とも成功する確率を指す。やり方が毎回同じになるという意味ではない。経路のばらつきのほうは原典が別の軸（繰り返しのあいだで読んだファイル集合がどれだけ違うか）で測っている。そちらを3つの actor で一貫して広げたのは自然言語検索だけで、この構成ではほとんど動かない¹。

「最大」と付いているとおり、これは条件を通した平均値ではない。4.7倍が出たのは9回連続の成功率で、しかも3つの actor のうち最も弱いモデルが 2.0% から 9.4% へ上がった場合である。強い2つでは1.05倍と1.12倍にとどまった。原典も、この構成の利得は最も弱い actor で最大だと書いている¹。その出所として原典がもっともらしいと挙げるのは、環境とのやり取りで起きる誤りの減少である。最も弱い actor では、プログラムを壊す編集が1試行あたり平均 1.64 回から 0.19 回へ、ツールの呼び出しの書き誤りが 0.96 回から 0.01 回へ減った。そのぶん、同じ課題を繰り返し解いた最終パッチは互いに似通った¹。

利得と費用は逆向きに出る。原典の効率の節は、この構成が費用を下げたのは最も弱いモデルだけで、強い2つ（Kimi-K2.5 と Sonnet-4.5）ではむしろ入力トークンが目立って増えたと報告している¹。bash なら1回でまとめて書ける作業を、読む・書く・探すの個別の口に割るぶん、ターンが増えるからだ。原典は所見を「この構成が得なのは、actor がもともと細かい単位で動いているときだけで、そうでなければ複合的な bash の作業を分割してターンを増やし、累積のトークン費用を押し上げる」と1文で置いている¹。

二つ目は自然言語検索だ。探したいものを言葉のまま書いて渡せる検索口を与えると、関連ファイルの再現率が相対で1割前後（actor 別に 9.7〜11.3%）上がった¹。再現率は、解決に関わったと見なせるファイルのうち実際に読まれた割合を指し、原典の表では絶対4.6〜6.4ポイントの上げ幅である。ただし原典は同じ一文の後半に「そのぶんノイズも増える」と自分で書き添えており、表では読んだファイルの適合率が4.6〜10.4ポイント下がることも示している¹。網は広がるが、そのぶん要らないものも入る。なお著者らはこの検索口を、埋め込み索引ではなく同じモデルを使う検索サブエージェントとして実装している¹。

この二つは、効きの向きが違う。前者は成功を取りこぼさなくする効きで、後者は見に行く範囲を広げる効きだ。手元の不満が「解けたり解けなかったりする」なのか「見るべきファイルに辿り着かない」なのかで、選ぶべき構成は分かれる。

三つ目は、成功率ではなく単価に出た。Python の CodeAct 形式のインタフェースは、同程度のタスク性能を、41.6%少ないステップと56.3%少ない入力トークン費用で達成している¹。この2つは要旨の見出し数値で、actor ごとの実測は原典の表のほうにある。ステップは 77→46、65→47、80→55 で、減り幅は28〜40%の間に散る。トークンのほうも「入力」に限った話だ。減ったのはステップごとに履歴ごと再送される累積の入力であって、生成した出力トークンと環境から返る観測トークンについては、原典が付録で「一様に小さくなるわけではなく概ね横ばい」と書き、3つの actor のうち2つではむしろ観測トークンが増えている。効いたのは1ステップを安くしたことではなく、API 呼び出しの回数そのものを減らしたことである¹。性能が上がったという報告ではない。同じ水準に、より短く、より安く着いたという報告である。もっとも、成功率がほぼ揃うことは、6アームの能力差を意図的に最小化した実験設計から予期されていた結果でもある¹。

そして安さには相手がある。一つ目で導入した pass^k で見ると、Python は一貫性を上げない。最も弱い actor では9回連続の成功率が 2.0% から 0.2% へ落ち、6アームで最も低い。強い2つでも全域で bash だけの構成を下回るか横ばいだった。原典は表の直後に「Scratchpad と Python は概して中立から負である」「pass^k がすべての actor で一様に正なのは Atomic だけだ」と置いている¹。探索の軸でも同じで、関連ファイルの再現率は3 actor とも 1.9〜4.7ポイント下がる¹。

記入欄を埋める作業から、プログラムを書く作業へ

CodeAct 形式そのものは、この統制実験が作ったものではない。2024年の独立した先行研究が提案し、名前も付けた形式である²。

その研究の出発点は、行動の書かせ方にあった。LLMエージェントは通常、あらかじめ定めた形式の JSON かテキストで行動を出力するよう促される。著者らはここに二つの限界を見る。一つは行動空間が制約されることで、選べるのはあらかじめ定義されたツールの範囲に限られる。もう一つは柔軟性が制限されることで、複数のツールを組み合わせられない²。

CodeAct の提案は単純だ。実行可能な Python によって、エージェントの行動を単一の行動空間に統合する。Python インタプリタと組み合わせれば、コードによる行動をその場で実行でき、返ってきた新しい観測に応じて直前の行動を動的に修正したり、新しい行動を出したりできる²。ツールの呼び出しは、記入欄を埋める作業から、プログラムを書く作業になる。

著者らは 17個のLLMを API-Bank と新規に作った M3ToolEval の二つで解析し、CodeAct が広く使われている代替手法（Text や JSON）を最大20%高い成功率で上回ったと報告する²。この「最大20%」は、要旨の見出し数値をたどると一点に行き着く。出所は M3ToolEval の側だ。web閲覧・金融・旅程計画・科学・情報処理の5領域にまたがる手作りの82問で、コードを書く課題ではない。複数のツールを組み合わせて答えに至れるかを、デモ無し・最大10ターンで測る。そこで最良のモデル一つ（gpt-4-1106-preview）が次点のテキスト形式に対して74.4%対53.7%、絶対で20.7ポイントの差を付けた、という数字である。相対で2割ではない。その M3ToolEval でも CodeAct が最良だったのは17モデル中12で、閉じたモデルの中にも JSON に11ポイント負けているもの（claude-instant-1）がある。原典は20.7ポイントの直後に、開いたモデルの最良が13.4%にとどまることも書き添えており、この差は絶対性能の高い閉じたモデルの側で出ている²。もう一方の API-Bank が測るのは単発のAPI呼び出しの正解率で、そこで CodeAct が最良だったのは17モデル中8にとどまり、閉じたモデルに限れば JSON のほうが上回ることが多かった²。

ではツールアーキテクチャ実験の「同程度」は、この20.7ポイントへの反証なのか。そうではない。原典は resolve rate が6アームでほぼ揃ったことを実測として報告し、能力差を最小化するよう意図的に設計しているのだから予期されたことだ、と明言している。そのうえで、効果を非機能的な性質のほうへ切り出している¹。比較の相手も違う。CodeAct が差を付けたのはあらかじめ形式を決めた JSON やテキストの呼び出しで、ツールアーキテクチャ実験の対照は汎用シェルだ。シェルはもともと Python スクリプトを書いて走らせられる、表現力の高い行動空間である。つまり二つの報告は、性能の軸で逆を向いているのではなく、そもそも同じ問いに答えていない。20% をリポジトリ規模の課題に持ち込む根拠にはならないし、ツールアーキテクチャ実験の側で CodeAct 形式に出た差は、平均の成功率ではなく単価と一貫性のほうである。

考えを書き留めさせるツールは効かなかった

四つ目の候補は、外れた。中間的な推論を書き留めさせるような、軽量なテキストベースの「認知的足場（cognitive-scaffolding）」ツールは、actor の挙動にほとんど影響しない¹。計画を書き出させる、考えたことをメモに残させる、次の一手を宣言させる、といった類のツールである。

これは負の証拠として重い。思考を明示的に書かせるツールを、多くの設計者が採っている。実装が軽く、足すのに費用がかからず、出力を読むと「考えているように見える」という手応えもある。統制実験が言っているのは、その手応えが挙動の変化として現れなかった、ということだ。原典は理由まで書いている。これらのツールは検索も記憶管理も新しい情報も足さず、推論のしかたを強制もしない。書き留める場所を1つ増やすだけである。書き留められた内容は bash だけのときに既に出ていた推論と文面がほとんど重なり（BLEU 0.6 超の項目が多い）、複数の仮説を並べて保持する使い方はまれで、呼び出し回数もそもそも少ない（仮説追跡はほとんどの試行で5回未満、スクラッチパッドは強い2つの actor でほとんどの試行が10回未満）¹。実装が軽いことは、この所見への反論にならない。原典自身も、この結論を「ここで調べた軽量な足場に限った話であり、認知的足場一般についての主張ではない」と切っている¹。

反対向きの測定もある。Anthropic は2025年3月、新しい情報も取らず考えをログに書き足すだけの「think」ツールを自社モデルに持たせた評価を公開した。方針の込み入った顧客対応の課題（τ-bench の航空）では、使い方の例を添えたプロンプトと組み合わせたとき、1回の試行での成功率が 0.370 から 0.570 へ上がったという（同じ報告に載る表では 0.332 から 0.584 で、本文の値と揃わない）。この報告は SWE-bench でも測っており、think ツール単独の効果は平均 1.6% の上げで、その差に Welch の t 検定で p < .001 を添えている。同社は2025年12月の追記で、多くの場合は専用のツールより拡張思考の機能を使うよう勧めている³。ベンダーによる自社モデルの評価で、査読も経ていない。同社もこのツールはすべての用途に当てはまるわけではないと書いている³。書き留めさせるツールが効くかどうかは、課題の性質と使わせ方で変わりうる。リポジトリ規模の issue 修正の上でも、二つの測定の向きは揃わない。統制実験では挙動がほとんど動かず、Anthropic の評価では SWE-bench の成績が小さく上がった。一貫性・探索・単価を動かしたいなら、先に手を付けるのは上の三つである。

6つのアームは、既存のエージェントの設計から取られている

ここまでの6アームは、実験のためにこしらえた架空の構成ではない。原典は各アームに、同じツールの設計を採る既存のエージェントを対応させている¹。bash だけの構成は SWE-bench の bash-only リーダーボードや mini-SWE-agent にあたる。読む・書く・探すを個別の口に切り出す構成は OpenHands・Claude Code・TRAE・SWE-agent、自然言語検索は Augment Code のコンテキストエンジン、Python の構成は smolagents である。書き留めさせるツールは、複数のエージェントが備える sequential thinking のツールを写している¹。見せ方は、作り手の側では既に選び分けられている。

見せ方が挙動を動かしうるという見立ても、この実験が最初ではない。原典は「似た情報に触れ、似た行動を取れる二つのエージェントでも、その能力をどう組織してモデルに見せるかで挙動は意味のある形で変わりうる」という見立てを、2024年の SWE-agent の研究に帰している¹。先に見た CodeAct も、同じ2024年の提案である²。統制実験が足したのは、既存の選択を能力を揃えたまま並べ直して測り、効く選択と効かない選択を分けたことである。

リポジトリの側に置かれているのは、ほぼ指示文書だけ

設定の側には、別の調査がある。AIware 2026 で発表され、その後 arXiv で拡張された探索的研究が、2026年2月時点で Claude Code、GitHub Copilot、Cursor、Gemini、Codex の設定機構を分析している。その研究は、静的なコンテキストから実行可能なもの、外部連携までにわたる 8つの設定機構を同定している⁴。そのうえで走査対象を条件で絞っている。GitHub の OSS で、フォークでなく、貢献者2人以上、OSI ライセンス、主要10言語、コミット271本以上・ウォッチャー7人以上、2025年6月以降にコミットがあり、しかも2024年1月1日より前に作られたものである。最後の条件は原典が理由を明記していて、検出される設定を「そのツールを前提に生まれた新規プロジェクトではなく、確立したプロジェクトへの後付け」に限るためだ。この37,249本から README で開発の実体を判定できた 32,564本の既定ブランチを走査し、エージェント向けの設定成果物が一つでも見つかったのは 2,853本、約9%だった⁴。

その9%の中で、結果は大きく偏った。Context Files が設定の風景を支配している。採用者2,853本のうち2,586本（90.6%）にコンテキストファイルがある⁴。Context Files は、エージェントが起動時に読む静的な指示文書のことで、リポジトリに置かれた唯一の設定機構であることも多い。AGENTS.md が、ツール間で相互運用可能な標準として立ち上がりつつある⁴。

一方で、Skills や Subagents のような高度な機構を採用しているリポジトリは少ない。Skills は、特定の手順をひとまとめにしてエージェントに読み込ませる再利用可能な部品で、Subagents は、下位のエージェントに部分課題を委譲する仕組みだ。しかも採用されている Skills も、その大半は実行可能なスクリプトではなく静的な指示に依存していた⁴。ツールごとの慣行も分かれつつあり、Claude Code の利用者が最も広い範囲の機構を使っている⁴。ただしこれは2026年2月の静止画である。原典は同じ調査の中で、コンテキストファイルの採用が継続的に増え続けている（Skills と Subagents の伸びは相対的に遅い）ことを時系列でも示しており、自分の結果を「慣行がまだ固まっていない分野の、ある一点のスナップショット」と断っている⁴。

並べるとこうなる。2024年以前から続く OSS プロジェクトの9割はエージェント向けの設定を一つも置いておらず、置いている1割弱でも、ほぼコンテキストファイル一本である⁴。ただしこの数字は、統制実験が比べたツールの見せ方が現場で使われていないことを示してはいない。ツールの切り分けと提示の形を決めるのはエージェントの作り手で、その選択は既存のエージェントごとに既に分かれている¹。この調査が数えたのは、リポジトリの所有者がその上に何を置くかである。エージェントを前提に生まれた新しいリポジトリや、社内の閉じたリポジトリは原典の母集団に入っていないので、そちらの採用率は分からない。設定ファイルが置いてあるだけで使われているとは限らない、という疑いのほうには答えがある。原典は2,853本の全コミット履歴を走査し、2,058本（72.1%）で AI 由来のコミットを実際に検出している。明示的な帰属が残る場合しか数えていないので、これは下限である⁴。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。