Amazon QuickSight本番運用Vol1｜SPICE/埋め込み/生成BI

1. Amazon QuickSight 全体像と本記事の射程

1-1. 本記事のゴール

Amazon QuickSightは「お手軽にダッシュボードを作れるBIツール」として導入されるケースが多いサービスです。しかし、マルチテナント対応・SaaS埋め込み・生成AI活用といった本番要件が加わると、設計の複雑さは一気に増します。SPICE容量の算出方法、増分更新の前提条件、RLSのルールセット設計、埋め込み認証の料金プラン——これらを正確に理解しないまま実装を進めると、本番直前で大規模なリファクタリングを強いられます。

本記事が読者に届けるゴールは以下の6点です。

①SPICE/DirectQuery設計

大規模データでのダッシュボード応答速度を確保するためのSPICE（インメモリキャッシュ）の設計と、リアルタイム性が要件のDirectQuery（ライブ接続）との使い分けを判断できるようになります。容量計算（論理サイズ）・更新スケジュール（最短Hourly・最大5スケジュール/データセット）・DirectQueryの制約（2,000列上限・2分タイムアウト）を正確に把握します。

②データセット設計

テーブル結合（JOIN）・計算フィールド・フィルタ・パラメータを活用したデータセット設計のベストプラクティスを習得します。増分更新（Incremental Refresh）の前提条件——Enterprise edition かつ SQLソース限定（S3/ファイル系は全件更新のみ）——を事前に確認し、設計ミスを防ぎます。

③RLS/CLS

マルチテナントBI・部門別アクセス制御を実現するRLS（行レベルセキュリティ）とCLS（列レベルセキュリティ）を設計できるようになります。2025年3月以降に必須化された明示フラグ（UseAs: RLS_RULES）の設定、RLSのテキスト列限定制約（日付・数値には効かない）も含めて解説します。

④埋め込み分析

SaaSアプリへのダッシュボード埋め込みで頻発するUnsupportedPricingPlanException（匿名埋め込み時のキャパシティプライシング未設定）とUnsupportedUserEditionException（Standard editionでの埋め込み試行）を事前回避するための認証設計を習得します。

⑤生成BI（Amazon Q in QuickSight）

東京リージョン(ap-northeast-1)での提供状況（2026年6月時点でGA・Scenarios対応済）を確認し、Q Topicsの設計指針・Reader Pro/Author Proの料金体系を正確に理解します。

⑥ダッシュボード運用

バージョン管理・テーマ・閾値アラート・スケジュールレポートの本番設定パターンを習得し、安定したBI配信オペレーションを確立します。

1-2. 読者像

本記事は以下の読者を主な対象としています。

BIを内製しているデータ担当者・アナリスト

QuickSightで社内BI基盤を構築・運用しており、SPICEの容量設計、データセットの更新スケジュール管理、RLSによる部門別アクセス制御に課題を持つ方を想定します。「ダッシュボードは動いているが、SPICE容量が足りなくなってきた」「RLSを設定したいが、どのデータセット形式を使えばよいか分からない」といった悩みを持つ方に、とりわけ役立つ内容です。

SaaS埋め込みを担当するエンジニア

プロダクトにQuickSightダッシュボードを組み込む実装を担当しており、埋め込みURL生成API・JS SDK・認証フロー設計に取り組むバックエンド・フルスタックエンジニアを対象とします。「匿名埋め込みでエラーが出る」「セッションタグを使ったタグベースRLSの仕組みが分からない」という課題を持つ方に直接役立つ内容です。

BI基盤全体を設計するソリューションアーキテクト

マルチテナントBI基盤の設計を担当し、RLS/CLS・埋め込み料金プラン・生成AIの要件を一括して満たすアーキテクチャを検討しているAWS中級者以上の方を想定します。複数のEdition・料金プランの選択肢を正確に比較して最適構成を提案できるようになることを目標とします。

前提知識: IAM・S3・Athena・Redshiftの基本概念を持つAWS中級者を対象とします。QuickSightのコンソール操作（データソース接続・ビジュアル作成の基礎）は既知とし、本番BI基盤設計の核心部分に絞って解説します。

1-3. QuickSightを構成する機能群の地図

全体像を把握してから各§に進みます。QuickSightの機能を6カテゴリに整理し、Enterprise edition必須の有無を明示します。

本表のとおり、本番BI基盤に必要な機能はほぼすべてEnterprise editionに集中しています。以下の要件が1つでもある場合は、最初からEnterpriseを選択することを推奨します。

• 外部ユーザー・マルチテナントへのBI提供（RLS/CLSが不可欠）
• SaaSアプリへのダッシュボード埋め込み（Enterprise必須）
• 生成BI（Amazon Q in QuickSight）機能の活用（Enterprise必須）
• 閾値アラートやスケジュールレポートによる自動配信（Enterprise必須）
• 増分更新（Hourly含む）によるデータ鮮度確保（Enterprise必須）

Standardは社内向けの小規模ダッシュボードに適した選択肢です。後からEnterpriseへのアップグレードは可能ですが、RLS/埋め込みの設定を最初からやり直すコストが発生するため、要件が明確な段階でEditionを確定することを推奨します。

1-4. 本記事の差別化と前提知識

名称変更について（2026年3月）

2026年3月、AWSはQuickSightを上位スイート「Amazon Quick（Quick Suite）」へ統合・改称し、サービス名が「Amazon Quick Sight」に変更されました。ただし、APIエンドポイント・SDK名・埋め込みURLのパスはすべて変更なしです。既存のコード・IaC（CloudFormation/CDK）はそのまま動作します。本記事ではSEO主要語として「QuickSight」を継続使用しますが、AWSマネジメントコンソールや最新の公式ドキュメントでは「Amazon Quick Sight」と表示される場合があります。

既存記事との棲み分け

当ブログのデータ分析パイプライン関連記事（Kinesis Data Streams・MSK・EMR Serverless）では、QuickSightを「可視化レイヤーの最終ステップ」として扱っています。本シリーズはQuickSight単体のBI専用 deep-diveとして独立させており、SPICE設計・埋め込み認証・生成AIといった本番運用の核心部分に特化します。データレイク・データウェアハウスの上流構成については既存のパイプライン関連記事をご参照ください。

Standard vs Enterprise の機能差（Edition選定ガイド）

§2 データソース接続・SPICE設計へ進む

2. データソース接続・データセット設計・SPICE vs DirectQuery

2-1. データソースの種類（Athena/Redshift/RDS/S3/SaaS）

QuickSightが接続可能なデータソースは大きく「AWSネイティブ」と「外部・SaaSコネクタ」に分かれます。2026年6月時点の主要ソースを整理します。

AWSネイティブデータソース

外部・SaaSデータソース（主要）

S3/ファイル系の重要制限

S3や手動アップロードファイルから直接データを取り込む場合、以下の制限があります。

• DirectQuery非対応: S3はファイルのため、ライブクエリができません。必ずSPICEへ全件取込になります。
• 増分更新非対応: 全件更新のみです。増分更新（日次差分のみ取込）を行いたい場合は、S3データをAthenaまたはRedshiftのテーブルとして定義し、SQLソースとして接続し直す必要があります。
• スキーマ変更の影響: S3ファイルの列構成が変わると、データセット側でスキーマの再マッピングが必要になります。

VPC接続とプライベートエンドポイント

プライベートサブネット内のRDS・Redshift・Snowflakeに接続する場合は、QuickSightのPrivate VPC Access機能を使用します。

設定手順:
1. QuickSightコンソール → 管理 → VPCとプライベートDNS → VPC接続を追加
2. 接続先VPC ID・セキュリティグループ・プライベートサブネットを指定
3. QuickSightのENI（Elastic Network Interface）が作成され、そのIPをソースとして接続先DBのセキュリティグループインバウンドルールに追加（MySQL=3306、PostgreSQL=5432、Redshift=5439）
4. 接続テストで疎通を確認

クロスアカウント接続

QuickSightから別アカウントのAthena/Redshiftへ接続する場合:
– Athena: クロスアカウントのS3バケットポリシーにQuickSight実行ロールARNを許可し、Glue Data Catalogのクロスアカウントアクセスも設定します。
– Redshift: Resource Access Manager(RAM)によるサブネット共有またはVPCピアリングを組み合わせ、セキュリティグループのインバウンドをQuickSightのCIDRから許可します。

