Databricks、AIコーディング費用を70%削減

メインコンテンツへスキップ AIコーディングツールは計り知れない価値をもたらします。Databricksでは、エージェント型コーディングにより、追跡しているあらゆる速度指標が測定可能に改善され、一部のチームではアウトプットが桁違いに向上しました。 しかし、AIツールを大規模に展開しているほぼすべての企業が同じ壁にぶつかっています。それは、指数関数的に増加するコストです。この曲線は持続不可能であり、放置すれば最終的には収益を上回ることになります。 支出の爆発により、企業は逆説的な状況に置かれています。一方では、AI変革を最大限に推進し、従業員に強力なツールを提供したいと考えていますが、他方では、AIがもたらす効率向上そのものを損なう、あるいは逆転させる可能性のある総コストプロファイルを調整する必要があります。 幸いなことに、最も早期に大規模採用した企業のいくつかが、このパズルを解決する一連のアプローチを収束させ、「デュアルマンデート」を達成しました。(a)最小限の摩擦でAIツールの広範なアクセスを提供すること、および(b)ユーザーあたりの総コストをおおよそ固定された範囲内に保つこと。 この記事では、Databricksでの経験と、Stripe、Coinbase、Uber、Rampなどの他の多くのデジタルネイティブ企業との会話に基づいた、実績のあるコスト管理技術の概要を説明します。 以下の表は、現在の技術とその関連する節約額をまとめたものです。数値は、開発チームの非公式な調査に基づいた方向性を示すものです。 これらの技術の一部は、多くの企業がすでに使用しているソフトウェアで簡単に実装できます。 他のものには、特にエンドユーザークライアントを変更したり、トラフィックをモデル間でシフトしたりする技術には、新しいインフラストラクチャが必要です。 Databricksでは、主要なインフラストラクチャコンポーネントであるエンドユーザーメタハーネス（Omnigent）とAIゲートウェイ（Unity AI Gateway）をオープンソース化または無料で利用できるようにしました。 完全を期すために、この記事では、私たちが話を聞いた他の企業が使用しているソフトウェアについてもカバーしています。 コーディングモデルの「効率フロンティア」 新しいモデルがリリースされるにつれて、コーディング費用をより効率的なモデルに移行させることが、最大のコストレバーです。 この点は、議論の余地があります。なぜなら、「より安価なモデル」という単純な説明は、実際にはモデルのコストと品質の間の微妙な関係を隠しているからです。 一般的に、フロンティアモデルという用語は「最も知的なモデル」を意味し、フロンティアラボは主にピーク知能の進歩に焦点を当てています。 フロンティアモデルは現在、数学やサイバーセキュリティの新しい問題を解決できます。 しかし、AIが大規模に展開される場合、より重要なのは別の種類のフロンティアです。それは効率フロンティアです。 効率フロンティアは、特定の知能レベルに対して最も優れた価格ポイントを持つモデルのセットによって定義されます。 ほとんどの日常的なコーディングは、数学的証明や新しいセキュリティインサイトを必要としないため、全体として重要なのは、典型的なソフトウェアエンジニアリング作業の品質基準を満たすモデルのコストです。 この「効率フロンティア」は、知能フロンティアよりもはるかに速く進歩しており、毎週のように新しいモデルがリリースされ、以前のモデルよりも単価あたりの知能が高いものを提供しています。 コストレバー #1: オープンソースおよび低コストモデルへの移行 より新しく、より効率的なモデルを迅速に採用することが、あらゆる技術の中で最大のコスト削減をもたらします。 しかし、そのメリットを享受するには、企業はまず、どのモデルが実際に既存のモデルを上回るかを知る必要があります。 公開ベンチマークは、コーディングタスクにおける実際のパフォーマンスを適切に示していないため、これは困難な場合があります。 新しいモデルを評価するために、多くの企業は、社内の開発ミックスをより代表するものと信じている自動評価を構築しました。 Databricksは最近、このようなベンチマークの例を公開しました。その中で、GLMモデルの価格/パフォーマンスが非常に競争力があることを確認しました。 そのベンチマークにより、GLMを社内の開発者に展開することになりました。 多くの場合、新しいモデルは効率フロンティアを進歩させず、評価はしばしば否定的な結果をもたらします。 Stripeは、Opus 4.7がOpus 4.6よりも品質を大幅に向上させず、コストが増加したことを発見しました。そのため、Opus 4.7を社内で利用可能にしないことを決定しました。 Databricksも、Opus 5.0と4.8を比較した際に同様のコスト増加を確認しました。 ハーネスとモデルの柔軟性 最大のメリットは新しいモデルへの切り替えから得られるため、モデルの柔軟性を可能にするエンドユーザーツールを採用することが、コストを抑えるための重要なコンポーネントになりつつあります。 特定のモデルと組み合わせて最も一般的に使用されるツールはハーネスと呼ばれます。 プロプライエタリなフロンティアモデルは、特定のハーネスと連携するようにますます共同設計されており、特定のハーネスは特定のモデルと「より良く機能する」ことを意味します。 企業がモデルの独立性を維持したい場合、アプローチはほぼ2つあります。 ユーザーにハーネスを切り替えてもらう。 1つのアプローチは、開発者に一連のハーネス（Claude Code、Codex、またはCursor）を提供し、企業が支出を低コストモデルに移行したいときにハーネスを切り替えるように依頼することです。 これにより、ユーザーは可能な限り好みのハーネスで作業できますが、このアプローチの欠点は、個々の開発者にとっての切り替えコストが高くなる可能性があることです。 切り替えコストが高すぎると、ハーネス自体がモデルファミリーへの事実上のロックインとなり、より競争力のあるモデルへの支出を移動する能力を制限します。 メタハーネスを使用する。 新しく、ますます人気のあるアプローチは、メタハーネスを使用することです。 メタハーネスは、開発者に共通のユーザーエクスペリエンスを提供しながら、基盤となるハーネス（プロプライエタリおよびオープンソースの両方）にリクエストをディスパッチします。 このアプローチにより、モデル/ハーネスの独立性が確保されると同時に、開発者の切り替えコストが削減されます。 Databricksでは、Omnigentを活用する開発者にとって、これがデフォルトモードです。 私たちが話を聞いた一部の企業は、開発ツールチェーンと統合されたカスタムの社内メタハーネスを構築しています。 コストレバー #2: 動的なリクエストとタスクルーティング ユーザーにタスクに適したモデルを自分で選択させるのではなく、エージェント型コーディングワークフローからさらに効率を引き出すことができる自動モデルおよびツール選択に関する研究が増えています。 ルーティングアプローチは、大まかに3つのカテゴリに分類されます。 リクエストレベルルーティング：ステートフルプロキシが、クライアント（コーディングハーネスなど）と基盤となるファウンデーションモデルの間に配置されます。 プロキシは、各推論リクエストに応答できる最も低コストのモデルにリクエストをルーティングしようとします。 エージェント型ユースケースのルーティングも、サーバーサイドキャッシュを考慮する必要があります。 なぜなら、コールドキャッシュヒットは、大規模コンテキストワークロードにとって非常にコストが高いからです。 新しい製品の波が、ルーティングの初期の有望な結果を示しています。 例としては、Cursor Router、OpenRouterのAutoRouter、RampのRouter機能、およびDatabricks独自のUnity AI GatewayのSmart Routing機能があります。 タスクレベルルーティング（メタハーネス）：クライアントサイドプロセスが、タスクの複雑さに基づいてユーザータスクを異なるハーネスにディスパッチします。 ユーザータスクは、「このコンポーネントをXからYに名前変更する」（簡単なタスク）または「レイテンシーを削減するための設計上の考慮事項を探る」（複雑なタスク）のようなものかもしれません。 メタハーネスと呼ばれるディスパッチャーは、タスクに必要な基盤モデルのレベルを調べ、そのエンドツーエンドのタスク全体をモデルに委任します。 Omnigentは、このパターンをサポートするメタハーネスの例です。 エスカレーション/委任パターン：単一のハーネスが2つのモデル（高価で高知能なモデルと安価なワーカーモデル）をペアにします。 ClaudeのAdvisor Toolのような一部のアプローチでは、安価なモデルが主導権を握り、より多くの処理能力が必要だと判断した場合にエスカレーションします。 逆のアプローチも存在します。 CognitionのDevin Fusionでは、高コストモデルがメインループであり、安価なモデルに作業を選択的にアウトソースします。 Databricksの社内結果は、当社のAIゲートウェイSmart Routerが、作業セットの中で最も高価なモデルの品質にほぼ匹敵しながら、平均タスクコストを一貫して30%以上削減できることを示唆しています。 私たちが話を聞いた他の企業も同様の結果を見ています。 コストレバー #3: 開発者に可視性、トリップワイヤー、予算を提供する この記事全体が「ユーザーに月間予算を与えて、それで終わりにする」で始まらず、終わらなかったことに驚くかもしれません。 ハードバ