[アップデート] Amazon SageMaker Data Agent が業務用語からのデータ発見が可能になったので実際に試してみた

クラウド事業本部の石川です。Amazon SageMaker Data Agent が SageMaker Catalog のビジネスコンテキスト（用語集・メタデータ・README）を参照し、技術的なテーブル名ではなく業務用語からデータセットの発見と SQL/Python の生成を行えるようになりましたので、実際に試してみました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-sagemaker-data-agent-bdc/

SageMaker Data Agent は、SageMaker Unified Studio のノートブックや Query Editor から自然言語でデータの探索・分析・可視化を行える対話型エージェントです。この Data Agent が SageMaker Catalogに蓄積されたビジネスコンテキストとメタデータを参照できるようになりました。

例えば、データ利用者は tbl_cust_001 のような技術的なテーブル名を覚えていなくても、「顧客の解約に関するデータは？」「顧客維持率を計算して」といった業務用語で問い合わせるだけで、エージェントが適切なテーブルとカラムを特定し、より正確なコードを生成してくれます。Collibra・Atlan・Alation から同期したメタデータも活用できる点が特徴です。

SageMaker Data Agent のビジネスコンテキスト統合とは

公式ドキュメントによると、Data Agent に質問すると以下の流れでテーブルが特定されます。

1. AWS Glue Data Catalog や Redshift の技術メタデータからアクセス可能なテーブルを検索する
2. ビジネスコンテキストを照会し、業務用語に一致する資産を探す
3. 技術メタデータとビジネスメタデータを統合して正しいテーブルを特定する
4. 正しいカタログ・データベース・テーブル・カラムを参照する SQL / PySpark を生成する

エージェントが照会するビジネスコンテキストは、SageMaker Catalog に登録された次の4要素です。

• 用語集（glossary terms）
• カスタムメタデータフォーム（metadata forms）
• 資産のサマリー（summary）
• README

この流れを図にすると以下のようになります。

この統合機能は、SageMaker Unified Studio のノートブック（Data Notebook）と Query Editor で利用できます。なお、Data Agent はあくまで SageMaker Unified Studio の UI 上で動作する機能であり、本記事執筆時点では CLI や SDK から直接エージェントを呼び出す手段は提供されていません。そのため本記事では、ビジネスメタデータの付与を AWS CLI で行い、エージェントへの問い合わせは Query Editor の画面上で実施しています。

やってみた

前提条件

• SageMaker Unified Studio ドメイン（今回は IAM ベースのドメインを使用）
• SageMaker Catalog にプロジェクトとデータ資産が公開済みであること
• 検証環境: リージョン ap-northeast-1

検証の題材には、ワークショップ用に用意されていた quick_workshop.order_info テーブルを使用します。これは受注明細（order）と顧客の産業マスタ（customer_industry）を顧客IDで結合した Glue View で、顧客名・売上・利益・産業・セクター など19カラムを持つ日本語の販売データです。

検証のシナリオ

このテーブルには 売上 や 利益 といったカラムはありますが、「LTV（顧客生涯価値）」という業務概念に直接対応するカラムは存在しません。そこで、

1. order_info にビジネスメタデータ（用語集タグ・サマリー・README）を付与し、
2. Data Agent に「LTV 分析に使えるデータは？」と業務用語で問い合わせて、
3. 技術カラム名にない「LTV」という用語からエージェントが order_info を特定できるか

を確認します。これが特定できれば、ビジネスコンテキストが効いている証拠になります。

Step 1: 事前状態の確認（ビジネスメタデータが無い状態）

まず付与前の状態を確認します。order_info は SageMaker Catalog 上では DataZone の資産（asset）として管理されているため、get-asset で確認します。

$ aws datazone get-asset \
  --domain-identifier dzd-d3w2uawk8vo7a1 \
  --identifier 4iwqc4p3huask9 \
  --query '{description:description, glossaryTerms:glossaryTerms, forms:formsOutput[].formName}' \
  --output json
{
    "description": null,
    "glossaryTerms": null,
    "forms": [
        "GlueViewForm",
        "SubscriptionTermsForm",
        "DataSourceReferenceForm",
        "AssetCommonDetailsForm"
    ]
}

description も glossaryTerms も空で、技術メタデータのフォームしか持たない状態です。ドメインには「Customer Metrics」という用語集があり LTV・Churn Rate・ARR の3用語が登録済みでしたが、order_info には紐付いていませんでした。

Step 2: ビジネスメタデータの付与

ここがこの検証の技術的な肝です。DataZone のアセットはイミュータブルなリビジョンモデルになっており、update-asset のような API は存在せず、メタデータの付与は create-asset-revision で新しいリビジョンを作成することで行います。

付与する内容は次の3点です。

• --description: 資産の説明文（業務的な用途を記述）
• 用語集タグ: --glossary-terms で「LTV」用語を紐付け
• サマリーと README: AssetCommonDetailsForm の summary / readMe フィールドに格納

