皆様もClaude Code、Codex、それともPi？OpenCode？色々なコーディングエージェントを使われていると思います。

特に会社でもこれらは使われ始めていて、便利ですよね。でも使い続けていると気づいたらメチャクチャなコストがかかっていて、怒られた！みたいなこともあるのかも知れません、怒られたくない！

そこで今日は、Databricksがどのようにコーディングエージェントの社内展開しているのか、といった話をできればと思います！

TokenmaxxingからValuemaxxingへ

まずこれです、一時期流行っていたのはTokenmaxxingという話で、これはザックリいえば「トークン使いまくって成果を出しまくれ！」っていう話でした。

結果何が起こったかと言うと、コストの大幅な高騰でした。Uberは2026年4月に、年間AI予算を使い切ってしまった事が話題になりましたし、他にも同じ様な話がでてきて、Tokenmaxxingはちゃうんかな、、、という空気になりました😅

そこでDATA+AI Summit 2026のキーノートでもお話がでた、TokenmaxxingからValuemaxxingへの移行、「トークンに見合った最大のバリューをだそうぜ！」という話になってきています。

Databricks社内でも様々な取り組みをして、Valuemaxxingへの取り組みをしていますし、Blogもいくつかでておりますので、それらの内容を踏まえてお話できればと思います！

コーディングエージェントを開発組織に配ると何が起こる？

まず、コーディングエージェントを開発組織に配ると、二つのことが同時に起きました

一つは「開発速度の向上」です。
Databricksでは、計測している開発速度の指標がどれも改善しました。チームによっては、出せる成果の量が一桁増えました、メチャクチャ嬉しいじゃないです？

でも、果たして嬉しいだけでしょうか？
同時に、トークン課金は使うほど増え、管理しないままでは支出が指数的に伸びていきました。いわゆるTokenmaxxing状態です。

そこでValuemaxxingを実現するためにはどうしたらいいか、、、コストの月次制限をシンプルにしてみました。

これは失敗でした。

単一の月次上限で起きたこと

最初に試したのは、先ほど書いた通り1人あたりの月次上限を一つ置くやり方です。

その結果、毎月500人から1,000人が上限に到達し、その結果発生したのは数百件の上限緩和チケットと、無数の中断された作業セッションと、社内の開発ツール用Slackチャンネルに溜まった不満でした。
これって通常作業を中断されただけ！？

一方で、自動化ループの暴走など、一瞬で大量のトークンを処理してしまうような放置できない失敗の形も存在しています。

これは同じ「上限」という言葉で、性質の違う二つの問題を扱おうとしていたことが問題だったわけです。

ひとつは即座に止めるべき事故で、もうひとつは事業として判断すべき例外でした、、、。

日次制限と月次制限

そこでDatabricksは上限を二段階制に。

日次予算は暴走等のイレギュラーをその日のうちに検知するためのもので、月次に対して小さく上限設定し、毎晩リセットされます。
到達したときに、解除は本人で可能でSlackのボタンを押し「この支出は自分の意図通り」と確認すると上限緩和可能です。承認は要らず、1日の回数にも制限はない。

対して月次予算は、恒常的な浪費を事業の優先度に結びつけるための制限で、通常は到達しない上限として設定します。これの引き上げにはマネージャー承認が必要で、ティア単位で上がり、1か月から6か月で自動的に元に戻る様になっています。

これにより、意図しない利用にもすぐに気付け修正するタイミングを作ることができ、月額予算も見通しがつきやすく、使わないといけない人にも最小限の手間で使ってもらうことができる環境が作れています。

同時に利用者に自分の利用額をいつでも確認できるようにしています。
これらによって、自分の利用状態を管理しつつ必要な所に必要なだけトークンを使うことができるようになりました。

例えばClaude Codeを週の59%を使っていて、そのうち44%がOpus 4.8だと分かったら、じゃあモデルを節約する？ハーネスを変える？などは本人が選択できるわけです。

どのモデルが効率がいい？

まず、Databricksは、一つの指標でモデルを選定しています。「対コスト比のコストパフォーマンス」です。

コストを下げようとしたら、まず安いモデルを使いましょう！と上でもかきました、ですが社内ベンチマークの結果は以外な結果でした。

Sonnet 5はOpus 4.8よりトークン単価が約1.7倍安いですが、1タスクあたりの費用は、Sonnet 5が$2.09、Opus 4.8が$1.94でした。

理由はトークン消費量で、Sonnet 5は同じタスク完了までに1.9倍のトークンを使いました。そのため単価ではなく、1タスクあたりの費用で測る必要がありました。

Databricksは、どのモデルが”対タスク比”でコストが安いかを確認しました。これを効率性のフロンティアモデルといっており、いわゆる知能のフロンティアモデルと言われているものとは区別しています。

特定の知能レベルにおいて最も優れた価格を実現するモデルです。

これらを定期的に確認していきつつ、社内で主に使っていくモデルを決定敷くことでValuemaxxingを実現しようというわけです。

