この記事では、EDB Postgres AI を使用してエージェント型 AI のためのセマンティックレイヤーを構築し、Amazon Bedrock AgentCore 上で動作する Strands Agents エージェントからそのレイヤーにクエリを実行してカスタマー 360（C360）の質問に答える方法を紹介します。これはシリーズの一部であり、以前の記事では Stardog のナレッジグラフ、Denodo のデータ仮想化プラットフォーム、AtScale のディメンショナルモデル、Strategy Mosaic のリンクされたモデルで同じ C360 パターンを構築しました。
EDB Postgres AI は、セマンティックレイヤーを AIDB 拡張機能として運用中の Postgres データベース内に配置します。ビジネス上の意味は標準の Postgres COMMENT ステートメントを介してデータの隣に存在し、結合グラフは Postgres の外部キーから取得され、ガバナンスは AIDB に同梱される Model Context Protocol（MCP）エンドポイントを通じて Postgres の GRANT と行レベルセキュリティを使用して実装されます。
この記事を読み終えると、次のことがわかります。Postgres スキーマ上に AIDB セマンティックナレッジベース（SemKB）を構築する方法、COMMENT ON ステートメントと aidb.create_semantic_alias がオーサリングサーフェスとして機能する方法、外部キーが結合パスにクロールされる方法。AIDB ツールカタログを、組み込みの EDB MCP エンドポイントを介して外部エージェントに公開する方法（Application Load Balancer（ALB）でフロントされ、Amazon Bedrock AgentCore の機能である AgentCore Gateway に MCP ターゲットとして登録されます）。Postgres のロール、列レベルの GRANT ステートメント、行レベルセキュリティが、呼び出し元ごとに異なる結果を生み出す方法。プロンプト、ツールカタログ、エージェントコードは同じままです。AIDB がすべての SQL 実行の OpenTelemetry トレースを aidb_otel スキーマ内の行としてキャプチャし、通常の SQL でクエリできる方法。
エージェントに必要な 3 つのレイヤー
ライブデータからビジネス上の質問に答えるエージェントには、3 つのレイヤーが必要です。クエリを計画および作成するモデル、データが何を表すかをエージェントに伝える意味レイヤー、エージェントをホストし ID とアクセスを制御するランタイムです。このシリーズの Stardog の記事でこのフレーミングを紹介しました。この記事のモデルレイヤーは、以前の記事と同じく Amazon Bedrock 上の Anthropic Claude です（モデルの可用性は AWS リージョンによって異なります）。ランタイムレイヤーは AgentCore ランタイム（Amazon Bedrock AgentCore の機能）です。AgentCore Gateway がインバウンド認証を処理し、AgentCore Identity（Amazon Bedrock AgentCore の機能）がツールターゲットのアウトバウンド認証情報を保持します。EDB Postgres AI はデータベース自体の中にエージェントとツールをホストし、MCP エンドポイントを介して外部エージェントの接続ポイントとして機能します。
意味レイヤーが、この記事が他の記事と異なる点です。ここでは、運用中の Postgres データベース内に存在する SemKB です。スキーマとビジネス定義が一緒にインデックス化されます。Postgres の GRANT、行レベルセキュリティ、列レベルの GRANT がアクセスを強制し、助言的なシステムプロンプトではありません。以下のセクションでは、AIDB がレイヤーを構築する方法、AgentCore がそれを公開する方法、2 つの Postgres ロールが同じ質問をして異なる答えを得る方法を説明します。
ユースケース例：EDB Postgres AI 上の C360
データセットは Stardog C360 Knowledge Kit で、専用の c360 スキーマ内の単一の EDB Postgres AI インスタンスにロードされます。データモデルには 4 つのテーブルと 1 つの派生ビューがあります。
物理スキーマは単純な Postgres 結合グラフです。customers テーブルの顧客は locations に存在し、purchases を行い、各 purchases は products を参照します。セマンティックな作業は、列名では明らかにならない 3 つのビジネス概念に基づいています。
州は顧客行にはありません。locations にあり、customers.location 外部キーを介して到達し、その列のコメントが SemKB に場所を伝えます。
purchases.price は注文合計を記録します。エージェントがこれを単価と誤解して数量を掛けると、トップ顧客に対して 27,991.66 ドルではなく 502,529 ドルを返します。
大口消費者はビジネスが所有する用語です。COMMENT ON VIEW ステートメントを持つビューとしてキャプチャされ、その定義はすべてのエージェント、ダッシュボード、クエリが読み取る 1 つの場所に保たれます。
エージェントを通じてエンドツーエンドで実行する質問：
総支出額でトップ 10 の顧客は誰で、それぞれどの州にいますか？
州ごとに大口消費者は何人いますか？
10 人の顧客とそれぞれの州をリストできますか？
最も多く売れた 10 製品はどれですか？
5 人の顧客と社会保障番号をリストできますか？（ガバナンスの再実行で使用）
リファレンスアーキテクチャ
次の図は、アナリストから Amazon Bedrock AgentCore を経由して EDB Postgres AI 内のセマンティックレイヤーに至るリクエストパスを示しています。アナリストは Amazon Cognito で認証し、発行された JSON Web Token（JWT）を Bearer トークンとして AgentCore Gateway を呼び出します。ゲートウェイは AgentCore ランタイムにルーティングし、Amazon Bedrock 上の Claude で計画します。エージェントはゲートウェイを介して MCP ツールを呼び出し、ゲートウェイは EDB Postgres AI 仮想プライベートクラウド（VPC）内の Application Load Balancer に転送し、AIDB 内の edb-endpoints MCP サーバーに転送します。AIDB は SemKB、セマンティックエイリアス、読み取り専用の PostgreSQL テーブルを提供します。AgentCore トレースは Amazon CloudWatch に送られ、AIDB は OpenTelemetry トレースを Postgres 内の aidb_otel スキーマの行としてキャプチャします。
図 1：EDB Postgres AI と Amazon Bedrock AgentCore のリファレンスアーキテクチャ
AgentCore と EDB Postgres AI の間の境界を越える 2 つのフローがあります。
インバウンド：クライアントは Amazon Cognito ユーザープールが発行したベアラートークンで AgentCore Gateway を呼び出します。ゲートウェイのインバウンド JWT 認証子は、Cognito ディスカバリ URL に対してトークンを検証します。次にゲートウェイは、トークンのクレームに対して Cedar ポリシーを評価し、このエージェントがこのユーザーのために呼び出せるツールを決定します。その後 AgentCore ランタイムにルーティングします。エージェントは Amazon Bedrock 上の Claude を呼び出して計画と回答の構成を行います。
セマンティックレイヤーへのアウトバウンド：エージェントのツール呼び出しは MCP リクエストです。AgentCore Gateway は MCP サーバーターゲットを直接サポートします。AIDB の edb-endpoints HTTP サーバーは HTTP Basic 認証を伴うストリーミング可能な HTTP MCP を話すため、ゲートウェイは変換レイヤーなしで MCP サーバーターゲットとして扱えます。HTTPS リスナーと AWS Certificate Manager（ACM）証明書を備えた Application Load Balancer が Amazon Elastic Compute Cloud（Amazon EC2）インスタンス上の edb-endpoints をフロントします。ALB URL はゲートウェイターゲットとして登録されます。AgentCore Identity 認証情報プロバイダーは Postgres ロールの認証情報を保持し、すべてのアウトバウンドリクエストに Basic 認証として注入します。エージェントコードは Postgres 認証情報を見ません。
可観測性：AgentCore はツール呼び出し、大規模言語モデル（LLM）呼び出し、トークン使用量のトレースを CloudWatch Transaction Search に送信します。AIDB は SQL 実行の OpenTelemetry トレースを Postgres 内の aidb_otel スキーマの行としてキャプチャし、データベースが書き込み用に構成された後（ソースデータベースでのテレメトリ有効化を参照）、通常の SQL でクエリできます。
このアーキテクチャでは AWS Lambda は不要です。AIDB はすでに MCP を話すため、ゲートウェイは ALB を介して直接 MCP サーバーターゲットとして通信します。このシリーズの Denodo の記事では、MCP サーバーの前で同じ ALB パターンを使用しており、ベンダー以外のアーキテクチャは変わりません。
セマンティックレイヤーの構築
これらの手順は、AIDB が EDB Postgres AI インスタンスにインストールされ有効化され、Stardog C360 キットの 4 つの CSV が前述の主キーと外部キーを持つ専用の c360 スキーマにロードされていることを前提としています。このレイヤーはデータと同じデータベース内に存在するため、デプロイする 2 番目のシステムも、同期するカタログもありません。セマンティックレイヤーは SQL で定義され、行を書き込むアプリケーションと同じデータベース内にあります。
AIDB セマンティックナレッジベースは、データではなく Postgres スキーマをインデックス化します。すべてのテーブル、ビュー、列の定義（COMMENT ON テキストとともに）をベクトルストアに埋め込み、エージェントが自然言語で検索できるようにします。3 つのオーサリングタスクが、エージェントが意味によって正しいテーブルと列を見つけるのを助けます。COMMENT ON ステートメントを書くこと、ビジネス用語を独自のコメントを持つビューとして定義すること、繰り返しの質問をセマンティックエイリアスとして登録することです。コメントは 3 つのオーサリングタスクの中で最も簡単で、ユーザーとエージェントの両方のテキストから SQL への精度を最も向上させます。
エージェントが見る場所にコメントを追加する
COMMENT ON COLUMN c360.purchases.price IS '顧客が注文全体に対して支払った合計金額（米ドル）。単価ではありません。'; COMMENT ON COLUMN c360.purchases.cid IS '注文を行った顧客。customers.cid に結合します。'; COMMENT ON COLUMN c360.customers.location IS '顧客の自宅住所。locations.id に結合します。州は locations.state にあります。'; COMMENT ON COLUMN c360.customers.ssn IS '米国社会保障番号。機密情報であり、列レベルの GRANT が必要です。';
CREATE VIEW c360.big_spender AS SELECT c.cid, c.full_name, l.state, count(*) AS large_orders, max(pu.price) AS largest_order FROM c360.purchases pu JOIN c360.customers c ON c.cid = pu.cid JOIN c360.locations l ON l.id = c.location WHERE pu.price > 250 GROUP BY c.cid, c.full_name, l.state;
COMMENT ON VIEW c360.big_spender IS '大口消費者。大口消費者とは、250 米ドルを超える注文を少なくとも 1 件持つ顧客です。' '大口消費者に関する質問にはこのビューを使用してください。';
ビューはビジネス定義を 1 か所に保持するため、エージェントやダッシュボードが大口消費者を再定義する必要はありません。事前にコメントに費やす時間は、エージェントがその後実行するすべてのクエリで報われます。
セマンティックナレッジベースの作成
c360 スキーマ上に SemKB を作成します。この呼び出しは、名前、埋め込みモデル、ターゲットスキーマ、自動処理モードを登録します。
SELECT aidb.create_semantic_kb( name => 'c360_kb', model => 'bge-small-en-v1.5-f16', schemas => ARRAY['c360'], auto_processing => 'Live' );
埋め込みモデルは、AIDB Amazon Machine Image（AMI）に同梱されるローカル llama.cpp モデル（llamacpp_embeddings）です。SemKB は KB ごとに 1 つの埋め込みモデルを使用するため、すべてのエントリが同じベクトル空間に存在します。AIDB AMI には public 上に semkb というデフォルトの SemKB が同梱されているため、c360_kb を作成するとインスタンス上に 2 つの SemKB が残ります。複数の SemKB が存在する場合、すべての aidb.semantic_kb_search 呼び出しで kb_name を明示的に渡す必要があります。ローカルモデルをリモート埋め込みモデル（Amazon Bedrock 上の Amazon Titan Text Embeddings など）に置き換えるには、aidb.create_model でリモートモデルを登録し、その名前を SemKB の model パラメータとして渡します。auto_processing パラメータは Disabled、Live、Background を受け入れます。Live は Postgres イベントトリガーを介してスキーマ変更に反応します。Background はワーカーから非同期で処理します。Disabled は明示的な aidb.refresh_semantic_kb() を待ちます。SemKB は同時に外部キーを関係にクロールします。purchases.cid 外部キーは、エージェントが列名ではなく意味によって発見できる結合パスになります。
繰り返しの質問をセマンティックエイリアスとしてキャプチャする
セマンティックエイリアスは、自然言語の説明を持つ名前付きのパラメータ化された読み取り専用 SELECT であり、SemKB がスキーマメタデータと一緒にインデックス化します。エージェントは意味によってそれを見つけ、パラメータで呼び出し、ガバナンスされた回答を返します。
SELECT aidb.create_semantic_alias( name => 'big_spenders_by_state', description => '州ごとに大口消費者をカウントし、多い順から少ない順に並べます。', query_text => $$SELECT state, count(*) AS big_spenders FROM c360.big_spender GROUP BY state ORDER BY big_spenders DESC, state$$, params => '[]' );
エイリアスは AIDB の再利用可能なテキストから SQL へのビルディングブロックです。テーブルやビューと一緒に SemKB インデックスに存在し、エージェントにツールとして表示されます。テキストから SQL への完全なウォークスルーについては、EDB のドキュメントを参照してください。
アクセスのガバナンス
このアーキテクチャのガバナンスは、Postgres のプリミティブを通じて一貫して実行されます。AIDB MCP エンドポイントには独自の権限システムがありません。「Postgres のグラントが各エージェントが読み取れる内容を決定します。」