AWS上でStardogとAmazon Bedrock AgentCoreを使用したエージェンティックAIのセマンティックレイヤーの構築

エンタープライズアナリティクスは20年来、同じ目標を追い求めてきました。ビジネス上の質問から信頼できる答えまでの時間を短縮することです。スケジュールされたレポートはダッシュボードに取って代わり、ダッシュボードはセルフサービスのビジネスインテリジェンス（BI）に取って代わりました。しかし、セルフサービスでさえ、データエンジニアが適切な質問に対して適切なモデルを事前に構築していることに依存しており、人間のアナリストは準備されたデータセット以外のすべてのボトルネックのままでした。生成AIエージェントは次のステップです。データを視覚化する代わりに、データについて推論します。彼らは自律的に計画し、クエリを書き、結果を評価し、最適化し、オンデマンドで会社のライブデータに対して反復します。エージェンティックアナリティクスとは、このシフトを表す用語です。つまり、すべてのビジネスユーザーのそばにいる自律エージェントが、リクエストキューで待つことなくアナリストの作業を行うのです。

難しい部分はもはや基盤モデルではありません。Amazon Bedrockで利用可能な基盤モデルは、マルチステップワークフローを計画し、スキーマについて推論し、ジュニアアナリストと同等のSQLを生成できます。難しい部分はその下にあります。モデルが推論するデータです。エンタープライズデータは、同じものを異なる方法で定義するシステムに分散しています。CRMシステムの「顧客」は、請求システムの「顧客」と同じレコードではありません。北米チームが計算した「収益」は、欧州チームが生成した数字と同じではありません。この断片化されたデータに直接アクセスできるAIエージェントは、技術的には有効だが、間違った、矛盾した、または説明できない回答を返すクエリを書くでしょう。最初に2つのエージェントが同じ質問に対して2つの異なる数字を返した時点で、信頼は損なわれます。

AWSでは、そのデータはおなじみの組み合わせにまたがっています。運用レコードはAmazon Auroraやその他のAmazon RDSエンジンに存在します。分析履歴はAmazon Redshiftに存在します。非構造化データはAmazon S3に存在し、Amazon Athenaを介してクエリされ、Apache Icebergなどのオープンテーブル形式でAmazon S3 Tablesにますます多く存在し、Athena、Amazon EMR、Amazon Redshiftがすべて読み取ることができます。各レイヤーは保存するものに合わせて構築されており、ほとんどの企業はその形状を維持します。課題は、AIエージェントが、シニアアナリストが同じ質問に対して持つ流暢さで、それらすべてを一度に推論できるようにすることです。

基盤モデルは言語をもたらし、AWSデータアプリケーションは事実をもたらします。今日それらを接続する一般的な方法は、検索拡張生成（RAG）です。ポリシードキュメント、マニュアル、サポートチケットをAmazon Bedrock Knowledge Basesにインデックス化し、クエリ時に一致するパッセージをモデルのコンテキストにプルします。RAGは、答えが検索が見つけられるテキストに存在する場合にうまく機能します。分析的な質問、つまり答えがシステム間でのライブレコードの結合、ビジネスルールの一貫した適用、行レベルまたは列レベルのアクセスポリシーの遵守に依存する場合には、うまく機能しません。

言語と事実の間にあり、通常これらの分析的な質問には欠けているのは、ビジネスコンテキストとビジネスメトリクスです。典型的な小売りの例を考えてみましょう。顧客とは何か、注文がどのように顧客にリンクするか、大口顧客や高リスクアカウントとして数えられるものは何か、どのシステムがどの事実を所有しているか、ビジネスが報告する数字がどのように計算されるかについての共通の定義です。同じギャップは、他のドメイン（保険の請求とポリシー、ヘルスケアの患者と診察、サプライチェーンの部品と出荷）でも異なる名前で現れます。セマンティックレイヤーは、そのコンテキストを一度キャプチャし、すべてのエージェントとツールが再利用できるようにします。それにより、AIエージェントは多くのソースから回答を構成し、それが返す数字の背後に立つことができます。セマンティックレイヤーはRAGを置き換えるのではなく、補完します。ほとんどのプロダクションシステムは両方を必要とし、同じエージェントから到達可能である必要があります。

