列コメント、外部キー、ビューを使い、業務上の意味をデータベース内に置く構成です。同じ質問でもPostgresの権限に応じて返せる項目が変わる実装例を示しました。 自然言語でSQLを作る前に、金額や業務用語の定義を整えることが焦点です。モデルへの指示と、データベースによる実際のアクセス制御を分けて設計します。 業務上の意味をデータのそばへ置く AWSは11月3日、EDB Postgres AIとAmazon Bedrock AgentCoreで分析エージェントを作る手順を公開しました。自然言語からSQLを生成しても、列名だけでは金額や業務用語の意味が伝わらない課題を扱います。意味の層は、Postgresの中にあるAIDB拡張で構成します。列やビューのコメントを索引に取り込み、外部キーから結合の経路を把握します。モデルはBedrock、実行環境や接続の管理はAgentCoreが担います。データの外側に別の業務定義を重ねるよりも、既存のスキーマと共に管理する構成です。公開例では顧客や購買のデータを使っています。 同じ質問でも権限によって結果を変える 例では、価格の列が単価ではなく注文全体の金額を表します。この意味を誤ると、数量を再度掛けて集計を大きく見積もります。列コメントは、その誤りを防ぐための情報になります。優良顧客のような業務用語はビューで定義し、定型の質問は再利用できる問い合わせとして登録します。接続にはMCPを使い、AgentCore IdentityがPostgresの資格情報を渡します。影響を受けるのは、顧客分析や社内集計をAIに任せる開発者とデータ管理者と見られます。原文では、同じ質問を権限の異なる役割で実行し、制限された個人情報の列が拒否されることを確認しています。アクセスの判断は、モデルの善意やプロンプトではなくPostgres側で行います。意味の説明と閲覧権限を、同じ運用の中で管理する例です。 定義の更新と接続の身元を監査する 意味の索引は、設定に応じてスキーマの変更へ同期します。導入側では、業務用語を誰が更新し、その変更がいつエージェントへ反映されるかが論点になります。古い定義のまま回答しないか、列の意味を省略していないかも確認対象です。権限制御では、入口の認証と、出口で使うPostgresの役割を分けて把握する必要があります。原文は、列や行の制御に加え、SQL実行の記録をOpenTelemetryの情報としてデータベースへ残します。出力側の個人情報対策にはGuardrailsを組み合わせるとしています。接続や暗号化、保守の作業も残るため、実装例を動かしただけで運用が完了したとは見なせません。自社の集計問題と拒否されるべき質問の両方で、結果を確かめることが考えられます。 分析の正確性を定義から確かめる 記事は、別のデータソースへ広げる場合も業務定義をPostgres側に保つ方向を示しています。ただし、公開例の集計が通ることは、すべての質問の正しさを保証しません。次の判断点は、自社の指標や結合の定義をどれだけ明示できるかです。生成されたSQLとその根拠を確認し、権限を狭めた際にも意図した拒否が働くかを検証する必要があると見られます。モデルの比較だけで解けない課題として、データの意味の管理が重要になります。