AWS Machine Learning出典公開日2026-10-20 23:33 UTC+8

AtScale と Amazon Bedrock AgentCore を使って AWS 上にエージェント AI 向けセマンティックレイヤーを構築する

における本シリーズの最初の投稿、私たちはAWS上に、Stardogのナレッジグラフを用いたセマンティック層を構築しました。 Amazon Aurora および Amazon Redshift。

における本シリーズの最初の投稿、私たちはAWS上に、Stardogのナレッジグラフを用いたセマンティック層を構築しました。 Amazon Aurora および Amazon Redshift。私たちは行いました Strands エージェントが Amazon Bedrock AgentCore その層に対して。 2番目の投稿同じ顧客360(C360)パターンを維持し、Denodoのデータ仮想化プラットフォームに置き換えて、オンプレミスのPostgreSQLクラスタを含むようソースの構成を拡張しました。この投稿では、再び同じC360パターンを使用し、 AtScale セマンティックレイヤーとして。

AtScaleは前述の2つとは異なる形をとります。セマンティックモデルはトリプルのグラフやビューの集合ではなく、ディメンション型(ディメンション、階層、メジャー)です。AtScaleではモデルを次のようにオーサリングします。セマンティック・モデリング言語「、Gitでバージョン管理されるオープンなYAMLベースの仕様であり、単一のデプロイ済みモデルから、SQL、XML for Analysis (XMLA)、Model Context Protocol (MCP) という3つのプロトコルで同時に公開します。Strandsエージェントと、企業が既に使用しているビジネスインテリジェンス(BI)ツールは、同じ定義から同じ計算結果を取得します。」

このパターンの残りは、以前の投稿からそのまま引き継がれます。基盤モデルは Amazon Bedrock （解説では Anthropic Claude Sonnet 4.6 を使用）が計画を立て、クエリを作成します。Amazon Bedrock AgentCore は Strands エージェントをホストし、エージェントが AtScale に対して提示する送信資格情報を管理します。呼び出し元に適用される結合、メトリクス定義、行フィルターおよび列フィルターは、プロンプト内ではなくセマンティックレイヤー内に存在します。

私たちは、あなたがセマンティックレイヤーアーキテクチャについて、以下の内容を通じてすでにご存知であると想定しています。最初の投稿シリーズの内容：セマンティックレイヤーとは何か、何のためにあるのか、そしてなぜモデルが結合を所有せずにクエリを計画するのかについて。もしこれらが初めて聞く内容であれば、最初の投稿がその基礎を解説しています。

この記事を読み終える頃には、次のことが分かるようになります:

Semantic Modeling Language(SML)でC360ドメインをモデル化する方法:データセット、ディメンションと階層、ファクト、メジャー、計算メジャー、パースペクティブ、そしてGitによるバージョン管理。
AtScaleがAmazon Redshiftに対するディメンショナルクエリをどのように計画するか、そしてAtScaleの自律的な集計管理が、エージェントが生成するクエリパターンをどのように高速化するかについて説明します。
AtScale MCPサーバーを通じてAgentCoreでホストされたStrandsエージェントにモデルを公開する方法、およびそのMCPサーバーを登録する方法 AgentCore Gateway「、これは Amazon Bedrock AgentCore の機能です。」
企業のアイデンティティプロバイダーから人間のユーザーのアイデンティティがどのように伝播するかについて AgentCore Identity(エージェントコア・アイデンティティ)、 Amazon Bedrock AgentCoreの機能、AtScaleへの接続方法、そしてAtScaleがクエリ実行時にロールベースアクセス制御(RBAC)、行セキュリティ、パースペクティブをどのように強制するかについて説明します。
AtScaleをデプロイする方法： Amazon Elastic Kubernetes Service (Amazon EKS) AtScale Helmチャートと AtScale K8S Blueprints リポジトリを使用します。

このウォークスルーの信頼できる情報源は AtScale C2026.7リリースです。特定のツール名やエンドポイントが該当する場合は、AtScaleのドキュメント.

を引用します。例：Amazon Redshift上のCustomer 360

最初の2つの記事で扱ったCustomer 360パターンはそのまま維持されます。ある小売企業には、顧客レコード、注文、製品、リワード登録が複数のシステムに分散しており、ビジネスユーザーはどの事実がどのシステムにあるかを知らなくても、横断的な質問を行いたいと考えています。The Stardog C360 Knowledge Kit このシリーズの最初の投稿では、整数で結合された Customer、Order、Product、Address の各エンティティでこのシナリオをモデル化しています。 cid 顧客テーブルでは主キーとして現れ、購入テーブルでは普通の列として現れるものです。

この投稿が最初の2つの投稿と異なるのは、データが物理的にどこに置かれているかという点です。StardogとDenodoはクエリ実行時に2つのエンジンをまたいでフェデレーションを行います。AtScaleはディメンショナルクエリをウェアハウスのネイティブSQLとして計画し、クエリごとに1つのエンジンへプッシュするため、エンジン間にまたがるデータは上流で統合されます。このチュートリアルでは、分析用のC360データはすべて Amazon Redshift Serverless。Amazon Aurora PostgreSQL は引き続き運用上のシステムオブレコードであり、レプリケーションパス(AWS Database Migration Service または Amazon Aurora から Amazon Redshift への zero-ETL)は分析用コピーを最新の状態に保ちます。エージェントは、Amazon Redshiftテーブルにマッピングされた単一のAtScaleモデルに対してクエリを実行します。

Amazon Redshiftのスキーマ:

