StardogとBedrock AgentCore、製品横断分析向けセマンティック層を構築

AWSは、Stardogの知識グラフをAuroraとRedshiftの上へ置き、Bedrock AgentCoreで動くエージェントが共通の業務定義を使って製品横断の質問へ答える構成を解説しました。

要点

• データを一カ所へ複製せず、仮想グラフから各情報源へ実行時に問い合わせます。
• 顧客、売上、関係、計算規則をオントロジーで一度定義し、複数のエージェントから再利用します。
• AgentCoreは認証、実行環境、ツール資格情報を担い、Stardogへ直接SPARQLまたはMCP経由で接続します。

今回のブログ記事で語られていること

企業データでは、CRMの「顧客」と請求システムの「顧客」、地域ごとの「売上」が同じ意味とは限りません。LLMが個別のスキーマを読んでSQLを生成できても、定義の違いを知らなければ、技術的には正しくても業務上は誤った数字を返します。記事は、この問題をモデルのプロンプトだけで解決せず、概念、関係、属性、規則を持つセマンティック層へ切り出す構成を示しています。

StardogはAuroraとRedshiftの行を共通の識別子へ対応付け、SPARQLを各情報源のSQLへ実行時に変換します。データは元の場所へ残るため、ETLで別の統合表を作る必要はありません。名前付きグラフをアクセス制御の単位にし、同じ質問でも役割が読めるグラフによって結果を変えられます。S3、Athena、Icebergへ広げることも想定されています。文書検索を得意とするRAGを置き換えるのではなく、構造化データの結合や業務指標にセマンティック層を併用する考え方です。

エージェントはClaude Sonnet 4.6をBedrockで利用し、AgentCore Runtimeで実行します。AgentCore GatewayとIdentityは受信認証、ホスティング、ツール資格情報を管理します。接続方法は、エージェントからStardogへ直接SPARQLを送る道と、Stardog Cloud MCP serverをGatewayのツールにする道が示されています。どちらを選ぶ場合も、モデルへ広いSQL権限を与えるのではなく、意味とアクセス規則を持つ層を介すことが中心です。

導入時は、オントロジーを作れば自動的に正しい指標が得られるわけではありません。概念の所有者、定義変更の承認、情報源との対応、同一人物・企業を結ぶ規則、欠損や遅延の扱いを管理する必要があります。行・列権限が名前付きグラフへ正しく写るか、生成された説明から元の数値と規則へ遡れるか、異なる役割で情報が漏れないかを試してください。ベータ機能と一般提供機能の境界も本番採用前に確認が必要です。

今回のブログ記事が関係する人

データアーキテクト、BI・分析基盤担当、AIエージェントへ企業データを公開するガバナンス責任者に関係します。

結局、今回のブログ記事をどう読むべきか

モデルへSQL生成を任せるだけでは業務定義の不一致を解消できません。エージェントの下に、共通の意味、権限、計算規則を持つ検証可能な層を置く設計例として有用です。