EDB Postgres AIとAmazon Bedrock AgentCoreで構築する、権限連動型セマンティックレイヤー
セマンティックレイヤーを運用DBに置く設計
AWSの技術記事は、EDB Postgres AI（AIDB）にセマンティック知識ベース（SemKB）を構築し、Amazon Bedrock AgentCore上で動作するStrands Agentsエージェントから利用する、顧客360（C360）の実装例を示している。構成の要点は、データの意味づけ、リレーションの発見、アクセス制御を、運用データと同じPostgres環境にまとめることだ。
SemKBはテーブルやビュー、カラムの定義を索引化するが、行データ自体を索引化するものではない。COMMENT ONで記述した説明もスキーマ情報と一緒にベクトルストアへ登録され、自然言語の質問から関連するオブジェクトを見つける手掛かりになる。外部カタログを別途運用したり、アプリケーションのスキーマと同期したりせず、SQLを著作面としてセマンティック情報を管理できる。
例では、C360データを専用のc360スキーマにロードし、customers、locations、products、purchasesの4テーブルと、派生ビューbig_spenderを使用する。Postgresの外部キーはSemKBによって関係としてクロールされ、エージェントが列名だけに頼らず結合経路を発見できる。さらに、繰り返し利用する質問は、自然言語の説明とパラメーターを持つ読み取り専用SELECTとしてaidb.create_semantic_aliasに登録できる。エイリアスはスキーマ情報と同じ索引に含まれ、エージェントからツールとして利用可能になる。
SQLコメントが回答精度を左右し、権限はDBで強制される
C360例では、カラム名だけでは判断できない業務上の意味をコメントで補っている。たとえば、purchases.priceは商品の単価ではなく注文全体の金額である。これを伝えない場合、エージェントが金額に数量を掛けてしまい、最上位顧客の支出額を約502,529ドルと誤算する。コメントをSemKBで検索可能にすると、正しい集計値は27,991.66ドルとなる。記事の例は、セマンティック情報が単なる説明文ではなく、SQL生成時の誤解を抑える実行上のコンテキストであることを示している。
同様に、顧客の州はcustomers行に直接格納されず、customers.locationからlocations.stateへ結合して取得する。カラムコメントで参照先を明示することで、エージェントは適切な結合経路を選びやすくなる。「big spender」の定義も、purchases.price > 250を条件にしたbig_spenderビューとCOMMENT ON VIEWで一元化する。業務定義をビューに保持すれば、エージェント、ダッシュボード、SQL利用者が同じ定義を共有できる。
ガバナンスはプロンプト上の注意書きではなく、Postgresのロール、カラム単位のGRANT、行レベルセキュリティ（RLS）で実施する。記事では、mcp_agent_fullとmcp_agent_restrictedの2ロールを作り、後者からcustomers.ssnへのSELECT権限だけを除外する。同じ質問、ツールカタログ、SemKB、エージェントコードを使っても、AgentCore IdentityがMCPリクエストに付与するPostgres資格情報によって結果が変わる。制限ロールがSSNを参照すると、Postgresが権限エラーを返し、MCPエンドポイントはそのエラーを変更せず転送する。RLSを設定した場合も、MCP経由の問い合わせは直接のPostgres接続と同じ行フィルタリングを受ける。
AgentCoreとMCPをつなぐ実行・監査経路
リクエスト経路は、Amazon Cognitoで認証したクライアントから始まる。クライアントはJWTをBearerトークンとしてAgentCore Gatewayへ送り、GatewayはCognitoのdiscovery URLに基づいてトークンを検証する。その後、トークンのクレームに対するCedarポリシー評価で呼び出し可能なツールを判断し、AgentCore runtimeへルーティングする。エージェントはAmazon Bedrock上のAnthropic Claudeを用いて計画と回答生成を行う。
データベースへのツール呼び出しにはMCPを使う。AIDBのedb-endpoints HTTPサーバーは、HTTP Basic認証を使うstreamable HTTP MCPを提供するため、Gatewayは変換層を挟まずMCPサーバーターゲットとして接続できる。EC2インスタンス上のエンドポイントを、HTTPSリスナーとAWS Certificate Manager（ACM）証明書を持つApplication Load Balancer（ALB）で公開し、ALBのURLをGatewayターゲットとして登録する。AgentCore Identityのcredential providerがPostgresロールの資格情報を保持し、外向きリクエストにBasic認証として注入するため、エージェントコード自体はDBパスワードを扱わない。この構成ではAWS Lambdaは不要である。
エンドポイントの有効化には、edb.endpoints_mcp_enabled = on、shared_preload_librariesへのaidb追加、およびPostgresの再起動が必要となる。外部から接続する場合は、edb.endpoints_mcp_hostに0.0.0.0などの非ループバックアドレスを設定し、ポートをedb.endpoints_mcp_portで指定する（既定値は8765）。非ループバックでのバインドにはTLS証明書と鍵も必要だ。記事の開発・テスト構成ではALBからEC2への接続にHTTPSを使い、バックエンド証明書チェーンを検証しないため、自己署名証明書を利用できる。プロダクションでは内部ALBとGatewayのVPC egressを組み合わせ、通信をプライベートに保つ構成が推奨されている。
観測性はエージェント側とDB側に分かれる。AgentCoreはツール呼び出し、LLM呼び出し、トークン使用量のトレースをCloudWatch Transaction Searchへ送る。一方、AIDBはSQL実行に関するOpenTelemetryトレースをaidb_otelスキーマの行としてPostgres内に記録し、通常のSQLで照会可能にする。これにより、エージェントの処理経路と、実際に実行されたDBクエリを異なる層で追跡できる。モデル側のAmazon Bedrock Guardrailsは、データベース権限を置き換えるものではなく、機密情報の読み取りを止めるPostgres制御と、回答生成時のPII漏えい抑制などを補完するものとして説明されている。
開発者・エンジニア視点での考察
-
コメントをデータ品質の一部としてレビューする。
COMMENT ON COLUMNは任意の文書ではなく、SQL生成に影響する仕様である。金額の単位・粒度、外部キーの意味、PII区分、適切なビューの利用条件を明記し、スキーマ変更と同じレビュー・テスト工程で管理すると、誤った結合や集計を早期に抑えやすい。 -
役割ごとの資格情報を、エージェントの権限境界として設計する。 同じエージェントをユーザー層ごとに分岐させるのではなく、AgentCore Identityが注入するPostgresロールと、そのロールに対する
GRANT・RLSを基準に権限を構成できる。実装時は「許可された列・行が返る」だけでなく、「禁止列を要求したときに権限エラーとなる」ことも検証し、権限設定の回帰テストに含めるべきだ。 -
監査可能性を、クエリ実行と身元の対応まで含めて設計する。 MCP接続ごとにPostgres認証を行い、ツール呼び出し内の
current_userが実行ロールとなるため、DB側の権限判断とトレースを結び付けやすい。AgentCoreの呼び出しトレースとaidb_otelのSQL実行記録を合わせて確認できるよう、運用時にはロール、質問、ツール呼び出し、SQLの追跡手順を整備したい。
Source / 元記事
この記事について
この記事は、公開されているニュース、論文、公式発表、RSSフィードなどをもとに、AIが要約・補足調査・考察を行って作成しています。
元記事の完全な翻訳・逐語的な要約ではなく、AIによる背景説明や開発者向けの考察を含みます。
重要な技術仕様・価格・提供状況などは、必ず元記事または公式情報をご確認ください。