サマリーと README が AssetCommonDetailsForm に入る点は、フォームタイプの定義を確認すると分かります。summary（最大5000文字）と readMe（最大10240文字）はいずれも @searchable 属性を持っており、まさに Data Agent が検索対象とするフィールドです。

ひとつ注意点があります。create-asset-revision は新リビジョンを作るため、既存のフォームを --forms-input で省略すると消えてしまいます。そのため、既存の4フォーム（GlueViewForm 等）をそのまま再供給したうえで、AssetCommonDetailsForm にだけ summary と readMe を追記する形でリクエストを組み立てます。実行は内容を JSON ファイルにまとめて --cli-input-json で渡しました。

付与した README は以下のような Markdown です。ここでは、業務用語を意図的に盛り込んでいます。

## order_info(受注・顧客分析ビュー)

受注明細と顧客の産業分類を結合した、売上・顧客分析の基盤ビューです。

### 主なユースケース
- 顧客生涯価値(LTV)の算出: 顧客名 × 売上 を集計
- 産業/セクター別の売上・利益分析
- 利益率(利益 ÷ 売上)の可視化

### 関連ビジネス用語
- LTV(顧客生涯価値): 本ビューの 顧客名 × 売上 が算出元データ

create-asset-revision を実行して、既存カタログに存在するアセットに対して、メタデータを更新した新しいバージョンを作ります。

$ aws datazone create-asset-revision \
  --region ap-northeast-1 \
  --cli-input-json file://create_asset_revision_request.json
{
    "revision": "2",
    "description": "受注明細(order)と顧客産業マスタ(customer_industry)を顧客IDで結合した分析用ビューです。顧客別の売上・利益・ディスカウント、産業・セクター別の販売動向、顧客生涯価値(LTV)算出の基盤データとして利用します。",
    "glossaryTerms": ["btm8669qf3vrfd"],
    "formsOutput": [ "GlueViewForm", "SubscriptionTermsForm", "DataSourceReferenceForm", "AssetCommonDetailsForm" ]
}

リビジョン2が作成され、description、glossaryTerms（LTV）、summary/readMe が付与され、既存の4フォームも保全されました。

Step 3: カタログへの反映確認

Data Agent が検索するのはカタログに公開されたリスティングです。作成したリビジョン2をカタログに反映するため、再公開します。

$ aws datazone create-listing-change-set \
  --domain-identifier dzd-d3w2uawk8vo7a1 \
  --entity-type ASSET --entity-identifier 4iwqc4p3huask9 \
  --entity-revision 2 --action PUBLISH
{
    "listingId": "didt0hra2stxg9",
    "listingRevision": "3"
}

反映後、業務用語でカタログ検索すると order_info がヒットするようになりました。

![20260609-amazon-sagemaker-data-agent-bdc-1](/Users/ishikawa.satoru/workspaces/cc/blog/20260606-amazon-sagemaker-data-agent-bdc-2/img/20260609-amazon-sagemaker-data-agent-bdc-1.gif)$ aws datazone search-listings \
  --domain-identifier dzd-d3w2uawk8vo7a1 \
  --search-text "顧客生涯価値 LTV" \
  --query 'items[].assetListing.{Name:name, GTerms:glossaryTerms[].name}' \
  --output json
[
    {
        "Name": "order_info",
        "GTerms": [ "LTV" ]
    }
]

ここまでで「LTV」という業務用語から order_info に到達できる状態になりました。

Step 4: Query Editor で Data Agent に業務用語で質問する

SageMaker Unified Studio のポータルにサインインし、プロジェクトの「クエリエディタ」を開きます。画面右側に Data Agent のチャットパネルが表示されます。次の質問を投げます。テーブル名は一切指定せず、業務用語の「LTV」だけで問い合わせます。

顧客生涯価値（LTV）を分析したいです。どのテーブルを使えばよいですか？
そのテーブルを選んだ理由と、LTVを概算するSQLも教えてください。

接続セレクタから「Athena (SQL)」を選択し、改めて同じ質問を送信します。すると、エージェントは Glue カタログ → データベース → テーブルと探索したうえで、ビジネスメタデータを確認し、次のように order_info を推奨してきました。

以下、一連の流れをご覧ください。

応答の要点を引用します。

1. quick_workshop.order_info （最も推奨）

このテーブルには「LTV」用語タグが付けられており、顧客の購買行動分析・売上分析の中核データセットとして設計されています。

選定理由：

• 顧客ID（顧客id）で顧客ごとのデータ集計が可能
• 売上データ（売上）が含まれており、LTVの基本指標
• オーダー日付（オーダー日付）で期間分析が可能
• 利益（利益）データも含まれ、より詳細な分析が可能
• 産業やセクター情報も含まれ、セグメント別のLTV分析も実施可能
• ビジネスメタデータでLTV分析に特化していることが明記されている