表	キーコラム
顧客	cid (PK)、first_name、last_name、email、ssn、phone、location
アドレス	id (PK)、city、state、zip、street_name
クレジットカード	id (PK)、cid、card_num、card_type
リワードアカウント	id (PK), cid, account_id, create_date
購入	id (PK)、pid、purchase_date、quantity、price、cid、card
製品	id (PK)、name、brand、price、dept
カテゴリー	id (PK), dept_name, parent
ベンダー	id (PK), vendor_name, industry

8つのテーブルにわたる9つの注目列。 cid 顧客記録を購入履歴と紐付けます。 pid 購入を製品に紐付けます。 dept 製品をカテゴリに紐付けます。分析に関わるものはすべて Amazon Redshift 上にあるため、結合はセマンティックレイヤーや抽出・変換・ロード（ETL）パイプラインで解決されるのではなく、ネイティブ SQL にプッシュダウンされます。

モデル全体をexerciseする代表的な質問： 生涯支出額による上位 20 名の顧客のうち、まだリワードプログラムに登録していないのは誰ですか？ これは Denodo の記事からの自動登録に関する質問を引き継いだものであり、このシリーズをフォローしている読者が、同じ要求が別のセマンティックレイヤーによってどのように回答されるかを確認できるようにしています。顧客プロファイル、住所、購入履歴、および登録状況に触れます。4 つの論理エンティティにわたり顧客ごとに 1 行です。

本記事で使用する AtScale の用語

AtScale は、ウェアハウス上のディメンショナルモデルとしてセマンティックレイヤーを実装します。AtScale のドキュメントと SML 仕様は、本記事全体を通じて登場する特定のプリミティブのセットを使用します。ウォークスルーに入る前に、簡単なリファレンスがあると便利です。

Semantic Modeling Language（SML）– セマンティックモデルを記述するためのオープンで YAML ベースの仕様。すべての SML オブジェクト（モデル、データセット、ディメンション、階層、メトリック、計算、パースペクティブ、行セキュリティ）は YAML ファイルです。仕様は次の場所にあります。 github.com/semanticdatalayer/SML.
Model（モデル）– 最上位の成果物。モデルはデータセット、ディメンション、ファクト、およびメトリックを参照し、AtScale クエリエンジンを通じてそれらを公開します。
Dimension（ディメンション）と hierarchy（階層）– ディメンションは関連する属性（顧客、製品、日付）をグループ化します。ディメンション内の階層は、これらの属性をレベルに整理します（製品 → カテゴリ → 部門、または年 → 四半期 → 月 → 日）。
Fact（ファクト）と measure（メジャー）– ファクトは、キー列でディメンションに結合された測定可能なイベントを保持するデータセットです。メジャーはファクト列から集計された数量です。たとえば、 SUM(price * quantity) は売上用です。
Calculation（計算）– 他のメジャーに対する数式として表現される派生メジャー。
Perspective（パースペクティブ） – 特定のロールやグループに公開されるモデルの公開可能なサブセット。パースペクティブは、AtScale が呼び出し元にどのディメンションとメジャーを見せるかを制御する仕組みです。
Row security（行セキュリティ） – 呼び出し元の ID または属性に基づいて、呼び出し元に返される行をフィルタリングするモデルオブジェクトです。
自律的な集計管理 – AtScale は複数のコンシューマーにまたがるクエリパターンを監視し、あるパターンが集計テーブルを作成する価値があるほど高コストである場合に、ウェアハウス内にサマリーテーブルをマテリアライズします。そのパターンに一致する後続のクエリは、透過的に集計にルーティングされます。
Design Center – AtScale のオーサリングサーフェスです。モデル作成者はビジュアルキャンバスまたはテキストエディタを通じて SML を編集します。どちらの場合も、ディスク上の成果物は Git 内の SML YAML です。
AtScale MCP サーバー – 製品内の MCP エンドポイントであり、 <atscale-host>/mcp にあり、セマンティックモデルを任意の MCP クライアントに公開します。

より詳しい情報が有用な場合は、 AtScale ドキュメントおよび SML 仕様が権威あるリファレンスです。

リファレンスアーキテクチャ

ランタイムは、Stardog および Denodo の記事と同じ構造に従い、インバウンドパスとアウトバウンドパスに分かれています。

インバウンド。 クライアントはユーザーの質問を AgentCore Gateway を通じて Strands エージェントに送信します。Gateway は、人間のユーザーを識別する JSON Web Token（JWT）をエンタープライズアイデンティティプロバイダー（IdP）に対して検証し、その後リクエストを AgentCore ランタイム（Amazon Bedrock AgentCore の機能）にルーティングします。ここでエージェントプロセスがホストされます。エージェントは Amazon Bedrock 上の Claude Sonnet 4.6 を呼び出して、プロンプトを解釈しクエリを計画します。

アウトバウンド。 エージェントがセマンティックモデルへのクエリを決定すると、AtScale MCP サーバーへのツール呼び出しを実行します。AgentCore Gateway がアウトバウンドプロキシとして機能します。AtScale MCP サーバーは Gateway 上の MCP ターゲットとして登録されているため、ツール呼び出しは Gateway を経由してルーティングされ、そのホップで AgentCore Identity が資格情報を注入します。AtScale の MCP エンドポイントは、ベアラートークン（開発および単一アイデンティティのシナリオ用）または AtScale にバンドルされた Keycloak インスタンスが発行する OAuth 2.0 アクセストークン（本番環境のパス）のいずれかを受け付けます。AtScale エンジンはトークンを検証し、呼び出し元を AtScale のロールに解決し、デプロイされた C360 モデルに対してクエリを計画します。

