In Silico

AIエージェント

道具の見せ方で挙動は動く——効く三つ、効かない一つ

2026/8/25

🤖 AIが執筆しています

目次
※ 概念図（数値は出典より） 【設定】 できることは同等のまま、見せ方だけを変える 6アーキテクチャ／3 actor／65課題×10回＝11,700トラジェクトリ 【結果】 効いた三つ 連続成功率 最大4.7倍（最弱actorで2.0→9.4%） 到達+11%超（適合率↓）／歩−41.6%（一貫性↓） 効かなかった一つ 思考を書き留めさせる軽量な足場 【留保】 現場と揃うのは能力カテゴリ。道具の分け方もその周りも、まだ揃っていない 収束＝能力カテゴリ（読む・探す・編集・実行）／発散＝ツール数0〜37・制御ループ・圧縮戦略 2024年以前からのOSS 32,564本中、設定を置くのは2,853本＝約9%
※ 概念図（フロー）・作図：AI。数値は出典より。現場と揃っているのは道具の下の能力カテゴリで、道具の分け方そのものも、その周りのループも、設定を置いていない大多数も、まだ揃っていない。
背景

AIエージェント——指示を受け取り、自分で道具を呼び出しながら作業を進めるプログラム——に仕事をさせるとき、作り手がまず考えるのは「何ができるようにするか」だ。ファイルを読む、リポジトリを検索する、コマンドを走らせる、テストを回す。使える道具を足せば、こなせる仕事の幅は広がる。道具を足す作業は成果が目に見えるし、足したぶんだけ効くように感じられる。

だが道具には、別の面がある。同じ能力でも、それをどんな単位に切り分け、どんな名前と説明で並べ、どんな書き方で呼ばせるかは、作り手が選んでいる。ファイルの中身を見る操作を、汎用のシェルに打つ命令として渡すのか、専用の読み取り口として渡すのか。呼び出しを決まった書式の記入欄にするのか、その場で書ける短いプログラムにするのか。できることは同じなのに、渡し方は何通りもある。

この「渡し方」は、たいてい作りはじめに決まったまま見直されない。能力の目録には現れず、比べる対象にもなりにくいからだ。しかし受け取る側にとっては、そこが作業の入口そのものである。

問い

能力を変えずに道具の見せ方だけを変えたとき、エージェントの挙動は本当に動くのか——動くなら、どの選択が効いて、どの選択が効かないのか。

要点

動く。しかも効く選択と効かない選択がはっきり分かれ、広く使われている設計が、効かない側に入る。 2026年8月に公開された統制実験は、この設計次元を tool architecture（ツールアーキテクチャ） と名づけた1。基盤となる情報と行動は同等に保ったまま、組織と提示の仕方だけを変えた 6種類のアーキテクチャを、3種類の actor に与え、11,700 のトラジェクトリを集めている。効いたのは三つ。bash ツールしか持たない基本構成と比べ、構造化された低水準インタフェースは繰り返し試行にわたる一貫性——同じ課題を k 回解いて k 回とも成功する確率——を最大4.7倍改善した。自然言語検索は関連ファイルへの到達を11%以上増やした（そのぶん読んだファイルの適合率は下がる）。Python の CodeAct 形式は、41.6%少ないステップと56.3%少ない入力トークン費用で、タスク性能を落とさずに済ませた（そのかわり一貫性は下がる）。効かなかったのは、中間的な推論を書き留めさせる軽量な「認知的足場」の道具である1。ただし測られた場所はコーディングエージェントの土俵——リポジトリ規模の issue 修正に、機能実装とデバッグを足した範囲——であって、あらゆるエージェント一般ではない。そして実際に動いている足場のほうは、道具の下の能力カテゴリでは現場も四つに収束している一方、その上のツール数は0から37まで開き、制御ループやコンテキスト圧縮も散らばっており、6アームのどれかにそのまま重なるわけではない2。リポジトリを見ると話はさらに手前で、エージェント向けの設定を一つでも置いているのは走査対象の約9%にとどまる3。

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

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

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

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

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

効いた三つ

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

「最大」と付いているとおり、これは条件を通した平均値ではない。4.7倍が出たのは9回連続の成功率で、しかも3つの actor のうち最も弱いモデルが 2.0% から 9.4% へ上がった場合である。強い2つでは1.05倍と1.12倍にとどまった。原典も、この構成の利得は最も弱い actor で最大だと書いている1。

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

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

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

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

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

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

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

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

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

