AIコスト管理の新たな経済学

過去2年間、エンタープライズAI導入に関する議論の多くは、いかに人々にAIを使わせるかという点に集中していました。ここ数ヶ月で、その状況は多くの組織で急速に変化しています。かつてトークン量で成功を測定していたAIオブザーバビリティは、投資対効果（ROI）で成功を測定し始めており、コスト管理を最初に解明した企業こそが、支出が収益を上回ることなくAIを拡張できる企業となります。

AIコスト管理の本質は、モデル、エージェント、アプリケーション、チーム全体にわたるAI支出を測定、アトリビューション（帰属分類）、制御、最適化する取り組みです。目標は単にトークン使用量を減らすことではなく、費やした1ドルごとに生成されるビジネス価値を最大化することです。AIエージェントがより多くの自律的なタスクを担うようになるにつれ、その規律はエージェントの推論、ツール呼び出し、それらを駆動するモデルのコスト管理へと拡大しています。

DatabricksのシニアスタッフエンジニアでありUnity Gatewayのテクニカルリードを務めるKevin Stumpf氏にインタビューし、チームがこの規律を実際にどう運用すべきかについて語り合いました。AIコストを単に削減すべき一項目として扱うのではなく、管理すべきシステムとして捉えるアプローチです。

tokenmaxxingからvaluemaxxingへ

SNSでは、「tokenmaxxing」（AIを可能な限り高速かつ頻繁に実行すること）こそが革新を加速させる正解だと主張するリーダーで溢れています。明白なコストへの影響以外に、なぜそれがAI導入に関する間違った考え方なのでしょうか？

Kevin Stumpf: 業界はtokenmaxxingからvaluemaxxingへと移行しつつあります。初期の頃は、どれだけのトークンを消費したかを示すパブリックなリーダーボードが存在し、当時の戦略としてはそれが理にかなっていました。多くの人がAIの利用開始に消極的だったため、誰もが尊敬するリーダーたちがAIを大量に使用していることを示すことで、他の人々にもそれに続く理由を与えていました。尊敬する誰かが大量のAIを使っていれば、自分もその人のようになりたいと思うものです。

しかし、システムは悪用されました。リーダーボードのトップに立つことがステータスシンボルになると、人々はそこに到達する最速の方法が良い成果を出すことではなく、量（ボリューム）であることに気づきました。ループで実行される愚かなエージェントを立ち上げ、何度も天気を尋ねさせ、実質的に何も生み出さないままトークンを消費するのです。これは成果ではなく生の使用量を報いるインセンティブ構造から予見できた結果でした。

組織がAIを広く受け入れるようになった現在、議論は責任ある効果的な使用へと移行しています。私たちが本当に構築を目指すべきなのは、AIで生成したインパクトをそれを生成するのにかかったコストで割った値でランキングする、別の種類のリーダーボードです。それが投資対効果（ROI）であり、生データとしてのトークン数よりも定量化がはるかに困難ですが、それこそが実際に重要な数値です。関連情報: エンタープライズにおけるAI導入の推進要因とは？

実践におけるコストアトリビューションの真の意味

AIにおける「コストアトリビューション」の真の意味について説明していただけますか？

Kevin Stumpf: AIにおけるコストアトリビューションとは、最終的に2つの質問に答えることです。支出はどこから生じているのか、そしてそれに対して何を得たのか？最もシンプルなレベルでは、データサイエンスチームやソフトウェアエンジニアリングチームなど、個々のユーザーやチームにコストを割り当てることを意味します。また、特定のプロジェクトにマッピングしたり、組織図のノードにマッピングしたりすることもできます。例えば、AI担当VPとエンジニアリング担当SVPの下でどれだけの支出が発生しているかを把握することなどです。

目標は、データを様々な角度から分析し、コストが実際にどこから生じているかを把握できるほど十分な細度で可視化することです。測定できないものは管理できません。Databricksは、ユーザー、グループ、エージェント、AI gatewayエンドポイント、モデル、プロバイダー、期間ごとのコストアトリビューションを標準で提供しています。しかし、組織はリクエストレベルのタグを使用して高度にカスタマイズすることも可能です。タグは、特定のプルリクエスト、機能、外部顧客など、組織が重視するあらゆるものを表現でき、すべてのリクエストにそのタグが付与されれば、必要な方法で支出を集計できます。

お客様の意識におけるその変化は本物です。6ヶ月前、最大の懸念事項はAI導入の遅れでした。現在ではその逆となっています。AIが無駄な目的に使用されることが多く、収益よりも早くコストが増加しており、リーダーたちはそのコスト曲線を収益性に悪影響を与える前にどのように抑えるかを尋ねています。これは仮説ではありません。私たちが話をするほぼすべての組織における取締役会レベルでの議論であり、これにはDatabricks内部も含まれます。