どのタスクにどのモデルを使う？

次に社内の実利用をタスクの複雑さ別に集計したら分布は次のようになりました。

88%が「中（ちょっと難しい）」以下でした。
それでも当初デフォルトでは高価なモデルが選ばれていました。

もちろん上の様にユーザ側でも利用モデルを気をつけるというのもありますが、Databricksとしては、Smart Routingという仕組みもリリースしてます。

与えられたプロンプトなどからタスクの複雑度を判別し、それによって選択するモデルを動的に変更する仕組みです

DatabricksはOmnigentというメタハーネスソフトウェアと、ucodeと言われるラッパと、Unity AI GatewayによってSmart Routingを実現しています。

コンテキストを削減

モデルの選択とハーネスの選択の最適化後に残るのは1セッションで送るトークンの量でした。

社内の週次平均は、約1,200万トークンから約550万トークンへ下がりました。
効いた施策はハーネスのトークン効率の調整と、キャッシュの保持時間の延長の2つでした。

トークンは費用に直接関わってくるため、この削減はそのまま請求額に出ることになります。

対策ごとの効果

ここまでの対策をDatabricksは削減率の目安として整理するとこうなりました。

打ち手	削減率の目安
より安いモデルへの移行	50%以上
振り分け	30%程度
支出の統制	10%程度
コンテキストの最適化	10%程度

これらはもちろん現時点ではDatabricksの中でも調査結果にはなるので、皆様の会社で同じ削減率になるかはわかりませんが、方向性の確認として見て頂けると良いかなと思います！

全ての利用を1つのガバナンスの下へ

実はここまでのValuemaxxingへの対策は、どれも同じ前提を必要としています。
支出の可視化も、予算の強制も、モデルの差し替えも、全利用が1か所で管理されていなければ成立しない、ということです。

ツールごとの管理画面ではこの前提が満たせず、支出はツール単位までしか分からず、予算はツールごとに別々で、監査ログはばらばら、モデルの差し替えはそのツールの対応次第に、、、管理するには一箇所で同じガバナンス下で管理する場所が必要なのです。

Databricksが管理ツールとして使っているのは自社で開発しているUnity AI Gatewayです。いわゆるドッグフーディングと言ってもいいと思います。
管理の対象はモデルだけではなく、エージェント、MCPサーバー、スキル、ツール等を1か所に登録して権限を付ける事が可能です。

Gateway経由なら支出は人と組織と用途の単位まで按分され、利用量上限を設定でき、実行時のガードレールとレート制限とPII検査も可能となります。
監査ログと利用トレースはUnity Catalogに集まり、いつでもダッシュボードや、Genie Oneなどで分析可能となります。

じゃあ自分の会社でどこまでValuemaxxingできるのか！？自社のマージ済みPRで測る

ここまでの数値はDatabricks社内の測定で、他社にそのまま当てはまるわけではありません。

Databricksが行った方法としては、マージ済みのPRにを使い、それを使って評価しました。これには実装の試行錯誤と人のレビューとテストによる検証が、すべてあり、評価データとして使えたためです。

1. 対象を選ぶ：最近マージされた、人が書いた、テストが付いていて、1つのPRで完結している変更を抽出
2. 問題文にする：差分そのものは渡さず、何を実現したいかだけをエージェントへの指示に
3. 答えを隠す：Git履歴を見せない。採点用のテストは取り分けて、作業中は触らせない
4. テストで採点する：AIに良し悪しを判定させず、取り分けたテストが全部通ったときだけ合格とする

Databricksはこれを10言語以上の実コードで行いました。
この評価データが手に入ると、モデルとハーネスの組み合わせを1タスクあたりの費用と全通過率で比べられるようになり、この記事に出てきた判断を、自社の数字で再現できるかもしれません。

Valuemaxxingへレッツゴー！

いかがでしたでしょうか！

ここまで見てきたように、ただ無制限にトークンを消費して成果を求める「Tokenmaxxing」の時代は終わりました！
投下したコストに対し最大の価値を引き出す「Valuemaxxing」の時代がやってきています。

Databricksの取り組みから学べるのは、「ただ一律で制限して使わせない」のではなく、「開発者のスピードや体験を落とさずに、いかに組織全体で賢くエージェントを活用するか」という非常にポジティブなアプローチとなっています。

• 日次・月次の二段構えによる柔軟な予算管理
• Smart Routingによる適材適所のモデル選択
• ハーネスの最適化によるコンテキスト削減
• これらを一元管理する単一のガバナンス（Unity AI Gatewayなど）

これらを整えることで、管理者はコストの暴走に怯えず、開発者はストレスなくコーディングエージェントの真のパワーをフルに引き出すことができます。

「うちの会社でもできるかな？」と思った方、大丈夫です！自社の実データを使って、まずは現状を正しく測るところからスタートしてみてもおもしろいと思います！

さあ、皆さんの開発組織でも、Valuemaxxingへレッツゴー！

何かあればお近くのDatabricksまでおねがいします！ｗ