Amazon Web Services ブログ

Amazon QuickSight BIOps – パート1 : バージョン管理とコラボレーションのためのノーコードガイド

本記事は、2025年8⽉6⽇に公開された Amazon QuickSight BIOps – Part 1: A no-code guide to version control and collaboration を翻訳したもの です。翻訳は Public Sector PSA の西川継延が担当しました。

ビジネスインテリジェンス（BI）チームが成長するにつれて、ダッシュボード、データセット、分析の管理はますます複雑になります。明確なバージョン管理なしでのコラボレーションは、作業の上書き、レポートの不整合、本番環境でのエラーにつながる可能性があります。ビジネスのステイクホルダーは迅速なインサイトを要求しますが、BI 作成者は変更を間違いなく繰り返し、自信を持ってデプロイするためのツールを欠いていることがよくあります。

DevOps の原則に着想を得たビジネスインテリジェンスオペレーション（BIOps）は、BI プロセスにバージョン管理と共同開発を導入します。この記事では、Amazon QuickSight のノーコードのコンソール機能を使用して BIOps を実装する方法を説明します。ダッシュボードのバージョン管理、ビジュアルの再利用、並行でのコラボレーション、そして更新の安全なデプロイを、すべて QuickSight UI を通じて行う方法を紹介します。私たちのフレームワークは、QuickSight に組み込まれたバージョン管理ツールを使用して、チームが管理を合理化し、手作業を削減するのに役立ちます。このコード不要のアプローチは、BI アナリストとダッシュボード作成者の両方がこれらのプラクティスをすぐに採用するのに役立ちます。

QuickSight の基本

このセクションでは、Amazon QuickSight におけるビジネスインテリジェンスオペレーション（BIOps）の基本を紹介します。QuickSight のアセットがどのように分類されるか、基礎となる権限モデル、そして私たちのオペレーションを導く不可欠な BIOps の原則という3つの主要な領域を検証します。

アセットの分類

QuickSight はアセットを4つのカテゴリに整理し、それぞれが BI ワークフローで特定の目的を果たします。

  • メインアセット – これらは中核となる構成要素であり、QuickSight コンソール上でスタンドアロンのオブジェクトとして表示されます。これらのアセットは相互に依存しています。例えば、分析はデータセットに依存し、データセットはデータソースに依存します。
    • データソースは、Amazon Redshift、Amazon Athena、Amazon Simple Storage Service (Amazon S3) などのシステムに接続します。
    • データセットはデータソースから構築され、結合、カスタム SQL、計算フィールドを含むことができます。
    • 分析は、ビジュアルを構築するためのインタラクティブな環境です。
    • ダッシュボードは、分析が公開されたもので、読み取り専用のバージョンです。
    • Amazon Q のトピックは、自然言語クエリのためのセマンティックレイヤーを定義します。
  • 補助アセット -これらはユーザーエクスペリエンスを向上させますが、QuickSight UI では主要なオブジェクトではありません。例えば、テーマはダッシュボードや分析のスタイルを定義しますが、QuickSight コンソール上ではスタンドアロンのアセットとしてリストされません。しかし、テーマは API を介してプログラム的にスタンドアロンのオブジェクトとして管理でき、list、describe、update、delete などの操作をサポートします。
  • セカンドクラスアセット – これらはメインアセット内の内部コンポーネントであり、カスタム SQL、テーブル、フィルター、計算フィールド、パラメータなどが含まれます。これらの要素は QuickSight コンソール UI 上ではスタンドアロンのオブジェクトではなく、直接的なリスト (list) や詳細表示 (describe) の API コールを通じてもアクセスできません。代わりに、データセット、分析、またはダッシュボードの定義内で定義されます。これらは QuickSight コンテンツのロジック、構造、およびインタラクティビティを定義する上で重要な役割を果たします。
  • フォルダ – これらはメインアセットを階層構造に整理するために使用される管理アセットです。個人用または共有フォルダを作成してアセットを分類できます。フォルダはアクセス権限をサポートし、1つのアセットは複数のフォルダに存在できます。