2-2. データセット設計（結合・計算フィールド・パラメータ）

データソース接続後のデータセット設計は、QuickSightでのBIパフォーマンスと分析の柔軟性を左右する重要な工程です。

物理テーブル vs 論理テーブル

QuickSightのデータセットは2層で構成されます。

• 物理テーブル（Physical Table）: データソースから取得する生テーブル・SQLクエリ・S3マニフェストを定義します。1データセットに複数の物理テーブルを含めることができます。
• 論理テーブル（Logical Table）: 物理テーブルに対してJOIN・フィルタ・計算フィールドを適用したビューです。QuickSightの分析・ビジュアルが参照するのは論理テーブルです。

テーブル結合（JOIN）

複数の物理テーブルを結合して1つのデータセットを構成できます。サポートされるJOIN種別:

• Inner Join / Left Join / Right Join / Full Outer Join
• Cross Join（結合条件なし・全件デカルト積）

注意点:
– SPICEモード: JOIN後のデータがSPICEに取り込まれます。多対多JOINでは行数が急増するため、JOINキーのカーディナリティを事前に確認してください。
– DirectQueryモード: JOINはデータソース側に委譲されます。データベース側のJOINパフォーマンスがダッシュボードの応答速度に直結します。インデックス設計が重要です。

計算フィールド（Calculated Fields）

データセット内で集計・文字列・日付操作などの計算を定義できます。代表的な関数を示します。

# 日付差分（日数）
dateDiff({注文日}, {出荷日}, "DD")

# 文字列結合
concat({姓}, " ", {名})

# 条件分岐
ifelse({売上} > 1000000, "大口", ifelse({売上} > 100000, "中口", "小口"))

# NULL補完
ifelse(isNull({売上}), 0, {売上})

# 数値文字列の変換
toNumber({売上文字列})

計算フィールドはデータセットレベルまたは分析（Analysis）レベルのどちらでも定義できます。KPIや共通指標（売上・利益率等）はデータセットレベルで定義し、複数の分析から再利用する構成を推奨します。

フィルタとパラメータ

• データセットレベルフィルタ: 取込対象データを事前絞り込みします。SPICEモードでは絞り込み後のデータのみキャッシュされるため、不要データのSPICE消費を防ぎます。
• パラメータ: ダッシュボードのUI要素（ドロップダウン・スライダー・日付ピッカー）と連動した動的フィルタを構築できます。DirectQueryモードではパラメータ値がSQLのWHERE句に変換されてデータソースに送られます。

階層（Hierarchy）

地理・時間・組織などの階層構造をデータセットに定義しておくと、ビジュアル上でドリルダウン・ドリルアップが可能になります。例: 年→四半期→月→週、国→都道府県→市区町村。BI利用者がセルフサービスで掘り下げ分析できる環境を整えるために有効な機能です。

マルチソース結合とパフォーマンス最適化

異なるデータソースのテーブルを1つのデータセットに結合できます（例: AthenaとRedshiftを結合）。ただし、この場合はSPICEモードが強制されます（DirectQueryはシングルソースのみ対応）。

パフォーマンス最適化のポイント:
– 結合前にデータソース側でフィルタ・集計し、QuickSightが処理するデータ量を削減する
– 高カーディナリティな文字列カラム（ユーザーIDの全レコード等）はデータセットに含めず、集計キーとして使用する場合のみ保持する
– SPICEのデータセット更新タイミングでJOIN処理が走るため、更新頻度が高い場合はデータソース側の読み取り負荷を考慮する

2-3. SPICE vs DirectQuery

【★罠①】SPICE（Super-fast, Parallel, In-memory Calculation Engine）とDirectQueryの使い分けは、QuickSight設計の最重要判断ポイントです。正しく選択しないと、SPICE容量の過大消費や、ダッシュボード操作ごとのデータソース過負荷といった問題が本番環境で顕在化します。

SPICEの仕組み

SPICEはQuickSightのマネージドインメモリエンジンです。データソースからデータを取り込んでキャッシュし、ダッシュボード参照時はSPICEから直接データを返します。データソースへのクエリは更新スケジュール実行時のみ発生するため、ダッシュボードの応答速度が非常に速く、データソースへの負荷も最小限です。

DirectQueryの仕組み

DirectQueryはダッシュボード参照時・フィルタ変更のたびに、データソースに対してSQLクエリを発行します。データは常に最新状態が返りますが、クエリのたびにデータソース（Athena/Redshift/RDS等）に負荷が発生します。

選択基準の比較表

DirectQueryの主要制約（見落とし注意）

1. 列上限2,000: 1データセット最大2,000列です。ワイドテーブル（IoTデバイス属性等）を扱う場合はSPICEが必要です。
2. タイムアウト: ビジュアル生成・サンプルデータ取得で最大2分のタイムアウトが適用されます。さらにデータソース側のクエリタイムアウトも合算されます。Athenaの場合、実行時間の長いクエリはタイムアウトするリスクがあります。
3. 増分更新非対応: DirectQueryはデータをキャッシュしないため、増分更新の概念自体がありません。
4. マルチソースJOIN不可: 異なるデータソースをJOINする場合はSPICEモードが強制されます。

推奨判断フロー

Q1: 常にリアルタイムデータが必要か？
  YES →  Q2: データ規模が小〜中規模（< 数百万行）かつ単純クエリか？
YES → DirectQuery 検討
NO  → データソース側（Athena/Redshift）で事前集計してからSPICE
  NO  →  SPICE（更新スケジュールで鮮度確保）

Q3 (SPICE採用後): 更新頻度は?
  毎時以上必要 → Enterprise edition必須（Hourly更新）
  日次で十分 → Standard / Enterpriseどちらでも対応可

2-4. データセット更新（スケジュール・増分更新）

更新スケジュールの仕様（2026年6月時点）

「N回/日の固定上限値」は公式に定義されていません。5スケジュール × Hourly（Enterprise）= 実質最大24回/日程度が上限の目安です。

増分更新（Incremental Refresh）の前提条件

増分更新は前回更新以降に追加・変更されたデータのみを取り込む機能です。全件更新と比較して処理時間・クエリコストを大幅に削減できます。

⚠️ 前提条件（満たさないと増分更新は選択不可）:

1. Enterprise edition必須: Standard editionでは利用できません。
2. SQLソース限定: Redshift・Athena・PostgreSQL・MySQL・Snowflakeなど、SQLで日付フィルタできるソースが対象です。S3・ファイルアップロード・Amazon OpenSearch・SaaSコネクタは全件更新のみとなります。
3. 日付/タイムスタンプ列必須: データセット内に更新日時を示す列（created_at・updated_at・event_time等）が必要です。QuickSightはこの列をフィルタとして増分データを特定します。
4. Look-backウィンドウ: 増分更新では取りこぼし防止のためにlook-backウィンドウ（前回の更新時点より少し前を重複取込する期間）を設定します。データの遅延が考えられる場合はウィンドウを広めに設定してください。

sub-hourlyスケジュール

Enterprise edition + 増分更新の組み合わせでのみ、15分・30分間隔のsub-hourlyスケジュールが利用できます。ただし、データソース側のクエリ負荷も増加するため、Athenaであればクエリコスト、Redshiftであれば同時実行スロットへの影響を事前に見積もってください。

更新失敗時の通知

データセット更新が失敗した場合、QuickSightは以下の方法でアラートを送信できます。

• SNSトピックへの通知（QuickSight管理コンソール → データセット → 通知設定）
• 管理者メールアドレスへのアラートメール

本番運用では、SNSトピックをCloudWatch AlarmまたはAmazon EventBridgeと連携させ、Slackや PagerDutyへ即時通知する体制を整えることを推奨します。更新失敗を放置するとダッシュボードが古いデータを表示し続けるため、監視体制は必須です。

データ型変換・日付フォーマット注意点

データ取込時に頻発するデータ型の問題を整理します。