セマンティックレイヤーは、エンタープライズデータのオントロジー駆動ビューです。オントロジーは、ビジネスにとって重要な概念、関係、属性、ルールをキャプチャします。マッピングは、それらの概念が各ライブソースの行からどのようにマッピングされるかを宣言します。エージェントはレイヤーをクエリし、レイヤーは各クエリをランタイムで基盤システムに対するSQLに変換します。データは元の場所に残り、意味は一度キャプチャされて再利用されます。

そのセマンティックレイヤーがStardogのように実装される場合（オントロジー、各エンティティの安定した識別子、新しい事実を導出するルール、オントロジーに対してデータを検証する制約）、結果はナレッジグラフになります。データはテーブルの行ではなくビジネスエンティティのグラフとして接続され、各エンティティはIRIと呼ばれる安定したURLスタイルの一意の識別子を持ち、クエリはSPARQLと呼ばれるW3C定義の標準ベースのクエリ言語でそれらの接続をトラバースします。この投稿では、さらに2つの用語が繰り返し登場します。名前付きグラフは、それ自身のIRIで識別されるグラフのラベル付きサブセットであり、Stardogは名前付きグラフをアクセス制御の単位として使用します。仮想グラフは、その内容がStardogにまったく格納されない名前付きグラフであり、外部システム（Aurora、Redshift、Athena）に存在し、Stardogはマッピングを使用してオンデマンドで行を取得します。

この投稿の最後までに、次のことを理解できます。セマンティックレイヤーがRAGとどのように適合し、それぞれをいつ選択するか。StardogをAmazon AuroraとAmazon Redshiftにフェデレーションする方法と、Amazon Athenaや他のAWSデータソースに拡張するための注意点。なぜプロダクションでエージェントを実行するためにAgentCore Runtime、Gateway、Identityを推奨するか。エージェントからStardogへの2つの統合パス（直接SPARQLツールとGatewayツールターゲットとしてのStardog Cloud MCPサーバー）。ガバナンス、デプロイメント、GAとベータのトレードオフ。

エージェントに必要な3つのレイヤー 信頼性が高くビジネスコンテキストを認識した回答を提供するAIエージェントは、3つの要素が連携することに依存しています。それぞれが他の要素では解決できない問題を解決します。

1. モデルレイヤー：計画しコードを書くことができる基盤モデル。Amazon Bedrockは複数のモデルファミリーに単一のAPIを提供します。ここではAnthropic Claude Sonnet 4.6を使用します。モデルは言語を理解しますが、あなたのビジネスは理解しません。
2. 意味レイヤー：モデルにビジネス質問の背後にあるデータへの信頼できる管理されたアクセスを提供するセマンティックレイヤー。オントロジーは概念とそれらから新しい事実を導出するルールを宣言し、フェデレーションは各ソースからクエリ時にライブ行をプルします。レイヤーが作業を行います。つまり、どのデータが関連するかを判断し、SPARQLクエリを各ソースのSQLに書き換え、共有識別子で行を結合します。モデルの仕事はより狭いです。ユーザーの質問を読み、データが必要なときにレイヤーを呼び出し、平易な英語で回答を書きます。実際のデータ推論（フェデレーションソース全体でのBig_Spenderルールの適用など）は、プロンプト内ではなくStardog内に留まります。このために、AuroraとRedshift上のStardogのフェデレーションナレッジグラフを使用します。
3. エージェントランタイムレイヤー：エージェントをホストし、入站リクエストを終端し、ツールクレデンシャルを管理し、セキュリティとガバナンスの運用面を提供するコンピュート。AWSでは、管理ランタイム（Amazon Bedrock AgentCoreなど）から自己管理オプション（Amazon ECS、Amazon EKS、AWS Lambdaなど）まで、さまざまな選択肢があります。適切な選択は、エージェント運用のどの程度を自分で管理したいかによります。この投稿ではAmazon Bedrock AgentCoreを使用します。これはAWS上のプロダクションエージェントにとって最も規範的なオプションだからです。