権限モデル

QuickSight のメインアセット、補助アセット、および管理アセットは、安全なコラボレーションのためにユーザーおよびグループレベルの権限をサポートしています。

BIOps の基本ワークフロー

BIOps には３つのコア機能が含まれます。

  • アセットのバックアップと復元 – これは通常、AWS アカウントごと、または AWS リージョンごとにスコープが設定されます。このプロセスにより、誤った削除、サービスの中断、またはデータの破損が発生した場合に QuickSight アセットを復元できることが保証されます。
  • バージョン管理 – これは同じ AWS アカウント内で適用でき、BI チームはアセット定義（例えば、データセットやダッシュボード）への変更を追跡したり、以前のバージョンにロールバックしたり、時間の経過とともに異なる開発ブランチを維持したりできます。
  • デプロイメント – これは環境間（例えば、開発アカウントからテスト、QA、本番アカウントへ）およびリージョン間（例えば、us-east-1 から us-west-2 へアセットをデプロイ）でのアセットの昇格をサポートします。

BIOps ワークフローを使用すると、チームはアセットレベルとフォルダレベルの両方でデプロイとバックアップを管理できます。ダッシュボードをデプロイする際、チームは機能をサポートするために依存アセット（データセット、データソース、テーマ）を含めることができます。フォルダレベルの操作により、関連するアセットを単一のパッケージとして昇格させることが可能になります。AWS アカウント間でのデプロイには、慎重な権限管理が必要です。アセットタイプにはユーザーまたはグループの権限があり、セキュリティを維持し、依存関係の破損を防ぐために、ターゲット環境で適切に再作成する必要があります。

次の図は、BIOps ワークフローの概要を説明したものです。バージョン管理は、QuickSight コンソール UI を通じても実現できます。

QuickSight ダッシュボードの構築と公開

次のグラフに示すように、QuickSight のダッシュボード開発プロセスは、BI 作成者から始まります。BI 作成者は、アクセス管理を簡素化するためにグループにまとめることができます。

作成者はまず、QuickSight を Amazon Redshift などのストレージシステムに接続してデータソースを作成します。次に、変換、結合、カスタムフィールドを追加してデータセットを構築します。データセットの鮮度は、手動またはスケジュールされた更新によって維持され、モニタリング機能も備わっています。

これらのデータセットを使用して、作成者はビジュアルとインタラクティブなコンポーネントを備えた分析を作成します。一貫した組織のブランディングのためにテーマを適用することができます。最終ステップは、分析をダッシュボードとして公開し、特定のユーザーやグループと共有することです。このプロセスにより、ガバナンスを維持しながら、スケーラブルなセルフサービス BI が可能になります。

ソリューションの概要

この記事では、３つの主要な QuickSight 機能について説明します。

  1. コンソール UI を通じたダッシュボードのバージョン管理
  2. 異なる分析からダッシュボードを公開することによる並行でのチームコラボレーション
  3. 他の分析やダッシュボードからビジュアルをインポートすることによるコンテンツの再利用

QuickSight コンソールのこれらの新機能により、ノーコードのインターフェースを通じて効率的な BI コラボレーションとダッシュボードのライフサイクル管理が可能になります。作成者は以下のことができます。

  • ダッシュボードとデータセットのバージョン履歴を追跡する
  • ダッシュボードを以前のバージョンにロールバックする
  • アセットを手動で複製する
  • 分析とダッシュボード間でビジュアルをインポートおよびエクスポートする
  • アセットの説明を通じて変更を文書化する
  • ブックマークを使用してパーソナライズされたビューを作成する
  • 元に戻す（undo）とやり直し（redo）機能で分析の編集を管理する

これらの機能は、コーディングの経験を必要とせずに、合理化されたガバナンスとチームコラボレーションをサポートします。