• 日付文字列の解析: S3/AthenaからSTRING型で取り込んだ日付文字列は、データセット編集画面で明示的に日付型へ変換する必要があります。フォーマット（例: yyyy-MM-dd HH:mm:ss）を指定しないと、日付フィルタやtime-series visualがエラーになります。
• タイムゾーン: QuickSightのデータセットはUTC基準で保持します。日本時間（JST=UTC+9）で表示するには、計算フィールドでaddDateTime(9, "HH", {タイムスタンプ})を用いてオフセット補正するか、データソース側でJSTに変換してから取り込む方法を検討してください。
• NULL値の扱い: 集計関数（sum/avg等）はNULLを無視します。ビジュアルによっては0として扱う設定が必要な場合は、計算フィールドでifelse(isNull({値}), 0, {値})のようにNULL補完してください。
• 数値文字列の変換: STRING型として取り込まれた数値は、計算フィールドでtoNumber({列名})を使って数値型に変換できます。ただし変換できない値（”N/A”・”—”等）はNULLになるため、NULL補完と組み合わせて使用してください。

3. SPICE 容量設計・Import・増分更新・料金最適化

3-1. SPICEとは（Super-fast Parallel In-memory Calculation Engine）

SPICEは Super-fast, Parallel, In-memory Calculation Engine の略称で、Amazon QuickSightが独自に保有するインメモリデータエンジンです。クエリのたびにデータソースへSQLを発行するDirectQuery（ライブ接続）とは異なり、データをあらかじめ取り込んでメモリ上に保持しておくため、数億行規模のデータでもサブ秒レベルの高速応答を実現します。

SPICEの高速化を支える主な技術的特徴は次のとおりです。

SPICEはリージョン単位かつアカウント単位で容量が割り当てられます。すべてのユーザーとデータセットが容量を共有するため、複数チームが同一アカウントでQuickSightを利用する場合は容量の使い方を計画的に設計することが重要です。

ホームリージョン以外での利用には注意が必要です。 たとえばQuickSightをus-east-1で契約しながら東京（ap-northeast-1）でもSPICEデータセットを作成したい場合、東京リージョンのSPICE容量は別途購入が必要です。ホームリージョンの容量は他リージョンに自動では共有されません。

Edition別の1データセット上限は容量設計の起点となります。

行数とサイズのどちらかを先に超えた時点でインポートが停止します。数億行規模のトランザクションログや行動ログを扱うユースケースでは Enterprise Edition が前提となります。

SPICE保存時暗号化（AWS KMSで管理する保存データ暗号化オプション）は Enterprise Edition 限定 の機能です。Standard Edition では利用できません。PCI DSSやHIPAA等のコンプライアンス要件で保存データ暗号化の証明が必要な場合は、設計の初期段階でEnterprise Editionを選択してください。

3-2. SPICE容量設計と料金（精度の罠②）

料金体系（2026年時点・要最新確認）

【★精度の罠②】SPICEの容量料金は Enterprise版の方がStandard版より高い ことに注意してください。

高機能版（Enterprise）ほど単価は高くなります。「Enterpriseは安い」「StandardよりEnterpriseが割安」という逆方向の誤認が資料やコードコメントに散見されるため、数値の向きを必ず確認してください。

各アカウントには最初から無料のSPICE容量が付与されています。Author（作成者）ライセンスの場合、1ユーザーにつき10 GBが無償で利用できます。たとえばAuthorが3名いれば合計30 GBが無償となり、この範囲内であれば容量の追加費用は発生しません。

SPICE容量のサイジング計算

SPICEが消費する容量はソースファイルのサイズとは異なります。QuickSightはデータをカラム型フォーマットに変換するため、論理的な変換後サイズで見積もります。

データ型ごとのバイト消費の目安は次のとおりです。

概算式は次のとおりです。

必要容量 (GB) ≈ 行数 × Σ(列ごとの推定バイト数) ÷ 1,073,741,824

具体例: 100万行・50列（数値30列、テキスト20列・平均テキスト長50バイト）の場合

数値: 30列 × 12 B/値 = 360 B/行
テキスト: 20列 × (24 B + 50 B) = 1,480 B/行
合計: 100万行 × 1,840 B ÷ 1,073,741,824 ≈ 1.71 GB

Null値の扱いや内部圧縮によりサイズが変動するため、この概算値に 1.5〜2倍の余裕係数 を乗じた値をSPICE購入容量の下限として設定することを推奨します。

容量超過時の対応

SPICE容量が不足したデータセットのインポートは途中で中断され、エラーとなります。対応手段は2つです。

1. 容量の追加購入

QuickSightコンソールの「管理者設定 → SPICEキャパシティ」から追加容量を購入できます。AWS CLIからも実行可能で、購入後数分以内に容量が反映されます。購入単位は1 GBで、Standard: $0.25/月・Enterprise: $0.38/月の追加費用が発生します。不要になれば月単位で解放できます。

2. データセット側の最適化

容量購入を抑えながらSPICEを維持する手段として、データセット側を最適化します。

• フィルタで不要な行を絞り込む（例：3年超のアーカイブレコードを除外）
• 使用しない列を削除してカラム幅を削減
• テキスト列の長さを LEFT() 等で切り詰める
• 精度が不要な浮動小数点を INTEGER に型変換してバイト数を削減

3-3. SPICE Import・スケジュール更新・増分更新（精度の罠②b）

フルインポート（Full Refresh）

データセット全件をSPICEに取り込む最もシンプルな方式です。すべてのEditionとデータソース種別（S3・ファイルアップロード・Redshift・Athena・RDS/Aurora・Snowflake等）で利用できます。

コンソールの「今すぐ更新」ボタンか、次のAWS CLIで手動実行できます。

aws quicksight create-ingestion \
  --data-set-id <DataSetId> \
  --ingestion-id <一意ID> \
  --ingestion-type FULL_REFRESH \
  --aws-account-id <AccountId>

インポートの進捗は describe-ingestion APIで確認できます。完了まで数分〜数十分かかる場合があるため、大規模データセットでは非同期でポーリングする仕組みを組み込むことを推奨します。

スケジュール更新の設定

データセットに最大5件の更新スケジュールを設定できます。更新は予定時刻から 10分以内 に開始されることが保証されます（正確な開始時刻ではなくウィンドウ保証）。複数スケジュールを組み合わせることで「月曜は日次、月末は週次」といった柔軟な更新頻度の設計が可能です。

Edition別の最短更新間隔に注意してください。

Standard EditionではHourly更新は選択できません。「準リアルタイムにSPICEを更新したい」要件ではEnterprise Editionが前提となります。

増分更新（Incremental Refresh）【Enterprise + SQLソース限定】

【★精度の罠②b】増分更新は Enterprise Edition 限定 であり、かつ SQLデータソース（Redshift・Athena・PostgreSQL・Snowflake等）に限定 されます。S3・ファイルアップロード等のファイルベースのデータソースでは増分更新を利用できません。

増分更新の設定では「更新ウィンドウ（look-back window）」を指定します。「どの期間の差分を取り込むか」を表す期間で、直近の数分・数時間・数日のレコードだけを効率よくインポートします。

look-back windowの設定例（Redshiftの場合）

データセットのSQLクエリに次のシステム変数を利用します。

SELECT * FROM sales_transactions
WHERE updated_at >= ${incremental_window_start_time}
  AND updated_at < ${incremental_window_end_time}

${incremental_window_start_time} と ${incremental_window_end_time} はQuickSightが自動計算・代入するシステム変数です。増分更新のたびに前回実行時刻から現在時刻の範囲が自動的に設定されるため、アプリケーション側で日時を管理する必要はありません。

増分更新が適するユースケース

• IoTセンサーデータ（数億行/日のAppend-Onlyテーブル）
• 日次売上トランザクション（当日分のみ追記されるパターン）
• ログテーブル（過去データの変更が発生しない追記型データ）

更新・削除（UPDATE/DELETE）が頻繁に発生するテーブルには増分更新は適しません。その場合はフル更新を選択するか、ソース側でMERGE/UPSERTを整理したビューを経由する設計を検討してください。

sub-hourly更新（15分・30分間隔）

Enterprise Editionの増分更新では、15分・30分間隔のsub-hourlyスケジュールも設定可能です。これにより「ほぼリアルタイム」に近い更新頻度を実現できます。ただし更新頻度が高いほどRedshift・Athena側のクエリコストも増加します。コストと鮮度のバランスを考慮した上でスケジュールを設計してください。

3-4. SPICE容量管理のベストプラクティス

未使用データセットの定期削除

一度だけ使ったテスト用データセットや、ダッシュボードから参照されなくなったデータセットはSPICE容量を無駄に消費し続けます。QuickSightコンソールの「データセット」一覧で各データセットのSPICE使用量を確認し、不要なものを定期的に削除することが最もシンプルかつ直接的なコスト削減手段です。

