[アップデート] Amazon Quick Sight のマルチデータセットトピックで 4 つのデータセットの自然言語問合せを試してみた

Amazon QuickSightのトピックが複数データセットのランタイム結合に対応しました。事前にデータを結合する手間が不要になり、スタースキーマのまま複数テーブルをまたぐ分析ができるようになったので、実際にマネジメントコンソールで試してみました。

石川覚

2026.08.09

クラウド事業統括本部の石川です。Amazon Quick Sight のトピックが複数データセットのランタイム結合をサポートしましたので、マネジメントコンソールでマルチデータセットトピックの自然言語問合せを試してみました。
https://aws.amazon.com/jp/about-aws/whats-new/2026/08/amazon-quick/
これまで Amazon Quick Sight で複数テーブルにまたがる分析を行うには、データ準備の段階で手動の JOIN ロジックを組み、1 つのデータセットに事前結合しておく必要がありました。今回のアップデートでは、各データセットを元の粒度のまま保持したうえで、トピック側でリレーションシップ（結合キー）を定義しておけば、クエリ実行時に必要な結合だけが組み立てられるようになります。
1 つのトピックに最大 12 個のデータセットを追加でき、分析シートでのビジュアル作成でも、Amazon Quick チャットでの自然言語 Q&A でも、同じセマンティックモデルが使われます。行レベルセキュリティ（RLS）・列レベルセキュリティ（CLS）は既存のデータセット権限がそのまま継承されます。
https://aws.amazon.com/blogs/machine-learning/build-a-unified-semantic-layer-across-datasets-with-multi-dataset-topics-in-amazon-quick/
なお Amazon QuickSight は Amazon Quick へと進化し、BI 機能は Amazon Quick Sight という機能名になりました。
 マルチデータセットトピックとはトピック（Topic）は、エンリッチメント済みの複数データセットを 1 つの統合データモデルにまとめる、マルチデータセットのセマンティックレイヤーです。
従来との違いは以下のとおりです。
公式ドキュメントでは、トピックは 4 つのレイヤーとして説明されています。
破線で囲んだ「リレーションシップ」だけは、CloudFormation を含む API から設定できずコンソール専用です。この点は後ほど検証します。
リレーションシップは、データセットペアと結合に使う列名を記述した JSON ファイルをアップロードして定義します。公式ドキュメント Defining relationships between datasets in a Topic には、中央の売上ファクトテーブルを各ディメンションテーブルに結合するスタースキーマの例が掲載されています。
{
  "datasetPairs": [
    {
      "datasetLeft": { "datasetName": "SALES_FACT", "joinColumnNames": ["CUSTOMER_ID"] },
      "datasetRight": { "datasetName": "CUSTOMER_DIM", "joinColumnNames": ["CUSTOMER_ID"] }
    },
    {
      "datasetLeft": { "datasetName": "SALES_FACT", "joinColumnNames": ["PRODUCT_ID"] },
      "datasetRight": { "datasetName": "PRODUCT_DIM", "joinColumnNames": ["PRODUCT_ID"] }
    },
    {
      "datasetLeft": { "datasetName": "SALES_FACT", "joinColumnNames": ["STORE_ID"] },
      "datasetRight": { "datasetName": "STORE_DIM", "joinColumnNames": ["STORE_ID"] }
    }
  ]
}
公式ドキュメントに記載されている制限は以下のとおりです。
リレーションシップグラフは非巡回（DAG）である必要があり、循環結合は非サポート
自己リレーションシップ（データセットを自分自身に関連付ける）は非サポート
1 つのトピック内で SPICE と Direct Query を混在させることはできない
https://docs.aws.amazon.com/quick/latest/userguide/topics-relationships.html
 主な変更点1 つのトピックに 最大 12 個のデータセット を追加し、データセットペア間の結合キー（リレーションシップ）を定義できるようになりました
