Databricksが提唱するデータネイティブ・エージェントの統制境界

Databricksは、データを外部のAI専用基盤へ移すのではなく、エージェントをデータと統制のある場所へ置く「データネイティブ」設計を提唱しました。特に、計算後のマスキングでは遅いという主張が中心です。

要点

• 行レベル権限は集計後に隠しても結果へ影響済みであり、問い合わせ計画と実行時に適用すべきだと論じます。
• Unity AI Gateway、Unity Catalog、MLflow 3、AI Search、Lakebaseを一つの運用境界へ置きます。
• 外部基盤との比較はDatabricksの立場からの設計論で、既存投資や独立性を含む検証が必要です。

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

記事は、LLMをデータへつなぐ試作は簡単でも、本番では権限の分断、ネットワーク往復、データ搬出費用、重複保存、複数製品のログをつなぐ負担が増えると指摘します。外部エージェント構成では、データウェアハウス、ベクトルデータベース、モデル提供元、独自実行層へ統制を再実装する必要があります。対してデータネイティブ構成は、モデル、道具、検索、記憶をデータ基盤内の仕事として扱い、既存のID、権限、系譜、監視を適用する考え方です。

特に重要なのが「後から隠す」統制の限界です。行レベル権限が異なる財務データをエージェントが集計した場合、許可されない行を含めて計算した合計や傾向は、回答文から機密語を削除しても既に影響を受けています。権限判断は問い合わせ計画より前に必要です。DatabricksはUnity AI GatewayのALLOW、DENY、ASK方針で要求と応答を検査し、Unity Catalogで表、関数、モデル、MCP、Skillの権限と系譜を揃え、AI Searchで権限を守る検索を行う構成を示します。MLflow 3はモデル呼び出し、道具、取得文書、評価を一つの追跡へ載せます。

エージェントの状態と記憶も統制対象です。会話、作業途中の状態、利用者の好み、道具の結果を外部RedisやPostgreSQLへ置けば、データ基盤から見えない保管場所が生まれます。Lakebaseを同じ基盤内のトランザクション層として使い、複数エージェントが共有する一つの状態、原子的更新、誰が読み書きしたかの追跡を持たせるという説明です。これはDatabricks製品群の利点を強く押し出した記事であり、外部製品を使う構成が常に劣るわけではありません。既存の認証、リージョン、障害分離、製品切替、費用、データ移動量を比較し、統合による簡素化と単一基盤への集中リスクを同時に評価する必要があります。

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

エージェントの本番基盤を設計するアーキテクト、Unity CatalogとLakebaseを管理する担当、行レベル権限やデータ所在地を監査するガバナンスチームに関係します。

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

「データを動かさない」という標語より、計算前の権限制御と、エージェント記憶まで同じ統制へ入れる点が本質です。自社では外部構成のネットワーク、ログ、権限、状態保管を棚卸しし、どの境界を統合すると事故と運用負担が減るかで判断すべきです。