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

Databricksでは、エンジニアリングへのAI導入を積極的に進める中で、ソフトウェア開発の手法が急速に変化しています。コード作成のためのモデルやハーネス（実行環境）の状況はこの1年で急速に拡大し、開発者の選択肢はかつてないほど増えています。選択肢が増えるにつれ、実際のコーディングタスクにおいてどのコーディングエージェントが最高のパフォーマンスを発揮するのか、またタスクのパフォーマンスが価格によってどのように変化するのかを理解することがますます重要になっています。

本記事では、Databricksのコードベースでエンジニアが実際に行ったコーディングタスクに基づいてツールを評価するために、Databricks社内で構築したコーディングベンチマークの結果と手法を紹介します。タスクには、多くの一般的な言語（Python、Go、TypeScript、Scalaなど）をカバーする数百万行規模のコードベースに対する編集が含まれており、正確性を期すためにタスクとソリューションの両方が慎重にレビューされました。これは網羅的なものを目指したわけではありませんが、この取り組みによって、コーディングエージェントを活用したエンジニアリングチームの効率性がすでに大幅に向上するという知見が得られました。以下は、ベンチマーク全体におけるモデルとハーネスのスコアを示したものです。

図1：ベンチマークにおけるコストとパフォーマンスの比較

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

1. コーディングタスクにおけるパレートフロンティア（すなわち、特定のコストに対して最高の品質）には、OpenAI、Anthropic、およびオープンソースのモデルが含まれます。これは、現在、最先端のパフォーマンスを提供できるのは複数のツールの組み合わせのみであることを意味します。
2. オープンモデル、特にGLM 5.2は、現在、最高難易度のタスクにも対応できるようになっています。
3. モデルのトークン単価は、エンドツーエンドのタスクで発生する実際のコストの指標としては不十分です。大規模なモデルの方がトークン効率がはるかに高く、全体のコストが低くなる場合があります。
4. モデルを呼び出すハーネスは、コストと品質に劇的な影響を与えます。多くの場合、Piのようなシンプルなハーネスが、当社のワークロードで最高のパフォーマンスを発揮しました。

それぞれについて、もう少し詳しく見ていきましょう。

モデルはおおよその「能力ティア」に分類される

具体的な結果が数ポイントずれていても、実際のタスクでは相殺されることがよくあります。私たちは、さまざまなタスクにどのモデルを使用すべきかを判断するのに役立つ、テーマ別のパターンに焦点を当てました。実際、結果からは、モデルとハーネスが3つの能力ティアに明確に分類されることが示されました。

図2：全体的な結果から3つの明確な能力ティアが浮かび上がり、各グループでどのモデルが効果的であるかにはニュアンスの違いがありました

パフォーマンスの上限では、最もインテリジェントなモデルがあらゆる問題の解決に非常に効果的ですが、非常に高価です。中位および下位のインテリジェントモデルも一般的なタスクには依然として非常に効果的であり、多くの場合、大幅に安価です。

日々、エンジニアは複雑さが大きく異なるさまざまな業務を行っています。フラグの切り替えや設定の更新といった一般的な運用タスクには極めてインテリジェントなモデルは必要ありませんが、より深い設計の探求には必要です。しかし、これまでは、デフォルトのモデルが常に最も 高価なものでした。この分析に基づき、HaikuやGPT 5.4 Miniクラスのモデルにより多くの作業を割り当てるべきだと判断しました。

コーディングにおけるオープンモデルの台頭

GLM 5.2については多くの期待が寄せられていましたが、当社の結果からも、GLMが多くの開発者にとって日常的に使用するモデル（デイリードライバー）になり得ることが示されました。品質面ではOpus 4.8と統計的に同等でありながら、トップの能力ティアに位置し、Opusのタスクあたり1.94ドルに対して1.28ドルというコストパフォーマンスを実現しました。

GLMの品質スコアは、日常の開発でGLMを試験導入している社内開発者からの定性的なフィードバックと一致しています。日常的なコーディングタスクにおけるその優れたパフォーマンスから、私たちは GLMを最高のパフォーマンスで提供することに注力してきました。そして、これらをコーディングのデイリードライバーとしてデプロイし始める時期が来ていることが、データによって示されています。