分析シートで複数データセットのフィールドを使ってビジュアルを作成すると、Amazon Quick Sight が ランタイム内部結合（inner join） を自動生成します
Amazon Quick チャットでは、LLM ベースのチャットエージェントがリレーションシップをたどり、データセットをまたぐ SQL を生成して回答します。生成された SQL は内容を確認できます
カスタム指示（custom instructions） により、会計年度の定義・指標の算出ロジック・用語の曖昧性解消といったビジネスルールを自然言語で永続的に定義できます
既存のデータセット権限を継承し、行レベルセキュリティ（RLS）・列レベルセキュリティ（CLS） に対応します。RLS はランタイム結合の際にデータセット単位で適用されます
本リリース以前に作成済みのトピックは レガシートピック（legacy Topics） に分類され、従来どおり動作します
事前結合が不要になることで、ユースケースが変わるたびにデータセットを作り直す必要がなくなり、SPICE 容量の過剰な消費も抑えられます。人とエージェントの双方が同一のセマンティックモデルを参照するため、データガバナンスをクロスデータセットのビジュアル全体に一貫して適用できる点も大きなメリットです。
 対応リージョンAmazon Quick が利用可能なすべての AWS リージョンで一般提供（GA）されています。東京リージョン（ap-northeast-1）も含まれます。なお、Amazon Quick Sight のトピックは Enterprise Edition が対象です。
 やってみた 前提条件Amazon Quick Sight Enterprise Edition のアカウント
QuickSight ユーザーのロールは ADMIN_PRO
検証リージョン: ap-northeast-1（東京）
エディションは以下で確認しました。
% aws quicksight describe-account-subscription \
  --aws-account-id "${ACCOUNT_ID}" \
  --query 'AccountInfo' --output json
{
    "AccountName": "q-in-quicksight-sandbox",
    "Edition": "ENTERPRISE",
    "NotificationEmail": "ishikawa.satoru@classmethod.jp",
    "AuthenticationType": "IDENTITY_POOL",
    "AccountSubscriptionStatus": "ACCOUNT_CREATED"
}
なお、以降のリソース名は読みやすさのため mds- 接頭辞に短縮して記載しています。実際の検証では実行 ID を付与した名前を使用しました。
 スタースキーマの SPICE データセットを用意する公式ドキュメントの JSON 例に合わせて、SALES_FACT を中心に CUSTOMER_DIM / PRODUCT_DIM / STORE_DIM を配置したスタースキーマを CSV で作成し、S3 に配置して SPICE データセットにしました。
 SALES_FACT
 CUSTOMER_DIM
 STORE_DIM
 PRODUCT_DIM
 マルチデータセットトピックを作成するDataSets を 4 つ選択して、トピック（mds-star）を作成します。
次の画面の[Relationships]タブで、選択したデータセットのリレーションを設定します。
続いて [Custom Instructions] タブで、ビジネスルールを自然言語で登録します。
- “Fiscal year starts April 1. Interpret ‘this year’ using fiscal year boundaries.”
- “Active customers means customers with at least one purchase in the last 90 days.”
- “When ‘sales’ is mentioned without qualification, default to net_sales_amount.”
- “Return rate = count of returned items (RETURN_FACT) / total items sold (SALES_FACT), as a percentage.”
最後に設定したトピックを Publish（共有）します。
 問合せ対象のトピックを選択左のナビゲーションメニューから「新しいチャット」を選択して、問合せ対象のトピックを選択します。
作成したマルチデータセットトピック（mds-star）を選択します。
 マルチデータセットトピックに自然言語で問い合わせする「Customer-001がStore-01で購入した商品名と総売上を教えてください。」と分析軸（ディメンション）で質問します。ファクト（SALES_FACT データセット）と各ディメンション（CUSTOMER_DIMデータセット、STORE_DIMデータセット、PRODUCT_DIMデータセット）がジョインされていないと、正しく回答はできないはずです。
