[アップデート] Amazon SageMaker Unified Studio の IAM ベースドメインでカスタムアセットタイプが利用可能になったので、Amazon Quick ダッシュボードをカタログ登録してみた

Amazon SageMaker Unified Studio のカスタムアセットタイプ機能が IAM ベースドメインで利用可能になったので、Amazon QuickSight ダッシュボードをカタログ化して、実際のワークフローを試してみました。
石川覚
2026.07.17
クラウド事業本部の石川です。Amazon SageMaker Unified Studio（以下 SMUS）のカタログに、任意フォーマットのアセットを登録できる「カスタムアセットタイプ」が IAM ベースドメインでも利用可能になりましたので、Amazon Quick ダッシュボードをカタログ登録を実際に試してみました。
https://aws.amazon.com/jp/about-aws/whats-new/2026/07/smus-custom-asset-types-iam/
SMUSは、データ・分析・AI/ML の作業を 1 つのポータルに統合したサービスです。その中核となるカタログは Amazon DataZone をベースにしており、テーブルやBIダッシュボード、ML モデルといった「アセット」をガバナンスの効いたワークフローで発見・購読できます。
今回のアップデートでは、IAM ベースドメインのカタログに「カスタムアセットタイプ」が追加されました。これにより、ドメイン管理者は SMUS がネイティブに対応していない任意フォーマットのアセット（Amazon S3 上の医療画像ファイル、PowerBI で作成された収益ダッシュボード、サードパーティ製プラットフォームが生成した PDF レポートなど）もカタログに登録し、他のカタログアセットと同じメタデータ管理・発見・購読フローに載せられるようになります。
https://docs.aws.amazon.com/sagemaker-unified-studio/latest/userguide/catalog-iam-custom-asset-types.html
 カスタムアセットタイプとはアセットタイプは、特定種類のアセットが「カタログ上でどう表現されるか」を定義するスキーマです。1 つ以上のメタデータフォームタイプ（必須・任意）を持ち、バージョン管理されます。アセットを作成する際にはアセットタイプのスキーマに対して検証が行われ、不正な構造の場合は作成が失敗します。
カスタムアセットタイプは、このアセットタイプをドメイン管理者が自由に定義できるようにするものです。公式ドキュメントによると、想定ユースケースは次のとおりです。
SMUS がネイティブ対応していない独自フォーマットのカタログ化（社内レポートシステム、独自ファイル形式、サードパーティのエクスポートなど）
フォーマットを問わず、組織内の全アセットを統一的に発見できる体験の提供
フルフィルメント（実データ提供）が SMUS の外部で管理されるアセットに対する、ガバナンスされた購読ワークフローの提供
ポイントは「フルフィルメントは自前で用意する必要がある」ことです。通常のテーブルアセットの購読では承認時に Lake Formation の権限が自動付与されますが、カスタムアセットの購読では SMUS が付与するのは発見とメタデータへのアクセスまでで、実データへのアクセス提供はアセット所有者側の仕組みで行います。
なお、SMUS のコンソール上でカスタムアセットタイプを扱う機能は今回新しく追加されたものですが、その実体は DataZone のアセットタイプ・フォームタイプ・アセットです。そのため本記事では、あえて AWS CLI（aws datazone）から一連のフローを組み立てて挙動を確認していきます。
※ 補足: フルフィルメントとは、購読リクエストが承認された後に、購読者へ実データへのアクセスを実際に提供する（＝購読を「履行」する）プロセスのことです。
 やってみた今回は、Amazon Quick のダッシュボード「Superstore Sales Performance Dashboard」をカスタムアセットとしてカタログ化します。
Quick Sight ダッシュボードは AWS のサービスでありながら、SMUS のシステムアセットタイプ（AWS Glue テーブル・Amazon Redshift テーブル・Amazon S3 オブジェクトコレクション・SageMaker モデルなど）には含まれていません。つまり「SMUS がネイティブ対応していないアセット」であり、まさにカスタムアセットタイプの出番というわけです。
 検証の流れ全体の流れは次のとおりです。
 前提条件IAM ベースの SMUS V2 ドメイン（singleSignOn が DISABLED のドメイン）が作成済みであること