タスクあたりの価格 vs トークンあたりの価格

開発者は、コーディングタスクを完了する際にモデルがどれほど高価になるかを判断するために、トークンコストを大まかに見積もることがよくあります。しかし、モデル間での推論効率のばらつきにより、トークンコストはタスク全体のコストの指標としては不十分であることがわかりました。これは、タスクの形状や複雑さが文脈によって異なる可能性があるため、タスクレベルのベンチマークが必要であることを強調しています。

一例として、Sonnet 5はOpus 4.8よりもトークンあたり約1.7倍安価ですが、当社のタスクでは、Sonnetのコストがタスクあたり2.09ドルであったのに対し、Opusは1.94ドルでした。一方で、タスク完了率は6ポイント低くなりました（81%対87%）。これは主に、Sonnet 5が結果に達するまでにより長く動作し、より多く読み込んだため、1.9倍多くのトークンを消費したことが原因です。

ハーネスが効率性に与える大きな影響

同じ思考プロセスを持つ同じモデルを2つの異なるハーネス（Claude Code/Codex対Pi）で実行したところ、品質は同じままであるにもかかわらず、タスクあたりのコストに大きな差（場合によっては2倍以上）が生じることが観察されました。主な違いは、各ターンで各ハーネスがモデルに提供するコンテキストの量にありました。

Piが送信した1ターンあたりのコンテキストは、約3分の1でした。コンテキストをより適切に管理し、ワーキングセットをよりコンパクトに保ち、より少ない実行回数でタスクを完了しました。

ここでの教訓は、特定のハーネスが常に安価であるとか、ネイティブのハーネスが劣っているということではありません。そうではなく、モデルの選択はパズルの一片にすぎないということです。この柔軟性を確立するために、私たちはモデルとハーネスのシームレスな切り替えを可能にする Omnigentに投資しました。

なぜ独自のベンチマークを構築するのか？

SWE-BenchやTerminalBenchのような公開ベンチマークは有用ですが、私たちが抱いていた疑問に答えることはできません。これにはいくつかの理由があります。

• タスクが公開されているため、時間の経過とともにソリューションがトレーニングデータにリークしてしまいます。
• 10以上の言語に及び、Scala、Go、Rust、Java、Python、Bazel、Protobufなどで書かれた多くのサービスで構成される当社のコードベースにおいて、結果が代表的なものではないことがわかりました。

独自のPR（プルリクエスト）に基づいてベンチマークを構築することで、最適化を導入しても開発者の妨げにならないという高い確信を持って、これらの決定を下すことができます。

ベンチマークの構築方法

私たちは、すべてのコーディングインタラクションのログをキャプチャするために Unity AI Gatewayを使用しました。これにより、エンジニアがコーディングエージェントを使用して取り組むタスクの複雑さを分析することができました。タスクの複雑さには大きな多様性があり、約4分の1が低複雑度の作業、約60%が中複雑度の作業としてタグ付けされました。

しかし、高価なモデルがエンジニアのデフォルトモデルとして使用されていたため、効率性を向上させる大きな機会があることは明らかでした。

タスクの構築

当社のエンジニアは1日に数千件のコード変更をマージしているため、構築のベースとなる優れたデータセットがすでに存在しています。優れたプルリクエストは、開発者による反復を示すコミット、人間によるレビュー、そしてコード変更が意図通りであることを検証するのに役立つテストを含む、豊かな成果物です。しかし、それらから高品質なベンチマークを構築するには、いくつかの品質チェックとフィルターが必要でした。

• 新しさ（Recency）： 現在使用されているフレームワーク、パターン、規約など、今日の開発手法をタスクに反映させるため、最近の履歴から抽出しています。
• 人間による作成： Botのコミット、サービスアカウント、完全にAIによって生成された変更、自動生成された変更は除外されました。
• 関連する高品質なテストスイート： コード変更を検証するための高品質なテストが含まれているPRをフィルタリングしました。
• 自己完結型： 変更が少数のモジュールに限定されているもの。
• 代表的なタスク： フルスタックにわたるタスクの分布からPRを選択しました：Scalaバックエンドサービス、Rustシステムコード、ReactおよびTypeScriptフロントエンド、protobufおよびgRPCコントラクト、Bazel設定。

