7月16日、Databricksが「Data-Native AI Agents: Why Agents Must Move to Your Data」と題した記事を公開した。この記事では、AIエージェントを外部スタックに切り出すのではなく、データプラットフォームの内側でネイティブに動かすべき理由と、そのアーキテクチャ上の根拠について詳しく紹介されている。
「データをエージェントに送る」から「エージェントをデータに送る」へ
エンタープライズAIの多くは同じパターンで立ち上がる。LLMにデータを接続し、ベクターDBを挟んで、デモを見せる。問題はその後だ。セキュリティ審査でガバナンスの穴が露見し、マルチステップエージェントのレイテンシがUXを壊し、モデルプロバイダーへの請求が膨らむ。
Databricksはこれらの問題が「データをガバナンス済みシステムから引き出してAIスタックに流す」という構造的な判断から生じると指摘する。その対案として提示されるのがData-Native Agentsアーキテクチャだ。
考え方はシンプルだ。モデルやエージェントをデータの外に置いて接続するのではなく、エージェント自体をデータプラットフォームの内側で動かす。既存のデータスタックが持つガバナンス、セキュリティ、オブザーバビリティをそのままエージェントにも適用する。
ガバナンスは「後付け」では機能しない
記事が最も力を入れて論じているのがこの点だ。
現在主流の「外部エージェント」アーキテクチャでは、ガバナンスは事後処理として実装されることが多い。エージェントがデータにアクセスした後で、レスポンスから機密フィールドをマスクしたり、特定のトピックをブロックしたりする。シンプルなQ&Aデモでは機能するが、エージェントがデータを計算し始めた瞬間に破綻する。
具体例として挙げられているのが財務集計のシナリオだ。行レベルのセキュリティが設定されたデータに対して、エージェントが合計・平均・トレンドを算出する場合、集計結果そのものが「どの行が含まれたか」によって形が決まる。クエリ実行後にレスポンスを削除しても手遅れで、集計の時点でアクセス制御違反はすでに起きている。ポリシーの判断はクエリ計画時点で行われなければ意味がない。
さらに、後付けガバナンスはコストにも跳ね返る。ガバナンスが事後に解決される構造では、エージェントが「自分がこのデータを使っていいか」を自ら判断しようとして、監査ログを巡回したり、複数の外部システムからレコードを重複取得したりする。ブロックやマスクが返ってくるとエージェントは「失敗」と判断して再試行を繰り返し、1リクエストが数千トークンの消費に化ける。元記事はこうした連鎖的なトークン浪費を後付けガバナンスがもたらす典型的な帰結として指摘している。
DatabricksのUnity AI Gatewayが実装するのは、このループを断ち切るアプローチだ。LLMへのリクエスト・レスポンスすべてに対して、モデルに「従うよう指示する」フィルタではなく、ゲートウェイが強制するALLOW / DENY / ASKの決定論的ポリシーを適用する。
エージェントの「記憶」もガバナンス境界の内側に
もう一つ見落とされがちな問題が、エージェントの状態管理だ。
本番エージェントはデータを読むだけでなく、会話履歴、タスクの進捗、ユーザーの設定、ツールの出力を書き込む。この状態データを外部のPostgresやRedisに置いた瞬間、ガバナンス境界に穴が開く。「ユーザーXはEUの高価値顧客だ」というメモリエントリ自体が、その元になったレコードと同じアクセス制御・居住地要件に縛られる個人データだ。
また複数エージェントが協調するマルチエージェント構成では、状態の共有が本質的な難問になる。各エージェントがプライベートな状態を持ってピアツーピアでコンテキストを渡す構造では、真実の一つの源泉（single source of truth）がなく、書き込みの衝突や、エージェント間のハンドオフが新たな未管理チャネルを増やし続ける。
Databricksが提供する**Lakebase**は、この問題に対応するためにプラットフォームに統合されたデータベース機能だ。元記事の定義によれば、LakebaseはDatabricksのデータインテリジェンスプラットフォームに組み込まれており、エージェントの状態をUnity Catalogのガバナンス配下に置くことで、Delta Tableと同じアクセス制御を継承させる。スワーム（エージェント群）全体が同一のトランザクション層を共有するため、どのエージェントが何を書いたかを完全にトレースできる。
2つのアーキテクチャの比較
記事には、外部エージェントとData-Nativeエージェントの比較表が掲載されている。主要な差分を以下に整理する。
| 観点 | Data-Nativeエージェント | 外部エージェント |
|---|---|---|
| ガバナンス | クエリ計画時点でポリシー適用、単一コントロールプレーン | コンポーネントごとにACLを再実装、断片化 |
| セキュリティ | データがVPC内に留まる | データがセキュア境界の外に出る |
| エージェントメモリ | Lakebaseで管理、Unity Catalogのガバナンス下 | 別個のRedis/Postgresで管理、ガバナンス不可 |
| レイテンシ | データの近傍で実行、ネットワークホップが少ない | 外部ストアへの往復が積み重なる |
| コスト | データの一元保存、エグレスコストなし | 重複ストレージ＋エグレス費用が発生 |
| ビジネスコンテキスト | Unity Catalogのメトリクス定義・用語集が自動で利用可能 | カラム名からエージェントが推測するしかない |
「ビジネスコンテキスト」行について補足する。外部エージェントはテーブルのカラム名やスキーマ情報しか持たないため、「売上」「アクティブユーザー」といった用語の定義をエージェントが文脈から推測するしかない。一方、Unity Catalogはビジネス用語集（glossary）やメトリクス定義をカタログとして管理しており、Data-Nativeエージェントはこれを直接参照できる。クエリの解釈ミスや集計定義のずれが、本番での予期せぬ回答品質劣化につながりやすい箇所だ。
エンジニアへの示唆
このアーキテクチャ論が刺さるのは、「AIエージェントを本番化しようとして壁にぶつかっているチーム」だ。PoC段階では外部スタックを雑に繋いでも動く。問題は、スケールアウトしたときに現れる。ガバナンス・コスト・オブザーバビリティの問題がすべて、「データをシステムの外に出した」という初期設計の決定にトレースされる、というのが記事の核心的な主張だ。
実装上の具体的な示唆としては、まずアクセス制御の判断をクエリ計画層で行うことが起点になる。エージェントフレームワーク側でフィルタリングを後処理として実装している場合、財務集計のシナリオで示されたように「計算の時点ですでに制御違反が発生している」リスクを抱え続ける。また、エージェントの状態ストアをデータプラットフォームの外に置く判断は、マルチエージェント構成になった段階で負債として顕在化しやすい。Redis/Postgresを外部に立てること自体が問題なのではなく、そこに書き込まれる状態データがガバナンス境界の外に出ることが問題だ。自社のデータプラットフォームがエージェント状態の管理機能を持っているかどうかを、初期設計の段階で確認しておく価値がある。
Databricksの主張は自社プラットフォームの売り込みを兼ねているが、「ポリシー判断はクエリ計画時点で行われなければならない」「エージェントの状態もガバナンス境界の内側に置くべき」という設計原則そのものは、プラットフォームを問わず考慮に値する論点だ。
詳細はData-Native AI Agents: Why Agents Must Move to Your Dataを参照していただきたい。