クエリリクエストは AtScale エンジンを通って下り、結果は上に戻ります。クロスデータベース結合を事前にマテリアライズする ETL ジョブはありません。Amazon Redshift 内の分析用コピーがセマンティックモデルの信頼できるソースであり、上流のレプリケーションパスによって Aurora から最新の状態に保たれています。

図 1: クライアント、Amazon Bedrock AgentCore コンポーネント、AtScale MCP サーバー、AtScale エンジン、および Amazon Redshift Serverless 間のインバウンド認証パスとアウトバウンドクエリパス

このアーキテクチャは、アイデンティティに関して意図的に独自の立場を取っています。Gateway と Identity がランタイムの境界でトークンを保持します。エージェントはトークンを見ることはできず、会話とツール呼び出しのオーケストレーションのみを行います。

セマンティックレイヤーを構築する

AtScale のセマンティックモデルは、Git でバージョン管理される SML オブジェクト（データセット、ディメンション、ファクト、メジャー、計算、パースペクティブ、行セキュリティ）の集合です。動作するモデルは、データエンジニアがスタースキーマから認識できる形状を持ちますが、すべてのオブジェクトはデータ定義言語（DDL）ではなく YAML で表現され、すべてのオブジェクトが個別のファイルです。C360 モデルの構築は 3 つのパスで行われます。Amazon Redshift テーブル上のデータセット、それらの間の結合を伴うディメンションと階層、そしてビジネスロジックを表現するメジャーと計算です。

データセット。 各 Amazon Redshift テーブルは SML データセットになります。データセットは、物理的な接続、スキーマ、テーブル、および AtScale が公開する列を宣言します。データセットは Design Center でビジュアルに作成することも、YAML として直接編集することもできます。どちらのサーフェスも同じ SML ファイルを Git に書き込みます。

ディメンションと階層。 C360 モデルには 7 つのディメンションがあります。 dim_customer は顧客プロファイルの属性を保持し、場所キーを通じて dim_address に結合し、 dim_rewards を通じて cid. dim_product 製品の属性を保持し、それを~を通じて階層に整理します dim_category. dim_date 日付に基づく分析をサポートしています。 dim_vendor サプライヤーごとに製品をグループ化します。 dim_rewards 登録された顧客ごとに1行を保持し、 account_id および create_date、そして雪片が舞い落ちる dim_customer 未登録の顧客が登録属性においてnullとして表示されるようにします。

AtScaleの階層プリミティブは、製品とカテゴリの関係を簡潔に表現するものです。モデルに対するクエリは、ナビゲートすることができます product → category → parent category 再帰的なSQL共通テーブル式を使わずに、大規模言語モデル（LLM）は結合グラフではなく単一のディメンションパスのみを見ることになります。

製品階層の代表的なSMLフラグメント:

# dim_product.yml
unique_name: dim_product
object_type: dimension
label: Product
hierarchies:
  - unique_name: product_category
    label: Product Category
    levels:
      - unique_name: department
        dataset: category
        key_columns: [dept_name]
      - unique_name: category
        dataset: category
        key_columns: [id]
      - unique_name: product
        dataset: product
        key_columns: [id]
secondary_attributes:
  - unique_name: brand
  - unique_name: product_name
    key_column: name

事実と対策。 C360 のファクトテーブルは次のとおりです fact_purchaseAmazon Redshiftの購入テーブルにマッピングされます。これは次と結合します。 dim_customer on cid、そして dim_product オン pid、また dim_date オン purchase_date。措置は次の事実から外れるものではない: total_revenue として SUM(price * quantity), order_count として COUNT(id)、また units_sold として SUM(quantity).

計算メジャー。 クエリではなくモデル内に存在するビジネスロジック。 customer_lifetime_value は total_revenue 顧客グレインで評価され、同じ数式がファクトのより粗いスライスに適用されます。次のようなセグメント big_spender および spend_tier は、条件式を持つ計算メジャーです:

# big_spender.yml
unique_name: big_spender
object_type: metric
expression: |
  CASE WHEN SUM(price * quantity) > 10000
  THEN 'Yes' ELSE 'No' END

この式はクエリ時に評価されます。列であれば、1つのグレインに対して1つの答えを保持します。この式は、クエリが要求するスライス—顧客別、顧客と年別、または地域別—に応じて再計算されます。定義が変更された場合(しきい値が $10,000 から $15,000 に変わるなど)、更新は1つのYAMLファイルで行われ、プルリクエストとしてレビューされ、AtScaleのCIフックを通じてデプロイされます。各コンシューマーは、エージェントであれ、XMLA経由のExcelであれ、Multidimensional Expressions (MDX) 経由のTableauであれ、次のクエリで新しい定義を取得します。

図2:AtScale Design Center の C360 モデル。dim_customer、dim_address、dim_rewards、dim_product(製品からカテゴリへの階層を含む)、dim_date、dim_vendor、fact_purchase が、ディメンションとファクトの関係およびスノーフレーク関係を示すオレンジ色の線で接続されています。計算メジャー(customer_lifetime_value、big_spender、spend_tier)は、ファクトから参照される個別のノードとして表示されます

図3:同じモデルを並べて表示したSML YAML。ディメンション、メトリック、計算ごとに1ファイルで、Gitリポジトリでバージョン管理されています