著者らは 17個のLLMを API-Bank と新規に作った M3ToolEval の二つで解析し、CodeAct が広く使われている代替手法（Text や JSON）を最大20%高い成功率で上回ったと報告する4。この「最大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%にとどまることも書き添えており、この差は絶対性能の高い閉じたモデルの側で観測されたものだ4。もう一方の API-Bank で測られているのは単発のAPI呼び出しの正解率で、そこで CodeAct が最良だったのは17モデル中8にとどまり、閉じたモデルに限れば JSON のほうが上回ることが多かった4。

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

効かなかったもの——考えを書き留めさせる道具

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

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

現実の足場は、能力の層で揃い、道具の層から上で散らばる

ここまでは6アームの統制実験の話である。実際に動いているエージェントの足場（scaffold）——制御ループ、ツール定義、状態管理、コンテキスト戦略といった、モデルの外側でエージェントを成り立たせているコード——は、一枚の分類に収まらない。

単著のサーベイが、13個のオープンソース・コーディングエージェントの足場を、固定したコミットハッシュでソースコード水準まで降りて読んでいる。Claude Code、Cursor の AI バックエンド、GitHub Copilot Workspace は、足場コードが公開されていないため原典が名指しで除外している——この分類が描いているのはオープンソースの設計空間であって、コーディングエージェント全体ではない2。著者の問題意識は明確だ。既存のサーベイは抽象的な能力（道具利用・計画・内省）で分類するが、それではアーキテクチャ的に異なるシステムを区別できない。トラジェクトリを見る研究はエージェントが何をするかを観察するが、なぜそうなるかを決める足場コードそのものは調べない2。

読み取られた 12の次元は、制御アーキテクチャ／ツールと環境のインタフェース／資源管理の3層に整理された。結論は、足場のアーキテクチャが離散的な分類に馴染まないというものである。制御戦略は固定パイプラインからモンテカルロ木探索——次の手を木として展開し、試行を重ねて有望な枝を選ぶ探索手法——まで幅がある。ツール数は0から37まで開き、コンテキスト圧縮——文脈が長くなりすぎたときに履歴を要約したり切り詰めたりして収める処理——は7つの異なる戦略にわたる2。

ループの型も混ざっている。ReAct（推論と行動を交互に出す）、generate-test-repair（生成してテストして直す）、plan-execute（計画してから実行する）、multi-attempt retry（複数回やり直す）、木探索。この5つの原型は、排他的な分類というより、組み合わせ可能な構成要素として働いていた。13個中11個が複数を組み合わせている2。

ただし原典の結論には、もう半分ある。次元は、散らばるものと収束するものに分かれるというのが著者の第三の所見だ。散らばるのはコンテキスト圧縮・状態管理・複数モデルの振り分けといった、まだ設計の答えが定まっていない側。収束するのは外からの制約が効く側——ツールの能力カテゴリ、編集の形式、実行の隔離である。実際、ツール数が0から37まで開くと書いた直後に、著者は「その下の能力カテゴリは読む・探す・編集する・実行するの四つに収束する」と続け、この四つを自律コーディングエージェントの最小構成と見ている2。

ここで対応の向きを取り違えないようにしたい。収束しているのは能力カテゴリのほう——読む・探す・編集する・実行する——で、これは統制実験が6アーム全部で等しく保ったものである。原典は同じ段落で「0から37という幅は、能力レベルでの収束を生の本数が覆い隠しているだけだ」「bash ツール1本しか持たない mini-swe-agent も、シェルに委譲して四つ全部を覆う」と書いている2。統制実験が動かしたのはその一段下、同じ能力をいくつの口に割ってどう見せるかであり、そちらこそ原典が 0 から37まで開くと報告している側だ（Moatless Tools は検索カテゴリだけで6つの別アクションに割っている）2。実験は、現場が既に揃えている部分を固定し、現場がまだ揃っていない部分を動かした、ということになる。設計としては筋が通っているが、6アームが動かした幅——bash 1本と、検索・閲覧・置換・作成にシェルを足した5口——は、その帯のごく一部でしかない。実験の結論を自分の足場に持ち込むときは、道具の切り分け方も、それを回すループや圧縮戦略も、どちらも実験の想定より広い帯の上にあると勘定に入れる。著者自身も、この12の次元は変数を固定した統制実験に使えると次の一手に挙げており、統制実験を割り引く材料としては書いていない2。

