2026年8月10日

ガバナンスを損なうことなく、Genieエージェントを構造化データとドキュメントの両方にグラウンディングする方法

Genieエージェントは、テーブル、メトリクス、ドキュメントを一度に推論し、コンテキストと権限を考慮したインサイトを提供できます。

によって Doyoung Jung による投稿

• Genieエージェントを構造化データ（管理テーブル、外部テーブル、フォーリンテーブル、ビュー、メトリックビュー、マテリアライズドビュー）および非構造化ファイル（Unity Catalogのボリューム）にグラウンディングさせることで、1つのエージェントがそのすべてにわたって回答できるようになります。
• エージェントのガバナンスは、モデルレイヤーではなくカタログレイヤーに存在します。ガバナンスは制御不能になることなく、エージェントの拡張に合わせてスケールします。
• Unity CatalogにおけるAutomatic Identity Management (AIM)、オブジェクト権限、ABAC、行フィルター、列マスクにより、Genieエージェントはユーザーのアイデンティティとして実行され、すべての回答はそのユーザーの権限によってフィルタリングされます。

簡単なビジネス業務を自動化するエージェントの構築は容易かもしれません。しかし、自社のビジネスを真に理解し、既存のデータガバナンスを尊重するエージェントを作成することは、はるかに困難です。

長年、チームは構造化データと非構造化データを分析するために別々のシステムを使用しなければならず、その2つを連携させるだけで何週間も費やすことがよくありました。テーブルや非構造化ファイルから直接分析できるようにすることで、Genie Agentsはこのアーキテクチャをシンプルにし、単一のエージェントを構造化データと非構造化データの両方でグラウンディング（根拠付け）できるようにします。

このデータを統合するにつれて、重要な疑問が生じます。1つのエージェントがすべてにアクセスできる場合、誤った相手に誤った情報を伝えるのを防ぐにはどうすればよいでしょうか。

幸いなことに、Databricksを使用すれば、その答えはすでに構築されているデータガバナンスの基盤の中にあります。現在信頼しているものと同じ Unity Catalogのメカニズム（ID同期、オブジェクト権限、ABAC、行フィルター、列マスク）が、追加の設定なしで自動的にGenie Agentsを管理します。このシームレスな継承は、適切に設計されたガバナンス戦略に依存しており、これについて詳しく説明します。

これらの概念を具体化するために、架空のグローバルなレンガ小売業者であるBrickstoreの例を参考にしながら、これらのシナリオを進めていきます。

ガバナンスの契約：Genie Agentsはエンドユーザーの資格情報で実行される

アーキテクチャの基本原則はシンプルです。 Genie Agentsはエンドユーザーの資格情報で実行されます。Unity Catalogはデフォルトでガバナンスを強制し、テーブルやボリュームへのアクセスがエンドユーザーの既存のIDと権限に直接紐付けられるようにします。

これは極めて重要です。なぜなら、多くの自社開発システムはエージェントに広範なアクセス権を付与し、モデルレイヤーで結果をフィルタリングするためにプロンプトエンジニアリングに依存しているからです。これにより、事実上LLMがセキュリティ境界になってしまいます。モデルが操作されたりバイパスされたりする可能性があることを考えると、これは危険な賭けです。監査人に対して「制限されたデータを表示しないように指示を追加しました」と説明することは、防御可能なガバナンス管理とは言えません。

この記事で説明するガバナンスフレームワークを使用すれば、Databricksの他の部分と同様に、モデルではなくUnity Catalogがセキュリティ境界であり続けます。Genieはデータを どのようにクエリするかを決定しますが、エンドユーザーが表示を許可されていないレコードを返すことはできません。すべての回答は、Lakehouseから出力される前にデータレイヤーでフィルタリングされるためです。

ステップ0：すべてはIDから始まる：自動ID管理（AIM）とジャストインタイム（JIT）プロビジョニング

アーキテクチャの基盤は、企業のIDが正確かつ最新であることを保証することから始まります。

アクセス制御の信頼性は、根本的に評価対象となるIDの信頼性に依存します。「メンバーの brickstore_apacはAPACの注文のみを表示できる」というポリシーがあっても、Databricks内のグループメンバーシップが、IDプロバイダーにある情報の古い手動コピーであるならば、何の意味もありません。

