Databricks、Unity AI Gateway Budgetsでコーディングエージェント支出を管理する方法

Databricksでは、ソフトウェア開発の方法が急速に変化しており、エンジニアリングへのAI導入が積極的に進められています。毎日何千人ものエンジニアがClaude Code、Codex、Cursorなど複数のコーディングエージェントを併用しています。この導入は素晴らしいことですが、新たな問題も生み出しました。コーディングエージェントへの支出はR&Dの中で最も急成長している項目の一つであり、暴走した自動化ループが午後一ヶ月分の予算を消費することもあります。

本記事では、Databricksがこの問題にどのように内部で対処したか、そして顧客に提供しているUnity AI Gateway Budgetsを自社でも活用しているかを紹介します。Databricksでは、すべてのコーディングエージェントがツールやモデルに関係なくゲートウェイを経由するため、個別の管理コンソールを触らずに全社で統一された支出ポリシーを適用できます。

今回の展開から得られた主な教訓は以下の通りです。暴走支出の防止と月間支出制限は分離すべきであり、それぞれ異なるリセットサイクルが必要です。ほとんどの制限到達は問題ではなく、通常のエンジニアの通常の作業であるため、解除は自己サービスで行えるべきであり、承認キューにすべきではありません。承認は本当に例外的なケースに限定し、時間制限を設けることで、一時的なプロジェクトが恒久的な権限にならないようにします。これらはすべて、エージェントトラフィックが一つの制御ポイントを通過する場合にのみ機能します。

当初は月間制限のみを設定していました。各エンジニアにデフォルトの月間制限（例：500ドル）を設け、超過すると制限引き上げを申請する仕組みです。しかし、この戦略は摩擦を生みました。同じ制限が暴走防止も兼ねていたため、引き上げも同じ500ドル単位で行われ、ヘビーユーザーは毎回新たな申請が必要でした。さらに、引き上げは永続的で、高額プロジェクトの後も大きな制限が残り続けました。また、緊急時の対策がなく、トラブル対応などでAIを使いたいときに妨げになりました。

再設計の前に、AI支出に関する原則を二つにまとめました。第一に、一般的には承認やエスカレーションなしでエンジニアが自由に支出できるようにする。第二に、無駄を避ける。無駄には、短期的な暴走支出と長期的な過剰支出の二種類があります。

解決策として、Unity AI Gatewayに二つの予算を設定しました。日次制限は暴走支出をキャッチするためのもので、意図的に月間制限より小さく設定されています。到達するとSlack通知が届き、支出が意図的であることを確認するボタンを押すだけで制限が自動的に増加します。承認やチケットは不要です。月間制限は異常な支出を管理するためのもので、通常のエンジニアはまず到達しません。到達した場合、マネージャーの承認が必要で、プロジェクト期間に限定されます。

自己サービス確認ワークフローでは、日次制限の約90%に達するとSlack通知が届き、確認ボタンを押すと即座に制限が一段階上がります。同日に複数回の確認も可能です。層別設定により、日次層は自動的にリセットされ、月次層はマネージャー承認でプロジェクト単位で設定されます。

Unity AI Gatewayを通じて、すべてのコーディングエージェントからのリクエストがユーザーIDに紐づけられ、一元計測されます。予算は適用されるすべての予算の最小値で制限されるため、二つの制限が同時に機能します。データはUnity Catalogに蓄積され、管理者はチーム単位の支出を確認でき、財務部門も一つの請求書で済みます。

結果、中断を引き起こす承認キューはなくなりました。新モデルでは、月に日次制限に達するのはごく一部のヘビーユーザーだけで、それぞれ一回の確認クリックで解決します。月間制限の引き上げは、恒常的な作業から稀なプロジェクト単位の決定に変わりました。何より、エンジニアはAI利用を制限しなくなりました。ガードレールの目的は使用量削減ではなく、コストへの恐れを取り除いて導入を促進することでした。

次のステップとして、利用パターンの変化に合わせて数値を調整し、内部で有効だったパターンをBudget製品にフィードバックしています。また、よりスマートなモデルルーティングにより、日常業務には効率的なモデルを、高度なタスクにはフロンティアモデルを割り当てることで、高コストな経路を減らす取り組みも進めています。