Amazon Quick × SageMaker 統合アーキテクチャ — AI/ML パイプラインの可視化と運用自動化

Last updated at 2026-03-29Posted at 2026-03-29

Amazon Quick × SageMaker 統合アーキテクチャ — AI/ML パイプラインの可視化と運用自動化

はじめに

AI/ML プロジェクトにおいて、モデルの開発と運用の間には大きなギャップがあります。データサイエンティストが Jupyter Notebook で開発したモデルを本番環境にデプロイした後、推論結果の監視、データ品質の管理、ステークホルダーへのレポーティングは、多くの場合バラバラなツールで行われています。

Amazon Quick と SageMaker を統合することで、このギャップを埋めることができます。SageMaker Unified Studio でデータの準備からモデル開発まで行い、Amazon Quick で推論結果の可視化・監視・自動化まで一気通貫でカバーするアーキテクチャです。

この記事では、Amazon Quick × SageMaker 統合の具体的なアーキテクチャパターンを3つ紹介し、AWS Well-Architected Framework の観点で評価します。

本記事は Amazon Quick シリーズの第3回です。

第1回: Amazon Quick 入門 — Agentic AI が変えるエンタープライズデータ分析
第2回: Scenarios ハンズオン — 自然言語でデータ分析を自動化する
第3回（本記事）: Amazon Quick × SageMaker 統合アーキテクチャ

アーキテクチャ概要

統合の全体像

re:Invent 2025 のセッション ANT344 で発表された SageMaker × Amazon Quick 統合のキーコンセプトは、Shared Catalog による職種横断のデータ共有です。

統合アーキテクチャは Shared Catalog を中心とした 3 層構成です。

層	コンポーネント	主な役割
カタログ	Shared Catalog	データリネージ・ガバナンス・アクセス制御の一元管理
アプリケーション	SageMaker Unified Studio	データ準備・モデル開発・学習/推論
	Amazon Quick（Quick Sight + Scenarios）	可視化・分析・レポート
	Amazon Quick（Quick Flows + Automate）	モニタリング・アラート・自動修復
ストレージ	Data Lake (S3)	Raw Data → Processed Data → ML Features → Inference Results

Shared Catalog の役割:

データリネージ: データの出所・変換履歴をダッシュボードまで追跡可能
ガバナンス: 行レベルセキュリティ（RLS）や列レベルセキュリティ（CLS）を統一管理
職種横断の共有: データサイエンティスト、データエンジニア、BI アナリストが同じカタログを参照

ロール別の利用イメージ

ロール	主な利用ツール	活動内容
データエンジニア	SageMaker Unified Studio、Quick Flows	データパイプライン構築、品質監視の自動化
データサイエンティスト	SageMaker Unified Studio	モデル開発、学習、評価
BI アナリスト	Quick Sight、Scenarios	推論結果の可視化、ビジネスインサイトの分析
ビジネスユーザー	Quick Sight、Scenarios、Chat Agents	セルフサービス分析、レポート閲覧

統合パターン 1: ML 推論結果の可視化と Scenarios 分析

ユースケース

EC サイトの商品レコメンデーションモデルの推論結果を可視化し、レコメンド精度の推移を監視するケースを考えます。

アーキテクチャ

SageMaker Inference Endpoint → S3（推論結果 Parquet）→ Quick Sight Dataset → Topics（メタデータ）→ Scenarios（自然言語分析）

実装の流れ

1. SageMaker 推論結果の出力設定

SageMaker の Batch Transform ジョブで推論結果を S3 に出力し、Glue ETL で Parquet に変換します。Batch Transform の出力形式は text/csv または application/jsonlines に限定されるため、後段で Parquet 変換を行うのが一般的なパターンです。

import sagemaker
from sagemaker.transformer import Transformer

transformer = Transformer(
    model_name="recommendation-model-v2",
    instance_count=1,
    instance_type="ml.m5.xlarge",
    output_path="s3://ml-pipeline-bucket/inference-results-raw/",
    accept="application/jsonlines",
)

transformer.transform(
    data="s3://ml-pipeline-bucket/input-data/",
    content_type="text/csv",
    split_type="Line",
)

推論結果を Glue ETL で Parquet に変換し、Quick Sight から効率的にクエリできるようにします。