コンテキストブロート（膨張）の抑制

トークン使用量とコンテキストウィンドウサイズはよく非難の対象になりますが、十分に説明されることは滅多にありません。本番システムにおけるコンテキストブロート（膨張）とは実際どのようなもので、実践的な解決策は何でしょうか？

Kevin Stumpf: コンテキストブロートとは、エージェントが適切な決定を下すために必要な情報よりもはるかに多くの情報を与えてしまうことです。これは2つの理由で問題となります。第一に、無駄なトークンを消費すること。第二に、気が散る原因になることです。エージェントはその余計な情報を処理し、それが関連しているかどうかを判断しなければならず、それ自体が一種のオーバーヘッドとなります。これは、人に無関係な書類の山を手渡し、タスクを開始する前に何が重要かを解明するよう求めるようなものです。

最善の解決策は、後から削減したりキャッシュしたりすることではなく、最初からブロートを発生させないことです。一般的で効果的なパターンは、必要になりそうなすべての情報を事前かつ能動的に渡すのではなく、ツール、MCPサーバー、またはスキルを通じて、エージェントに必要なコンテキストをオンデマンドで取得させることです。手元のタスクにとって真に重要であると90%以上の確信がない限り、デフォルトでエージェントにコンテキストを渡すべきではありません。そうでない場合は、利用可能なものをエージェントに知らせ、必要な時に必要なものを取得できるようにします。

動的なモデルおよびハーネスのルーティング

モデルの選択は「一度選んだら固定」という決定になりがちです。なぜ代わりに動的であるべきなのでしょうか？また、インテリジェントルーティングは、タスクがフロンティアモデルを必要とするのか、それともより安価で高速なモデルで十分なのかをリアルタイムでどのように判断するのでしょうか？同じ考え方は、異なるエージェントハーネス間の選択にも適用されますか？

Kevin Stumpf: AIコストの最適化とは、常に最も安価なモデルを選択することではなく、チームはタスクが求める品質を提供できる、最も低コストなモデルまたはハーネスを選択するように移行すべきです。現在の現実は、フロンティアモデルは非常に高性能で高価である一方、非フロンティアモデルも十分に高性能であり、単に安価であるということです。真にフロンティアモデルを必要とするタスクはおよそ5〜10%に過ぎません。これは、失敗できないため最善の成果を望むか、問題が複雑すぎてそれ以外では対処できないかのいずれかです。残りの90%のタスクは、自身でホストするオープンソースモデルであろうと、主要なラボのより安価なモデルファミリーであろうと、より小規模なモデルで解決可能です。

自らのモチベーションに任せると、ほとんどの従業員は利用可能な最も高価なモデルをデフォルトで選択します。なぜなら、彼らの目標は単に問題を解決することであり、個々のコストを誰も監視していないからです。Smart Routingは、タスクの複雑さをリアルタイムで評価し、リクエストをフロンティアモデルに送信すべきか、それともより低コストなモデルに送信すべきかを判断するレイヤーを挟むことでこれを解決し、より低いコストで同じ品質の出力を維持することを目指します。

ハーネスルーティングは、モデルルーティングの先にある次のレイヤーです。まったく同じモデルでも、異なるハーネスを通して実行すると、コストに重大な差が生じる可能性があることを示す最新の研究が登場しています。ハーネスはモデルが環境とどのように対話するか（どのようなルールに従うか、いつコンテキストウィンドウを圧縮するか、どのようなビジネスロジックがその動作を制御するか）を決定するため、これは理にかなっています。これらすべてが消費されるトークン数に直接影響します。ハーネスルーティングは、コスト最適化の発展段階における次のステップであり、私たちはUnity GatewayおよびメタハーネスであるOmnigentを通じてこれを実現しています。

支出に関するガードレールの設計

ハードキャップ、予算、レート制限など、支出自体に対するガードレールについて話しましょう。開発者の生産性を損なったり本番ワークフローを中断したりすることなく、過剰なコストを抑えるために、これらをどのように設計するのが適切でしょうか？

Kevin Stumpf: 一部のルールはすべての組織に適用され、その他のルールはユースケースや企業に依存します。暴走した使用を防止するために、誰もがハードな支出制限（ハードキャップ）を設けるべきです。一般的なパワーユーザーのAI使用額が1日あたり高々300ドル程度であれば、ハードキャップをそれよりもやや高め（例えば500ドルなど）に設定します。この余裕があれば、意図しない高使用日制限を設けることなく、ループで誤って実行し続けてしまったエージェントのような本物のエラーを検知できます。

