IDE-Bench: Evaluating Large Language Models as IDE Agents on Real-World Software Engineering Tasks
IDE-Benchは、構造化されたIDEネイティブなツールインターフェースを通じて、AI IDEエージェントの能力を現実世界のマルチ言語ソフトウェアエンジニアリングタスクにおいて評価するために、未公開の8つのリポジトリにわたる80のタスクを備えた包括的なDocker化された評価フレームワークを導入します。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
あなたは、新しいジュニアデベロッパーをソフトウェアプロジェクトに採用しようとしていると想像してください。あなたは、その人が実際に仕事をこなせるかどうかを知りたいと考えています。つまり、バグを見つけ、新機能を追加し、他の部分を壊すことなく壊れたコードを修正できるかどうかです。
長い間、私たちはAIコーディングアシスタントを、空白の部屋で一つのパズルを解かせることでテストしてきました。しかし、実際のソフトウェア開発は、部屋の中のパズルではありません。それは、道具や設計図、そして他の作業員で満たされた、賑やかでハイテクなワークショップ（作業場）の中で働くことに似ています。
IDE-Benchは、AIモデルが現実世界でどのように使用されるかを正確にテストするために設計された、この新しい「ワークショップ」です。以下に、論文の発見事項を簡単な比喩を用いて解説します。
1. 新しいテスト：「紙と鉛筆」から「フル装備のワークショップ」へ
従来のテスト（SWE-Benchなど）は、学生に紙の上で数学の問題を与え、答えを書かせるようなものでした。彼らは計算機を使ったり公式を調べたりすることはできず、記憶に基づいて答えを推測するしかありませんでした。
IDE-Benchは異なります。これはAIに、CursorやWindsurfのようなアプリで使用されているものと同じツール一式を備えたDocker化されたワークショップ（安全で隔離されたデジタルルーム）を提供します。
- ツール: AIはコードを検索し、ファイルを読み、行を編集し、テストを実行し、さらにはデータベースをチェックすることさえできます。
- ゴール: AIは本物のエンジニアのように振る舞わなければなりません。単に推測するのではなく、探索し、変更を加え、それが機能するかを確認し、もし失敗したらミスを修正しなければなりません。
2. 「秘伝のレシピ」の料理本
AIがインターネット上の答えを単に暗記していないことを確認するために、研究者たちは8つの秘密のコードベースにわたる80の全く新しいタスクを作成しました。
- 比喩: 料理コンテストを想像してください。審査員が、これまで一度も見たことがない8つの新しいレシピを作成します。コンテスタント（AIモデル）はそれらを調理しなければなりません。これらのレシピはオンラインに公開されていないため、AIは学習データから解決策を探して「カンニング」することができません。
- 多様性: レシレシピは異なる「料理（プログラミング言語）」をカバーしています：C/C++（システムプログラミング）、Java（エンタープライズアプリ）、MERN（モダンなウェブアプリ）。
3. 結果：誰がマスターシェフか？
研究者たちは15種類の異なるAIモデルをテストしました。判明したことは以下の通りです。
- トップ層（マスターシェフ）: GPT-5.2を筆頭とするいくつかのモデルは、タスクの約**95%**を解決しました。彼らは、レシピを読み、適切な道具を掴み、最初の一手で完璧に料理を作り上げるシェフのような存在でした。
- 中間層（有能な料理人）: Claude SonnetやClaude Haikuのようなモデルは、タスクの約**85〜88%**を解決しました。彼らは非常に優秀ですが、完璧にするために二度目の試行が必要になる場合があります。
- 下位層（初心者）: 多くのオープンソースモデルは苦戦し、50%未満のタスクしか解決できませんでした。彼らはワークショップの中で迷子になったり、修正しようとしてコードを壊してしまったりしました。
4. 「あと一歩」の問題
最も興味深い発見の一つは、バイナリスコア（合格/不合格）は多くのニュアンスを隠してしまうということです。
- 比喩: ある学生がテストを受け、12問中11問正解したとします。厳格な採点システムでは、100%に達していないため「不合格」となります。
- 現実: IDE-Benchにおいて、多くのモデルはコードの「核」となる部分は正しかったのですが、カンマの欠落やわずかなフォーマットの誤りといった、極めて小さな詳細部分で失敗していました。論文ではこれらを**「惜しいミス（near misses）」**と呼んでいます。
- 教訓: モデルは解決策の90%に到達しているかもしれませんが、細かい部分を見逃すと、テストでは完全な失敗と見なされます。これは、現実世界の利用においては、コードをすべて捨ててやり直すのではなく、人間が小さなフォーマットエラーを修正するだけで済む可能性があることを示唆しています。
5. 効率性 vs 徹底さ
論文では、AIがタスクを解決するためにどれほど「コスト（費用）」がかかったか（「トークン」、つまり思考の言葉数で測定）についても調査しました。
- 速くて安い: 一部のモデル（Grok 4.1 Fastなど）は非常に効率的でした。彼らは素早くタスクを解決し、より少ないリソースを使用しましたが、失敗する頻度も高かったです。
- 遅くて徹底している: 他のモデル（Claude Opusなど）は、非常に長い時間をかけ、多くのファイルを読み、深く思考しました。彼らは成功する可能性が高いですが、時間と計算能力の面で多くのコストがかかります。
- 教訓: 「最高のモデル」というものは一つではありません。スピードと低コストを求めるなら、あるタイプのモデルを選び、高い信頼性が必要でコストを厭わないなら、別のモデルを選ぶことになります。
6. 失敗のパターン
研究者たちは、AIモデルがどのように失敗したかを分類しました。これは、自動車のメカニックがなぜ車が始動しないのかを診断するようなものです。
- 早すぎる編集（失敗の63%）: AIは設計図を理解する前にコードを変更し始めました。これは、ボンネットを開けて中を確認することなく、エンジンを修理しようとするようなものです。
- スラッシング（Thrashing）（28%）: AIは同じファイルを何度も書き換え、自分の作業を元に戻してしまうという、行った作業を何度もやり直すような状態に陥りました。まるで、進むべき道が決まらずに、同じ場所をぐるぐる回っている人のようです。
- コンテキストの喪失（Context Loss）（27%）: AIはタスクの途中で、自分が何をすべきだったのかを忘れてしまいました。これは、ケーキを作り始めたのに、ピザを作るはずだったことを忘れてしまうシェフのようなものです。
まとめ
IDE-Benchは、最高のAIモデルが、複雑でツールが豊富な環境において、本物のソフトウェアエンジニアのように振る舞う能力を持っていることを証明しています。しかし、同時に以下のことも示しています。
- 専門化が重要: あるモデルはウェブアプリには強いが、低レベルのシステムコードには弱いといった違いがあります。
- 完璧は難しい: 99%まで到達することは一般的ですが、最後の1%（細かなディテール）こそが、ほとんどのモデルが躓く場所です。
- 戦略が重要: 最善のアプローチは、まず「高速な」モデルを使用し、もし失敗した場合には、「徹底的な」モデルに切り替えて仕事を完了させることかもしれません。
論文は、AIを判断するために単一の「スコア」を見るのをやめ、彼らが「どのように働き」、「何に長けており」、「完了させるためにどれだけのコストがかかるのか」を見るべきであると結論付けています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。