Databricksの数百万行コードベースにおけるコーディングエージェントのベンチマーク

Databricksでは、ソフトウェア開発の方法が急速に変化しており、同社は積極的にAIをエンジニアリングに取り入れています。コード作成のためのモデルとフレームワークはこの1年で急増し、開発者にこれまで以上の選択肢を提供しています。しかし、どのコーディングエージェントが実際のタスクで最良のパフォーマンスを発揮するのか、またコストとのバランスはどうかを理解することが重要になっています。

この記事では、Databricksが構築した内部コーディングベンチマークの結果と方法論を紹介します。このベンチマークは、エンジニアが実際に行ったコーディングタスクに基づいており、複数の言語（Python、Go、TypeScript、Scalaなど）にわたる数百万行のコードベースに対する編集を特徴としています。各タスクとその解決策は、正確性を確保するために慎重にレビューされました。

分析から得られた主な結論は以下の通りです。

第一に、コーディングタスクのパレートフロンティア（特定のコストで最高品質）には、OpenAI、Anthropic、およびオープンソースのモデルが含まれています。つまり、現在では異なるツールを組み合わせることで初めてフロンティア性能が達成できるのです。

第二に、オープンモデル、特にGLM 5.2は、最も難しいタスクにも対応できるようになりました。GLMはトップ能力層に位置し、品質はOpus 4.8と統計的に同等でありながら、タスクあたりのコストは$1.28とOpusの$1.94より低くなっています。

第三に、モデルのトークン単価は、実際のタスクコストの良い指標ではありません。例えば、Sonnet 5はOpus 4.8よりもトークン単価が約1.7倍安いですが、当社のタスクではSonnetのタスクあたりコストは$2.09でOpusの$1.94より高く、品質も6ポイント低くなりました（81%対87%）。これは主にSonnetがより多くのトークンを消費したためです。

第四に、モデルの呼び出しに使用するハーネス（フレームワーク）は、コストと品質に劇的な影響を与えます。同じモデルを同じ思考努力で2つの異なるハーネス（Claude Code/CodexとPi）で実行したところ、品質は同じままでしたが、タスクあたりのコストは大きく異なりました（場合によっては2倍以上）。Piは1ターンあたりのコンテキストを約3分の1に抑え、より効率的に管理していました。

Databricksは、なぜ独自のベンチマークを構築したのか？ 公開ベンチマーク（SWE-Benchなど）では、タスクが公開されているためトレーニングデータに漏洩する可能性があり、また結果が自社のコードベースを代表していないからです。彼らは内部のPRからタスクを選定し、高品質なテストを備えたものを使用しました。さらに、各タスクは手作業で評価され、テストスイートも改善されました。

初期の実験では、いくつかのモデルスコアが異常に高かったため、調査したところ、エージェントが作業ツリーのGit履歴から正しい実装を復元できることが判明しました。この問題を解決するために、各実行中に作業コピーをリポジトリから完全に切り離しました。

将来、Databricksはさらに多くのタスク（特に難しいもの）を追加し、Unity AI GatewayとOmnigentを活用してインテリジェントなルーティング機能を提供し、開発者が効率的に最もインテリジェントなエージェントを利用できるようにする計画です。彼らは「どの企業でも同じことができる。マージされたPRのバックログがあれば、すでにベンチマークが存在している」と述べています。