図3の右側のアーティファクトは、モデルの説明ではありません。それこそモデルそのものです。Design Center のビジュアルキャンバスとYAMLエディターは同じファイルの2つのビューであり、Gitのdiffがすべての変更の信頼できる記録です。これらのファイルはオープンソースのSML仕様に準拠しているため、エンジンなしでもリポジトリを読むことができます。

デプロイ後、モデルはSQL(JDBCベースのBIツールおよびノートブック用)、XMLA(ExcelおよびPower BI用)、MCP(エージェント用)のすべてを介して同時にアクセス可能になります。この total_revenue 計算は、Claude Sonnet 4.6 に対しても、同じXMLAエンドポイントを指すExcelのピボットテーブルに対しても、同じ数値を返します。この一致は「検証」のセクションで確認します。

AtScaleがクエリを計画しプッシュダウンする仕組み

エージェントがセマンティックモデルに対して質問を行うと、AtScaleの AI Computation Engine (ACE) が計画を立てます。クエリが通るステップは、MCP run_query ツールからのディメンショナルSQLリクエストでも、ExcelからのXMLAリクエストでも同じです。異なるのは前端のパーサーだけです。

自動登録に関する質問を例に取ります: ライフタイム支出上位20社の顧客のうち、まだリワードプログラムに登録していないのはどれか? エージェントは、 describe_modelから返されたモデルコンテキストをプロンプトとして受け取り、C360 モデルに対するディメンショナルSQLクエリを組み立てます。ACEはそのクエリを論理プランに解析し、ディメンション参照を基盤となる fact_purchase, dim_customer, dim_address、 dim_rewards データセットに解決し、呼び出し元が対象となる行レベルセキュリティを適用し、その後Amazon Redshiftに対する物理クエリを計画します。

物理計画の段階で、AtScaleを手書きのパイプラインから区別する2つのことが起こります。第一に、結合はセマンティックレイヤーでマテリアライズされるのではなく、ネイティブSQL結合としてAmazon Redshiftにプッシュダウンされます。Amazon Redshiftのオプティマイザーは、フィルターと集計を含む単一のSQLステートメントを認識し、それに従って実行します。第二に、AtScaleの集計マネージャーがレジストリをチェックし、クエリパターンに一致する事前構築済みの集計を探します。適切なグレインで顧客別に購入をグループ化するサマリーテーブルが存在する場合、AtScaleは fact_purchaseをスキャンする代わりにその集計を参照するようにクエリを書き換えます。クエリは、生のファクトテーブルに対して実行する場合にかかる時間のごく一部で返され、ルーティングのためにエージェントやモデラーが手作業を行う必要はありません。

図4:エージェントのディメンショナルクエリがAtScaleプランナーに入ります。プランナーは集計レジストリをチェックし、クエリパターンに一致する集計を見つけ、Amazon Redshiftのサマリーテーブルを参照するようにクエリを書き換えて、結果を返します。下の経路は、一致する集計がない場合に同じクエリが fact_purchase を直接参照することを示しています

集計マネージャーこそが、エージェント駆動のワークロードを経済的に実現可能にするものです。LLM駆動の分析は、人間のアナリストよりも多くのクエリを発行し、 売上について何か興味深いことを教えて のような自由形式のプロンプトは十数件のクエリを生成することがあります。AtScaleはクエリパターンを監視し、ウェアハウス自体(別のキャッシュではなく)に集計をマテリアライズし、一致するクエリを透過的にルーティングします。集計の作成は、エージェントだけでなくすべてのコンシューマーにわたる観測されたトラフィックに基づく需要定義です。

このクエリの監査記録には、LLMが書いたディメンショナルSQLと、AtScaleが書き換えたウェアハウスネイティブSQLの両方に加え、集計がクエリに対応したかどうかが記録されます。その記録は、Design Center の AtScale Queries ページからオペレーターが参照でき、後続のガバナンスセクションはこれを基盤としています。

マルチソースと相互運用性に関する注意点

AtScaleはJDBC経由でウェアハウスに接続します。C360のウォークスルーはAmazon Redshift Serverlessを対象としています。同じSMLモデルがSnowflake、Databricks、Google BigQueryでも動作し、AtScaleはそれぞれの接続パターンをドキュメント化しています。接続を切り替えたときに変わるのは、AtScaleが出力するSQL方言であり、Git内のSMLではありません。

明示しておくべきアーキテクチャ上の特性が1つあります。これは本シリーズの最初の2本の記事とは異なる点です。単一のAtScaleクエリは1つのウェアハウスエンジン内で解決されます。C360モデルが2つのウェアハウスにまたがる場合（例えばディメンションはSnowflake、ファクトはAmazon Redshiftにあるなど）、両方に触れるクエリは次の2つの方法のいずれかで調整する必要があります。1つ目は上流で対処する方法で、レプリケーションパスを通じて1つのウェアハウスに分析用のコピーを統合します。2つ目はウェアハウス自身による方法で、次のようなエンジンレベルのフェデレーションを利用します。 Amazon Redshift Spectrum クエリ用 Amazon Simple Storage Service (Amazon S3)、または Apache Iceberg 両エンジンが読み取り可能なテーブルです。AtScaleはディメンションクエリを計画し、それを1つのエンジンにプッシュします。クロスエンジンの仕組みはその1つ下のレイヤーで実現されています。