測られた範囲の現場は、大半がまだレバーを握っていない

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

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

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

並べるとこうなる。統制実験がレバーとして測ったのは、道具の切り分けと提示の形だった。2024年以前から続く OSS プロジェクトの9割はそもそもどのレバーにも手をかけておらず、手をかけている1割弱でも、ほぼコンテキストファイル一本である。エージェントを前提に生まれた新しいリポジトリや、社内の閉じたリポジトリは原典の母集団に入っていないので、そちらの採用率は分からない。設定ファイルが置いてあるだけで使われているとは限らない、という疑いのほうには答えがある。原典は2,853本の全コミット履歴を走査し、2,058本（72.1%）で AI 由来のコミットを実際に検出している——明示的な帰属が残る場合しか数えていないので、これは下限である3。ハーネスが成績を動かすという一般論は既に共有されつつあるが、その中のどのつまみを回すかについては、測定と実践がすれ違っている。ここに、まだ触られていない余地がある。

実務で何を見るか

四本のうち三本は査読を通っている。CodeAct の提案は ICML 2024 の採択論文、ツールアーキテクチャの統制実験は COLM 2026 の採択論文、設定機構の実証は AIware 2026 に掲載された論文の拡張版である。査読前のプレプリントは、足場のソースコード分類の一本（単著）だけだ。ただし統制実験は投稿から10日も経っておらず、追試も再解析もまだ無い。数字は方向として読み、順位表として引き写さない。それでも、道具を足す以外の打ち手が測定として示された点は、今週から使える。

