2026年8月7日

大規模におけるAIコーディングコストの管理

によって Patrick Wendell（パトリック・ウェンデル）, Akshat Bhatia, Vinay Gaba, エリック・エルセン、イヴァン・ジョウによる投稿

AIコーディングツールは計り知れない価値をもたらします。Databricksでは、エージェント型コーディングによって、追跡しているすべての開発速度指標が目に見えて向上しており、一部のチームでは生産性が桁違いに向上しています。しかし、AIツールを大規模に導入しているほぼすべての企業が、同じ壁にぶつかっています。それが、指数関数的に増大するコストです。このコストの急上昇は持続不可能です。放置すれば、いずれ収益を上回ってしまいます。この支出の爆発的な増加により、企業は矛盾した状況に陥っています。一方では、AI変革を最大限に推し進め、強力なツールを従業員に提供したいと考えながら、他方では、AIがもたらす効率性の向上そのものを損なう、あるいは台無しにしかねない総コストの状況に対処しなければならないのです。

幸いなことに、最も早い時期に大規模な導入を行ったいくつかの企業は、この難題を解決する一連のアプローチにたどり着き、「二重の使命」を果たしています。それは、（a）摩擦を最小限に抑えながらAIツールへの幅広いアクセスを提供すること、そして（b）ユーザーあたりの総コストをほぼ一定の範囲内に抑えることです。本ブログ記事では、Databricksでの経験や、Stripe、Coinbase、Uber、Rampなどのデジタルネイティブ企業数社との対話に基づき、実証済みのコスト管理手法を紹介します。以下の表は、現在の手法とそれに関連する削減効果をまとめたものです。数値は開発チームへの非公式な調査に基づく目安です。

これらの手法の一部は、多くの企業がすでに使用しているソフトウェアで簡単に実装できます。一方で、エンドユーザーのクライアントを修正したり、モデル間でトラフィックを移行したりする手法など、新しいインフラを必要とするものもあります。Databricksでは、主要なインフラコンポーネントであるエンドユーザー向けメタハーネス（Omnigent）とAI Gateway（Unity AI Gateway）をオープンソース化、または無償で提供しています。全体像を把握しやすくするため、本記事では、お話を伺った他社が使用しているソフトウェアについても取り上げています。

コーディングモデルにおける「効率性のフロンティア」

コーディングにかかる費用を抑えるための最大の手段は、より効率的なモデルがリリースされた際に、それらへと迅速に移行することです。単に「より安価なモデル」と説明するだけでは、モデルのコストと品質の間の微妙な関係性が見えなくなってしまうため、この点については少し詳しく説明する必要があります。

口語的には、フロンティアモデルという用語は「最高レベルの知能を持つモデル」を意味し、フロンティアラボは主にピーク時の知能を向上させることに注力しています。フロンティアモデルは現在、数学やサイバーセキュリティにおけるこれまでにない課題を解決できるようになっています。しかし、AIを大規模に導入する場合、別の種類のフロンティアがより重要になります。それが 効率性のフロンティアです。効率性のフロンティアは、特定の知能レベルにおいて最も優れた価格帯を実現するモデルの集合として定義されます。日常的なコーディングの大部分は、数学的な証明や斬新なセキュリティの知見を必要としません。そのため、全体として重要になるのは、一般的なソフトウェア開発業務の品質基準を満たすモデルのコストです。この「効率性のフロンティア」は知能のフロンティアよりもはるかに速いペースで進歩しており、従来のモデルよりも価格あたりの知能に優れた新しいモデルがほぼ毎週のようにリリースされています。

コスト削減手段その1：オープンソースや低コストのモデルへの移行

新しく、より効率的なモデルを迅速に採用することは、あらゆる手法の中で最大のコスト削減効果をもたらします。しかし、その恩恵を享受するには、企業はまず、どのモデルが実際に既存のモデルを上回っているかを知る必要があります。公開されているベンチマークは、コーディングタスクにおける実際のパフォーマンスを十分に反映していないことが多いため、これを判断するのは困難な場合があります。新しいモデルを評価するために、多くの企業は、自社の社内開発環境をより正確に反映していると考えられる自動評価システムを構築しています。Databricksは最近、このようなベンチマークの例を公開しました。この中では、GLMモデルが非常に競争力のあるコストパフォーマンスを示していることが確認されました。このベンチマーク結果を受けて、私たちは社内の開発者向けにGLMの展開を開始しました。新しいモデルが必ずしも効率性のフロンティアを進めるとは限らず、評価結果が期待外れに終わることも少なくありません。例えば、StripeはOpus 4.7がOpus 4.6と比べてコストが増加する一方で、品質はそれほど向上しないことを発見しました。そのため、同社は社内でOpus 4.7を利用可能にすることを見送りました。Databricksでも、Opus 5.0と4.8を比較した際に、同様のコスト対効果の悪化が見られました。

