Databricks Genie、質問・構築・エージェント連携の実装例

Databricksは、第5回顧客向けGenie Hackathonの10プロジェクトを、データへ質問するGenieエージェント、分析資産を作るGenie Code、Genieを別のエージェントへ組み込む方法の3つに整理して紹介しました。製品発表ではなく、各機能をどの役割と規模で使うかを示す実装事例集です。

今回のブログ記事で語られていること

第1の形は、管理されたデータへ自然言語で質問するGenieエージェントです。分析担当者がUnity Catalogのテーブル、例示クエリ、SQL式、指標ビュー、信頼済み関数を設定し、業務利用者へ共有します。OneTrustの事例では、1エージェントが集中して扱う目安を最大30テーブルとし、190テーブルと300超のビューを複数の専門エージェントへ分け、監督層が質問を振り分けました。大規模データを一つの会話窓へ詰め込まず、領域別に分割した点が重要です。

第2の形は、Genie Codeに指標ビュー、Unity Catalog関数、パイプライン、ダッシュボードを作らせる方法です。紹介例では、使われていない報告書や重複報告を系譜とSQLから探すガバナンス基盤、宿泊施設の分析画面、顧客離反モデルの再検証などをハッカソン期間内に構築しました。作業時間の短縮例はありますが、生成物の正確性や本番品質を自動的に保証するものではなく、SQL、指標、モデル評価のレビューが必要です。

第3の形では、Genie Conversation APIとDatabricks管理のMCPサーバーを使い、Genieエージェントを別のエージェントが呼ぶツールにします。ShipBobは倉庫データと17の公開情報源から夜間の業務要約を作り、人の承認待ちの更新操作を用意しました。Rippleは社内CRMと外部の制裁・執行情報を合わせた顧客確認資料を作り、従来3〜4時間の調査を1分未満にしたと報告しています。これらは参加企業のプロトタイプ事例であり、全環境で同じ時間短縮を示すものではありません。

3形態に共通するのは、Unity Catalogで権限を保ち、Genie Ontologyや指標ビューで業務上の意味を与え、MLflowで処理を追跡する設計です。自然言語から利用できても、元データへの権限を越えてよいわけではありません。複数エージェントを組み合わせる場合は、各ツールの入力・出力、書き込み権限、人の承認、外部情報の出典を明確にする必要があります。

今回のブログ記事が関係する人

Genieを業務利用者へ展開する分析担当者、Genie Codeでデータ資産を作る開発者、MCPやDatabricksアプリで複数エージェントを構成する基盤チームに関係します。一つのGenieエージェントで多数のテーブルを扱おうとして精度や速度に課題がある組織にも参考になります。

利用前に確認したいこと

• 1エージェントが扱う業務領域とテーブル数を絞れているか
• 業務用語、指標、信頼済み関数を誰が承認・更新するか
• Genie Codeが作ったSQL、パイプライン、モデルを人が検証する手順
• MCPツールの読み取り・書き込み権限と人の承認地点
• 外部情報を使う要約で出典と処理履歴を追跡できるか

結局、今回のブログ記事をどう読むべきか

この記事は、Genieを一つのチャット機能としてではなく、質問、構築、他エージェントのツールという3層で使い分ける実装例です。ハッカソン成果の速度や効果は本番実績として一般化できませんが、領域別エージェント、管理された指標、承認付きの書き込みという設計パターンは参考になります。自社では一つの領域から始め、回答根拠と権限を確認してから構成を広げるのが適切です。