AWSで自律型AI用のデータ意味定義層を構築、StardogとAmazon Bedrock AgentCoreの連携構成を公開

要点

• AWSの機械学習ブログにて、Stardogの技術とAmazon Bedrock AgentCoreを組み合わせ、自律型AI向けのデータ意味定義層（セマンティックレイヤー）を構築する方法が紹介された。

• データの抽出・変換・格納（ETL）処理を行わずに、Amazon AuroraとAmazon Redshiftのデータを横断して顧客の全体像に関する質問に回答可能になる。

• データの定義がシステムごとに異なる「データの断片化」により、AIが文法的に正しくても誤ったクエリや矛盾する回答を出力してしまう課題を解決する。

• 既存のRAG技術は文書検索には適しているものの、複数データベースのライブレコードの結合やビジネスルールの適用が必要なデータ分析には適さないと指摘されている。

• 米アマゾン・ウェブ・サービス（AWS）は2026年7月10日、公式ブログ「AWS ML Blog」において、Stardogの「Semantic AI Application」と「Amazon Bedrock AgentCore」を組み合わせ、自律型AIのための「セマンティックレイヤー」を構築する構成例を公開した。この手法により、企業は複雑なデータ移行を行わずに、複数のデータソースを横断して正確な回答を生成するAIエージェントを構築できるようになるという。

StardogとBedrock AgentCoreによる構成

ブログで提示されたのは、関係性のあるデータを管理するシステムである「Amazon Aurora」と、大量データの分析に特化したデータウェアハウスである「Amazon Redshift」上のデータに対し、StardogのSemantic AI Applicationを重ねてセマンティックレイヤー（データの意味や関係性を統一的に定義する層）を構築する手法である。このレイヤーに対し、AIエージェントの実行環境であるAmazon Bedrock AgentCore上で動作する「Strands Agents」のエージェントが問い合わせを行う。

この構成の最大の利点は、データの抽出・変換・格納を意味する「ETL」処理を挟まない点にある。通常は異なるデータソースを連携させるためにデータ移動が発生するが、本構成では生データを移動させることなく、データベースを横断した顧客の全体像（カスタマー360）に関する質問へ自律的に回答できる。また、StardogのシステムはAmazon EKS、Amazon ECS、AWS LambdaといったAWSの主要なコンピューティング環境の後方でも同様に動作する。Amazon Bedrock AgentCoreを採用した理由については、接続認証やホスティング環境、各種ツールへのアクセス認証情報を一つのマネージドサービス（運用管理が自動化されたサービス）に統合できるためだと説明している。

データ分析の進化とAIエージェントの役割

ブログ記事では、企業におけるデータ分析（アナリティクス）の進展にも言及している。ビジネスの疑問から信頼できる回答を得るまでの時間を短縮することは、過去20年間におよぶ共通の目標であった。定期レポートからダッシュボード、そしてユーザー自身が分析を行うセルフサービス型BI（意思決定を支援するツール）へと進化してきたが、これまではデータエンジニアがあらかじめ作成したモデルに依存しており、アナリストがボトルネックになっていた。

これに対する次の段階として期待されているのが、自律型AIエージェントを活用した「エージェント型アナリティクス」である。この手法では、AIがデータを可視化するだけでなく、ビジネスユーザーの要求に応じて自律的に計画を立て、クエリを作成し、得られた結果を評価し、必要に応じて修正しながら企業のライブデータに対して繰り返し実行する。これにより、ユーザーは分析チームの順番待ちをすることなく、自律型AIを専任アナリストのように稼働させることができる。

データの断片化という課題

しかし、自律型AIを実用化する上でのボトルネックは、AIの脳にあたる「基盤モデル（多様なタスクに適応できるよう大量のデータで事前学習された大規模なAIモデル）」の性能そのものではなく、AIが読み取る「データ」の側にあるという。Amazon Bedrockで提供されている基盤モデルは、すでに複数ステップの計画策定やスキーマ（データベースの構造設計）の推論、SQLクエリの生成において、人間のジュニアアナリストに匹敵する実力を備えている。

問題は、企業のデータがさまざまなシステムに分散し、定義が統一されていない点にある。たとえば、顧客関係管理（CRM）システムに登録されている「顧客」のレコードと、課金システム内の「顧客」レコードは必ずしも一致しない。また、地域ごとの計算ルールの違いにより、北米チームが計算した「収益」と欧州チームが計算した「収益」の数値が異なる場合もある。このような断片化したデータにAIを直接接続してしまうと、AIはSQL文としては文法的に正しく実行可能なクエリを書いたとしても、返ってくる数値が誤っていたり、矛盾していたり、説明がつかなかったりする事態が発生する。同じ質問に対して2つの異なるAIエージェントが別の数値を返すような状況になれば、システムへの信頼性は失われてしまう。

AWSの一般的なデータ環境では、業務データはAmazon AuroraなどのAmazon RDS（リレーショナルデータベースサービス）に格納され、履歴データはAmazon Redshiftに保存される。また、非構造化データはAmazon S3に蓄積され、これをAmazon AthenaやApache Icebergなどのフォーマットを介して読み取る環境が一般的であり、多くの企業はこのデータ配置を維持したいと考えている。そのため、AIがこれらの多様な環境のデータを人間の熟練したアナリストのように解釈できる仕組みが不可欠となる。

RAGとの違いと限界

現在、生成AIとデータを結びつける一般的なアプローチとして「RAG（検索拡張生成：外部の知識源から関連情報を検索し、生成AIの回答精度を高める技術）」が広く使われている。これは社内規定やマニュアルなどの文書をAmazon Bedrock Knowledge Basesに登録し、質問に関連するテキスト部分を抽出してAIの文脈に挿入する技術である。RAGは文書の中から答えを見つけ出すタスクには効果的だが、複数のデータベースシステムからリアルタイムのレコードを結合したり、特定のビジネスルールを適用して集計したりする高度なデータ分析においては機能しにくいという限界がある。