アセットタイプ・フォームタイプ・アセットの所有プロジェクト（今回はドメイン作成時に生成される admin-project）
カタログ化対象の Quick Sight ダッシュボードが作成済みであること（今回は「Superstore Sales Performance Dashboard」）
検証環境
リージョン: ap-northeast-1
AWS CLI v2（2.35.21）

まず、対象ドメインが IAM ベースであることを確認します。IAM ベースドメインは singleSignOn.type が DISABLED になっています。
% aws datazone get-domain --identifier dzd-d3w2uawk8vo7a1 \
  --query '{name:name, version:domainVersion, sso:singleSignOn.type}' \
  --region ap-northeast-1
{
    "name": "Default_05252026_Domain",
    "version": "V2",
    "sso": "DISABLED"
}
以降、ドメイン ID を $DOMAIN、所有プロジェクト ID を $PROJECT として進めます。
export DOMAIN=dzd-d3w2uawk8vo7a1
export PROJECT=c778yzrdr7zy55
 メタデータフォームタイプを作成するカスタムアセットタイプに紐付けるメタデータフォームを先に作成します。ここでは Quick Sight ダッシュボードを表現するフォームとして、ダッシュボード ID（必須）・ダッシュボード URL・データ所有者・更新スケジュールを定義します。フォームのスキーマは Smithy 記法で記述し、--model に smithy キーを持つ JSON として渡します。
% SMITHY='structure QuickSightDashboardForm {
@required
dashboardId: String
dashboardUrl: String
dataOwner: String
refreshSchedule: String
}'
% MODEL=$(jq -nc --arg s "$SMITHY" '{smithy:$s}')
% aws datazone create-form-type \
  --domain-identifier "$DOMAIN" \
  --name QuickSightDashboardForm \
  --model "$MODEL" \
  --owning-project-identifier "$PROJECT" \
  --status ENABLED \
  --region ap-northeast-1
{
    "domainId": "dzd-d3w2uawk8vo7a1",
    "name": "QuickSightDashboardForm",
    "revision": "5"
}
リビジョン 5 としてフォームタイプが作成されました。必須にしたいフィールドには @required を付けるだけです。
 カスタムアセットタイプを作成する続いて、先ほどのフォームを必須として紐付けたカスタムアセットタイプを作成します。--forms-input はリストではなく「フォーム名をキーとするマップ」で、各値に typeIdentifier・typeRevision・required を指定します。
$ FORMS='{"QuickSightDashboardForm":{"typeIdentifier":"QuickSightDashboardForm","typeRevision":"5","required":true}}'

$ aws datazone create-asset-type \
  --domain-identifier "$DOMAIN" \
  --name CustomQuickSightDashboard \
  --description "An Amazon Quick Sight sales dashboard cataloged for governed discovery" \
  --forms-input "$FORMS" \
  --owning-project-identifier "$PROJECT" \
  --region ap-northeast-1
{
    "domainId": "dzd-d3w2uawk8vo7a1",
    "name": "CustomQuickSightDashboard",
    "revision": "3",
    "description": "An Amazon Quick Sight sales dashboard cataloged for governed discovery",
    "formsOutput": {
        "AssetCommonDetailsForm": {
            "typeName": "amazon.datazone.AssetCommonDetailsFormType",
            "typeRevision": "8",
            "required": false
        },
        "QuickSightDashboardForm": {
            "typeName": "QuickSightDashboardForm",
            "typeRevision": "5",
            "required": true
        }
    }
}
指定した QuickSightDashboardForm が required: true で紐付き、加えてビルトインの AssetCommonDetailsForm（任意）が自動的に含まれています。
 用語集と用語を作成する発見性を高めるための用語集（glossary）と用語を作成します。アセットにこの用語を付与しておくと、後で用語をキーにした発見が可能になります。
