TL;DR

バグ修正エージェントを自作して、「コードを全部 LLM に貼って 1 回で直させる」方法と比べました（DeepSeek、計 271 回実行）。

「エージェントの方が常に良い」ではなく、使い分けの基準 が数字で見えたのが一番の収穫です。

なぜこの実験をしたか

最初に汎用エージェントを自作したとき、「これ、1 回プロンプトを投げるだけでもできるのでは？」という疑問が出ました。エージェントは遅くて高いので、本当に必要な場面を知りたかったのが動機です。

サンドボックス内で動く 5 つのツールを持たせました。ファイル一覧、ファイル読み込み、検索、編集、テスト実行です。

編集ツール edit_file は 行番号ではなく「一意な文字列の置換」 にしています。

「テストを通す」ことが目標だと、モデルが テスト側を書き換えて 通そうとする可能性があります。2 段の防御を入れました。

271 回の実行で、テストを改ざんしようとしたケースは 0 回でした。ただ、難しい問題ほど起きやすくなるので防御は残しています。

自作の 23 問です。単一ファイル、ファイルをまたぐもの、誤解を招くエラーメッセージ、3 段の連鎖バグ（前のバグのエラーが次のバグを隠す）などを含みます。全問について「修正前はテストが失敗し、参照解で直すと通る」ことを確認済みです。

方式	内容
1 回のプロンプト	全コードとバグ報告を貼り、修正後のコードを 1 回で出させる
エージェント（テスト実行なし）	読む・探す・編集はできるが、テストは走らせられない
エージェント（フル）	テスト実行も可能

方式	成功率	平均トークン	平均時間
1 回のプロンプト	98%	915	1.6 s
エージェント（テストなし）	98%	6,989	4.6 s
エージェント（フル）	100%	8,617	5.8 s

ほぼ差がありません。エージェントはトークンが約 9 倍です。

予想と違いました。 評価セットが簡単すぎて飽和していると考え、仮説を 2 つ立てて追加実験をしました。

意外だったのは、テストを走らせられないエージェントも 100% だったことです。強みはテストのフィードバックではなく、ファイルを 1 つずつ読んで焦点を絞る進め方 にありそうです。

方式	成功率	平均トークン
1 回のプロンプト	91%	33,095
エージェント（フル）	100%	8,740

1 回のプロンプトは全コードを毎回渡すしかないので、トークンが 3.8 倍になります。エージェントは必要なファイルだけ読むので、ここで逆転します。

実験 1〜3 をまとめて、問題に含まれるバグの数で分けました。

問題の種類	1 回のプロンプト	エージェント（テストなし）	エージェント（フル）
バグ 1 つ	72/72（100%）	54/54（100%）	72/72（100%）
バグ複数	21/26（81%）	20/21（95%）	26/26（100%）

1 回のプロンプトの失敗は、ほぼすべて「バグが複数ある問題」 で起きていました。1 つ直して満足し、残りを見落とすパターンです。

実験 3 の途中で API の残高がなくなり、以降のリクエストがすべて 402 エラーになりました。評価スクリプトはこれを「修正失敗」として数え、一見まともなレポート（1 回のプロンプトの成功率 22%）を出力していました。

エージェントのトークン数が 0、ステップ数が異常に少ないことから気づきました。今は 401 / 402 を致命的エラーとして扱い、発生したら評価全体を即中止して結果を保存しないようにしています。

評価基盤は「被験者が失敗した」と「評価基盤自体が壊れた」を区別できないといけない。

問題は 23 問だけで、統計的な有意性は限られます
バグは自作なので、実際のバグより単純です
モデルは DeepSeek のみです
エージェントは平均してテストを 1 回程度しか走らせておらず、複数回の試行錯誤が効く問題はまだ含まれていません。次は SWE-bench の実プロジェクトのバグで試したいです

「とりあえずエージェント」ではなく、タスクの形で選ぶのが良さそうです。

LLM / AI エージェントの PoC、評価設計のご相談も受け付けています。ポートフォリオ：https://rayagent.dev/ja/