その選択には一長一短があります。これにより、StardogやDenodoがクエリ実行時に行うライブのクロスエンジン連携は不可能になりますが、その一方で、AtScaleのプランナーおよび集計マネージャーが単一エンジンの実行モデルを前提として動作できるようになります。これこそが、集計機能が大規模環境で重要な役割を果たせる理由です。運用システムからの変更データキャプチャ(CDC)パイプラインを備えたウェアハウス中心の分析アーキテクチャをすでに運用している企業は、そのアーキテクチャをそのまま活用できます。一方、回答を得るために複数エンジン間のライブ連携が必要な企業には、最初の2つの記事で扱ったセマンティックレイヤーの方が適しています。

ガバナンスされたアクセス:アイデンティティ伝播とランタイム強制

Customer 360 データは規制対象です。一部のユーザー(HR、不正検知担当)は、ソーシャルセキュリティ番号やカード番号などの個人を特定できる情報を見る必要がありますが、ほとんどのユーザー(マーケティング、アナリティクス)は見てはなりません。行レベルのフィルターでアナリストを地域別に制限し、ユーザーごとの監査証跡は、人間のブラウザからデータウェアハウスまで一貫して維持されなければなりません。

AtScaleは、セマンティックレイヤーにおいて、クエリがウェアハウスに到達する前にこれらの要件を強制します。呼び出し元がMCP経由のStrandsエージェントであろうと、XMLA経由でExcelを使うアナリストであろうと、JDBC経由のノートブックであろうと、強制はまったく同じように行われます。SMLの1つの行レベルセキュリティオブジェクト、1つのパースペクティブ、1組のロールバインディングが、モデルの各利用者に適用されます。

ユーザーからAtScaleへのアイデンティティの伝播

このチェーンは、Denodoの記事にあるものと同じ形状をしており、端末のホップがウェアハウスへ続くのではなく、AtScaleエンジンに到達しています。

人間のユーザーはエンタープライズIdPに対してアプリケーションへ認証を行い、JWTを受け取ります。
アプリケーションはJWTをベアラートークンとしてAgentCore Gateway経由でStrandsエージェントに転送します。Gatewayはそれを検証し(発行者、オーディエンス、署名)、リクエストをAgentCoreランタイムへルーティングします。
エージェントがAtScale MCPサーバーへのツール呼び出しを実行すると、AgentCore Identityが、AtScaleにバンドルされたKeycloakから発行され、人間のユーザーのIDにマッピングされたOAuth 2.0アクセストークンを提供します。AtScaleのクレデンシャルがエージェントのコードに入ることはありません。
AtScale MCPサーバーはOAuthトークンを受け付けます。AtScaleエンジンはKeycloakに対してそのトークンを検証し、呼び出し元をAtScaleのロールに解決し、呼び出し元の行レベルセキュリティの制約とパースペクティブのバインディングを適用してクエリを計画します。ウェアハウスへのアクセスには、AWS Secrets Managerから取得したAtScaleの接続アイデンティティが使用されます。

図5:人間のユーザーからAgentCore Gateway、AgentCore ランタイム、AgentCore Identity、AtScale MCP サーバー、AtScale エンジンを経て、セマンティックレイヤーにおける強制ポイントで終わるアイデンティティチェーン。ウェアハウスへのホップは AtScale の資格情報を持つサービスアカウント接続です。

RBAC、行セキュリティ、そしてビューについて

AtScaleはアクセス制御を、組み合わせ可能な3つのプリミティブとして表現しています。RBACはKeycloakのクレームに基づいて呼び出し元にロールを割り当てます。行セキュリティは、呼び出し元の識別情報や属性に基づいて呼び出し元に返される行をフィルタリングするモデルオブジェクトです。パースペクティブは、特定のロールやグループに公開されるモデルの公開可能なサブセットです。

C360のウォークスルーでは、2つのロールを定義します。

hr_user: C360モデルの全体を確認できます。以下を含みます。 ssn および card_num.
marketing_user: マーケティングのパースペクティブを表示します。これは ssn および card_num モデル層において。

いつ marketing_user 「言及する質問を投げかけます」 ssn、エージェントの describe_model 「call returns the Marketing perspective, one that does not include」 ssn. エージェントには投影すべき属性がありません。行レベルのフィルターも同じように機能します。州によって顧客を絞り込む SML の行セキュリティオブジェクトは、エージェントのプロンプトを変更することなく、呼び出し元を特定の行セットに制限します。

監査の忠実度

AtScaleエンジンを経由するクエリは、呼び出し者のID、モデル、LLMが生成したディメンショナルSQL、Amazon Redshiftが受け取ったAtScaleによる変換後のプッシュダウンSQL、適用されたセキュリティポリシー、集約がクエリに応答したかどうか、返された行数とともにログに記録されます。このレコードには、モデルが書いたクエリとウェアハウスが実行したクエリの両方が記録されるため、監査人は人間の質問から、その数値を生成したSQLまでを追跡できます。このシリーズの最初の記事も2番目の記事も、両方の形式のクエリを1つのレコードには記録していません。

ガバナンスされたクエリの監査レコードは次のようになります:

{
  "timestamp": "2026-08-31T10:34:56Z",
  "user_identity": "mary_major@example.com",
  "user_role": "marketing_user",
  "semantic_model": "Customer_360",
  "question": "Top 10 customers by revenue in California",
  "generated_sql": "SELECT full_name, total_revenue FROM ...",
  "translated_pushdown_sql": "SELECT ... FROM redshift ...",
  "security_policies_applied": ["regional_row_security"],
  "served_from": "aggregate",
  "execution_time_ms": 850,
  "rows_returned": 10
}

The generated_sql and translated_pushdown_sql フィールドが、監査証跡を完全にするものです。監査人は、LLMがセマンティックモデルに対して作成したクエリと、ウェアハウスが実際に実行したクエリの両方を目にすることができます。

