Databricks: Unity AI Gatewayの予算がコーディングエージェント支出をどう抑制するか
- Martin Chen
- 6 時間前
- 読了時間: 21分
Databricksは、毎月500〜1,000人の従業員が社内の支出上限に達するようになったことを受け、数千人のエンジニアによるコーディングエージェントの利用方法を変更した。現在、同社はClaude Code、Codex、Cursorなどのエージェントを1つのゲートウェイ経由で利用させ、日次と月次で別々の予算を設定している。
この設計は、急速に拡大するエージェント導入によって生じた対立に対応するものだ。DatabricksはエンジニアにAIを自由に使ってほしい一方、監視されていない自動化ループは、月間の利用枠を午後のうちに使い切る可能性がある。従来の月間上限では、生産的な作業と暴走したソフトウェアを同じ問題として扱っていた。
新しい仕組みは、より重要な考え方に基づいている。コスト管理は、人を日常的に止める前に、まず機械を止めるべきだというものだ。これは、固定のユーザー別上限、承認チケット、各コーディングツール内に個別に設けられた管理機能という従来モデルとは対照的である。
予算設計は、大規模なエンジニアリング組織におけるAIコストガバナンスを、異例なほど詳細に示している。ただし、その成果はあくまで同社の報告によるものであり、公開されている製品ドキュメントには、執行の詳細が不明な点も残る。
月間上限の失敗後にDatabricksが変えたこと
Databricksは、通常の需要と暴走した自動化は異なる時間軸で発生するため、単一の月間上限を連動する2つの管理手段に置き換えた。
同社は当初、すべてのエンジニアに標準の月間利用枠を割り当てていた。上限に達した従業員は固定単位で増額を申請し、特に大きな申請は手作業で審査された。しかも、増額はすべて恒久的なものだった。
この仕組みでは、毎月数百件の申請が発生した。利用量の多いユーザーは、1回の請求期間中に同じ手続きを何度も繰り返すことがあった。緊急作業に対応するエンジニアには、アクセスを直接回復する手段がなかった。
恒久的な増額は、その後のミスによる影響範囲も広げた。あるプロジェクトのために追加容量を必要としたエンジニアは、その作業が終わった後も容量を保持した。組織には、偶発的な利用に対する余地が大きいアカウントが徐々に蓄積していった。
より根本的な欠陥は構造的なものだった。午後いっぱい続く自動化障害を抑えられるほど小さい月間上限は、継続的なエンジニアリング作業には厳しすぎる。一方で、生産的なユーザーに十分な大きさの上限は、高速なループに対する保護としては弱い。
そこでDatabricksは、短期的な無駄と長期的な無駄を分離した。短期的な無駄には、予期せず多数のエージェントセッションを起動する自動化が含まれる。長期的な無駄には、高コストなワークフローを数日または数週間にわたって繰り返すケースが含まれる。
現在、前者は日次予算で扱われる。これは月間利用枠より意図的に低く設定され、社内で最も利用量が少ない時間帯にリセットされる。エンジニアは日次の境界に近づくと、アクセスを失う前にSlack通知を受け取ると同社は説明している。
従業員は、その活動が意図したものであることを確認できる。この操作により、承認申請をせずに日次利用枠がさらに1段階引き上げられる。同じ選択肢は社内ポータルとコマンドラインインターフェースにも用意されている。
月次予算は、継続的かつ例外的な利用を扱う。Databricksは、通常のエンジニアであれば到達しない程度に高い閾値を設定している。増額には、マネージャーが追加容量を特定の事業優先事項に結び付ける必要がある。
こうした月次の例外には期限がある。発表によると、Databricksは通常、1か月、3か月、または6か月の期間で割り当てる。その後、別の進行中プロジェクトが延長を正当化しない限り、従業員は標準レベルに戻る。
これにより、上限到達イベントの意味が変わる。日次の閾値到達は、その活動を人間が意図していたかを問う。月次の閾値到達は、組織がその基礎となるプロジェクトを引き続き支持しているかを問う。
この区別は重要だ。コーディングエージェントは、単一のプロンプトを超えて作業を続けられる。リポジトリを検索し、ファイルを編集し、テストを実行し、並列タスクを開始できる。そのため、エンジニアが別の作業に集中している間にも、利用量が加速する可能性がある。
Databricksは、実際の社内利用枠を公表していない。同社は、例で用いた数値は説明目的のものだと明示している。読者は、これらの例を他組織向けのベンチマークと見なすべきではない。
転用できるのは運用モデルである。短いリセット周期は突発的な異常を検知し、長い周期は継続的な需要を管理する。両者を連動させることで、どちらか一方に両方の責任を負わせずに済む。
Databricks: 2つの予算が1人のエンジニアをどう管理するか
中核となる仕組みは、現在の短期利用枠と承認済みの月間上限のうち、低い方を各エンジニアの上限とする。
日次予算と月次予算は、無関係な割り当てとして運用されるわけではない。Databricksは両者を固定比率で連動させている。マネージャーが従業員の月次ティアを引き上げると、対応する日次の増分も比例して引き上げられる。
この連動により、正当なプロジェクトに必要な余地を確保しつつ、暴走への保護を無意味にしない。安定して利用するエンジニアは日次の警告水準を下回るはずだが、急激な利用増は引き続き人間の確認を促す。
Databricksは、有効な境界を2つの値の最小値として説明している。一方は月間利用量に次の短期増分を加えたもの、もう一方は従業員に承認された月間総容量を示す。
その結果として発生するイベントは、次にどの対応が必要かをシステムに伝える。日次上限イベントはセルフサービスの確認で解決できる。月次上限イベントは、継続的な例外的消費を表すため、マネージャーに移される。
Databricksは、日次利用枠のおよそ90%でユーザーへの通知を開始する。メッセージには現在の利用量と残りの余裕が含まれる。従業員は、進行中のセッションがブロックされる前に上限を引き上げられる。
日次の確認回数に固定上限はない。意図的に負荷の高いワークロードを実行する人は、複数の増分を承認することがある。それぞれの確認は、監視されていないプロセスだけでは提供できない人間によるシグナルを与える。
この摩擦は小さいが、意図的に設けられている。増分が狭すぎれば、繰り返されるアラートは背景雑音になる。広すぎれば、注意を促す前に保護機能が許容する意図しない活動が多くなりすぎる。
同社は、安定した月間利用では通知が発生しないよう増分を調整したとしている。この主張は、利用可能なティア数より重要である。想定どおりの行動を繰り返し妨げるガードレールは、回避策や無差別な承認を招くだろう。
Databricksは、グループメンバーシップを通じてティアを実装している。全員が基本レベルから始まり、より上位のグループに入ると適用される閾値が変わる。これにより、個人に紐付く恣意的な値の集合が膨らむのを避けられる。
日次ティアの移動は、ほぼ自動化されている。スケジュールされたプロセスは、利用量が現在の上限に近づくと対象者を昇格できるが、1日に1回に限られる。別のプロセスが、月末に全員を基本レベルへ戻す。
月次ティアは別の経路で変更される。マネージャーは多数の細かな調整を交渉するのではなく、少数の大まかなレベルから選ぶ。Databricksによると、上位レベルは基本レベルのおよそ2倍、5倍、そして実質的に無制限の選択肢となる。
大まかな構造は、事業価値に関する判断を促す。マネージャーは小さな申請を何度も処理する代わりに、プロジェクト規模の例外を承認する。有効期限によって、一時的な作業が恒久的なリスクを生むことも防ぐ。
この仕組みは、本番環境の信頼性における重要な考え方を借りている。システムでは、突発的な異常と継続的なリソース圧力を区別することが多い。両者には異なる対応が必要だからだ。コーディングエージェントのガバナンスにも、同じ分離が必要になっている。
日次アラートは異常検知器に似ている。月次レビューは容量計画に似ている。両者を組み合わせることで、単一の固定上限より有用な情報が得られる。
このアプローチは、インシデント時のエンジニアに逃げ道も与える。顧客の問題を調査する従業員は、意図した活動であることをすぐに確認できる。これにより、本番作業がブロックされたまま中央委員会を待つ必要がなくなる。
とはいえ、セルフサービスは無制限の支出と同義ではない。すべての確認は、IDに紐付いた観測可能なイベントとなる。繰り返される確認は、ワークフロー、ルーティング、プロジェクト予算に対する後の変更に役立てられる可能性がある。
1つのゲートウェイがベンダーコンソール群を置き換える
Databricksが単一のポリシーを適用できるのは、サポート対象のすべてのコーディングエージェントが、共通の制御点を経由してモデルへのトラフィックを送るからだ。
個別のツールにも管理機能はすでにある。AnthropicはClaude Code向けに組織およびユーザーレベルの支出上限を提供し、OpenAIはCodex向けにユーザーおよびワークスペースの上限を提供している。しかし、エンジニアが複数の製品を使うと、こうした管理機能を整合させるのは難しくなる。
Databricksによると、同社のエンジニアはClaude Code、Codex、Cursorなどのエージェントを組み合わせて使うことが多い。複数を同時に使う人もいる。あるベンダーのコンソール内にある上限では、別のベンダー経由で発生した利用を把握できない。
Unity AI Gatewayは、それらのクライアントと呼び出されるモデルの間に位置する。ゲートウェイは各従業員を認証し、リクエストを計測し、どのモデルが作業を処理したかを記録する。これにより、予算はツールをまたいでユーザーに追随できる。
同社によると、ゲートウェイはClaude、GPT、Gemini、オープンソースモデルを対象とするリクエストを処理する。管理対象の構成を使用するエンジニアは、マシン上に個別のプロバイダーキーを持つ必要がない。Unity Catalogが、各モデルサービスにアクセスできるユーザーを決定する。
このルーティング層は、分断された利用を1つのポリシー面に変える。ゲートウェイは、ユーザーに適用されるすべての予算を確認してから、追加の活動を許可する。また、マネージャーと財務部門向けに統合された利用記録も生成する。
coding agent tutorialでは、公開設定はベータ機能として説明されている。管理者は外部エージェントをゲートウェイエンドポイントに接続するよう構成し、その後に権限、レート制限、支出管理を適用する。
レート制限と予算は、異なる問題を解決する。レート制限は短い時間間隔におけるリクエスト数またはトークン量を制御する。予算は、モデルの選択や各リクエストの規模に応じて変動する金銭的な消費を追跡する。
IDは両方に不可欠だ。共有APIキーでは、生産的なエンジニアと障害を起こしたバックグラウンドプロセスを区別するのが難しい。ユーザー単位の認証により、ゲートウェイは利用を帰属させ、個別の閾値を適用できる。
中央集約型のルーティングは、Databricksにモデル最適化への道も与える。将来のルーターは、日常的な作業をより効率的なモデルへ送り、負荷の高いタスクには最先端モデルを割り当てる可能性がある。同社によると、そのようなルーティングは開発中である。
この計画は、より広い競争圧力を浮き彫りにする。コーディングエージェントのベンダーは独自の分析機能や管理機能を次々と提供しているが、顧客が1つのエージェントだけに標準化することはほとんどない。利用が複数のプロバイダーにまたがる場合、企業にはツール層より上位のガバナンスが必要となる。
Googleは、Cloud Monitoringを通じてGemini Code Assistのアクティビティも報告している。指標には、アクティブユーザー数、受け入れられた提案、API呼び出し、トークン数が含まれる。ただしGoogleは、一部の測定値がIDE内のアクティビティのみを対象としていると指摘している。
こうしたネイティブコンソールは、製品固有のシグナルを可視化するため、引き続き有用だ。一方、中央ゲートウェイには、クライアントやモデルをまたいで一貫した帰属を実現できるという別の利点がある。多くの組織に必要なのは、単一の万能ダッシュボードではなく、この両方のレイヤーだろう。
Databricksのモデルは、権限をどこに置くべきかという判断をプラットフォームチームに迫る。各ベンダーのコンソールが独立したままであれば、ポリシーは乖離し、財務部門には同じエンジニアリング機能について複数の見解が提示されることになる。
すべてのトラフィックをゲートウェイ経由にすれば、組織は一貫した統制を得られるが、そのゲートウェイの可用性と設定に対する責任も負う。ルーティングのエラーは、参加するすべてのエージェントに同時に影響を及ぼしかねない。
これが本稿における主な対立軸だ。すなわち、断片化したベンダーごとの統制と、中央集約型でアイデンティティベースのガバナンスである。Databricksが中央集約を選んだのは、同社のエンジニアがすでに製品の境界を横断していたためだ。この選択により、ポリシーは単に文書化されるだけでなく、実際に執行可能になる。
同様のワークフローを構築するエンジニアリング組織にとって、検索可能な技術ナレッジベースは、承認済み例外の背景にある判断を残す助けになる。コスト記録だけでは、高額なエージェントセッションがなぜ重要だったのかを説明できない。
セルフサービスはチケットをなくしても説明責任まではなくさない
Databricksは、日々の上限到達イベントの大半を正当な業務として扱い、異常な消費は承認キューから始めるべきだという前提を覆している。
ここがこの設計で最も興味深い点だ。多くのコスト管理システムでは、作業を続ける前に、ユーザーが追加消費の価値を証明しなければならない。これに対しDatabricksは、短期的な増額には確認を求める一方、承認は継続的な例外に限定している。
このポリシーは、中断のコストを反映している。チケットは管理者の時間を消費するだけではない。エンジニアのワークフローも分断し、デバッグ、テスト、インシデント対応を遅らせる可能性がある。
Databricksによると、通常の月には500〜1,000人のエンジニアが従来の月間上限に達していた。この頻度では、承認は意味のあるレビューではなく、日常的な運用業務になる。繰り返される申請は、本当に例外的なケースの特定も難しくする。
代替となるワークフローでは、日次の境界で求める根拠を少なくしている。1回の操作で、本人が消費を認識し、継続を望んでいることを確認する。このシグナルは、意図的な作業の再開を許しつつ、放置されたソフトウェアを止める。
自動化ループはSlack通知をクリックできない。cronジョブも、社内ポータルを開いて現在の消費が意図したものだと確認することはできない。したがって人間による確認は、自律的なアクティビティを特に対象とする、控えめな障壁となる。
この障壁は行動面のものであり、技術的に絶対的なものではない。エンジニアは、根本的な手法を改善しないまま高額な作業を繰り返し承認できる。そのため、月間上限には依然として管理職の判断が必要となる。
管理職は、すべての急増をレビューするわけではない。その代わり、通常を超える消費が継続することが重要なプロジェクトに属するかを判断する。例外はその作業に紐付けられ、承認期間が終わると失効する。
この分離により、従業員にオーナーシップを与えながら、予算に関する意思決定のすべてを移管せずに済む。エンジニアは短期的な継続性を管理し、管理職は通常範囲からの長期的な逸脱を管理する。
このモデルは、チームが自らのテクノロジー利用に責任を持つべきだというFinOpsの原則に沿っている。FinOps AI frameworkも、きめ細かなデータ、予測不能な支出、クロスプラットフォームでの配賦を、AIに特有の課題として挙げている。
ただし、説明責任には閾値以上のものが必要だ。管理職には、どのリポジトリ、ワークフロー、タスク、モデルが消費を生み出したかという文脈が必要になる。月間合計だけでは、その作業が時間を節約したのか、あるいは使えない出力を繰り返し生成したのかを示せない。
Databricksによると、ゲートウェイの利用データはUnity Catalogに記録され、社内分析に用いる同じLakehouseテーブルに表示できる。これにより、コストとエンジニアリングメタデータを結び付ける基盤が得られる。同社は完全な投資対効果の算定方法を公開していない。
この省略は理解できるが、重要でもある。チケット量の削減は、新しいワークフローが管理上の摩擦を減らしたことを示す。しかし、追加されたすべてのエージェントセッションが、それに比例したエンジニアリング上の価値を生むことの証明にはならない。
同社はまた、エンジニアが利用を節約しなくなったとしている。これは社内の観察であり、独立して測定された生産性の結果ではない。利用拡大は、有益な委任、実験、あるいは回避可能な反復を意味し得る。
したがって、成熟したプログラムでは支出と並行して成果も追跡すべきだ。関連するシグナルには、受け入れられた変更、完了したタスク、差し戻されたコード、レビュー工数、インシデント解決、ワークフロー別のモデル利用などがある。
これらの測定にも限界がある。受け入れられた行数は冗長さを報いる可能性があり、タスク数は難易度を隠しかねない。成果あたりのコストは、組織が成果を慎重に定義して初めて有用になる。
Databricksは、すべての測定上の問いを解決する前に、執行レイヤーを構築した。この順序は、無制限の消費が導入を直ちに妨げ得るため、擁護可能である。ただし、暴走コストへの恐れが薄れるにつれ、価値に関する問いはより重要になる。
公開製品にはなお執行上の疑問が残る
Databricksは実証済みの社内パターンを提示しているが、顧客はそのパターンと、すべての公開ワークロード向けに現在文書化されている正確な統制を区別すべきだ。
7月28日の発表では、Unity AI Gatewayにおけるコーディングエージェントのサポートが、すべてのDatabricks顧客に提供されているとされる。また、日次予算、一時的なオーバーライド、ユーザー主導の閾値引き上げは、将来の製品開発に影響を与える社内メカニズムとして説明されている。
この表現は重要だ。同社の次のステップの一覧には、ネイティブの日次予算サイクル、期限付きオーバーライド、セルフサービスによる増額の権限モデルが含まれている。そのため、社内ワークフローの一部はゲートウェイ周辺の自動化に依存しているように見える。
発表前に更新された公開予算ドキュメントは、主に月次支出に焦点を当てている。また、追跡、オーバーライド、利用ブロックに影響する制約も列挙している。
たとえばドキュメントでは、外部モデル推論とプロビジョニング済みスループットは、現時点ではこれらの予算で追跡されないとしている。また、そのページでは、ユーザーごとのオーバーライドとブロックはGenie予算でのみ利用可能だと説明している。
別のベータ版チュートリアルでは、管理者がゲートウェイ全体の支出予算を設定し、コーディングエージェントの利用をブロックできるとしている。これらのページは、異なるロールアウト段階、クラウド環境、または機能構成を説明している可能性がある。本番の統制を設計する顧客のために、Databricksは境界を明確にすべきだ。
ニアリアルタイムの執行では、一定の超過も許容される。ドキュメントは、閾値に達した後も進行中のリクエストが完了する可能性があると警告している。ブロックが有効になるまでに短い遅延が発生することもある。
この挙動は従量制システムでは一般的だが、エージェントはリスクを複雑にする。1回のユーザー操作が複数のモデル呼び出しを生み出す可能性があり、同時セッションでは複数のリクエストがアクティブなままになり得る。組織は完全に厳格な境界を前提とせず、最悪ケースの影響をテストすべきだ。
レポートの遅延は、別の違いを生む。Databricksによると、執行にはニアリアルタイムの追跡を用いる一方、請求システムテーブルの更新には数時間かかる場合がある。したがって、アラート、ダッシュボード、SQLクエリは、同じ時点でも異なる合計値を表示し得る。
このタイミングの差はインシデントレビューに影響する。財務クエリに対応する行が現れる前に、エンジニアが警告を受けるかもしれない。運用手順では、即時判断をどの画面で行うかを定めるべきだ。
中央ルーティングは、完全なカバレッジにも依存する。エンジニアが直接のプロバイダーキー、未対応の統合、別の請求経路を使えば、ゲートウェイの可視性から逃れられる。アーキテクチャが機能するのは、アイデンティティとルーティングのポリシーがこうした代替手段を防ぐ場合に限られる。
Databricksによると、同社の社内コーディングエージェントトラフィックはすべてゲートウェイを通過している。顧客は自らの環境でもこの条件を検証する必要がある。トラフィックの大半を対象とするポリシーは、残りの部分について誤った安心感を生みかねない。
セルフサービスによる確認には、独自の失敗モードもある。特に締め切りが迫る場面では、頻繁なアラートが従業員に反射的な承認を習慣付ける可能性がある。Databricksはこの調整上の問題を認識しているが、社内で用いている閾値の計算式は公開していない。
組織ごとに個別の調整が必要になる。モデル価格、勤務時間、プロジェクトの形態、エージェントの振る舞いはチームごとに異なる。対話的な開発に適した閾値は、スケジュールされたテスト生成や移行作業には不適切かもしれない。
プライバシーや労働に関する懸念にも注意を払うべきだ。ユーザーごとの支出記録はコスト配賦を支援できるが、単純化された従業員の業績評価スコアにしてはならない。高い消費は難しい業務を反映している可能性があり、低い消費は効率的な作業や導入の限定性を反映している可能性がある。
最も安全な解釈は限定的なものだ。Databricksは信頼できる統制パターンを説明し、承認に伴う摩擦が減ったと報告している。しかし、普遍的な予算比率や、独立して検証された生産性向上を確立したわけではない。
顧客はまず観察から始め、通常の利用分布を把握し、管理されたワークロードで執行をテストすべきだ。また、財務上の境界として依存する前に、どのリクエスト種別が各予算に算入されるかを確認する必要がある。
このモデルが拡張可能かを示す3つのシグナル
次の試金石は、Databricksが取り除いた摩擦を再現することなく、社内自動化を明確でネイティブな製品統制へと変えられるかどうかだ。
第1のシグナルは、日次予算サイクルとセルフサービスによる増額へのネイティブサポートだ。Databricksは、これらの機能が製品ロードマップに反映されているとしている。実装されれば、社内ワークフローを再現するために必要なカスタム自動化を減らせる。
機能名よりも詳細が重要になる。顧客には、設定可能なリセット時刻、アイデンティティを考慮した通知、監査可能な確認、明確な権限が必要だ。また、複数のリクエストが同時に閾値を超えた場合の予測可能な挙動も求められる。
これらの統制が一貫したドキュメントとともに提供されれば、Databricksはゲートウェイレベルのガバナンスに関する主張を強化できる。社内スクリプトや限定プレビューに依存したままであれば、このパターンは顧客にとって採用しにくくなる。
第2のシグナルは、一時的な月間オーバーライドだ。有効期限は同社の主張の中心にある。なぜなら、1つのプロジェクトが将来のエクスポージャーを恒久的に拡大することを防ぐからだ。プロジェクト単位のネイティブな例外は、この原則を再利用可能な統制へと変える。
有用な実装では、承認した管理職、事業上の根拠、有効期間、影響を受けるアイデンティティグループを記録すべきだ。また、別のチケットを必要とせずに自動的に元へ戻る必要がある。
Databricksがこのライフサイクルを提供すれば、ゲートウェイは単なる従量計測レイヤーを超える。エンジニアリング、財務、管理職がエージェント消費への責任をどう分担するかを、エンコードし始めることになる。
第3のシグナルは、より賢いモデルルーティングだ。Databricksは、通常のタスクには効率的なモデルを使い、難しい作業にはフロンティアシステムを確保したいとしている。これにより、予算の境界が介入する前に高コストのワークフローへ対処できる。
ルーティングには信頼できる評価が必要になる。より安価なリクエストでも、再試行、レビュー作業、欠陥コードが増えるなら価値はほとんどない。Databricksは、トークン消費だけでなく、モデル選択とタスク成果を結び付ける必要がある。
成功すれば、同社の中核的な論点を裏付けることになる。ガバナンスは、消費の発生の仕方を形作りながら導入を促進できる可能性がある。一方、ルーティングの成果が不十分なら、非効率な判断がすでに下された後で、予算は症状の管理に追われることになる。
市場全体も反応するだろう。OpenAI、Anthropic、Googleは、利用状況の分析、上限設定、エンタープライズ管理機能を引き続き追加している。単一のプロバイダーに注力する組織にとっては、各社のネイティブな制御機能で十分になるかもしれない。
複数のツールが混在するエンジニアリング環境では、別のニーズが生じる。こうしたチームには、クライアントやモデルをまたいでアイデンティティに追随するポリシーレイヤーが必要だ。Databricksは、Unity AI Gatewayをその役割に位置付けている。
エンジニアリング部門のリーダーは今、自社のエージェントトラフィックを検証すべきだ。どれだけのツールが消費を生み出しているのか、自律ループはどれほど速くエスカレートし得るのか、そしてどの例外には即時のセルフサービス復旧がふさわしいのか。
Databricksのハウツーは実践的な出発点を示すが、その中心的な教訓は組織運営にある。短期的な異常と長期的な投資判断を、同じ承認メカニズムで扱うべきではない。
ネイティブの日次制御、有効期限付きのオーバーライド、成果を考慮したルーティングが、約束どおり導入されるかを注視したい。これらの兆候を総合すれば、Databricksが移植可能なガバナンスモデルを構築したのか、それとも効果的な社内カスタマイズにとどまったのかが見えてくる。
