SageMaker Unified Studio本番運用Vol1｜Lakehouse・ML・生成AI

1. この記事について — なぜデータとAIを単一スタジオで統合するのか

1-1. 本記事のゴール

SageMaker Unified Studio は、re:Invent 2024 でプレビュー発表され、2025年3月13日に一般提供(GA)を開始した AWS の統合データ・AI 開発プラットフォームです。従来は SageMaker Studio(ML開発)、Amazon Bedrock コンソール(生成AI開発)、Amazon EMR や Glue Studio(データ処理)、Amazon DataZone(ガバナンス)と用途ごとに分散していた開発環境を、単一のスタジオ上に統合します。

Bedrock IDE(旧 Bedrock Studio)も 2025年3月に Unified Studio 内で GA となり、生成AIアプリ開発と ML 開発が同一プロジェクト内で共存できるようになりました。SageMaker Catalog は DataZone をベースに構築された統合ガバナンス機能で、データ資産・モデル資産・AI 資産を一元カタログ化します。

なぜ「単一スタジオ」が必要なのか

従来のマルチサービス構成では、以下のような摩擦が生じていました。

• データエンジニアは EMR/Glue で ETL を行い、ML エンジニアは SageMaker Studio で学習し、生成AI 開発者は Bedrock コンソールでアプリを構築するという「サイロ分断」
• 各サービスへの個別 IAM ポリシー設定が重複・煩雑化し、権限管理の抜け漏れリスクが増大
• DataZone によるデータカタログ化が別コンソールで行われ、ML・AI 資産との連携が困難
• プロジェクト横断でのデータ・モデル共有にコンソール切り替えが必要で、コラボレーションのオーバーヘッドが高い

Unified Studio はこれらの摩擦を「単一プロジェクト空間」で解消します。EMR・Glue・Athena・Redshift によるデータ処理、SageMaker ノートブックによる ML 開発、Bedrock IDE による生成AIアプリ開発、SageMaker Catalog によるガバナンスを同一プロジェクト内で完結させます。

本記事を読み終えると到達する状態

本記事では、Unified Studio のセットアップから Lakehouse・ML・生成AI・ガバナンスの実践的な活用方法まで、本番設計を想定した手順を解説します。読み終えると、以下の運用が可能になります。

• SageMaker Unified Studio のドメインとプロジェクトを IAM Identity Center(IdC)連携で構成し、チームメンバーへの権限付与を一元管理できます
• SageMaker Lakehouse を起点に S3 や Redshift のデータを Apache Iceberg 標準で統合し、ML 学習・生成AIのデータソースとして活用できます
• Bedrock IDE(Bedrock Studio の後継・2025年3月 GA)で FM・Knowledge Bases・Guardrails・Agents・Flows を組み合わせ、本番品質の生成AIアプリを構築できます
• SageMaker Catalog(DataZone ベース)でデータ資産・モデル資産のカタログ化・系統管理・アクセス制御を統合管理できます

本 Vol1 の対象範囲

本 Vol1 は「データ→ML→生成AI の一気通貫設計」を最優先テーマとし、個別サービスの詳細手順(MLOps パイプライン・Bedrock モデル基盤・DataZone 単体)は既存の専門シリーズへ誘導します。Vol2 では Lakehouse の詳細構成と ML パイプラインの本番化を扱う予定です。

前提知識

本記事を効果的に活用するには、以下の知識があると理解が深まります。

• AWS IAM の基礎(ロール・ポリシー・信頼関係)
• Amazon S3 の基本操作(バケット・プレフィックス・アクセスポリシー)
• SageMaker の基本概念(スタジオ・ノートブック・学習ジョブ)の経験があると望ましい
• Bedrock の FM 呼び出し経験があると §5 の理解が深まります

1-2. 読者像

本記事は、以下のいずれかに該当するエンジニア・アーキテクトを主な読者として想定しています。

• データエンジニア: S3/Redshift/Glue によるデータ基盤を構築・運用しており、ML や生成AIチームへのデータ供給を SageMaker Lakehouse 上で統合したい方
• ML エンジニア: SageMaker Studio や個別の学習ジョブを運用しており、Unified Studio への移行と Bedrock IDE との連携パターンを把握したい方
• プラットフォーム担当: 複数チームが利用するデータ・AI 基盤を標準化したい方。IAM Identity Center を使った権限統合と SageMaker Catalog によるガバナンス実装が急務の場合に特に役立ちます
• 生成AI 開発者: Bedrock IDE(旧 Bedrock Studio)が Unified Studio に統合されたことを受け、既存プロジェクトの移行と新規アプリ開発の最短経路を知りたい方

本記事が扱うのは「統合スタジオとしての設計・設定・ガバナンス」です。SageMaker の ML パイプライン詳細(Pipelines・Feature Store・Model Registry)や Bedrock のモデル評価・Nova 推論などの深掘りは、各専門シリーズを参照してください。

Vol1 で扱う・扱わない内容の整理

1-3. 本シリーズの位置づけと既存記事との棲み分け

SageMaker Unified Studio は「複数の AWS サービスを横断するデータ・AI 開発を単一 UI で行う」プラットフォームです。以下の既存シリーズとの棲み分けを整理しておきます。

従来 SageMaker MLOps(ML/AI Vol3)との棲み分け

従来の SageMaker Studio をベースにした MLOps ワークフロー(Pipelines・Feature Store・Model Registry・エンドポイント管理)は引き続き有効です。Unified Studio はこれらを包含しつつ、データ統合・生成AI・ガバナンスを追加した上位プラットフォームとして位置づけられます。本記事では MLOps パイプラインの詳細手順は扱わず、ML/AI Vol3 へ誘導します。

Data Analytics(Glue/Athena/Redshift)との棲み分け

SageMaker Lakehouse は EMR・Glue・Athena・Redshift を統合データアクセス層として束ねます。ただし各サービスのジョブ設計・クエリ最適化・コスト管理の詳細は Data Analytics Vol1 で扱っており、本記事は「Lakehouse として統合起点を作る方法」に限定します。

Bedrock(モデル基盤/Flows/Agents)との棲み分け

Bedrock IDE は Unified Studio に統合された生成AIアプリ開発環境です。FM の選択・プロビジョンドスループット・Nova 推論・モデル評価などの Bedrock 基盤機能の詳細は Bedrock Vol1 で扱い、本記事では「Bedrock IDE を使ったアプリ開発フロー」にフォーカスします。

Data Governance(DataZone/Lake Formation)との棲み分け

SageMaker Catalog は DataZone をベースにした統合ガバナンス機能です。DataZone のドメイン・プロジェクト・サブスクリプション管理や Lake Formation の列レベル制御の詳細は Data Governance Vol1 で扱い、本記事では「Unified Studio 上の統合ガバナンス UX」に集中します。

棲み分けサマリー

従来SageMaker MLOps編：ML/AI Vol3(パイプライン・Feature Store)を読む

2. セットアップ — ドメイン/プロジェクト構成と IAM Identity Center 連携

2-1. 前提環境とドメイン/プロジェクト構成

SageMaker Unified Studio を利用するには、以下の前提環境を整える必要があります。

AWS アカウントと IAM 設定

• AWS アカウント: us-east-1(バージニア北部)など、Unified Studio 対応リージョンのアカウント
• IAM ロール: SageMaker Unified Studio の管理者ロール(AmazonSageMakerUnifiedStudioFullAccess 相当)
• VPC: オプション。サーバーレスノートブックはデフォルト設定で利用可能です

ドメインとプロジェクトの階層構成

Unified Studio はドメイン(Domain)→プロジェクト(Project)の 2 層構造で管理します。

ドメインは 1 つの AWS アカウントに複数作成できますが、通常は組織単位や事業部門ごとに 1 ドメインを推奨します。

ブループリントの種類

プロジェクト作成時にブループリントを選択します。

• データ分析ブループリント: EMR・Glue・Athena・Redshift を使うデータエンジニアリング向け
• ML 開発ブループリント: SageMaker ノートブック・学習・モデル管理を使う ML 開発向け
• 生成AI ブループリント: Bedrock IDE を使う生成AIアプリ開発向け
• カスタムブループリント: 組織固有の標準設定を定義(2025年9月 GA)

ドメイン作成の手順

AWS コンソールから Unified Studio のドメインを作成します。

1. AWS コンソールで SageMaker Unified Studio を開く: 検索バーで「SageMaker Unified Studio」と入力するか、SageMaker コンソールのサービスメニューから選択します
2. ドメインの作成: 「ドメインを作成」をクリックし、ドメイン名と認証方式(IAM または IAM Identity Center)を選択します。本番環境では IAM Identity Center を推奨します
3. S3 バケットの設定: ドメイン用の S3 バケット(Lakehouse データ保存先)を指定します。既存バケットも流用できます
4. KMS キーの設定: 本番環境では暗号化用の KMS キーを設定します。デフォルトは AWS マネージドキーです
5. VPC 設定: サーバーレスノートブックはデフォルト VPC でも動作しますが、本番環境ではプライベートサブネットへの配置を推奨します

上記手順は AWS CLI でも実行できます。