推奨サイクルは月次または四半期ごとです。list-data-sets APIで全データセットを一覧化し、参照ダッシュボードが0件のものを棚卸し対象として削除承認フローを通すことを推奨します。

容量使用量のモニタリング

QuickSightのSPICE使用量はCloudWatchのネイティブメトリクスとしては公開されていません（2026年時点）。データセット単位のSPICEサイズは describe-data-set APIのレスポンスに含まれる ConsumedSpiceCapacityInBytes フィールドで取得できます。

Lambda＋EventBridge Schedulerで定期的にこのAPIを呼び出し、結果をCloudWatch Custom Metricsへ送信し、閾値超過時にSNSで通知するカスタムモニタリングを構築することを推奨します。これにより「気づいたときには容量超過」という事態を防止できます。

SPICE vs DirectQuery のコスト選択

データセットをSPICEで保持するかDirectQuery（ライブ接続）にするかは、パフォーマンスだけでなくコスト面からも判断します。

全社員向けの日報BIでAthenaをDirectQuery接続すると、参照のたびにフルスキャンが走ります。表示コストが急増し、課金リスクを招きます。SPICEで一度取り込めばその後のビジュアル参照はAthenaスキャン費用ゼロになるため、高頻度アクセスシナリオではSPICEが有利です。

マルチテナント構成でのコスト配賦

複数の事業部門でQuickSightを共有する場合、部門別のSPICE使用量を把握してコストを按分する仕組みが必要です。データセット名にプレフィックス（例：sales_, marketing_, ops_）を付与する命名規則を定め、定期的にAPIでデータセット一覧を取得しSPICEサイズを集計するレポートを自動生成することで、内部チャージバックを実現できます。

4. RLS/CLS：行レベル・列レベルセキュリティの設計と運用

4-1. マルチテナント/部門別アクセス制御の要件

マルチテナント SaaS や部門間でダッシュボードを共有する場合、「同一のダッシュボードを使いながら、ユーザーごとに見えるデータを絞り込む」というBI特有の要件が生じます。テナント/部門ごとに別々のデータセット・ダッシュボードを作成する方法もありますが、管理コストが指数関数的に増大します。

QuickSight ではこの課題を RLS（Row-Level Security）と CLS（Column-Level Security） の2層で解決します。

Enterprise edition 必須（重要）: RLS・CLS はいずれも Enterprise edition でのみ利用可能です。Standard edition では設定画面自体が表示されません。本節全体を通じ、RLS/CLS の利用は Enterprise 前提として読み進めてください。

BI アクセス制御の設計原則:

1. 最小権限の原則: データが参照できる範囲を必要最小限に留める
2. データセット単位での制御: ダッシュボード単位ではなくデータセット単位で RLS/CLS を設定し、再利用性を確保
3. グループ活用: ユーザー単位よりグループ単位でルールを管理し、メンテナンスコストを削減
4. テスト環境での事前検証: 本番適用前に専用テストユーザーでフィルタリング挙動を必ず確認する

4-2. RLS（行レベルセキュリティ）

RLS の仕組み

RLS は ルールセット（rules dataset） と呼ばれる専用データセットを使って行フィルタリングを実現します。ルールセットには以下の2種類の列が必要です。

ルールセットの例（CSV イメージ）:

UserName,region,department
alice,ap-northeast-1,sales
bob,us-east-1,engineering
carol,,sales

上記の場合、alice は region=ap-northeast-1 かつ department=sales のレコードのみが見え、carol は region を空値にしているため全リージョンの sales データが参照できます（空値 = 制限なし）。

テキスト列限定という重要制約

RLS でフィルタリングできるのはテキスト型（string/char/varchar）の列のみです。数値列・日付列は直接 RLS フィルター対象にできません。数値や日付で行を絞り込みたい場合は、テキスト型のラベル列（例: "sales_region": "JP" のような VARCHAR 列）を事前に作成し、そのテキスト列を RLS の対象にする設計が必要です。

この制約は、データセット設計の段階から RLS を考慮した列設計をしておくことが重要である理由の一つです。

2025-03-31 以降の新方式：rules dataset 明示フラグ

2025年3月31日以降、rules dataset の作成方法に変更が加わりました。新方式では rules dataset であることを明示的に示すフラグが必要です。

• API: CreateDataSet で UseAs: "RLS_RULES" パラメータを指定
• コンソール: データセット作成時に「NEW RULES DATASET」オプションを選択

旧方式（フラグなし）で作成した rules dataset と新方式のものが混在するアカウントでは、意図しない挙動を招く可能性があります。2025-03-31 以降に作成するルールセットは必ず新方式（明示フラグあり）で作成してください。

また、rules dataset として設定した後は データセットの種類（通常 → ルールセット）の変更はできません。誤った設定をした場合は、新しいデータセットを作り直す必要があります。

RLS の設定手順

Step 1: ルールセット（rules dataset）の作成

1. QuickSight コンソール → [データセット] → [新しいデータセット]
2. ルールを格納したソース（S3 CSV / Athena / Redshift 等）を接続
3. データセット作成時に「NEW RULES DATASET」を選択（2025-03-31 以降）
4. UserName 列または GroupName 列、および各制限フィールド列を確認

Step 2: 対象データセットへの RLS 適用

1. QuickSight コンソール → [データセット] → [対象データセット] → 編集
2. [行レベルのセキュリティ] セクション → ルールセットデータセットを選択
3. ルールセットの列と対象データセットの列をマッピング
4. [保存して公開]

Step 3: 検証

1. テスト用 QuickSight ユーザーでログイン
2. 当該データセットを使ったビジュアルを作成・確認
3. フィルタリングが正しく効いているか（他ユーザーのデータが見えていないか）を確認
4. ルール未設定ユーザーはデフォルトで全件閲覧可能なことに注意

RLS の主な制限事項

4-3. CLS（列レベルセキュリティ）

CLS の仕組み

CLS（Column-Level Security）は、データセット内の特定の列（カラム）へのアクセスをユーザー/グループ単位で制限する機能です。RLS が「見えるレコード（行）」を制限するのに対して、CLS は「見えるフィールド（列）」を制限します。

Enterprise edition 必須: CLS も RLS 同様、Enterprise edition のみ利用可能です。

主なユースケース:

CLS の設定手順

Step 1: 列権限の定義

1. QuickSight コンソール → [データセット] → [対象データセット] → 編集
2. [列レベルのセキュリティ] セクションを展開
3. 制限したい列を選択
4. アクセスを許可するユーザー/グループを指定（ホワイトリスト方式）

Step 2: データセットへの適用

1. [保存して公開] をクリック
2. 指定した列は、権限を持たないユーザーからは見えなくなる

Step 3: 検証

1. 権限を持たないテストユーザーでログイン
2. 当該データセットを使ったビジュアルを作成しようとする
3. 制限列が選択肢に表示されないこと、または含むビジュアルが表示できないことを確認

CLS 適用時の挙動

• 制限列を含む visual は、権限のないユーザーには作成・閲覧ともに不可
• 制限列が含まれるダッシュボードを共有された場合、権限のないユーザーはそのビジュアル自体が見えない（エラー表示になる場合あり）
• CLS と RLS を同一データセットに同時適用することが可能（2層セキュリティ）

4-4. タグベースRLS（匿名埋め込み用）

タグベース RLS とは

通常の RLS は QuickSight の登録ユーザー/グループを識別子として行をフィルタリングします。しかし匿名埋め込み（Anonymous embedding）では、QuickSight にユーザーアカウントを作成せずにダッシュボードを表示するため、通常の RLS（UserName/GroupName ベース）は使えません。

この課題を解決するのが タグベース RLS（Tag-based RLS） です。バックエンドサーバーが埋め込み URL を生成する際に セッションタグ（SessionTags） を付与し、そのタグ値に基づいてデータを動的にフィルタリングします。

タグベース RLS は匿名埋め込み専用です。登録ユーザー埋め込みではセッションタグによる行制御は利用できません。

タグベース RLS の仕組み

[エンドユーザーのブラウザ]
 ↓ ダッシュボード表示リクエスト
[アプリケーションサーバー（バックエンド）]
 ↓ IAM 認証
[QuickSight API: GenerateEmbedUrlForAnonymousUser]
 SessionTags: [{ Key: "tenant_id", Value: "tenant_A" }]
 Namespace: "default"
 ↓ 埋め込み URL（5分有効・1回限り）
