はじめに
Snowflakeを導入している組織の中で、「せっかくデータがあるのに、SQLが書けないから触れない…」という声を耳にすることはありませんか？
アナリストやエンジニアだけでなく、営業や企画などビジネスユーザも自分でデータを整形して取り出し、分析できたら便利なのに。
そんな課題を解決するヒントのひとつがSnowflake Cortex Analyst だと、私は考えています。
今回はその実力を、実際の検証シナリオを通じて探ってみたいと思います。
1. Cortex Analystとは
Cortex Analystは、いわゆるText-to-SQLと呼ばれる技術に分類されます。
SQLに慣れていないビジネスユーザでも、自然言語を使ってデータベースに問い合わせを行い、その結果を分析に活用できるようにする仕組みです。
イメージがつきやすいように、自然言語の問い合わせから結果が返るまでの流れを図にしました。
以下のように5つのステップを経て、ユーザの質問がSQLに変換され、実際のデータベースに問い合わせが行われます。
1. ユーザが「A部門の8月の売上を教えて」と自然言語で問い合わせる
2. Cortex Analystが自然言語を解釈し、SQLに変換する
3. 変換したSQLを使って、データベースに問い合わせする
4. データベースから結果が返却される
5. Cortex Analystがその結果をユーザに返す
さらに、Snowflake公式ブログに掲載されている図をもとに仕組みを整理すると、Cortex Analystは次の4つのステップで動作していることが分かります。
出典：Cortex Analyst：AIによるセルフサービスアナリティクスへの道筋
1. ユーザの質問と関連するセマンティックモデルを受け取る
2. ユーザの質問の意図を分析する
3-1. 複数のSQL生成エージェントが候補SQLを生成する
3-2. コンパイルエラーがないかをチェックし、必要に応じて修正する
4. 候補の中から最適なSQLを選択し、実行する
このように、Cortex Analystは単なるSQL生成ツールではなく、セマンティックモデルを活用して複数のエージェントが候補を検討・検証する点が特徴です。
Cortex Analystの概要を理解したところで、その可能性をさらに探っていきましょう。
2. 検証シナリオ
今回の検証では、Cortex Analystの実力を次の3段階に分けて確認しました。
| Level | 目的 | データ/前提 | 代表タスク/質問例 |
|---|---|---|---|
| 1（単一テーブル） | 単一テーブルで自然言語→SQLの正確性を確認 | 1テーブル（例：SALES） | 「2024年の売上合計」「月次売上の推移」「上位5商品」/ 同義語テスト |
| 2（単表×マルチターン） | 文脈の引き継ぎ（参照・省略・曖昧解消） | Level1と同一データ | ①「2024年の売上」→②「Q2だけ」→③「カテゴリTOP3」→④「前年同期比」 |
| 3（複数テーブル） | 複数テーブルJOIN前提の質問の正確性 | SALES × STORE（+α） | 「店舗別売上TOP3（SALES×STORE）」 |
結果の評価は、以下の観点で行いました。
| 観点 | 評価内容 | 指標例 | ポイント |
|---|---|---|---|
| 1. 複数質問での再現性 | 各Levelごとに質問カタログを用意（10問程度） | ― | 単発の成功に左右されないよう全体傾向を確認 |
| 2. 回答が返らないケース | 「SQLが生成されなかった」「生成されたSQLが実行エラーになった」を分けて集計 | - SQL生成失敗率 - SQL実行失敗率 |
正答率とは別に扱うことで、「出ない vs 出たけど間違い」を切り分け |
| 3. チューニング効果の比較 | セマンティック定義やモデル改善の前後を比較 | - 初回正答率（最初の試行で正答） - 最終正答率（修正後に正答） - 訂正率（最終−初回） |
Before/Afterで改善度を可視化 |
3. Level1：単一テーブル
3.1 環境準備
まず、Level1の検証用として以下のテーブルを用意しました。
| カラム名 | データ型 | 制約 | 説明 |
|---|---|---|---|
| ORDER_ID | NUMBER | NOT NULL | 注文ID |
| ORDER_DATE | DATE | NOT NULL | 注文日 |
| ITEM_ID | NUMBER | NOT NULL | 商品ID |
| ITEM_NAME | STRING | NOT NULL | 商品名 |
| CATEGORY | STRING | NOT NULL | 商品カテゴリ |
| PRICE | NUMBER(10,2) | NOT NULL | 単価（小数点2桁まで） |
| QUANTITY | NUMBER(4) | NOT NULL | 注文数量 |
サンプルデータはランダム生成で約3,000件投入し、複数年・複数カテゴリに分布させています。
次に、このテーブルに対応するセマンティックビューを定義しました。設定方法は公式ドキュメントを参照し、Snowsight上で実施しています。
👉 Cortex Analyst セマンティックビュージェネレーターの使用
なお、この段階では検証済みクエリ等は設定せず、最小限の定義にとどめています。まずはシンプルな構成でセマンティックビューを用意し、Cortex Analystがどのように動作するかを確認することを目的としました。
設定後のセマンティックビュージェネレーターの画面は以下の通りです。
右側のテスト画面から、Cortex Analystを呼び出せるため、本検証では、この画面上でテストを実施します。
3.2 実行:質問ごとの評価
今回の検証は「試す → NGなら直す → 直した状態で次へ進む」という流れで行いました。こうして逐次的に改善しながら、Cortex Analystの挙動を確認しています。
下表の「チューニング後」欄は、修正を加えたうえで再実行した結果を示しています。
| # | 質問 | 意図 | 初回結果 | SQL生成失敗 | チューニング後 |
|---|---|---|---|---|---|
| 1 | 2024年の売上合計を教えて | 単純なSUM | ⚪︎ | - | - |
| 2 | FY2024年度の売上合計を教えて | 同義語処理（年度→年） | × | × | ⚪︎ |
| 3 | 2024年の月ごとの売上推移を出して | GROUP BY（月） | ⚪︎ | - | - |
| 4 | 売上が多い商品トップ5を表示して | ORDER BY＋LIMIT | ⚪︎ | - | - |
| 5 | 2023年と2024年の売上を比較して | 複数年比較 | × | - | ⚪︎ |
| 6 | Beverageカテゴリの2024年売上合計を出して | 条件フィルタ＋SUM | ⚪︎ | - | - |
| 7 | 注文数量の合計が一番多い商品を教えて | SUM(QUANTITY)＋順位付け | ⚪︎ | - | - |
| 8 | 1件あたりの平均売上金額はいくら？ | 平均（売上/注文数） | × | - | ⚪︎ |
| 9 | Chocolateの2024年の売上推移を月ごとに出して | 特定商品＋月別集計 | ⚪︎ | - | - |
| 10 | 2024年のカテゴリ別売上構成比を出して | 集計＋比率計算 | ⚪︎ | - | - |
3.3 初回結果NGの考察と対処
質問No.2
チューニング前の結果
- 質問：FY2024年度の売上合計を教えて
- 期待：FY2024＝2024/4/1～2025/3/31の期間を集計
- 回答：申し訳ございませんが、ご質問は会計年度に関するものですが、セマンティックデータモデルには暦日しか含まれていないため、お答えできません。
対処1:日付を明示して問い合わせる
- 2024年4月～2025年3月の売り上げを教えて
- 結果：意図した期間で集計できた。
対処2:セマンティックビューを編集する
- time dimensionに以下を追加
CASE WHEN MONTH(order_date) >= 4
THEN YEAR(order_date)
ELSE YEAR(order_date) - 1
END
➡ 4月以降の注文は当年、1～3月の注文は前年に属する年度として扱うロジック。
- Synonyms (optional)に「会計年度, 年度, FY, FY年度」を追加
- 結果：期待した結果を得られた。
💡 補足
会計年度（Fiscal Year, FY）は国や企業によって異なります。
• 日本企業では 4月1日～翌年3月31日 を会計年度とするケースが一般的
• 企業によっては 7月開始 や 10月開始 など独自の設定も存在
本検証では「FY2024＝2024年4月1日～2025年3月31日」と定義しており、そのために上記の CASE 式を用いて年度を判別しています。
質問No.5
チューニング前の結果
- 質問：2023年と2024年の売上を比較して
- 期待：2023年の合計売上と2024年の合計売上を出力
- 回答：2023~2024年の売上を月別に出力（年ごとの出力を意図していた）
対処:プロンプトを修正する
- 月次ではなく年単位の合計だけを比較して
- 結果：期待した結果を得られた。同時に、ひとつ前のコンテキストを踏まえたうえで回答ができることを確認できた。(マルチターン）
質問No.8
- 質問：1件あたりの平均売上金額はいくら？
- 期待：全期間の売上金額の合計/売上発生件数
- 回答：全期間の単価の合計/売上発生件数（1件あたりの単価を算出）
対処:セマンティックビューを編集する
- metricを追加する
SUM(price * quantity) / NULLIF(COUNT(DISTINCT order_id), 0)
- Synonyms (optional)に「1件あたりの平均売上金額, 平均注文額」を追加
- 結果：期待した結果を得られた。
3.4 Level1の評価まとめ
今回のLevel1（単一テーブル）検証を、以下の3つの指標で評価しました。
• 初回正答率：7/10（70%）
• 最終正答率：10/10（100%）
• 訂正率：+30%（改善により正答率が向上した割合）
単表レベルでは、初期状態でも7割の質問に正しく回答できました。
さらに、セマンティックビューやメトリクスを最小限チューニングすることで、すべての質問に正しく答えられるようになり、Cortex Analystが実用レベルの精度を持つことを確認できました。
4. Level2：単表×マルチターン
4.1 環境準備
Level2では新たなテーブル作成は行わず、Level1で用意した SALES_L1 テーブルと、その検証終了時点でチューニング済みのセマンティックビューを利用しました。
4.2 実行: 会話チェーンごとの評価
本検証では、会話の文脈を引き継ぎながら自然言語指示を追加できるかを確認しました。
会話チェーンを3〜4ターンで設計し、各ターンごとに初回結果を評価。必要に応じて最小限のチューニング（同義語追加・日付ロールアップ・簡単なメトリクス定義など）を行いました。
| チェーン | ターン | 発話 | 意図 | 初回結果 | SQL生成失敗 | チューニング後 |
|---|---|---|---|---|---|---|
| A | 1 | 2024年の売上合計を教えて | SUM / 年フィルタ | ⚪︎ | - | - |
| A | 2 | じゃあQ2だけ | 前ターン条件の継承 / 期間変更 | ⚪︎ | - | - |
| A | 3 | Beverageに絞って | フィルタ追加 | × | × | ⚪︎ |
| A | 4 | その条件で商品トップ3 | ランキング / 粒度維持 | ⚪︎ | - | - |
| B | 1 | 2024年の月次売上の推移 | 月別GROUP BY | ⚪︎ | - | - |
| B | 2 | 前年同月も並べて | 比較（2023 vs 2024） | × | - | ⚪︎ |
| B | 3 | 伸び率も計算して | 比率計算 | ⚪︎ | - | - |
4.3 初回結果NGの考察と対処
質問 A-3
- 質問：Beverageに絞って
- 期待：Beverageの2024売上を集計
- 回答：申し訳ございませんが、ご提供いただいたセマンティックモデルに「Beverage」というカテゴリがないため、ご質問にお答えできません。モデルには「snack」「other」といったカテゴリが含まれていますが、「Beverage」は含まれていません。
対処：セマンティックビューを編集する
- Samplevaluesに「Beverage」を追加
- 結果：期待した結果を得られた。
今回のケースから、Cortex Analyst はユーザの質問に対して直接テーブルを参照しているわけではなく、あくまでセマンティックビューに定義された情報をもとに「回答可能かどうか」を判断していることが確認できた。
質問 B-2
-
質問：前年同月も並べて
-
期待：
月 Sales_2023 Sales_2024 01月 123456 135000 02月 98765 102300 03月 110000 120500 ... ... ... 11月 496112 325240 12月 345612 400000 -
回答：年月単位で出力され、2023-01と2024-01が別行になってしまった。
Month Sales_2023 Sales_2024 2023-11 496112 null 2023-12 345612 null ... ... ... 2024-11 null 325240
対処１:プロンプトを修正する
- 「2023年と2024年の売上を月ごとに比較してください。列は月（01月〜12月）、Sales_2023, Sales_2024としてください。 また、月に年月を入れないで、月（X月）だけにしてください」
- 結果１:改善せず
対処２:セマンティックビューを編集する
- プロンプト修正では期待結果を得られない。生成されたSQLとセマンティックビューを見比べると
- セマンティックビューの時間軸は FISCAL_YEAR（会計年度）とORDER_DATE（注文日）のみ
- この状態でLLMは「月ごと」を解釈するため DATE_TRUNC('MONTH', order_date) を利用
- しかしこれは「年月」粒度になるため、2023-01と2024-01が別行として出力
- 結果として「月（01〜12）を軸に2年分を横並びで比較する」意図を正しく表現できない
そこで、セマンティックビューに以下の2つの dimension を追加しました。
- name: MONTH_NUM
expr: DATE_PART('MONTH', ORDER_DATE)
synonyms: [月, month, 月番号]
data_type: NUMBER(2,0)
- name: YEAR
expr: DATE_PART('YEAR', ORDER_DATE)
synonyms: [年, year, 暦年]
data_type: NUMBER(4,0)
- 結果２
この状態で、対処１のプロンプトを実行したところ、期待した出力を得ることができた。
4.4 Level2の評価まとめ
今回のLevel2（単表 × マルチターン）検証を、以下の3つの指標で評価しました。
• 初回正答率：5/7（約71%）
• 最終正答率：7/7（100%）
• 訂正率：+29%（改善により正答率が向上した割合）
※質問 B-2は計算結果は正しいので、正解とみなす。
マルチターンのやり取りにおいても、初期状態で7割程度は正しく回答できました。
一方で、「Beverageカテゴリがセマンティックビューに存在しない」、「月粒度の扱いが曖昧」といったケースでは誤回答となり、プロンプト修正だけでは改善できない場面がありました。
しかし、セマンティックビューに適切なディメンションを追加することで、最終的にはすべての会話チェーンで意図した回答を得ることができました。
この結果から、Cortex Analystはマルチターンでも十分実用的に動作する一方で、セマンティックビュー設計が回答の成否を大きく左右することが確認できました。
次回予告：Level3検証へ
Level 1・2（単表〜マルチターン）の検証で分かったのは、セマンティック を整えることで回答精度が向上できるということ。次回はLevel3（JOIN 前提）の検証に進みます。そして、全体の検証結果を踏まえて、Cortex Analystの設計上の考慮事項を整理します。
取り上げるトピック
- SALES→STORE→REGION／SALES→ITEMのrelationships設計（外さない結合）
- ピボット体裁を崩さないVerified Query化
- 導入時に使える設計チェックリスト
仲間募集
NTTデータ ソリューション事業本部 では、以下の職種を募集しています。
Snowflake、生成AIを活用したデータ基盤構築/活用支援（Snowflake Data Superheroesとの協働）
Databricks、生成AIを活用したデータ基盤構築/活用支援（Databricks Championとの協働）
プロジェクトマネージャー（データ分析プラットフォームソリューションの企画～開発～導入／生成AI活用）
クラウドを活用したデータ分析プラットフォームの開発(ITアーキテクト/PM/クラウドエンジニア)
ソリューション紹介
Trusted Data Foundationについて
～データ資産を分析活用するための環境をオールインワンで提供するソリューション～
最新のクラウド技術を採用して弊社が独自に設計したリファレンスアーキテクチャ（Datalake+DWH+AI/BI）を顧客要件に合わせてカスタマイズして提供します。
可視化、機械学習、DeepLearningなどデータ資産を分析活用するための環境がオールインワンで用意されており、これまでとは別次元の量と質のデータを用いてアジリティ高くDX推進を実現できます。
TDFⓇ-AM（Trusted Data Foundation - Analytics Managed Service）について
～データ活用基盤の段階的な拡張支援（Quick Start) と保守運用のマネジメント（Analytics Managed）をご提供することでお客様のDXを成功に導く、データ活用プラットフォームサービス～ TDFⓇ-AMは、データ活用をQuickに始めることができ、データ活用の成熟度に応じて段階的に環境を拡張します。プラットフォームの保守運用はNTTデータが一括で実施し、お客様は成果創出に専念することが可能です。また、日々最新のテクノロジーをキャッチアップし、常に活用しやすい環境を提供します。なお、ご要望に応じて上流のコンサルティングフェーズからAI/BIなどのデータ活用支援に至るまで、End to Endで課題解決に向けて伴走することも可能です。
NTTデータとSnowflakeについて
NTTデータとSnowflakeについて
NTTデータでは、Snowflake Inc.とソリューションパートナー契約を締結し、クラウド・データプラットフォーム「Snowflake」の導入・構築、および活用支援を開始しています。
NTTデータではこれまでも、独自ノウハウに基づき、ビッグデータ・AIなど領域に係る市場競争力のあるさまざまなソリューションパートナーとともにエコシステムを形成し、お客さまのビジネス変革を導いてきました。
Snowflakeは、これら先端テクノロジーとのエコシステムの形成に強みがあり、NTTデータはこれらを組み合わせることでお客さまに最適なインテグレーションをご提供いたします。
NTTデータとDatabricksについて
NTTデータは、お客様企業のデジタル変革・DXの成功に向けて、「databricks」のソリューションの提供に加え、情報活用戦略の立案から、AI技術の活用も含めたアナリティクス、分析基盤構築・運用、分析業務のアウトソースまで、ワンストップの支援を提供いたします。
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。