そのベースラインを超えて、チームやプロジェクトごとに差別化された予算を設定することは非常に理にかなっています。CEOにとって極めて重要なプロジェクトに取り組むチームには、優先度の低い作業を行うチームよりもはるかに高い予算が認められる場合があり、その決定は、チームがもたらす価値とより多くの余裕を与えるコストを比較検討して行うべきです。

予算設定は単に処理を強制停止（ハードストップ）するだけでなく、さまざまな種類のアクションをトリガーできるようにする必要があります。例えば、アラートの送信、厳格な上限（ハードキャップ）の設定、利用可能なモデル容量の削減などが可能です。チームが予算の70%を消費した段階でフロンティアモデルへのデフォルトアクセスをカットし、残りのリクエストをオープンソースモデルへルーティングするといった運用が考えられます。あらゆる場面に適用される核となる原則は、コストの暴走を防ぐこと、グループやプロジェクトごとに異なる上限を設定すること、上限に達する前にアラートを出すこと、そして突然停止させるのではなくインテリジェントに容量を削減する仕組みを組み込むことです。

AIが実際にもたらす成果の測定

エージェントの監視とコスト追跡を両立して提供するプラットフォームにはどのようなものがありますか？また、その可視化によって、単なる支出管理にとどまらず実際のROI測定までどこまで踏み込めるのでしょうか？

Kevin Stumpf: コストの測定は、そのコストを投資対効果（ROI）に結び付けることよりもはるかに容易です。しかし、それこそが誰もが答えを求めており、まだほぼ誰も完全に解決できていない問いなのです。これを可能にするのが、セッションレベルやリクエストレベルでのタグ付けです。エージェントが特定のプルリクエストに対応している場合、そのセッションやエージェントが生成するリクエストに、プルリクエストの識別子をタグ付けできます。この帰属情報（アトリビューション）がコストダッシュボードに反映されることで、例えば「特定のプルリクエストの完了に300ドルかかった」といったことが把握できるようになります。これはDatabricks社内でもすでに実践していることです。

理想的な状態では（そしてこれは私たちがUnity Gateway製品に組み込んでいる機能ですが）、さらに一歩進めて、そのプルリクエストを特定の機能に紐付け、その機能を一定期間に創出した売上やパイプラインといった測定可能な成果に結び付けることができます。これこそが究極の目標（Holy Grail）です。単にAIにかかったコストを知るだけでなく、AIが何をもたらしたかを把握することです。Unity Gatewayには、これを構築するための高度にカスタマイズ可能なプラットフォームがすでに備わっており、各チームが自前で構築しなくても、コスト対効果のビューをすぐに利用できるように投資を進めています。

支出の可視化には中央集権型システムが必要

多くのチームにわたって複数のモデル、エージェント、ツールを運用している企業にとって、優れた支出の可視化には実際何が必要なのでしょうか？これはダッシュボードの問題でしょうか、ガバナンスの問題でしょうか、それともFinOpsの問題でしょうか？

Kevin Stumpf: 優れた支出の可視化を実現するには、すべてのAIインタラクションが中央集権型システムを経由する必要があります。これにより、適切な情報を一貫して集約できるため、その上に信頼性の高いダッシュボードやアラートを構築できます。AI Gatewayは、モデル、エージェント、ツール、チーム全体にわたるAIコスト管理のための一元的な制御ポイントを提供します。Databricks Unity Gatewayは、モデル、エージェント、ツール、コーディングエージェントにわたってその一元的な制御ポイントを提供するように設計されています。AIインタラクションが共通の制御ポイントを経由することで、組織は使用状況の監視、コストの割り振り、予算の適用、支出の最適化を単一の場所で行えるようになります。

しかし、中央集権型システムがあるだけでは不十分です。全員が実際にAIトラフィックをそのシステム経由でルーティングするように強制する仕組みも必要です。可視化が機能するのは、導入がオプションではなく、全体で徹底されている場合に限られます。

コスト最適化と出力品質のバランス

コスト管理のために品質や信頼性を犠牲にすることはできません。最適化が行き過ぎて出力に悪影響を及ぼし始めたことを、どのようにして見極めればよいでしょうか？

Kevin Stumpf: それはまさにユースケース次第です。フィードバックメカニズムが必要であり、それには主観的なものと客観的なものの両方があり得ます。主観的なフィードバックとは、「現在の予算内では仕事を完了できない」とチームの誰かが言うような感覚的なものです。手早くい手に入りますが、一人の不満として一蹴されがちです。一方、客観的なフィードバックは自動評価から得られるもので、設定は難しくなりますが、はるかに信頼性が高くなります。