# ドメイン作成 (AWS CLI)
aws sagemaker create-domain \
  --domain-name "prod-unified-studio" \
  --auth-mode IAM_IDENTITY_CENTER \
  --default-user-settings '{"ExecutionRole":"arn:aws:iam::123456789012:role/SageMakerExecutionRole"}' \
  --region ap-northeast-1

プロジェクト作成の手順

ドメインを作成したら、用途ごとにプロジェクトを作成します。

1. プロジェクトの作成: ドメイン画面から「プロジェクトを作成」をクリックします
2. ブループリントの選択: 用途に合わせてブループリントを選びます。複数の機能を使う場合は「包括的なブループリント」を選択します
3. プロジェクト名と説明の入力: チームやユースケースを識別できる名前をつけます
4. 既存リソースの持ち込み設定: 既存の SageMaker ドメイン・Redshift クラスター・Glue データカタログを「持ち込み」として登録できます
5. メンバーの追加: IdC ユーザーまたはグループを「開発者」「閲覧者」「管理者」ロールで追加します

プロジェクトの持ち込みリソース一覧

2-2. IAM Identity Center 連携と権限管理

Unified Studio は 2025 年に IAM Identity Center(IdC)ドメイン対応を追加しました。これにより、組織の SSO(シングルサインオン)と一元権限管理を Unified Studio に適用できます。

IAM Identity Center 連携手順

1. IAM Identity Center の有効化: AWS Organizations に IAM Identity Center を有効化します。既存の Active Directory や SAML IdP と連携している場合はそのまま利用可能です
2. Unified Studio ドメインで IdC 認証を選択: ドメイン作成時に「IAM Identity Center」認証モードを選択します。従来の「IAM」認証モードとは別に選択肢が追加されています
3. ユーザー/グループの割り当て: IdC で管理するユーザーまたはグループを Unified Studio ドメインに割り当てます。AWS アカウントごとの IAM ユーザー管理が不要になります
4. プロジェクトへのメンバー追加: ドメイン配下の各プロジェクトに IdC ユーザー/グループをメンバーとして追加します。ロール(データ閲覧者・開発者・管理者)単位で権限を制御します

IdC 対応による機能追加

IdC ドメインに切り替えると以下の機能が利用可能になります。

• サーバーレスノートブック: ブラウザで即時起動。JupyterLab 環境を事前プロビジョニングなしに使えます
• data agent: 自然言語での SQL 生成や ETL コード生成を Unified Studio 内で利用できます
• Q Developer 統合: Amazon Q Developer がプロジェクト内のデータコンテキストを理解した上でコード補完・生成をします

権限管理の簡素化

Unified Studio の権限モデルは、プロジェクト単位での一元管理を重視して設計されています。従来は SageMaker/EMR/Glue/Bedrock それぞれに個別のリソースベースポリシーを設定していたところを、プロジェクトのロール設定に集約できます。

既存の AWS リソース(SageMaker ドメイン・EMR クラスター・Redshift クラスター・Glue データカタログ)は、Unified Studio プロジェクトへの「持ち込み」が可能です。新規に作り直す必要はありません。

対応リージョン(2025-03 GA 時点)

SageMaker Unified Studio の GA 時点(2025年3月13日)での対応リージョンは以下の通りです。

• us-east-1(米国東部: バージニア北部)
• us-west-2(米国西部: オレゴン)
• eu-west-1(欧州: アイルランド)
• ap-southeast-1(アジアパシフィック: シンガポール)
• ap-northeast-1(アジアパシフィック: 東京)

東京リージョン(ap-northeast-1)でも GA 時点から利用可能です。対応リージョンは随時拡大されており、最新情報は AWS 公式ドキュメントを参照してください。

IAM ロールとサービスロールの構成

Unified Studio はプロジェクトごとにサービスロールを自動作成します。このサービスロールが EMR・Glue・Athena・SageMaker・Bedrock などのサービスへのアクセスを担います。

自動作成されるロールは最小権限原則で設計されていますが、カスタムデータソースや特定の KMS キーを使う場合はインラインポリシーを追記します。

IdC グループ設計のベストプラクティス

組織規模が大きい場合、以下の IdC グループ設計を推奨します。

• sagemaker-admin グループ: ドメイン管理者。ブループリント管理・プロジェクト作成権限を持ちます
• sagemaker-dev-{project} グループ: プロジェクト単位の開発者グループ。ノートブック実行・モデル学習・Bedrock IDE 利用が可能です
• sagemaker-viewer-{project} グループ: 閲覧専用。ノートブック出力・カタログ検索のみ可能です

プロジェクトごとにグループを分けることで、プロジェクト間のデータ・モデルアクセスを IdC 側で制御できます。

ネットワーク設定と VPC エンドポイント

本番環境では、以下の VPC エンドポイントを設定することを推奨します。

• com.amazonaws.{region}.sagemaker.api: SageMaker API アクセス
• com.amazonaws.{region}.sagemaker.runtime: 推論エンドポイントアクセス
• com.amazonaws.{region}.s3: S3 アクセス(Lakehouse データ)
• com.amazonaws.{region}.glue: Glue データカタログアクセス
• com.amazonaws.{region}.bedrock-runtime: Bedrock モデル呼び出し

インターネットゲートウェイなしでプライベートサブネットから利用する場合、これらのエンドポイントが必須です。サーバーレスノートブックはデフォルトではパブリックインターネット経由になるため、セキュリティ要件に応じて設定を変更してください。

コスト管理の基本設計

Unified Studio 自体の利用料金はありませんが、内部で利用する各サービスの料金が発生します。主なコスト発生源を以下に示します。

プロジェクト単位でタグを設定し、AWS Cost Explorer でプロジェクト別コストを可視化することを推奨します。

セットアップ後の動作確認チェックリスト

ドメインとプロジェクトのセットアップが完了したら、以下の項目を確認します。

1. ドメインアクセス確認: IdC でサインインし、Unified Studio のドメインにアクセスできることを確認します
2. プロジェクト画面の表示確認: 作成したプロジェクトが一覧に表示され、権限に応じたメニューが表示されることを確認します
3. サーバーレスノートブック起動確認: プロジェクト内の「ノートブック」から JupyterLab を起動し、カーネルが選択できることを確認します(IdC ドメインのみ対応)
4. Lakehouse 接続確認: SageMaker Lakehouse のデータソース一覧に S3 バケットと Redshift クラスターが表示されることを確認します
5. Bedrock IDE 起動確認: Bedrock IDE のメニューが表示され、FM の一覧が取得できることを確認します
6. SageMaker Catalog 確認: 「Catalog」タブを開き、持ち込んだ Glue データカタログのテーブルが検索できることを確認します

よくある設定ミスと対処

2-3. CloudTrail と CloudWatch によるドメイン監査

CloudTrail による操作ログの有効化

Unified Studio の操作(ドメイン作成・プロジェクト追加・メンバー変更)は AWS CloudTrail に記録されます。マネジメントイベントトレイルを有効化しておくことで、誰がいつどのプロジェクトを変更したかを追跡できます。

重要なイベント例:
– sagemaker:CreateDomain: ドメイン作成
– sagemaker:CreateProject: プロジェクト作成
– sagemaker:AddAssociation: リソース関連付け追加
– sagemaker:DeleteDomain: ドメイン削除(誤操作防止のアラート推奨)

CloudWatch アラームの設定推奨事項

3. SageMaker Lakehouse — データ統合とカタログ

3-1. Lakehouse アーキテクチャ(Iceberg)と統合データアクセス

SageMaker Lakehouse は、S3 上のデータと Redshift のデータウェアハウスを Apache Iceberg オープン標準で統合し、単一のデータ起点として扱えるようにする仕組みです。従来はデータレイク(S3)とデータウェアハウス(Redshift)が分断されており、両者を横断するクエリには ETL パイプラインや個別コネクタが必要でした。Unified Studio の Lakehouse はこの分断を解消し、データエンジニア・ML エンジニア・データアナリストが同一のカタログ・同一の権限モデルでデータにアクセスできる環境を提供します。

Apache Iceberg がもたらすオープン標準の利点

Apache Iceberg はテーブルフォーマットの業界標準として広く採用されており、AWS Glue・Amazon Athena・Amazon Redshift・Apache Spark/Flink など主要エンジンが対応しています。SageMaker Lakehouse が Iceberg を採用することで、以下の恩恵を受けられます。

• タイムトラベル: スナップショット管理により過去時点のデータを参照可能です。ML 特徴量の再現性確保や実験のロールバックに有効です。
• スキーマ進化: カラム追加・型変更を既存クエリを壊さず適用できます。プロダクションデータのスキーマ変更に柔軟に対応します。
• 行レベルの更新・削除: S3 上のデータに対して UPDATE/DELETE が可能です。GDPR 準拠のデータ消去要件にも対応できます。
• ベンダーロックインの回避: Iceberg フォーマットは Apache ライセンスのオープン仕様です。AWS 以外のエンジンからも同じデータにアクセスできます。

Athena を使って Iceberg テーブルを作成・参照する基本的な SQL を示します。

-- Apache Iceberg テーブルを Athena で作成
CREATE TABLE lakehouse_db.sales_features (
  customer_idBIGINT,
  purchase_date DATE,
  product_code  VARCHAR(50),
  amount  DECIMAL(10, 2)
)
LOCATION 's3://my-lakehouse-bucket/features/sales/'
TBLPROPERTIES ('table_type' = 'ICEBERG', 'format' = 'parquet');

