EDB Semantic LayerがPostgres内にエージェントのアクセスルールを組み込む
AWSは、エージェントが読み取れる情報をプロンプト指示ではなくデータベース権限で管理するEDB semantic layerのウォークスルーを公開した。11月3日に公開されたこの例では、EDB Postgres AIを、ソフトウェアエージェントのホスティングと接続を担うAWSサービスであるAmazon Bedrock AgentCoreと接続している。中心的な提案は具体的だ。ビジネス定義を運用データの近くに置き、クエリが実行される場所でアクセスを強制する。
セマンティックレイヤーは、ビジネス上の言葉をデータベース構造や計算と結び付ける。ここでは、ツールを呼び出すエージェントを構築するフレームワークであるStrands Agentsを使用し、顧客活動に関する質問に回答する。課題は、柔軟なクエリ生成と信頼できる制御の間にある。アシスタントには質問を解釈する十分な自由度が必要な一方、データベース所有者にはアクセス範囲に対する予測可能な制限が必要だ。
分散ソースをクエリするデータ仮想化プラットフォームDenodoとの比較は、EDBのアプローチを位置付ける助けになる。両者ともエージェントにビジネスコンテキストを提供するが、そのコンテキストを異なるデータアーキテクチャを中心に構成する。開発者とエンタープライズの購入担当者にとって、当面の問いは、定義と権限をどこに置くべきか、そして誰がそれらを保守すべきかだ。
EDB semantic layerはデータベースの意味を発見可能にする
この変更は、既存のデータベース定義を外部エージェントが利用できるようにする統合パターンである。
agentic semantic layerのウォークスルーは、EDBのAIDBデータベース拡張機能とAWS上で稼働するエージェントを組み合わせる。顧客の例では4つのテーブルと派生ビュー、すなわちデータベースオブジェクトとして提示される保存済みクエリを使用する。ビジネス上の説明はデータベースコメントから取得し、関連レコードを結び付ける制約である外部キーが結合関係を提供する。
AWSによると、この例ではプロンプトとエージェントコードを一定に保ったまま、データベース認証情報を変更する。制限付きロールは、保護された社会保障番号の列を取得できない。これは有用な違いだ。アシスタントが回答を作成する前に、データベースがアクセス試行を拒否する。
これはあくまでベンダーが作成した参照例である。エンタープライズ全体での信頼性を独立して証明するものではなく、提案された実装とサンプル動作を示している。導入準備性について結論を出す前に、読者はこれらの主張を区別すべきだ。
EDBのドキュメントは、データベース構造と説明の検索可能なインデックスである基盤のsemantic knowledge baseを説明している。これは顧客レコードを埋め込むのではなく、テーブル、ビュー、列、コメントをインデックス化する。類似性照合に用いる数値表現である埋め込みにより、エージェントは自然言語の質問を通じて関連するデータベースオブジェクトを見つけやすくなる。
この違いは評価において重要だ。正しい構造を見つけても、生成された計算が正しいことまでは証明されない。モデルがクエリを組み立てるための材料を改善するにとどまる。チームは依然として、回答を承認済みのビジネス結果と比較する必要がある。
EDB semantic layerの解説を求める人にとって、有用な出発点は発見と強制の分離である。説明はエージェントがデータの意味を判断する助けとなる。権限は、提案されたクエリがそのデータにアクセスできるかどうかを決定する。
この配置は所有権も変える。データベースコメントは、開発者が時折参照するだけのドキュメントではなく、エージェントの作業コンテキストの一部となる。不正確な説明は、誤解を招くアプリケーションインターフェースと同等の注意を払うべきだ。
仮に、購入フィールドの名前から、それが単価なのか注文合計額なのか分からないとする。どちらの解釈も有効な算術計算を支える。だがビジネス定義に一致するのは片方だけであり、実行が成功しただけでは誤りを特定できない。
このアーキテクチャがサンプルデータセットを超えて重要となる理由はそこにある。その価値は、チームが曖昧なデータベース慣行を、保守され発見可能な定義へと変換できるかにかかっている。エージェント接続は、その作業を消し去るのではなく、前提条件として表面化させる。
データベース所有者はエージェント運用の一部を担う
意味をPostgresに移すことで、データベースチームは回答品質に直接関与することになる。
直接的な負担は、スキーマ、レポーティング定義、アクセス方針を所有する人々にかかる。アプリケーションチームはアシスタントへの指示を改善できるが、未確定のビジネス定義を表現だけで解決することはできない。
例えば、営業部門と財務部門でアクティブ顧客の定義が異なる場合を考える。一方は最近の購入を数え、もう一方は良好な状態のアカウントを要件とする。エージェントが説明なしにどちらかの解釈を選べば、組織の実態以上に確定したように見える回答を作り出す。
定義をデータの近くに置けば、その不一致を解消する場所が生まれる。しかし、それだけでどの部門が正しいかは決まらない。誰かが定義を承認し、その適用範囲を説明し、変更を管理する権限を持つ必要がある。
このため、アーキテクチャと並行して運用上の負担にも注意を払うべきだ。このパターンを採用するチームは、データベースの意味に関する継続的な編集作業を見込む必要がある。説明のレビューは、ソフトウェアエージェントが利用するインターフェースの保守の一部となる。
同じことはテーブル間の関係にも当てはまる。技術的に有効な接続が、質問に必要なビジネス関係を自動的に表すわけではない。購入担当者は、既存のデータベース構造がレポーティング要件を反映しているのか、それともアプリケーショントランザクションを支えるだけなのかを問うべきだ。
この違いは、顧客が複数の住所、アカウント所有者、または過去の分類を持つ場合に明らかになる。現在の担当地域に関する質問には、注文時点の担当地域に関する質問とは異なる解釈が必要だ。いずれの回答も、文書化されていない前提に依存すべきではない。
これらは評価シナリオであり、EDBの実装で報告された障害ではない。より強力なスキーマ発見にも、どこでビジネス判断が必要かを示している。有用なパイロットでは、前提が変わると答えも変わる質問を意図的に含めるべきだ。
人員配置への示唆は直接的である。エージェントチームは、すでにレポーティング上の論争を解決している人々にアクセスできる必要がある。そうでなければ、アプリケーション開発者が、定義する権限を持たない指標の非公式な所有者になるリスクがある。
したがって、エンタープライズの購入担当者は、エージェントのデモと並行して保守プロセスを評価すべきだ。変更された定義を誰が承認するのか。どのアプリケーションがそれに依存するのか。アシスタントが古い解釈を使っていることを組織はどう発見するのか。
エンジニアリングチームにとって、searchable knowledge baseは、そうした決定の背景にある考え方を保存できる。データベース定義と裏付けとなるドキュメントは、異なるシステムに存在していても関連する目的を果たす。
短期的な課題は、信頼できるパイロットを準備することだ。長期的な課題は組織的なもの、すなわちアプリケーション、レポーティング要件、人員が変わってもビジネス定義の一貫性を保つことである。このアーキテクチャはその責任をより可視化するが、誰かが引き受けて初めて有用になる。
レビュー済みクエリは柔軟なエージェントに安定した参照を与える
繰り返し発生するビジネス上の質問には、利用者が異なる言葉で尋ねる場合でも、再利用可能なクエリロジックが必要である。
EDBは、検索可能な自然言語の説明と定義済みパラメータを組み合わせた名前付きクエリであるsemantic aliasesを文書化している。エイリアスには、結果を取得するクエリである単一の読み取り専用SELECTを含める必要がある。EDBによれば、エイリアスの作成時と実行時にこの制限を検証する。
アーキテクチャ上の含意は、固定的なレポーティングインターフェースと無制限のクエリ生成の中間にある道筋だ。利用者はよくある依頼を会話形式で表現でき、システムには参照として利用可能な既存クエリがある。
仮想的な地域別売上レポートでは、レビュー済みのロジックがレポーティング期間、顧客分類、キャンセル済み注文の扱いをすでに指定している可能性がある。こうした決定は、利用者が依頼をどのように表現するかが変わっても維持されるべきだ。
これは、モデルに毎回すべての判断を再構築させることとは異なる。既知のロジックを再構築すると、ばらつきが生じる機会がさらに増える。再利用により、レビュー担当者はより小さく具体的な対象を検査できる。
ただし、保存済みクエリだけで解釈の問題が解決するわけではない。エージェントはなお、適切なクエリを特定し、適切なパラメータを指定しなければならない。四半期ごとの活動という依頼が、最新の暦四半期に関する依頼へと黙って変換されるべきではない。
これにより、異なる評価項目が生まれる。システムは意図されたビジネス上の質問を認識したか。適切な期間と範囲を選択したか。返された説明は、クエリが測定した内容を正確に表しているか。
好ましいデータベース結果は、その連鎖の一部にしか対応しない。アシスタントは正しいレコードを取得しても、それを誤って要約する可能性がある。逆に、流暢な説明が、近接した別の質問に答えたクエリを隠すこともある。
実務的な対応は、繰り返しの依頼に対する参照回答を維持することだ。チームは表現、日付、ユーザー権限を変えながら、生成された回答を参照回答と比較できる。これにより、利用者が実際に遭遇する挙動をテストできる。
レビュー済みロジックは、より明確な変更プロセスも生む。ビジネスが定義を変更した場合、保守担当者は該当するクエリを特定し、影響を受ける出力を評価できる。共有された参照がなければ、同等の定義がエージェントアプリケーション間で乖離する可能性がある。
この利点には境界がある。高度に探索的な質問では、既存のクエリカタログを超えた解釈が依然として必要になる。購入担当者は、近い一致がない場合にシステムがどのように振る舞うか、特に明確化を求めるかどうかを評価すべきだ。
重要な製品上の挙動は、正直な不確実性である。曖昧な依頼を識別するツールは、利用者に方向を修正する機会を与える。不適切な定義を自信を持って選択するツールは、その判断を隠してしまう。
したがって、EDBのアプローチは、再利用可能な意味とクエリロジックを整理する方法として評価するのが最適だ。その有用性は、検索品質、パラメータ処理、レビュー慣行が連携して機能することに依存する。いずれも、別の成功したデモから推測すべきものではない。
Denodoはデータベースローカルな意味の境界を浮き彫りにする
EDBとDenodoの比較は、データ配置と運用責任にかかっている。
AWSの以前のdata virtualization architectureでは、Denodoを使用して、Amazon Aurora、Amazon Redshift、オンプレミスのPostgreSQLデータベースにまたがる顧客情報を接続している。データ仮想化は、共有クエリレイヤーを通じて分散ソースを提示する。そのウォークスルーでは、ビジネスビューとアクセス方針をDenodoに配置している。
一方、EDBの例では、その運用Postgresデータベース内に意味を集約している。この比較は、パフォーマンス上の勝者を示すものではない。ビジネス定義をどこに置くべきかを判断する際の、異なる出発条件を示している。
関連データがすでに一箇所にまとまっているチームにとっては、データベース内で定義を管理する方式は検討に値する。組織面での魅力は明快だ。既存のデータベース管理者には、回答を形づくるオブジェクトを確認するための使い慣れた場所がある。
顧客情報が独立した複数システムにまたがるチームでは、中心的な課題はより広い。システム間で識別子、意味、権限を整合させなければならない。エージェントのインターフェースを追加しても、こうした統合に関する判断が不要になるわけではない。
したがって、有用な EDB と Denodo の比較は、ビジネス上の問いがどこまで及ぶかに関わる。組織は、すでに運用しているガバナンス管理済みのデータベースから回答できるのか。それとも、その回答には複数のソース間での調整が必要なのか。
たとえば、更新対応が必要な顧客を知りたいというアカウントマネージャーを想定してみよう。購入履歴だけでは不十分かもしれない。契約状況、未解決のサポート案件、アカウントの担当者はいずれも回答に影響し得る。
それらの記録が別の場所にある場合、データベース中心のパイロットでは、その制約を明らかにすべきだ。そうしなければ、利用可能な記録に基づく正しい回答が、完全なアカウント評価だと誤解されかねない。欠けているソースは、技術的な成功に見せかけたビジネスリスクになる。
分散型アプローチにも、独自の評価負担がある。ソースを接続しても、その定義が一致していることが自動的に証明されるわけではない。購入者は、競合する識別子や報告期間をシステムがどのように調整するのかを依然として確認する必要がある。
両方のアプローチに共通する中心的な緊張関係は同じだ。柔軟なエージェントには、維持管理された意味と強制可能なアクセス制御が必要である。アーキテクチャの選択は、こうした責務がどこに集約されるかを決めるのであって、それらをなくすものではない。
これが、コネクタ数が不完全な購入基準にとどまる理由でもある。コネクタは情報への経路を確立する。しかし、特定の問いに対して、接続されたすべてのソースにまたがる合意済みの意味を確立するわけではない。
チームは、代表的なビジネス要求とその完全な依存関係を用いてアーキテクチャを比較すべきだ。ソースの所有者、承認済みの計算、アクセス制限、期待される説明を含める。そうすることで、エージェント機能に関する一般論以上のことが明らかになる。
EDB にとっての機会は、既存のデータベース構造をエージェントの信頼できる基盤にすることにある。同時に、その境界も明確だ。組織は、その基盤がユーザーが実際に尋ねる問いのどこまでをカバーするのかを確立しなければならない。
権限は依然として Postgres に到達するアイデンティティに依存する
データベースのアクセスルールが意図したユーザーを保護できるのは、クエリが適切なロールで実行される場合に限られる。
EDB の MCP server は、エージェントが外部ツールを呼び出すための標準インターフェースである Model Context Protocol を使用している。そのドキュメントによれば、ツール呼び出しは認証済みの Postgres ロールとして実行される。その後、データベース権限によって、そのロールが実行できる内容が決まる。
これは本番チームにとって具体的なレビュー項目となる。アプリケーション境界で個人を認証することと、下流のデータベースアイデンティティを選択することは、別個の責務である。レビュアーは、ユーザー固有のアクセスに関する主張を受け入れる前に、その両方を追跡すべきだ。
仮に共有のレポーティングアカウントを考えると、この問題が分かりやすい。すべてのリクエストがそのアカウントでデータベースに到達するなら、データベースルールはそのアカウントの権限を評価する。パーソナライズされたアプリケーションインターフェース自体が、パーソナライズされたデータベース強制を確立するわけではない。
これは、共有アカウントが常に不適切だという意味ではない。その権限が、意図されたサービス境界に適合しなければならないということである。限定的な範囲のレポーティングアシスタントと、異なるアクセス権を持つユーザーにサービスを提供するアシスタントでは、必要要件が異なる。
PostgreSQL の 行セキュリティポリシー は、ロールがアクセスできるレコードを制限する。適用可能なポリシーなしで有効化された場合、行セキュリティはデフォルトで拒否となる。ただし、スーパーユーザーと BYPASSRLS を持つロールはこれらの制限を回避し、テーブル所有者も通常は強制的に従わせない限り回避する。
エージェント接続をテストする際には、こうした文書化された例外が重要になる。管理者アカウントを用いたデモンストレーションでは、通常ユーザー間の分離を証明できない。評価者は、実際のリクエスト経路における有効なロールとその権限を確認する必要がある。
列の制限と行の制限も、それぞれ異なる問いに答える。機密フィールドを隠しても、別の顧客のレコードにアクセスできないことは証明されない。説得力のある評価では、アプリケーションが約束するアクセスの次元をテストすべきだ。
その評価には、別の質問を通じたアクセス試行も含めるべきである。機密フィールドを直接要求することは有用だが、ビジネス要求では許可された属性が予期しない形で組み合わされる場合がある。レビュアーは、アプリケーションが何を返すか、また制限をどう説明するかを確認すべきだ。
権限制御は、回答の正しさも保証しない。ロールには、エージェントが誤って結合するレコードを読む権限が与えられている可能性がある。セキュリティ評価と分析評価は、それぞれの証拠を伴って別個に維持すべきである。
読み取り専用アクセスにも同様の厳密さが必要だ。書き込みを防ぐことで、エージェントがその経路を通じて変更できる内容は制限される。しかし、認可された結果に、特定のコンテキストでアプリケーションが表示すべき情報が含まれているかどうかは決まらない。
これらの留保は、その主張を退けるのではなく、適用範囲を定めるものである。データベースによる強制は、レビュアーに具体的な確認対象を与える。アシスタントが表明する意図だけに頼るのではなく、ロール、権限、ポリシー、実行されたクエリを確認できる。
残る作業は、アプリケーションが意図したアイデンティティのもとで一貫してその強制ポイントに到達していることを検証することだ。これはデプロイメント上の責務であり、受け入れ証拠で確認できるようにすべきである。
アイデンティティ分離、定義変更、再現可能な回答に注目する
次に有用な証拠は、ユーザー、定義、リクエスト量の変化をまたいでガバナンスが維持されるかを示すものになる。
今後数か月、購入者はこれらの次元を結び付けた評価に注目すべきだ。よく知られた質問についてデモンストレーションを追加しても、アーキテクチャの境界を中心に設計されたテストほど多くの情報は得られない。
最初のシグナルは、デプロイされたリクエスト経路全体におけるアイデンティティの分離である。異なる権限を持つユーザーが、適切に異なる結果を受け取るという証拠を探すべきだ。証拠では、単にインターフェース上で異なる名前を表示するのではなく、有効なデータベースロールを特定する必要がある。
分離テストには、ユーザーの権限外にある操作の試行と、それに対するデータベースの挙動を含めるべきだ。一貫した強制は、このアーキテクチャを支持する根拠を強める。説明されない資格情報の共有は、ユーザー固有のガバナンスに関する主張を弱める。
2つ目のシグナルは、定義変更が回答にどのように影響するかである。ビジネス指標がアプリケーションのライフサイクルを通じてまったく変更されないことはめったにない。チームは、定義を更新し、その後のアシスタントの解釈を検証するデモンストレーションを探すべきだ。
意味のある証拠には、移行そのものが含まれる。アシスタントは改訂後の意味を使用するのか。レビュアーは、以前の回答を支えた定義を特定できるのか。影響を受ける参照回答は、明示的なプロセスを通じて更新されるのか。
変更を適切に処理できれば、維持管理されたデータベースオブジェクトの近くに意味を置くという主張を強めることになる。所有者が不明確だったり解釈が古いままだったりすれば、同じ場所に置くだけでは一貫性を実現できないことが示される。
3つ目のシグナルは、代表的な利用状況での再現可能な正確性である。評価では、質問の表現、ユーザー権限、同時アクティビティの量を変化させるべきだ。購入者は、条件が元のデモンストレーションと異なる場合でも、システムが有用性を維持するかを確認する必要がある。
これは、すべてのビジネス上の問いをベンチマーク競争として扱う必要があるという意味ではない。期待される動作を明示した一連の基準が必要だということである。正しい計算、適切な拒否、理解可能な制約、許容可能な応答時間には、それぞれ証拠が必要である。
EDB セマンティックレイヤーを運用上の観点から理解したいチームにとって、こうしたシグナルは実践的な意思決定の枠組みを提供する。アーキテクチャ上の提案を、パイロットで回答できる問いへと変換する。
また、どのプラットフォームが勝つかについて、根拠のない予測を避けることにもなる。最も強力な実装は、データの配置、アイデンティティ要件、組織が定義を維持する能力に左右される。データベース中心のアプローチは、こうした条件に照らして判断すべきだ。
まず、チームがすでに信頼性高く回答できているビジネス上の問いから始め、その定義、期待される結果、アクセス境界を文書化する。アシスタントの説明を信頼しなくても結果を再現できるだけの情報を、レビュアーに提供する。適切に制限されたアイデンティティで同じリクエストを実行し、応答と並行してデータベースの挙動を確認する。次に、関連する定義を変更し、回答が承認済みの変更に従うことを検証する。EDB セマンティックレイヤーを用いて、特定の運用上の命題をテストする。すなわち、組織はクエリ時のアクセスを強制しながら、共有された意味を維持できるという命題だ。パイロットを拡大する前に、重要なすべての回答と重要なすべての拒否を説明できるかを問うべきである。
