トップ > AWS re:Invent 2025 > 【re:Inent 2025】Operationalize Amazon Quick Suite deployments at scale (BIZ406) 参加レポート

【re:Inent 2025】Operationalize Amazon Quick Suite deployments at scale (BIZ406) 参加レポート

AWS re:Invent 2025 Amazon Quick Suite Amazon QuickSight
記事タイトルとURLをコピーする

はじめに

エンタープライズクラウド本部の小林です。

AWS re:Invent 2025で開催された Chalk talk「Operationalize Amazon Quick Suite deployments at scale (BIZ406)」にて、Amazon QuickSight の利用拡大に伴う管理手法について解説がありました。

特に、開発環境で作成した Amazon QuickSight のアセット一式を、本番環境や別のリージョンへ移行・複製するデプロイメントの自動化について、推奨される解決策が紹介されましたので、そのセッション内容をかいつまんで説明します。

1. QuickSightアセット管理とデプロイ手法の変遷

Amazon QuickSightを利用した開発や運用において、まず理解しておくべきなのがアセットの分類と、これまで課題とされてきたデプロイ（環境移行）手法の変遷です。本セッションでは、これらが体系的に整理され、最新のベストプラクティスが提示されました。

QuickSightのアセット分類

QuickSightのリソースは、その役割と扱い方によって大きく3つのカテゴリに分類されます。これらを正しく理解することが、後述する自動化の第一歩となります。

  • Main Assets（メインアセット） コンソール上の左メニューに表示される独立したオブジェクト群です。

    • データソース (Data Sources): RedshiftやRDS、S3などのデータウェアハウスへの接続情報。
    • データセット: スキーマ定義や計算フィールドの定義を含みます。SPICE（インメモリエンジン）またはダイレクトクエリの設定もここに含まれます。
    • 分析: 作成者がビジュアルやフィルタ、シート構成を定義・編集するためのオブジェクトです。
    • ダッシュボード: 分析を公開（Publish）したもので、エンドユーザー向けの読み取り専用オブジェクトです。
    • トピック: 自然言語クエリ機能（Amazon Q in QuickSight）で使用されます。

  • Auxiliary Assets（補助アセット） 単体では表示されず、メインアセットに付随して利用されるオブジェクトです。

    • テーマ: 分析やダッシュボードのカラーパレットやスタイル定義。
    • VPC接続: プライベートネットワーク内のデータソースへの接続設定。
    • テンプレート: 以前のデプロイ手法で使用されていた、リソース定義のスナップショット。

  • Management Assets（管理アセット）

    • フォルダ: アセットを階層構造で整理するためのコンテナです。本セッションでは、このフォルダを単なる整理用としてだけでなく、セキュリティの境界線やデプロイの単位として活用する手法が推奨されています。

デプロイ機能の歴史とAsset Bundle APIの登場

QuickSightにおける開発環境から本番環境への移行（デプロイ）は、長らくユーザーにとっての課題でした。

  1. 2020年頃：テンプレート機能 初期のデプロイ手法です。当時のQuickSightは定義情報（JSON）が隠蔽されていたため、現在のダッシュボードの状態をテンプレートとしてスナップショット化し、それを別環境で参照して再作成するというポインタ方式をとっていました。定義そのものを直接扱えないため、柔軟性に欠ける部分がありました。

  2. 2021年頃：定義の記述 DescribeAnalysisDefinition や DescribeDashboardDefinition といったAPIが登場しました。これにより、分析やダッシュボードの構成要素（シート、ビジュアル、レイアウトなど）をJSON形式で抽出・保存できるようになり、コードベースでの管理（Infrastructure as Code）への道が開かれました。しかし、依存するデータセットやデータソースまでは一括で扱えず、それぞれ個別に移行する必要がありました。

  3. 2022年以降（現在）：Asset Bundle API これまでの課題を解決するために登場したのが、現在の推奨手法である Asset Bundle API です。

    • 最大の特徴: このAPI（StartAssetBundleExportJob）を使用すると、ダッシュボードだけでなく、それが依存する分析、データセット、データソース、テーマまでをすべて含めた単一のパッケージファイル（.qs または .zip）としてエクスポートできます。
    • メリット: 依存関係（Dependencies）が自動的に維持されるため、移行先でデータソースの紐付け直しといった煩雑な作業が不要になります。また、インポート時に環境ごとの設定（接続情報など）を上書きする機能も備えており、Dev/Test/Prod間のパイプライン構築が劇的に簡素化されました。

2. フォルダを活用した階層化とセキュリティ境界

QuickSightのフォルダ機能は、単にファイルを整理するためだけの箱ではなく、フォルダを権限管理の階層構造およびセキュリティの境界線として設計するベストプラクティスが紹介されました。

フォルダ構成のベストプラクティス