Automatic Identity Management（自動ID管理）for Microsoft Entra ID and Oktaは、そのギャップを埋めます。これを有効にすると、ユーザー、グループ、グループメンバーシップ、サービスプリンシパルが、SCIMアプリケーションを必要とせずに、これらのIDプロバイダーからDatabricksに自動的に同期されます。ジャストインタイムプロビジョニングは常にオンになっているため、Databricksにログインしたことがないユーザーでも、最初のログイン時にプロビジョニングされ、既存のグループメンバーシップを保持した状態でアクセスできます。

ステップバイステップのフローは以下の通りです。

IdPが信頼できる唯一の情報源（Source of Truth）となります。誰かがAPACの営業組織に加わると、IDプロバイダーはそのユーザーを brickstore_apacグループに追加します。
AIMがそれをDatabricksに同期します（グループメンバーシップを含む）。ユーザーが初めてGenie Oneを開いたときに、JITがDatabricks上にユーザーをプロビジョニングします。
Unity Catalogのポリシーはこれらのグループを基準にします。オブジェクト権限、ABACポリシー、行フィルター、列マスクはすべて、クエリ実行時にグループメンバーシップを評価します。
ユーザーがGenie Agentに質問すると、そのグループ権限で許可されている内容に基づいて正確に回答が生成されます。それ以上でもそれ以下でもありません。

このメリットは、ガバナンスが一時的な設定ではなく、 継続的に行われる点にあります。従業員がAPACからAMERに異動すると、IdPがグループ間でその従業員を移動させ、同期によってそれが反映されます。これにより、その従業員が次にGenieに質問したときには、チケットを起票したりGenie Agentを変更したりすることなく、AMERのビューが返されます。従業員が退職した場合は、IdPで無効化され、すべてのGenie Agentへのアクセス権が即座に削除されます。

ステップ1：構造化データのグラウンディングと4つのアクセスレイヤーの制御

IDが適切に確立されたら、次は表示を許可する対象に焦点当てます。構造化データの場合、Genie Agentは、テーブル、ビュー、マテリアライズドビュー、メトリックビュー、ストリーミングテーブル、さらには外部システムからフェデレーションされた外部テーブルなど、あらゆるUnity Catalogデータアセットにアクセスできます。

たとえば、Deltaテーブルはファクトとディメンションです。Brickstoreでは、これらは brickstore.sales.orders（regionと customer_emailを含むすべての注文）および brickstore.sales.products（レンガのカタログ）にあたります。 メトリックビューは、その上にある管理されたセマンティックレイヤーです。ビジネスメトリックの定義（例：「純収益」の意味、「販売されたレンガ数」の計算方法、「売れ筋のレンガ」の基準など）をYAMLで一度エンコードするため、すべての利用者が同じ方法で計算できます。

これらのアセットの上には、混同されがちな4つのアクセス制御レイヤーが存在します。

レイヤー	解決する疑問	メカニズム
オブジェクト権限	誰がどのリソースに対してどのレベルのアクセス権を持っているか？	`GRANT SELECT`（カタログ/スキーマ/テーブルに対する）
属性ベースのアクセス制御（ABAC）	どのポリシーが何に適用されるか？	一度アタッチすると伝播する、管理されたタグ駆動型のポリシー（例：「PII」タグが付いた列は特定のグループのみが利用可能）
行フィルター	ユーザーはどの行へのアクセス権を持っているか？	クエリ実行時に各行を評価するSQLユーザー定義関数（UDF）（関数がFALSEを返す行はクエリ結果から除外される）
列マスク	どの列をどのようにマスクすべきか？	列の値を入力として受け取り、元の値またはマスクされたバージョンを返すSQL UDF

オブジェクト権限はアクセスの最初のレイヤーです。 SELECTがなければ、Genieはエンドユーザーに代わってテーブルをクエリできません。しかし、テーブルへのアクセスを許可することは、その すべてを許可する必要があるという意味ではありません。これらの許可の上に行フィルターと列マスクを重ねることで、地域マネージャーは注文テーブルをクエリしながら、自分の地域の行のみを表示し、顧客の生のメールアドレスは決して表示しないようにすることができます。これらの行および列の制御は、許可ですでに使用しているものとまったく同じグループ（ is_account_group_member('brickstore_apac')など）を基準にします。次に説明するABACは、これらを置き換えるものではありません。テーブルごとではなく、ポリシーによって同じフィルターとマスクを アタッチする方法にすぎません。

ABAC：ポリシーを一度定義すれば、それを伝播させることができる

従来の行および列のセキュリティ手法は、テーブルごとに行うものでした。行フィルターを作成して ordersにアタッチし、列マスクを作成して別のテーブルにアタッチするという作業を延々と繰り返していました。これは単発のロジックには適していますが、何百ものテーブルに適用する場合、設定漏れが発生しやすくなります。

