コーディングエージェントのコストは上限ではなく摩擦で抑える

• 請求書は来たのに誰がいくら使ったか分からない状態
• ハード予算が最後の手段である理由
• 暴走防止とガバナンスを分ける二段構造
• 増分ひとつの大きさが設計のほぼすべてです
• ルーティングはもっとも安いモデルではなく、やり遂げられるもっとも安いモデルへ
• 実際にコストを支配するのはモデル単価ではなくコンテキスト
• キャッシュはただではありません
• 自分の組織に持ち込むときの最小構成
• 参考資料

請求書は来たのに誰がいくら使ったか分からない状態

コーディングエージェントをチームに解き放って二か月ほど経つと、たいてい同じ会話が始まります。先月比で請求額が三倍になり、それがどこから来たのかを誰も説明できません。ツールは三種類あり、それぞれ別のアカウントで別のモデルを呼んでいて、使用量はベンダーのコンソールに散らばっています。

この状態でもっともよくある対応が、一人あたりの上限を掛けることです。そしてたいてい失敗します。上限に当たった人は作業の途中で止まり、チケットを開き、誰かが承認してくれるまで待ちます。節約された金額より、途切れた作業時間のほうが高くつきます。

ハード予算が最後の手段である理由

Databricksが2026年8月7日に公開したManaging AI Coding Costs at Scaleは、複数の会社にインタビューしたうえでこう書いています。ハード予算は、彼らが話を聞いたすべての会社で最後の手段としてのみ使われていた、と。

理由はコスト構造にあります。コーディングエージェントの支出は正規分布ではなくロングテールです。ほとんどのエンジニアはごく普通に使い、少数が大きな作業を回します。そしてその少数の大きな作業こそが、たいていもっとも価値のある作業です。大規模なリファクタリング、古いサービスの移行、障害原因の追跡のように、人がやれば何日もかかる仕事です。平均に合わせて上限を引くと、まさにその作業が切られます。

上限の二つ目の問題は、学習効果がないことです。止められた人は自分がなぜ多く使ったのかを知るのではなく、ただ止められたという事実だけを知ります。翌月も同じやり方で使い、同じ場所で止まります。

そこで方向が変わります。使えないように止める代わりに、いくら使っているかを見えるようにし、使い続けるなら一度確認させるという形にします。

暴走防止とガバナンスを分ける二段構造

同じ会社が2026年7月28日に出したHow Databricks manages its own coding agent spendには、その設計が具体的に出てきます。予算が二層に分けられています。

日次予算は低く引かれた暴走防止線です。目的は節約ではなく事故検知です。無限ループに陥ったエージェント、設定を誤ったバッチ処理のようなものを一日のうちに捕まえます。使用量が90パーセント付近に達するとSlackに通知が飛び、ボタンひとつで本人が上限を一段階上げられます。この自己承認には回数制限がありません。

月次予算は性格が違います。ほとんどのエンジニアが生涯たどり着かないほど高く設定され、上げるには管理者の承認が必要で、引き上げには1か月、3か月、6か月といった期限が付いて自動的に元へ戻ります。段階も細かくなく、およそ2倍、5倍、事実上無制限といった粗さです。粗く作ったことが意図であり、そうしてはじめて承認のやり取りが形式的な確認ではなく実際の議論になります。

増分ひとつの大きさが設計のほぼすべてです

この構造でもっとも気を配って決めるべき値は、上限ではなく増分です。原文の表現どおり、月次予算に合わせて均等に使うエンジニアが通知を一度も見ないように増分の大きさを決めています。

そして管理者が月次上限を上げると、日次上限と増分も比例して一緒に大きくなります。これをやらないと、大きなプロジェクトの承認を得た人が一日じゅう自己承認ボタンを押すだけになり、暴走防止線が意味を失います。

"""ゲートウェイの予算判定: 上限は二つ、実効上限はひとつ。"""
from dataclasses import dataclass


@dataclass
class BudgetPolicy:
    monthly_max: float        # 管理者承認でのみ上がる上限
    runaway_increment: float  # 自己承認1回で開く幅

    def effective_limit(self, month_to_date: float) -> float:
        """月累計 + 増分1回。ただし月上限は超えない。"""
        return min(month_to_date + self.runaway_increment, self.monthly_max)

    def decide(self, month_to_date: float, today: float, today_limit: float):
        limit = self.effective_limit(month_to_date)
        if month_to_date + today >= self.monthly_max:
            return "block", "月上限に到達 - 管理者承認が必要"
        if today >= today_limit:
            return "self_ack", "確認ボタン1回で続行できる"
        if today >= today_limit * 0.9:
            return "notify", f"本日の残り {round(today_limit - today, 2)} 単位"
        return "allow", ""


