モデルは「3つのグループ」に分かれる、常に最高価格帯を使う必要はない

彼らは順位を追いませんでした。数ポイントの差は実タスクではならされてしまうからです。役に立つのはグルーピングのほう — モデルと外側のすべての組み合わせが、はっきり3つの能力帯に落ちました。

3つの能力帯：82–90%、71–82%、51–60%。右側の注記は各帯の内部の価格差倍率で、第1グループ内では最大2.2倍の開きがあります。画像出典：Databricks

どの作業を下ろすかは、まずログで測る

着手前に、彼らはまず AI コーディングセッションのログを全部引き出し、エンジニアが実際に AI に何をさせているかを調べました。

AI コーディングセッションのタスク複雑度別の分布。上から順に、ごく簡単7.6%、低難度19.3%、中難度61.1%、高難度12.1%。画像出典：Databricks

およそ4分の1が低複雑度の作業、6割が中難度で、本当に深い設計探索が要るのは12.1%だけ。それなのにデフォルト設定ではずっと最高価格帯のモデルが使われていた — この間の無駄は目に見えています。

オープンソースの台頭、日常の「主力機」として十分使える

第1グループにはオープンソースのモデルが1つ座っています。智譜（Zhipu）の GLM 5.2 です。

「トークン単価が安い」は「最終的に安い」ではない

モデルを選ぶとき、ほぼ全員が同じ数字を見ています。100万トークンいくらか。この数字では、最後にいくら払うかを予測できません。

実行フレームワーク（ハーネス）がコストに与える影響は絶大

同じモデル、同じ思考レベルで、外側を替えるだけ。1問あたりコストは2倍以上変わり、品質はほぼ動きません。多くの人は、外側を「選べるもの」だと思っていません。

1問解き終えるまでに、累計でモデルへ再送されたコンテキストの総量（中央値）。上段は Opus 4.8 で、claude code 742k、pi 236k、3.2倍差。下段は GPT 5.5 で、codex 1235k、pi 665k、1.9倍差。画像出典：Databricks

赤い点が pi、白抜きの円が各社純正の外側、横軸は1問あたりコスト。各行の右側に両者の正解率を記載。画像出典：Databricks

pi — 道具箱に4つしか入っていないコーディングアシスタント

pi は Claude Code や Codex と同じ種類のもの。自分のマシンに入れてターミナルで動かし、やってほしいことを一言で伝えると、自分でコードを漁り、ファイルを直し、テストを走らせ、終わったら報告してくれます。

薄いこと。それが安さの理由のすべてです。毎ターン、外側はひとかたまりの情報をモデルに再投入します。常駐の説明書、全ツールの使い方、それまでの会話、今回見せるコード。ツールが多く、説明書が長く、履歴を全部残すほど、このかたまりは膨らみます。そして毎ターン、その分の料金を払い直すことになります。

送らなかった情報が消えるわけではありません。モデルが本当に必要になったら、自分で「ファイルを読む」を呼んで取りに行きます。この設計が成り立つ前提は、モデルが自分から取りに行き、ちゃんと取ってこられることです。

思考レベルを振り切ると、高くて悪い

モデルの思考レベルを最大にしても、精度が上がるとは限りません。ただし料金は確実に上がります。

なぜ定番の SWE-Bench などを使わないのか

ここまでの結論を信じられるかどうかは、問題の作り方にかかっています。公開ベンチマークでは、彼らの問いに答えられません。

そこで自社エンジニアが毎日マージしているコードを問題に作り替えました。レビューを通った PR は、それ自体が良い素材です。開発者が一歩ずつ直したコミット履歴があり、人によるレビューがあり、その変更が正しいか検証するテストもあります。

まず絞り、それから作り替える

あるテストの書き換え前後。元のテストは文字列の完全一致に依存しており、モデルが言い方を変えるだけで失敗と判定されていました。出力がもともと一定しない場面では良い検証方法ではないため、振る舞いが正しいかを見る形に変更しています。画像出典：Databricks

AI に採点させないのは、それが「正しそうに聞こえる答え」を評価してしまうから

採点の流れはこうです。モデルが「終わった」と言ったら、その時点のコードを保存し、隠しておいたテストを戻して走らせ、全部通ればその問題は正解。評価の全過程で大規模言語モデルを審査員に使っていません。理由はこうです。

We did not use an LLM judge to evaluate correctness, since we've found that this rewards sounding right over being right. 正しさの評価に LLM の審査員は使いませんでした。それは「正しいこと」より「正しそうに聞こえること」を評価してしまうと分かっているからです · Databricks

テストが通るか通らないかは二値で、解釈の余地がありません。だからこそ「質の高いテストが必須」という条件は外せないのです。採点基準の信頼性は、このテスト群にすべて賭けられています。

Databricks はどうやってカンニングを防ぎ、テストを組んだか

初期の実験では、いくつかのモデルのスコアが不自然に良すぎました。実行の全トレースを引き出して人の目で追うと、原因は環境にありました。どの問題もマージ済みのコミットから作られており、しかも完全な git 履歴が作業ディレクトリにそのまま置かれていたのです。シェルコマンドを実行できる Agent なら、git 履歴をたどって当時の「模範解答」をそのまま掘り出せてしまいます。

対処は単純明快。実行のたびに、作業コピーとリポジトリを丸ごと切り離し、git 履歴を取れなくしました。

彼らが追加した守りの措置。画像出典：Databricks

すべてのコーディング Agent の外側とモデルは、それぞれ標準の初期設定のまま使用。Databricks のエンジニアが普段使える一般的なツールを添えただけで、テスト向けの特別なチューニングはしていません。

まとめと示唆

これは Databricks の規模がなければできない話ではありません。マージ済みの PR が一定量あるチームなら、モデルが学習していないベンチマークはすでに手元にあります。採点基準は、自分たちが書いたテストそのものです。

彼らは今後も問題を追加していく方針で、とくに難しい問題を増やし、新しい Agent や外側が出るたびにこのテストを通すとしています。

同じ問題群、同じ採点基準で、7モデル × 3フレームワーク × 4思考レベルを走らせると、結果は3つの帯に落ちました。第1グループにはオープンソースが1つ。智譜（Zhipu）の GLM 5.2 が87%で Opus 4.8 と互角、1問 $1.28 対 $1.94 です。

モデルを選ぶとき、ほぼ全員が100万トークンいくらかを見ています。その数字と最後に払う金額の間には、変数が1つ挟まります。モデルがそれをやり終えるまでに、どれだけ読み、どれだけ考えるか。

外側（harness）は、モデルの出力を実際の操作に変えるレイヤーのソフトウェアです。毎ターンどれだけのコードをモデルに見せるか、どのツールを呼べるか、失敗したらどう再試行するかを決めます。Claude Code、Codex、pi はどれも外側で、下にどこのモデルを挿しても動きます。同じモデル、同じ思考レベルで外側を替えるだけで、1問あたりコストは2倍以上変わります。

同じ Opus 4.8、同じ問題群で、1問解き終えるまでに累計投入された量は3.2倍の差。送らなかった情報は消えておらず、モデルは必要になったら自分で「ファイルを読む」を呼びます。pi は Armin Ronacher（Flask、Jinja2 の作者）と Mario Zechner のオープンソースプロジェクトで、GitHub のスターは約5.4万。この背景は原文に記載がありません。この勝負を制したのはサードパーティのオープンソースで、Databricks 自社の Omnigent は、モデルも外側もいつでも差し替えられるようにする製品です。