はじめに

Google Cloud Next Tokyo 26のスポンサーセッション「Unity CatalogでつくるセマンティックレイヤーとAIエージェント基盤」（D2-SIL-01）のセッションレポートをお届けします。

企業でAIが業務に浸透しない理由は、モデルの賢さではなくその手前にある、というのがセッションの出発点でした。データはあっても部署ごとに「売上」の定義が違い、AIに聞いても答えが揃わない。その状況を踏まえて本セッションが示したのは、AIエージェントを企業で動かすために、統合データ基盤・ガバナンス・セマンティック・エージェントの4つを下から積み上げるという整理でした。

セッション概要

項目 内容
セッションID D2-SIL-01（スポンサーセッション）
会場・時間 Room 10／12:00〜12:30
登壇者 谷本 成弘 氏、北村 匡彦 氏（データブリックス・ジャパン株式会社）

前半を谷本氏が考え方の整理、後半を北村氏がデモという分担で進みました。

gc-next-tokyo-26-databricks-session-title

1. AIの課題は「知能」から「コンテキスト」へ

出発点は、知能の問題はすでに実質的に解かれている、という認識でした。スライドではその根拠として、最新のモデルは人間でも難しい試験問題を解けるところまで来ていて、かつて汎用人工知能の到達点とされていた水準はすでに超えている、と説明されていました。それでもAIが組織に浸透していないのは、企業の専門用語や業務のコンテキストをモデルが学んでいないからだ、という指摘でした。

gc-next-tokyo-26-databricks-four-c

そこで突破すべき壁として挙げられたのが4つのCです。ロックインされない選択肢のChoice、セキュリティとガバナンスのControl、暴走するAIコストのCost、そして企業文脈のContext。Costについては、気づかないうちに利用料が膨らむ例として、安いモデルがフォールバックした先で高いモデルが回り続ける、という話が挙がっていました。

2. AI-Readyなデータ基盤は4層

4つのCを実現する基盤として示されたのが、下から統合データ基盤・ガバナンス・セマンティック・エージェントという4層の構成です。
以降は、この4層を1つずつ埋めていく流れになります。

gc-next-tokyo-26-databricks-ai-ready-layers

3. ①統合データ基盤

1層目の統合データ基盤は、構造化データと非構造化データをコピーせず1つの基盤で扱う、という考え方です。特徴として挙げられていたのは、データを物理的に持たない点でした。データはGCSなどのクラウドストレージに置いたままで、その上にマウントする形でDatabricksを使う。フォーマットもIcebergのようなオープンテーブルフォーマットを採用しているので、他のエンジンからも読める状態が保たれるとのことでした。

gc-next-tokyo-26-databricks-ltap

ここに新しいカテゴリとして示されたのがLTAP（Lake Transactional/Analytics Processing）です。分析基盤のLakehouseと、Serverless PostgresのLakebaseを1つのストレージの上に並べ、OLAPとOLTPをまとめて扱う。エージェントが業務データを更新した結果をETLやデータコピーなしで分析側に持ってこられるようにする、というのが狙いだそうです。

gc-next-tokyo-26-databricks-lakehouse-rt

もう1つがLakehouse RTです。企業内でエージェントが数千から1万と動くようになると、そのすべてが探して考えるを繰り返すため、クエリの量が人間の分析とは桁違いに増加するそうです。そこに応えるために、レイクハウスからデータを移動させずミリ秒単位で処理するReydenという新しいコンピュートエンジンを載せた、という説明でした。

4. ②ガバナンス

2層目のガバナンスは、Unity CatalogとUnity AI Gatewayの2つで担います。静的なデータ資産の管理をUnity Catalogで、動的な実行時の制御をUnity AI Gatewayで実現する、という分担です。

gc-next-tokyo-26-databricks-unity-ai-gateway

Unity AI Gatewayは現時点でベータで、モデル・エージェント・MCPサーバーを一元的に管理する層になります。ポリシー、予算、レート制限、ID認識型の制御に加えて、プロンプト・トレース・ツール呼び出し・ペイロードログ・ポリシー決定までをキャプチャする、という位置づけでした。人がデータを見に行く前提で作られたガバナンスの隣に、AIが見に行く前提のガバナンスをもう1つ置く、という構図です。

5. ③セマンティック

3層目のセマンティックは、言葉の定義を揃える層です。事業部Aの売上と事業部Bの売上では意味も計算方法も違うため、そのままAIに聞くと違う答えが返ってくる。売上がどういう計算に基づいて出されるのかという意味付けをUnity Catalogに持たせるのがセマンティックレイヤーだ、という説明でした。