コーディングエージェントのような一般的なユースケースの場合、2週間以内にロールバックされなかったマージ済みプルリクエストなど、品質の代替指標（プロキシメトリック）を定義することが考えられます。そこから実験を行います。予算を半分に減らしてみて、その重要な指標（ゴールドスターメトリック）が変化するか、安定しているか、あるいは制約によって創造性が生まれることで改善するかを確認します。異なる予算、モデル、ハーネスを設定したチーム間で並行実験を行ったり、数週間にわたる期間限定の比較を行ったりすることで、推測に頼るのではなく、特定の予算設定が価値を生み出しているのか、損なっているのかを判断できるようになります。

エンドツーエンド トレーシングの価値

ここでエンドツーエンドのトレーシングとモニタリングはどのような役割を果たすのでしょうか？エージェントのワークフロー全体にわたってプロンプト、ツール呼び出し、トークン使用量を把握できるようになると、これまでできなかった何が可能になるのでしょうか？

Kevin Stumpf: トレーシングとは、エージェントが行っていることの全ログを収集することです。エージェントが何を考えているか、どのツールを呼び出しているか、どんなデータを読み込んでいるか、プロンプトが良いか悪いかなどです。このローデータこそが、不正利用、無駄、セキュリティ漏洩、あるいは思いもよらなかったパターンの特定など、インサイトを掘り起こすための素材となります。

これは、データ業界全般で起きたことと重なります。初期の頃、データベース内にはクリーンな構造化データしかありませんでした。その後データレイクが登場しましたが、価値を抽出する方法がないまま非構造化データが投げ込まれたため、一時期は「データスワンプ（データの沼）」と化してしまいました。最終的にそれらの沼は再び利用可能なデータレイクへと変わり、現在ではLLMが柔軟に処理できるようになったことで、非構造化データや半構造化データからインサイトを抽出するのにかつてないほど絶好の環境が整いました。エージェントのトレースもこれと同じカテゴリーに属します。収集すればするほど多くのインサイトが得られるようになり、しかも今までになく簡単にアクセスできるようになっています。

エージェントフリートへのスケール

多くの企業が単一のAIアプリケーションからエージェントのフリート（群）の運用へと移行しています。1つのアプリの背後で1つのモデルを動かす場合と比較して、このシフトはコスト方程式（新たなコスト要因や新たな盲点など）を変化させるのでしょうか？

Kevin Stumpf: 方程式を変えるというよりは、それを何倍にも拡大させるものです。エージェントのスウォーム（群）が新たな日常になろうとしており、それらすべてのエージェントがトークンを消費するため、帰属情報の記録、モニタリング、管理が必要になります。本番環境で動作するエージェントの数が予測通りに増加する前の「今」こそ、適切なコスト可視化と管理の基盤を整えるべきタイミングです。

現在トークンを最も消費している主要カテゴリーはコーディングエージェントですが、これは24時間体制で自律的に作業を行う多様なクラスのエージェントへと拡大していきます。エージェントが別のエージェントを呼び出し、それがさらに別のエージェントを呼び出すといった構成です。その複雑さが到来するまで中央集権型のAI可視性（オブザーバビリティ）やコスト管理インフラの構築を待ってしまうと、組織は主導権をもってではなく、追いつめられた状態で構築を強いられることになります。

来年に向けて、エンタープライズのAIリーダーにコスト管理に関するマインドセットの転換を1つだけ伝えるとしたら、何になりますか？

Kevin Stumpf: 来年まで待つ必要はありません。これは緊急の課題であり、今すぐ取り組むべきです。1つの考え方に要約するとすれば、「測定できないものは管理できない」ということです。これは原材料にも、人材にも適用され、AIにもまったく同じことが当てはまります。AIは急速に企業のキャッシュフロー計算書における最も重要な費用の1つになりつつあり、測定し、ひいては管理できるようにするために、完全に可視化（インストゥルメンテーション）される必要があります。AIは組織の製品やサービスを生み出すシステムにおけるもう1つの「原材料」にすぎず、他の原材料と同じ規律を持って扱われるべきなのです。

カウントダウンは始まっています 複数のモデルやツールを使用するチーム全体でAIコストを管理することは、単一のダッシュボードや一度限りのモデル選択で解決できる問題ではありません。それは運用上の規律です。支出を個人やプロジェクトまで追跡できるほど粒度の細かいアトリビューション、タスクの要求に応じてリアルタイムで適応するルーティング、問題になる前にコストの暴走を未然に防ぐガードレール、そして生の利用データを真のインサイトに変換できるほど詳細なトレーシングが必要となります。この取り組みで先手を打っている組織は、AIへの支出が最も少ない組織ではありません。支払った費用に対して具体的に何が得られたかを自信を持って言える組織なのです。

Unity GatewayがどのようにAI環境全体のコストアトリビューション、スマートルーティング、支出ガードレールを一元化するかについての詳細をご覧ください。

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