注目すべきは選定理由です。1点目で Step 2 で付与した「LTV」用語タグを明示的に引用し、2点目では 付与したサマリー（顧客の購買行動分析・売上分析の中核データ）をそのまま引用しています。order_info のカラムに「LTV」という名前は存在しないにもかかわらず、ビジネスメタデータを根拠にテーブルを特定できていることが確認できました。これがビジネスコンテキスト統合の効果です。

Step 5: 生成された SQL を実行してみる（つまずきポイント）

エージェントは「顧客別LTV分析」についてと、その SQL を生成し、セルに挿入しました。

顧客生涯価値（LTV）分析

quick_workshop.order_info テーブルを使用して顧客ごとのLTVを計算します。このクエリでは以下の指標を算出します：

• 総売上（Total Sales）: 顧客ごとの累計売上
• 総利益（Total Profit）: 顧客ごとの累計利益
• 購入回数（Purchase Count）: 顧客ごとの注文回数
• 平均購入額（Avg Order Value）: 1回あたりの平均購入額
• 顧客LTV: 総売上をLTVの指標として使用

SELECT 
    "顧客id" AS "Customer_ID",
    "顧客名" AS "Customer_Name",
    "産業" AS "Industry",
    "セクター" AS "Sector",
    COUNT(DISTINCT "オーダーid") AS "Purchase_Count",
    SUM("売上") AS "Total_Sales_LTV",
    SUM("利益") AS "Total_Profit",
    AVG("売上") AS "Avg_Order_Value",
    MIN("オーダー日付") AS "First_Purchase_Date",
    MAX("オーダー日付") AS "Last_Purchase_Date"
FROM 
    "quick_workshop"."order_info"
GROUP BY 
    "顧客id",
    "顧客名",
    "産業",
    "セクター"
ORDER BY 
    "Total_Sales_LTV" DESC
LIMIT 100

右の [Accept and run] ボタンを押してクエリを実行します。

下記のエラーが発生しました。noというカラムがないのか、そもそも権限が付与されていないかと予想されます。

COLUMN_NOT_FOUND: Column 'no' cannot be resolved or requester is not authorized to access requested resources

最初は、[Fix with AI]ボタンやチャットから修正を試みましたが、最終的にエラーの原因は、SageMakerのIAMロールAmazonSageMakerAdminIAMExecutionRole_1 にテーブルへのLake Formation権限付与がされていなかったためです。権限を付与してリトライしたら成功しました。

実際に取得したデータは以下のとおりです。（前頭の数件の抜粋です。）

業務用語での問い合わせから、テーブルの発見・SQL 生成・実データの算出まで一連の流れを確認できました。

考察

今回の検証で得られた知見を整理します。

• ビジネスコンテキスト統合は明確に機能している: カラム名に存在しない「LTV」という業務概念から order_info を特定できました。しかもエージェントは選定理由として、付与した用語集タグとサマリーを具体的に挙げており、技術メタデータだけのマッチングではないことが分かります。データスチュワードが整備した用語集や README が、そのままエージェントの精度に効くという設計思想が体感できました。
• メタデータ整備の投資が活きる: 逆に言えば、用語集・サマリー・README が空のままだとこの機能の真価は出ません。今回は付与前のカタログ検索では業務用語で order_info に到達できませんでした。既存のカタログ整備への投資をそのまま活用できる、というアナウンスのとおりの挙動でした。
• Query Editor では先に接続が必要: Data Agent にカタログを検索させるには、先に Athena もしくは Redshift の接続を選択しておく必要がありました。
• AWS Lake Formation の権限付与: アセットの作成、テーブルメタデータの取得ができたとしても、クエリできるかは、アクセス権限がないとエラーになりますので権限付与が必要です。これは、[Fix with AI]ボタンやチャットから変更できません。

制限事項として、Data Agent は SageMaker Unified Studio の UI（Data Notebook / Query Editor）でのみ利用でき、CLI / SDK からの直接呼び出しはできません。一方で、エージェントが参照するビジネスメタデータの付与は今回のように datazone の API で完全に自動化・コード化できるため、複数テーブルへのメタデータ整備をスクリプト化しておくと、この機能の効果を組織全体に広げやすいと感じました。

最後に

Amazon SageMaker Data Agent のビジネスコンテキスト統合を、quick_workshop.order_info を題材に試してみました。用語集タグとサマリーを付与した結果、エージェントは「LTV 分析に使えるデータは？」という業務用語の質問から、カラム名に LTV を持たない order_info を正しく特定し、その根拠として付与したメタデータを引用してくれました。

技術的なテーブル名を知らない業務担当者でも、整備されたビジネス用語でデータにたどり着けるのは大きな価値です。一方で、アセットの作成、テーブルメタデータの取得ができたとしても、クエリできるかは、アクセス権限がないとエラーになりますので権限付与が必要です。データ活用する立場とデータガバナンスを管理する立場は別なので、正しい動作とも言えます。

メタデータの付与自体は datazone create-asset-revision で自動化できますので、カタログの整備とあわせて、Data Agent を活用したセルフサービス分析の土台づくりを進めてみてはいかがでしょうか。この記事がどなたかのお役に立てば幸いです。