ハーネスとモデルの柔軟性

最大の成果は新しいモデルへの切り替えから得られるため、モデルの柔軟性を可能にするエンドユーザー向けツールの採用は、コストを抑えるための重要な要素になりつつあります。特定のモデルと連携して最も一般的に使用されるツールは、ハーネスと呼ばれます。独自のフロンティアモデルは、特定のハーネスとうまく連携するように共同設計されることが増えており、特定のハーネスが特定のモデルで「より良く機能する」ことを意味します。企業がモデルの独立性を維持したい場合、大まかに2つのアプローチがあります。

ユーザーにハーネスの切り替えを促す。1つのアプローチは、開発者に一連のハーネス（Claude Code、Codex、Cursorなど）を提供し、企業がより低コストのモデルに支出を移行したい場合に、ハーネスを切り替えるよう求めることです。これにより、ユーザーは可能な限り好みのハーネスで作業できますが、このアプローチのデメリットは、個々の開発者にとっての切り替えコストが高くなる可能性があることです。切り替えコストが高くなりすぎると、ハーネス自体が事実上特定のモデルファミリーへのロックインとなり、より競争力のあるモデルへの支出移行が制限されてしまいます。

メタハーネスを使用する。新しく、人気が高まっているアプローチは、開発者に共通のユーザー体験を提供しつつ、基盤となるハーネス（独自およびオープンソースの両方）にリクエストを振り分けるメタハーネスを使用することです。このアプローチにより、モデルやハーネスの独立性を維持しながら、開発者の切り替えコストを削減できます。Databricksでは、Omnigentを活用する開発者のデフォルトモードとなっています。お話を伺ったいくつかの企業は、自社の開発ツールチェーンと統合されたカスタムの社内用メタハーネスを構築しています。

コスト削減手段その2：動的なリクエストおよびタスクのルーティング

ユーザーにタスクに適したモデルを自分で選択させる代わりに、モデルやツールを自動的に選択することで、エージェント型コーディングのワークフローからさらに効率性を引き出せるという研究が増えています。ルーティングのアプローチは、大まかに以下の3つのカテゴリに分類されます。

リクエストレベルのルーティング：クライアント（コーディングハーネスなど）と基盤となるファウンデーションモデルの間に、ステートフルなプロキシを配置します。プロキシは、各推論リクエストに対して、回答可能な最も低コストのモデルにリクエストをルーティングしようとします。エージェント型のユースケースにおけるルーティングでは、サーバー側のキャッシュも考慮する必要があります。コンテキストが大きいワークロードでは、コールドキャッシュヒットのコストが非常に高くなるためです。新しい製品群は、ルーティングにおいて有望な初期成果を示しています。例としては、Cursor Router、OpenRouterのAutoRouter、RampのRouter機能、そしてDatabricks独自のUnity AI Gatewayのスマートルーティング機能などがあります。
タスクレベルのルーティング（メタハーネス）：クライアント側のプロセスが、タスクの複雑さに基づいてユーザーのタスクを異なるハーネスに振り分けます。ユーザーのタスクには、「このコンポーネントの名前をXからYに変更する」（単純なタスク）や、「レイテンシを削減するための設計上の考慮事項を検討する」（複雑なタスク）といった自由形式のタスクがあります。通常、メタハーネスと呼ばれるディスパッチャーは、タスクにどのレベルの基盤モデルが必要かを判断し、そのエンドツーエンドのタスク全体をそのモデルに委ねます。Omnigentは、このパターンをサポートするメタハーネスの一例です。
エスカレーション／デリゲーション（委譲）パターン：単一のハーネスで2つのモデル（高価で高知能なモデルと、安価なワーカーモデル）をペアにします。一部のアプローチ（ClaudeのAdvisor Toolなど）では、安価なモデルが処理を主導し、タスクにより高い処理能力が必要であると判断した場合にエスカレーション（上位モデルへの引き継ぎ）を行います。逆のパターンも存在します。Cognition’s Devin Fusionでは、高コストのモデルがメインループとなり、安価なモデルに選択的に作業をアウトソーシング（委譲）します。
Databricksの社内検証結果では、当社のAI Gatewayスマートルーターを使用することで、稼働中のセットの中で最も高価なモデルとほぼ同等の品質を維持しながら、平均タスクコストを継続的に30%以上削減できることが示されています。お話を伺った他社でも、同様の結果が得られています。

