AIエージェントにコーディングを任せる企業が契約前に目にするのは、「1000トークンあたり◯ドル」というベンダーの提示価格だ。だがUberは2026年、AI利用を全社で後押しした結果、わずか4か月で年間予算を使い切り、6月に利用上限を敷く事態に追い込まれた。トークン単価が安いモデルを選べば安く済むはずなのに、なぜ現場のコストは見積もりを超えるのか。
Databricksが7月9日に公表した社内ベンチマークが、その理由を示した。AnthropicのSonnet 5はトークン単価でOpus 4.8より約1.7倍安いのに、タスク1件のコストは2.09ドルとOpus 4.8の1.94ドルを上回った。逆にGLM 5.2は、Opus 4.8と同水準の品質でタスク単価1.28ドルと34%安く済んだ。トークン単価は、実際の請求額を言い当てていない。
タスク単価で見るとOpus超えになったSonnet 5の誤算
このベンチマークはDatabricksのエンジニアリングチームが公式ブログで公開したもので、同社が実際に扱う数百万行規模のコードベース上で、エンジニアが日々こなしている実タスクを使って評価している。共著者にはDatabricks CTOのMatei Zaharia氏(UCバークレー校コンピュータサイエンス准教授を兼任)も名を連ねる。結果はモデルとハーネスの組み合わせによって明確に3つの能力階層に分かれ、GLM 5.2は最上位階層でOpus 4.8と統計的に同水準の品質を示しながら、タスク単価は1.28ドルとOpus 4.8の1.94ドルより34%安かった。OpenAI・Anthropic・オープンソースそれぞれのモデルがコストと品質の最適な組み合わせ(パレートフロンティア)を分担して構成しており、単一のベンダーの製品だけを使う調達方針では今回計測した水準の性能を再現できないこともブログは指摘している。
問題はSonnet 5だ。Databricksのブログは、Sonnet 5がOpus 4.8よりトークンあたり約1.7倍安いにもかかわらず、実際のタスクではOpus 4.8の1.94ドルに対しSonnet 5が2.09ドルとなり、タスク完了率も6ポイント低い81%(Opus 4.8は87%)だったと報告している。その主因についてブログは、Sonnet 5が完了までに長く動作しより多くを読み込んだ結果、消費トークン量がOpus 4.8の1.9倍になったためと説明する。見積もりの根拠にしていたトークン単価の序列が、請求額の序列とは一致しなかったことになる。
消費トークン量の差が安さを裏切る仕組み
トークン単価とタスク単価が逆転する理由をDatabricksは「モデル間の推論効率のばらつきによって、トークン単価は実際のタスクコストの悪い指標になる」と総括している。同じ問いに答えるにも、あるモデルは短く要点だけを読んで答えを出す一方、別のモデルは何度もコードを読み返し、長く思考してから答えを出す。Sonnet 5はOpus 4.8よりも長く動作しより多く読み込んだ結果、消費トークン量が1.9倍に膨らみ、トークン単価の安さという優位を消費量の増加が上回った。
この「約1.7倍安い」という比較がAnthropicのどの価格帯を基準にしているかを、Databricksのブログは明記していない。Anthropicは標準価格(Sonnet 5が入力100万トークンあたり3ドル・出力15ドル、Opus 4.8が同5ドル・25ドル)とは別に、2026年8月31日まで適用される導入価格(Sonnet 5が入力2ドル・出力10ドル)を設定しており、この期間はOpus 4.8よりトークンあたり約2.5倍安い計算になる。Databricksが示した1.7倍という比率は標準価格の比率(5/3・25/15)と一致するため、標準価格を基準に算出されたとみてよい。導入価格を基準に同じトークン消費量で再計算すると、Sonnet 5のタスク単価は2.09ドルの3分の2にあたる約1.39ドルとなり、Opus 4.8の1.94ドルを下回る。価格の前提条件次第で結論そのものが変わりうる点は、この種の比較につきまとう留保として押さえておく必要がある。
Sonnet 5の場合、標準価格ベースで見る限りトークン単価の安さでは埋め合わせられないほど消費トークン数が積み上がり、完了率でも劣後した結果、Opus 4.8より高いタスク単価に着地した。同様の現象は2026年3月に発表された学術論文「The Price Reversal Phenomenon」でも確認されている。
Lingjiao Chen氏ら(Zaharia氏も共著者に名を連ねる)は、8つの最先端推論モデルを12種類のタスクで評価し、モデル比較の約32%で表示価格の安いモデルの実コストがより高くなる逆転を確認した。例としてGemini 3 Flashは表示価格がGPT-5.4より80%安いのに、タスク全体の実コストは38%高かったと報告している。同論文は価格逆転の幅が最大28倍に達し、同一の問いへの回答でも思考トークンの消費量がモデル間で最大900%異なることも記録した。価格逆転の主因は、1回のクエリ内で消費する思考トークン量や環境とのやり取りの回数がモデルごとに大きく異なる点にあり、失敗後の再試行費用が直接の原因になっているわけではない。トークン単価だけを見て安いモデルに切り替える判断は、この消費量の差という変数を見落としやすい。
エージェントが1回のセッションでこなせるタスクの複雑さは年々伸びている。AI評価機関METRの計測では、AIエージェントが一定の信頼度で完了できるタスクの長さ(人間専門家換算の所要時間)は、2019年から2025年にかけて約7か月ごとに倍増するペースで伸びてきた。タスクが長く複雑になるほど1回の試行に投入するトークン量そのものが増えるため、モデル間の消費量の差が実額に与える影響は今後さらに大きくなる方向にある。
円換算で見るタスク単価、3モデルの実際の差
1ドル=162円(2026年7月中旬の実勢レート目安)で換算すると、Databricksが計測した3モデルのタスク単価は次のようになる。ドル建ての数字にレートを掛けただけの単純換算であり、為替変動や個別契約の割引条件は反映していない。それでも共通のものさしに揃えることで、日本円で予算を組む開発チームが比較すべき規模感が見えてくる。
- GLM 5.2: 1.28ドル→約207円/タスク
- Opus 4.8: 1.94ドル→約314円/タスク
- Sonnet 5: 2.09ドル→約339円/タスク
最も安いGLM 5.2と最も高いSonnet 5の差は1タスクあたり約132円にすぎない。しかし1日に数百件、月に数千件のタスクをこなす開発チームでは、この差が積み上がって桁の違う金額になる。契約時に比較するのはベンダーが提示するトークン単価だが、実際のタスク単価は消費トークン数と完了率という2つの実測値によって決まるため、契約段階の見積もりと運用後の実額がずれる余地が最初から埋め込まれていることになる。
たとえばエンジニア20人が1日50件のタスクをAIエージェントに任せる開発チームを想定すると、1日あたりの処理数は1,000件になる。Opus 4.8とSonnet 5のタスク単価差(1件あたり約25円)をこの規模に当てはめると、1日で約2万5,000円、20営業日の月間では約50万円の差になる計算だ(実在の特定企業の数字ではない。あくまで規模感を示すための仮定シナリオである)。タスク単価のわずかな差が、チーム規模が大きくなるほど無視できない金額に膨らんでいく。
Uberの月1,500ドル上限とタスク単価はどうつながるか
Uberは2026年に入ってAIエージェントの利用を全社的に後押しし、社内リーダーボードまで用意した結果、わずか4か月で年間AI予算を使い切った。TechCrunchとBloombergの報道によれば、Uberは2026年6月、Claude CodeやCursorなどエージェント型コーディングツールについて、ツール1つあたり従業員1人につき月1,500ドルの利用上限を設定した(全ツール合計の予算上限ではない)。エンジニアの約95%がこうしたツールを使い、同社コードの約10%がAIエージェントによって生成されているという規模の利用実態が、予算超過の背景にある。
このツール単位の上限額をDatabricksが計測したタスク単価に当てはめると、選ぶモデル次第でこなせるタスク数に差が出る構図が見える。仮に1ツールあたり月1,500ドルの枠をタスク単価だけで割ると、GLM 5.2相当なら約1,172タスク、Opus 4.8相当なら約773タスク、Sonnet 5相当なら約718タスクとなる計算だ(実際のUberの利用モデルやタスク構成は公開されておらず、あくまでDatabricksの数値を上限額に当てはめた試算である)。同じ1,500ドルの枠でも、選ぶモデル次第でこなせるタスク数は718件から1,172件まで、最大39%の開きが生じる。Uberの予算超過は利用量の急拡大が主因だが、トークン単価だけを基準に契約や予算配分を決める発注方式が、完了率という変数を欠いたまま組まれていた可能性を示す傍証にはなる。
経営層がAI予算を「トークン単価×想定利用量」で見積もると、実際の完了率次第で処理できる仕事量が想定より目減りするリスクを織り込みにくい。Uberのケースで特定モデルの完了率が予算超過の直接原因として名指しされたわけではないが、エンジニアの95%がエージェント型ツールを常用し、コードの1割をAIが生成する規模まで利用が広がった状況では、トークン単価だけを基準にした発注が実際の消費量を見誤りやすい構造は共通している。
安いモデル=お得ではない。ハーネス次第で3倍動くコスト構造
Databricksの検証でもうひとつ目を引くのが、同じモデル・同じ思考量の設定でも、実行環境(ハーネス)によってコストが大きく変わった点だ。ベンダー製のClaude CodeやCodexと、軽量な自社製ハーネス「Pi」とで同一モデルを比較したところ、品質は変わらないままタスクあたりのコストが2倍以上違うケースがあったという。差が生まれた主な要因は、各ハーネスが1回のやり取りでモデルにどれだけの文脈(コンテキスト)を送り込むかだった。Piは1回のやり取りで送る文脈量が他のハーネスよりおよそ3分の1少なく、作業対象を絞り込んだまま少ない往復でタスクを終わらせていたという。
モデル選定だけに注力してハーネスを既定のまま使い続ける調達判断は、コスト最適化の半分しか見ていないことになる。Databricksはこの知見を踏まえ、モデルとハーネスの組み合わせを柔軟に切り替えられる社内基盤「Omnigent」に投資したと説明している。「安いモデルに乗り換えれば得をする」という直感は、モデル単体の話に矮小化された時点で崩れやすい。
自社コードベース限定という限界と、TCOで測る次の一歩
Databricksがこの評価を独自に構築した理由は2つある。SWE-BenchやTerminalBenchのような公開ベンチマークは、課題が公開されているために解法が時間とともに学習データへ流入してしまうこと、そしてDatabricksが扱うScala・Go・Rust・Java・Pythonなど10以上の言語にまたがる多言語コードベースを代表していないことだ。実際のマージ済みプルリクエストを基に構築したベンチマークだからこそ、自社のエンジニアを妨げない形で最適化の判断ができるとDatabricksは説明している。GLM 5.2の34%安いという結果も、この自社特有のコードベースとタスク分布に基づくものであり、業種やコードベースの性質が異なる企業でそのまま再現される保証はない。
Zaharia氏は2026年3月の学術論文「The Price Reversal Phenomenon」の共著者でもある。同じ人物が関わった社内ベンチマークと学術研究の双方で同じ逆転現象が確認された事実は、この現象が一時的な計測誤差ではないことを裏付ける材料になる。一方で両方の分析にZaharia氏が共著者として名を連ねている以上、今回の結果は独立した第三者監査ではなく「Databricks社内の評価」という文脈込みで受け止める必要がある。
ここまでの計測結果を素直に読むなら、AIコーディングエージェントの調達で比較すべき指標は複数ある。トークン単価はそのひとつにすぎない。タスク完了率を欠いたまま単価を比べれば、実際の消費トークン量や品質面のリスクが見積もりから抜け落ちる。
1タスクあたりの平均消費トークン数もモデル単体では決まらず、ハーネスの設計次第で3倍前後動く。そして何より、その評価結果が自社のコードベースや業務内容でも再現されるかを確かめる検証プロセスそのものが欠かせない。
一方でEpoch AIの分析は、複数のベンチマークで一定の性能水準を満たす最安モデルの価格を追跡すると、その下落率は年間中央値で約50倍に達することを示している。これは性能基準を満たす最安モデルを追いかけたときの下落率であり、市場全体の平均トークン単価を示す数字ではない。個別タスクの実コストが同じペースで下がるとは限らないという点で、Databricksの逆転現象と同じ方向を指している。Databricks自身、この分析結果を踏まえてフラグ切り替えや設定変更のような定型作業をHaikuやGPT 5.4 Miniクラスの安価なモデルへ回す判断を下したという。
ベンダーが提示するトークン単価の一覧表は出発点に過ぎない。自社のコードベースとタスク分布で完了率・消費トークン数・ハーネス依存度を測り直し、その結果を実際の調達判断に反映させるところまでやり切れるかどうかが、エンタープライズのAI予算管理の分かれ目になる。