% aws datazone create-glossary \
  --domain-identifier "$DOMAIN" \
  --name BusinessIntelligence \
  --description "Glossary for BI and analytics assets" \
  --owning-project-identifier "$PROJECT" \
  --status ENABLED \
  --region ap-northeast-1
{
    "domainId": "dzd-d3w2uawk8vo7a1",
    "id": "5tw3jvbuknlok9",
    "name": "BusinessIntelligence",
    "owningProjectId": "c778yzrdr7zy55",
    "description": "Glossary for BI and analytics assets",
    "status": "ENABLED"
}
作成した用語集の ID を指定して用語を追加します。
% aws datazone create-glossary-term \
  --domain-identifier "$DOMAIN" \
  --glossary-identifier 5tw3jvbuknlok9 \
  --name SalesDashboard \
  --short-description "A dashboard visualizing sales performance metrics" \
  --status ENABLED \
  --region ap-northeast-1
{
    "id": "d97scm3meiuf15",
    "domainId": "dzd-d3w2uawk8vo7a1",
    "glossaryId": "5tw3jvbuknlok9",
    "name": "SalesDashboard",
    "status": "ENABLED",
    "shortDescription": "A dashboard visualizing sales performance metrics"
}
 カスタムアセットを作成するいよいよカスタムアセットを作成します。作成したアセットタイプを --type-identifier に、メタデータフォームの入力を --forms-input に、用語を --glossary-terms に指定します。--type-revision は数値ではなく文字列 "1" である点に注意します。--forms-input の content にはフォームの中身を JSON 文字列として渡します。
% FORMS_INPUT=$(jq -nc --arg c "$CONTENT" '[{formName:"QuickSightDashboardForm",typeIdentifier:"QuickSightDashboardForm",typeRevision:"5",content:$c}]')

% aws datazone create-asset \
  --domain-identifier "$DOMAIN" \
  --name "Superstore-Sales-Performance-Dashboard" \
  --description "Superstore sales performance dashboard built in Amazon Quick Sight, external fulfillment" \
  --type-identifier CustomQuickSightDashboard --type-revision "3" \
  --owning-project-identifier "$PROJECT" \
  --forms-input "$FORMS_INPUT" \
  --glossary-terms d97scm3meiuf15 \
  --region ap-northeast-1
{
    "id": "3svczzdy7akcnt",
    "name": "Superstore-Sales-Performance-Dashboard",
    "typeIdentifier": "CustomQuickSightDashboard",
    "typeRevision": "3",
    "revision": "1",
    "description": "Superstore sales performance dashboard built in Amazon Quick Sight, external fulfillment",
    "createdAt": "2026-07-17T02:51:01.226000+09:00",
    "createdBy": "7cf1da49-6b49-4cf9-aa3a-2398ed6794a9",
    "firstRevisionCreatedAt": "2026-07-17T02:51:01.226000+09:00",
    "firstRevisionCreatedBy": "7cf1da49-6b49-4cf9-aa3a-2398ed6794a9",
    "glossaryTerms": [
        "d97scm3meiuf15"
    ],
    "owningProjectId": "c778yzrdr7zy55",
    "domainId": "dzd-d3w2uawk8vo7a1",
    "formsOutput": [
        {
            "formName": "QuickSightDashboardForm",
            "typeName": "QuickSightDashboardForm",
            "typeRevision": "5",
            "content": "{\"dashboardId\":\"e0fcec7c-fc9f-459a-a975-105b5ccd9b68\",\"dashboardUrl\":\"https://ap-northeast-1.quicksight.aws.amazon.com/sn/dashboards/e0fcec7c-fc9f-459a-a975-105b5ccd9b68\",\"dataOwner\":\"bi-team@example.com\",\"refreshSchedule\":\"Direct query (no SPICE refresh)\"}"
        }
    ],
    "readOnlyFormsOutput": []
}
dashboardId と dashboardUrl には、Quick Sight の実際のダッシュボード ID・URL をそのまま格納しています。アセットが作成できたので、get-asset でメタデータフォームの中身が保存されているかを確認します。
% aws datazone get-asset --domain-identifier "$DOMAIN" --identifier 3svczzdy7akcnt \
  --query 'formsOutput[?formName==`QuickSightDashboardForm`].content' --output text \
  --region ap-northeast-1
{"dashboardUrl":"https://ap-northeast-1.quicksight.aws.amazon.com/sn/dashboards/e0fcec7c-fc9f-459a-a975-105b5ccd9b68","dashboardId":"e0fcec7c-fc9f-459a-a975-105b5ccd9b68","dataOwner":"bi-team@example.com","refreshSchedule":"Direct query (no SPICE refresh)"}
入力した内容がそのまま永続化されていました（キーの並び順は入力時と変わることがあります）。
 スキーマ検証の挙動を確認する「不正な構造だと作成が失敗する」という仕様を確かめるため、ダメ元で必須フィールド dashboardId を欠いたアセットの作成を試してみました。