この記事では、ノーコードでUIベースのワークフローに焦点を当てます。このシリーズの パート 2 と パート 3 では、QuickSight API とプログラム可能なアプローチを使用した自動化されたガバナンスとデプロイについて説明します。

UI ベースのデータセットとダッシュボードのバージョン管理

QuickSight は 2021 年後半にネイティブな データセットのバージョン管理 を導入しました。ユーザーは、QuickSight コンソール UI 内で直接、最大 1,000 の公開済みバージョンを追跡および管理できます。データセットの所有者は、過去の状態をプレビューしたり、以前のバージョンに戻したり、安全に編集したりできます。これには、互換性のない変更（削除されたソースや無効な計算など）に対する保護機能が含まれています。

2025 年 4 月、QuickSight は ダッシュボードのバージョン管理 を導入し、バージョン管理機能をデータセットから完全なダッシュボードへと拡張しました。ダッシュボードの所有者は、UI を通じてバージョンの管理、変更の追跡、以前の状態への復元を、コードを書くことなく行えるようになりました。技術チームは引き続き API ベースの自動化を選択するかもしれませんが、アナリストやビジネスユーザーはこれらの機能を利用して、エンドツーエンドのダッシュボードライフサイクル管理を容易に行うことができます。

次の図は、QuickSight のダッシュボード開発における、バージョン管理された継続的インテグレーションと継続的デリバリー（CI/CD）のワークフローを示しています。

ワークフローは、分析の作成と編集（バージョン 1）から始まり、次にそれをダッシュボードバージョン 1 として公開します。QA テストの後、ダッシュボードが合格すれば、分析はバージョン 2 に更新され、再公開されます。QA テストがどの時点でも失敗した場合、チームは現在のバージョンの編集を続けるか、以前のバージョンにロールバックすることができます。このサイクルは、公開、テスト、更新という反復的な開発を続け、変更が本番環境に到達する前に検証されることを保証します。「元に戻す」「やり直し」アクションは分析内の変更をサポートし、バージョンのロールバックは BI チームの安全性と俊敏性を高めます。

分析における軽微な編集のための「元に戻す」「やり直し」

QuickSight で分析を編集する際、作成者は 「元に戻す」および「やり直し」 オプションを使用して、変更が永続的になることを心配せずに実験できます。分析内で最大 200 のアクションを元に戻したり、やり直したりすることができ、ツールバーのアイコン（次のスクリーンショットを参照）を使用してアクセスできます。

ダッシュボードの公開とバージョン履歴

分析がダッシュボードとして公開されると、QuickSight は自動的に新しいバージョンを作成します。ダッシュボードの所有者は、バージョン履歴を表示することでこれらのバージョンを管理できます。そのためには、ダッシュボードを開き、上部ツールバーのバージョン履歴アイコンを選択します（次のスクリーンショットを参照）。

これにより、現在公開されているバージョンと、タイムスタンプや各バージョンを公開したユーザーを含むすべての以前のバージョンのリストが表示されるペインが開きます。そこから、必要に応じて以前に公開されたバージョンを確認、比較、復元できます。この機能は、ダッシュボードの変更履歴を明確に追跡でき、所有者はコンテンツがどのように変化してきたかを把握することができます。

間違いが発見されたり、以前のバージョンが好まれたりした場合、所有者はワンクリックでダッシュボードを以前のバージョンにロールバックできます。

このバージョン管理機能は、公開された各ダッシュボードの完全なスナップショットを保持することで、手動での再作業を削減します。他のバージョンへのアクセスを失うことなく以前のバージョンを復元でき、安定性を維持しながら迅速なイテレーション（反復）を可能にします。

UI ベースの並行作成とコラボレーション

次の図は、単一の QuickSight 開発アカウント内で複数の作成者が並行してコラボレーションする方法を示しています。共有フォルダ「QA Assets」は、再利用可能なコンテンツを一元管理する場所として機能し、作成者はダッシュボードを拡張したり、ビジュアルを再利用したり、バージョンを独立して管理したりできます。

