Amazon Quick Dataset Q&A / Topic Q&A / Dashboard Q&A の使い分けと組み合わせのベストプラクティス
クラウド事業本部の石川です。Amazon Quick では、同じ「自然言語で聞く」という操作でも、Dataset Q&A・Topic Q&A・Dashboard Q&Aという 3 つの方式が用意されており、内部の仕組みはまったく異なります。ここを取り違えると「集計が合わない」「元となった数値がどこにあるのか分からない」といった事故につながります。
本記事では、Redshift / Athena 上の数億行規模の構造化データと、PowerPoint / Excel などの非構造化文書が混在する環境を前提に、3 方式の技術的な使い分け・組み合わせのベストプラクティスを整理します。
最初に結論
- 数値（売上・在庫の集計）は構造化ルートだけで答える。 Redshift/Athena の「認定データマート」→ QuickSight データセット →（Dataset Q&A / Topic Q&A / Dashboard Q&A）。数億行規模なので direct query を主役にし、SPICE は集約済みマートに限定する。
- PowerPoint/Excel は「文脈」を返すナレッジベース（RAG）として使う。数値の正本にしない。 特に Excel の数値表・集計表は RAG に入れず、構造化して Dataset Q&A 側へ回す（RAG は決定論的な集計ができない）。
- Quick Chat（チャットエージェント）＝日常的な問い合わせ、ディープリサーチ（研究）＝引用付きの分析レポート生成、と役割を分ける。重要 KPI は「すべてのデータ」任せにせず、業務別カスタムエージェントで認定リソースにスコープする。
- 3 つの方式は技術的に別物:
- Dataset Q&A = text-to-SQL（動的に SQL 生成）
- Topic Q&A = セマンティックモデル方式の NLQ（事前キュレーションしたメタデータ層を介する）
- Dashboard Q&A = 事前構成ビジュアル（集計済み）への NLQ
※ ナレッジベース = RAG（セマンティック検索＋生成、非構造化文書向け）
1. 「それぞれ何なのか」— 3 方式の技術的な正体
ユーザーの問い「Dataset Q&A は text-to-SQL。では Topic / ナレッジベースは？」への回答です。同じ「自然言語で聞く」でも、内部の仕組みがまったく違います。 ここを取り違えると「集計が合わない」事故が起きます。
| 方式 | 技術的な正体 | 何に対して答えるか | 集計の正確性 | セットアップ |
|---|---|---|---|---|
| Dataset Q&A | text-to-SQL（質問を動的に SQL 化し、フルデータに実行。スキーマを実行時に読み、関係を推論。意味グラフ検索でサンプル値・分布も参照） | データセットの任意のフィールド＋実行時計算 | ◎ 決定論的 SQL。Explain で生成 SQL・仮定・フィルタを検証可 |
不要（即利用） |
| Topic Q&A | セマンティックモデル方式の NLQ（Author が事前にフィールド名・シノニム・名前付きエンティティ・既定集計・フィルタを定義したメタデータ層を介する） | キュレーション済みの定義された指標のみ | ○ 定義した集計ルールに従う（定義品質に依存） | 必要（トピック構成・継続メンテ） |
| Dashboard Q&A | 事前構成ビジュアル（集計済み結果）への NLQ。Author が設計した範囲内で回答 | 既存ダッシュボードのビジュアル＋その背後のデータセット | ○ Author が検証済みの計算が土台 | 必要（ダッシュボード作成） |
要点: ナレッジベースは、RAG（Retrieval-Augmented Generation）。文書をインデックス化（Quick Index）し、意味検索でチャンクを取得して LLM が生成。PowerPoint/Excel/PDF 等の非構造化文書のなので、集計には使えない。「文書にそう書いてある値」を返すだけです。
要点: Dataset / Topic / Dashboard Q&A は「程度の違う SQL ベース」で数値は信頼できる。ナレッジベースだけが RAG で、数値の集計には絶対に使わない。
2. 質問パターン別「どのデータを組み合わせるか」
2-1. 売上分析（集計）への問い合わせ — 構造化ルート
例:「先月の事業部別 純売上を前年同月比で。粗利率トップ 10 SKU は？」
正しく答えるためのデータの組み合わせ（下から積み上げる）:
- ① 認定データマート: KPI 定義はプロンプトではなくデータ層に置く。純売上／粗利率／引当可能在庫／在庫回転率／消化率といった指標を Redshift/Athena のビューや dbt モデルで定義し、「正本」を一箇所に。
- ② データセット: RLS（行レベルセキュリティ）/CLS（列レベルセキュリティ）、日付粒度、非加算指標の既定集計（在庫残高・率・単価・構成比は単純 SUM 禁止）を設定。
- ③ 3 種の Q&A: 数億行なので direct query（Redshift/Athena）が主役。Dataset Q&A は direct query で行数無制限。標準 KPI は Topic、既存ダッシュボードは Dashboard Q&A。
- ④ Quick Chat: 認定リソースだけをバインドした売上エージェント経由で。回答は
Explainで生成 SQL・フィルタ・粒度を確認。
※ 数億行のポイント: SPICE は Enterprise でも 20 億行 / 2 TB が上限。生明細をそのまま SPICE に載せず、日次・SKU 別などに集約したマートだけ SPICE 化して高速応答、生粒度のドリルダウンは direct query、という二段構えが最適。
2-2. PowerPoint / Excel（自然言語）への問い合わせ — 非構造化ルート
例:「Q1 の値引き施策の狙いは？ 競合 A への対抗方針は議事録でどう決まった？」
- ① 文章主体（用語集・定義・ポリシー・手順・レポート・提案書・議事録）→ ナレッジベース（RAG）へ。
- ②③ メタデータ付与: 年度・部門・商品カテゴリ・対象期間・施策名・SKU/店舗 ID を文書側にも付与し、構造化データと共通の業務語彙・IDで揃える（これが橋渡しの鍵）。
- ④ 利用: 単純な検索・要約はQuick Chat、複数文書＋Web＋社内データ横断の調査はディープリサーチ。
※ 最重要の落とし穴 — Excel の数値表・集計表
「非構造化に数値表・集計表が含まれる」としても、数値表を RAG（ナレッジベース）に入れて集計させてはいけません。RAG は意味検索なので「合計」「前年比」を正しく計算できません。
→ 集計対象の Excel は S3 経由で Athena/Redshift に取り込み、構造化して Dataset Q&A 側で扱う。 文章・所見が主の Excel だけナレッジベースへ。判断基準は 3-1 のフロー参照。
2-3. 両者の合成（橋渡し）
例:「4 月の売上が落ちた理由は？」→ 数値（落ち幅）は Dataset Q&A、理由・施策・営業コメントはナレッジベースから引用して合成。
- Quick Chatに丸投げせず、共通 ID とメタデータで構造化↔非構造化を接続。
- 回答では「数値の出典（どのデータセット/SQL）」と「文書の出典（どのファイル）」を分けて表示させる。
- KPI 定義書は Topic/データセットの説明にも、ナレッジベースにも入れて、語彙を一致させる。
3. 正確な集計をどう担保し、どう使い分けるか
3-1. 「数値か文脈か」の振り分けフロー
3-2. 正確性を担保する 6 つの設計原則
- KPI 定義はデータ層に置く: 認定ビュー / dbt モデル / データマートで一元定義。自然言語 Q&A はその上に載せるだけ。
- Topic を標準 KPI の第一入口に : 「売上」「昨対」「欠品」などの曖昧語をシノニム・既定集計で固定。非加算指標（在庫残高・率・単価・構成比）は単純 SUM させない。
- Dataset Q&A は認定データセット限定で開放 : 生テーブルではなく整形済みデータセットに。重要報告値は
Explainで SQL・WHERE・日付列・集計粒度を確認。 - Dashboard Q&A は対象データセットを最小化 : 表示中ビジュアル以外も参照され得るため、CLS で隠す列を守り、RLS を必須に。
- Excel の扱いを二分 : 集計対象（明細・予算・在庫表）は構造化ルートへ取り込み。会議資料・所見はナレッジベースへ。KB が返す数値は「文書記載値」で BI の正本とは別物として扱う。
- ゴールデン質問セット（正解が確定した代表質問の集合）で継続検証 : 「代表質問」と「人手で検証した SQL の期待値（＝ground truth／正解値）」をペアで用意し、Q&A の回答が期待値と一致するか定期照合する回帰テスト。精度は ground truth ベンチで約 48% 向上の報告があるが、過信せず監査要件データは元クエリで裏取り。
4. 扱えるデータ規模・制限の早見表
4-1. 構造化データ（SPICE vs direct query）
| 項目 | SPICE | direct query |
|---|---|---|
| 行数 | Standard: 2,500 万行 / 25 GB、Enterprise: 20 億行 / 2 TB（先に達した方） | 行数・サイズ制限なし（バックエンド DB 依存） |
| カラム数 | 2,000 列 / ファイル | 結果セット 2,000 列 |
| カラム名 | 127 Unicode 文字 | 127 Unicode 文字 |
| 1 フィールド長 | 2,047 文字（新データ準備で 65,534 文字） | — |
| タイムアウト | （取り込み済みなので高速） | 可視化生成 2 分（※Redshift 等は反応せずクエリ継続）＋ DB エンジン側タイムアウト |
| 数億行での推奨 | 集約済みマートのみ SPICE 化 | 生粒度・大規模はこちが主役 |
Dataset Q&A 固有: direct query は行数無制限、SPICE は容量内、20 億行までスケール、RLS/CLS 尊重。非対応: 複合データセット（親 SPICE＋子 direct query）／カスタム SQL のパラメータ。Enterprise Edition が必要。
Topic / Dashboard Q&A の規模観点: いずれも背後のデータセット（SPICE/direct query）の制限を継承。Topic はキュレーション運用コストがあり、フィールドが多すぎると管理困難。Dashboard Q&A は集計済みビジュアルが土台なので大規模生データを直接スキャンの心配がありません。
4-2. アップロードファイルの制限（用途で 2 系統に分かれる）
| 用途 | 何に使う | サイズ・件数 | カラム/テキスト |
|---|---|---|---|
| SPICE インポート（構造化として集計） | S3 マニフェストは 最大 1,000 ファイル | 2,000 列 / 1 フィールド 2,047（新 65,534）文字 | |
| ナレッジベース（非構造化として検索） | PowerPoint/PDF/Word/Excel を文書として | 標準テキスト文書（PDF/Word/PPT/テキスト）500 MB／動画 10 GB／音声 2 GB | 抽出テキストは 1 文書 30 MB 上限（超過分は非インデックス） |
| 参照ドキュメント（エージェントの常駐指示） | 厳密に守らせる手順・テンプレート | 最大 10 ファイル / 合計 50 MB | 抽出後 10 万文字上限／pdf・txt・html・md・csv・doc・docx |
| スペースへの直接アップロード | 即席の共有素材 | — | — |
使い分けの核心: 同じ Excel でも「集計したい」なら SPICE インポート/Athena 取り込み（構造化）、「読んで参照したい」ならナレッジベース（非構造化）。数値表を 30 MB 抽出上限の RAG に押し込むと、大きい表は途中で切れて集計が壊れます。
4-3. Quick Chat / ディープリサーチのタイムアウト・制限
| 項目 | 値 | 備考 |
|---|---|---|
| データセットのdirect query | 2 分 | 重い集計は SPICE 集約 or マート最適化で回避 |
| DB エンジン側タイムアウト | エンジン依存 | Redshift は QuickSight 側 2 分に反応しない場合あり |
| ナレッジベース同期 | 最大 14 日／回 | 超過で FAILED。フィルタ・分割で範囲縮小 |
| Quick Chat 固定タイムアウト | 公開値なし | 対話用途で短時間想定。重い集計は構造化最適化で対処 |
| ディープリサーチ 所要時間 | 固定上限は非公開 | 長時間実行型エージェント。事例で数分〜30 分規模 |
※ タイムアウトは「固定値を当てにする」より、重い集計はマート/SPICE、マテリアライズドビュー で軽くしておく設計で実質的に回避するのが正攻法です。
5. 今回の要件に最適化したベストプラクティス構成
5-1. 全体アーキテクチャ
5-2. 利用者 3 層 × 推奨機能のマッピング
| 利用者 | 主なニーズ | 第一推奨 | 補助 |
|---|---|---|---|
| 現場担当 | 自由度・即時性のアドホック集計 | Dataset Q&A（＋ Explain） | Topic Q&A |
| 非技術者 | 一貫性・信頼性の定型 KPI | Topic Q&A / Dashboard Q&A | 売上/在庫エージェント |
| 企画・経営 | 網羅性・引用根拠の分析 | ディープリサーチ | Dataset Q&A（数値の裏取り） |
5-3. 実装ロードマップ
- 認定マート構築 — Redshift/Athena に売上・在庫の認定マート / ビュー（KPI 定義の正本）を作る。数億行は direct query 前提、集約結果のみ SPICE 化。
- データセット認定 — RLS/CLS・日付粒度・非加算指標の集計ルールを設定。フィールド説明・シノニムを記述。
- Dashboard Q&A 有効化 — 既存ダッシュボードで最短導線を提供（対象データセット最小化）。
- Topic 整備 — 売上/在庫 Topic を作り、同義語・既定集計・業務説明を投入。
- Dataset Q&A 開放 — 認定データセット限定で開放。
Explain確認運用とエンリッチメント（YAML/JSON でシノニム・集計ルール）を適用。既存 Topic 資産はエンリッチメントファイルへ移植可能。 - ナレッジベース化 — PowerPoint/Excel/PDF を S3/SharePoint 等経由で同期。集計用 Excel は構造化ルートへ分離。文書メタデータ・ACL を整備。
- エージェント構築 — Quick Chatに売上/在庫エージェントを作成し、認定 Dashboard/Topic/Dataset/KB だけをバインド。回答に出典・フィルタ・仮定の明示を指示。
- 継続検証 — ゴールデン質問セットで Q&A 回答 vs 検証済み SQL を定期照合。ディープリサーチは Quick Flows でレポート定期生成も検討。
6. アンチパターン
| アンチパターン | なぜダメか | 正しい対処 |
|---|---|---|
| Excel の数値表をナレッジベースに入れて集計 | RAG は意味検索で決定論的集計ができない。30 MB 抽出上限で表が途中欠落 | Athena/Redshift に取り込み Dataset Q&A |
| 日次 KPI をディープリサーチで確認 | 遅く・コスト高・正本でない | Dataset/Topic/Dashboard Q&A |
| 生明細をそのまま SPICE に全量ロード | Enterprise でも 20 億行/2 TB 上限・コスト増 | 集約マートのみ SPICE、生粒度は direct query |
| 重要 KPI を**「All data」任せ** | 想定外データセットを参照し誤集計の恐れ | 認定リソース限定の専用エージェント |
| KPI 定義をプロンプトに書く | 定義が散在・非加算指標を誤る | データ層（ビュー/dbt）に定義の正本 |
| Q&A 回答を無検証で経営報告 | text-to-SQL も粒度・日付を誤り得る | Explain ＋ゴールデン質問で裏取り |
最後に
Amazon Quick の 3 方式は「同じ自然言語インターフェース」に見えても、Dataset / Topic / Dashboard Q&A は SQL ベースで数値が信頼でき、ナレッジベースは RAG で文脈を返すもの、という決定的な違いがあります。数値は構造化ルート、文脈は非構造化ルートに振り分け、共通の業務語彙・ID で橋渡しすることが、正確な集計と豊かな文脈を両立させる鍵です。
特に「Excel の数値表を RAG に入れない」「KPI 定義はプロンプトではなくデータ層に置く」「ゴールデン質問セットで継続検証する」という 3 点は、集計事故の防止に直結します。本記事が、Amazon Quick を業務に組み込む際の設計の一助になれば幸いです。