ABACポリシーは、ガバナンス対象タグや自動データ分類とともにUnity CatalogでGA（一般提供開始）となり、これを逆転させます。機密データにガバナンス対象タグ（アカウントレベルでアクセス制御されたキー/値のペア、例えば pii:emailなど）を付与し、1つのポリシー（「このタグがある場所にはどこでも、この保護を適用する」）を記述するだけです。新しいテーブルはタグ付けされた瞬間にその保護を継承するため、テーブルごとの作業は不要になります。

カタログ内のすべてのメール列を保護するカラムマスク＋ ABACポリシー（1つのステートメントで完結）：

そして、グループメンバーシップに基づいて、各マネージャーが自分のリージョンの注文のみを表示できるようにする行フィルター＋ ABACポリシー：

その結果、APACマネージャーが注文について質問すると、Genie AgentはAPACの行のみを返し、customer_emailはマスクされます。AMERマネージャーが同じテーブルをクエリすると、AMERの行が取得されます。

ステップ 2：同じガバナンスをドキュメントに拡張する

歴史的に、非構造化データを扱う際、チームにとってガバナンス戦略はより困難なものでした。構造化データはデータウェアハウスやデータベースで安全に管理されますが、ドキュメントは個別のACLによって管理される隔離されたストレージシステムに保管されることがよくあります。

解決策は、ファイルを構造化データと同じガバナンスプレーン内に保持することです。ファイルをUnity Catalog Volumesに配置すれば、他のすべてのオブジェクトと同様に保護可能なリソースになります。閲覧を許可するグループやユーザーに「GRANT READ VOLUME」を実行すると、Genieは同じアイデンティティ契約に基づいてそれらを推論します。

エージェントを設計する前に、1つの動作を理解しておく必要があります。Genie Agentにボリュームをアタッチすると、それは必須のソースになります。つまり、エージェントはロード時にアタッチされたすべてのソースへのアクセス権を検証するため、アタッチされたボリュームに対する「READ VOLUME」権限を持たないユーザーは、そのエージェントを一切使用できなくなります。言い換えれば、ボリュームの権限付与は、エージェントを使用するための前提条件としてドキュメントを管理します。そのため、各エージェントのドキュメントソースのスコープを、そのエージェントを使用する対象ユーザーに限定するようにしてください。2つのユーザー層が異なるドキュメントを必要とする場合は、それぞれに異なるGenie Agentを提供する必要があるかもしれません（各エージェントには、そのユーザーが読み取り可能なボリュームのみをマウントします）。

また、Unity Catalog Volumeは保護可能な最小単位であるため、権限は個々のファイルではなくボリューム全体に適用されることにも注意してください。共有する特定のファイルを個別に選択することはできません。ボリューム全体へのアクセスを許可するか、まったく許可しないかのどちらかになります。

これらの点を考慮すると、テーブルやビューの場合と同様に、ボリュームをナレッジソースとしてGenie Agentに直接アタッチできます。Genie Agentが読み取れるのはPDFだけではありません。サポートされているフォーマットには、PDF、画像ファイル（JPG、JPEG, PNG, TIFF, TIF）、Officeドキュメント（DOC, DOCX, PPT, PPTX）のほか、プレーンテキストやMarkdownが含まれます。実質的には、きれいなPDFだけでなく、スキャンされた契約書、スライド資料、仕様書などもすべて対象となります。（全リストと現在の制限については、 Genie Agentのボリュームに関するドキュメントを参照してください。）

正確なルーティングと最適なパフォーマンスを確保するために、ボリュームを設定する際は以下のベストプラクティスに従ってください：

明確な説明を追加する：ボリュームに含まれるコンテンツ、その構成、およびエージェントがそれをどのように使用すべきかを正確に記述します。一般的なプレースホルダーは使用しないでください。たとえば、「地域ファイル」の代わりに「APAC市場レポート — APAC地域の需要要因、トレンド、および注目項目」のように記述します。Genieはこの説明を頼りに適切なボリュームを選択します。
重複するコンテンツを避ける：重複する情報を含む複数のボリュームをアタッチすると、エージェントが関連するドキュメントを検索するのが難しくなります。ボリューム内の個々のファイルについても同様です。
無関係なファイルを避ける：エージェントのドメインに関連するファイルのみを含めてください。無関係なファイルはエージェントを混乱させる可能性があります。
わかりやすいファイル名を使用する：エージェントがファイルを区別できるように、説明的なファイル名を使用します。

