AI にデータを渡すと何が変わる ? - Amazon Quick の構造化データ活用とセマンティックレイヤー -
2026-10-05 | Author : 服部 洋明
はじめに
こんにちは！AI Specialist Solutions Architect の服部 洋明です !
AI が業務に浸透してきた昨今、「もっと楽に仕事を回したい」と誰もが思っています。文章の壁打ち、企画のブレスト、メールの下書き、生成 AI でずいぶん楽になりました。でも、こんな経験はないでしょうか。
- AI に「売上の改善策は ?」と聞いたら、どの会社にも当てはまる一般論が返ってきた
- 月次報告書を AI に書かせたら、体裁は整っているが中身は実データに基づかないフィクションだった
- 提案書のレビューを頼んだら、文法は直してくれたが「この数字は最新の実績と合っているか」は判断できなかった
AI に自社のデータを渡していないのだから、当然です。AI の本当の力は、あなたのデータと組み合わせたときに発揮されます。
では、プロンプトに背景情報を書き込めばいいのでしょうか ? たしかに「うちの会計年度は 4 月始まりで、売上は net revenue で…」と毎回書けば精度は上がるかもしれません。でも、それを毎回の質問で繰り返すのは現実的でしょうか。チームメンバーが別々の表現で書けば結果がブレ、新メンバーには「正しいプロンプトの書き方」を教えなければなりません。
毎回のプロンプトで頑張るのではなく、データとビジネスルールを事前にシステムに仕込んでおく。そうすれば、誰がどんな聞き方をしても、同じ精度の回答が返ってくる。これが Amazon Quick のアプローチです。
本記事では、Amazon Quick における構造化データの活用にフォーカスし、「データにビジネスの意味を持たせるセマンティックレイヤー」がどのように機能するのかを紹介します。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
Amazon Quick とは
Amazon Quick は、自然言語のチャットを入り口に、データの分析・可視化、ドキュメント検索、外部サービス連携、タスク自動化などを行う AI サービスです。複数のプラットフォームから AI 機能を利用し、非構造化データと構造化データ両方を利用して、業務の改善や効率化、インサイトを発見します。
本記事で主に扱うのは、その中でも構造化データ (データベースや CSV などの数値データ) を自然言語で活用する部分です。Amazon Quick では、構造化データに対する自然言語クエリ (NLQ) の精度を左右する仕組みとしてセマンティックレイヤーを提供しています。
セマンティックレイヤーとは何か
セマンティックレイヤーとは、データ (テーブル・カラム) と、ビジネスユーザーや AI が使う「意味」の間に置く翻訳層です。Amazon Quick では、この翻訳層を Dataset Enrichment と Multi-Dataset Topic という 2 つの仕組みで実現しています。
- Dataset Enrichment — 個々のデータセットにビジネスコンテキストを付与。これだけでも自然言語クエリが利用でき、AI の回答精度が向上します。
- Multi-Dataset Topic — 複数のデータセットをリレーション定義で論理統合し、マルチデータセットの分析を可能にします。
この 2 つは独立して使うことも、組み合わせて使うこともできます。
データウェアハウスのカラム名 rev_adj_excl_fx を見て、それが「為替影響除外調整済み売上」だと理解できるのは、そのテーブルを設計した人だけです。AI にとっても同じで、カラム名とデータ型だけでは正確なクエリを生成できません。
公式ドキュメントでは、Topic を利用する場合の全体像を以下の 4 層構造で説明しています。
- Data Sources — SPICE (インメモリ) や Direct Query でデータベースに接続
- Dataset Enrichment — 各データセットにビジネスコンテキストを付与
- Multi-Dataset Topic — 複数のデータセットをリレーション定義で論理統合
- Consumption — Chat での自然言語クエリとその根拠の確認
以降、この 4 層を順に見ていきます。
Layer 1 : Data Sources — データへの接続
まず、分析対象のデータを Amazon Quick に接続します。接続方法は大きく 2 つです。
|
接続方式
|
方式
|
向いているケース
|
|---|---|---|
|
SPICE (インメモリ)
|
データを取り込んで高速クエリ |
定期更新のデータ、高速レスポンスが必要な場面 |
|
Direct Query
|
データソースに直接クエリ。データ移動なし |
リアルタイム性が重要な場合 |
また、CSV / Excel / JSON ファイルをアップロードするだけでも SPICE データセットが作成できます。データベース環境がなくてもすぐに始められる入り口です。
Layer 2 : Dataset Enrichment — データに「意味」を教える
データを接続しただけでは、AI はカラム名とデータ型しか知りません。ここで Dataset Enrichment を使って、ビジネスコンテキストを付与します。設定はすべて自然言語で記述でき、SQL の知識は不要です。
"Custom Instructions are the most impactful component of Dataset Enrichment. They directly guide AI agents on how to interpret and query a dataset." — Dataset Enrichment
設定できる3つのレベル
|
レベル
|
内容
|
|---|---|
|
Dataset Description
|
データセット全体の説明 (何のデータか、粒度、対象期間、更新頻度) |
|
Custom Instructions
|
AI へのビジネスルール (計算式、用語定義、デフォルト挙動、注意事項) |
|
Column Description / Additional Notes
|
各カラムの意味、有効値、注意事項 |
設定の具体例
さらに、外部カタログからのメタデータ一括取り込みも可能です。YAML / JSON / TXT 形式でファイルアップロードすれば、dbt や Databricks、Alation で管理しているカラム定義をインポートできます。
それぞれの設定の具体例を見てみましょう。
Column Description の例 (取引明細データセットより) :
- revenue → 「売上 (JPY) 。『売上』はこのカラムを使用。」
- risk_score → 「顧客リスクスコア (0 ~ 100) 。80 以上が高リスク。」
- status → 「取引ステータス (完了/処理中/取消/テスト) 。『テスト』は分析除外。」
Synonyms (同義語) の例:
- channel に同義語「チャネル」「経路」「販売経路」を設定 → ユーザーが「販売経路別の売上」と質問しても channel カラムが正しく選択される
Enrichment の有無でどう変わるか
ここでは、ある金融事業会社の取引データを例に、Enrichment の有無で AI の回答がどう変わるかを見てみましょう。
Dataset Enrichment の効果 (データセット単体)
D-1 :「チャネル別の売上を見せて」
この会社では、取引チャネルのデータ値は '店頭' / 'オンライン' / 'ATM' / 'コールセンター' の4種類。社内では「店頭」のことを「対面」と呼んでいますが、データ上に '対面' という値は存在しません。
Dataset Enrichment で 「対面」= channel = '店頭' と定義しておけば、AIは channel カラムの意味を正しく理解し、チャネルごとの売上を日本語の値 (店頭・オンライン・ATM・コールセンター) で正確に集計します。
画面イメージ
D-2 :「月次の売上推移を見せて」
Custom Instructions に「売上 = revenue カラム」「時系列軸は transaction_date」と定義しておくことで、AIは正しいカラムを選び、月単位の集計で 14ヶ月分の推移を正確に返します。Enrichment がなければ、revenue と amount (経費含む取引総額) のどちらを使うべきかAIは判断できません。
📌 ソース: Dataset Enrichment
Layer 3 : Multi-Dataset Topic — 分散データの統合
実際のビジネスでは、売上・顧客・商品が別々のテーブルに格納されています。「商品カテゴリ別の売上は ?」という質問に答えるには、複数テーブルの JOIN が必要です。
Multi-Dataset Topic は、複数のデータセットをリレーション定義で論理的に統合し、マルチデータセットの自然言語クエリを実現します。
Topic にはリレーション定義 (JOIN条件) を設定し、データセット間の関係を明示します。Chat では LLM がこのリレーション定義に基づいてマルチデータセット SQL を自動生成します。また、Analysis (分析・ダッシュボード構築画面) でも Topic をデータモデルとして利用でき、複数データセットのフィールドを選択するとランタイムで Inner Join が自動実行されます。なお、同一 Topic 内では SPICE または Direct Query にデータセットを統一する必要があります (混在は不可) 。RLS (Row-Level Security) はデータセットレベルで適用され、マルチデータセットのクエリでも有効です。
Topic レベルの Custom Instructions
Topic には、データセット横断のビジネスルールを定義できます。
"Custom instructions are persistent natural language rules that guide the AI engine in interpreting domain-specific terminology and cross-dataset logic." — Adding custom instructions to a Topic
Multi-Dataset Topic の効果 (マルチデータセット)
T-1 :「地域別の融資延滞件数は ?」
融資データ (fact_loans) には顧客IDしかなく、地域情報は顧客マスター(dim_customers) にあります。Topic のリレーション定義により、AIは fact_loans → dim_customers を customer_id で自動JOINし、都道府県別の融資延滞件数を回答します。Topic がなければ、単一データセットに地域情報がないため回答不可です。
T-2 :「商品カテゴリ別の売上を見せて」
取引データ (fact_transactions) には商品IDしかなく、カテゴリー情報は商品マスター (dim_products) にあります。Topic の JOIN 定義により、AI は自動でテーブルを結合し、投資信託・損害保険・医療保険…といったカテゴリー別の売上を集計します。
Dataset Enrichment × Topic の組み合わせ
C-1 :「顧客セグメント別の売上を見せて」
この質問には、Dataset Enrichment のセグメント定義 (VIP / 優良 / 一般 / 休眠 / 離反の 5 種類) と、Topic の JOIN (fact_transactions → dim_customers) の両方が必要です。
C-2 :「事業部別・チャネル別の売上を見せて」
事業部 (銀行/保険/証券) × チャネル (店頭/オンライン/ATM/コールセンター) の2軸で集計。Enrichment の用語マッピングと Topic による全社横断ビューが組み合わさり、12セル (3事業部×4チャネル) の全社横断分析が一発で返ります。Dataset Enrichment (個々のテーブル内の意味) と Topic Custom Instructions (テーブル間の関係性) の2層構造がセマンティックレイヤーの核です。単独でもそれぞれ価値がありますが、組み合わせたときに最も力を発揮します。
Layer 4 : Consumption —活用と透明性
セマンティックレイヤーが整ったら、いよいよ活用です。ユーザーは Chat で自然言語の質問を投げるだけで、AI が適切なデータセットを選び、SQL を生成し、結果を返します。Dataset Q&A (データセット単体) でも Topic Q&A (マルチデータセット) でも、ここまでに設定した Enrichment と Topic の定義が自動的に反映されます。さらに重要なのが透明性です。数値の回答には、なぜその計算を行ったのかを把握できることが求められます。
Chat Explainability —「なぜその数字 ?」に答える
Dataset Q&A でも Topic Q&A でも、Chat Explainability (Explanation 機能) が利用できます。AI の回答に対して、ボタンひとつで以下が表示されます。
|
表示項目
|
内容
|
|---|---|
|
Found data in
|
どのデータセット/ダッシュボードからデータを取得したか |
|
Filters
|
適用されたフィルター条件 |
|
Assumptions
|
AI が行った解釈や前提 |
|
Calculation explained
|
計算ロジック (自然言語 + 数式) |
|
Generated SQL (Dataset Q&A 時)
|
実際に発行された SQL |
"Instead of manually verifying each answer by finding the original source and re-creating the logic, you can directly see the model's assumptions at the click of a button." — Amazon Quick chat explanations
クエリの説明について
『C-2: 「事業部別・チャネル別の売上を見せて」』で行なったクエリの説明は図のようになります。
AI の回答が信頼できるかどうかを手動で検算する必要がなくなる。これは「楽をしたい」と「正確さが必要」の両立において非常に大きなポイントです。
Catalog Integration — 既存メタデータの活用
すでに AWS Glue Data Catalog や Databricks Unity Catalog でメタデータを管理している組織は、Catalog Integration を使うことで、そのメタデータを Amazon Quick に取り込めます。 ※ 本機能は2026年9月時点でプレビュー提供です。仕様は変更される可能性があります。
|
連携先
|
同期対象
|
|---|---|
|
AWS Glue Data Catalog
|
テーブル説明・カラムコメント |
|
Databricks Unity Catalog
|
フィールドメタデータ |
"By building curated representations (datasets and topics) in Quick, Quick can combine catalog data with other enterprise knowledge sources." — When to use data catalog integration
その他の支援機能
カタログ上のテーブルから、ビジネス用途に合ったテーブルを AI が発見し、DirectQuery データセットと Topic の一括作成、セマンティック定義の自動継承までを支援する機能も提供されています。
セマンティックレイヤーが整うと何が変わるか
セマンティックレイヤーは、AI の精度と信頼性の土台です。Dataset Enrichment で個々のテーブルに意味を持たせ、Topic で複数テーブルの関係性を定義し、Chat Explainability で回答の根拠を透明にする。この3つが揃うことで、「自然言語で聞くだけで、正確なデータに基づいた回答が得られる」世界が実現します。
|
Before (セマンティックレイヤーなし)
|
After (セマンティックレイヤーあり)
|
|---|---|
|
AI はカラム名とデータ型だけで推測
|
AI はビジネスルール・用語定義・計算式を理解 |
|
「売上」のカラム選択を間違える
|
Custom Instructions に従い正確なカラムを選択 |
|
複数テーブルの JOIN は手動で SQL
|
Topic のリレーション定義で自動 JOIN |
|
回答の根拠がブラックボックス
|
Chat Explainability で SQL・前提・計算式を開示 |
|
毎回プロンプトに背景情報を手打ち
|
一度定義すれば全ユーザー・全質問に適用 |
|
カタログのメタデータが BI 側で活かせない
|
Catalog Integration で自動同期 |
さらに先へ — 非構造化データとの接続
本記事では構造化データのセマンティックレイヤーに焦点を当てましたが、Amazon Quick ではナレッジベース (Knowledge Base) や Action Connector を通じて、非構造化データや外部サービスもAIの知識・行動として活用できます。
たとえば：
- 「Q3 で売上が下がった地域の原因は ?」→ 構造化データで数値を特定し、SharePoint のナレッジベースから営業報告書を検索して原因を引用
- 「延滞リスクの高い顧客の担当者に連絡して」→ データ分析でリスク顧客を特定し、Salesforce で案件情報を確認、Slack で担当者にアラートを送信
構造化データの「What (何が起きているか）」に、非構造化データの「Why (なぜ）」と外部サービスへの「Action (次の一手）」が加わることで、AI は分析から行動までを伴走します。
まとめ — データに意味を持たせることがスタートライン
本記事では、Amazon Quick の構造化データ活用を、セマンティックレイヤーの 4 層構造に沿って紹介しました。AI に「楽をさせてもらう」ためには、AI が正確に動くための「仕込み」が必要です。その仕込みの核がセマンティックレイヤーであり、Dataset Enrichment はビジネスユーザーが自らのドメイン知識を自然言語で記述するだけで設定できます。データに意味を持たせること。それが、AI を「壁打ち相手」から「仕事のパートナー」に変えるスタートラインです。
|
層
|
機能
|
やること
|
|---|---|---|
|
Layer 1
|
Data Sources |
SPICE / Direct Query / ファイルアップロードでデータ接続 |
|
Layer 2
|
Dataset Enrichment |
Description・Custom Instructions・Column Semantics でビジネスコンテキスト付与 |
|
Layer 3
|
Multi-Dataset Topic |
複数データセットをリレーション定義で統合、マルチデータセット Custom Instructions |
|
Layer 4
|
Dataset Q&A / Topic Q&AChat Explainability |
自然言語クエリ + Chat Explainability で結果の透明性を確保 |
|
+
|
Catalog Integration |
既存カタログのメタデータを自動同期 |
筆者プロフィール
服部 洋明
アマゾン ウェブ サービス ジャパン合同会社
AI Specialist Solutions Architect
2022 年 Technical Account Manager として入社。エンタープライズサポートにご加入のお客様にアーキテクチャ提案から運用面までサポート。現在は、AI Specialist Solutions Architect として日本の全テリトリーにおける Amazon Quick の技術面のリードをしている。大好きなサウナは Quick には終わらないスタイル。