import awswrangler as wr
import pandas as pd

# JSON Lines → Parquet 変換（Glue ETL ジョブ内）
df = wr.s3.read_json(
    path="s3://ml-pipeline-bucket/inference-results-raw/",
    lines=True,
)
wr.s3.to_parquet(
    df=df,
    path="s3://ml-pipeline-bucket/inference-results/",
    dataset=True,
    partition_cols=["inference_date"],
)

推論結果のスキーマ例:

カラム	型	説明
`user_id`	string	ユーザー ID
`item_id`	string	商品 ID
`score`	float	レコメンドスコア（0〜1）
`category`	string	商品カテゴリ
`inference_date`	date	推論実行日
`model_version`	string	モデルバージョン

2. Quick Sight データセットの作成

S3 の推論結果を Quick Sight のデータセットとして登録します。SPICE（Super-fast, Parallel, In-memory Calculation Engine）を利用することで、大量の推論結果も高速にクエリできます。

Quick Sight → Datasets → New dataset
→ Data source: Amazon S3
→ Manifest file:
  {
    "fileLocations": [
      {"URIPrefixes": ["s3://ml-pipeline-bucket/inference-results/"]}
    ],
    "globalUploadSettings": {
      "format": "PARQUET"
    }
  }
→ SPICE への取り込み: 有効化
→ スケジュール更新: 日次

3. Topics の設定

推論結果に対する Topics を設定し、Scenarios の分析精度を高めます。

Topic: "ML Recommendation Analysis"
Columns:
  score:
    description: "レコメンドモデルの予測スコア。1に近いほど推薦度が高い"
    synonyms: ["スコア", "推薦度", "prediction score", "confidence"]
  model_version:
    description: "推論に使用したモデルのバージョン"
    synonyms: ["モデルバージョン", "model ver", "version"]
  category:
    description: "レコメンドされた商品のカテゴリ"
    synonyms: ["カテゴリ", "商品区分", "product category"]

4. Scenarios による分析例

モデルバージョン間の精度比較:

モデル v2.0 と v2.1 のスコア分布を比較し、
カテゴリ別にどちらのバージョンが高いスコアを出しているか分析してください。
特にスコアが 0.3 以下の低信頼度レコメンドの割合も比較してください。

異常検知:

直近7日間でスコアの分布が通常と異なるパターンを検出してください。
特定のカテゴリやユーザーセグメントに偏りがないか確認してください。

統合パターン 2: データ品質モニタリングの自動化

ユースケース

ML パイプラインに投入するデータの品質を自動監視し、異常を検知したら即座にアラートを送信するケースです。データ品質は ML モデルの精度に直結するため、継続的なモニタリングが不可欠です。

re:Invent 2025 のセッション BIZ203（Amazon 社内展開事例）でも、「データ基盤が第一優先」 と強調されていました。

アーキテクチャ

Glue ETL Job → S3（処理済みデータ）→ Quick Sight Dataset → Anomaly Detection → EventBridge → Quick Flows（調査・修復）/ Lambda（自動修復）/ SNS（Slack 通知）

実装の流れ

1. データ品質メトリクスの定義

Glue ETL ジョブの出力に、データ品質メトリクスを含めます。

import awswrangler as wr
import pandas as pd

def calculate_quality_metrics(df: pd.DataFrame) -> pd.DataFrame:
    """ETL 出力データの品質メトリクスを計算する"""
    metrics = []
    for col in df.columns:
        metrics.append({
            "column_name": col,
            "null_rate": df[col].isnull().mean(),
            "unique_count": df[col].nunique(),
            "total_count": len(df),
            "measured_at": pd.Timestamp.now(),
        })
    return pd.DataFrame(metrics)

# メトリクスを S3 に出力
quality_df = calculate_quality_metrics(processed_df)
wr.s3.to_parquet(
    df=quality_df,
    path="s3://ml-pipeline-bucket/quality-metrics/",
    dataset=True,
    partition_cols=["measured_at"],
)

2. Quick Sight の異常検知設定

Quick Sight の ML ベースの異常検知（Anomaly Detection）を使って、品質メトリクスの異常を自動検出します。

Quick Sight → Analysis → Add insight
→ Anomaly detection
→ メトリクス: null_rate
→ ディメンション: column_name
→ 時間軸: measured_at
→ 感度: High（品質劣化は見逃したくないため）

