AI注目記事のキュレーターページ

この記事では、StardogのセマンティックAIアプリケーションを使用して、Amazon AuroraとAmazon Redshift上にセマンティックレイヤーを構築する方法を示します。また、Amazon Bedrock AgentCore上でStrands Agentsエージェントを実行し、ETL（抽出、変換、ロード）なしで両方のソースから顧客360の質問に答える方法についても説明します。同じStardogのデプロイメントは、AWSのコンピューティング環境（Amazon Elastic Kubernetes Service、Amazon Elastic Container Service、AWS Lambda）でも機能します。エンタープライズ分析は、ビジネスの質問と信頼できる回答の間の時間を短縮するという目標を20年間追い続けてきました。スケジュールされたレポートはダッシュボードに、ダッシュボードはセルフサービスのビジネスインテリジェンス（BI）に進化しました。しかし、セルフサービスでさえ、データエンジニアが正しいモデルを構築していることに依存しており、人間のアナリストは準備されたデータセットの外でのすべてのボトルネックでした。生成AIエージェントは次のステップです。データを視覚化するのではなく、それを推論します。計画を立て、クエリを書き、結果を評価し、洗練し、会社のライブデータに対して要求に応じて反復します。エージェント分析はこのシフトを指す用語です：ビジネスユーザーのすぐそばにいる自律エージェントが、リクエストキューで待つことなくアナリストの作業を行います。難しいのはもはや基盤モデル（FM）ではありません。Amazon Bedrockで利用可能な基盤モデルは、すでにマルチステップのワークフローを計画し、スキーマについて推論し、ジュニアアナリストのようにSQLを生成することができます。難しいのはその下にあるデータです。エンタープライズデータは、同じことを異なる方法で定義するシステムに散在しています。顧客関係管理（CRM）システムの「顧客」は、請求システムの「顧客」とは異なるレコードです。北米チームが計算した「収益」は、欧州チームが生成する数字とは異なります。断片化されたデータに直接アクセスできるAIエージェントは、技術的に有効なクエリを作成しますが、間違った、矛盾した、または説明できない回答を返します。最初に2つのエージェントが同じ質問に対して異なる数字を返すと、自信が揺らぎます。AWS上では、そのデータはおなじみのミックスに散在しています。運用記録はAmazon Auroraや他のAmazon Relational Database Service（Amazon RDS）エンジンに存在します。分析履歴はAmazon Redshiftにあります。非構造化データはAmazon Simple Storage Service（Amazon S3）にあり、Amazon Athenaを通じてクエリされ、ますますApache Icebergなどのオープンテーブル形式で、Amazon S3 TablesというAmazon S3の機能で読み取られます。各レイヤーは保存するものに特化しており、ほとんどの企業はその形を維持します。課題は、AIエージェントが同じ質問に対してシニア人間アナリストが持つのと同じ流暢さで、すべてのレイヤーを同時に推論できるようにすることです。基盤モデルは言語を提供し、AWSデータアプリケーションは事実を提供します。今日、これらを接続する一般的な方法は、Retrieval Augmented Generation（RAG）です。ポリシー文書、マニュアル、サポートチケットをAmazon Bedrock Knowledge Basesにインデックスし、クエリ時にモデルのコンテキストに一致するパッセージを引き出します。RAGは、回答が検索で見つけられるテキストに存在する場合にうまく機能します。分析的な質問では、回答がシステム間でライブレコードを結合し、一貫してビジネスルールを適用し、行または列レベルのアクセスポリシーを尊重することに依存するため、あまりうまく機能しません。言語と事実の間に存在し、通常は分析的な質問に欠けているのは、ビジネスコンテキストとビジネスメトリクスです。典型的な小売の例を考えてみましょう：顧客とは何か、注文がどのようにリンクするか、大口顧客や高リスクアカウントとは何か、どのシステムがどの事実を所有するか、ビジネスが報告する数字がどのように計算されるかの共有定義です。同じギャップは、他のドメイン（保険の請求とポリシー、医療の患者と遭遇、サプライチェーンの部品と出荷）でも異なる名前で現れます。セマンティックレイヤーは、そのコンテキストを一度キャプチャし、すべてのエージェントとツールが再利用できるようにします。これにより、AIエージェントは多くのソースから回答を構成し、返す数字の背後に立つことができます。セマンティックレイヤーはRAGを置き換えるものではありません。それを補完します。ほとんどの生産システムは、同じエージェントを通じてアクセス可能な両方を必要とします。セマンティックレイヤーは、企業データのオントロジー駆動のビューです。オントロジーは、ビジネスにとって重要な概念、関係、属性、ルールをキャプチャします。マッピングは、各ライブソースの行からそれらの概念がどのようにマッピングされるかを宣言します。エージェントはレイヤーにクエリを実行します。レイヤーは、実行時に基盤となるシステムに対して各クエリをSQLに変換します。データはそのまま保持され、意味は一度キャプチャされ再利用されます。Stardogが行うようにセマンティックレイヤーが実装されると（オントロジー、すべてのエンティティの安定した識別子、そして新しい事実を導出するルール、オントロジーに対してデータを検証する制約）、結果はナレッジグラフになります。データは、テーブルの行ではなくビジネスエンティティのグラフとして接続され、各エンティティにはIRIと呼ばれる安定したURLスタイルの一意の識別子があります。クエリは、W3Cで定義された標準ベースのクエリ言語SPARQLでその接続を横断します。この記事の残りの部分では、2つの用語が繰り返し登場します：