% BAD_CONTENT='{"dashboardUrl":"https://ap-northeast-1.quicksight.aws.amazon.com/sn/dashboards/only-url","dataOwner":"nobody@example.com"}'

% BAD_FORMS=$(jq -nc --arg c "$BAD_CONTENT" '[{formName:"QuickSightDashboardForm",typeIdentifier:"QuickSightDashboardForm",typeRevision:"5",content:$c}]')

% aws datazone create-asset \
  --domain-identifier "$DOMAIN" \
  --name "Invalid-Dashboard-NoId" \
  --type-identifier CustomQuickSightDashboard --type-revision "3" \
  --owning-project-identifier "$PROJECT" \
  --forms-input "$BAD_FORMS" \
  --region ap-northeast-1

aws: [ERROR]: An error occurred (ValidationException) when calling the CreateAsset operation: $.QuickSightDashboardForm.dashboardId: is missing but it is required
上記のエラーが返され、作成は拒否されました。アセットタイプで定義した必須制約がしっかり効いていることを確認できました。
 カタログに公開して発見する作成直後のアセットはプロジェクトのインベントリに存在します。まずはインベントリ検索で見つかることを確認します。
% aws datazone search \
  --domain-identifier "$DOMAIN" \
  --owning-project-identifier "$PROJECT" \
  --search-scope ASSET \
  --search-text "Superstore" \
  --region ap-northeast-1 \
  --query '{items: items[].assetItem.{identifier:identifier, name:name, typeIdentifier:typeIdentifier}, totalMatchCount: totalMatchCount}'
{
    "items": [
        {
            "identifier": "4ruxgtt71v2pzt",
            "name": "superstore_joined",
            "typeIdentifier": "amazon.datazone.GlueTableAssetType"
        },
        {
            "identifier": "3svczzdy7akcnt",
            "name": "Superstore-Sales-Performance-Dashboard",
            "typeIdentifier": "CustomQuickSightDashboard"
        }
    ],
    "totalMatchCount": 2
}
今回作成したカスタムアセットに加えて、このダッシュボードの元データである Glue テーブル superstore_joined（ネイティブのシステムアセットタイプ）もヒットしました。テーブルとダッシュボードというフォーマットの異なる資産が、同じ検索でまとめて見つかっています。
インベントリで見つかっただけでは、他ユーザーがカタログから発見・購読することはできません。カタログに公開（リスティングの発行）するには create-listing-change-set を使います。
% aws datazone create-listing-change-set \
  --domain-identifier "$DOMAIN" \
  --entity-identifier 3svczzdy7akcnt \
  --entity-type ASSET \
  --action PUBLISH \
  --region ap-northeast-1
{
    "listingId": "5f1w8c8znff95l",
    "listingRevision": "1"
}
公開できました。カタログ（リスティング）の検索で発見できるか確認します。
% aws datazone search-listings \
  --domain-identifier "$DOMAIN" \
  --search-text "Superstore" \
  --region ap-northeast-1 \
  --query 'items[].assetListing.{name:name, type:entityType, listingId:listingId}'
[
    {
        "name": "superstore_joined",
        "type": "GlueTableAssetType",
        "listingId": "awlq30o3e85dw9"
    },
    {
        "name": "Superstore-Sales-Performance-Dashboard",
        "type": "CustomQuickSightDashboard",
        "listingId": "5f1w8c8znff95l"
    }
]
カスタムアセットタイプのアセットが、ネイティブアセット（Glue テーブル）と並んでカタログ上で発見できる状態になりました。「フォーマットを問わず、組織内の全アセットを統一的に発見できる」という冒頭のユースケースを、そのまま体験できた形です。
 コンソールでの見え方を確認するここまで CLI で作成してきたオブジェクトが、SMUS ポータルのコンソールからどう見えるかも確認しました。ポータルにサインインし、左下の「ドメイン管理」を開くと、左のナビゲゲーションの「カタログ」配下に「カスタムアセットタイプ」（今回追加された新機能）が現れます。