# 月上限は余裕をもたせ、一日の増分は小さく取る組み合わせ
policy = BudgetPolicy(monthly_max=1000.0, runaway_increment=40.0)
for mtd, today, day_limit in [(120, 10, 40), (120, 37, 40), (120, 41, 40), (990, 15, 40)]:
    print(mtd, today, policy.decide(mtd, today, day_limit))

このコードがやることは単純ですが、ここに組織の方針がすべて入っています。何が遮断で、何が確認で、何が沈黙なのかが四行で決まります。散らばったダッシュボードの代わりに、この関数ひとつをレビューすれば済みます。

ルーティングはもっとも安いモデルではなく、やり遂げられるもっとも安いモデルへ

二つ目の軸はルーティングです。Databricksは、社内ゲートウェイのスマートルーターが最高品質のモデルとおおむね同等の結果を保ちながら、平均の作業コストを30パーセント超削減していると述べています。

注意すべきは、これが「安いモデルを使おう」とは違うということです。リクエストごとに、その仕事をやり遂げられるもっとも安いモデルを選ぶ判定であり、判定を誤ると再試行が付いてかえって高くつきます。だからルーターは導入の前後で必ず品質指標と再試行率を一緒に見る必要があります。コストだけを見れば、いつでも改善したように見えます。

同じ記事には、上位モデルを社内に開放しないと決めた判断も出てきます。以前のバージョンに対する品質向上が確認できなかったという理由でした。最新のモデルを使わないことも選択肢だという点が、ここでは重要です。

実際にコストを支配するのはモデル単価ではなくコンテキスト

三つ目の軸がもっとも大きいところです。原文の表現を移すと、高価な推論が実行される時点では、ユーザーが最初に打った文はシステムに入るデータのうち無視できる割合でしかなく、コストはコンテキストが支配します。

エージェントの一回の呼び出しに載るのは、システムプロンプト、ツール定義、ファイルの断片、検索結果、そして前のターンの履歴すべてです。ユーザーが打った一行は、これに比べれば丸め誤差です。だから単価が半分のモデルへ移るより、コンテキストを半分に減らすほうがたいてい大きな効果を出します。

Databricksはハーネスの調整とキャッシュ設定の変更によって、生成トークン数をほぼ50パーセント減らしたと書いています。モデルを変えずに得た数字だという点が核心です。

キャッシュはただではありません

キャッシュについては一文が正確です。キャッシュ書き込みにはコストがかかり、キャッシュ読み出しは推論あたりのコストを大きく下げるということです。

この二つが同時に成り立つという事実が、実務ではよく忘れられます。プレフィックスが頻繁に変わる構成でキャッシュを有効にすると、書き込みコストだけを払い続けてヒットは出ません。だからキャッシュを有効にする前に確認すべきは、ヒット率ではなくプレフィックスの安定性です。システムプロンプトとツール定義がリクエストごとに順序が変わったり、タイムスタンプが混ざり込んだりすれば、ヒット率は構造的に上がりません。

点検は難しくありません。実トラフィックからリクエストを100件抜き出し、キャッシュ対象のプレフィックスをハッシュにして出力してみればよいのです。異なるハッシュが90個出てくるなら、その構成ではキャッシュはコストを増やすだけです。ツール一覧の並び順を固定し、動的に差し込んでいた現在時刻とセッション識別子をプレフィックスの後ろへ移すだけで、ハッシュの種類が一桁に落ちる例はよくあります。

自分の組織に持ち込むときの最小構成

この設計をそのまま複製する必要はありませんが、順序は守る価値があります。

Databricksの記事は、社内で予算構造を変える前は毎月500人から1,000人のあいだのエンジニアが上限に当たっていたと明かしています。数百件のチケットと、それと同じ数だけ途切れた作業セッションです。コスト管理の成否は、請求書がどれだけ減ったかだけでなく、減らす過程で何度人の手が必要になったかでも見るべきだということです。

参考資料

• Managing AI Coding Costs at Scale — Databricks, 2026-08-07 — 四つの技法、ルーティングの30パーセント超の削減、生成トークン50パーセント減、キャッシュ書き込みコストへの言及がこの記事の内容です。
• How Databricks manages its own coding agent spend with Unity AI Gateway Budgets — Databricks, 2026-07-28 — 二段予算、自己承認、増分の比例拡大、月500〜1,000人が上限に当たっていた状況がここに出てきます。
• 一部メディアの要約では、これらの技法で最大90パーセントを削減したという表現が出回っていますが、Databricksの原文で私が確認できた数値は上に書いたものであり、表にまとめられた削減幅は非公式アンケートに基づく方向性の数値だと原文が直接述べています。90パーセントという数字は原文では確認できません。
• 本文の予算判定コードは、原文に述べられた規則を私が移して実装したものであり、数字は例です。