購入した商品名「Product-030」、レコードも、総売上も正しく取得できています。
 補足: SPICE と Direct Query は本当に混在できないのか同様に「1 つのトピック内で SPICE と Direct Query を混在させることはできない」という制限も試してみます。今回作成した SPICE の SALES_FACT と、既存の Direct Query データセット superstore_joined_jp を 追加してみたところ、想定通りエラーになりました。
All datasets in a SEMANTIC_VIEW topic must use the same query mode.
Dataset superstore_joined_jp uses DirectQuery mode, but dataset STORE_DIM uses SPICE mode.
(errorCode: MIXED_DATASET_QUERY_MODE)
 考察今回の検証で得られた知見を整理します。
 事前結合なしでクロスデータセットの質問に答えられました「Customer-001 が Store-01 で購入した商品名と総売上」という質問は、ファクト 1 つとディメンション 3 つをまたがないと答えられません。従来であれば 4 テーブルを JOIN 済みの単一データセットを用意する必要がありましたが、トピックにリレーションシップを定義しただけで、商品名・レコード・総売上のいずれも正しい値が返ってきました。
各データセットを元の粒度のまま保持できるため、ユースケースが増えるたびに JOIN 済みデータセットを作り直す必要がなくなります。今回の 4 データセットの SPICE 消費量は合計 51 KB ほどで、事前結合したデータセットを別途持つ場合と比べて無駄がありません。
 クエリモードの混在はコンソールがブロックしますSPICE の STORE_DIM と Direct Query の superstore_joined_jp を同じトピックに入れようとすると、専用のエラーコード MIXED_DATASET_QUERY_MODE で弾かれました。ドキュメントに書かれた制約が、UI 上できちんと強制されていることが確認できます。
エラーメッセージに出てくる SEMANTIC_VIEW という語から、新しいトピックが内部的にセマンティックビューとして扱われていることも読み取れます。
 リレーションシップの定義はコンソール専用です冒頭の図で破線にした部分です。describe-topic で返ってくる Topic のキーは Name / Description / UserExperienceVersion / DataSets の 4 つだけで、Relationships に相当するフィールドは存在しません。
 設計はスタースキーマから始めるのが定石です公式ドキュメントでは、1 つ以上の中心的なファクトテーブルを共有ディメンションテーブルに結合するスタースキーマでのモデリングが推奨されています。結合キーには可能な限り整数のサロゲートキーを使い、両側のデータ型の一致・NULL の除去（内部結合では NULL は一致しません）・参照整合性を確認しておきましょう。
ディメンションにサブディメンションがぶら下がるスノーフレーク構造は、結合ホップを減らすために 1 つのディメンションデータセットへフラット化することが推奨されています。リレーションシップグラフは非巡回（DAG）である必要があるため、循環が生まれる場合は片方の経路を落として非正規化します。
今後に期待したい点は以下のとおりです。
TopicDetails への Relationships 追加（CloudFormation / API での IaC 対応）
CreateTopic / UpdateTopic でのデータセット数上限・クエリモード混在のバリデーション
分析シートでの外部結合（outer join）サポート
 最後にAmazon Quick Sight のトピックが、最大 12 データセットのリレーションシップを定義してランタイム結合できるマルチデータセットのセマンティックレイヤーになりました。事前結合したフラットなデータセットを作らずに済むため、データ準備の工数と SPICE 容量を抑えつつ、正規化されたデータモデルのまま分析できます。
実際に試してみると、コンソールから 4 つのデータセットを選んでリレーションシップを設定するだけで、データセットをまたぐ自然言語の質問に正しく答えてくれました。分析シートと自然言語チャットの両方が同じセマンティックモデルを共有する点も、ガバナンス面で大きな利点です。
ユースケースが増えるたびに JOIN 済みデータセットが増殖してしまっている環境をお持ちの方は、スタースキーマでのモデリングとあわせて移行を検討してみてはいかがでしょうか。