AWSはDenodoとAgentCoreを組み合わせ、クラウドとオンプレミスのデータを問い合わせる構成を公開しました。指標や結合、行・列の制御はデータ側で管理します。 エージェントのプロンプトへ業務定義を詰め込む負担を減らします。元データの所在、権限の委任、接続遅延と問い合わせの費用が論点になります。 分散したデータに同じ業務の意味を与える AWSは10月20日、Denodoを使う意味層とBedrock AgentCoreの構成を紹介しました。意味層は、業務上の指標やデータ間の関係を共通に定義する仕組みです。例ではAurora、Redshift、オンプレミスのPostgreSQLを結び、顧客を横断的に把握します。エージェントはDenodoのSQL方言であるVQLを使い、MCP経由で管理されたビューへ問い合わせます。データを使うための結合や行・列の制御を、プロンプトの記述から切り離す構成です。今回の技術記事は既存サービスを使った設計例であり、すべての業務データの意味をAIが自動で確定するという発表ではありません。 利用者の権限を問い合わせまで引き継ぐ 影響を受けるのは、複数のシステムをまたいで分析する業務部門と、データ基盤を管理するチームです。例では顧客情報と購買履歴、会員情報を組み合わせます。データの場所が異なっても同じ業務の定義で質問できますが、その定義は管理者が設計します。AgentCoreは入口の認証と、Denodoへ渡す認証情報を管理し、本人の委任を問い合わせに結び付けます。共通のサービス用権限だけで全データを見る場合と異なり、利用者ごとの制御を維持することが論点です。オンプレミスを含むため、ネットワークの接続や元システムの稼働状況も回答の可用性へ影響します。情報のコピーを増やさない利点と、実行時に複数の処理先へ依存する性質を合わせて考える必要があります。質問を変えた際にも同じ指標を使えるかが重要です。言葉の違いで異なるビューを選ぶ可能性があるため、業務用語とデータの定義の対応を確かめることが検討点になります。 定義の維持と分散問い合わせの費用を測る 実務では、指標の所有者や変更手順を決め、意味層の定義が元データの変更に追従するかを確認することが論点です。意味層があっても、顧客IDの対応や集計期間が誤っていれば回答はずれます。異なる権限の利用者で同じ質問を試し、許可された範囲だけが返るかを調べる必要があります。費用にはモデルの呼び出し、分散した元システムの処理、通信、定義の維持が含まれると考えられます。原文は管理サービスと自己管理の展開方法を示していますが、どちらが適するかは既存の運用体制にも依存します。次の判断点は、代表的な横断質問に対し、同じ定義と権限で安定した結果を返せるかです。エージェントの回答だけでなく、発行された問い合わせと参照先を確認できる状態が重要になります。問い合わせが集中する時間帯も試験対象です。元システムの負荷が業務へ及ぶ範囲を把握すれば、利用可能な処理と実行の制限を決めやすくなります。