gc-next-tokyo-26-databricks-genie-ontology

さらに、定義を揃えるだけでは不十分です。「売上が上がっている理由は何か」との問いに対して、売上の定義だけでは答えは出ないためです。どの商品が売れているのか、利益はどうなっているのか、といった隣り合う言葉まで辿れて初めて答えにたどり着けるので、この関係性をあらかじめ作っておく考え方がオントロジーだそうです。Databricksではこれを担う機能としてGenie Ontologyが用意されていました。材料になるのは、Unity Catalogで人が定義した言葉の意味と、社内の各SaaSに蓄積されたナレッジの2つです。そこから関連する知識を推論するときに利用者の権限も考慮するため、見せてはいけない情報まで辿ってしまうことがないように設計されているとのことでした。

6. ④エージェント

4層目のエージェントは、誰が使うかで入り口が3つに分かれます。

gc-next-tokyo-26-databricks-agent-layer

ビジネスユーザー向けがGenie One、データ/AIチームがエージェントを自作するためのフレームワークがAgent Bricks、サードパーティのエージェントから接続するための口がGenie MCPです。Genie MCPの説明で、1つのMCPでどのエージェントからも接続でき、Unity Catalogの権限とAI Gatewayのポリシーをそのまま継承する、とされていたのが目を引きました。ツールごとに個別の連携を作らずに済み、権限の定義も1か所で済むという整理でした。

7. デモ

デモは3つで、Google Cloudとのデータ連携、Unity AI GatewayによるMCPサーバーの制御、Genie Oneの画面という並びでした。それぞれが4層のどこにあたるかも示されています。

gc-next-tokyo-26-databricks-demo-overview

1つ目は、GCS上のIcebergテーブルをUnity Catalogで管理し、同じデータをBigQueryから参照する流れです。Unity Catalogでテーブルのストレージの場所を確認するとGCSのパスが出てきて、Cloud Storageのコンソールで同じパスを開くと実体のファイルがある。BigQuery Studio側のデータセットにも同じテーブルが見えていて、クエリの結果もDatabricks側と一致する。

gc-next-tokyo-26-databricks-cross-cloud-lakehouse

仕組みとしては、Google Cloud側のFederated CatalogがIceberg REST API経由でUnity Catalogのメタデータを定期的にPullし、データ本体はBigQueryやDataprocがGCSから直接読む形になっています。2回目以降はGCS Local Cacheが効いてEgressを抑えられる、低レイテンシが必要ならCross-Cloud Interconnectを併用できる、といった補足もされていました。

2つ目はUnity AI Gatewayで、GoogleカレンダーのMCPサーバーを登録して払い出されたアドレスをClaudeデスクトップのコネクタに設定し、来週の予定を聞く、というデモです。テーブルデータと同じようにユーザー単位・グループ単位で権限を制御でき、誰がどれだけ呼んだか、レイテンシはどうか、エラーは出ていないかがすべてロギングされる。さらにポリシーとしてPII検出のガードレールを入れておくと、MCPサーバー経由で顧客情報を引き出そうとしたリクエストを拒否できる、という説明でした。

gc-next-tokyo-26-databricks-demo-mcp-guardrail

設定画面では、違反を検出したときの動作として拒否と承認依頼のどちらかを選べるようになっていて、判定にはGeminiが評価者モデルとして指定されていました。何をPIIとして弾くかはプロンプトで書き下ろす形で、社会保障番号やクレジットカード番号、APIキーやアクセストークンは弾き、ツールの引数として普通に使われる氏名やメールアドレスは弾かない、といった具合に線引きされています。

3つ目のGenie Oneは、Databricksとは独立したチャットベースのUIです。ドメインという単位でデータがカタログ化されていて、マーケティング、営業、ネットワーク運用といった切り口で社内に配れるようになっています。デモでは通信ネットワークのカバレッジについて現在の状況と今後のベストアクションを尋ね、状況レポートと次に取るべき打ち手が生成されました。

gc-next-tokyo-26-databricks-demo-genie-one

さいごに

AIエージェントを企業で動かすために、統合データ基盤・ガバナンス・セマンティック・エージェントの4つを下から積み上げるという内容でした。モデルやエージェントそのものの話ではなく、終始その下にあるデータ層の話だったのが印象的でした。特に、人向けのガバナンスとAI向けのガバナンスを別物として置いて、MCPサーバーもテーブルと同じ粒度で権限管理するという整理は、エージェントを増やしていくときの参考になりました。Google CloudのストレージにデータをそのままにしてBigQueryとDatabricksの両方から読める構成も、設計時の選択肢になると思いました。