AWS、エージェントAI向けセマンティックレイヤー構築でStrategy MosaicとAmazon Bedrock AgentCoreの連携構成を公開

要点

• 米AWSは、自律型AI（エージェントAI）向けデータ基盤として、Strategy MosaicとAmazon Bedrock AgentCoreを組み合わせた構築手法を公開した。

• Amazon RedshiftとAmazon Auroraを跨ぐ顧客360度（C360）データモデルを、ETL処理を行わずに2つのリンクモデルで統合する。

• AIエージェント向け通信規格のMCPをはじめ、SQL向けのJDBC/ODBC、BI向けのXMLA、RESTの4つのプロトコルを単一の定義から提供する。

• テーブル結合やメトリクス定義、アクセス制御（RLS/OLS）をAIのプロンプトではなくデータ層に集約し、エンドツーエンドの安全性を担保する。

• 米Amazon Web Services（AWS）は2026年10月20日、自律型AI（エージェントAI）向けのデータ基盤構築に関する技術解説を公式機械学習ブログ（AWS ML Blog）で公開した。同記事では、米Strategy社のデータプラットフォーム「Strategy Mosaic」とAWSの「Amazon Bedrock AgentCore」を連携させ、複数のデータベースを統合したセマンティックレイヤーを構築する手法が紹介されている。執筆はStrategy社のZhili Cheng氏、George Earle氏、Kyler K氏らとの共同によるものだという。

連載における位置づけと「次元モデル」によるアプローチ

AWSはこれまで、エージェントAIが正確にデータを取得・分析するための「セマンティックレイヤー（データの意味やビジネスルールを一元定義し、背後の複雑な構造を抽象化する中間層）」の構築手法を連載形式で解説してきた。第1回では知識グラフ技術のStardogを用い、RDFやSPARQLをベースとしたオントロジー構造を解説。第2回ではDenodoのデータ仮想化技術を採用し、VQL（Virtual Query Language）を用いた仮想ビューによってオンプレミスのPostgreSQLまで連携対象を拡張した。

第3回となる今回の記事では、同様のアーキテクチャパターンを踏襲しつつ、セマンティックレイヤーにStrategy Mosaicを採用している。Stardogがオントロジー、Denodoがデータ仮想化に基づくのに対し、Strategy Mosaicは「ディメンショナル（次元）モデル」を基盤としている点が特徴だという。属性、階層構造、ファクト、メトリクスといった要素をStrategy独自の式構文で組み立て、「リンクモデル」をフェデレーション（データ統合）の基本単位として扱う構成をとっている。

ETL不要でRedshiftとAuroraを統合するC360モデル

今回の記事で扱われている具体例は「C360（Customer 360：顧客に関する多様なデータを全方位から一元的に把握する設計パターン）」である。データソースにはクラウドデータウェアハウスの「Amazon Redshift」と、リレーショナルデータベースの「Amazon Aurora」が選定された。

元記事によると、Strategy Mosaic上で2つのリンクモデルを連携させることで、従来のETL（データの抽出・加工・転送）処理を行うことなくC360ドメインのモデルを構築できるという。さらにMosaicは、SnowflakeやDatabricksなどのクラウドDWH、Amazon RDS、Oracle、SQL Serverなどの運用データベース、Amazon Athena、Trino、SAP HANAなどの分析エンジン、さらにはSalesforceをはじめとするSaaSなど、広範な認定データソースに対応している。このため、今回のRedshiftとAuroraの組み合わせにとどまらず、多様なシステム環境へ柔軟に拡張可能だと説明されている。

MCPを含む4つのネイティブプロトコルを単一の定義から提供

Strategy Mosaicの大きな特徴の一つとして、単一のモデル定義から4つのネイティブプロトコルを提供できる点が挙げられている。具体的には以下の4系統をサポートする。

1. Model Context Protocol（MCP）: AIモデルやエージェントと外部システムを接続するための標準仕様
2. JDBC/ODBC（over Trino）: 従来のSQLクライアント向け通信
3. XMLA: Power BIやMicrosoft ExcelなどのBI・集計ツール向け通信
4. REST: 独自に開発するカスタムアプリケーション向けAPI

今回の検証では、Amazon Bedrockの機能である「Amazon Bedrock AgentCore」のランタイム上で動作する「Strands」エージェントが、MCPエンドポイントを経由してMosaicへアクセスする構成が実証された。

プロンプト依存を脱するセキュリティと実行制御

エージェントAIの運用において課題となりやすいのが、テーブル結合条件や集計ロジックの管理、そして権限制御である。元記事では、テーブル同士の結合条件やメトリクス定義、呼び出し元ごとのフィルタリング処理をエージェントのプロンプト内に記述するのではなく、すべてMosaicの内部に保持させることが示されている。

Mosaicのメトリクス式構文は、基本指標に加え、名前付きフィルターオブジェクトを用いた高度な定義、レベル修飾子、複合指標などをサポートしており、エージェントが推論すべきビジネスロジックを厳密に定義できるという。

セキュリティ面では、呼び出し元のユーザー識別情報がエンドツーエンドで伝播される。これにより、ユーザーごとの行単位アクセス制御（Row-Level Security：RLS）やオブジェクト単位アクセス制御（Object-Level Security：OLS）がMosaic側で確実に適用され、安全なデータアクセスが維持されるとしている。

さらに、エージェントからのリクエスト処理においては、バックエンドのデータベースへクエリを直接渡す「ライブプッシュダウン」と、高速な「インメモリ実行」のいずれかを選択可能であると解説された。また、このように統制されたデータ定義は、AIエージェントのみならず、Power BI、Tableau、データ分析用ノートブック、カスタムアプリケーションに対しても共通の資産としてそのまま公開できると述べられている。

補足

本記事で解説された構成により、データソースを直接複製することなく、AIエージェントと既存の各種分析ツールの双方が同一の統制されたビジネス定義を参照できる環境がAWS上で実現可能となる。