-- タイムトラベルクエリ (1 日前のスナップショットを参照)
SELECT * FROM lakehouse_db.sales_features
FOR SYSTEM_TIME AS OF (NOW() - INTERVAL '1' DAY);

S3/Redshift の統合データアクセス

SageMaker Lakehouse では、S3 の Iceberg テーブルと Redshift のテーブルを、Unified Studio の SQL エディタから同一クエリで扱えます。例えば、Redshift に蓄積された販売トランザクションデータと S3 に保存された行動ログデータを JOIN して ML の特徴量テーブルを生成する処理を、単一クエリで実行できます。データ接続の設定は Unified Studio のプロジェクト設定から行い、接続情報は SageMaker Catalog に登録されます。エンジニアは「どのストレージにあるか」を意識せず、Catalog 上の論理テーブル名でデータにアクセスできます。

Unified Catalog — DataZone ベースの統合 UX

SageMaker Catalog は DataZone をベースとした統合データカタログで、Unified Studio に深く組み込まれています。主な機能は以下のとおりです。

• 統合 UX: データ資産・ML モデル・AI 資産を単一のカタログで横断検索できます。
• セマンティック検索: 「売上集計に使える特徴量テーブル」のような自然言語クエリで関連データ資産を発見できます。
• 単一権限モデル: Catalog 上で定義した Entitlement が、S3・Redshift・Athena への実際のアクセス制御に自動的に反映されます。データへのアクセス申請・承認フローも Catalog UI から行えます。
• メタデータ管理: テーブルスキーマ・系統(Lineage)・タグ・ビジネス用語集をカタログで一元管理できます。

DataZone 単体の詳細(ドメイン/プロジェクト購読フロー・Lake Formation との統合・Clean Rooms)は、Data Governance シリーズで扱います。本§3 は「Lakehouse という統合データ起点をどう設計するか」に集中した観点です。

S3 Tables 統合(2025年)

2025年から提供が拡大した S3 Tables は、S3 に Iceberg テーブル管理機能をネイティブに組み込んだものです。従来の S3 バケット上で Iceberg メタデータを手動管理するアプローチとは異なり、S3 Tables ではスナップショット管理・コンパクション・有効期限管理を AWS がマネージドで提供します。SageMaker Lakehouse は S3 Tables と統合されており、Unified Studio からそのままテーブルとして参照できます。ML パイプラインの特徴量ストアや生成AIのナレッジデータ管理に S3 Tables を活用することで、インフラ管理コストを大幅に削減できます。

S3 Access Grants によるきめ細かなアクセス制御(2025年)

Lakehouse のアクセス制御には S3 Access Grants が統合されています。S3 Access Grants は、S3 バケット・プレフィックス・オブジェクト単位でアクセス権限を付与する仕組みで、SageMaker Catalog と連携することで、プロジェクト・チーム・個人ユーザーごとに細粒度の権限設計を適用できます。Catalog が各ユーザーの Entitlement を管理し、実際のデータ取得時に S3 Access Grants が一時認証情報を発行する流れになります。これにより、データのサイロを排除しつつコンプライアンス要件を満たすガバナンスを一元化できます。

3-2. Visual ETL と Zero-ETL

Unified Studio 内には、データパイプライン構築のための Visual ETL と Zero-ETL という2つのアプローチが統合されています。

Visual ETL — ノーコードでのデータ変換

Visual ETL は、AWS Glue をバックエンドとして、Unified Studio の GUI 上でドラッグ&ドロップによるデータ変換パイプラインを構築できる機能です。S3・RDS・DynamoDB・Redshift などのソースから、フィルタリング・結合・型変換・集計などの変換ステップを視覚的に定義し、最終的に S3 の Iceberg テーブルや Redshift に書き出せます。

ML エンジニアにとって特に有用なのは、特徴量エンジニアリングパイプラインを Visual ETL で構築できる点です。生データの前処理・正規化・欠損値補完などの変換ロジックを、コードを書かずに定義してスケジュール実行できます。変換ロジックは Glue ジョブとして保存されるため、既存の Glue 資産との連携も可能です。

Visual ETL のジョブ実行履歴は Unified Studio の Project ビューから確認でき、失敗した変換ステップのデバッグも GUI 上で行えます。大規模データの処理には Auto Scaling が適用され、処理完了後はリソースが自動解放されるサーバーレス実行も選択できます。

Zero-ETL — ETL なしのリアルタイムデータ統合

Zero-ETL は、ETL パイプラインを一切書かずにデータソースのデータを Redshift へリアルタイムに統合する仕組みです。Aurora MySQL/PostgreSQL・RDS MySQL・DynamoDB・S3 などのソースから、変更データキャプチャ(CDC)を使ってデータを Redshift へ複製します。Unified Studio では、Zero-ETL 統合をプロジェクト設定から数ステップで有効化できます。ソースとターゲットのマッピング定義後は ETL コードのメンテナンスが不要になるため、データパイプラインの運用コストを大幅に削減できます。OLTP データベースの最新データを ML 学習や生成AIのナレッジベースに即時反映したいユースケースで特に効果を発揮します。

Zero-ETL 統合は AWS CLI から有効化できます。

# DynamoDB テーブル → Redshift Serverless への Zero-ETL 統合作成
aws redshift create-zero-etl-integration \
  --source-arn arn:aws:dynamodb:ap-northeast-1:123456789012:table/sales_transactions \
  --target-arn arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/prod-ns \
  --integration-name "dynamo-to-redshift-sales"

Lakehouse 全体のデータパイプライン(Visual ETL + Zero-ETL)は、SageMaker Catalog に自動的に系統(Lineage)として記録されます。「どのデータが、どの変換を経て、どの ML モデルに使われたか」をカタログ上でトレースできるため、コンプライアンス対応と再現性確保が両立します。

個別分析サービスの深掘り：Data Analytics Vol1(Athena/Glue/Redshift)を読む

4. ML開発フロー — ノートブックから学習・モデル管理まで

4-1. サーバーレスノートブックと学習

SageMaker Unified Studio の ML 開発環境は、従来の SageMaker Studio の後継として、プロジェクトベースの統合開発体験を提供します。最大の変更点は、すべての ML 開発リソースが「ドメイン > プロジェクト」の階層に紐付き、データ・AI・分析の担当者が同一プロジェクト上でコラボレーションできる点です。

サーバーレスノートブック

Unified Studio のノートブック環境は JupyterLab ベースで、コンピューティングリソースの管理をサーバーレスで提供します。従来の SageMaker Studio はインスタンスを常時起動する必要がありましたが、Unified Studio のサーバーレスノートブックは使用時のみリソースが割り当てられ、アイドル時のコストが発生しません。

IAM Identity Center(IdC)ドメイン対応後のアップデートにより、サーバーレスノートブックは IdC で認証されたユーザーが直接利用できます。チームメンバーが Unified Studio のプロジェクトに招待されると、追加の IAM 設定なしにノートブック環境を共有できます。ノートブック上では Lakehouse への接続が事前に設定されているため、Athena や Redshift Serverless 経由で S3/Redshift 上のデータに直接アクセスできます。

data agent による自然言語データ操作

Unified Studio には data agent が統合されており、自然言語でデータ操作を指示できます。「先月の売上データをプロジェクト別に集計して特徴量テーブルを作って」と入力すると、data agent が SQL を生成・実行し、結果を Lakehouse テーブルに書き出します。SQL に慣れていない ML エンジニアでもデータ前処理を効率化できます。

SageMaker Training ジョブと Spot Training

ノートブックでプロトタイプを作成した後、本番規模の学習には SageMaker Training ジョブを使います。Unified Studio のプロジェクト画面から、以下のパラメータを設定してジョブを起動できます。

• フレームワーク: 組み込みアルゴリズム・PyTorch・TensorFlow・Hugging Face Transformers など
• インスタンスタイプ: CPU インスタンス(ml.m5.xlarge 等)から GPU インスタンス(ml.p4d.24xlarge 等)まで対応
• 分散学習: マルチノード・データ並列/モデル並列を設定ファイルで指定
• Spot Training: EC2 スポットインスタンスを使い最大 90% のコスト削減が可能

Spot Training では中断時の自動チェックポイントが SageMaker で管理されるため、長時間学習でもスポット中断からの再開が自動化されています。学習ジョブのメトリクスは CloudWatch Metrics に自動送信され、Unified Studio の Project ビューでリアルタイムにモニタリングできます。

サーバーレスノートブックから Lakehouse のデータを取得し、SageMaker Training ジョブを起動するコード例を示します。

import awswrangler as wr
import sagemaker
from sagemaker.estimator import Estimator

# Lakehouse の Iceberg テーブルからクエリ
df = wr.athena.read_sql_query(
 sql="""
  SELECT customer_id, amount, product_code
  FROM lakehouse_db.sales_features
  WHERE purchase_date >= DATE('2025-01-01')
 """,
 database="lakehouse_db",
 workgroup="unified-studio-wg"
)
print(f"取得: {len(df)} 行")