候補となるPRが揃った後、以下の方法で明確に定義されたタスクを構築することに注力しました：

1. 意図を汲み取り、プロンプトとして要約する。PRを読んでそれが実際に何を目的としているかを理解し、期待する成果を記述します。通常、これは問題や目標を述べ、制約を挙げ、解決策の記述を削除することで、PRの説明を書き直すことを意味します。例えば、バグ修正がなぜ正しいのかという説明を削除することが重要です。そうしないとタスクが簡単になりすぎてしまうためです。
2. 関連するテストを切り離す。テスト以外のファイルはモデルが独自に再現しなければならない変更であるため、テストファイルは脇に置いておき、コンパイルできることを確認しました。当社のビルドシステムは、元のPRで変更されたファイルにどのテストが依存しているかをすでに判断できるため、それらのテストターゲットをすべて実行しました。

この作業から得られたのが、ベンチマークにおける単一のタスクです。以下は簡略化した例です：

スクリプトとAIを使用して候補タスクを生成しましたが、各サンプルを手作業で評価しました。場合によっては、代替の実装を可能にしたり、より厳密にしたりするために、元のPRのテストを書き直す必要があることがわかり、これらを手動で（AIを使わずに）行いました。同様に、タスクの説明を改善して明確に定義する必要があるケースも見つかりました。

図3：テストスイートのビフォー・アフター。以前のテストは完全な文字列一致の検証に依存していたため、モデルがタスクを解決しようとしたときにいくつかの失敗が発生しました。これは非決定的な出力をテストする優れた方法ではなかったため、代わりに動作を評価するように書き直されました。

Databricksのエンジニアが利用できるすべての一般的なツールを備えた、標準的なそのままで使えるセットアップを使用して、コーディングエージェントのハーネスとモデルをインスタンス化しました。

エージェントがタスクを完了したと明示的に述べた時点で、そのコードのチェックポイントを作成し、除外されていたテストを適用し、テストを評価して、そのタスクがそのモデルとハーネスの組み合わせにおいて「合格」であるかどうかを判断しました。正確性を評価するためにLLMの判定員は使用しませんでした。なぜなら、そうすると「正しいこと」よりも「正しそうに聞こえること」が評価されてしまうことがわかったためです。

追加のガードレール

初期の実験では、一部のモデルのスコアが良すぎて信じられないほどだったため、トレースを手動で検査して、これらのエージェントの軌跡で何が起こったのかを理解しました。わかったことは、元のセットアップのせいで、ワークツリーのGit履歴から「正しい」実装がまだ復元可能だったということです！すべてのタスクはマージされたコミットから発生していたため、シェルを持つエージェントがGit履歴を遡ってそれを見つけるのを防ぐものは何もありませんでした。この問題を解決するために、Git履歴を封印しました。各実行の間、ワーキングコピーをリポジトリから完全に切り離しました。

次のステップ

私たちはシンプルな問いから始めました。コーディングエージェントをより効率的に使用できるか？答えは間違いなく「イエス」です。そして、データ駆動型のアプローチを取ることができるため、適切なモデルを自動的に選択し、効率を追跡する機能の構築を開始できます。

どの企業でも同じことができます。マージされたPRのバックログを持つチームは、どのモデルもトレーニングされていない、チームが作成したテストによって評価されるベンチマークをすでに持っていることになります。私たちは積極的にタスク（特に難易度の高いもの）を追加しており、すべての新しいエージェントやハーネスをこれに通して、選択に対する自信を深める計画です。

Databricksでは、ベンダーロックインだけでなく、時間の経過とともにチームの柔軟性を失わせるような前提条件に対しても、常に警戒してきました。その同じ本能が、オープンなフォーマットと標準への早期の投資を形作り、現在のAIへのアプローチにも影響を与えています。出荷するコードで実際に機能するものを測定し、一貫したガードレールのもとでエンジニアがモデルやハーネスを自由に移行できるようにし、AIを効果的に使用するための最適化を行います。

次回のブログでは、開発者が効率的に最もインテリジェントなエージェントを使用できるように、Unity AI GatewayやOmnigentのインテリジェントルーティング機能をどのように活用しているかについて詳しく説明します。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事