# 大規模なAIコーディングコストの管理：Databricks共同創業者に聞く

- 番組: [Software Engineering Daily](https://ai-curator.jp/podcasts/shows/cmv3z5c1c000w5o10bjjhgahi)（Software Engineering Daily）
- 元のタイトル: Managing AI Coding Costs at Scale
- 配信日: 2026年10月27日
- 長さ: 1時間1分
- 要約作成日: 2026年10月27日
- トピック: [#AIコスト管理](https://ai-curator.jp/topics/AI%E3%82%B3%E3%82%B9%E3%83%88%E7%AE%A1%E7%90%86) [#LLMルーティング](https://ai-curator.jp/topics/LLM%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0) [#AIゲートウェイ](https://ai-curator.jp/topics/AI%E3%82%B2%E3%83%BC%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A4) [#コーディングエージェント](https://ai-curator.jp/topics/%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#エンタープライズAI](https://ai-curator.jp/topics/%E3%82%A8%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%97%E3%83%A9%E3%82%A4%E3%82%BAAI) [#セキュリティ](https://ai-curator.jp/topics/%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3)
- URL: https://ai-curator.jp/podcasts/cmvqh0k1c00006u10j2u694hy

## 要約

Databricks共同創業者のPatrick Wendellが、数千人のエンジニアにAIツールを展開する中で急増したコストをどう抑えたかをKevin Ballと語った回。モデル価格の下落の活用、動的ルーティング、自前の評価基準、AI Gatewayによる集中管理が柱となる。次の課題は、企業固有の文脈をAIに与える「ナレッジ層」の構築だと述べている。

## ポイント

- Opus 4.5前後からコーディングAIが実用水準になり、従量課金への移行も重なって、Databricksのコストは2か月ごとに倍増する勢いになったという。
- 最大のレバーはモデル価格の継続的な低下で、複数モデルをすぐ切り替えられる体制が重要だと述べている。
- 定型作業には安価なモデルで足りるため、デフォルトを安いモデルにし、タスク単位やリクエスト単位の動的ルーティングを使っている。リクエスト単位ではKVキャッシュの扱いが難しい。
- 新モデルは自社コードベースを使ったオフライン評価で素早く検証し、モデルとハーネスの組み合わせで評価する。異なるモデル同士でコードを書かせレビューさせると質が上がるとも語った。
- 全トークンと社内データへのアクセスをAI Gatewayに通し、ログ、コスト管理、ゼロリテンション、挙動に基づく動的リスク評価、サンドボックス化を行っている。
- 次の課題は企業固有の文脈をAIに与えるナレッジ層（オントロジー）で、スキルの手作業管理はYahooディレクトリ的でスケールしないという見方を示した。

## 章立て

- [02:04] **Patrickの経歴とDatabricksのAI活用** — UCバークレー発のDatabricksの成り立ちと、数千人規模のエンジニアへのAI展開という立場が紹介される。
- [04:04] **AIコストはなぜ爆発したか** — 導入促進の時期から、コーディングAIの性能向上と従量課金の組み合わせで指数的にコストが増えた経緯を説明する。
- [09:00] **価格低下とモデル性能の進化** — コスト対品質の曲線が動くことの恩恵と、なぜ需要が飽和しないのかを議論する。
- [15:00] **モデル選別と動的ルーティング** — デフォルトの引き下げ、劣化したモデルの除外、タスク単位や細粒度のルーティングとキャッシュの課題を語る。
- [23:55] **ゲートウェイとクライアントでの制御・評価** — サーバー側とクライアント側の制御の使い分け、マルチハーネス、自社コードでのオフライン評価を紹介する。
- [31:00] **言語選択とコード設計の影響** — PythonがLLMに強いことや、検証しやすい小さなインターフェース設計の利点について直感を述べる。
- [36:18] **AI Gatewayとセキュリティ** — 全トークンの集中管理、ゼロリテンション、OAuthの限界、挙動ベースのリスク評価、サンドボックスを説明する。
- [49:40] **次の課題：企業のナレッジ層** — コーディング以外の業務ではAIに文脈が不足している点を挙げ、スキルの限界と検索的アプローチの必要性を論じる。

## 解説記事

Software Engineering Dailyのこの回では、Databricks共同創業者のPatrick Wendellが、同社でAIコーディングツールのコストを制御してきた経験をKevin Ballと語った。彼が書いたブログ記事はHacker Newsの首位に届いたという。使用を締め付けるのではなく、仕組みでコストを抑えるという姿勢が一貫している。

#### なぜコストは急増したのか

Wendellによれば、2023年から2025年初頭は、社員にAIをもっと使わせることが課題だった。ところがOpus 4.5あたりでモデルのコーディング能力が大きく向上し、CodexやClaude Code、Cursorなどのハーネス（モデルを動かす実行環境）が成熟すると、問題は逆転した。さらに各社が席単位の定額から従量課金へ移行したことで、Databricksでは2か月ごとにコストが倍増するような指数的な伸びが見えたという。数千人の開発者がいる会社では急速に積み上がり、放置すれば会社を傾けかねないと述べている。定額プランでは提供側が赤字になりかねず、従量課金は自然な帰結だという見方も示した。

#### 最大のレバーはモデル価格の低下とルーティング

同氏が最も大きいとするのは、モデルの価格性能曲線（パレートフロンティア）が継続的に動くことだ。新モデルが同等の性能をより安く提供するので、20%の削減でも大量のトークンでは大きい。そのためにはモデルをすぐ切り替えられる体制が要る。

定型的なリファクタリングなどには旧世代の安いモデルで十分なことが多い。ただし個々の開発者は最高性能に設定しがちなので、デフォルトを安いモデルにし、必要なら上げられる形にしている。あわせて、新モデルが高価で品質も低いと評価で判明した場合は提供しない判断もした。さらにタスク単位やリクエスト単位で動的にモデルを振り分けるルーティングを使う。リクエスト単位は負荷分散に似て強力だが、キャッシュ読み取りが安いためキャッシュを手放すコストとの兼ね合いが難しく、研究余地が大きいと語った。振り分けの判定自体も、分類器としてのモデルを学習させる方向で取り組んでいる。

#### ゲートウェイ対クライアント、そして評価

ルーティングはサーバー側のゲートウェイと、クライアント（ハーネス）側の両方で行っている。ゲートウェイは古いクライアントでも使え、社員が設定を回避する余地も小さく、暴走した支出の遮断もしやすい。一方クライアントはセッション履歴などの文脈をより多く持つ。さらにオープンソースのOmnigentのようなマルチハーネスのディスパッチャを使えば、あるモデルが書いたコードを別のモデルにレビューさせることもできる。自分の出力には甘くなりがちなので、品質面でも利点があるという。

モデルの品質評価では、以前は全開発者に展開して不満が集まるのを待ち、数週間を無駄にしたことがあった。そこで自社コードベースの過去のスナップショットを使ったオフライン評価を作り、新モデル公開から1時間程度で候補かどうかを判断できるようにしたという。モデルとハーネスの組み合わせで結果が大きく変わる点も強調した。

#### AI Gatewayによる集中管理とセキュリティ

Databricksはツールやモデルの選択は社員に委ねつつ、守るべき点を三つに絞る。全トークンをAI Gatewayに通すこと、社内データへのアクセスをプロキシ経由にすること、モデル提供側にゼロリテンション（データを保持しない）を求めることだ。ゲートウェイではコスト分析やログに加え、セキュリティも担う。OAuthのスコープは粗く静的なので、クレジットカードの不正検知のように、エージェントの挙動を動的にリスク評価する必要があるという。例えばGoogle Driveの大量ダウンロードを検知して遮断し、担当者に確認するといった運用だ。これに加えてネットワークのサンドボックス化も行い、今のところエージェントの脱出は確認されていないと述べた。この仕組みはUnity AI Gatewayとして製品化されている。

#### 次の課題：企業固有の文脈

コスト管理が落ち着いた今、Wendellが最も注力するのは、AIに必要な文脈を与えることだ。コードベースは自己完結していて検証もしやすく、Gitにはアクセス制御がないという偶然も重なり、AIに向いていた。しかし、Slack、データウェアハウス、文書、暗黙知が散らばる一般業務ではそうはいかない。社内用語のDBUの定義が財務と製品で食い違う例も挙げた。人手で書くスキルは古くなり矛盾も生じるため、Yahooディレクトリのような段階にあり、Google検索のように新しさや権威性といったシグナルで動的に学ぶ方向が必要だという見方を示した。

#### まとめ

日本の企業でもAI導入は「使わせる」段階から「費用対効果を管理する」段階に移りつつある。本回の示唆は、複数モデルを切り替えられる設計、自社コードに基づく評価、ゲートウェイでの一元的なコストとセキュリティ管理の三点に整理できる。ただし本人も、すべての答えを持っているわけではなく実験を続けていると述べており、各社の事情に合わせた検証が前提になる。次の焦点は企業固有の知識をどうAIに届けるかであり、権限管理を含めた設計が今後の差になりそうだ。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Software Engineering Daily「Managing AI Coding Costs at Scale」