# SageMaker Training ジョブ起動 (Spot Training でコスト削減)
session = sagemaker.Session()
estimator = Estimator(
 image_uri=sagemaker.image_uris.retrieve("xgboost", session.boto_region_name, "1.7-1"),
 instance_type="ml.m5.2xlarge",
 instance_count=1,
 role=sagemaker.get_execution_role(),
 use_spot_instances=True,
 max_wait=7200,
 hyperparameters={"num_round": 200, "max_depth": 6, "eta": 0.05, "objective": "reg:squarederror"}
)
estimator.fit({"train": "s3://my-lakehouse-bucket/features/sales/train/"})
print(f"モデル出力先: {estimator.model_data}")

4-2. モデル管理と従来 MLOps との連携

Unified Studio 内での ML 開発フローは「データ → 学習 → モデル管理 → デプロイ」までを一気通貫で扱います。MLOps の深層(複雑なパイプライン・Feature Store・Model Registry の詳細運用)は SageMaker MLOps Vol3 に委ねる設計です。本§4-2 では、Unified Studio 内で完結するモデル管理と、デプロイまでのフローを解説します。

SageMaker Model Registry との連携

学習が完了したモデルは、SageMaker Model Registry に登録して管理します。Unified Studio のプロジェクト内から直接 Model Registry に登録でき、以下の情報を一元管理できます。

• モデルバージョン・学習ジョブの識別情報・ハイパーパラメータ
• 評価メトリクス(accuracy/F1/AUC など)
• Approval ワークフロー(Pending Approval → Approved/Rejected)
• SageMaker Catalog へのメタデータ自動登録

Model Registry の Approval ワークフローを活用することで、「開発環境での検証済みモデルのみを本番 Endpoint にデプロイ」という CI/CD ゲートを設けられます。承認された Model Package のみが次フェーズに進める運用です。MLOps パイプライン(SageMaker Pipelines)や Feature Store の詳細運用は、SageMaker MLOps Vol3 で扱います。本§4 は「Unified Studio 内でのモデル開発サイクル」に集中します。

Amazon Q Developer 統合

Unified Studio には Amazon Q Developer が統合されており、ML 開発の生産性を向上させます。

• NL SQL: 自然言語でクエリを記述すると、Q Developer が最適な SQL を生成します。Lakehouse の Iceberg テーブルに対してもそのまま使えます。
• ETL コード生成: 「顧客テーブルと取引テーブルを結合して特徴量を作るコードを書いて」と指示すると、PySpark や Pandas のコードを生成します。
• コード補完: JupyterLab 上でリアルタイムにコード補完を提供し、エラーメッセージの原因説明も行います。
• ドキュメント生成: 関数やクラスのドキュメントを自動生成し、チーム内のコード共有を促進します。

Q Developer は Unified Studio のエディタに統合されており、別タブを開かずにアシスタント機能を利用できます。前処理スクリプトの定型作業を大幅に削減できます。

モデルデプロイ — Inference Endpoint

開発・検証が完了したモデルを本番環境で推論するには、SageMaker Inference Endpoint を使います。Unified Studio のプロジェクト画面から、以下の Endpoint タイプを選択してデプロイできます。

本番ワークロードでは Real-time Inference + Auto Scaling の組み合わせが基本です。CloudWatch メトリクス(InvocationsPerInstance/CPUUtilization)に基づくスケーリングポリシーを設定し、トラフィック変動に自動対応します。

新バージョンのモデルをデプロイする際は Blue/Green デプロイまたは Canary デプロイを選択できます。Canary デプロイでは「新バージョンに 10% のトラフィックを流し、エラー率が閾値以下なら段階的に 100% へ移行」という安全なロールアウトが可能です。デプロイした Endpoint のレイテンシ・スループット・エラー率は、Unified Studio の Project ビューと CloudWatch から継続的にモニタリングできます。

MLOpsパイプライン深掘り：ML/AI Vol3(Pipelines/Feature Store)を読む

5. 生成AI開発 — Bedrock IDE・プロンプト/Flow・RAG・アプリ化

5-1. Bedrock IDE の生成AIアプリ開発

Bedrock IDEは、Amazon Bedrock Studioの後継サービスとして2025年3月にSageMaker Unified Studio内でGA(Generally Available)となりました。従来のBedrock Studioがスタンドアロンのコンソールとして提供されていたのに対し、Bedrock IDEはUnified Studioのプロジェクト構造に完全統合されており、データ管理・ML開発・生成AIアプリ開発を単一の作業環境から行えます。

FM 選択と Playground

生成AIアプリ開発の起点はFM（Foundation Model）の選択です。Bedrock IDEのプロジェクト画面ではAmazon Nova・Anthropic Claude・Meta Llama・Mistral等の複数FMをPoint-and-clickで切り替えられます。モデルを選択するとPlayground画面が開き、システムプロンプトの設定・ユーザーターンの入力・レスポンスのリアルタイム確認を即座に行えます。Playgroundはモデルバージョン管理・プロンプトテンプレートのバージョン管理をサポートしており、チームでのプロンプト開発サイクルを効率化できます。

プロンプト評価フレームワーク

Bedrock IDEに組み込まれた品質保証機能として、プロンプト評価フレームワークがあります。評価データセット（質問・期待回答のペア）をS3やLakehouseから読み込み、定量指標（BERTScore・ROUGE・カスタム評価関数）でモデル出力の品質を測定します。複数のモデルを同一データセットで並列評価し、精度・コスト・レイテンシのトレードオフを可視化できるため、本番投入前のモデル選定に活用できます。評価結果はプロジェクト内に保存されるため、チームメンバーと比較・共有しながらモデル選定を進められます。

Unified Studio 内でのBedrock IDE 利用の利点

Unified Studio内でBedrock IDEを利用する最大の利点は、プロジェクト全体のコンテキストをシームレスに引き継げる点です。Lakehouseで蓄積されたデータソース・SageMaker Catalogへ登録されたAI資産・プロジェクトメンバーの権限情報が統合されており、コンソールを切り替えることなく生成AI開発を進められます。FM選択からPlayground評価、KB接続、本番公開までの作業がプロジェクト単位で管理されるため、開発ライフサイクル全体をチームで一元管理できます。

5-2. Knowledge Bases・Guardrails・Agents・Flows の活用

Knowledge Base と RAG 構築フロー

Knowledge Base（KB）はRAG（Retrieval-Augmented Generation）を構成する中核機能です。Bedrock IDE画面でデータソース（S3バケット・Lakehouseのテーブル・既存データカタログのエントリ）を指定すると、ドキュメントの自動チャンキング・埋め込みベクトルの生成・ベクトルストア（Amazon OpenSearch Serverless等）へのインデックス化がパイプラインとして自動実行されます。Unified Studio内でLakehouseに整備したデータをKBのソースとして直接参照できるため、データ基盤とRAGの接続に別途ETLを構築する必要がありません。データが更新されるたびにKBの自動同期スケジュールを設定でき、常に最新のコンテキストをFMに提供できます。

以下は SDK を使って Knowledge Base のデータソース同期をトリガーし、RAG クエリを実行する例です。

import boto3

bedrock_agent = boto3.client("bedrock-agent", region_name="ap-northeast-1")

# Knowledge Base のデータソースを同期 (S3 の更新内容をインデックスへ反映)
bedrock_agent.start_ingestion_job(
 knowledgeBaseId="XXXXXXXXXX",
 dataSourceId="YYYYYYYYYY",
 description="商品ドキュメントの週次更新"
)

bedrock_rt = boto3.client("bedrock-agent-runtime", region_name="ap-northeast-1")

# RAG クエリ: Knowledge Base を参照して FM が回答
response = bedrock_rt.retrieve_and_generate(
 input={"text": "在庫切れ商品の代替品を提案してください"},
 retrieveAndGenerateConfiguration={
  "type": "KNOWLEDGE_BASE",
  "knowledgeBaseConfiguration": {
"knowledgeBaseId": "XXXXXXXXXX",
"modelArn": "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0"
  }
 }
)
print(response["output"]["text"])

Bedrock Guardrails によるポリシー適用

Bedrock GuardrailsはKBに接続したFMの出力を保護するポリシー層です。有害コンテンツのフィルタリング・PII（個人識別情報）の自動マスキング・根拠なき幻覚（ハルシネーション）の抑制・特定トピックの拒否をポリシーとして定義できます。GuardrailsはBedrock IDE画面から設定を追加でき、コードを一切書かずにFMのアウトプットポリシーを適用できます。企業ガバナンス基準に合わせた安全な生成AIアプリをスピーディーに実装できます。

Bedrock Agents のビジュアル開発と本番アプリ化

Bedrock Agentsはツール呼出し（API連携・Lambda関数実行・KB検索）の自動化機能です。エージェントの目的・使用するツール群・接続するKBをBedrock IDE画面上で定義すると、ユーザーからの自然言語入力に応じて必要なツールを自律的に選択・実行するエージェントが完成します。Bedrock IDE内のビジュアルテスト画面でエージェントの動作を確認し、そのまま本番エンドポイントとして公開できます。

Bedrock Flows による処理パイプライン定義