この例では、３人の作成者が共有の開発ワークフローに貢献しています。

  • Ying は分析 1 を作成し、それをダッシュボード 1 として公開し、チームのための再利用可能なアセットを確立します。
  • Julia は分析 2 を作成し、ダッシュボード 1 から選択したビジュアルをインポートします。これにより、既存の作業を基に構築しながら、独自のバージョンを維持できます。その後、ダッシュボード 2 を公開します。
  • Rushabh はダッシュボード 2 の「名前を付けて保存」オプションを使用して分析 3 を作成し、さらにカスタマイズしてダッシュボード 3 を公開します。Rushabh は、分析 3 を公開してダッシュボード 1 を置き換えることで、ダッシュボード 1 を更新することもできます。

このアプローチは 2 つの主要な利点をサポートします。

  • 並行開発 – 各作成者は、共有アセットを参照しながら独立して作業します。これにより、上書きや競合の変更のリスクなしに、複数のダッシュボードや機能を同時に開発できます。
  • 副次的な変更を伴わない安全な修正 – 本番のダッシュボードに迅速な修正が必要な場合、作成者は公開されたバージョンから開始し、ターゲットを絞った編集を行い、再公開することができます。これにより、開発中の元の分析にある未完成のビジュアルや実験的な変更を導入することがありません。

これらの機能を組み合わせることで、バージョンの追跡可能性が促進され、リスクが最小化され、大規模なコラボレーションが合理化されます。共有フォルダとモジュール式のワークフローにより、QuickSight はエンタープライズ BI チームにとって強力なプラットフォームとなります。

ダッシュボードを分析として保存

公開後、ダッシュボードはさらなる変更のために分析として 保存 できます。作成者は、次のスクリーンショットに示すように、「名前を付けて保存」オプション（フロッピーディスクアイコン）を使用して、利用中のダッシュボードから新しい分析を作成できます。

新しい分析は個人のリストに表示され、自由に編集できます。元のダッシュボードに影響を与えることなく、ビューをカスタマイズしたり、ビジュアルを試したりできます。

他の分析やダッシュボードからビジュアルをインポート

QuickSight の ビジュアルのインポート機能 を使用すると、分析間でダッシュボードコンポーネントを効率的に再利用し、標準化できます。分析ツールバーから「ビジュアルのインポート」を選択し、共有または個人のアセットを参照して 1 つ以上のビジュアルをインポートします。クエリ、フォーマット、インタラクションを含むインポートされたビジュアルは、現在の分析にコピーされ、元のソースに影響を与えることなく独立してカスタマイズできます。この機能により、ダッシュボードの開発が合理化され、ビジュアルの一貫性が促進され、チーム間の重複が削減されます。

分析からダッシュボ​​ードを公開

QuickSight で既存のダッシュボードを置き換えるには、公開時に「既存のダッシュボードを置き換える」を選択します。これにより、セキュリティ設定や E メールレポートの設定に影響を与えることなく、ダッシュボードが新しい変更で更新されます。

ダッシュボードを分析として保存する、任意の分析からダッシュボードを公開する、他の分析やダッシュボードからビジュアルをインポートするなどの機能を組み合わせることで、BI チームは開発ワークフローにおいて強力な柔軟性を得ることができます。チームはダッシュボードを並行して開発でき、複数の作成者が異なる機能やビジュアルに独立して取り組むことができます。また、元の分析にある進行中または実験的なビジュアルを誤って本番バージョンに導入することなく、本番ダッシュボードの問題を安全に修正することもできます。このモジュール式で管理されたアプローチは、本番環境での安定性を維持しながら、アジャイルなイテレーション（反復）をサポートします。

ダッシュボードを壊さずにデータセットを置き換える

QuickSight のフィールドタイプは、ビジュアル、フィルター、計算がどのように機能するかを決定します。データセットのスキーマ変更が分析の要件と競合すると、ダッシュボードの障害が発生する可能性があります。次のスクリーンショットは、フィルターとビジュアライゼーションのキーフィールドとして SaleDate を使用して構築された、映画チケット販売ダッシュボードの例です。

