DatabricksがGLM 5.2を標準採用|タスク単価34%減の3要点

DatabricksがGLM 5.2を開発の標準モデルに採用。Opus 4.8と同等性能でタスク単価34%減の実測データ、3層の性能クラスタ、トークン効率の新指標をEC事業者向けに解説します。

投稿日: カテゴリー AIニュース

Databricksは2026年7月9日、中国発オープンソースAI「GLM 5.2」を開発者の標準コーディングモデルに採用すると発表しました。

自社の数百万行規模のコードベースで実施した独自ベンチマークで、GLM 5.2がAnthropicのOpus 4.8と統計的に同等の性能を示し、タスクあたりのコストは1.28ドル対1.94ドルと約34%安かったことが決め手です。The Decoderが7月9日に報じました。Snowflake、Coinbaseに続き、米国の主要テック企業が中国系オープンソースモデルを実務の主力に据える流れがまた一歩進んだ形です。

Databricksのベンチマークで各モデルが3つの性能クラスタに分かれた分析図

何が起きたか:自社コードベースでの実測でOpus 4.8と統計的に同等

結論から言うと、Databricksは公開ベンチマークではなく自社の実コードベースで各モデルを検証し、GLM 5.2を日常の主力モデルに切り替える判断を下しました。検証結果をまとめたDatabricks公式ブログには共同創業者のMatei Zahariaも著者として名を連ねています。ブログでは「これらを日常のコーディング用ドライバーとして展開し始める時期が来たことを証拠が示している」と明言されており、社内パイロットでの開発者フィードバックも結果を裏付けたとしています。

検証の設計も注目に値します。SWE-Benchのような公開ベンチマークは、解答が学習データに漏出する経年劣化があり、自社の技術スタック(Python、Go、TypeScript、Scala、Rustなど10言語超)を代表しないため、実際のプルリクエストから独自ベンチマークを構築しました。採点はLLMによる審査ではなくテスト通過のみで判定し、モデルがGit履歴から正解を検索してしまう「カンニング」への対策として、実行ごとにGit履歴を切り詰める処理まで加えています。OpenAIも最近、同様の理由でSWE-Bench-Proへの依存に警鐘を鳴らしており、「公開ベンチマークより自社タスクでの実測」という評価手法の潮流が鮮明になっています。

なぜ重要か:単一ベンダー依存の終わりとトークン効率という新指標

このニュースが重要な理由は、性能の最上位層がもはや1社の独占ではないことを実務データが示した点にあります。Databricksの検証では、テストしたモデルと構成が3つのクラスタに分かれました。合格率82〜90%の最上位グループにはOpus 4.8、GLM 5.2、一部構成のGPT 5.5が入り、71〜82%の中位グループにSonnet 4.6、Sonnet 5、GPT 5.4など、51〜60%の下位グループにGPT 5.4-miniとHaiku 4.5が位置しました。品質とコストの最適比率を示すパレートフロンティアは、OpenAI、Anthropic、オープンソースの3陣営のモデルで構成されており、Databricksは「フロンティア級の性能を出せるのは複数モデルの併用だけ」と結論づけています。

品質対コストのパレートフロンティアを示すDatabricksの分析図

もう1つの発見は、トークン単価と実際のタスクコストは別物だという点です。Databricksは自動車の燃費にたとえて「トークン効率」の重要性を指摘しており、同社のPiハーネスはClaude Codeと比べて約3分の1のコンテキスト送信量で動作しました。Opus 4.8の高エフォート設定では、品質がほぼ同等(85%対87%)のままPi経由のコストが2.08分の1になり、GPT 5.5でもCodexの123万5,000トークンに対しPiは66万5,000トークンで済んだといいます。どのモデルを選ぶかと同じくらい、どの実行環境で動かすかがコストを左右するということです。

業界全体でも同じ方向の動きが続いています。CoinbaseはGLM-5.2やKimi 2.7への移行でAI支出を半減させ、SnowflakeのCEOもGLM-5.2がOpus 4.7と僅差であると公言していました。OpenRouterでは2026年2月以降、中国系モデルが週間トラフィックの30%超を占め、前年の11%から急伸しています。価格は欧米モデル比で60〜90%安い水準です。

今後の動き:タスク複雑度によるルーティングが次の標準に

Databricksが次に進めるのは、タスクの複雑さに応じたモデルの使い分けです。Unity AI Gatewayを通じた分析では、同社エンジニアのコーディングタスクの61%が中程度の複雑さで、低難度が約19%、高難度は12%にとどまりました。従来は最も高価なモデルが既定になっていましたが、今後は安価な階層へ仕事を振り分ける方針です。この設計は、Anthropic自身が進めるFable 5からSonnet 5への委譲構成とも方向性が一致しており、「高性能モデルを常時使う」から「適材適所で配分する」への移行は業界標準になりつつあります。

日本のEC事業者にとっても、この考え方はそのまま応用できます。商品説明文の量産やレビュー返信の下書きのような定型タスクに最上位モデルを使い続けているなら、タスクの難度別にモデルを振り分けるだけでAI利用コストは大きく変わります。その際はDatabricksがやったように、公開ベンチマークの評判ではなく、自社の実タスク数件で品質とコストを実測してから切り替えるのが確実です。なお、GLM 5.2を日本の商用環境で使う場合のデータ取り扱い条件やサポート体制は要確認です。

まとめ

DatabricksがGLM 5.2を標準コーディングモデルに採用し、最上位性能がOpenAI・Anthropic・オープンソースの3陣営に分散していることを実測で示しました。モデル選定の判断材料は「ブランド」から「自社タスクでの単価と品質の実測」へ移っています。EC事業者もタスク難度別のモデル使い分けとコスト実測を始める時期です。

※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/

引用元: The Decoder


【監修】齋藤竹紘(株式会社オルセル代表 / 19年・5,000社のEC支援実績)


投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。

お問い合わせ