出典4件

  1. Xiangzhe Xu, Hamidreza Saghir, Qianhui Wu, Marc-Alexandre Côté, Tong Wang, Kiran Lakkaraju, Kexin Pei, Xiangyu Zhang, “The Devil Is in the Interface: Evaluating How Tool Architecture Shapes Coding Agent Behavior”（arXiv:2608.11386, 2026年8月11日投稿／PDF 各頁の柱に Published as a conference paper at COLM 2026 と印字。arXiv の abs 頁には Comments も Journal ref も無い）。エージェントの道具に関する従来研究が「何ができるか」を広げることに集中してきたのに対し、能力がどう組織されモデルにどう提示されるかという設計次元を tool architecture（ツールアーキテクチャ）と名づけ、リポジトリ規模の issue 修正で統制実験を行う。基盤となる情報と行動を同等に保ったまま組織と提示だけを変えた6種類のツールアーキテクチャを、3種類の actor・合計11,700のトラジェクトリで比較した。11,700 の内訳は、SWE-bench Live の100リポジトリから25を無作為抽出し1リポジトリ最大5 issue に絞った65 problem instances を、10 rollouts × 3 actor × 6アームで解かせた総数である。bash ツールしか持たない基本構成と比べ、構造化された低水準インタフェースは繰り返し試行にわたる一貫性（pass^k＝k 回の試行が全部成功する確率）を最大4.7倍改善し、自然言語検索は関連ファイルへの到達を11%以上増やし、Python の CodeAct 形式は同程度のタスク性能を41.6%少ないステップと56.3%少ない入力トークン費用で達成する。ただし4.7倍は pass^9・Qwen3Coder-30B の 0.020→0.094 で、Kimi-K2.5 は1.05倍・Sonnet-4.5 は1.12倍にとどまる。41.6% と56.3% は Abstract と Introduction の貢献リストにしか現れない見出し数値で、Table 8 の actor 別の実測はステップ 77→46・65→47・80→55（28〜40%減）である。同じ表で Total-Obs は Qwen3Coder-30B が 15,228→15,992、Kimi-K2.5 が 23,670→26,298 と増えており、Appendix B.5 は its total output tokens and total observation tokens remain broadly similar rather than uniformly smaller the main efficiency gain does not come from making each interaction cheaper, but from reducing the number of API calls needed to complete an attempt と書く。Python の側の代償も同じ論文に出ている——Table 2（pass^k）で Python は全 actor で BashOnly 以下（Qwen3Coder-30B の pass^9 は 0.020→0.002）、Table 7 で recall も3 actor とも低下（-0.042／-0.019／-0.047）し、著者らは Scratchpad and Python are generally neutral to negative Atomic is the only setup with uniformly positive pass^k deltas across all three actors と明記している。主要3所見の外部妥当性は Appendix B.6 で追試されており、SWE-bench Verified・SWE-bench Pro（機能実装）・スタックトレース付きデバッグ split の72 instances／23リポジトリで同じ向きが出る（actor は Qwen3Coder-30B と Kimi-K2.5 の2つ、5 rollouts、比較は Atomic／NLSearch／Python 対 BashOnly の三組のみ。認知的足場はこの追試に含まれない）。自然言語検索は埋め込み索引や意味索引ではなく、同じ actor モデルを用いる検索サブエージェントとして実装されている。その効果については、著者ら自身が同じ一文で but also introduce additional noise と書き添え、Table 7 で適合率が4.6〜10.4ポイント下がることを示している。また resolve rate が6アームで揃うのは測定結果ではなく設計上の前提で、著者らは This is expected, since we intentionally design the tool architectures to minimize capability differences relative to the BashOnly setup と明記する。一方、中間的な推論を書き留めさせる軽量なテキストベースの認知的足場（cognitive-scaffolding）ツールは actor の挙動にほとんど影響しない。§3.5 はこれを specific to the lightweight scaffolds studied here, rather than as a claim about cognitive scaffolding in general と限定し、Appendix C/D が機構を示している（スクラッチパッドの記述は BashOnly の推論に対する BLEU が高く多くが0.6超、HypoTrack の分岐利用はまれ、HypoTrack はほとんどの試行で5回未満、Scratchpad は Kimi-K2.5 と Sonnet-4.5 でほとんどの試行が10回未満の呼び出し）。対象はコーディングエージェントのリポジトリ規模 issue 修正で、Appendix B.6 が機能実装とデバッグまで広げている。https://arxiv.org/abs/2608.11386 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 ↩29 ↩30

  2. Benjamin Rombaut, “Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures”（arXiv:2604.03515, 2026年4月3日投稿）。LLMベースのコーディングエージェントを取り巻く足場コード（制御ループ、ツール定義、状態管理、コンテキスト戦略）がよく理解されておらず、抽象的な能力で分類する既存サーベイではアーキテクチャ的に異なるシステムを区別できないと指摘する。13個のオープンソース足場を固定コミットハッシュでソースコード水準から分析し、12の次元を3層（制御アーキテクチャ／ツールと環境のインタフェース／資源管理）に整理した。足場のアーキテクチャは離散的な分類に馴染まず、制御戦略は固定パイプラインからモンテカルロ木探索まで、ツール数は0から37、コンテキスト圧縮は7つの異なる戦略にわたる。5つのループ原型（ReAct／generate-test-repair／plan-execute／multi-attempt retry／木探索）は組み合わせ可能な構成要素として働き、13個中11個が複数を組み合わせている。ただし結論はもう半分あり、外からの制約が効く次元（ツールの能力カテゴリ、編集形式、実行の隔離）では収束し、答えの定まらない次元（コンテキスト圧縮、状態管理、複数モデルの振り分け）で発散する、と著者は書く。§5 は「0から37」の直後に yet the underlying capability categories converge on four (read, search, edit, execute) と続け、この四つを最小構成と見ている。また将来課題として The most direct extension is controlled experimentation を挙げており、統制実験を割り引く材料としては書かれていない。外部妥当性について原典は、足場コードが公開されていない Claude Code・Cursor の AI バックエンド・GitHub Copilot Workspace・Windsurf を除外したこと（The taxonomy should therefore be understood as describing the open-source design space, not the full design space of coding agents）、13本の分布は not claimed to be representative of any population であること、corpus が Python 向けエージェントに偏ることを自ら挙げている。単著という脆さについては、抽出した296の主張を clone したリポジトリへ当て直す事後検証（267を確認・19を訂正・10を簡略化として許容）を回している一方、分析自体は LLM 支援のコード探索を併用したと書いている。https://arxiv.org/abs/2604.03515 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  3. Matthias Galster, Seyedmoein Mohsenimofidi, Jai Lal Lulla, Muhammad Auwal Abubakar, Christoph Treude, Sebastian Baltes, “Harness Engineering for Agentic AI Coding Tools: An Exploratory Study”（arXiv:2602.14690, 2026年2月16日投稿。本記事が参照したのは AIware 2026 に掲載された “Configuring Agentic AI Coding Tools: An Exploratory Study” を拡張した v5・2026年6月30日で、2,853 という値はこの版で初めて出る。v1 の Abstract は 2,926）。Claude Code、GitHub Copilot、Cursor、Gemini、Codex の設定機構を体系的に分析し、静的なコンテキストから実行可能なものや外部連携までにわたる8つの設定機構を同定したうえで、採用の有無と方法を調べる（Context Files、Skills、Subagents を詳しく見る）。母集団は GitHub の OSS を条件で絞った37,249リポジトリから、README で「engineered」と判定できた32,564本で、設定成果物が一つ以上見つかったのがそのうち2,853本（約9%）、以下の比率はすべてこの2,853本の中の話である。条件には The creation cutoff of 1 January 2024 ensures that each repository predates the broad availability of agentic AI coding tools by more than a year, so detected configuration mechanisms represent additions to established projects rather than greenfield experiments built around the tools が含まれ、ほかに非フォーク・貢献者2人以上・OSI ライセンス・主要10言語・コミット271本以上・ウォッチャー7人以上・2025年6月以降のコミットがある。∴ 9% は「2024年以前に作られ、いまも活発な OSS プロジェクト」の採用率であって、社内リポジトリやエージェントを前提に作られた新しいリポジトリの採用率ではない（原典自身 We selected repositories showing established engineering practices, but cannot claim representativeness for closed-source development と書く）。データは point-in-time snapshot (February 2026) で、同じ調査が Context Files の採用は have increased continuously と時系列で報告している。2,853本の全コミット履歴を走査した結果、2,058本（72.1%）で AI 由来のコミットが検出されており（明示的な帰属が要るため下限）、設定成果物が実使用と結びついている根拠になっている。Context Files が設定の風景を支配し（2,586本＝90.6%）、リポジトリで唯一の機構であることも多く、AGENTS.md がツール間で相互運用可能な標準として立ち上がりつつある。Skills や Subagents のような高度な機構を採用しているリポジトリは少なく、Skills も大半は実行可能なスクリプトではなく静的な指示に依存する。ツールごとに異なる設定慣行が形成されつつあり、Claude Code の利用者が最も広い範囲の機構を使う。この母集団の9割はそもそも設定を置いておらず、置いている1割弱が触っているレバーも、ツールアーキテクチャではなくほぼコンテキストファイルである。https://arxiv.org/abs/2602.14690 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  4. Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, Heng Ji, “Executable Code Actions Elicit Better LLM Agents”（arXiv:2402.01030, 2024年2月1日投稿／ICML 2024）。LLMエージェントが通常あらかじめ定めた形式の JSON かテキストで行動を出力するよう促されることを、行動空間が制約される（あらかじめ定義された道具の範囲に限られる）ことと柔軟性が制限される（複数の道具を組み合わせられない）ことによる限界として指摘する。提案する CodeAct は実行可能な Python によって行動を単一の行動空間に統合し、Python インタプリタと組み合わせて新しい観測に応じ直前の行動を動的に修正できる。17個のLLMを API-Bank と新規ベンチマーク M3ToolEval で解析し、広く使われている代替手法（Text や JSON）を最大20%高い成功率で上回ったと報告する。M3ToolEval は 82 human-curated instances, spanning tasks including web browsing, finance, travel itinerary planning, science, and information processing で、コーディング課題ではなく、デモを与えないゼロショット・最大10ターンの設定で測る。この「最大20%」の出所は M3ToolEval（82 instances）側の一文で、the best model gpt-4-1106-preview achieves a 20.7% absolute improvement compared to the next best action format (text)——1モデルの、テキスト形式に対する絶対20.7ポイント差（Table 3 で 74.4 対 53.7）であり、相対2割ではない。M3ToolEval 側も一様ではなく、Table 3 の Frequency of Best-performing Format は CodeAct 12／JSON 5／Text 4（同点があるため合計は17を超える）で、claude-instant-1 は CodeAct 20.7 に対し JSON 31.7 と11.0ポイント負けている。著者らは同じ段落で there is still a significant gap in terms of absolute CodeAct performance between open- and closed-source LLMs as the best open-source model achieving 13.4% while the best closed-source model gpt-4-1106-preview 74.4% とも書く。API-Bank 側の指標は成功率ではなく Correctness（単発のAPI呼び出しが正解出力と一致するか）で、Table 2 の Frequency of Best-Performing Format は CodeAct 8／JSON 5／Text 4、閉じたモデルに限れば CodeAct 4／JSON 5 と JSON が上回る。上記のツールアーキテクチャ実験が測った Python 形式インタフェースの元になった、独立の先行研究にあたる（著者集合は両者で重ならない）。https://arxiv.org/abs/2402.01030 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

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