Bedrock Flowsはマルチステップ処理のビジュアルパイプライン定義機能です。入力→前処理→KB検索→FM推論→後処理→出力の各ノードをキャンバス上のドラッグ&ドロップで接続し、条件分岐・ループ・エラーハンドリングを含む複雑な処理フローを構築できます。完成したFlowはAPI呼出しでトリガーできるため、Webアプリ・社内ツール・バッチ処理の基盤として活用できます。Agents と Flows はどちらも本番エンドポイントとして外部から呼び出せる形式で公開でき、数時間で生成AIアプリを本番環境へ届けられます。

Bedrockのモデル基盤詳細（Flows・Nova推論・Agents詳細設計・本番評価フレームワークの深掘り）はBedrockシリーズで体系的に解説しています。

Bedrockモデル基盤の深掘り：Bedrock Vol1(Flows/Nova/Evaluations)を読む

6. Data & AI Governance — SageMaker Catalogとアクセス制御・系統管理

6-1. SageMaker Catalog(DataZoneベース)の統合カタログ

SageMaker CatalogはAmazon DataZoneをベース技術として構築された統合データ・AI資産カタログです。DataZoneが提供するドメイン管理・プロジェクト境界・サブスクリプションベースのアクセスフロー・ガバナンスポリシー機能を基盤として採用し、SageMaker Unified Studioの画面に統合したUXとして提供されています。

本§6ではUnified Studio内で統合ガバナンス機能としてSageMaker Catalogをどう使うかに焦点を当てます。DataZoneの基礎概念（ドメイン設計・プロデューサー/コンシューマーの役割分担・サブスクリプション承認フロー・Lake Formation連携の詳細）はData Governance Vol1で体系的に解説していますので、そちらを参照してください。

セマンティック検索による横断的な資産探索

統合カタログの主要機能の一つ目はセマンティック検索です。テーブル名・モデル名を正確に知らない状態でも「顧客の購買履歴データ」「品質スコアが高いテキスト生成モデル」といった自然言語でデータ・AI資産を横断検索できます。SageMaker Catalog上ではS3データセット・Icebergテーブル・MLモデル・Bedrock Agents等の異種資産が一元管理されており、データエンジニア・MLエンジニア・生成AI開発者が同一のカタログから必要な資産を探し出せます。

自動メタデータ収集

LakehouseにS3データセット・Icebergテーブルが追加されると、SageMaker Catalogが自動検出し、スキーマ情報・行数・更新頻度・品質統計を収集してカタログへ登録します。手動でのカタログ更新を不要とし、データカタログの鮮度を継続的に維持できます。MLモデルのメタデータ（学習パラメータ・評価指標・使用データセット）も自動収集対象となり、AI資産の再利用性を高めます。

metadata rules による品質基準の強制(2025年3月 GA)

2025年3月からはmetadata rules機能が追加されています。組織が定めるデータ命名規則（カラム名の接頭辞ルール等）・必須タグ付けポリシー（PII分類タグ・データオーナー指定・有効期限ラベル等）をルールとして定義し、カタログへの資産登録時に自動チェックを行います。規格外の資産登録を拒否または警告することで、カタログ全体の品質基準を統一し、ガバナンス運用の省力化を実現できます。

metadata generation run を CLI から手動トリガーする例を示します。

# メタデータ自動生成ジョブを手動トリガー (DataZone API)
aws datazone create-metadata-generation-run \
  --domain-identifier dzd_xxxxxxxxxx \
  --target '{"identifier":"<asset-identifier>","revision":"1","type":"ASSET"}'

# S3 Access Grants でプレフィックス単位の読み取り権限を付与
aws s3control create-access-grant \
  --account-id 123456789012 \
  --access-grants-location-id <location-id> \
  --grantee '{"GranteeType":"IAM","GranteeIdentifier":"arn:aws:iam::123456789012:role/DataScientistRole"}' \
  --permission READ \
  --access-grants-location-configuration '{"S3SubPrefix":"features/sales/"}'

6-2. アクセス制御・系統追跡・監査と Custom Blueprints

S3 Access Grants 統合ときめ細かなアクセス制御

きめ細かなアクセス制御の基盤となるのはS3 Access Grants統合です。従来のLake FormationによるGlueカタログのテーブル単位のアクセス制御に加え、S3 Access Grantsにより特定のS3プレフィックス・オブジェクトタグへのアクセス権を個人・グループ・アプリケーション単位で付与できます。SageMaker Catalogのサブスクリプション承認フローと連動しており、コンシューマーがカタログ上でデータアクセスを申請すると、承認に応じてS3 Access Grantsの権限が自動発行されます。アクセス権の付与・剥奪がCatalogの承認フロー1本で管理され、IAMポリシーの個別編集作業を大幅に削減できます。

単一権限モデルによるアクセス経路の統一

単一権限モデルとは、データへのアクセスをSageMaker Catalog経由のサブスクリプションフローに統一する設計です。S3バケットへの直接IAMポリシー付与やGlueカタログ個別の権限設定を排除し、Catalog上の承認フローのみを正規のアクセス経路とすることで、誰がどのデータにアクセスできるかの見通しを大幅に改善できます。複数チームが共有するLakehouseデータを安全に管理し、権限の肥大化を防ぐ実践的な設計パターンです。

データ系統（リネージ）追跡

データ系統（リネージ）追跡は、データが収集されてから分析・ML活用に至るまでの変換履歴を自動記録する機能です。Lakehouse上でのETL処理・Glue Visual ETLジョブ・ML学習パイプラインの入出力関係がリネージグラフとして自動構築されます。どの学習データセットがどのモデルに使用されたかを可視化でき、モデルの品質問題が発生した際の原因データの特定・影響範囲の把握を迅速に行えます。規制業種においてはモデルの決定根拠を問われる場面でもリネージデータが証跡として機能します。

監査・コンプライアンス対応

SageMaker Catalog上でのすべてのデータアクセス・資産操作はAmazon CloudTrailに記録されます。誰がどの資産をいつ参照・変更・削除したかのログを保持し、SOC2・GDPR・金融系規制（FINRA等）のコンプライアンス監査において証跡として活用できます。SageMaker Catalogのサブスクリプション申請・承認・権限発行の記録も監査ログに残るため、「誰が承認してデータにアクセスできたか」を完全に追跡できます。

Custom Blueprints によるドメイン専用環境の標準化(2025年9月 GA)

Custom Blueprints（2025年9月GA）はUnified Studioのドメイン専用環境をカスタマイズするためのテンプレート機能です。業界別・部門別のデータポリシー・ガバナンスルール・推奨ツールセット（特定のBedrock FMの固定・必須Guardrailsポリシーの適用・Catalogのmetadata rules設定等）をブループリントとして定義できます。新規プロジェクト作成時にブループリントを選択するだけで、標準化されたガバナンス設定が自動適用されるため、プロジェクト横断での一貫したコンプライアンス体制を省力化して実現できます。組織全体のガバナンス基準を「コードとしての設定」として管理でき、新規チームのオンボーディングを加速します。

DataZone・Lake Formation・Clean Roomsの単体深掘り（サブスクリプションフロー詳細・列レベルセキュリティの設定手順・クリーンルームによる共同分析設計）はData Governance Vol1で体系的に解説しています。

DataZone/Lake Formation単体の深掘り：Data Governance Vol1 を読む

7. 実戦統合パターン — データ→ML→生成AIの一気通貫

SageMaker Unified Studioの最大の価値は、データエンジニア・データサイエンティスト・MLエンジニア・アプリ開発者という4職種が単一プロジェクト内で協調できる点にあります。従来は各ロールが異なるツールセット(Glue/Athena・SageMaker Studio・MLflow・Bedrock)を使い分け、ハンドオフが多発していました。Unified Studioはこの断絶をプロジェクト単位の統合環境で解消します。

7-1. 4職種コラボレーション基盤とエンドツーエンドMLOpsパイプライン

データエンジニアはLakehouseのスキーマ設計・Visual ETLジョブの構築・Zero-ETL統合によるRedshiftデータ連携・Apache Icebergテーブルのパーティション設計と最適化を担当します。SageMaker CatalogへのデータセットPublishと購読承認フロー設定を通じ、データサイエンティストが即座にデータを発見・活用できる環境を整備します。

データサイエンティストはサーバーレスノートブックでLakehouseのIcebergテーブルに直接アクセスし、Amazon Q Developer(data agent)を使った自然言語SQLによる探索的分析をします。特徴量エンジニアリングとモデルプロトタイプの作成、Feature Storeへの特徴量登録とプロジェクト内共有も単一環境で完結します。

MLエンジニアはSageMaker Pipelinesによる本番学習パイプラインの構築と自動化、学習ジョブのスケジューリングとハイパーパラメータ最適化、Model RegistryとCatalogを連携したモデルバージョン管理、モデルデプロイとエンドポイント監視の設定を担当します。

アプリ開発者はBedrock IDEでFMを選択してpoint-and-clickでアプリを構築し、Knowledge BasesにRAGドキュメントを追加してドメイン特化アプリを開発します。GuardrailsでPIIフィルタリングと有害コンテンツ対策を設定し、FlowsでMLモデル推論と生成AIを組み合わせた複数ステップ処理を実装します。

これら4職種は同一プロジェクト内でコードリポジトリ・データ接続・モデル成果物・アクセス権を共有します。IAM Identity Centerとの統合により、プロジェクトへのアサインメントが権限付与を兼ねるため、オンボーディングの手間が大幅に削減されます。

