数百万行のコードベースでコーディングエージェントを試したら、現実がベンチマークを裏切った

「SWE-benchで50%超えたので導入を検討しています」という話を社内で聞くたびに、それ、うちのコードで動くの？と思ってきた。

Databricksが自社の数百万行コードベースでコーディングエージェントをベンチマークした研究がその問いに一つの答えを出した。結果は、思っていたよりずっと厳しいものだった。

実験の設計が正直だった

Databricksの検証でまず目を引くのは、評価環境の選び方だ。Apache Spark、Delta Lake、MLflow、Unity Catalogといった自社の主要プロダクトのリポジトリ群、総コード行数は数百万行規模のモノレポに近い構成で、実際のGitHubイシューとプルリクエストから抽出したタスクを使って評価した。

SWE-benchが使うのは「教科書的な」オープンソースリポジトリが中心で、コードの密度も依存関係の複雑さも現実の大規模プロダクトとはかなり違う。Databricksの実験はそこを正直に直した。

評価対象のエージェントはClaude 3.5 Sonnet/Opus、GPT-4oなど複数のモデルを含む構成で、タスク数は1,000件を超える規模。通過率（パッチ適用後にテストがパスするかどうか）で一律に評価した。

数字を見ると壁がある

トップエージェントでもパス率は15〜30%台にとどまった。SWE-bench公式リーダーボードの同じエージェントのスコアが40〜55%に達しているのと比較すると、実コードベースでは大幅な性能低下が起きている。

特に差が出たのは以下のケースだ。

ファイルをまたぐ依存関係が深い修正は、エージェントが局所的にパッチを当てても、別モジュールとの整合性が取れずテストが落ちる。コードベース固有の内部ユーティリティを使うパターンでは、汎用コードで書き直してしまい、既存の抽象化層と噛み合わない。テストスイートが充実していて「動くがテストが落ちる」を弾ける環境では、逆説的に、テストが少ないコードベースよりパス率が見かけ上低くなる。

成功したケースに共通するのは「影響範囲が1〜2ファイルに収まり、修正パターンが定型的なもの」だった。型エラーの修正、小さなバグ修正、既存関数のロジック修正あたりはエージェントが安定して対処できた。

コンテキストの壁は思ったより高い

数百万行のコードベースでエージェントが詰まる最大の理由はコンテキストウィンドウではなく、「どこを読めば答えにたどり着けるか」のナビゲーション能力だ。

人間のエンジニアなら「この機能はあそこのモジュールに集まっている」という暗黙知でコードを絞り込める。エージェントはその絞り込みを検索とgrep的な探索で代替しようとするが、依存グラフが深いコードベースでは「正しいファイルを見つける前に諦める」パターンが多発した。

Databricksの実験ではリポジトリ全体を渡すのではなく、タスクに関連するファイルをある程度事前に絞って渡す設定も試されたが、それでもエージェントが見落としたファイルが原因で失敗するケースが続いた。「選択するAI」と「コーディングするAI」を分けるアーキテクチャの必要性を示唆している。

現場から見ると使い所が見えてくる

この結果を見て「コーディングエージェントはまだ使えない」と読むのは早計だと思う。むしろ「どこに投入するか」の解像度が上がる。

パス率が高かった類のタスク、つまり影響範囲が狭くパターンが定型的な修正は、コードレビューの手直し、型アノテーション追加、既知パターンのリファクタリングとかなり重なる。これらは人間のエンジニアがやっても単純作業で、かつミスが出やすい領域でもある。

一方でアーキテクチャレベルの判断、モジュール間の設計変更、新機能の方向性を決める段階はまだ人間がいないと成立しない。エージェントが「実装」を担い、人間が「判断」を担うという分業は、今回の数字からも妥当に見える。

自分の仕事に引き当てると、分析パイプラインの特定ステップのバグ修正やSQL変換の定型作業はエージェントに任せるのが合理的で、モデルの評価指標を何にするかという上流の決定はまだ人間のターンだ。

問われているのはベンチマーク選び

この研究が示す一番の教訓はエージェントの限界よりもベンチマークの選び方だと思う。SWE-benchのスコアで製品評価を語ることへの警戒感は以前からあったが、実コードベースで計測した数字が出ると説得力が違う。

自社のコードに近いベンチマーク環境を作るコストは決して小さくないが、それをやったDatabricksの姿勢は評価できる。少なくとも「自社に導入前に自社コードで試す」という工程を省略することへの免罪符はなくなった。

コーディングエージェントの評価を任されている人は、ベンダーのリーダーボードと自社コードでの実測の間にある「ギャップの大きさを測る」ことから始めるのが誠実だと思う。

まとめ

• Databricksが数百万行コードベースで複数のコーディングエージェントを評価
• トップエージェントのパス率は15〜30%台で、SWE-bench公式スコアから大幅に低下
• 失敗の主因はコンテキストウィンドウではなく、大規模コードベースのナビゲーション能力
• 影響範囲が局所的な定型的修正タスクでは実用的な水準の結果が出た
• 「どのタスクにエージェントを使うか」の判断精度を上げることが今の優先事項

元記事: https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase