データネイティブAIエージェント：なぜエージェントはデータへと移行しなければならないのか

ほとんどの企業のAIパイロットは、同じような低いハードルをクリアすることから始まります。LLMをデータに接続し、ベクトルデータベースを導入し、経営陣にデモを披露する、といったことです。本当に難しいのはその後にやってきます。セキュリティ部門がガバナンスの不備を指摘し、マルチステップのエージェントにおける遅延がユーザー体験を損ない、モデルプロバイダーからの請求額は増え続けます。これらの問題は通常、1つの決定に起因しています。それは、ガバナンスが効いたシステムからデータを取り出し、ポリシーを適用するようには設計されていないAIスタックにデータを移行してしまうことです。

本ブログ記事では、これとは異なるアーキテクチャの方向性を提案します。データを移動させるのではなく、モデルとエージェントをデータの場所に移動させるのです。並行してAIインフラを構築してレイクハウスに接続し直すのではなく、エージェントをデータプラットフォーム内で実行されるネイティブなワークロードとして扱います。これにより、データに対してすでに信頼しているものと同じガバナンス、セキュリティ、オブザーバビリティ（可観測性）の制御を適用できます。

レイクハウスは、データを一元的にガバナンスする場所を提供しました。次の課題は、エージェントをその境界の内部に置くか、それとも外部に置くかです。現在、2つのパラダイムが登場しています。

外部エージェント

エージェントとLLMは、別のAIスタックで実行されます。データはネットワーク経由でエクスポートされるかクエリされ、外部のベクトルデータベース、SaaS LLM、または個別に構築されたサービングレイヤーに送られます。ガバナンス、セキュリティ、オブザーバビリティは、AI用に別途再実装されます。

データネイティブエージェント

エージェント、モデル、ツール、リトリーバル（検索）、エージェントメモリは、データ自体と同じプラットフォーム内で、統合されたガバナンスおよびセキュリティレイヤーのもとで実行されます。AIは、既存のデータスタック上のもう1つのワークロードになります。

外部エージェントの隠れた代償

データには重力があります。コンピュートの再配置は低コストですが、データの移動はそうではありません。特にデータの量が増え、モダリティが多様化するにつれてその傾向は強まります。データを取り出すことで、以下のようなよくあるデメリットが生じます。

• ガバナンスの低下：すべての統合においてアクセス制御、リネージ、データレジデンシーを再実装すると、監査で指摘されるようなセキュリティホールが生じます。
• レイテンシの累積：外部のベクトルストアやLLMへの往復（ホップ）が発生するたびに、複数のツールを使用するエージェント全体で遅延が蓄積されます。
• コストの分散：データ転送（エグレス）料金、重複するストレージ、ベンダーごとのトークン単位の課金により、3つの方向から予算が圧迫されます。
• ライフサイクル管理の複雑化：デプロイパイプラインを共有していないシステム間でスキーマ、インデックス、モデルが乖離（ドリフト）し、ベンダー間の調整が必要になります。
• オブザーバビリティの断片化：1つのリクエストをエンドツーエンドで追跡するために、3つまたは4つのツールのログをつなぎ合わせる必要があります。
• ビジネスコンテキストの喪失：指標の定義、ビジネス用語集、ドメインのグループ化はガバナンスレイヤーに存在しますが、外部エージェントはこれらを列名から再構築するか、推測するしかありません。

なぜ事後的なガバナンスはエージェントにおいて失敗するのか

これらのデメリットの中でも、ガバナンスには特に注意を払う必要があります。なぜなら、ガバナンスは事後にパッチを当てることができないからです。AIガバナンスに対する多くのアプローチは、エージェントがデータにアクセスした後に適用されるフィルターとして扱っています。例えば、回答から機密性の高いフィールドを墨消し（マスキング）したり、出力レイヤーで特定のトピックをブロックしたり、事後にログを監査したりすることです。これはシンプルなQ&Aのデモでは機能しますが、エージェントがデータに対して計算を開始した瞬間に破綻します。

行レベルセキュリティの対象となる行にわたって財務サマリーを計算するエージェントを考えてみましょう。集計自体（合計、平均、トレンド）は、どの行が含まれるかによって決定される派生値です。クエリが実行される前にガバナンスが適用されていない場合、その結果には、ユーザーがアクセス権を持たないはずのデータがすでに反映されてしまっています。下流でどれだけ墨消しを行っても、その計算結果を元に戻すことはできません。ポリシーの決定は、回答のレンダリング時ではなく、クエリの計画時に行われる必要があったのです。

これが、境界ベースまたは事後的なガバナンスにおける根本的なギャップです。つまり、データがエージェントに到達した後に安全に検閲できるという前提に立っていることです。実際には、集計や変換が行われた時点で、ガバナンスの意図はすでに失われています。遡及的な制御は、根本的に不完全です。

これを誤ることによる2つ目のコストがあり、それは請求書に現れます。問題は、エージェントが何にアクセスを許可されているかだけではありません（それも一部ですが）。ガバナンスがソース（データ元）ではなく事後に解決される場合、エージェント自身が整合性の調整を行うことになります。監査ログをトラバースし、外部システム間で断片化されたデータを結合し、同じレコードを複数の場所から取得して使用可能かどうかを判断し、部分的な結果ごとに再推論を行います。これらは本来のタスクではありません。事前に提供されなかった、ガバナンスの効いた回答を補うためにエージェントが苦肉の策をとっているのです。ブロックされた出力や墨消しされた出力は、エージェントがそれを失敗とみなして再試行するため、悪循環を招くだけです。セッションは長引き、ホップごとにモデルにより多くのコンテキストがロードされ、1つのリクエストがいつの間にか数千の課金トークンへと膨れ上がります。これが「トークン消費のループ」であり、事後的なガバナンスがそれを引き起こす原因となっています。

データネイティブエージェントは、ポリシーの適用をクエリの計画と計算に直接組み込むことで、これらの課題に対処します。すべての中間結果に同じガバナンス制約が反映されます。ガバナンスは実行前および実行中に評価される必要があり、計算が完了した後に後付けで適用する余裕はありません。Unity AI Gatewayのカスタムガードレールは、これを具体化したものです。これは、モデルに事後的に従うよう求めるフィルターではなく、ゲートウェイがすべてのリクエストとレスポンスに対して強制する、構成可能で決定論的なポリシーです。すでにガバナンスが効いた一元的な場所にあるデータに対して、計画時にポリシーを決定することは、エージェントがシステム間を探索してデータを組み立てたり正当化したりする代わりに、1回のパスで明確な回答を得られることも意味します。

エージェントの状態とメモリにもガバナンスが必要

これまでは、エージェントがデータをどのように読み取るかに焦点を当ててきました。しかし、本番環境のエージェントは書き込みも行います。会話履歴、タスクの進捗、ユーザーの好み、キャッシュされた結果、後で監査するためのツールの出力などです。エージェントがより多くの役割を担うようになるにつれ、データレイヤーと同様に状態（ステート）レイヤーも重要になります。これをガバナンスの境界の外に置いてしまうと、エンドツーエンドの監査可能性という約束に穴が空くことになります。

状態（ステート）とは、エージェントの短期的なスクラッチパッド（メモ帳）です。進行中の会話、実行中のタスク、入力されたばかりのキャッシュなどがこれに該当します。メモリとは、セッションを超えて存続するものです。エージェントが対応した顧客、ユーザーの好み、再利用する価値のある過去の出力などです。どちらもトランザクションストレージを必要とし、プラットフォームを離れた瞬間にガバナンスが漏洩します。「ユーザーXは優良なEU顧客である」といったメモリ自体が機密データであり、それが要約するレコードと同じアクセスルールやデータレジデンシールールに縛られます。また、これはトランザクションワークロードです。Deltaテーブルは大規模な分析スキャン向けに構築されていますが、エージェントの状態には、高速な行ごとの読み書き、キー指定のルックアップ、アトミックな更新が必要です。

一般的な回避策は、外部のPostgresやRedisを使用することです。しかし、それでは本記事で反対している問題に逆戻りしてしまいます。エージェントの状態が、ガバナンスレイヤーからは見えないシステム（独自のセキュリティやライフサイクル管理が必要なシステム）へと、ガバナンスの境界線を超えて出ていってしまうのです。これでは、ガバナンスの効いていない依存関係を持つデータネイティブエージェントを構築したことになってしまいます。

そして、1つのエージェントが複数のエージェント（スウォーム）になると、この問題はさらに大きくなります。より大きな成果に向けて連携するスウォーム（スペシャリストに権限を委譲するプランナーや、その結果を調整するスーパーバイザーなど）には共有メモリが必要ですが、その整合性を維持する部分でシステムが破綻しがちです。各エージェントがプライベートな状態を保持し、ピアツーピアでコンテキストを渡す場合、信頼できる唯一の情報源（Single Source of Truth）が存在しなくなります。エージェント間で不一致が生じ、書き込みの競合が発生し、スウォームが拡大するにつれて、すべてのハンドオフがガバナンスの効いていないチャネルとして増殖していきます。メモリの交換こそが、最も難しい部分であることがわかります。

Lakebaseはこれらのギャップを埋めます。これは、Databricksプラットフォーム内の完全に管理されたPostgreSQLストレージであり、他のすべてと同じガバナンスプレーンのもとにあります。エージェントの状態はガバナンス対象のアセットになります。プラットフォームのアクセス制御を継承し、エージェントのデータやツールと共存し、個別のインフラチームを必要としません。そして、すべてのエージェントがその同じトランザクションレイヤーを読み書きするため、スウォームの信頼できる唯一の情報源としても機能します。状態は一貫して保たれ、アトミックな更新によって2つのエージェントが同じタスクを破損するのを防ぎ、1つのエージェントのビューに対するポリシーが次のエージェントのために書き込む内容に引き継がれ、あらゆるメモリをスウォーム全体で追跡できます（どのエージェントがそれを書き込み、どのエージェントがそれを読み込み、どのようにして深い結論がそのソースに到達したかなど）。

データネイティブエージェントを支持する理由

ガバナンスに関する議論が最も説得力がありますが、メリットはそれだけにとどまりません。エージェントがデータスタック内で実行されると、セキュリティ、品質、オブザーバビリティ、デプロイ、レイテンシ、コストなど、あらゆる運用の側面で相乗効果が生まれます。ツールとデータの依存関係はモデルとともに構成およびログ記録されるため、システム全体がデフォルトでバージョン管理され、監査可能で、再現可能になります。

以下の比較は、本番システムにとって最も重要な側面において、これら2つのパラダイムがどのように異なるかをまとめたものです。

Databricksにおけるデータネイティブエージェントの実際の姿

データインテリジェンスプラットフォームは、これを実用化します。個別の「AIスタック」を構築してデータに接続する代わりに、データスタック自体の内部にAIエージェントを構築します。Databricks上のデータネイティブエージェントとは、以下のようなエージェントです。

• すべてのモデルとエージェントのトラフィックをUnity AI Gateway経由でルーティングします。ここでは、実行前にすべてのリクエストがチェックされ、実行後にすべてのレスポンスが検査されます。事後のベストエフォート型のフィルタリングに代わり、決定論的なALLOW / DENY / ASKポリシーが適用されます。アクセス制御、レート制限、ペイロードログ記録、コスト追跡はすべて、外部のLLMプロバイダーやコーディングエージェントへの呼び出しを含め、同じコントロールプレーンに存在します。
• すべてのAIプリミティブ（モデル、エージェント、MCP、スキル、およびそれらが呼び出すツール）を、テーブルや関数と並んでUnity Catalogのアセットとして扱います。これにより、アイデンティティ、リネージ、アクセス制御がAI環境全体に一律に適用されます。
• MLflow 3を通じて完全なリクエストトレースをキャプチャします。すべてのLLM呼び出し、ツール呼び出し、スコア、評価、取得されたドキュメント、およびエンドツーエンドのモニタリングループが、コンプライアンスのための監査やデバッグのための観察が可能になります。
• サードパーティのAIスタックへの管理外のデータ移動を行うことなく、Databricksのセキュリティ境界内のModel Serving上で推論を実行します。
• AI Searchを活用し、Unity CatalogのACLを尊重し、リネージを自動的に追跡するDeltaベースのインデックスからコンテキストを取得します。
• Lakebaseベースの状態とメモリを通じて、セッションをまたいで記憶を保持します。短期的な会話コンテキスト、複数ステップのタスクの進行状況、長期的なユーザーの好み、過去のツール呼び出しのエピソード記憶が、エージェントが推論するデータと並んで存在します。
• Unity Catalog Semantics（メトリクス、ビジネス用語集、ドメイン）およびGenie Ontology（チームがすでに使用しているテーブル、クエリ、ダッシュボード、アプリから抽出され、自動的に維持されるナレッジグラフ）を通じて、ビジネスコンテキストに即した推論を行います。
• 構造化データに関する質問に対応するGenieなど、他のエージェントに専門的な推論を委任し、プラットフォームの境界内でドメイン横断的かつ複数ステップの調整を行います。
• Claude Code、Codex、Cursorを共有セッションと共通の監査証跡とともにUnity AI Gateway経由でルーティングするメタハーネスであるOmnigentを通じて、同じガバナンスをコーディングエージェントにも拡張します。

