TL;DR
Genieには2種類のコストがあり、簡単にコントロールできるのはそのうち1つだけです。LLM利用量の側はUnity AI Gatewayの予算機能でカバーできます。一方、Genieが起動するコンピュート(SQL Warehouseとサーバーレスジョブ)には同等の管理手段がなく、請求データにGenieのタグも付きません。解決策は、より優れたレポートではありません。Genieのワークロードに専用のコンピュートを割り当て、一貫してタグ付けすることで、請求書が届いてから再構築するのではなく、最初からコスト帰属を組み込んでおくことです。
Databricksのコスト最適化といえば、通常はクラスターのライトサイジングや自動終了ポリシーの見直しを指します。しかしGenieは、こうした定石ではカバーできない厄介な問題を持ち込みます。検索可能な請求項目として一切現れないまま、実際のコンピュートを起動できるワークロードだからです。本シリーズの第1回ではGenieの4つのツールを紹介し、第2回ではGenieの実際のコストを取り上げました。その中では、AI利用量は簡単に測定できた一方でコンピュートは測定できなかった実際のテストも紹介しています。本記事では、このギャップが調査作業以上のコストを生む前に埋める方法を解説します。
このギャップをDatabricks自身が解消する可能性は低いでしょう。Genie Agentの回答やGenie Codeのセッションの多くはSQLやコードを生成して実行しますし、実行こそがコンピュートの役割です。ただし常にそうとは限りません。Genie Agentはテーブルに触れずに一般的な質問に答えることもあり、Genie Codeは実行せずにコードを生成するだけのことも少なくありません。実行が行われる場合、それを生成したAI利用量には明確なラベルが付きます。しかし実行そのものには付きません。この分離は見落としではなく、Databricksの製品設計を反映したものです。だからこそ、解決策もアーキテクチャレベルである必要があります。
請求書を見るだけではGenieのコストがわからないのはなぜか
DatabricksはGenieのLLM利用量に明示的なタグを付けています。すべてのレコードにbilling_origin_product = 'GENIE'が付与されるため、推測なしでフィルタリング、グルーピング、集計が可能です。しかし、Genieが起動するコンピュートはそうではありません。SQL Warehouseの請求書からわかるのは、ウェアハウスがクエリを実行したという事実だけです。そのSQLを人間が入力したのか、Genie Agentが生成したのかはわからないのです。
Gartnerは、2027年までに企業の40%が、本番環境で問題が起きて初めてガバナンスの欠陥が表面化した結果、自律型AIエージェントを格下げまたは廃止すると予測しています。コストの可視性も、まさに同じガバナンスギャップの一部です。財務部門から答えられない質問をされてから帰属の問題に取り組むのは、最も高くつく学び方です。
LLM側の管理で実際にカバーできる範囲は?
Unity AI Gatewayの予算は、アカウント、ワークスペース、ユーザーグループ、個別ユーザー単位でスコープを設定でき、databricks-product: genieのタグが付くため、GenieのLLM支出を確実にコントロールできます。Genie One、Agents、Codeはすべて同じ仕組みで計測されるため、1つの予算でファミリー全体をカバーできます。タグは積み重ねて付与できる仕組みなので、増やしてもトラッキングは壊れません。同じGenie支出をより細かい粒度で見られるようになるだけです。
これはすでに解決済みの問題です。ただし、はっきり言っておきます。Genieの予算を設定しただけで止まってしまうと、リスクの半分程度しかカバーできていません。より大きな残り半分は手つかずのままです。
コンピュート側がはるかに難しいのはなぜか
Genie Agentは、指定されたウェアハウス(通常はワークスペース内の他のすべてが使っているのと同じもの)に対してSQLを実行します。Genie Codeは、生成したコードを実行するためにサーバーレスコンピュートを起動します。どちらにも、デフォルトではGenie固有のタグは付きません。後からGenieのコンピュートコストを調べようとすると、system.billing.usageをsystem.query.historyやsystem.compute.warehouse_eventsと突き合わせ、タイムスタンプを揃えながら、同じ瞬間に他の何も動いていなかったことを祈るしかありません。1回限りのテストならそれでも通用します。しかし、複数のワークロードが同じウェアハウスに触れた瞬間に破綻します。そして実際の環境とは、まさにそういうものです。
McKinseyの調査によると、AIワークロードを運用する組織の93%がすでにAI予算を超過しており、追跡されていないコンピュートはこのパターンの直接的な要因です。後から再構築することでしか把握できない数字は、管理できません。
これは、私たち自身がGenieをテストした際にぶつかった壁そのものです。ebook『Databricks Genie Explained』では、請求テーブルからGenieの実際のDBU使用量を直接取得するために使ったクエリを含め、テストの全容を解説しています。
Genieのコンピュートの帰属先を明確にするには?
可能な限り、ダッシュボードやアドホックなSQLなどとウェアハウスを共有するのではなく、Genieに専用のコンピュートを割り当ててください。Genie Agent専用のSQL Warehouseがあれば、答えようのない問いが単純な計算に変わります。GenieのウェアハウスにそのDBUレートを掛ければ、それがGenie関連のSQLコストです。突き合わせも、タイムスタンプの照合も、推測も不要です。
そのコンピュートには、追跡が必要な他のリソースと同じようにタグを付けます。一貫したウェアハウスタグとサーバーレスの予算ポリシータグを、ワークロードの実行前に適用するのであって、後から再構築するのではありません。FinOps Foundationのアロケーションプラクティスでは、タグ付けとリソースレベルの命名規則を、共有コストや曖昧なコストを帰属させるための基本的な仕組みと位置づけており、Genieのコンピュートはまさにこのプラクティスが解決するために存在する種類の曖昧なコストです。専用コンピュートはワークロードを分離し、タグはそれを識別します。必要なのは両方であって、どちらか一方ではありません。
すべてのAgentに専用ウェアハウスが必要なわけではありません。コストの可視性が本当に重要な、大量利用またはビジネスクリティカルなAgentに限定し、小規模で利用頻度の低いAgentは、利用量が専用ウェアハウスに見合う規模に育つまで共有環境のままで十分です。
Genie Codeの場合はどうか
Genie CodeはGenie Agentよりも分離が難しくなります。実行の一部が、自分でプロビジョニングして名前を付けるウェアハウスではなく、サーバーレスコンピュート上で動くためです。同じように専用ウェアハウスに向けることはできません。ここでは、ユーザー単位の帰属、サーバーレスの予算ポリシー、一貫したタグ付けがより大きな役割を担います。Genie Codeを実行しているユーザーまたはサービスプリンシパルを把握し、その利用にスコープを絞った予算ポリシーを適用し、起動されるサーバーレスジョブにタグを付けて、匿名の請求項目ではなくGenieのコンピュートとして表示されるようにしましょう。
設定後は実際にどうなるのか
タグ付けされ分離された専用のGenieウェアハウスがあれば、これまで突き合わせクエリが必要だった問いが、ダッシュボードを見るだけで答えられる問いに変わります。まさにそれが狙いです。目指しているのは、より賢い事後レポートを作ることではありません。ワークロードの実行場所を変えることで、請求書そのものが最初から答えを示すようにするのです。誰かがGenieのコストを尋ねるたびにsystem.billing.usageをクエリ履歴やウェアハウスイベントと結合する代わりに、1つのウェアハウスタグでフィルタリングして数字をそのまま読み取るだけになります。
Genie Codeも同様です。サーバーレスジョブに一貫したタグと明確な所有者が付けば、「Genie Codeにいくらかかっているのか」は調査課題ではなく、単なるフィルター操作になります。これらの対策はどちらもLLM側には一切触れていませんが、それこそがポイントです。LLM側はGenieの予算ですでにカバーされています。これは純粋に、もう半分を同じくらい見やすくするための施策です。
SELECT for Databricksのようなプラットフォームは、まさにこの種の突き合わせのために作られています。DBU課金を基盤となるクラウドインフラコストと結合することで、Genieのコンピュート側のコストを、誰かが尋ねるたびに手作業でつなぎ合わせる必要がなくなります。
実際に何を、どの順番でやるべきか
まずは予算からです。GenieのLLM利用量に対してUnity AI Gatewayの予算を設定し、databricks-product: genieのタグだけを付け、共有のアラートしきい値に加えて、利用量が突出したユーザー向けのユーザー別しきい値を設定します。ここではハードブロックよりアラートが有効です。共有予算を使い切ると、超過を引き起こした本人だけでなく、スコープ内の全員のGenieが止まってしまうからです。
次にコンピュート側を整えます。利用量が最も多い、またはビジネス上最も重要なGenie Agentに専用のSQL Warehouseを割り当てます。そのウェアハウスと、Genie Codeに紐づくサーバーレス予算ポリシーには、利用がパイロットユーザー数人の規模を超える前に、一貫したタグを付けてください。サービスプリンシパルは別途監視しましょう。どのGenie製品でも無料枠がなく、チャットインターフェースを操作する人間とは異なる形で利用量が拡大するためです。
ここで述べたことは、Genieに固有のものではありません。優れたDatabricksコスト最適化がすでに求めているのと同じ規律、つまり適切にサイジングされたコンピュート、一貫したタグ、そして互いに紛れ込まないワークロードです。Genieは、その規律を向けるべき需要の発生源を1つ増やしただけです。
Genieとは何か、実際のセッションにいくらかかるのか、どうすればコストの帰属先を明確に保てるのか。続きが気になる方は、3つすべてをまとめたebook『Databricks Genie Explained』をご覧ください。
よくある質問
Databricks Genieのコスト最適化とは何ですか?
GenieのLLM利用量と、Genieが起動するコンピュートの両方の支出を、請求書が届いてから再構築するのではなく、可視化して管理可能にする取り組みです。具体的には、LLM利用量に対するUnity AI Gatewayの予算と、Genieが起動するSQLやサーバーレスジョブに対する専用かつタグ付けされたコンピュートを意味します。
Genieの予算でコンピュートコストは管理できますか?
いいえ。databricks-product: genieタグ付きのUnity AI Gatewayの予算がカバーするのはLLM利用量だけです。Genieが起動するSQL Warehouseとサーバーレスコンピュートは別途課金されるため、帰属先を明確に保つには専用のコンピュートとタグ付けが必要です。
Genie Agentに専用のSQL Warehouseを用意すべき理由は?
共有ウェアハウスではGenieのクエリがそこで動く他のすべてと混ざるため、請求書からどの部分がGenie由来かを判別できないからです。専用ウェアハウスがあれば、ウェアハウスのDBUコストがそのままGenieのコストという直接的な計算になり、再構築の必要が一切なくなります。
Genie CodeはGenie Agentよりも帰属が難しいですか?
はい。Genie Codeは自分でプロビジョニングするウェアハウスではなくサーバーレスコンピュート上で動くため、同じ方法では分離できません。Genie Codeでは、専用コンピュートよりも、ユーザー単位の帰属、サーバーレスの予算ポリシー、一貫したタグ付けが重要になります。
SELECT for DatabricksはGenieのコスト最適化にどう役立ちますか?
DatabricksのDBU課金と基盤となるクラウドインフラコストを1か所で突き合わせることで、専用のGenieコンピュートやタグ付けが解決するのと同じ問題、つまり標準の請求データでは通常見えない支出を、その原因となったワークロードに帰属させるという課題に対応します。