コスト抑制のレバー3：開発者への可視化、トリップワイヤー、予算管理の提供

「ユーザーに月次予算を設定して終わりにする」という話でこの記事の最初から最後までが終始していないことに、驚かれるかもしれません。特定の支出しきい値に達した時点で利用を完全に遮断するハードバジェット（厳格な予算制限）は、私たちが話を聞いたすべての企業において、多くの場合、最終手段としてのみ使用されていました。トークンに対する厳格な予算制限が、AIの支出管理においてそれほど効果的ではない理由は2つあります。第一に、開発者が予算の上限に達したからといってAIツールへのアクセスを遮断してしまうと、生産性が著しく低下します。企業にとっても従業員にとっても、これは望ましい結果ではありません。第二に、「支出額が高い」ユーザーの少なくとも一部は、実際にはAIを活用して驚異的な効率化を達成し、膨大な成果を生み出しているユーザーだからです。そのようなユーザーの意欲を削ぐことは、本末転倒です。

ユーザーに対する厳格な支出上限を設ける代わりに、多くの企業は、エンドユーザーへの可視化に焦点を当て、支出の増加に伴って段階的に制約（フリクション）を課していく、よりきめ細やかで段階的なアプローチを採用しています。

可視化：私たちが話を聞いたすべての企業が、現在の支出状況に関するフィードバックをほぼリアルタイムでユーザーに提供する仕組みを備えていました。また、その多くは、より安価なモデルを使用して支出を削減するための具体的なヒントやインサイトも提供していました。ユーザーが最も高いROIを得られるツールを選択できるようにするためにも、すべてのツールにわたる支出をユーザー自身が確認できることが重要です。
現在の支出状況を表示するDatabricksの開発者ダッシュボード
支出ゲート：支出額の増加に応じて、開発者に特定のアクションを求めたり、承認を申請させたりすることができます。最もシンプルな支出ゲートは、ユーザー自身で解除（セルフクリア）できるもので、支出ペースが特定のしきい値を超えて上昇していることを警告する役割を果たします。Databricksでは、セルフクリア可能なゲートが、偶発的または意図しない支出を防ぐための有用なメカニズムであることを見出しました。さらに、明示的な予算承認（多くの場合、管理ライン経由）を必要とするゲートを導入することも可能です。
ダウンシフト：開発者が支出ゲートに達した場合、トークンへのアクセスを完全に停止するのではなく、より低コストのモデルにダウンシフトさせることができます。最も低コストのモデルは、最先端のインテリジェントモデルに比べて劇的に安価であるため、この手法により、開発者は膨大な継続的支出を発生させることなく業務を継続できます。
一時停止：極端なケースとして、ほとんどのシステムは、ユーザーによるすべてのトークンアクセスを完全に停止する機能を備えています。前述のように、これは多くの場合、一時的な措置にすぎず、AIを効率的に活用する方法について話し合うための出発点となります。

コスト抑制のレバー4：トークンオーバーヘッドの削減

ユーザーがAIコーディングエージェントに比較的シンプルなリクエスト（「このバグを調査して修正してください」など）を入力すると、そのエージェントはその後、関連する大量のコンテキストを収集し、多数のツールを呼び出し、コードベースを検索し、会社から提供されたスキルやシステム情報を統合します。コストのかかるLLM推論が実行される頃には、ユーザーの最初の指示文はAIシステムに投入されるデータのごくわずかな割合にすぎず、コストの大部分はユーザーが明示的に含めなかったコンテキストによって占められることになります。コンテキストの肥大化を抑える技術はまだ新しいものですが、以下のような有望なアプローチがいくつか模索されています：