QuickSightの共有フォルダは最大10階層までネスト（入れ子）させることが可能です。この機能を活用し、組織構造に合わせた階層を作成します。

  • トップレベル（全社/Admin）: 例えば「全社共通」や「Company」といったルートフォルダを作成します。ここには管理者（Admin）や経営層（C-level execs）を所有者（Owner）または閲覧者（Viewer）として割り当てます。彼らは配下のすべてのフォルダとアセットに対するアクセス権を継承します。

  • 部門レベル: トップレベルの下に、各部門ごとのフォルダを作成します。管理者はこのフォルダを作成し、各部門の分析担当チームに権限を委譲します。

権限の分離とセキュリティ境界

フォルダ階層の中で、役割に応じた権限を適切に配置することで、開発環境と閲覧環境を明確に分離します。

  • 分析チーム: 例えば、マーケティング部門のフォルダに対して、分析担当者を投稿者として追加します。

    • できること: このフォルダ内でのサブフォルダ作成、データセットや分析（Analysis）といったアセットの新規作成・編集が可能。
    • できないこと: 親フォルダ（部門フォルダ自体）の削除などは制限され、安全な作業スペースが確保されます。

  • エンドユーザー（Viewer権限）: 分析チームは、自分たちの作業用フォルダの中に「Assets（素材）」フォルダと「Dashboards（完成品）」フォルダを作成して整理します。そして、Dashboardsフォルダに対してのみ、閲覧者（Marketing End Users）に閲覧者権限を付与します。

この構成のメリット

このフォルダによるセキュリティ境界を設けることで、以下のメリットが生まれます。

  1. 不要な情報の隠蔽: エンドユーザーは、データソース接続情報や作成途中の分析（Analysis）、中間データセットなどを見る必要がありません。完成したダッシュボードだけが共有されるため、混乱を防げます。
  2. 安全な共有: 生データや未承認の分析が誤って公開されるリスクを、フォルダ構成レベルで遮断できます。
  3. 管理の効率化: 上位階層の権限は下位に継承されるため、上位の管理者は個別に権限設定を行わなくても、組織全体のデータを把握できます。

3. 「フォルダ作成」をトリガーにした自動デプロイメント

APIやCLIに不慣れなBI担当者でも、使い慣れたQuickSightの画面操作だけで高度なCI/CDパイプラインを実行できる「フォルダ駆動型デプロイ」の仕組みが紹介されました。

課題：BI担当者と開発ツールのギャップ

従来、QuickSightのアセットをコードベース（Git）で管理したり、自動化パイプライン（CI/CD）に組み込むには、AWS CLIやSDK、Gitコマンドを操作する必要がありました。 しかし、多くのBIアナリストやビジネスユーザーにとって、これらの開発者向けツールは敷居が高く、導入の障壁となっていました。

解決策：GUI上の「フォルダ」をデプロイのスイッチにする

この課題を解決するために提示されたのが、特定の名前のフォルダを作成することをデプロイ開始のトリガー（合図）にするというアプローチです。 BI担当者は、QuickSightの画面上で整理されたアセットの中に、決められた名前（例：RequestCodePush）のサブフォルダを作成するだけで、裏側の自動化プロセスを起動し、開発環境で作成した Amazon QuickSight のアセット一式を、本番環境や別のリージョンへ移行・複製する仕組みです。

アーキテクチャ解説

この仕組みは、AWSのサーバーレスサービスとQuickSightのイベント機能を組み合わせて実現されていました。

  1. Trigger (トリガー): フォルダの作成 ユーザー（BI担当者）は、デプロイしたいアセットが入っている親フォルダの中に、RequestCodePush という名前の空フォルダを作成します。これが本番環境や別のリージョンへ移行・複製のデプロイボタンの代わりになります。

  2. Detect (検知): Amazon EventBridge QuickSight上での操作（フォルダ作成など）はイベントとして発行されます。Amazon EventBridge がこのイベントを常時監視しており、「フォルダが作成された」というアクションを即座に検知します。

  3. Process (判定と実行): AWS Lambda EventBridgeからの通知を受けて AWS Lambda が起動します。Lambdaは作成されたフォルダの名前をチェックし、それが事前に定義されたキーワード（RequestCodePush）と一致する場合にのみ、デプロイパイプライン（AWS CodePipeline）を実行します。

    • ユーザーへのフィードバック: Lambdaはパイプラインのステータスに合わせて、作成されたフォルダの名前を RequestCodePush_Triggering → RequestCodePush_Exporting → RequestCodePush_Completed のように書き換えます。これにより、ユーザーはQuickSightの画面を見るだけで進捗状況を確認できます。

  4. CI/CD (AWS CodePipeline) Lambdaによってトリガーされたパイプラインは、以下のステップを自動実行します。

    • Export (エクスポート): Asset Bundle Export API を使用して、対象の親フォルダに含まれるすべてのアセット（ダッシュボード、分析、データセット、データソース）を依存関係ごとパッケージ化して抽出します。
    • Git連携: 抽出されたバンドル（.qs/.zip）を展開し、JSON定義としてGitリポジトリ（GitHub等）にプッシュします。同時にプルリクエスト（PR）を自動作成します。
    • Approval (承認): 管理者（BI Admin）へ通知が飛びます。管理者はGit上で変更差分（Diff）を確認し、問題なければ承認・マージします。
    • Import (インポート): 承認されるとパイプラインが再開し、Asset Bundle Import API を使用して、ターゲット環境（本番環境や別リージョン）へアセットを展開します。

