30秒サマリー
- Amazon QuickのAI構築アプリが、QuickSightデータセットをリアルタイムで照会できる「Live Data in Apps」の仕組みをAWSが公式ブログで詳説
- 自然言語の指示だけでアプリを生成し、行・列レベルのセキュリティを自動適用しながら常に最新データを表示
- SQLの記述やDevOps作業不要で、業務担当者がガバナンスを維持したまま社内向けデータアプリを自力で構築・共有可能
何が起きたか
AWSは公式の機械学習ブログで、AI統合インテリジェンスサービス「Amazon Quick」の「Live Data in Apps」機能の仕組みと活用方法を解説した。
これまでQuick Appsでは、AIエージェントがアプリを生成する際にQuickSightのデータセットを参照しても、その値はビルド時点のスナップショットとして固定されていた。Live Data in Appsでは、公開済みアプリがユーザーの開くたびにQuickSightのSPICEまたはDirect Queryデータセットに対してSQLをリアルタイムで実行する。クエリは閲覧者の認証情報で実行されるため、既存の行レベルセキュリティ（RLS）と列レベルセキュリティ（CLS）のルールが自動的に適用され、各ユーザーは自身に許可されたデータのみ表示される。
ブログでは営業リーダーが顧客更新管理アプリを自然言語のプロンプトで構築するユースケースを例示している。エージェントが関連データセットを自動検出してSQLを生成し、ビルダーがデータセットごとに同意を承認した後、アプリを公開・共有する流れが紹介されている。同一アプリ内でSPICEとDirect Queryを組み合わせることも可能だが、異なるソースのDirect Queryデータセットを同一アプリで混在させることはできないなど、いくつかの制約事項も明記されている。
なお、アプリの利用には認証済みQuickユーザーであることが必須であり、匿名・パブリックアクセスは非対応。閲覧者は初回利用時にデータセットへのアクセスについて同意を求められる仕様となっている。
原典ハイライト
「クエリは閲覧者として実行される。結果として、各ユーザーは自身が閲覧を許可されたデータだけを正確に参照できる」——AWSがブログ内で強調した、ガバナンスの核心となる設計方針。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
BIツールのデータをAI生成アプリに「ライブ接続」する仕組みが、既存のセキュリティ設定をそのまま引き継ぐ形で実現されたことが重要な点。従来は最新データを社内向けアプリに組み込むためにAPIの開発やスナップショット管理が必要だった工程を、自然言語の指示だけで代替できる可能性を示している。IT部門への依存を減らしながら、データガバナンスを緩めないという方向性は、セルフサービスBIをさらに進化させるものといえる。
日本企業への示唆
日本企業でQuickSightを活用しているチームにとって、このアプローチは「週次レポートの手作業集計」や「Excelスナップショットの回覧」といった定番業務の代替候補となりうる。特に営業や経営管理部門が最新KPIを常時参照できるアプリを、IT工数をかけずに展開できる点は検討に値する。一方で、同一アプリ内でDirect Queryのデータソースを複数混在させられない制約や、ビルダー側のRLSが返すデータが空の場合はアプリ構築自体が失敗するといった実装上の制約を事前に把握したうえでPoC設計を行うことが重要。Reader Proロール以上が必要な点も、ライセンスコストの試算に含めておく必要がある。
背景・経緯
Amazon Quickは企業データと企業コンテンツを一元的に接続するAI統合インテリジェンスサービスと位置づけられており、Quick Appsはその機能の一つとして自然言語でウェブアプリを生成・デプロイする機能を提供している。原文によれば、アクションコネクター（Jira・Slack・Google Driveなど）やウェブ検索・AI推論はすでに「表示時実行」に対応していたが、QuickSightのデータセットはビルド時スナップショットに限定されていた。今回のブログはその制約を解消する「Live Data in Apps」の仕組みを詳説したものとなっている。