[QuickSight]
 ← タグ値 tenant_id=tenant_A で行フィルタリング
 ← フィルタリングされたダッシュボードを表示

タグベース RLS の設定手順

Step 1: ルールセットの作成（タグ列を使用）

タグベース RLS では、ルールセット内でタグキーをフィルター列として定義します。QuickSight コンソールのタグ RLS 設定画面でタグキーと対象データセット列のマッピングを行います。

Step 2: API で埋め込み URL 生成時に SessionTags を付与

import boto3

client = boto3.client('quicksight', region_name='ap-northeast-1')

response = client.generate_embed_url_for_anonymous_user(
 AwsAccountId='123456789012',
 Namespace='default',
 AuthorizedResourceArns=[
  'arn:aws:quicksight:ap-northeast-1:123456789012:dashboard/my-dashboard'
 ],
 ExperienceConfiguration={
  'Dashboard': {
'InitialDashboardId': 'my-dashboard'
  }
 },
 SessionTags=[
  {
'Key': 'tenant_id',
'Value': 'tenant_A'  # バックエンドで動的に設定
  }
 ]
)

embed_url = response['EmbedUrl']

Step 3: フロントエンドで埋め込み URL を使用

import { createEmbeddingContext } from 'amazon-quicksight-embedding-sdk';

const embeddingContext = await createEmbeddingContext();
const embeddedDashboard = await embeddingContext.embedDashboard({
 url: embedUrl,  // バックエンドから取得した URL
 container: document.getElementById('dashboard-container'),
});

タグベース RLS の注意事項

4-5. RLS + CLS 組み合わせ設計のベストプラクティス

RLS と CLS は同一データセットに重ねて適用できます。本番環境では以下の組み合わせが有効です。

推奨パターン: 部門 × 機密列の2層制御

データセット: sales_data
  ← RLS: sales_region='JP' のみ見えるユーザー alice
  ← CLS: salary 列は HR グループのみ参照可

結果: alice が JP の売上データを見ると
  → RLS で JP 以外の行は非表示
  → alice が HR グループ外なら salary 列も非表示

設計チェックリスト:

1. データセット設計段階で RLS に使うフィルタ列をテキスト型で用意する
2. ルールセットデータセットは 2025-03-31 以降の新方式（明示フラグ）で作成
3. ルール未設定ユーザーの扱いを事前決定（デフォルト全件公開に注意）
4. CLS で制限する列を含むビジュアルを持つダッシュボードは共有先を制限
5. タグベース RLS を使う場合はバックエンドの認証フローとセッションキャパシティプランを整備
6. 変更管理: ルールセット内容の変更は rules dataset を更新し再インポートが必要

5. 埋め込み分析：匿名埋め込み・登録ユーザー埋め込み・SDK

5-1. 埋め込み分析のユースケース

QuickSightの埋め込み分析は、作成したダッシュボードや分析を 外部アプリケーションに直接組み込む 機能です。典型的なシナリオは次の2パターンに大別されます。

パターンA: SaaS プロダクトへの組み込み
マルチテナント SaaS では、テナントごとに異なるデータを見せる必要がある。自社で BI エンジンを構築する代わりに QuickSight ダッシュボードを各テナントのポータルに埋め込めば、BI 開発コストを大幅に削減できる。この場合、テナント識別子をセッションタグとして渡してタグ RLS（§4-4 参照）で行フィルタリングするため、匿名埋め込み が主な選択肢になる。

パターンB: 社内ポータルへの統合
既存の社内イントラや業務システムに QuickSight ダッシュボードを統合するケース。社員は IAM または IdP（Okta/AzureAD 等）で認証済みのため、QuickSight ユーザーとして登録された上で 登録ユーザー埋め込み を利用する。人事・財務・営業の各部門ポータルに専用ダッシュボードを組み込む構成が典型例です。

どちらのパターンも、ダッシュボードは QuickSight コンソール上で通常どおり作成・管理し、表示のみを外部アプリに委ねる。QuickSight 側のビジュアルやデータ更新は埋め込み先アプリを変更せずに反映される点が大きなメリットです。

5-2. 登録ユーザー埋め込み vs 匿名埋め込み

2つの埋め込みモードは料金体系・認証フロー・API・制限が根本的に異なる。先に全体像を比較する。

登録ユーザー埋め込みの詳細

QuickSight ユーザーとして CreateUser API またはコンソールで事前登録（プロビジョニング）が必要。SAML/OIDC フェデレーションで IdP ユーザーを QuickSight ユーザーに自動マッピングする構成が多い。料金は登録された QuickSight ユーザー単位の月額サブスクリプション（Reader $3/月 等）が発生する。ダッシュボードへのアクセス権は QuickSight の共有設定で制御するため、タグベース RLS は使えない。

import boto3

qs = boto3.client('quicksight', region_name='ap-northeast-1')

response = qs.generate_embed_url_for_registered_user(
 AwsAccountId='123456789012',
 UserArn='arn:aws:quicksight:ap-northeast-1:123456789012:user/default/john@example.com',
 ExperienceConfiguration={
  'Dashboard': {
'InitialDashboardId': 'dashboard-xxxx'
  }
 },
 AllowedDomains=['https://portal.example.com'],
 SessionLifetimeInMinutes=60
)
embed_url = response['EmbedUrl']

匿名埋め込みの詳細

QuickSight へのユーザー登録不要。アプリ側で認証した外部ユーザーに対して、バックエンドがセッションごとに埋め込み URL を生成して渡す。マルチテナント SaaS ではテナント ID をセッションタグとして付与すれば、タグ RLS がそのタグに対応した行のみを返す（§4-4 参照）。session capacity pricing を有効化していないと UnsupportedPricingPlanException が返るため、AWS コンソールの QuickSight 管理ページで「キャパシティ料金」を先に設定すること。

response = qs.generate_embed_url_for_anonymous_user(
 AwsAccountId='123456789012',
 Namespace='default',
 AuthorizedResourceArns=[
  'arn:aws:quicksight:ap-northeast-1:123456789012:dashboard/dashboard-xxxx'
 ],
 ExperienceConfiguration={
  'Dashboard': {
'InitialDashboardId': 'dashboard-xxxx'
  }
 },
 SessionTags=[
  {'Key': 'tenant_id', 'Value': 'tenant-abc'}
 ],
 AllowedDomains=['https://app.example.com'],
 SessionLifetimeInMinutes=60
)
embed_url = response['EmbedUrl']

5-3. 埋め込みURL生成と JS SDK

認証フロー: AWS STS → IAM Role → embed URL

embed URL 生成は IAM 権限を持つバックエンドが担う。外部ユーザーに QuickSight の IAM 権限を直接付与してはならない。フローは以下のとおり。

[外部ユーザー] → [アプリバックエンド]
  ↓
[アプリバックエンド]
  1. STS AssumeRole（QuickSight へのアクセス権を持つ IAM ロール）
  2. qs.generate_embed_url_for_anonymous_user() / ...for_registered_user()
  3. embed URL をレスポンスで返却
  ↓
[フロントエンド]
  4. embed URL を JS SDK へ渡してダッシュボードを描画

匿名埋め込みで IdP（Cognito 等）のユーザーを使う場合は AssumeRoleWithWebIdentity を使って JWT から IAM ロールを引き受け、その認証情報で QuickSight API を呼ぶパターンが一般的です。

JavaScript Embedding SDK（2.0 系）

iframe に直接 embed URL を設定する方法は旧来の手法であり、現在は amazon-quicksight-embedding-sdk（v2.0 系） の使用が推奨されている。SDK を使う理由は主に2点ある。①パラメータ（フィルター・テーマ・ビジュアル表示制御等）をプログラムで後から変更できる。②コールバック（ダッシュボードのロード完了・エラー等のイベント）を取得できる。

npm install amazon-quicksight-embedding-sdk

import { createEmbeddingContext } from 'amazon-quicksight-embedding-sdk';

async function embedDashboard(containerDiv, embedUrl) {
  const embeddingContext = await createEmbeddingContext({
 onChange: (changeEvent) => {
console.log('Context changed:', changeEvent);
 }
  });

  const dashboard = await embeddingContext.embedDashboard({
 url: embedUrl,
 container: containerDiv,
 height: '700px',
 width: '100%',
 onChange: (changeEvent) => {
if (changeEvent.eventName === 'FRAME_LOADED') {
  console.log('Dashboard loaded');
}
 }
  });

  // ダッシュボードロード後にフィルターを動的にセット
  await dashboard.setParameters([
 { Name: 'region', Values: ['ap-northeast-1'] }
  ]);
}