アクティブなコンテキストのより頻繁な圧縮（コンパクション）を強制する。
「おしゃべりが少ない」（トークン効率の高い）ハーネスを使用するか、既存のハーネスをチューニングしてトークンのオーバーヘッドを減らす。
よく使われるツールを監査し、その冗長性を低減する。
開発者にタスクをより小さな個別の作業単位に分割することを促し、コンテキストの範囲を狭める。

コンテキストが大きくなると、プロンプトのキャッシュも全体的なパフォーマンスにおいて重要な役割を果たします。商用およびオープンソースのLLMは、いずれもプロンプトキャッシュを有効にし、キャッシュの保存期間をチューニングできる設定を備えています。キャッシュの書き込みにはコストがかかりますが、キャッシュされた読み取りは推論あたりのコストを劇的に削減できます。このトレードオフは企業の具体的なワークロードに依存するため、デフォルトのキャッシュ設定を手動でチューニングして全体的なキャッシュヒット率を向上させることで、全体的なコストを劇的に改善できます。

Databricksでは、ハーネスとキャッシュの設定を比較的シンプルにチューニングするだけで、開発者向けの品質低下を一切招くことなく、生成されるトークン数と関連コストをほぼ50%削減できました。私たちはこの分野の技術を引き続き模索しており、さらに大きな最適化が可能であると考えています。

不要な推論呼び出しの排除とキャッシュ書き込みの削減による、セッションあたりのトークン数の劇的な減少。

AI Gatewayのデザインパターン

上記の手法には、多くの暗黙的な技術要件がありました。新しいモデルを迅速に活用するには、企業は「モデルメニュー」を管理する中央の場所を持つ必要があり、エンドユーザーはモデルの組み合わせをサポートするツールチェーンを持つ必要があります。複数のAIツールにわたって予算の可視性を提供するには、統合されたコスト観測性（オブザーバビリティ）機能が存在しなければなりません。コンテキストの肥大化を管理するには、企業は一般的なツール呼び出しの出力を監視し、圧縮やコンパクションを強制する方法を必要とします。これらのニーズは、**AI Gateway**と呼ぶにふさわしい、新しいクラスのインフラストラクチャソフトウェアによって一括して解決されつつあります。AI Gatewayは、以下のすべてが行われる中央の場所です：

基盤となるモデル（商用モデルとOSSモデルの両方）へのアクセスの容量管理とプロキシ。
段階的な制約レベルやモデルのダウンシフトなど、複雑な予算ポリシーを含む予算の追跡と執行。
モデルの許可リスト、圧縮設定、その他のローカルで調整される側面を強制するための、エンドユーザー向けツールの構成管理。
後続の効率分析やベンチマークのための、コーディングセッショントレースのロギング。

Databricksでは、これらすべての機能についてUnity AI Gatewayに大きく依存しています。

まとめ

AIコーディングコストの急激な増加は避けられないものではなく、解決可能なエンジニアリングとガバナンスの課題です。コストを抑制できている企業は、共通のプレイブックを共有しています。それは、インテリジェンスの限界ではなく効率性の限界を執拗に追求すること、モデルの柔軟性を維持するツールを採用すること、対応可能な最も安価なモデルにインテリジェントにタスクをルーティングすること、厳格な予算制限を可視化と段階的な制約に置き換えること、そして実際の支出の大半を占めるトークンのオーバーヘッドを削減することです。これらの手法はいずれも、そもそもAIを導入する価値をもたらした生産性の向上を犠牲にする必要はありません。これらを組み合わせることで、組織は予測可能なコストの範囲内で、摩擦の少ない幅広いアクセスを提供するという2つの要件を同時に満たすことができます。

企業がコストを管理するためのツールを提供する、一連の新しいインフラストラクチャの抽象化が登場しつつあります。Databricksでは、コスト管理スタックの主要コンポーネントをオープンソースまたは無料のソフトウェア製品としてリリースしています。中央管理用のUnity AI Gatewayと、開発者ツール用のOmnigentです。毎日、何千もの企業がこれらのコンポーネントを使用しています。このテクノロジーの展望が急速に進化する中、より多くの企業が知見を共有し、手法を比較検討することを歓迎します。

謝辞：この記事にコメントとレビューを提供してくださったUber、Stripe、Coinbase、Rampのインフラストラクチャリーダーの皆様に感謝いたします。また、この記事の初期草稿にフィードバックをくださったThrive Capitalに感謝いたします。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事