何から始めるべきか

一部の企業は、すでにこのような方法で構築を進めています。彼らのエージェントはデータと同じ境界内で実行され、Unity Catalogポリシーがその両方をカバーし、状態はLakebaseに保存され、トラフィックはUnity AI Gatewayを経由します。一回限りのプラットフォーム再構築プロジェクトだけでそこに到達した企業はありません。彼らはレイクハウスとAIスタックの間の隙間をパイロットプロジェクトごとに1つずつ埋めていき、新たな隙間を作らないようにしました。

この道のりの初期段階にあるチームにとって、その作業は劇的なものではありません。Model Serving、Unity Catalog、Lakebase、MLflowなど、ほとんどの要素はすでにプラットフォーム側に存在しています。欠けているのは、これらを並行するスタックのデータソースとしてではなく、エージェントの「ホーム」として扱うという決断です。そして、その決断こそが最も困難な部分となる傾向があります。

最も効果的な開始点は、すでに境界の外側で実行されているもののインベントリ（一覧）を作成することです。次のガバナンスインシデントはそこから発生する可能性が高く、その整理作業こそが他のすべてを可能にする土台となります。

適切なガードレールとパターンを用いてデータネイティブエージェントを運用する方法についてさらに深く知りたい場合は、以下のリソースが次のステップとして最適です。

• 戦略を具体的なコントロールに落とし込むには、A Practical AI Governance Framework for Enterprises（企業向けの実用的なAIガバナンスフレームワーク）をご覧ください。ここでは、Databricks Data Intelligence Platform上で、ハイレベルな目標をロール、ポリシー、ワークフローに変換する方法を説明しています。
• 実践における責任あるAIのより広い視野を得るには、AI Governance Best Practices: How to Build Responsible and Effective AI Programs（AIガバナンスのベストプラクティス：責任ある効果的なAIプログラムを構築する方法）で、チーム全体で採用できる原則と運用モデルを紹介しています。

このブログ投稿で取り上げたプラットフォーム機能について詳しく調べるには：

• Unity AI Gateway: What’s New at Data + AI Summit 2026 — 決定論的なALLOW/DENY/ASKカスタムガードレールを備えた、すべてのモデルおよびエージェントトラフィック用の単一のコントロールプレーン。
• Agent Bricks: Data + AI Summit 2026 — プラットフォーム上でファーストクラスの管理されたワークロードとして提供される、自動最適化されたエージェント。
• Omnigent: A Meta-Harness to Combine, Control and Share Your Agents — 共有監査証跡とともに、コーディングエージェント（Claude Code、Codex、Cursor）をUnity AI Gateway経由でルーティングします。
• Introducing Genie One, Genie Agents, and Genie Ontology — エージェントをビジネスコンテキストに即したものにする、自動維持されるナレッジグラフ。
• Memory Scaling for AI Agents — プラットフォーム内のUnity Catalogによって管理される、Lakebase上でのエージェントの状態とメモリの拡張方法。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事