Databricksが数百万行のモノレポで測ったコーディングエージェントの実力と選び方

こんにちは、カイです。

プロダクト改善にAIをどう組み込むかを、AimanaVo（エーアイマナボ）で連載しています。

SWE-benchで87%取ってます、と言われても、うちのモノレポで動くかは別問題ですよね。

比較記事を何本読んでも、自社導入の判断根拠までは埋まらない。

このモヤモヤ、けっこう多くのチームで同じように積み上がっているんですよ。

その空白に、Databricksが2026年7月に出した数百万行モノレポの実測データが正面から答えを出していて、コーディングエージェント選定の議論をひっくり返す内容でした。

Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase

Databricks shares results from its internal coding benchmark, evaluating coding agents on a multi-million line codebase to optimize engineering cost and performance.

www.databricks.com

Toy benchmarkでは答えられなかった問い

公開ベンチマークで答えられなかった問いが3つあります。

1つ目は学習汚染のリスク。

SWE-benchやTerminalBenchのタスクは公開されている以上、モデルが訓練データとして吸い込んでいる可能性が消せません。

「解けた」のか「覚えていた」のかの区別がつかない。

2つ目は言語の偏り。

公開ベンチマークはPythonが中心で、Databricksのように10言語以上（Go、TypeScript、Scala、Rust、Java、Bazel、Protobuf、gRPC等）を抱えるモノレポでは代表性がありません。

3つ目は逆に、自社の内部PRなら「モデルが学習していないデータ」として信頼できるという反転の発想。

マージ済みでテストが通っているPRは、それ自体がベンチマークの正解データになります。

「うちのコードベースで動くのか」は、公開ベンチマークを何本並べても答えが出ない問いなんですよ。

数百万行・10言語以上のモノレポでの実測が、Toy repoベンチとは別次元の情報になるのはそこです。

数百万行モノレポで見えた実測データ

数字を並べると直感に反するものが出てきます。

Databricksが比較したモデル群のうち、上位ティア（完了率87%）はタスクあたり約$1.94。

中位ティア（完了率81%）はタスクあたり約$2.09。

まず気づくのは、完了率が高い方がコストが安いという逆転現象です。

難しいタスクを一発で通すモデルはリトライが減るぶんトータルコストが下がる。

「高性能モデルは高コスト」という直感が成り立たないケースがあるんですよね。

さらに意外なのが、あるオープンソースモデルが上位ティアと統計的に同等の完了率を出しつつ、タスクあたり約$1.28まで下がっていた点です。

上位ティア（$1.94）より約34%安い。

「クローズドモデルの独壇場」という前提が、数字で崩れた瞬間です。

タスク複雑度の分布は、低25%・中60%・高15%（残り）という配分になっています。

日常業務の85%は低〜中複雑度で、上位モデルをフル投入する必要がない領域。

Databricksが提示した「上位・中位・下位の3ティア戦略」はここに紐づきます。

• 上位ティア: 高複雑度タスク（新機能実装、複雑なリファクタ）に投入
• 中位ティア: 中複雑度タスク（バグ修正、テスト追加）で費用対効果を取る
• 下位ティア: フラグ変更・設定更新・単純置換を回す

月に1000タスク動かすチームなら、$1.94と$1.28の差は月$660、年で約8,000ドル（120万円弱）。

モデル1つの選択で、この規模の予算差が生まれます。

公開ベンチマークは「一次スクリーニング」に使う

ここまで読むと「公開ベンチマークは意味ない」と思われそうですが、そうではないんですよ。

市場に出ているエージェント候補を最初にふるいにかけるフェーズでは、共通のベンチマーク数値が意思決定を速くします。

ここを自社ベンチマークだけでやろうとすると、初手のコストが跳ね上がる。

自社ベンチマークは最終判断の場面で効いてきます。

「候補が2〜3社に絞れた」段階で、自社コードベースで動くかの検証をやる。

Databricksの言葉を借りると、"Any team with a backlog of merged PRs is sitting on a benchmark already"。

マージ済みPRを積んできたチームは、既にベンチマークデータを持っている状態です。

公開ベンチマークと自社ベンチマークは対立軸ではなく、二段構えの評価パイプライン。

この整理が入ると、社内の議論の解像度が上がります。

同じモデルでも2倍変わる、ハーネスの影響

ここが、この記事で一番伝えたいポイントです。

Databricksが自社開発したPiという軽量ハーネスは、1ターンあたりに送信するコンテキストがClaude CodeやCodex比で約1/3。

そして、同じモデルを使っていても、ハーネスを変えるとコストが2倍以上変わるケースがあると報告されています。

注目してほしいのは「同じモデルで」という点です。

完了率（品質）はハーネス間でほぼ一定なのに、コスト構造だけが大きくブレる。

「どのモデルを使うか」と「どのハーネスで走らせるか」は独立した意思決定で、後者が抜けているとコストが倍増します。

多くのチームで「モデル選定会議」はやってるのに「ハーネス選定会議」はやってないんですよね。

ハーネスは"モデルの上に乗る実行環境"で、コンテキスト圧縮・ツール呼び出し・ループ制御を担う層。

この層の設計が月次のAI予算を決めます。

Databricksはさらに、モデルとハーネスをシームレスにスワップ可能にするOmnigentというメタハーネス基盤を作っています。

自社でここまで作れるチームは少数派でも、「そういう階層がある」と知っておくと選定の目線が上がります。

自社コードベースで測るための3つの評価軸

軸1: タスク複雑度の分布把握

自社の開発タスクを低・中・高で棚卸しします。

Databricksの25/60/15を参考値に、直近3ヶ月のPRを分類してみる。

「うちは高複雑度が40%ある」となれば、上位ティアの割合を厚くする必要が出てきます。

軸2: モデル選択（ティア混在の設計）

タスク複雑度に応じて上位・中位・下位ティアを混在させます。

単純作業に高性能モデルを投入しても差は出ませんし、逆に高複雑度タスクを軽量モデルで通そうとすると失敗コストがかさむ。

「タスク種別 × モデル」のマッピングを1枚の表に落とすと議論が具体化します。

軸3: ハーネス選択（モデル選択より先に議論する）

市販のエージェントハーネス（Claude Code、Codex、Cursor等）にどこまで載せるか、あるいは軽量ハーネスの選択肢を並べて比較するか。

自社でPiのようなハーネスを開発するのは非現実的でも、「送信コンテキスト量」「ツール呼び出し設計」を選定基準に入れるだけでコスト構造が大きく変わります。

以前書いた「ループエンジニアリング」の記事でも触れましたが、何を測るかが決まらないと改善のループは回りません。

この3軸を1枚のシートに書き出して、次のスプリントレビューで投げるところから始めるのが実務的ですね。

明日、手元で始められる最初の1歩

Databricksの結論をもう1度置きます。

マージ済みPRを積んできたチームは、既にベンチマークデータを持っている。

明日から手元でできる1つのアクションは、直近マージ済みPRを3〜5本選び、「AIエージェントがこのPRを再現できるか」を評価用タスクとして用意することです。

テストが通っているPRなら、AIの出力がテストを通過するかで自動採点できます。

3〜5本なら1時間で用意できる粒度で、PRD 1本書くより短い時間で自社ベンチマークの初版が組めます。

コーディングエージェントの選定は、他社の比較記事を待つフェーズから、自社データで判断するフェーズに移りました。

手元のPRが、その第一歩の材料になります。