これら3つのうち、意味レイヤーがこの投稿が扱うギャップであり、残りのウォークスルーでそれを構築します。エージェントランタイムレイヤーは、ほとんどのチームが過小評価しているものです。エージェントがどのように呼び出されるか、どのように認証するか、セマンティックレイヤーへのクレデンシャルがどこにあるか、どのようにスケールするか。AgentCoreはこれらの質問への回答を1つのマネージドサービスにパッケージ化しており、それがここで使用する理由です。

ユースケース例：AuroraとRedshiftをまたがるカスタマー360エージェント このウォークスルーの残りの部分では、カスタマー360（C360）を選択しました。これは、AIエージェントが実際の分析作業を実行しようとすると遭遇するすべてのギャップを表面化し、セマンティックレイヤーがマッピングとルールの数百行でそれぞれをどのようにクローズするかを示すことができるからです。典型的な小売りの設定では、顧客プロファイル、住所、クレジットカード、報酬情報は運用データベースにあります。注文、製品、カテゴリ、ベンダーは分析用のデータウェアハウスにあります。各サイドはそれぞれの機能に最適化されています。どちらのサイドも、単独では顧客全体に関する質問に答えることはできません。「最も価値のある顧客は誰で、何を購入しているか？」という質問に答えようとするエージェントは、2つのデータベース、2つのスキーマ、2つの「顧客」定義、および誰の列にも存在しない派生概念（「最も価値がある」）を調整しなければなりません。C360はこれらのギャップを具体化します。

C360エージェントは分析チーム向けに実行されます。セールスリード、マーケター、または不正アナリストから平易な英語で質問を受け付けます。クエリを書き、会社のデータ全体で実行し、短いナラティブ回答とサポート数字で応答します。ユーザーはSQLやSPARQLを見ず、エージェントは許可されていないデータを見ません。

ユーザーはC360エージェントに平易な英語で尋ねます。「ウィスコンシン州の大口顧客は誰ですか？」顧客プロファイルと住所はAuroraにあります。注文合計はRedshiftにあります。エージェントは安定した顧客識別子でそれらを結合する必要があり、その結合はセマンティックレイヤーが追加する3つのことの1つです。

1. 共有された意味を通じたシステム間の結合。セマンティックレイヤーは、共有ビジネスキーを使用してAuroraとRedshiftの両方からの顧客レコードを共通の顧客アイデンティティにマッピングします。これにより、結合を物理的な統合パイプラインではなくセマンティックモデルを通じて表現できます。それがなければ、その結合には通常、データの3番目のコピーを実体化し、各ソースが変更されるたびに同期を保つ必要があるパイプラインの保守が必要になります。
2. クエリではなくルールとしての派生事実。「大口顧客」のような定義は、すべてのクエリで再表現される代わりに、オントロジー内のルールとして存在でき、それを言及するすべてのクエリは同じ答えを得ます。それがなければ、その定義はダッシュボード、ノートブック、レポート全体で重複し、しきい値が変更されるとコピーがドリフトし、同じ質問が異なる答えを返し始めます。
3. グラフレベルのアクセス制御。名前付きグラフのセキュリティはグラフレベルでアクセスを制御するため、異なるロールはエンタープライズナレッジグラフの異なるサブセットを見ます。より細かい保護のために、:ssnや:cardNumberなどの機密プロパティを保護プロパティとして指定できます。許可を持つユーザーは実際の値を見ることができ、他のユーザーはデフォルトでマスクされた値を見ます。このアプローチにより、異なるロールが同じクエリを実行でき、ナレッジグラフはそれにアクセスするすべてのアプリケーションにわたって一貫したセキュリティポリシーを強制します。

StardogのC360ナレッジキットを採用し、元々はローカルCSVをロードしていましたが、Aurora PostgreSQL（顧客側）とAmazon Redshift（注文側）にフェデレーションするように適応しました。キットにはオントロジー、マッピング、ルールがすべてStardogの構文で含まれています。Stardogサービスをデプロイし、AuroraとRedshiftを指す仮想グラフを構成し、エージェントクエリをテストしました。結果は、セマンティックレイヤーが2つのソースからの顧客データを正常に統合し、大口顧客を正しく識別し、サポート数字を提供したことを示しました。エージェントは、事前構築された統合データパイプラインなしでは不可能だった質問に答えることができました。