ひとことで言うと
次世代 Amazon SageMaker の一部で、AWS のデータ・分析・AI・ML を1つのブラウザ画面にまとめた開発環境です。単一のインターフェースからワークフローを構築・デプロイ・実行・監視でき、Amazon Bedrock のツール群（エージェント・ガードレール・プロンプト・フロー・評価・関数）もこの中から扱えます。
要するに、部署ごとにバラバラだった作業場を、入退室記録の付く1棟のビルに移した、というサービスです。個々の道具（Athena・EMR・Glue・Redshift・Bedrock・SageMaker AI）は元のまま。変わったのは誰がどの部屋に入れるか（ドメイン・プロジェクト・プロジェクトプロファイル）と、成果物をどこに置いて共有するか（SageMaker Catalog）です。機能の追加ではなく境界の設計が本体です。
なぜ生まれたか
生成AIのアプリは、**データ基盤・SQL分析・ML・FM 利用の4つを同時に触ります。**ところが従来はそれぞれ別コンソール・別権限・別の成果物置き場で、「誰がどのデータで何を作ったか」が横断で追えませんでした。Unified Studio は、道具を新しくするのではなく、ドメインとプロジェクトという境界を先に引き、その中に既存サービスを呼び込む構造にしています。
| 概念 | 何を決めるもの |
|---|---|
| ドメイン | 資産・ユーザー・プロジェクトを結びつける最上位の器。企業で1つでも、事業部ごとに複数でもよい |
| ドメインユニット | ドメイン内で事業部・チーム単位に資産と権限を分ける区画。アカウント所有者から権限を委譲する |
| プロジェクト | 共同作業の境界。コード・ノートブック・クエリ・ダッシュボード・ワークフローの入れ物であり、業務文脈・共同作業・権限の3つの境界を兼ねる |
| プロジェクトプロファイル | プロジェクトのテンプレート。ブループリントの集合で、プロジェクト内で使える道具はこれで決まる |
| ブループリント | 個々の AWS ツール・サービスをプロジェクトに持ち込むための構成単位 |
| SageMaker Catalog | 各プロジェクトから公開された資産のカタログ。スコープはドメインで、アカウントとリージョンの境界を越えて検索できる |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| 生成AIアプリの開発 | Generative AI application development プロファイルで、Bedrock のチャットエージェント・ナレッジベース・ガードレール・関数・フロー・プロンプト・評価を使う | D2 |
| FM の試し打ち | 生成AIプレイグラウンド（チャット用と、画像・動画用の2種類）でモデルの応答を比較する | D1 |
| データの発見と統制 | SageMaker Catalog に資産を公開し、他プロジェクトはサブスクリプション申請→承認で使う | D1 |
| レイクとウェアハウスの横断 | lakehouse アーキテクチャで S3 データレイクと Redshift を Apache Iceberg ベースの共有メタデータカタログで束ねる | D1 |
| SQL 分析 | Querybook（Athena / Redshift をエンジンに、SQL と Markdown のセルを持つノートブック） | D1 |
| ML 開発 | JupyterLab の IDE（SageMaker Distribution イメージ、スペース単位でインスタンスと EBS を持つ） | D2 |
| ETL の作成 | Visual ETL で画面から定義すると、Apache Spark 向けの Python コードが自動生成される | D1 |
| コーディング補助 | Amazon Q Developer（現行リリースでは既定で全ユーザーが Free Tier を利用可能） | D2 |
| 版管理 | プロジェクト専用の Git リポジトリ（既定は CodeCommit、GitHub / GitHub Enterprise Server / GitLab / BitBucket に差し替え可） | D2 |
試験でどう問われるか
**主役では出ません。**ただし **「複数チームが同じデータと FM を、統制の効いた形で共有する」**というシナリオでは、Unified Studio が答えになります。逆に、Bedrock の機能制約が引っかけの材料として使いやすい構造をしているので、そこは覚える価値があります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| チーム横断の開発環境 | データエンジニア・アナリスト・ML・生成AI開発者が同じ場所で協働し、成果物をカタログで共有したい → Unified Studio | 各自が個別のコンソールと IAM ロールで作業する案 |
| 使える道具の限定 | プロジェクトで何を使えるかを管理者が決めたい → プロジェクトプロファイル（ブループリントの集合）で制御する | IAM ポリシーだけで個別に絞る案／プロジェクトメンバーの権限で調整する案 |
| Bedrock の機能制約 | プロビジョンドスループット・カスタムモデル・インポートモデルは非対応。対応するのはオンデマンドスループットとオンデマンドのクロスリージョン推論のみ | 「Unified Studio 上でプロビジョンドスループットを購入して安定化する」 |
| 分離の強さ | 厳密な分離が要るならプロジェクトを別アカウントに置く | 「プロジェクトを分ければセキュリティ的に分離される」（公式が「プロジェクトは強いセキュリティ分離を提供しない」と明記） |
| データ共有の作法 | 他プロジェクトのデータを使う → カタログへの公開と、サブスクリプション申請の承認 | プロジェクト間で S3 バケットを直接共有する案 |
| ドメインの種類 | 管理コンソールで作れるドメインは2種類あり、Amazon DataZone ドメインと SageMaker unified ドメインは手引きが別 | 「どちらのドメインでも Unified Studio の手順は同じ」 |
| 認証 | IAM / IAM Identity Center / SAML | 「専用のユーザーディレクトリを新設する」 |
管理コンソールの URL が console.aws.amazon.com/datazone です。ドメイン・プロジェクトプロファイル・ブループリント・アカウント関連付け・サブスクリプション申請という語彙も含め、Amazon DataZone の系譜がそのまま入っています。DataZone の概念を知っていると読み替えるだけで済み、知らないと「なぜ ML の話で資産の公開申請が出てくるのか」で詰まります。
実務でどう使うか
- プロジェクトプロファイルは、ドメインを所有する AWS アカウントの管理者しか作れません。 関連付けアカウント側のユーザーが同じ手順を踏んでも、生成AIブループリントが有効になるだけでプロファイルは作られません。作業を始める前にどのアカウントで誰がやるかを決めておかないと空振りします
- 生成AIのプロファイルは7つのブループリントの束です。
AmazonBedrockChatAgent/KnowledgeBase/Guardrail/Function/Flow/Prompt/Evaluationが、親のAmazonBedrockGenerativeAIにまとまっています。テンプレートからプロファイルを作った場合は Tooling ブループリントの機能しか入らないため、後からAmazonBedrockGenerativeAIを構成する必要があります - ブループリントはリージョン単位で有効化します。 ドメインと別リージョンでプロジェクトプロファイルを有効にする場合、そのリージョン側でも同じブループリントを有効化しないと動きません（Tooling ブループリントを含む）
- ネットワーク要件が固めです。 VPC を選び、必要な VPC エンドポイントを含むサブネットを、異なるアベイラビリティゾーンから3つ以上指定します。パブリックサブネットでは一部機能が使えないため、プライベートサブネットが推奨です
- 暗号化はドメイン作成後に変更できません。 既定は AWS 所有キーで、独自の KMS キーを使うならドメインを作る時点で決めます
- モデルへのアクセスは2つのロールで分かれます。 プロビジョニングロール（プロジェクト内で使う推論プロファイルを作る側）と、コンシューモンロール（プレイグラウンドでユーザーがモデルを触る側）。Bedrock 側でモデルアクセスが有効になっていないと、そもそも一覧に出てきません
- スペースは個人の作業場です。 コンピュートインスタンス・EBS ボリューム・JupyterLab アプリの組で、作成時にプロジェクトの Git リポジトリがクローンされます。プロジェクトの共有物と、個人のサンドボックスは別物として扱います
「作れば使える」までの距離が長いサービスです。ドメイン作成 → ブループリント有効化（リージョンごと）→ プロジェクトプロファイル作成 → Bedrock 側でのモデルアクセス許可 → プロビジョニング／コンシューモンロールの設定 → プロジェクト作成、まで通してようやくユーザーが触れます。PoC の見積りで「環境を用意する」を1行で書くと、その1行に数日入ります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon SageMaker AI | SageMaker AI はモデルを作って動かすサービス。Unified Studio はそれを含む複数サービスの入口と境界。Unified Studio の中で SageMaker AI を使う関係 |
| Amazon Bedrock（単体） | Bedrock は API とマネジメントコンソールで直接使える。Unified Studio はプロジェクト単位の統制と協働を被せた入口で、代わりにプロビジョンド・カスタム・インポートモデルが使えない |
| SageMaker Studio（Classic を含む） | Studio は SageMaker AI の ML 向け IDE。Unified Studio はデータ分析・SQL・生成AIまで含む上位の統合環境 |
| Amazon DataZone | 語彙と管理コンソールは共通の系譜。管理コンソールでは DataZone ドメインと SageMaker unified ドメインの2種類が作れ、前者に割り当てられた場合は DataZone のガイドを読む |
| AWS Glue Data Catalog | Glue のカタログはテーブルの技術メタデータ。SageMaker Catalog はプロジェクトが公開した資産の発見と購読。Glue と Redshift は SageMaker Catalog のデータソースとして取り込む側 |
| Amazon Q Developer | Unified Studio に同梱されるコーディング支援であって、Unified Studio そのものではない |
想起チェック
Q1. Unified Studio のプロジェクトで使える道具を管理者が決めるとき、触るのはどれですか。
プロジェクトプロファイルです。ブループリントの集合であるプロファイルがプロジェクトのテンプレートになり、プロジェクト内で利用できるツールを規定します。IAM ポリシーで個別に絞る話ではありません。
Q2. 「Unified Studio 上で Bedrock のプロビジョンドスループットを使って応答を安定させたい」。成立しますか。
成立しません。 Unified Studio 内の Amazon Bedrock が対応するのはオンデマンドスループットとオンデマンドのクロスリージョン推論だけで、プロビジョンドスループット・カスタムモデル・インポートモデルは非対応です。
Q3. 「機密度の高いワークロードを他チームから確実に分離したい」。プロジェクトを分ければ足りますか。
足りません。 公式に「プロジェクトは強いセキュリティ分離を提供しない」と明記されています。ドメイン間・プロジェクト間のリソース発見を制限するなら、別アカウントにプロジェクトを作ることを検討します。
Q4. 他プロジェクトが公開したデータを自分のプロジェクトで使うまでの流れは？
SageMaker Catalog で見つけ、サブスクリプション申請を出し、所有プロジェクト（プロデューサー）の承認を得る流れです。承認されると所有側が必要な権限を付与します。