Unified Studioが提供するエンドツーエンドのパイプラインは以下の4ステップで構成されます。Step 1ではLakehouseでS3バケット上のApache IcebergテーブルとRedshiftクラスターを統合し、Visual ETLジョブでデータクレンジングと特徴量を生成します。Step 2ではサーバーレスノートブックでLakehouseのIcebergテーブルに直接クエリを発行し、Amazon Q Developerが自然言語でSQLクエリを生成するためSpark記述量を削減できます。Step 3ではMLflowとSageMaker Pipelinesを組み合わせてCI/CDパイプラインを構築し、学習→評価→モデル登録→承認フローを自動化します。Step 4ではBedrock IDEでFMとStep 3で登録したMLモデルを組み合わせてエンドユーザー向けアプリを構築します。このすべてをUnified Studioの単一プロジェクト内で完結できます。

7-2. 既存資産との共存・段階的移行とAmazon Q Developer連携

従来SageMaker Studioからの移行: SageMaker StudioのKernelGateway/JupyterServer環境はUnified Studio移行後も並行稼働できます。機密プロジェクトや既存パイプラインを維持しながら、新規プロジェクトからUnified Studioに移行するアプローチが現実的です。IdCドメインへの移行はIAMドメインからの変換機能が提供されておらず、新規ドメイン作成が必要です(詳細は§8の詰まりポイント①を参照してください)。

DataZoneからの移行: SageMaker CatalogはDataZoneをベースに構築されているため、DataZoneで構築したデータカタログ・ビジネスデータカタログ・購読フローはUnified Studio統合後もそのまま利用できます。ただしDataZone独自のポータルUIは統合UIに置き換わるため、ユーザー向けのトレーニングが必要です。

個別サービスの持ち込み: 既存のGlue Data Catalog・Athenaワークグループ・Redshiftクラスターはプロジェクト接続として追加できます。Visual ETLジョブは既存のGlue ETLスクリプトを取り込めるため、既存のデータ処理ロジックを書き直す必要はありません。Amazon Q Developer(NL SQL/ETL自動生成)を活用するとGlueスクリプトのメンテナンスコストをさらに削減できます。

Amazon Q Developer統合: Unified Studio内で利用可能なAmazon Q Developerのdata agentは、自然言語でのSQL生成・ETLコード自動生成・クエリ最適化提案・データ探索ガイダンスを提供します。「先週の売上上位10商品を教えて」といった自然言語入力から適切なSQLを生成してLakehouseのIcebergテーブルへクエリを実行し、結果をノートブック内で可視化するまでを半自動化できます。データエンジニア不在のチームでもデータ活用の加速が期待できます。

チーム導入パターン: 本番環境への段階的導入には3フェーズが有効です。Phase 1(1〜2ヶ月)では1チーム・1プロジェクトのパイロットとしてIdCドメインを新規作成し、サーバーレスノートブックとLakehouse接続の動作を検証します。Phase 2(3〜4ヶ月)ではVisual ETL/Zero-ETLでLakehouseを本格稼働させ、SageMaker PipelinesとModel RegistryとCatalogを連携します。Phase 3(5ヶ月以降)ではBedrock IDEをプロジェクトに追加し、ML資産をBedrock Agentのツールとして統合して全社横断のデータ・AI資産カタログを一元化します。

マルチクラウド・ハイブリッド対応(2025年時点): 2025年時点のUnified StudioはプライマリにはフルマネージドのAWSサービスとして提供されており、他クラウドとのネイティブ連携は限定的です。Glue ETLジョブ経由でオンプレミスのJDBCデータソースをLakehouseに取り込むハイブリッド連携パターンが現実解です。SageMaker Catalogのフェデレーテッドカタログ機能により、外部データソースをUnified Studioカタログに統合できます。GCP/Azure上のデータはAWS Transfer Family・Kinesis Data Streams・AppFlow経由でS3に取り込んでLakehouseで処理するアーキテクチャが一般的です。

7-3. ユースケース実装 — 業界別一気通貫パターン

Unified Studio の真価は「データ→ML→生成AI」を単一プロジェクト内でつなぎ、複数職種が同一ツールセット上でコラボレーションできる点です。以下に代表的な業界パターンとコード例を示します。

一気通貫アーキテクチャの全体像

[S3 / Redshift]
↓ Lakehouse (Iceberg)
[Visual ETL / Zero-ETL]
↓ 特徴量テーブル (SageMaker Catalog へ自動登録)
[SageMaker Training ジョブ]
↓ Model Registry (Approval フロー)
[Bedrock IDE]
↓ Knowledge Base + FM + Guardrails
[エンドユーザー向けアプリ / API]

データエンジニアが Lakehouse でデータを整備し、ML エンジニアが学習ジョブを実行し、アプリ開発者が Bedrock IDE でアプリ化するまでの流れが、すべて同一プロジェクト内で完結します。IAM Identity Center による単一権限モデルのもと、各職種が必要なデータ・モデル・AI 資産へアクセスできます。

ユースケース 1: 小売業の需要予測 AI

小売業では、過去の販売データをもとに商品需要を予測し、生成 AI が顧客へのレコメンド文を生成するアーキテクチャが典型的です。

Step 1: Lakehouse への特徴量テーブル作成。サーバーレスノートブックで S3 の販売ログを Iceberg テーブルとして整形します。

import awswrangler as wr
import pandas as pd

df_sales = wr.s3.read_parquet("s3://retail-data-lake/raw/sales/2025/")
df_inv= wr.s3.read_parquet("s3://retail-data-lake/raw/inventory/2025/")

df_feat = df_sales.merge(df_inv, on="product_id", how="left")
df_feat["stock_ratio"] = df_feat["current_stock"] / df_feat["avg_weekly_demand"]
df_feat["days_since_last_sale"] = (
 pd.Timestamp.now() - df_feat["last_sale_date"]
).dt.days

wr.athena.to_iceberg(
 df=df_feat,
 database="retail_lakehouse",
 table="demand_features",
 temp_path="s3://retail-data-lake/tmp/",
 schema_evolution=True
)
print(f"特徴量テーブルに {len(df_feat)} 行を書き込みました")

Step 2: SageMaker Training ジョブで需要予測モデルを学習します。Spot Training を使うことで最大 90% のコストを削減できます。

import sagemaker
from sagemaker.estimator import Estimator

session = sagemaker.Session()
estimator = Estimator(
 image_uri=sagemaker.image_uris.retrieve("xgboost", session.boto_region_name, "1.7-1"),
 instance_type="ml.m5.2xlarge",
 instance_count=1,
 role=sagemaker.get_execution_role(),
 use_spot_instances=True,
 max_wait=7200,
 hyperparameters={
  "num_round": 200, "max_depth": 6,
  "eta": 0.05, "objective": "reg:squarederror"
 }
)
estimator.fit({"train": "s3://retail-data-lake/features/demand/train/"})
print(f"学習完了: {estimator.model_data}")

Step 3: Bedrock IDE で需要予測結果をもとにレコメンド文を生成します。Bedrock Flows を使い、ML モデルの推論結果を Lambda 経由で受け取り、FM が顧客向けのレコメンド文を生成して返す処理パイプラインを構築します。顧客の購買履歴と在庫状況をコンテキストとして FM へ渡すことで、パーソナライズされたレコメンドが生成されます。Guardrails で PII フィルタリングと不適切コンテンツのフィルタリングを適用し、本番品質の出力を保証します。

推論レスポンスタイムを SLA 以内(例: 3 秒以内)に収めるため、予測モデルは Real-time Inference Endpoint としてデプロイし、Bedrock 側は同一リージョンの On-Demand モデルを使用します。エラー時のフォールバックとして Guardrails に「レコメンド生成失敗時はデフォルト文を返す」ルールを設定しておくと安全です。

ユースケース 2: 金融の不正検知 + Bedrock IDE アラート

金融業では、リアルタイムのトランザクションデータから不正を検知し、審査担当者への説明文を生成 AI が作成するパターンが有効です。

Step 1: Zero-ETL で DynamoDB のリアルタイムデータを Redshift へ統合します。

# DynamoDB テーブル → Redshift Serverless への Zero-ETL 統合
aws redshift create-zero-etl-integration \
  --source-arn arn:aws:dynamodb:ap-northeast-1:123456789012:table/tx_events \
  --target-arn arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/fraud-ns \
  --integration-name "dynamo-to-redshift-fraud"

Step 2: 不正検知モデルを SageMaker Async Inference で大量バッチ推論します。

import boto3

sm_rt = boto3.client("sagemaker-runtime", region_name="ap-northeast-1")

response = sm_rt.invoke_endpoint_async(
 EndpointName="fraud-detection-endpoint",
 InputLocation="s3://fraud-data/batch/tx_2025_06_05.jsonl",
 ContentType="application/json"
)
print(f"推論結果の格納先: {response['OutputLocation']}")