3. アラート連携の設定

Quick Sight の異常検知アラートは、メールまたは SNS トピックに通知を送信できます。SNS → Lambda → EventBridge の連携により、後続の自動化ワークフローにつなげます。

Quick Sight Anomaly Alert
  → SNS Topic (data-quality-alerts)
    → Lambda (アラート解析・EventBridge イベント発行)
      → EventBridge Rule
        → Quick Flows / Slack / Jira

# Lambda: SNS から受信したアラートを EventBridge に転送
import boto3
import json

eventbridge = boto3.client("events")

def lambda_handler(event, context):
    sns_message = json.loads(event["Records"][0]["Sns"]["Message"])

    eventbridge.put_events(
        Entries=[
            {
                "Source": "custom.quicksight.anomaly",
                "DetailType": "Data Quality Anomaly Detected",
                "Detail": json.dumps(sns_message),
            }
        ]
    )

4. Quick Flows による調査・修復ワークフロー

異常が検知されたら、Quick Flows が自動的に調査と初期対応を実行します。

# Quick Flows 定義（概念的な記述）
Trigger: EventBridge - QuickSight Anomaly Alert

Steps:
  - type: reasoning
    prompt: |
      以下のデータ品質異常について調査してください:
      - カラム: {{event.column_name}}
      - メトリクス: null_rate = {{event.value}}
      - 通常値: {{event.expected_range}}
      過去の類似パターンと比較し、原因の仮説を3つ挙げてください。

  - type: action
    target: slack
    channel: "#data-quality-alerts"
    message: |
      :warning: データ品質異常を検知しました
      カラム: {{event.column_name}}
      NULL率: {{event.value}} (通常: {{event.expected_range}})
      AI分析結果: {{previous_step.output}}

  - type: action
    target: jira
    project: "DATA"
    issue_type: "Bug"
    summary: "データ品質異常: {{event.column_name}}"
    description: "{{previous_step.output}}"

統合パターン 3: ダッシュボード CI/CD の自動化

ユースケース

ML パイプラインの更新に伴い、関連するダッシュボードも自動的にテスト・デプロイするケースです。re:Invent 2025 のセッション BIZ406 で紹介された Asset Bundle API を活用します。

アーキテクチャ

Git リポジトリ（ダッシュボード定義）→ CodePipeline → Lambda（Asset Bundle デプロイ）→ Quick Sight（本番）。CodePipeline のステージング段階で Quick Sight（ステージング環境）へのテストデプロイと検証を実行します。

実装の流れ

1. Asset Bundle のエクスポート

Quick Sight の Asset Bundle API を使って、ダッシュボード定義をコードとして管理します。

import boto3

quicksight = boto3.client("quicksight", region_name="us-east-1")

# ダッシュボードを Asset Bundle としてエクスポート
response = quicksight.start_asset_bundle_export_job(
    AwsAccountId="123456789012",
    AssetBundleExportJobId="ml-dashboard-export-001",
    ResourceArns=[
        "arn:aws:quicksight:us-east-1:123456789012:dashboard/ml-pipeline-dashboard"
    ],
    ExportFormat="QUICKSIGHT_JSON",
    IncludeAllDependencies=True,
)

2. CI/CD パイプラインの構成

# CodePipeline 定義（概念的な記述）
Pipeline:
  Source:
    - Git リポジトリ (ダッシュボード定義リポジトリ)

  Stages:
    - name: Validate
      actions:
        - Lambda: ダッシュボード定義の構文検証
        - Lambda: データソース接続の疎通確認

    - name: DeployToStaging
      actions:
        - Lambda: Asset Bundle をステージング環境にインポート
        - Lambda: テストクエリの実行（データが表示されることを確認）

    - name: Approval
      actions:
        - ManualApproval: ステージングダッシュボードの目視確認

    - name: DeployToProduction
      actions:
        - Lambda: Asset Bundle を本番環境にインポート
        - Lambda: デプロイ完了通知

3. Asset Bundle のインポート（Lambda 関数）

import boto3
import json

