AIエージェントに社内データを横断させる｜AWS実装

AI TREND

AWSとStardog：意味レイヤー実装公開

AWSが、Stardogの意味レイヤーをAmazon AuroraとAmazon Redshiftの上に構築し、Strands AgentsのエージェントをAmazon Bedrock AgentCore上で動かして、ETLなしで両データソースを横断する顧客360度の質問に答える実装方法を公開した。

3 の要点を3分で

AWSは2026年7月11日、StardogのSemantic AI Application（意味レイヤー）をAmazon AuroraとAmazon Redshiftの上に構築し、Strands AgentsのエージェントをAmazon Bedrock AgentCore上で動かして、ETL（抽出・変換・移動）なしで両データソースを横断する顧客360度の質問に答える実装方法を公開した。意味レイヤーは問い合わせ時にSQLへ変換して稼働中のDBから直接行を取得するため、データを動かさずに済む。

本当の難所は基盤モデルではなく、社内で「顧客」や「売上」の定義が各システムでばらつく点にある。定義がずれたままAIに直接データを触らせると矛盾した答えを返す。Stardogはオントロジーで定義を統一し、この問題を抑える。意味レイヤーは検索連携（RAG）を置き換えず補完する位置づけで、多くの本番システムは両方を必要とする。

AgentCoreは認証・ホスティング・ツール認証情報を1つのマネージドサービスに束ね、2025年10月に正式提供（GA）となった。同一のStardog構成はEKS・ECS・AWS Lambdaのいずれの背後でも動き、基盤モデルにはAnthropic Claude Sonnet 4.6を使う。既存のデータ配置を保ちたい企業にとって現実的な選択肢となる。

AIエージェントに社内データを横断させる｜AWS実装の本文内説明図 — 図解: AIエージェント - AWSがStardogの意味レイヤーをAmazonAurora

押さえるポイント

この変化で何が要点か。図解と出典つきで一目で。

データを移動・変換せず稼働中のDBへ直接問い合わせるETLなし設計
AgentCoreが認証・ホスティング・ツール権限を1サービスに統合
同一のStardog構成がEKS・ECS・Lambdaのどれでも動く

5W1Hでサクッと理解

構造化された事実を最初に。誰が何をいつどこでなぜどのように。

誰が: AWSとStardog
何を: 意味レイヤー実装公開
いつ: 2026年7月11日
どこで: AWSブログ
なぜ: 定義統一で信頼確保
どのように: AgentCore連携

背景

企業分析は20年にわたり「ビジネス上の問いから信頼できる答えまでの時間短縮」を追ってきた。定型レポートはダッシュボードへ、さらにセルフサービス型の分析ツールへと進化したが、あらかじめデータエンジニアが用意した範囲でしか答えられず、人間のアナリストがボトルネックだった。生成AIエージェントは計画を立て、問い合わせ文を書き、結果を評価して繰り返し実行できる次の段階にある。ただし本当の難所は基盤モデルではなく、その下にあるデータそのものであり、社内の「顧客」や「売上」の定義が各システムでばらばらなため、AIに直接データを触らせると技術的には正しいが矛盾した答えを返してしまう。

なぜ今注目なのか

Amazon Bedrock AgentCoreは2025年10月に正式提供（GA）となり、認証・ホスティング・ツール権限を1つの管理サービスに束ねてエージェントを本番運用できる基盤として整った。この記事は、単に賢いモデルを使うだけでなく、意味の統一（オントロジー）で信頼できる答えを出すという実務上の勘所を示す。データを動かさずに複数の社内システムを横断できる設計は、既存のデータ配置を保ちたい企業にとって現実的な選択肢となる。

ETLなしで社内データを横断するエージェント構成

AWSが2026年7月11日に公開した実装ガイドは、StardogのSemantic AI Application（意味レイヤー）をAmazon AuroraとAmazon Redshiftの上に構築し、その上でStrands AgentsのエージェントをAmazon Bedrock AgentCore上で動かす構成を示した。特徴は、事前にデータを抽出・変換・移動するETLを挟まない点にある。

In this post we show how to build a semantic layer on AWS using Stardog’s Semantic AI Application over Amazon Aurora and Amazon Redshift, and how to run a Strands Agents agent on Amazon Bedrock AgentCore that queries the layer to answer customer 360 questions across both sources without extract, transform, and load (ETL).
出典: AWS Machine Learning Blog

引用にある「customer 360 questions」とは、顧客に関する情報を複数システムから寄せ集めて一つの全体像として答えること。意味レイヤーは問い合わせを受けるとSQLへ変換し、稼働中のAuroraとRedshiftから直接行を取得する。データはもとの場所に置いたまま横断できる。

なぜモデルの賢さだけでは信頼できる答えが出ないのか

本当の難所は基盤モデルではなく、その下にあるデータそのものにある。社内では「顧客」や「売上」の定義が各システムでばらばらなため、AIに直接データを触らせると技術的には正しいが矛盾した答えを返してしまう。

Stardogの意味レイヤーは、オントロジー（用語や関係の意味を定義した共通の設計図）でこの定義を一本化する。問い合わせ時にSQLへ翻訳して各システムから行を取り出すため、定義が統一された状態で横断的な答えを組み立てられる。この整理は、意味レイヤーが検索連携（RAG、社内文書などを検索してAIの回答に根拠を与える仕組み）を置き換えるものではなく補完するものだ、という位置づけとセットで示されている。多くの本番システムは両方を必要とする。

AgentCoreが束ねる認証・ホスティング・権限

この構成でAmazon Bedrock AgentCoreを使う理由は、本番運用の足回りを1サービスにまとめられる点にある。

We use AgentCore here because it bundles inbound auth, hosting, and tool credentials into one managed service.
出典: AWS Machine Learning Blog

引用の「inbound auth」は外部からエージェントへのアクセス認証、「tool credentials」はエージェントが外部ツールへ接続するための認証情報のこと。従来はこれらを個別に組む必要があったが、AgentCoreは認証・ホスティング（実行環境の用意）・ツール権限の管理を一つのマネージドサービスに束ねる。AgentCoreは2025年10月に正式提供（GA）となっている。

さらに、同一のStardog構成はAmazon EKS（コンテナ運用基盤）、Amazon ECS（同じくコンテナ運用基盤）、AWS Lambda（サーバー管理不要の実行環境）のいずれの背後でも動く。基盤モデルにはAnthropic Claude Sonnet 4.6を使う。運用チームは自社が慣れた計算基盤を選びながら、同じ意味レイヤー構成を維持できる。