このアーキテクチャにより、BI担当者は複雑なツールを一切触ることなく、ガバナンスの効いた安全なデプロイプロセスを実現できます。

4. デモ：EUリージョンからUSリージョンへのクロスリージョン展開

実際に開発されたアセットを、異なるリージョンへ自動的に移行する様子が実演されました。ここでは、単なる自動化だけでなく、チャットボット（AIエージェント）に指示してデプロイを実行させるという手法が紹介されました。

シナリオ：アイルランドからオレゴンへのアセット移行

  • ユーザー: マーケティング分析担当者（Marketing Analyst）
  • 移行元: eu-west-1 (アイルランド) リージョン
    • フォルダ構成: Oktank > Marketing > Assets
    • 含まれるアセット: 分析、ダッシュボード、および特定の Action Connector
  • 移行先: us-west-2 (オレゴン) リージョン
    • 状態: フォルダもアセットも何もない、空の状態

Chat Agentの活用：会話によるデプロイ実行

通常であれば、ユーザーが手動で「RequestCodePush」という名前のフォルダを作成することでパイプラインを起動しますが、このデモではさらに一歩進んだ方法がとられました。

  1. AIアシスタントへの指示: ユーザーはQuick Suiteの画面右にあるチャットパネルを開き、カスタム作成されたチャットエージェント「Asset Helper」に対して、自然言語で「フォルダをデプロイして（Help me deploy a folder）」と入力しました。

  2. AIとの対話と実行:

    • AI: 「デプロイしたいフォルダのIDを教えてください」と返答します。
    • ユーザー: 対象のフォルダIDをコピー＆ペーストします。
    • AI (Action): IDを受け取ったAIエージェントは、裏側でAPI（Amazon API Gateway経由でLambda）を呼び出し、ユーザーの代わりに「デプロイ用のトリガーフォルダ（RequestCodePush）」を作成。
    • フィードバック: AIは「デプロイを開始しました」と報告し、現在のステータス（パイプライン起動中、エクスポート中など）をチャット画面上でユーザーに通知します。

このプロセスにより、ユーザーは「フォルダを作成する」という操作すら意識せず、チャットでの会話だけで複雑なデプロイ処理を開始した、というシナリオでした。

デプロイの結果と確認

AIによるトリガー後、バックグラウンドでAWS CodePipelineが走り、以下の処理が自動で行われました。

  • アセットのエクスポートとGitへのコミット
  • 管理者による承認（承認メールが飛び、承認ボタンを押下）
  • USリージョンへのインポート実行

このデモを通して、QuickSightの資産管理機能（フォルダ、Asset Bundle API）とAgentic AIを組み合わせることで、ユーザーの作業負荷を下げつつ、統制の取れた運用が可能であることが見て取れました。

5. 現地での質問 (FAQ)

Q: Terraformは使える？
A: Asset Bundle APIの出力（JSON）を使ってTerraform化が可能。Amazon Q Developerを使えば変換も容易です。

Q: 環境ごとの設定変更（クレデンシャル等）は？
A: Import APIの OverrideParameters を使用し、Dev/Prodで接続先やVPC設定を差し替えられます。

Q: 行レベルセキュリティ（RLS）は？
A: ルール自体は維持されますが、移行先にユーザー/グループが存在する必要がある点に注意が必要です。

まとめと考察

本セッションで紹介されたアーキテクチャは、BIツール運用の「あるある」な悩みを解消するものでしたが一方で、実際に構築する際にはいくつかの考慮点もありそうです。

  • UXの非同期性: 「フォルダ名が変わる」ことでステータスを通知するアイデアは面白いですが、EventBridgeの検知ラグなどを考慮し、ユーザーが焦って連打しないような周知が必要です。
  • クロスリージョンの整合性: リソース（VPC、SPICE容量）やユーザー権限の差異をどう吸収するか、APIの外側での設計も重要になります。
  • AIエージェントの権限: チャットでデプロイできるのは便利ですが、「誰が実行できるか」という認証・認可の設計はより慎重に行う必要があります。

これらを踏まえても、Asset Bundle API とフォルダ運用の組み合わせは、大規模なQuickSight環境を持つ企業にとって非常に強力な選択肢になると感じました。


小林 嵩生 (記事一覧)

導入～設計構築～運用まで何でもしたいなといった感じです。