AtScale MCPサーバーを通じてレイヤーを公開する

The AtScale MCPサーバーはAtScaleディストリビューションのコンポーネントであり、 <atscale-host>/mcpで公開されています。これは AtScale C2026.7リリースで一般提供されており、標準の Model Context Protocolを話します。MCP互換のクライアント（AgentCoreランタイムのStrandsエージェント、Claude、ChatGPT、Cursor、VS Code）であれば、どれでも同じデプロイ済みモデルに対して同じエンドポイントに接続できます。

このサーバーは、セマンティックモデルへのクエリを対象とした一連のツールを公開しています。AtScaleのドキュメントでは、リリースごとのツールリファレンスが公開されています。エージェント駆動のワークロードにとって重要なツールは次のとおりです。

list_models: 呼び出し元が参照できるモデルを列挙し、ディメンションがファクトにどのようにマッピングされるかを記述するカラムグループとともに返します。
describe_model: 選択したモデルのディメンション、階層、メジャー、計算、ビジネス記述を返します。これは、エージェントがクエリの作成を開始する前にシステムプロンプトへ読み込まれるペイロードです。
search_columns: モデルのカラムに対するキーワード検索。完全な describe_model ペイロードではLLMのコンテキストウィンドウを消費しすぎる場合に有用です。
validate_query: ディメンショナルSQLステートメントがウェアハウスに対して実行される前に、モデルと互換性があるかを検証します。これにより、エージェントはAmazon Redshiftに課金されるようなクエリを実行する前に、低コストでクエリを反復改善できます。
run_query: モデルに対してディメンショナルSQLステートメントを実行し、行を返します。
run_queries: 複数のステートメントをバッチで実行します。エージェントが複数の探索的クエリを並行して実行するようなオープンエンドなプロンプトに有用です。
get_version: MCPサーバーのバージョンを報告します。クライアントはこれにより、モデルのスキーマをキャッシュするかどうかを判断できます。

AtScale MCPエンドポイントは2つの認証モードを受け付けます。 ベアラートークン 方式は、Design Centerで発行されたAPIトークンを使用します。すべてのリクエストはトークンの所有者として実行され、この方式は概念実証や単一IDのサービスに適しています。 OAuth 2.0 方式は、AtScaleにバンドルされたKeycloakを使用し、IDが正確に atscale-mcpである事前プロビジョニング済みクライアントを利用します。詳細はAtScaleの Connecting with Claude ページに記載されています。AgentCore Gatewayがエージェントの代理でアクセストークンを提示し、AtScaleエンジンがKeycloakに対してそのトークンを検証し、ダウンストリームのポリシー評価では人間のユーザーのIDが使用されます。

AtScale MCPサーバーをAgentCore Gatewayのターゲットとして登録するには、標準のGateway MCPターゲットフローに従います。先に挙げたツールは通常のツールとしてエージェントに表示され、GatewayホップでのクレデンシャルはAgentCore Identityが処理します。

サイドバー: AI支援モデリングによるモデルの拡張

AtScale MCPサーバーはクエリを対象としたツールを公開していますが、AtScaleは、エージェントがウェアハウスのスキーマをイントロスペクトし、ソースメタデータから候補のSMLモデルを生成し、SMLを仕様に対して検証し、その結果をGitにコミットできるオーサー側のツールによってMCPサーフェスを拡張してきました。エージェントがセマンティックモデルを読み取るだけでなく形成するというこのパターンは、Claude CodeやCursorのワークフローに自然に適合します。これらのワークフローでは、データエンジニアがLLMと協力して、新しいデータセット上にモデルをブートストラップします。

AtScaleはこの方向性を3つの機能としてまとめています。 Semantic Discovery Engine は、ウェアハウスのスキーマ、クエリ履歴、リネージをスキャンし、候補となる結合、階層、メトリック定義を推論します。 Model Recommendation System 観測されたクエリパターンに基づいて、ディメンション、メジャー、リレーションシップを提案します。A 管理されたフィードバックループ 「AIの提案に対する人間によるレビューを維持する」 SML-and-Git ワークフローであり、変更はバージョン管理され、監査可能です。

公開時点で利用可能な具体的なツールは、AtScale MCP tools referenceに文書化されています。最新のリリースノートで、一般提供されているものとまだプレビュー段階のものを確認してください。この記事の残りの部分では、コンシューマーパス、すなわちデプロイされたモデルにクエリを実行するエージェントについて説明します。これは、今日の本番環境のC360ワークフローが依存しているものです。

エージェントをデプロイして実行する

Strands Agents は、エージェントを構築するための小さなフレームワークです。短いPythonエントリポイントが、Amazon Bedrock上のClaude Sonnet 4.6をツールソースとしてAtScale MCPサーバーに接続します。AgentCoreランタイムがこのプロセスをホストします。AgentCore Gatewayがインバウンドリクエストを終端し、AgentCore Identityを通じてアウトバウンドのAtScale資格情報を保持します。Amazon Bedrockでの基盤モデルの利用可能性はAWSリージョンによって異なります。最新の一覧については、 Regional availability by models.