def lambda_handler(event, context):
    quicksight = boto3.client("quicksight", region_name="us-east-1")
    account_id = context.invoked_function_arn.split(":")[4]

    # Asset Bundle をインポート
    response = quicksight.start_asset_bundle_import_job(
        AwsAccountId=account_id,
        AssetBundleImportJobId=f"deploy-{event['pipeline_execution_id']}",
        AssetBundleImportSource={
            "S3Uri": event["asset_bundle_s3_uri"]
        },
        OverrideParameters={
            "DataSources": [
                {
                    "DataSourceId": "ml-inference-datasource",
                    "DataSourceParameters": {
                        "S3Parameters": {
                            "ManifestFileLocation": {
                                "Bucket": event["target_bucket"],
                                "Key": "manifests/inference-results.json",
                            }
                        }
                    },
                }
            ]
        },
    )

    return {
        "statusCode": 200,
        "importJobId": response["AssetBundleImportJobId"],
    }

4. Chat Agent によるデプロイ支援

非技術者でもダッシュボードのデプロイをリクエストできるよう、Chat Agent（"Asset Helper"）を構築します。

ユーザー: 「レコメンドダッシュボードの最新版を本番にデプロイして」

Asset Helper:
  1. 最新の Asset Bundle を特定
  2. ステージング環境へのデプロイを実行
  3. テスト結果を報告
  4. 承認を求める
  5. 承認後、本番デプロイを実行

Well-Architected Framework の観点での評価

本アーキテクチャを AWS Well-Architected Framework の6つの柱で評価します。

運用上の優秀性（Operational Excellence）

フォルダベースガバナンス:

Amazon Quick では、会社 → 部門 → チームの階層構造でリソースを管理できます。

レベル 1	レベル 2	コンテンツ例
Company（ルート）	Data Engineering	ML Pipeline Dashboards / Data Quality Monitors
	Data Science	Model Performance Reports / Experiment Tracking
	Business Analytics	Executive Dashboards / Self-Service Analytics

運用の自動化:

ダッシュボードの CI/CD パイプラインにより、手動デプロイを排除
Quick Flows によるインシデント対応の自動化
Scenarios による ad-hoc 分析のセルフサービス化

セキュリティ（Security）

認証・認可:

IAM との統合による認証
行レベルセキュリティ（RLS）: ユーザーの所属部門に応じてデータアクセスを制限
列レベルセキュリティ（CLS）: 機密カラム（個人情報等）のアクセス制御

# RLS 設定例: 部門ごとのデータアクセス制限
rls_rules = {
    "Rules": [
        {
            "DatasetParameterName": "department",
            "UserName": "data-science-team",
            "FilterValues": ["data_science"],
        },
        {
            "DatasetParameterName": "department",
            "UserName": "business-analytics-team",
            "FilterValues": ["marketing", "sales"],
        },
    ]
}

Shared Catalog のガバナンス:

データリネージにより、元データからダッシュボードまでの変換履歴を追跡
機密データのタグ付けと自動マスキング

信頼性（Reliability）

クロスリージョンデプロイ:

Asset Bundle API を使って、複数リージョンにダッシュボードをデプロイ可能です。プライマリリージョン障害時のフェイルオーバーに備えます。

# クロスリージョンデプロイ
regions = ["us-east-1", "us-west-2"]
for region in regions:
    client = boto3.client("quicksight", region_name=region)
    client.start_asset_bundle_import_job(
        AwsAccountId=account_id,
        AssetBundleImportJobId=f"deploy-{region}-{execution_id}",
        AssetBundleImportSource={"S3Uri": asset_bundle_uri},
    )

SPICE の冗長性:

SPICE はマネージドサービスとして高可用性が保証されており、データの自動レプリケーションが行われます。

パフォーマンス効率（Performance Efficiency）

SPICE による高速クエリ:

推論結果をSPICE に取り込むことで、数億レコードでもサブ秒のクエリ応答
スケジュール更新により、最新データを定期的に反映

Scenarios の応答速度:

Topics の最適化が応答速度に直結
不要なカラムの除外、適切なシノニム設定でクエリ解釈を高速化

コスト最適化（Cost Optimization）

ユーザー層に応じたライセンス配分:

ユーザー層	推奨プラン	理由
データエンジニア	Enterprise ($40)	Quick Flows/Automate の利用が必要
データサイエンティスト	Enterprise ($40)	Scenarios の深い分析が必要
BI アナリスト	Enterprise ($40)	Scenarios + Research の利用
ビジネスユーザー（閲覧中心）	Professional ($20)	ダッシュボード閲覧と簡単な Q&A
エグゼクティブ	Professional ($20)	レポート閲覧のみ

Agent 利用時間の管理:

Enterprise プランでは Research Agent 4時間/月、Flows/Automate 4時間/月が含まれます。超過分は従量課金（Research: $6/時間、Flows: $3/時間）のため、利用状況のモニタリングが重要です。

持続可能性（Sustainability）

サーバーレスアーキテクチャ:

Amazon Quick 自体がフルマネージドのため、アイドル時のリソース消費が最小
SPICE のオートスケーリングにより、必要な分だけリソースを消費
Batch Transform による推論でオンデマンドなリソース利用

Amazon 社内での大規模展開事例

re:Invent 2025 のセッション BIZ203 で紹介された Amazon 社内での Amazon Quick 展開事例は、大規模導入の参考になります。

展開方法

ブラウザ拡張 + Microsoft 365 アドインによる自動インストール
ユーザーの既存ワークフロー（ブラウザ、Office）に自然に統合

定量的な効果

指標	Before	After	改善率
ステータスレポート作成	週100時間以上	大幅削減	—
財務分析	4時間	5分	98%削減
専門コンテンツ作成	通常時間	1/10	90%削減

成功の鍵

Amazon の事例で最も強調されていたのは 「データ基盤が第一優先」 という点です。Amazon Quick の AI 機能がどれだけ優れていても、基盤となるデータの品質が低ければ期待する成果は得られません。統合パターン2（データ品質モニタリング）を最初に構築することが推奨されます。

導入ロードマップ

Amazon Quick × SageMaker 統合を段階的に導入するロードマップを提案します。

Phase 1: 記述的分析（1〜2ヶ月目）

目標: 既存の ML パイプラインの可視化

Amazon Quick 環境のセットアップ
SageMaker 推論結果を Quick Sight データセットとして登録
基本的なダッシュボードの作成（推論結果の可視化）
Topics の初期設定

Phase 2: 診断的分析（3〜4ヶ月目）

目標: Scenarios による深い分析とモニタリング

Scenarios の本格活用（モデルパフォーマンス分析）
データ品質モニタリングの自動化（統合パターン2）
Quick Flows による Slack/Jira 連携
ビジネスユーザーへの Scenarios トレーニング

Phase 3: 処方的分析（5〜6ヶ月目）

目標: 自動化と CI/CD の確立

ダッシュボード CI/CD パイプラインの構築（統合パターン3）
Quick Automate による複合ワークフローの自動化
Chat Agent の構築（セルフサービス化）
クロスリージョンデプロイの設定

まとめ

Amazon Quick × SageMaker の統合により、AI/ML パイプラインの「ラストマイル」——推論結果の可視化・監視・自動化——を包括的にカバーできます。

3つの統合パターン:

ML 推論結果の可視化と Scenarios 分析: 自然言語でモデルのパフォーマンスを分析
データ品質モニタリングの自動化: 異常検知 → Quick Flows → 自動通知・修復
ダッシュボード CI/CD: Asset Bundle API による自動デプロイ

Well-Architected の観点:

運用上の優秀性: フォルダベースガバナンスとCI/CDによる自動化
セキュリティ: RLS/CLS、Shared Catalog によるデータリネージ
信頼性: クロスリージョンデプロイ、SPICE の高可用性
コスト最適化: ユーザー層に応じたライセンス配分
パフォーマンス: SPICE による高速クエリ、Topics 最適化

Amazon Quick × SageMaker 統合は、AI/ML Data Engineer としてのスキルセットを拡張する強力なツールです。まずは Phase 1 の推論結果の可視化から始めて、段階的に自動化を進めていくことをおすすめします。

参考資料

Amazon Quick シリーズ:

Amazon Quick 入門 — Agentic AI が変えるエンタープライズデータ分析
Amazon Quick Scenarios ハンズオン — 自然言語でデータ分析を自動化する
Amazon Quick × SageMaker 統合アーキテクチャ — AI/ML パイプラインの可視化と運用自動化 ← 本記事

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up