データセットが更新されました。この更新中に、SaleDate は Date（日付）フィールドから Integer（整数）に変更されました。

再公開後、ダッシュボードは SaleDate に関連付けられたビジュアルを読み込むことに失敗しました。影響を受けた各ビジュアルには、「データセットが変更されすぎたため、QuickSight が分析を自動的に更新できませんでした」というメッセージが表示されました。

円グラフのレンダリングが停止し、時間比較のビジュアルが失敗し、SalesDate のフィルターコントロールが機能しなくなりました。

すでにダッシュボードを動かしているデータセットのスキーマを更新する際、データ型の不一致（フィールドを Date から Integer や String に変更するなど）は、ビジュアルが破損する一般的な原因です。

スキーマの変更が意図的な場合は、次のことを行う必要があります。

  • 影響を受けるフィルターを再作成する
  • 新しいデータ型を認識するようにビジュアルを更新する

スキーマの変更が意図的でない場合は、次のことができます。

  • 不要な変更が含まれていない以前のデータセットバージョンに戻す

QuickSight でデータセットを置き換える際、フィールドマッピングの不一致によるビジュアルの破損も一般的なリスクです。これを軽減するために、QuickSight は現在、次のアクションを実行します。

  • 不一致が検出された場合にフィールドマッピングを更新するようユーザーに自動的に促す
  • スキーマの類似性に基づいてフィールドを自動的にマッピングしようと試みる
  • スキーマが完全に一致しない場合にレビューのための不一致ダイアログを表示する

一致しない、または不整合なフィールドは手動で調整する必要があります。QuickSight は検出された不一致に対してマッピングを強制しますが、ユーザーが提供したマッピングの正確性を検証しません。スキップされたり不適切なマッピングは、依然としてビジュアルの破損を引き起こします。正しいフィールドマッピングにより、ビジュアルが新しいデータセットで期待通りにレンダリングされることが保証されます。

まとめ

新しい QuickSight コンソール機能により、ダッシュボードとデータセットのライフサイクルをコードフリーで管理できます。チームは、バージョン管理、ロールバック機能、並行開発、ビジュアルの再利用を活用して、より安全で効率的なワークフローを作成できます。

自動化、CI/CD 統合、またはプログラムによるガバナンスを必要とするチームのために、このシリーズの パート 2 と パート 3 では、API ベースの BIOps ワークフローについて説明します。

著者について

Ying Wang は、AWS のジェネレーティブ AI 組織に所属するシニアスペシャリストソリューションアーキテクトで、Amazon QuickSight と Amazon Q を専門とし、大企業や ISV のお客様をサポートしています。彼女はデータアナリティクスとデータサイエンスで 16 年の経験を持ち、データアーキテクトおよびソフトウェア開発エンジニアリングマネージャーとしての強力なバックグラウンドを持っています。データアーキテクトとして、Ying は顧客がクラウドでエンタープライズデータアーキテクチャソリューションを設計し、スケールするのを支援しました。エンジニアリングマネージャーとしての役割では、新機能を提供し、エンジニアリングと製品の両方の観点から製品イノベーションを推進することで、顧客が QuickSight を通じてデータの力を解き放つことを可能にしました。

Julia Flash は、AWS のジェネレーティブ AI 組織に所属するシニアビジネスディベロップメントスペシャリストで、北米のエンタープライズセグメント向けのQuickSightエンゲージメントをリードしています。AI、コーディング、製品戦略で 12 年の経験を持ち、エンジニア、テクニカルプロダクトマネージャー、特許を持つイノベーターとしての深いバックグラウンドを持っています。Julia は AI ソリューションの設計と開発、オープンソースのデータサイエンスへの貢献、そして影響力の大きい顧客対応のエンゲージメントを提供してきました。今日、彼女は引き続き顧客と協力し、QuickSight の大規模な採用を推進しています。