システムプロンプトは重要です。AtScaleのドキュメントおよびAtScaleコーパス内のリファレンスデモは、エージェントに対して一貫して3ステップの呼び出しパターンを推奨しています。 list_models で利用可能なものを確認し、次に describe_model をターゲットモデルに対して実行してディメンションとメジャーをコンテキストに読み込み、その後初めて run_query (または、 validate_query クエリの反復処理にコストがかかる場合は先に)を実行します。その理由は、LLMが列名やメトリック名を捏造すべきではないからです。LLMが参照すべきは describe_model が返したものだけです。システムプロンプトにはそのことを明示的に記載し、さらにターゲットモデル内のビジネス用語に関する短いセクションを含めるべきです(total_revenue は単位ではなく売上ドルを意味する、など)。こうすることで、エージェントはユーザーの質問を適切なメジャーにマッピングできます。

有効にしてください Amazon Bedrock プロンプトキャッシングを、システムプロンプトの再利用部分に対して。 describe_model ペイロードは数千トークンに及び、モデルバージョン内では変更されないため、これをキャッシュすることで繰り返し呼び出し時のクエリごとの入力トークンコストが削減されます。キャッシュポイントの設定は、 BedrockModel オブジェクトに対するリクエストパラメータです。現在のパラメータ名についてはStrandsのドキュメントを参照してください。

検証

セマンティックレイヤー、エージェント、およびIDフローが意図どおりに機能することを確認するため、3つのクエリをエージェント経由で実行し、さらにそのうちの1つを別のロールでガバナンスの再実行を行いました。以下に示す動作が、正常に動作するデプロイメントで再現されるべき挙動です。

クエリ 1、単一ディメンション

ウィスコンシン州の顧客を、都市とともに一覧表示してください。

エージェントはC360モデルに対するディメンショナルSQLクエリを生成し、 first_name, last_name、および city を dim_customer と dim_address から選択し、条件は state = 'WI'です。AtScaleのプランナーはディメンショナルパスをAmazon Redshift内の customer テーブルと address テーブルに解決し、単一のSQLステートメントをプッシュダウンして、行を返します。

クエリ 2、アグリゲートヒットを伴う集約

販売数の上位 10 製品は何ですか?

エージェントは units_sold を製品ごとに集約し、降順で並べ替えます。AtScaleのアグリゲートマネージャーは一致する需要定義アグリゲートを検出し、 fact_purchaseをスキャンする代わりにAmazon Redshift内のサマリーテーブルにヒットするようクエリを書き換えます。Queriesページには、LLMが生成したディメンショナルSQLと、アグリゲートにルーティングされたウェアハウスSQLが並んで表示されます。

クエリ 3、クロスドメイン

生涯購入額による上位20社の顧客のうち、まだリワードプログラムに登録していないのはどこですか？

エージェントは結合を行うクエリを生成します。 dim_customer, dim_address, dim_rewards、および fact_purchase、そして集計します customer_lifetime_value 顧客別に照会します。このクエリでは、次の条件に該当する顧客に絞り込んでいます。 dim_rewards.account_id は null です。への左外部結合 dim_customer オン cid 未登録の顧客はNULLのエンロールメント・レコードとして現れるため、そのまま残ります。エージェントはライフタイム支出額の上位 20 件を返します。AtScale のプランナーは結合を Amazon Redshift に対するネイティブSQLへと解決し、ランキングされたリストを返します。 customer_lifetime_value その計算式はLLMが考案しなければならないものではありません。これは一度定義された計算された指標であり、 customer_lifetime_value.yml クエリ内で名前によって参照されます。

ガバナンスの再実施

我々は、次の要素を追加したQuery 1の変種を実行する ssn 射影へ(ウィスコンシン州の顧客を、SSN付きで表示してください。)を2人の異なる発信者として扱います。As hr_user, describe_model C360モデル全体を返し、エージェントがクエリを構成すると、結果セットにはSSNの値が含まれます。 marketing_user, describe_model マーケティングのパースペクティブを返します。これは公開していません ssn。エージェントには投影すべき属性がないため、SSN を含まない回答を返します。2 回の実行の間で変わるのは呼び出し元のIDだけです。クエリテキスト、エージェントコード、MCP サーバー、AtScale エンジン、Amazon Redshift はいずれも一切変更されていません。

クロスコンシューマー確認

AtScaleのXMLAエンドポイントを通じて同じC360モデルをExcelで開き、ドラッグしました Customer.State および Total Revenue ピボットテーブルに出力した。州レベルの合計値は、エージェントが同等の質問に対して返したものと桁まで一致した。

データソースをまたいだ拡張

C360モデルに新しいデータソースを追加することは、統合の課題ではなくモデリングの課題です。カスタマーサポートチームが、エージェントが回答できるようにモデルにチケット数を含めるよう求めたとします。 過去30日以内にサポートチケットを開設した上位の支出者はどちらですか？ 手順は次のとおりです。

サポートチケットのデータを他のC360テーブルとともにAmazon Redshiftに格納し、運用テーブルで使用されているのと同じレプリケーションパターンを使用します。
新しいテーブルを論理オブジェクトにマッピングするSMLデータセットを追加します。
ディメンションの追加または拡展(dim_ticket)して、joinを追加します dim_customer オン cid.
モデルに必要な新しい指標を追加します(open_ticket_count, avg_resolution_time).
SMLの変更をコミットし、プルリクエストとしてレビューした後、AtScale CIフックを通じてデプロイします。

エージェントコードやAgentCoreの設定は何も変更する必要がありません。次にエージェントが describe_modelを呼び出したとき、新しいディメンションやメジャーが認識され、それらに対する質問を組み立てられるようになります。同じパターンは別のウェアハウスにも適用されます。ソースがAmazon RedshiftではなくSnowflakeやDatabricksに置かれる場合、接続はSnowflakeまたはDatabricks接続を持つ新しいSMLデータセットとなり、クエリは前述のマルチソースに関する注意事項に従ってそのエンジン内で解決されます。