- 名前付きグラフは、IRIによって識別されるグラフのラベル付きサブセットです。Stardogは、アクセス制御の単位として名前付きグラフを使用します。同じクエリは、各役割が許可されている名前付きグラフに応じて異なる結果を生成します。
- 仮想グラフは、Stardogにまったく保存されていない名前付きグラフです。これらは外部システム（Aurora、Amazon Redshift、Athena）に存在し、Stardogはマッピングを使用して必要に応じて行を取得します。この投稿では、フェデレーションはソースごとに1つの仮想グラフのセットとして実装されています。

Stardogの用語集は、これらの用語を定義し、Stardogの「はじめに」シリーズはそれらを文脈に置きます。この記事を読み終えると、次のことがわかります：

- セマンティックレイヤーがRAGとどのように適合し、各々を選択するタイミング。
- Amazon AuroraとAmazon Redshiftを通じてStardogをフェデレートする方法、Amazon Athenaや他のAWSデータソースへの拡張に関するメモ。
- エージェントを本番環境で実行するためにAgentCore Runtime、Gateway、Identityを推奨する理由。
- エージェントからStardogへの2つの統合パス：直接SPARQLツールとStardog Cloud Model Context Protocol（MCP）サーバーをゲートウェイツールターゲットとして使用する。
- ガバナンス、デプロイメント、一般提供（GA）とベータのトレードオフ。

エージェントが必要とする3つのレイヤー
信頼できるビジネスコンテキストを持つ回答を提供するAIエージェントは、3つの要素が連携して機能することに依存しています。それぞれが他の要素が解決できない問題を解決します。
1. モデルレイヤー。計画と執筆ができる基盤モデル。Amazon Bedrockは、複数のモデルファミリーに対して単一のAPIを提供します。私たちはAnthropic Claude Sonnet 4.6を使用しています。このモデルは言語を知っていますが、あなたのビジネスを知りません。
2. 意味レイヤー。モデルに信頼できる、ガバナンスされたデータへのアクセスを提供するセマンティックレイヤー。オントロジーは概念と新しい事実を導出するルールを宣言し、フェデレーションはクエリ時に各ソースからライブ行を引き出します。このレイヤーが作業を行い、関連するデータを特定し、各ソースのSPARQLクエリをSQLに書き換え、共有識別子で行を結合します。モデルは狭い役割を持ちます。ユーザーの質問を読み、データが必要なときにレイヤーを呼び出し、平易な英語で回答を書きます。データに対する実際の推論は、フェデレーテッドソース全体で「大口顧客」ルールを適用するようなものは、プロンプト内ではなくStardog内に留まります。私たちはこれにStardogのフェデレーテッドナレッジグラフを使用しています。
3. エージェントランタイムレイヤー。エージェントをホストし、受信リクエストを終了し、ツールの資格情報を管理し、セキュリティとガバナンスのための運用サーフェスを提供するコンピュート。AWSでは、Amazon Bedrock AgentCoreのような管理されたランタイムから、Amazon ECS、Amazon EKS、AWS Lambdaのような自己管理オプションまで、選択肢の幅があります。適切な選択は、エージェントの操作のどれだけを所有したいかによります。この記事では、AWS上の本番エージェントに対して最も指示的なオプションであるAmazon Bedrock AgentCoreを使用しています。