Step 3: Bedrock IDE で不正フラグ付きトランザクションの説明文を生成します。不正スコアが閾値を超えたトランザクションについて、Bedrock Agents が SageMaker Endpoint と Redshift へ問い合わせ、審査担当者向けの説明文を自動生成します。「このトランザクションは過去の不正パターンと類似度 87% です。主な根拠は取引場所の急変(前回から 500 km 超)と 1 日の取引回数が平均の 5 倍」のような説明文が自動生成されます。Guardrails のグラウンディングチェックにより、証拠のない推測が出力されることを防ぎます。

既存 SageMaker ジョブの段階的移行パターン

既存の SageMaker Studio 環境を Unified Studio へ移行する際は、以下の 3 フェーズが安全です。

フェーズ 1(1〜2 ヶ月): 既存 IAM ドメインを並行稼働させながら、新規 IdC ドメインで Unified Studio を試験稼働します。既存の学習ジョブや推論 Endpoint はそのまま動作し続けます。新規プロジェクトのみ Unified Studio で開始し、サーバーレスノートブックの使い勝手を検証します。既存の Glue ETL スクリプトをプロジェクトへの「持ち込み」として接続し、Visual ETL との使い分けを評価します。

フェーズ 2(3〜4 ヶ月): Lakehouse を本格稼働させ、Unified Studio のサービスロールに既存 EMR クラスターや Redshift クラスターへのアクセス権を追加します。Model Registry を Unified Studio から参照できる状態にし、Catalog のメタデータ収集を有効化して既存データカタログのエントリが検索できることを確認します。SageMaker Pipelines の MetadataProperties を設定してリネージを有効化します。

フェーズ 3(5 ヶ月以降): Bedrock IDE をプロジェクトへ追加し、既存の ML モデルを Bedrock Agent のカスタムツールとして統合します。全チームを IdC ドメインへ移行し、個別コンソール管理を Unified Studio に集約します。旧 IAM ドメインの廃止を完了します。Custom Blueprints で標準化したプロジェクト設定をテンプレート化し、新規チームのオンボーディングを省力化します。

落とし穴と設計のコツ

一気通貫パイプラインを設計する際に特に注意すべき点を示します。

• 権限伝播の遅延: IAM Identity Center のグループ変更が Unified Studio へ反映されるまで数分かかることがあります。ロール変更後すぐに動作確認する場合はセッションをリフレッシュしてください。
• Lakehouse と Bedrock IDE のデータ共有: Bedrock IDE の Knowledge Base ソースに Lakehouse の S3 パスを指定する場合、Bedrock のサービスロールに当該バケットへの s3:GetObject と s3:ListBucket を明示的に許可してください。プロジェクトサービスロールとは別の権限設定が必要です。
• FM 呼び出しのコスト管理: Bedrock FM の呼び出しは都度課金です。開発段階では Guardrails の「最大トークン数制限」を設定し、テスト時のコスト急増を防いでください。
• セッション間のデータ共有: サーバーレスノートブックはセッション終了時にメモリが解放されます。セッション間でデータを渡す場合は Lakehouse テーブルまたは S3 を経由し、インメモリのみへの依存を排除したパイプライン設計を徹底してください。

8. 詰まりポイントとアンチパターン — 本番導入で直面する問題と解決策

本番導入で実際に直面しやすい詰まりポイントとアンチパターンを解説します。事前に把握しておくことで、試行錯誤による無駄なコストと時間を削減できます。

8-1. 詰まりポイント7選

詰まり① IdCドメイン移行の罠 — IAMドメインからの変換不可

問題: 従来のSageMaker StudioはIAMドメインとして動作していますが、Unified Studioの一部機能(サーバーレスノートブック・data agent)はIdCドメインでのみ利用可能です。「IAMドメインをIdCに変換できる」と誤解して移行を試みるケースがあります。

原因: Unified StudioのIAMドメインからIdCドメインへのインプレース変換機能は2025年時点で提供されていません。ドメインのアイデンティティプロバイダーは作成時にのみ設定可能です。

解決手順:

1. 新規のIdCドメインをAWSコンソールまたはInfrastructure as Codeで作成する
2. IAM Identity CenterにプロジェクトユーザーをSSOユーザーとして登録する
3. 旧IAMドメインのプロジェクト設定(ブループリント・接続情報)をドキュメント化して引き継ぐ
4. 旧IAMドメインを並行稼働させながら、プロジェクト単位で新IdCドメインへ段階移行する
5. 全プロジェクト移行完了後に旧ドメインを削除する

移行期間中は旧SageMaker Studioと新Unified Studioが並行稼働するため、コストが一時的に増加します。移行完了タイムラインとコスト見積もりをステークホルダーへ事前に説明しておくことを推奨します。

詰まり② Catalogのメタデータ収集タイミングと自動取得設定

問題: Lakehouseへ新しいIcebergテーブルを追加しても、SageMaker Catalogにすぐ表示されないケースがあります。「Catalogが壊れた」と誤解してサポートケースを開くことが散見されます。

原因: CatalogはGlue Data Catalog/DataZoneのメタデータ収集スケジュールに依存しており、デフォルトでは非同期で収集されます。テーブル作成直後は収集遅延が発生します。

解決手順:

1. DataZoneのデータソース設定で「自動メタデータ収集を有効化」をオンにする
2. 収集スケジュールを「1時間ごと」から「15分ごと」に変更する
3. 緊急の場合はDataZoneコンソールから「今すぐ実行」でメタデータ収集をトリガーする
4. Catalogに表示されたら購読(Subscribe)フローを通じてプロジェクトメンバーにアクセスを付与する
5. 購読承認が必要なデータセットは承認ワークフローを設定して自動化する

新テーブルの利用開始予定が決まっている場合は、ETLジョブ完了後すぐに「今すぐ実行」をトリガーするCIパイプラインステップを組み込むと、収集待ち時間を実質ゼロにできます。

詰まり③ Bedrock IDEでFMを切り替える方法がわからない

問題: Bedrock IDEでプロジェクトを作成後、使用するFMを別のモデルに変更したいが変更方法がわからない、または「使いたいモデルが選択肢に出ない」というケースです。

原因: Bedrock IDEで利用可能なFMは、対象リージョンでの「モデルアクセス」が有効化されている必要があります。また、デフォルトモデルはアプリケーション単位で後から変更できます。

解決手順:

1. AWSコンソール → Amazon Bedrock → 「モデルアクセス」で使用したいFMのアクセスをリクエストする
2. 承認後、Bedrock IDEのアプリ設定でモデルを変更する
3. 「Foundation モデル」セクションで既存モデルを削除し、新しいモデルを追加する
4. テスト環境でレスポンス品質を検証してから本番に反映する
5. コスト最適化のため、探索フェーズには軽量モデル、本番環境には高性能モデルを用途別に使い分ける

Cross-Regionリファレンスモデルを使用する場合は、レイテンシーとスループットが通常リージョンより変動しやすい点を考慮してタイムアウト設定を調整してください。

詰まり④ LakehouseでRedshiftデータにアクセスできない

問題: RedshiftのデータをLakehouseに追加したにもかかわらず、ノートブックからSQLでアクセスすると権限エラーやテーブルの未検出エラーが発生します。

原因: Lakehouseを通じたRedshiftアクセスにはいくつかの前提条件があります。RedshiftクラスターとLakehouseのIAMロールが適切に信頼関係を結んでいる必要があり、接続設定(クラスターエンドポイント・VPCセキュリティグループ)が正しく構成されていない場合にもエラーが発生します。Zero-ETL統合を使用する場合はRedshift Serverlessとの構成要件が通常接続と異なります。

解決手順:

1. Lakehouse接続設定でRedshiftの「接続のテスト」を実行し、接続確立を確認する
2. RedshiftのIAMロールにLake Formationへのアクセス権限を追加する
3. Unified StudioのプロジェクトロールにRedshiftのデータアクセス権限を付与する
4. VPCエンドポイントが設定されている場合は、セキュリティグループのインバウンドルール(Redshiftデフォルトポート)を確認する
5. Zero-ETL統合を使用する場合は、Redshift ServerlessのNamespaceとWorkgroupがUnified Studioと同一リージョンにあることを確認する

Lake Formationのデータレイク設定で「サービスにリンクされたロール」が正しく設定されていない場合にも同様のエラーが発生します。Lake Formationコンソールで「管理者の設定」を確認してください。

詰まり⑤ Custom Blueprintsの権限設定エラー

問題: 2025年9月にGAしたCustom Blueprintsを使ってプロジェクトテンプレートを作成したが、他のプロジェクトメンバーがブループリントを使用しようとすると権限不足エラーが発生します。

原因: Custom Blueprintsには「作成者(Publisher)」と「使用者(Member)」という2つのレベルの権限があります。ブループリントをPublishしただけでは他のプロジェクトメンバーは使用できず、明示的に使用権限を付与する必要があります。

解決手順:

1. IAM Identity Centerのコンソールで対象グループに適切なカスタムポリシーを追加する
2. Unified Studioのドメイン設定 → 「ブループリント」で対象ブループリントの「アクセス管理」を開く
3. 使用を許可するIAM Identity Centerグループを追加する
4. ブループリントのステータスが「Enabled」になっていることを確認する
5. プロジェクト作成フローでブループリントが選択肢に表示されることを確認する

ブループリントの管理者とプロジェクトメンバーをIdCの異なるグループで管理することを推奨します。管理者グループには「Publisher」権限、一般メンバーグループには「Member」権限を付与する設計が運用上明快です。