デプロイメント：Amazon EKS上のAtScale

AtScaleはKubernetes上で動作し、AWSでのリファレンスデプロイメントは Amazon EKSです。AtScaleは公式のHelmチャートを oci://docker.io/atscaleinc/atscaleで提供しており、 AtScale K8S Blueprints リポジトリには、AtScaleが想定するコンポーネントを備えたEKSクラスタを立ち上げるためのインフラストラクチャ as code（IaC）のスキャフォールディングが用意されています。具体的には、イングレスコントローラー、AtScaleメタデータデータベース用の永続ストア、クエリキャッシュ用のRedisインスタンス、アイデンティティフェデレーション用のAtScale設定済みKeycloakインスタンスです。

EKS上のAtScaleデプロイメントは、少数のKubernetesポッド群にわたって実行されます。 atscale-engine はコアとなるクエリプランナー兼エグゼキューターです。 atscale-mcp-server はエージェントが接続するMCPエンドポイントです。 atscale-keycloak は、Amazon Cognito、Okta、Azure Active Directory、およびその他のOpenID Connect（OIDC）準拠のIdPにフェデレーションするバンドル済みのアイデンティティプロバイダーです。サポート用のポッドとして、SML APIとDesign Center UI（atscale-sml-api, atscale-sml-web）、PostgreSQLメタデータストレージ（atscale-db）、クエリキャッシュ（atscale-redis）、イングレス（atscale-ingress、通常はAWS Network Load Balancerの前面に配置）を処理するものがあります。

C360アプリケーション（エージェントを呼び出すチャットUIまたはクライアントライブラリ）は、同じEKSクラスタ内の独自の名前空間で実行できます。これはサービスアカウント用IAMロール（IRSA）を使用して、認証情報を埋め込むことなくBedrockや AWS Secrets Manager にアクセスします。

ネットワーキングは標準的です。AtScaleは仮想プライベートクラウド（VPC）エンドポイント、またはAtScale名前空間のアウトバウンド通信をAmazon Redshiftに許可するセキュリティグループルールを通じてAmazon Redshiftにアクセスし、人間のユーザーはイングレスロードバランサーを通じてアプリケーションにアクセスします。

AtScaleは、自己管理型EKS以外のクラウドデプロイメントオプションも提供しています。最新の提供内容とAWSでの利用可能性については、 AtScaleのウェブサイトを確認してください。この記事の残りの部分では、前述の自己管理型パターンを前提とします。

結論

エンタープライズデータへのエージェントによるアクセスには、連携して機能する3つの要素が必要です。クエリを計画・生成できる基盤モデル、ライブウェアハウス上でガバナンスされたビジネス意味のある回答を計算するセマンティックレイヤー、そしてエージェントをホストしアイデンティティフローを管理するランタイムです。Amazon Bedrock、AtScale、Amazon Bedrock AgentCoreは、それぞれこれらの役割の一つを担います。

エージェントはウェアハウスに直接ではなく、セマンティックレイヤーとやり取りします。ディメンション、階層、メジャー、パースペクティブ、行レベルセキュリティはGit内のSMLに存在します。スキーマが変更されたりガバナンスルールが変わったりした場合、更新は1つのファイルで行われ、各コンシューマー（エージェント、Excel、Tableau、Power BI）は次のクエリでそれを取得します。

始めるには

この仕組みを実際に動かせたチームのほとんどは、まず狭い範囲で始めてから拡大しています。

2〜3つのデータソースにまたがり、現在は回答に必要以上の時間がかかっているワークフローを1つ選びます。
そのワークフローが答える必要がある質問を3〜5個書き出します。これらが、セマンティックレイヤーが初日から対応しなければならないクエリになります。
分析データを、 AWS Database Migration Service または Amazon Aurora zero-ETL を使って運用データ用にAmazon Redshift(または任意のウェアハウス)に統合します。
Design CenterでウェアハウスのスキーマからSMLをブートストラップし、その後、コンピテンシー質問(competency questions)に対して磨き上げます。
AtScale HelmチャートとAtScale K8S Blueprintsを使用してAtScaleをAmazon EKSにデプロイし、AtScale MCPサーバーをAgentCore Gatewayターゲットとして登録して、Strandsエージェントを経由して接続します。

参考資料

AtScale MCPサーバードキュメント: Connect to AtScale with AI
AtScale C2026.7 リリースノート: documentation.atscale.com
AtScale MCPツールリファレンス(AtScaleドキュメントとともにリリースごとに公開されます)
AtScale K8S Blueprints: github.com/AtScaleInc/atscale-k8s-blueprints
意味モデリング言語（Semantic Modeling Language）仕様: github.com/semanticdatalayer/SML
Amazon Bedrock AgentCore デベロッパーガイド
Amazon Bedrock プロンプトキャッシング
AWS Prescriptive Guidance の Strands Agents
Stardog と Amazon Bedrock AgentCore を使って AWS 上のエージェント AI 向けセマンティックレイヤーを構築する (本シリーズの最初の記事)
Denodo と Amazon Bedrock AgentCore を使って AWS 上のエージェント AI 向けセマンティックレイヤーを構築する (本シリーズの2番目の記事)

著者について

原文の出典

AWS Machine Learning

原文を読む

内容について

原文の公開と権利は出典元に帰属します。

機械翻訳 · 原文をご参照ください