React / Next.js への統合パターン

// components/QuickSightDashboard.tsx (Next.js App Router)
'use client';

import { useEffect, useRef } from 'react';
import { createEmbeddingContext } from 'amazon-quicksight-embedding-sdk';

export default function QuickSightDashboard({ tenantId }) {
  const containerRef = useRef(null);

  useEffect(() => {
 async function load() {
// バックエンドから embed URL を取得（毎回生成）
const res = await fetch(`/api/quicksight-embed?tenant=${tenantId}`);
const { embedUrl } = await res.json();

const ctx = await createEmbeddingContext();
await ctx.embedDashboard({
  url: embedUrl,
  container: containerRef.current,
  height: '600px',
  width: '100%'
});
 }
 if (containerRef.current) load();
  }, [tenantId]);

  return <div ref={containerRef} />;
}

Next.js のサーバーコンポーネント（API Route / Route Handler）でバックエンド処理（IAM ロール取得 → embed URL 生成）を行い、クライアントコンポーネントへ URL を渡す構成が推奨です。AWS SDK は クライアントサイドに公開しないこと。

Vue 3 / Nuxt での統合

Vue では onMounted フック内で SDK を初期化する。Nuxt の場合はクライアントサイドのみで実行する（process.client ガードまたは ラッパーを使用）。iframe の src を直接バインドする実装はなるべく避け、SDK の createEmbeddingContext 経由で描画すること。

5-4. 運用上の考慮（料金・認証・ドメイン）

セッションキャパシティ料金（匿名埋め込み）

匿名埋め込みのコストは セッションキャパシティ課金。1セッション = 30分単位でカウントされ、例えば 500 セッション/月 ≈ $250/月（2026年時点の参考値・変動あり）。利用量が読めない初期は AWS Cost Explorer でセッション数をモニタリングしながら段階的に拡大するのが安全です。登録ユーザー埋め込みは per-user のサブスクリプション料金（Reader $3/月 等）なのでコスト予測が立てやすい。アクセス頻度が低い社内ユーザー向けは登録ユーザー埋め込み、不特定多数の外部ユーザー向けは匿名埋め込み + セッションキャパシティ、という使い分けが基本になる。

AllowedDomains（オリジン許可リスト）

AllowedDomains パラメータで embed URL を表示できるドメインを明示的に制限する。1回の API コールで指定できる上限は 最大3ドメイン。ステージング・本番・管理ポータルのように3環境が必要な場合は、環境ごとに embed URL 生成 API を分けるか、バックエンドで動的に組み合わせる設計にする。AllowedDomains を指定しない場合は任意のドメインで表示可能になるため、本番環境では必ず設定すること。

HTTPS 必須とオリジン検証

embed URL を組み込む親ページは HTTPS が必須。HTTP ページへの埋め込みはブラウザの Mixed Content ポリシーによりブロックされる。ローカル開発環境では http://localhost を AllowedDomains に追加すれば動作するが、ステージング以上は必ず HTTPS ドメインを使うこと。

トークン管理のポイント

公式ドキュメント: Amazon QuickSight 埋め込み分析

6. Amazon Q in QuickSight：生成BI・自然言語分析

6-1. 生成BIとは（Amazon Q in QuickSight の全体像）

Amazon Q in QuickSight は、生成 AI 技術を BI ダッシュボードへ統合した機能群の総称です。SQL や分析の専門知識がなくても、自然言語で質問するだけでグラフ・サマリー・ナラティブが自動生成されます。2025 年以降、AWS は QuickSight の AI 機能を「生成 BI（Generative BI）」として積極的に拡張しています。

★ 東京リージョン（ap-northeast-1）の対応状況

Amazon Q in QuickSight（Scenarios 含む）は 東京リージョン（ap-northeast-1）で正式 GA・healthy です。AWS 公式リージョン表では Tokyo = Scenarios ✓ が確認されており、2025 年 7 月の What’s New でも東京追加が明記されています。日本 Geography での Cross-Region 推論は Tokyo + Osaka 内で完結し、追加料金は発生しません。

なお、以下のリージョンでは現時点（2026 年 6 月）で Amazon Q in QuickSight が 未提供です：

マルチリージョン構成の場合、Q 機能を利用するユーザーは対応リージョンに QuickSight アカウントを持つ必要があります。

★ Edition 前提と Q Pro ライセンス

Amazon Q in QuickSight の生成 AI 機能はすべて Enterprise edition が必須 です。Standard edition では利用できません。さらに Q Pro ライセンス（Reader Pro または Author Pro）が別途必要です。

容量課金（Capacity Pricing）も選択可能で、500 質問パック ≈ $250/月 が目安です（2026 年時点の参考額。公開直前に AWS 公式料金ページで必ず確認してください）。

機能群の概要マップ

★ 日本語自然言語クエリについての注意（重要）

QuickSight のコンソール・ダッシュボード UI は日本語対応していますが、Ask Q・Generative Q&A への日本語入力は English-first でリリースされており、日本語クエリの精度・正式対応は公式に保証されていません。

現時点では英語でのクエリ入力を推奨します。日本語 NL クエリの正式対応状況は、AWS 公式ドキュメントの最新版（amazon-quicksight-user-guide）を随時確認してください。

6-2. Q Topics の設計

Q Topics は、Amazon Q in QuickSight が自然言語を正しく理解するための セマンティック層（意味的メタデータ層） です。データセットのフィールドにビジネス語彙（同義語）・集計ルール・フィルターを付与することで、NL クエリの精度を大幅に向上させます。Q Topics は Enterprise edition 専用です。

Q Topics の構造

Q Topic
  ├── データセット（最大 25 個）
  └── フィールド設定（列ごと）
  ├── Friendly name（ビジネス用語に合わせた表示名）
  ├── Description（フィールドの説明文）
  ├── Synonyms（同義語リスト）
  ├── Semantic type（Date/Location/Person/Organization 等）
  ├── Aggregation（SUM/AVG/COUNT/MIN/MAX のデフォルト）
  ├── Filter（常時適用するデフォルトフィルター）
  └── Visibility（Included/Excluded）

Q Topics 作成手順（コンソール）

1. QuickSight コンソール左メニューで [Topics] を選択
2. [New topic] → トピック名・説明を入力して作成
3. [Add dataset] で対象データセットを紐付け
4. フィールド一覧から各フィールドを設定：
5. Friendly name: 「revenue」→「売上」、「cust_id」→「顧客 ID」
6. Synonyms: 「売上」→ sales, revenue, 売上高, 売上金額
7. Aggregation: 金額フィールドは SUM、評価スコアは AVG
8. Filter: 「status = ‘active’」をデフォルト条件として設定
9. 分析に不要なシステムフィールド（内部 ID・更新日時等）は [Excluded] に設定
10. [Publish topic] で公開 → Reader Pro ユーザーが Ask Q 経由でアクセス可能になる

精度向上のベストプラクティス

Q Topics の制約と注意点

• RLS（行レベルセキュリティ）は Q Topics 経由でも適用される。ユーザーが見えないデータは Q も返さない
• 1 つの Q Topics に紐付けられるデータセットは最大 25 個（目安）
• Q Topics の設定変更はリアルタイムで反映。ただし SPICE データ自体の鮮度はスケジュール更新に依存
• 複数の Q Topics を作成し、部門・用途別に使い分けることが可能（例：「営業用」「マーケ用」）

6-3. 自然言語クエリ（Ask Q）と Generative Q&A

Ask Q は、QuickSight ダッシュボードに配置できる自然言語 Q&A バーです。ビジネスユーザーが質問を入力すると、Q Topics のセマンティック情報を参照して最適なビジュアルを即座に生成します。

Ask Q の利用フロー

1. Author Pro が Q Topics を作成・公開
2. ダッシュボードに Q bar ウィジェット をドラッグ＆ドロップで追加
3. Reader Pro ユーザーがダッシュボードを開き、Q バーに質問を入力
4. QuickSight が Q Topics を参照し、フィールド・集計・フィルターを自動判定
5. グラフ（棒・折れ線・ポイント・ピボット等）が即座に生成
6. ユーザーはビジュアルを固定・共有・エクスポートできる