詰まり⑥ サーバーレスノートブックのコールドスタート

問題: Unified Studioのサーバーレスノートブックは、アイドル後の再起動に数分かかることがあります。頻繁なインタラクションが必要な探索的分析では体験が悪化します。

原因: サーバーレスアーキテクチャの特性上、一定時間アイドル状態になるとコンピューティングリソースが解放されます。再アクセス時にはコンテナの起動・依存関係のインストールが必要になるため、コールドスタートが発生します。

解決手順:

1. カスタムLifecycle設定を作成し、よく使うPythonライブラリをプリインストールしたカスタムイメージを登録する
2. 長時間処理はSageMaker Trainingジョブに移行し、ノートブックをインタラクティブな試行錯誤専用に使い分ける
3. コスト重視の場合はアイドルタイムアウトを短くし(デフォルト120分→30分)、コールドスタートを許容する運用設計を採用する
4. 頻繁にアクセスするチームには専用コンピュートオプション(非サーバーレス)の利用を検討する
5. よく使うライブラリをカスタムイメージに焼き込んでおくことでコールドスタート時間を大幅に短縮できる

大規模チームで複数ユーザーが同時アクセスする場合は、コールドスタートが同時多発するリスクを考慮し、キャパシティを設計してください。

詰まり⑦ データ系統/リネージが途切れる原因と修復

問題: SageMaker Catalogのリネージビューで、データの変換フロー(S3 → Glue ETL → Iceberg → ML学習)が途中で途切れて表示されます。一部のジョブが系統グラフに現れません。

原因: リネージ追跡はGlue ETLジョブの「リネージ有効化」設定とSageMaker Pipelinesのメタデータエミット設定が有効になっている場合のみ機能します。既存のGlueジョブをUnified Studio移行後も修正せずに使い続けると、リネージが途切れます。また、PySpark直接記述のカスタムスクリプトではリネージが自動取得されません。

解決手順:

1. GlueコンソールでETLジョブの「ジョブの詳細」→「リネージを有効にする」をオンにして再実行する
2. SageMaker Pipelinesのパイプライン定義にMetadataPropertiesを追加して入出力アーティファクトを明示する
3. カスタムPySparkスクリプトを使用している場合は、GlueのOpenLineage互換ライブラリを組み込む
4. 修正後にCatalogのデータソース収集を再実行し、リネージが接続されていることを確認する
5. 以降は新規ジョブ作成時にリネージ設定を必須チェック項目に追加して横展開する

系統/リネージの可視化はデータ品質問題の根本原因特定とコンプライアンス対応に直結します。初期構築時にリネージ設定を標準化しておくと、後から遡及修正する手間を大幅に削減できます。

8-2. アンチパターン → 正解変換5選

アンチパターン① SageMaker Studioの「延長線」として使う

アンチパターン: SageMaker Unified Studioを「新しいデザインのSageMaker Studio」として位置づけ、個人ノートブック中心の使い方を継続する。プロジェクト機能を使わず、各自がドメイン直下でリソースを作成する。

正解: Unified Studioの核心はプロジェクト中心設計です。データ接続・コードリポジトリ・モデル成果物はすべてプロジェクトに紐づけ、チーム全員が同一プロジェクトで協調することで、Catalogによる資産の可視化と権限の自動管理が機能します。個人スタジオとしての使い方ではUnified Studioの価値の大部分を活かせません。まずチームの代表的なMLプロジェクトでプロジェクト中心設計を試験導入し、効果を確認してから全社展開することを推奨します。

アンチパターン② SageMaker Catalog = DataZoneなので既存DataZone実装をそのまま流用する

アンチパターン: DataZoneで構築したカスタムポータルやAPI連携スクリプトを「SageMaker CatalogはDataZoneベースだから同じはず」としてそのまま移植する。Catalogのドメインエンドポイントが異なることを見落とす。

正解: SageMaker CatalogはDataZoneをベースにしていますが、APIエンドポイント・ポータルUI・権限モデルがUnified Studio統合用に変更されています。DataZone APIの一部はそのまま使用できますが、ポータル関連のAPIや管理操作はUnified Studio管理コンソール経由に移行する必要があります。まず機能差分を公式ドキュメントで確認してから実装の移行計画を立ててください。移行前にサンドボックス環境で動作検証を行うことを強く推奨します。

アンチパターン③ 全サービスを一気にUnified Studioへ移行するビッグバンアプローチ

アンチパターン: 「Unified Studio一元化」を目標に、全チームの全プロジェクトを同時にUnified Studioへ移行するビッグバンアプローチを採る。既存の学習パイプラインやDataZoneポータルを同時停止する。

正解: 段階的移行が定石です。まず新規プロジェクトをUnified Studioで立ち上げ、既存プロジェクトは並行稼働させます。ML開発→Lakehouse統合→Bedrock IDE統合の順で機能を段階的に追加し、各ステップで安定性を確認してから次に進みます。ビッグバンは万が一の障害時に影響範囲が全社に及ぶリスクがあります。既存ワークロードを守りながら新環境を段階的に育てるアプローチが長期的に安全です。

アンチパターン④ 各サービスを引き続き個別コンソールで管理する

アンチパターン: 「Unified Studioは画面が変わっただけ」として、Glue・SageMaker・Bedrockをそれぞれ専用コンソールで引き続き操作する。Unified Studioへの接続のみ行い、実際の管理を個別コンソールで続ける。

正解: Unified Studioのプロジェクトを通じて管理することで、Catalogによる資産の横断検索・系統追跡・権限の一元管理が機能します。データアクセス権の付与はプロジェクトメンバーへのアサインメント経由で行うことで、Lake FormationとIdentity Centerの権限が自動連動します。個別コンソール管理を続けると権限の整合性が保てなくなり、セキュリティインシデントのリスクが高まります。

アンチパターン⑤ プレビュー機能を本番環境でそのまま使う

アンチパターン: Unified Studioのリリースノートに記載されたプレビュー機能を「便利そうだから」と本番ワークロードに組み込む。SLAが保証されない段階で業務の中核処理に採用する。

正解: AWSのGA/プレビュー/パブリックベータの区別を必ず確認してから採用可否を判断してください。Unified Studioでは機能単位でGAが異なります(サーバーレスノートブック・Bedrock IDE・Custom Blueprintsはそれぞれ異なるタイミングでGAしています)。本番導入前にAWSの公式What’s Newページで「Generally Available」表記を確認し、SLAと利用規約を検証した上で採用してください。プレビュー機能はフィードバックを提供しながら試用する位置づけとし、本番への適用は慎重に判断することを推奨します。

8-3. まとめ — Unified Studioが実現する「データとAIの一体運用」

SageMaker Unified Studioは2025年3月のGAから急速に機能を拡充し、データエンジニア・データサイエンティスト・MLエンジニア・アプリ開発者という4職種が単一スタジオで協調できる環境を実現しました。従来のデータサイロ・ツールサイロを解消し、Lakehouseのデータ統合から生成AIアプリのデプロイまでをエンドツーエンドで管理できる点が最大の価値です。

本記事(Vol1)では以下のテーマを解説しました。

• IAM Identity Center連携によるドメイン/プロジェクト構成と権限管理
• SageMaker LakehouseによるS3/Redshiftの統合データ基盤構築
• サーバーレスノートブックとAmazon Q Developerを活用したML開発フロー
• Bedrock IDEによる生成AIアプリのpoint-and-click開発
• SageMaker Catalogによるデータ・AI資産の統合ガバナンス
• 4職種協調のエンドツーエンドMLOpsパイプラインと段階導入パターン
• 7つの詰まりポイントと5つのアンチパターンから学ぶ本番導入のノウハウ

2025年以降のロードマップ

AWSはUnified Studioのロードマップを以下の方向性で拡張する方針を示しています。

Amazon Q Developer data agentの強化により、自然言語でのデータ探索・ETL生成・クエリ最適化の精度が向上する見込みです。データエンジニア不在のチームでもデータ活用が加速します。クロスアカウント協調の強化により、複数AWSアカウントにまたがるプロジェクトのデータ共有とガバナンスがより統合的に管理できるようになります。Bedrock IDE × SageMaker MLのさらなる統合により、MLモデルをBedrock Agentのカスタムツールとしてシームレスに登録・利用できるワークフローが強化されます。プロジェクト単位のAWSサービスコストを統合したコスト可視化ダッシュボードも提供される予定であり、FinOps対応が容易になります。

SageMaker Unified Studioへの移行は「ツールの乗り換え」ではなく「データとAI開発の組織設計を見直す機会」です。段階的な導入とプロジェクト中心の組織設計により、開発速度とデータガバナンスを同時に高める本番運用体制を構築してください。

本番運用チェックリスト

Unified Studioを本番環境へ展開する前に以下の項目を確認してください。

このチェックリストは展開のたびに見直し、組織の運用基準に合わせて項目を追加・更新してください。

関連：Data Governance Vol1(DataZone×Lake Formation)を読む

関連：ML/AI Vol3(SageMaker MLOps パイプライン・Feature Store)を読む

関連：Bedrock本番運用Vol3(Guardrails高度化・Prompt management・Nova生成)を読む