この3つの中で、意味レイヤーがこの記事の主題であり、残りの手順はそれを構築します。エージェントランタイムレイヤーは、最も多くのチームが過小評価するものです：エージェントはどのように呼び出され、どのように認証され、セマンティックレイヤーへの資格情報はどこにあり、どのようにスケールするのか。AgentCoreは、これらの質問への回答を1つの管理サービスにパッケージ化しているため、ここで使用しています。

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

C360エージェントは分析チームのために実行されます。営業リーダー、マーケター、または不正分析者からの平易な英語の質問を受け入れ、クエリを作成し、会社のデータを横断して実行し、短いナラティブの回答とサポートする数字を返します。ユーザーはSQLやSPARQLを見ず、エージェントは許可されていないデータを見ることはありません。

ユーザーがC360エージェントに平易な英語で「ウィスコンシン州のトップスピンダーは誰ですか？」と尋ねます。顧客プロファイルと住所はAuroraにあり、注文合計はAmazon Redshiftにあります。エージェントは安定した顧客識別子でそれらを結合する必要があります。この結合は、セマンティックレイヤーが追加する3つの要素の1つです：
1. 共有意味を通じたシステム間の結合。セマンティックレイヤーは、AuroraとAmazon Redshiftの両方から顧客レコードを共有ビジネスキーを使用して共通の顧客IDにマッピングします。これにより、物理的な統合パイプラインではなく、セマンティックモデルを通じて結合を表現できます。これがなければ、その結合は、データの第3のコピーを生成し、各ソースが変更されるたびに同期を保つ必要があるメンテナンスされたパイプラインを必要とします。
2. ルールとしての派生事実、クエリではなく。例えば、「大口顧客」の定義は、オントロジー内のルールとして存在でき、各クエリで再表現されることはありません。これにより、ダッシュボード、ノートブック、レポート全体でその定義が重複することがなくなります。しきい値が変更されると、コピーは異なり始め、同じ質問が異なる回答を返すようになります。
3. グラフレベルのアクセス制御。名前付きグラフのセキュリティは、グラフレベルでアクセスを制御します。異なる役割がエンタープライズナレッジグラフの異なるサブセットを表示します。より細かい保護が必要な場合は、:ssnや:cardNumberのような敏感なプロパティを保護されたプロパティとして指定できます。権限のあるユーザーは実際の値を見ますが、他のユーザーはデフォルトでマスクされた値を見ます。このアプローチにより、異なる役割が同じクエリを実行できますが、ナレッジグラフはそれにアクセスするすべてのアプリケーションで一貫したセキュリティポリシーを強制します。

私たちはStardogのC360ナレッジキットを使用し、元々はローカルCSVをロードするものでしたが、Aurora PostgreSQL（顧客側）とAmazon Redshift（購入側）を横断するように適応しました。このキットには、オントロジー、サンプルデータ、および既製のクエリが含まれています。これを自分の作業の出発点として使用できます。

エージェントが見ないデータモデル
エージェントの下には、C360データが2つのAWSデータベースに分かれています。Auroraは運用上の顧客向けテーブルを保持し、Amazon Redshiftは分析用のファクトテーブルと製品次元を保持します。

