によって Rohit Agrawal, Shuyu Cao, Darming Zhao, Zack Siegel 、 アーロン・デビッドソン による投稿
• Databricksでは、すべてのコーディングエージェントをUnity AI Gateway経由でルーティングすることにより、AI支出を大規模に管理しています。これにより、チームはすべてのモデルとツールにわたって、予算、可視性、ポリシーを適用できる一元化された場所を確保できます。
• 当社では、日次と月次の個別予算を使用してAI支出の暴走を防ぐと同時に、承認のボトルネックをなくし、セルフサービスでの予算増額によってエンジニアの生産性を維持することで、イノベーションとコスト管理のバランスを両立させています。
• この実績のあるガバナンスモデルは、中央集中型の支出管理、統合されたオブザーバビリティ、データ駆動型のポリシー適用を組み合わせることで、開発者の作業スピードを落とすことなく、AIの導入を拡大します。
Databricksでは、エンジニアリングへのAIの積極的な導入に伴い、ソフトウェア開発の手法が急速に変化しています。何千人ものエンジニアが毎日コーディングエージェントを使用しており、Claude Code、Codex、Cursorなどを、時には複数同時に組み合わせて使っています。この導入は素晴らしいことですが、新たな問題も生じています。コーディングエージェントの費用が、現在R&Dにおいて最も急速に増加している項目の一つとなっており、自動化ループが1回暴走するだけで、午後のうちに1ヶ月分の予算を使い果たす可能性があるのです。
本記事では、お客様に提供しているものと同じ Unity AI Gateway Budgetsを使用して、この問題を社内でどのように解決したかをご紹介します。Databricksのすべてのコーディングエージェントは、ツールやモデルに関係なく、トラフィックが当社のゲートウェイを経由するため、個々のコーディングエージェントの管理コンソールを操作することなく、組織全体に単一の支出ポリシーを適用できます。
これを導入して得られた主な教訓は以下の通りです。
どのようにしてこの解決策に至ったのか、詳しく見ていきましょう。
注：本記事に記載されているドルの数値は例示であり、実際の社内数値ではありません。
コスト管理の取り組みを始めた当初、設定した制限は1つだけでした。すべてのエンジニアにデフォルトの月次支出制限（例えば500ドル）を設定し、それに達した場合は引き上げ申請を行うというものです。これは机上では合理的に思えますが、実際にはあらゆる場面で摩擦が生じることがわかりました。
この制限が暴走支出に対する唯一の防御策でもあったため、制限の引き上げも毎回同じ500ドル刻みで行われました。ヘビーユーザーは新しい制限に達するたびに、時には月に何度も新しい申請を行う必要があり、2,500ドルを超える引き上げには手動での審査が必要でした。 さらに悪いことに、引き上げはすべて恒久的なものでした。高額なミスを一度犯したエンジニアや、支出の多いプロジェクトに携わったエンジニアは、大きな制限枠を無期限に保持することになり、高額なミスのリスクにさらされる 社内の割合が静かに増加していきました。さらに、緊急時の例外プロセス（break glass process）がなかったため、顧客のインシデントをAIでデバッグするような、一刻を争う重要なタスクにおいて、エンジニアが自らブロックを解除する手段がありませんでした。
当社の規模では、毎月500人から1,000人のエンジニアが制限に達していました。これは、何百ものチケット、何百回もの作業の中断、そして不満の溜まった#ai-devtools Slackチャンネルを意味していました。
設計を始める前に、AIの支出について私たちが実際に考えていることを書き出しました。それは次の2つの原則に集約されます。
これを書き出したことで、矛盾が 浮き彫りになりました。暴走支出を捉えるためには、数時間の事故で制限に達するほど制限枠を小さくする必要があります。しかし、それほど小さな制限枠では、通常の月次利用が常に中断されてしまいます。単一の数値で両方の役割を果たすことはできません。
私たちはシンプルな原則に基づいて再構築しました。それは、エンジニアには自由に支出させ、実際に問題となる2種類の無駄（短期的な無駄と長期的な無駄）に対してのみ介入するというものです。
これら2つの失敗モードに対する解決策は、Unity AI Gatewayにおける2つの予算に対応しています。
暴走支出を捉えるための日次制限。この制限は、月次支出に比べて意図的に小さく設定されています。エンジニアがこれに達しても、何かが間違っているとは仮定しません。Slack通知が届き、支出が意図的なものであることを確認すると、制限が自動的に一定量引き上げられます。承認もチケットも待ち時間もありません。支出が事故であった場合、その通知はまさに必要なアラームとなります。日次予算は、利用者が最も少ない時間帯である毎晩リセットされ、毎月初めに完全にクリアされます。
例外的な支出を管理するための月次制限。この制限は、一般的なエンジニアが遭遇しないほど十分に高く設定されています。これを超えるということは、他のメンバーよりも大幅に多くの支出を求めていることを意味します。それは問題ありませんが、特定のビジネス上の優先事項に関連している必要があります。これらの引き上げは、中央の承認委員会ではなくマネージャーの承認を経て行われ、際限のない細かな引き上げではなく、いくつかの大まかな階層（ティア）で提供されます。そして極めて重要なことに、プロジェクトの期間に限定されます。プロジェクトが終了すると、制限は元に戻ります。
これら2つの制限は、固定された比率を通じて連携しています。当社の運用では、月を通してスムーズに支出しているエンジニアが日次制限に達することは決してありません。月次予算を稼働日数で割った値が、日次のしきい値を十分に下回るためです。マネージャーが大きなプロジェクトのために誰かの月次制限を引き上げると、日次制限と引き上げ幅も比例してスケールアップするため、暴走防止機能は煩わしいものになることなく、有効に機能し続けます。
内部的には、任意の時点における有効な制限はシンプルに説明できます。ユーザーの支出は両方の予算によって管理されるため、2つの制限（今月のこれまでの使用量に暴走防止の引き上げ幅を1回分加えたもの、および月次上限）のいずれか低い方に制限されます。ユーザーがブロックされた場合、その数式によってどちらのケースに該当するかも正確にわかります。暴走制限に達した場合は、セルフサービスの確認後に利用を再開できます。月次上限に達した場合は、マネージャーと相談する必要があります。
日次制限が機能するのは、ブロック解除が本当にスムーズである場合のみです。そ のため、私たちは設計作業の大部分をその経路に費やしました。エンジニアが実際に体験するのは以下のような流れです。
ユーザーが日次制限の約90%を超えると、ブロックされる前に引き上げの対象になります。コンテキスト（今日の支出額、残りの余裕枠）と、支出が意図的なものであることを確認する1つのボタンが含まれたSlack通知が届きます。ボタンをクリックすると、日次制限がすぐに1段階引き上げられます。同様の自己引き上げは、社内の予算ポータルやCLIからも利用でき、CLIには残りの日次および月次のクォータと、いずれかを引き上げるためのリンクが表示されます。
1日あたりの自己確認の回数に制限はありません。本当に重いワークロードを実行しているエンジニアは、1日に2〜3回引き上げを確認することもありますが、それで問題ありません。それぞれの確認は、「はい、これは私であり、意図してこれを行っています」という、人間による意図的なシグナルです。監視されていないcronジョブがSlackのボタンをクリックすることはできません。ここでは引き上げ幅の大きさが重要です。小さすぎると通知がノイズになり、人々が深く考えずにクリックするようになってしまいます。大きすぎるとガード機能が果たせなくなります。私たちは、月次予算に対してスムーズに支出しているエンジニアには通知が一切表示されないようにサイズを調整しました。
制限をユーザーごとの任意の値に変動させる代わりに、両方の予算はゲートウェイのグループメンバーシップとして実装された、いくつかの固定された階層（ティア）を移動します。全員がベースティアから開始し、ティアが上がるごとに出費のしきい値が一定のステップで引き上げられます。これにより、システムの透明性が維持されます。グループのリストを見れば、誰がデフォルトを超えており、その額がいくらであるかが一目でわかります。
2つの予算は、それぞれの異なる役割に合わせて、異なる方法で階層を移動します。
日次ティアは自動的に移行します。全員がベースティアから月を開始します。自己承認を行うたびにユーザーは1つ上のティアに昇格し、スケジュールされたジョブも、支出が現在の天井に近づいたときにプロアクティブにユーザーを昇格させます（最大で1日1回）。これにより、通常の利用が中断されることはありません。月末には、別のジョブが全員をベースティアにリセットします。先月の急激な利用増加（ビッグプッシュ）が、今月の余裕枠（ヘッドルーム）として繰り越されることはありません。
月次ティアの移行は慎重に行われます。段階は、おおよそ2倍、5倍、そして実質無制限までの数段階しかなく、昇格にはマネージャーまたは上位の承認（スキップレベル承認）が必要です。昇格は、それを必要とするプロジェクトの期間（通常は1ヶ月、3ヶ月、または6ヶ月）に限定され、その後元に戻されます。この大まかな段階設定により、誰も確認しないような微増を繰り返すのではなく、支出に関する実質的な話し合いが促されます。月次ティアを引き上げると、日次の増加幅も比例してスケールするため、 予算超過を防ぐガードレール（runaway guard）の調整が維持されます。
カスタムインフラをほとんど構築することなくこれが機能する理由は、Unity AI Gateway がすでにすべてを把握しているからです。Claude、GPT、Gemini、またはオープンソースモデルのいずれを利用しているかに関わらず、すべてのコーディングエージェントからのすべてのリクエストはユーザーのアイデンティティに関連付けられ、1箇所で測定されます。ゲートウェイに設定された予算は、エンジニアが使用するすべてのツールに適用され、支出が適用可能な予算を超えることはありません。この最後の特性により、追加のコストをかけることなく「2つの制限のうち低い方」を適用する動作が実現します。両方の予算を定義すれば、常に両方が有効になります。
日次および月次のティアは、予算のユーザーごとのしきい値オーバーライドを異なるグループに割り当てることで実装されます。そして、日次の自動化、自己承認、マネージャーの承認を通じて、ユーザーを上位ティアのグループのメンバーにすることで、ティアの昇格が実現します。
ゲートウェイがこのすべての利用データを Unity Catalog に格納するため、オブザーバビリティ（可観測性）も追加コストなしで得られます。マネージャーは、当社が 社内コーディングエージェントのベンチマークを構築したのと同じ Lakehouse テーブルでチームレベルの支出を確認でき、財務部門は5つ の請求書の代わりに1つの請求書を確認するだけで済みます。
割り込み型の承認待ちキューはなくなりました。新しいモデルでは、特定の月に日次制限に達するのはごく一部のヘビーユーザーのみと想定されており、そのような場合でも1回の承認クリックで解決します。月次制限の引き上げは、エンジニアごとの繰り返しの雑務から、マネージャーが一度だけ行う、プロジェクト範囲に限定された稀な決定へと変わりました。
同様に重要なのは、エンジニアが利用を制限しなくなったことです。これらのガードレールの目的は、決して AI の利用を減らすことではありませんでした。無制限に膨らむコストへの懸念を取り除き、導入をさらに推進できるようにすることでした。現在、支出は警戒心から制限するものではなく、データに基づいてコントロールするものとなっています。
利用パターンの変化に合わせて数値の微調整を続けており、社内で有効性が証明されたパターンは、Budgets 製品自体に反映されています。これには、ネイティブな日次予算サイクル、予算サイクルとともに期限切れになる一時的なオーバーライド、事前に定義されたオーバーライドグループよりも柔軟に、エンドユーザーが予算 API を通じて直接自分の日次しきい値を自己引き上げできる権限モデルなどが含まれます。
また、よりスマートなモデルルーティングを通じて、そもそも高コストな経路を必要としないようにする取り組みも進めています。これにより、日常 的なタスクは効率的なモデルに割り当てられ、最先端（フロンティア）モデルはそれを必要とする作業のために温存されます。これについては、今後の投稿で詳しく説明します。
もし皆様の組織でコーディングエージェントの規模を拡大しており、ツールごとに独自の予算管理画面がある場合、その解決策は当社が採用したものと同じです。Unity AI Gateway におけるコーディングエージェントのサポートは、現在すべての Databricks のお客様にご利用いただけます。開始するには、 ドキュメントをご覧ください。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。