クエリ例（英語入力を推奨）

"Show me monthly sales by product category for 2025"
"What are the top 10 customers by revenue last quarter?"
"Compare monthly orders between 2024 and 2025 in Japan region"
"Which products had a sales decline greater than 20% this year?"

Generative Q&A

Generative Q&A は Ask Q の発展型で、グラフ生成に加えて AI による解説テキスト（ナラティブ） をセットで提供します。

埋め込み（Embedded）環境での Ask Q

Q バーは埋め込みダッシュボードでも統合可能です。

// amazon-quicksight-embedding-sdk 2.0 系
const embeddingContext = await createEmbeddingContext();
const embeddedDashboard = await embeddingContext.embedDashboard({
  url: embedUrl,
  container: document.getElementById("dashboard-container"),
  options: {
 questionBar: {
enabled: true,
initialTopicId: "TOPIC_ID",
 },
  },
});

埋め込みで Q バーを利用するユーザーにも Reader Pro ライセンスと Q Topics の閲覧権限 が必要です。

Ask Q が理解できない場合のフォールバック

• QuickSight が質問の意図を解析できない場合、候補フィールドや集計タイプの選択肢を提示
• Q Topics の同義語・説明が不足している場合に多発 → Quality Review で改善
• 時系列・地理情報を含むクエリは Semantic type（Date/Location）の設定が特に重要

6-4. Executive Summaries / データストーリー

Executive Summaries は、ダッシュボードの KPI やチャートを AI が自動解析し、ビジネス言語でのサマリーテキストを生成する機能です。週次経営レポートやステークホルダー向け報告資料の自動化に活用できます。

Executive Summaries の動作フロー

1. Author がダッシュボードに [Summaries] ウィジェット を追加（右パネルから挿入）
2. QuickSight が対象ビジュアルの KPI・チャート値を解析
3. トレンド変化・外れ値・ランキング・前期比を自動検出
4. 「先月の売上は前月比 +12%、特に東日本地区が好調」等のナラティブを生成
5. SPICE 更新のたびにサマリーが自動再生成される（手動更新不要）

Data Stories

Data Stories は「テーマ（問い）」を入力すると、関連ビジュアルを自動選択してスライド形式のナラティブを組み立てる機能です。

操作例:
[Build a story] → テーマ入力:
  "2025年の四半期別売上推移を日本市場に絞って分析して"
  ↓
QuickSight が Q Topics・ダッシュボードビジュアルを参照
  ↓
スライド形式のデータストーリー（グラフ＋解説テキスト）を自動生成
  ↓
PDF エクスポート・ダッシュボードへの埋め込みが可能

Scenarios（What-If 分析）

Scenarios 機能では、目標値を入力すると達成に必要なシナリオを AI が自動提示します。

• 例：「来期の売上目標を前期比 20% 増に設定した場合、どの施策が有効か？」
• パラメータを変更した場合の指標変化をシミュレーション
• 東京リージョン（ap-northeast-1）で GA 済み（2025 年 7 月以降）

ロール別 Amazon Q 機能アクセス早見表

※ すべての行で Enterprise edition が前提です。Standard edition では上表の全機能が利用不可です。

7. ダッシュボード運用：バージョン管理・テーマ・アラート・スケジュールレポート

7-1. 分析とダッシュボードの分離・公開フロー

QuickSight では「分析（Analysis）」と「ダッシュボード（Dashboard）」が概念として明確に分離されている。分析はデータを可視化・探索する編集可能なワークスペースであり、Author ロール以上が操作できる。一方、ダッシュボードは分析を「公開」した読み取り専用のスナップショットで、Reader を含む幅広いユーザーへの配信に用いる。

この分離により、データ担当者が分析を改修している最中も、消費者（Consumer）ユーザーは安定したダッシュボードを閲覧し続けられます。意図しない変更が本番表示に即時反映されることがない設計です。

公開フロー

1. 分析画面右上の「公開」ボタンをクリックし、ダッシュボード名を指定する。
2. QuickSight は自動的にバージョン番号（V1, V2, …）を付与し、公開した時点の状態をスナップショットとして保存する。
3. 以降、分析に変更を加えて再公開するたびに新しいバージョンが積み上がる。

バージョン管理とロールバック

ロールバックは管理者または所有者ロールが実行でき、API（UpdateDashboard + UpdateDashboardPublishedVersion）でも同等操作が可能です。IaC 管理では CloudFormation / CDK を利用したダッシュボード定義の外部管理も選択肢になります。

共有設定

公開したダッシュボードは「共有」設定で閲覧者を制御する。

• 個別ユーザー/グループ指定: 招待メールで QuickSight ユーザーを追加
• URL シェア: 「リンクを許可」を有効化すると、QuickSight アカウント内の全ユーザーが URL でアクセス可能
• 読み取り専用: ダッシュボード消費者（Reader）は閲覧のみ。フィルタ操作は許可できるが、ビジュアル編集は不可

埋め込み配信（§5 参照）では共有設定とは別に API レベルのアクセス制御を行う。複数の共有チャネルを組み合わせる場合は、RLS（§4 参照）によるデータアクセス制御が共有設定に優先されることを念頭に置くこと。

7-2. テーマとブランディング

QuickSight のテーマ機能を使うと、カラーパレット・フォント・ウィジェットのスタイルを一括管理し、組織全体のダッシュボードにブランドの統一感を持たせることができる。

組み込みテーマ

QuickSight にはデフォルトテーマとして以下が提供されている。

カスタムテーマの作成

1. 管理コンソール → 「テーマ」→「テーマを作成」
2. 設定可能な要素:
3. カラーパレット: プライマリカラー（最大 8 色のデータカラー）・セカンダリカラー・背景色
4. フォント: Noto Sans / Open Sans 等から選択（日本語表示は Noto Sans 推奨）
5. ボーダー: タイル境界線の有無・角の丸み
6. タイル: 背景の透過・パディング
7. JSON 定義のエクスポートが可能。CreateTheme API でプログラマティックに管理できる。

# カスタムテーマの作成例（AWS CLI）
aws quicksight create-theme \
  --aws-account-id 123456789012 \
  --theme-id "corporate-brand-v1" \
  --name "Corporate Brand v1" \
  --base-theme-id "CLASSIC" \
  --configuration '{
 "UIColorPalette": {
"PrimaryForeground": "#FFFFFF",
"PrimaryBackground": "#0033A0",
"SecondaryForeground": "#333333",
"SecondaryBackground": "#F5F5F5",
"Accent": "#FF6600",
"AccentForeground": "#FFFFFF"
 },
 "DataColorPalette": {
"Colors": ["#0033A0","#FF6600","#00A3E0","#78BE20","#FFC72C","#DA291C","#6F2DA8","#009A44"]
 }
  }'

テーマの共有と適用

• 個人テーマ: 作成者のみ使用可能
• 共有テーマ: 特定ユーザー/グループ、または組織全体に共有
• ダッシュボード単位でテーマを切り替え可能。組織展開では管理者が共有テーマを作成し、各 Author にデフォルト適用を促すオペレーションが標準的です。
• テーマ変更は公開済みのダッシュボードにも即時反映されるため、本番適用前にステージング環境で確認すること

7-3. 閾値アラート

⚠️ Enterprise Edition 必須
閾値アラートは Enterprise edition のみ利用可能。Standard edition では設定メニュー自体が表示されない。

機能概要

閾値アラートは、KPI やゲージなどのビジュアルが指定した閾値を超えたとき（または下回ったとき）に、メールで通知を送る機能です。BI 運用における異常検知の自動化に役立ち、担当者が毎日ダッシュボードを目視する手間を削減します。

重要: アラート評価のタイミング
アラートはリアルタイムには動作しない。SPICE データセットの更新が成功したタイミングで評価される。したがって、アラートの粒度はデータ更新頻度（最短 Hourly = Enterprise 限定）に依存する。更新間隔が長いほどアラート検知が遅れることに注意。

対応するビジュアルタイプ

また、DirectQuery データセットはアラート非対応。SPICE データセットにインポートされている列を対象にすること。

設定手順

1. ダッシュボードで対象の KPI ビジュアルを開く（分析ではなくダッシュボード画面で操作）
2. ビジュアル右上の「⋯」→「アラートを作成」
3. 以下を設定する:

1. 「保存」でアラートが有効化される。