ステップ 3：本番環境でのGenie Agent：同じ質問、異なる回答

この時点で、Genie Agentは構造化データと非構造化データの両方に完全にアクセスできるようになり、真のドメインエキスパートとして機能する能力を十分に備えています。基盤となるナレッジベースは、ユーザーごとの権限に基づく行フィルター、カラムマスク、およびボリュームの権限付与によって、依然として徹底的に保護されています。

2人の異なるユーザーにまったく同じ質問をしてもらい、それぞれに対して一意に正しい2つの回答が得られるかどうかをテストすることで、実装のベンチマークを行います。

まったく同じアセット（ordersテーブル、productsカタログ、およびmarket_report ボリューム）に基づく、2つの同時実行されるGenie Agentセッションを考えてみましょう。一方の要求者はbrickstore_apacに属し、もう一方はbrickstore_amerに属していますが、両者ともまったく同じクエリを送信します：

「今四半期のベストセラー製品は何ですか？また、その需要を牽引している要因は何ですか？さらに、それらの売上を支えている上位の顧客とそのメールアドレスもリストアップしてください。」

回答 1 - APACマネージャー向け

回答 2 - AMERマネージャー向け

指摘しておくべき点が3つあります：

数値は異なりますが、どちらも正しいです。両方のマネージャーの「ベストセラー製品」クエリは同じテーブルからデータを取得しています。違いは純粋にそれぞれが権限を持つ行の違いであり、指標の計算方法の違いではありません。
この違いを実現するために、ユーザーごとのプロンプトエンジニアリングは一切必要ありませんでした。「ユーザーがAPACの場合は他の地域を非表示にする」といった記述は誰も行っていません。エージェントへの指示は同一です。Unity Catalogがクエリ実行時に、行とマスクされた列の両方に対してフィルタリングを行いました。PIIを保護するために、メール列がマスクされていることに注目してください。
非構造化知識によって強化された構造化データ。 地域のドキュメントがなければ、Genieは「何が起きているか」という問いを簡単に特定できたかもしれませんが、どのような要因が需要を喚起しているのかを突き止めるのには苦労したでしょう。非構造化データが利用可能であることで、Genieはビジネスに関する完全なコンテキストを把握できます。

注目すべきパターン

このブログで得た学びを本番環境に導入する際に、注意すべきいくつかのパターンを紹介します：

まずはタグ、次にポリシー。テーブルごとにマスクしないこと。目の前にある3つのテーブルを保護したくなるのが本能ですが、そこはこらえてください。将来にわたってデータガバナンスを維持できるように、管理されたタグと ABAC ポリシーを定義しましょう。
1つのボリュームに対して1つのオーディエンス。ボリュームは権限を付与できる最小単位であるため、ドキュメントへのアクセス権はボリュームの境界で決定します。2つのドキュメントで異なる閲覧者が必要な場合は、異なるボリュームと異なる Genie Agent が必要になります。事前にレイアウトを計画してください。
MCP または API を介して外部に Genie One または Genie Agent を公開する場合は注意が必要です。アイデンティティを慎重に処理する必要があります。Databricks UI を介して実行する場合とは異なり、エンドユーザーのアイデンティティを使用する権限が常に付与されるとは限りません（例：認証にサービスプリンシパルを使用する場合など）。採用すべき特定のパターンがあり、Databricks は U2M、M2M、および OBO の構成についてあらゆる場所から Genie にアクセスで詳しく説明しています。
目視による確認ではなく、インパーソネーション（なりすまし）によってテストすること。ポリシーを読んで「これで正しい」と自分を納得させることでガバナンスを検証しないでください。各グループのメンバーとして同じ質問を投げかけ、その回答を比較してください。これを回帰テストとし、ポリシーやグループ化が変更されるたびに実行するようにしましょう。

まとめ

エージェントの構築は簡単かもしれませんが、そのガバナンスを管理するには本格的な設計作業が必要です。Databricks では、エンタープライズアイデンティティが IdP から同期され、オブジェクト権限によってアクセスが制限され、ABAC と管理されたタグによって大規模な保護が適用され、行フィルターと列マスクによって返される内容が制御され、ドキュメントはデータと同じシステム内に保持されます。

この設定により、Genie Agent は追加の設定を行うことなく、すべてのガバナンスを継承します。

最初のガバナンスが適用された Genie Agent の構築を開始するには、Genie のドキュメントおよびABAC ポリシーのドキュメントをご覧ください。

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