Aurora PostgreSQL（運用）

| テーブル | 主要列 |
| --- | --- |
| 顧客 | cid, first_name, last_name, email, ssn, phone, location |
| 住所 | id, city, state, zip, street_name |
| クレジットカード | id, cid, card_num, card_type |
| リワードアカウント | id, cid, account_id, create_date |

Amazon Redshift（分析）

| テーブル | 主要列 |
| --- | --- |
| 購入 | id, cid, pid, date, quantity, price, card |
| 製品 | id, name, brand, price, dept |
| カテゴリ | id, dept_name, parent |
| ベンダー | id, vendor_name, industry |

2つのデータベース間の共有識別子は整数cidです。これはAuroraの顧客テーブルの主キーとして現れ、Amazon Redshiftの購入テーブルには外部キーではない列として現れます。これらをリンクするSQL制約はありません。なぜなら、異なるエンジンに存在するからです。顧客とその注文を結合する回答は、クエリ時に毎回その整数を調整しなければなりません。ETLなしで。

これがセマンティックレイヤーが吸収するものです。オントロジーは1つの概念、:Customerを宣言し、それに対する1つの安定したアイデンティティを持ちます：形式urn:stardog:demos:c360:customer:{cid}のIRIです。Auroraの顧客マッピングとAmazon Redshiftの購入マッピングは、それぞれのcid値からその同じIRIを生成します。エージェントは、プロファイル、住所、カード、リワードアカウント、注文を持つ1つの顧客エンティティを見ます。ウェアハウスはそれぞれの行を変更せずに自分の行を見ます。マッピングは、両方のデータベースのcidから同じ顧客IRIを生成します。Stardogは、その共有アイデンティティを使用して、基盤となるデータベースが互いに知る必要なく、フェデレーテッド結果を結合します。

参照アーキテクチャ

図1。重要なポイント：データはAuroraとAmazon Redshiftに留まります。クエリのみがセマンティックレイヤーを通過します。

これが推奨される本番アーキテクチャです。この記事のPOCは、エージェントがスタンドアロンスクリプトとして実行されるパスAを使用しました。

図は2つのフローを示しています。

- インバウンド。クライアント（アプリケーション、別のエージェント、またはStardog Studio）がAgentCore Gatewayを通じてエージェントを呼び出します。Gatewayは受信したJSON Web Token（JWT）を検証し、呼び出しをAgentCore Runtimeにルーティングします。これがStrandsエージェントをホストします。エージェントは、計画と回答構成のためにAmazon Bedrock上のClaude Sonnet 4.6を呼び出します。
- セマンティックレイヤーへのアウトバウンド。2つのパスが示されています。
- パスA（今日、オレンジの破線）：Strandsエージェントは、Stardogに直接話すquery_kg SPARQLツールを呼び出します。これは、まだVoicebox APIアクセスがない場合に使用します（後述）。
- パスB（Stardog Cloud MCP、APIアクセスが利用可能な場合、青）：AgentCore Gatewayは、Stardog Cloud MCPサーバーをMCPターゲットとして登録しています。GatewayはAgentCore IdentityからStardogトークンを取得し、呼び出しを転送します。エージェントは資格情報に触れません。

Stardog自体は、クエリ時にJava Database Connectivity（JDBC）を介してウェアハウスにフェデレートします。SPARQLはソースごとにSQLに書き換えられ、結果は共有IRIでStardog内で結合されます。ETLジョブやデータの第3のコピーはありません。

セマンティックレイヤーを構築する
フェデレーションを機能させるためには、3つの要素が必要です。オントロジーは概念（:Customer、:Order、:Product）とそれらの間の関係を宣言します。マッピングは、各データストアの行がどのようにそれらの概念のインスタンスになるかを宣言します。推論ルールは、すでにスコープ内にあるデータから新しい事実を導出します。Stardog Designerは、これら3つのすべての著作表面です。