アラートの管理

• ダッシュボード右上「⋯」→「アラートの管理」から一覧表示・編集・削除が可能
• 1 つのビジュアルに複数のアラートを設定可能（例: 警告 80% / 危険 95%）
• アラートが発火すると設定したメールアドレスに通知メールが届く
• 管理者は組織内の全アラートを「管理」画面で一元管理できる

設計上の注意点

• SPICE データセットの更新スケジュールを先に決定してからアラート閾値を設計する
• 閾値が頻繁に超過する場合、通知の洪水（アラートノイズ）が発生する。適切な閾値バッファを設けること
• RLS が適用されたデータセットでは、アラートは異常検知（Anomaly Detection）非対応。RLS 対象のダッシュボードにアラートを設定する場合は、KPI ビジュアルが RLS フィルタの影響を受ける点を考慮する

7-4. スケジュールレポートとスナップショット

⚠️ Enterprise Edition 必須
スケジュールレポートは Enterprise edition のみ利用可能。

機能概要

スケジュールレポートは、ダッシュボードを定期的に PDF 形式でメール送信する機能です。週次の KPI レポートや月次の経営報告書など、「決まったタイミングでデータを届ける」シナリオを QuickSight 内で完結させます。

スケジュールの設定手順

1. 対象ダッシュボードを開く
2. 設定メニュー「⋯」→「レポートをスケジュール」を選択
3. 以下を設定する:

受信者制限（重要）
受信者として指定できるのは、そのダッシュボードがすでに共有済みのユーザー/グループのみ。未共有ユーザーをリストに追加しても配信されない。先にダッシュボード共有設定を行うこと。

RLS 対応スナップショット

スケジュールレポートは RLS（行レベルセキュリティ）を考慮したスナップショットを生成する。受信者それぞれが自分のアクセス権限内のデータのみが表示された PDF を受け取る。たとえば、東日本チームには東日本のデータだけが表示される PDF が、西日本チームには西日本のデータだけが表示される PDF が個別に生成・配信される。大量の受信者に RLS 対応 PDF を配信する場合は処理時間が増加する点に注意。

スナップショット API（StartDashboardSnapshotJob）

プログラマティックにスナップショットを生成する場合は StartDashboardSnapshotJob API を使用する。

# スナップショットジョブの開始（PDF生成・S3出力）
aws quicksight start-dashboard-snapshot-job \
  --aws-account-id 123456789012 \
  --dashboard-id my-dashboard-id \
  --snapshot-job-id my-snapshot-job-001 \
  --snapshot-configuration '{
 "FileGroups": [{
"Files": [{"SheetSelections": [], "FormatType": "PDF"}]
 }],
 "DestinationConfiguration": {
"S3Destinations": [{
  "BucketConfiguration": {
 "BucketName": "my-report-bucket",
 "BucketPrefix": "quicksight-reports/"
  }
}]
 }
  }'

# ジョブ完了確認
aws quicksight describe-dashboard-snapshot-job \
  --aws-account-id 123456789012 \
  --dashboard-id my-dashboard-id \
  --snapshot-job-id my-snapshot-job-001

出力ファイルは指定した S3 バケットに保存される。PDF / CSV / Excel の 3 形式に対応する。

組織展開とフォルダ管理

ダッシュボードが増えてきたら「フォルダ」で整理する。

8. まとめ・コスト最適化・運用ベストプラクティス

8-1. QuickSight BI基盤の全体像（再掲）

本記事では、Amazon QuickSight を「単発ダッシュボード作成ツール」ではなく「本番 BI 基盤」として運用する視点で、以下の機能群を体系化した。

Enterprise 必須機能の一覧（再掲）

本番 BI 基盤として QuickSight を活用するために必要な主要機能はほぼ Enterprise edition に集中している。

個人・チームの試行段階では Standard で始めることができるが、本番 BI 基盤として組織展開する際は実質的に Enterprise edition が前提となる。

8-2. コストの考え方

QuickSight の料金は 3 つのコンポーネントの組み合わせで決まる。

コンポーネント 1: ユーザーサブスク

コンポーネント 2: SPICE 容量（$/GB/月）

Enterprise は Standard より単価が高い点に注意。「高機能版だから安い」という誤解が多い。SPICE 容量はリージョン・アカウント単位で共有され、超過分は追加購入する。

コンポーネント 3: キャパシティ課金（オプション）

⚠️ 料金は変動します
上記は 2026年6月時点の参考値です。QuickSight は Quick Suite への統合再編に伴い料金体系が改定される場合があります。本番利用前に AWS 公式料金ページで最新価格を必ず確認してください。

コスト最適化の指針

• 大規模データは SPICE が有利: 全社員が日次で参照するダッシュボードを DirectQuery（Athena）で接続すると、毎アクセス時のフルスキャンによりコストが急増する。高頻度アクセスシナリオでは SPICE にインポートしてクエリコストを削減する。
• 不要 SPICE データセットの定期削除: 使われなくなったデータセットが容量を消費し続ける。月次・四半期ごとに棚卸しし、参照ダッシュボードが 0 件のデータセットを削除する。
• Reader vs Reader Pro の選択: Ask Q を使わない一般閲覧者は Reader（$3/月）で十分。Reader Pro（$20/月）は生成 BI を活用するパワーユーザーに限定する。
• Enterprise vs Standard の ROI 判断: RLS / 埋め込み / アラートのいずれかが必要なら Enterprise 一択。これら 3 機能を使わないなら Standard でコストを抑えられるが、のちの移行コストも考慮に入れる。

8-3. 運用ベストプラクティスまとめ

データセット設計

複数ダッシュボードで共通して使うデータセットは 1 つに集約し再利用する。データセットの増殖は SPICE 容量の無駄遣いとメンテナンスコスト増大につながる。結合（Join）はデータセットレイヤーで完結させ、ダッシュボード側の計算フィールドを最小化する。

RLS / CLS の先行設計

セキュリティ要件はデータセット設計の段階から組み込む。後付けの RLS 追加は、既存ダッシュボードの表示崩れや権限漏れのリスクが高い。ルールセットデータセットはバージョン管理対象に含め、IdP グループや IAM の変更と同期して更新する体制を作る。

SPICE 容量監視

SPICE 使用量はデータセット単位の describe-data-set API（ConsumedSpiceCapacityInBytes フィールド）で取得できる。Lambda + EventBridge Scheduler で定期集計し CloudWatch Custom Metrics へ送信、閾値超過時に SNS 通知するカスタムモニタリングを構築することを推奨する。

Amazon Q Topics 整備

Q Topics はフィールドに同義語（例: 売上 = Revenue = 売り上げ）と説明文を付与することで自然言語クエリの精度が大幅に向上する。Ask Q の誤回答をフィードバックし、定期的にチューニングする継続的な改善サイクルを設ける。

埋め込みセキュリティ

AllowedDomains は最小化し、本番ドメインのみを指定する。埋め込み URL は生成後 5 分で無効化されるため、フロントエンドでキャッシュせず毎ページロード時にバックエンドで生成する設計にする。セッションタグ値はバックエンドで検証・変換してから付与し、外部入力を直接渡さない。

テーマ統一

ブランドカラーをカスタムテーマとして定義し組織全体に共有する。新規ダッシュボード作成時に Author が統一テーマを使える環境を整えることで、ダッシュボードの見た目の品質が安定する。

データ分析基盤全体の設計パターン（Kinesis / EMR / S3 連携など QuickSight をアウトプット層として組み込む構成）については、データ分析パイプライン徹底解説の記事も合わせて参照されたい。

8-4. 次巻予告

Vol1 では SPICE 設計・RLS/CLS・埋め込み分析・Amazon Q（生成 BI）・ダッシュボード運用の本番実装パターンをカバーした。

Vol2 では以下を扱う予定：

• 大規模マルチテナント埋め込み: 数千テナントを想定した capacity pricing / namespace 分離 / タグ RLS の設計パターン
• QuickSight API / IaC 自動化: CloudFormation / CDK を使ったダッシュボード・データセット・RLS のコード管理と CI/CD 統合
• データメッシュ連携: Lake Formation / Glue Data Catalog と QuickSight を繋いだドメイン横断データプロダクト配信の実装

Vol2（大規模マルチテナント埋め込み・API/IaC 自動化・データメッシュ連携）は現在準備中です。公開後は本記事よりリンクします。