一覧から CustomQuickSightDashboard を開くと、紐付けたメタデータフォーム QuickSightDashboardForm が「必須」トグル ON で表示され、dashboardId - required・dashboardUrl・dataOwner・refreshSchedule の各フィールドが確認できます。CLI で定義したスキーマがそのままコンソールに反映されていることが分かります。
さらに、ポータル上部の検索から「Superstore」を検索すると、Discover 画面に公開済みのカスタムアセットが Glue テーブルと並んで表示されます。アセットタイプ CustomQuickSightDashboard と用語 SalesDashboard がタグとして併記され、What's New が説明する「名前・タイプ・用語での発見」が体験できます。
 考察実際に一連のフローを試して分かった点を整理します。
コンソールの「カスタムアセットタイプ」は、実体としては DataZone のフォームタイプ・アセットタイプ・アセットです。そのため aws datazone の各 API でそのまま自動化でき、CLI で作成したオブジェクトはコンソールにも即座に反映されます。IaC やスクリプトでカタログ整備を自動化したいケースと相性が良さそうです。
作成順序には依存関係があります。「フォームタイプ・用語集、 アセットタイプ、アセット、公開」の順で進める必要があります。
スキーマ検証は確実に効きます。必須フィールドを欠くとアセット作成が ValidationException で失敗するため、カタログの品質を一定に保てます。
削除には無効化（DISABLED）の一手間が必要です。用語・用語集・フォームタイプは ENABLED のままでは削除できません。また、アセットタイプはそのタイプから作られたアセットが残っていると、フォームタイプは参照元のアセットタイプが残っていると、それぞれ削除できません。さらに、削除しても同名タイプのリビジョン番号は引き継がれるため、リビジョンをハードコードしたスクリプトは再実行時に壊れます。クリーンアップや再実行の手順を組む際は、この依存関係と状態遷移を織り込む必要があります。
権限面では、所有プロジェクトの指定が必須（owning-project-identifier）で、操作するプリンシパルがそのプロジェクトのメンバー（オーナー/コントリビューター）である必要があります。公式ドキュメントによると、アセットタイプの利用権限を編集できるのはドメインユニットのオーナーとプロジェクトオーナーに限られ、コントリビューターは参照のみとされています。
カスタムアセットの購読は、あくまで発見とメタデータへのアクセスを提供するものです。通常のテーブルアセットのように Lake Formation 権限が自動付与されるわけではなく、実データの提供（フルフィルメント）は所有者側で用意する必要があります。今回の Quick Sight ダッシュボードであれば、購読承認を受けて所有者が aws quicksight update-dashboard-permissions で購読者に閲覧権限を付与する、といった運用が考えられます（DataZone が EventBridge に発行する購読イベントを使えば自動化も狙えそうです）。この点は導入時に運用設計として押さえておきたいところです。
今後に期待したい点としては、フォームタイプの無効化に create-form-type の再発行を使う必要がある部分など、専用の状態変更 API があるとより直感的に扱えると感じました。
 最後にAmazon SageMaker Unified Studio の IAM ベースドメインで、カスタムアセットタイプを使って Amazon Quick Sight のダッシュボード「Superstore Sales Performance Dashboard」をカタログ化し、公開・発見までを一通り試してみました。
SMUS がネイティブ対応していない任意フォーマットのアセットでも、メタデータフォームでスキーマを定義し、用語で意味づけし、ガバナンスされた発見・購読フローに載せられるのは大きな利点です。実際、元データの Glue テーブル（ネイティブアセット）と Quick Sight ダッシュボード（カスタムアセット）が同じ検索で並んで見つかる様子も確認できました。実データの提供は自前で用意する前提ではありますが、「組織内のあらゆるデータ資産を 1 つのカタログで発見できる」状態に近づけられます。
コンソールからの操作はもちろん、本記事のように aws datazone の API から自動化することもできます。社内の BI ダッシュボードやレポート類のカタログ整備を検討されている方は、一度触ってみてはいかがでしょうか。この記事がどなたかのお役に立てば幸いです。