Databricksの共同創業者であるPatrick Wendellが、AIコーディングコストが指数関数的に増加する理由と、エンジニアリングリーダーがチームのスピードを落とさずにコストの増加傾向を抑える方法について解説します。
によって キャサリン・ブラウン による投稿
この対談では、Catherine BrownがPatrickと語り合い、DatabricksがAIコーディングエージェントに全面的に取り組んだ際に何が起きたのかを明かし ます。使用量の増加に伴い当初どのようにコストが急増したのか、ユニットコストを最大90%削減した具体的な方法、そしてなぜすべてのエンジニアリング組織が開発者とモデルの間に管理レイヤーを必要とするのかについて議論します。この管理レイヤーは、Databricks自体のAI利用料金に対する社内でのソリューションとして始まり、Unity Gatewayの着想へとつながりました。
Catherine: あなたはDatabricksのAIプロダクトを担当し、社内でのAI活用推進のリーダーも務めていますね。なぜこれを個人としてそれほど重要な優先事項として捉えているのですか？
Patrick: エンジニアリングのアウトプットが私たちのビジネスにおける最大のボトルネックだからです。すべての企業はエンジニアリングチームのスピードアップを必要としており、生産性を大幅に向上させるツールを提供できれば、それには非常に大きな価値があります。初期のチャットプロダクトもある程度有用でしたが、約1年前に最初の優れたコーディングモデルが登場したことで、ROI（投資対効果）が大きく変化しました。
Catherine: AIツールから生産性の向上を得られているかどうかは、どのように判断していますか？
Patrick: 私たちは、プルリクエスト数、リリースされた機能、コード行数など、数多くの成果指標を追跡しています。単体で完璧な指標はありません。私はR&Dをひとつの大きなマシンだと考えています。リソースを投入すれば機能 やコードが出力され、どれだけの成果が増えたかを測定できます。全体として、同じチームサイズでアウトプットをほぼ倍増させています。AIを中心にプロセスを再構築したチームは、それよりもはるかに速いスピードで進んでいます。
Catherine: Databricksが最初にAIコーディングツールを導入した際、どのような誤りがありましたか？
Patrick: 面白いことに、最初は真逆の問題を抱えていました。誰も新しいツールを試そうとしなかったのです。私はあちこちに声をかけて回っていました。そこで私たちは、多くの企業がやるようにあらゆる障壁を取り除きました。最も高価なモデルを、希望するだけのトークン数で提供したのです。これは善意から出た施策だったと思います。人々に最初のハードルを乗り越えてもらおうとしたのです。
しかし実際に人々が使い始めると、コストが指数関数的に急増しました。これらのツールは現在、席数単位ではなく従量課金制であるため、原理的には1人のユーザーが無制限に費用を使うことができます。最も高価なモデルで処理をループ実行させたままランチに行くことも可能です。そのループが非常に価値のある作業を行っているかもしれないし、単にトークンを無駄遣いしているだけかもしれません。コストが指数関数的に増加しているのに収益が伴わなければ、どこかで問題が発生します。導入の最大の目的であった効率化による効果が、コストのせいで相殺されかねない状況にまで達しました。
その時点で、私は個人として深く関与するようになりました。大規模にAIを導入している他のテクノロジー企業（Coinbase、Uber、Stripeなど）のリーダーたちと情報交換を行いました。全体として、私たちの多くが同様の手段を試みていました。現在、Databricksでは、総使用量とそこから得られる価値が増加し続けているにもかかわらず、1人あたりのトークン費用はほぼ横ばいで推移しています。
Catherine: 多くの企業の最初の反応は、厳格な支出上限（ハードキャップ）を設定することです。あなたもそれを試しましたね。どうなりましたか？
Patrick: それは当然の最初のステップであり、そのような仕組み自体は必要です。しかし、強制的にストップさせるのは良くない体験です。作業の途中で利用を制限されると集中が途切れ、数時間分の作業が無駄になることもあります。そして、上限に達する人々は往々にして最も優秀なユーザーです。彼らを制限すると、一部は個人のアカウントを使い始めてしまい、組織からは利用状況がまったく見えなくなってしまいます。
そのため、私たちは段階的な制御（摩擦）を導入する手法へ移行し、それをすべてUnity Gatewayで処理しています。まず警告を出し、次に承認を求め、作業を継続できるようより安価なモデルへとダウンシフトさせます。実際に利用を完全に停止するのは最終手段です。また、全員に自身の支出内訳と節約のアドバイスを定期的に送信しています。これだけでも約10%の削減効果があります。私の知っているある企業では、すべてのプルリクエストにモデル名とコストを明記しています。ちょっとした作業に高価なモデルを使うと、実質的に公 開羞恥を受けることになるわけです。とても面白いアイデアですね。
Catherine: あなたはこれらのコストを削減するための4つのレバーについて執筆されました。どれが最も大きな影響を与えましたか？
Patrick: 私たちが最も気に入っている方法は、至ってシンプルなものです。より優れ、より安価なモデルが続々と登場しているため、トラフィックをそれらに移行するのです。商用およびオープンソースのベンダーからは、毎週おそらく5つのモデルがリリースされています。すべてがコスト面での前進とは限りませんが、1〜2週間に1つ程度は進歩しています。これは全体の底上げとなります。誰も何も変更することなく、より少ない費用で同じアウトプットが得られます。複雑なルーティングも必要ありません。
この変化がいかに速いかをお伝えすると、最近の安価なモデルの1つは、約9か月前の最先端（フロンティア）モデルと同等のパフォーマンスを、タスクあたり約1%のコストで実現しています。1年未満で100分の1に下がったことになります。これはまだ初期段階の試算ですが、このような方向性に向かっています。
ポイントは、実際に移行しなければならないということです。新しいモデルが登場しても社内の誰も使っていなければ、意味がありません（誰もいない森で木が倒れるようなものです）。そのため、私たちは新しいモデルを迅速に評価し、十分な品質が得られればワークロードを速やかに移行するノウハウを 確立しました。すべてがUnity Gatewayを経由しているため、一箇所でその切り替えを行うことができ、開発者は何も変更する必要がありません。これが私たちが実施した中で最も効果的だった施策であり、これ単体で50%以上のコスト削減を実現しました。さらにルーティング、支出の可視化、トークンオーバーヘッドの削減を加えることで、場合によってはユニットコストを最大90%まで削減できました。
Catherine: あなたのチームは、Databricks自身の数百万行規模のコードベースを用いてコーディングエージェントのベンチマークを実施していますね。なぜ公開されているベンチマークをそのまま信用しないのですか？
Patrick: 公開ベンチマークは、自社のコードに関する情報をあまり教えてくれません。タスクが学習データに漏洩していたり、大規模なエンタープライズコードベースとは大きく異なっていたりするためです。そこで、リポジトリ内の実際のプルリクエストから独自のベンチマークを構築し、実際にテストを実行して評価しています。LLMを審査員（ジャッジ）として使わないのは、正しさよりもそれっぽく聞こえる回答を評価してしまいがちだからです。
いくつかの結果は驚くべきものでした。オープンソースモデルであるGLM 5.2は、Opus 4.8と同等の品質を達成しつつ、タスクあたりのコストは約3分の1に抑えられました。トークン単価が1.7倍安いモデルであっても、使用トークン数が多くなったためにタスクあたりの総コストが高くなったケースもありました。また、モデルを囲むコーディングツールである「ハーネス」の重要性もモデル自体と同等でした。同じモデルでもハーネスが異なるとコストに2倍以上の開きが生じます。ハーネスとキャッシュ設定をチューニングしただけで、50%近く削減できました。
Catherine: 最も安価なモデルと最も高価なモデルの差は100倍になることもあります。エンジニアリングリーダーはこの価格差をどのように捉えるべきでしょうか？
Patrick: 自動車に例えて考えると分かりやすいでしょう。ランボルギーニ、ホンダの乗用車、そして自転車があるようなものです。すべての移動にランボルギーニが必要なわけではなく、ほとんどのコーディング作業には最大のモデルは不要です。
Astraは良い例です。約3,500人の全エンジニアに展開しました。私たちが知る限り、このような展開を公に共有した最初の企業です。システム設計のような高難度の作業においては明らかに優れていました。しかし、支出は約60%増加し、既存のモデルで十分対応できる日常的なタスクに対して明確な効果は見られませんでした。その費用の多くは無駄であり、他のモデルを使うべき場面でAstraが使用されていました。そこで、Unity GatewayでAstraに専用の予算を割り当て、高難度な課題にのみ使用するようにしました。
長期的にはどのような方向に向かうかは分かりません。安価なモデルが ルーチンワークを代替し続ける一方で、人々はより高度で難解な問題をAIに投入するようになっています。それこそが本質であり、どちらの方向にも柔軟に舵を切れる状態にしておくことが重要です。
Catherine: あなたは、AIのコストは調達の問題ではなくインフラの問題であると主張されていますね。なぜ予算管理やポリシー設定だけでは解決できないのですか？
Patrick: 予算設定は役立ちますが、予算自体はどのリクエストをどのモデルで処理すべきかを判断できません。それが「ルーティング」です。コンポーネントのリネームのような簡単な作業は安価なモデルへ、高難度で直感的な解のない問題は高性能なモデルへと振り分けます。当社のSmart Routerは、最も高価なモデルと同等の品質を維持しながら、平均タスクコストを30%以上削減します。また、高価なモデルをいつ使うべきかをユーザー自身に判断させる必要がなくなり、自動的に最適化が行われるようになりました。
これを実現するには、開発者とモデルの間に管理レイヤーが必要です。私たちは必要に迫られて独自のものを構築しました。Claude Code、Codex、Cursor、あるいは当社のメタハーネスであるOmnigentのいずれであっても、すべてのコーディングツールのトラフィックが1つのゲートウェイを通過します。これにより、資金がどこに使われて いるかを実際に把握できるようになりました。その後、すべての顧客が同じ問題を抱えていることに気づき、製品化してUnity Gatewayとして提供しました。現在では数千社のお客様にご利用いただいています。
Catherine: ルーティング技術の競争は、モデル自体の開発競争と同じくらい激化するでしょうか？
Patrick: それが私たちの見解です。モデルのマージン（利益率）が薄くなるにつれて、どの用途にどのモデルを使うべきかを見極めることが非常に興味深い領域となっています。ルーティングモデルは小さく高速である必要があります。また、これを上手く機能させるのは簡単なことではありません。これらのモデルの活用に向けた実用面には未解決の研究課題が多く存在しており、正しく実装できればそこに真のIP（知的財産）があると考えています。
Catherine: 膨らみ続けるAIのコスト問題に直面しているCTOにアドバイスを1つ送るとしたら、何と伝えますか？
Patrick: コストがどこで発生しているかを把握することです。多くの企業では、チーム別やモデル別のAIの支出額を把握できておらず、それが成果につながっているかどうかも分からない状態です。モデルの手前にゲートウェイを配置して、すべてのトラフィックが1箇所を通るように可視化しましょう。それができれば、その後の対応はすべて容易になります。探求の手を緩めないでください。生産性の向上は間違いなく本物です。しかし、この効果やコストは急速に蓄積されるため、対策を後回しにすると、請求額は想像以上に大きなも のになってしまいます。
パトリックがエンジニアリングリーダーに伝えたいメッセージは、AIの生産性とコスト管理のどちらか一方を選択する必要はないということです。これを成功させている企業は、最高のモデルへの広範なアクセスを維持しながら、自社のコードで新しいモデルをテストし、実用レベルに達したらすぐに低価格なモデルへと移行し、開発者に制約（壁）ではなく可視性を提供しています。これらすべての基盤となるのが、AIへの支出を可視化・制御可能にする単一の管理層（ゲートウェイ）です。Databricksでは、その層がUnity Gatewayとなりました。
Databricksが自社のAIコーディング費用をどのように管理しているかの詳細は、パトリックのブログ「Managing AI Coding Costs at Scale」をお読みいただき、Databricks Unity Gatewayをぜひお試しください。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。