Snowflake Cortex Analystで、SlackからSQLを自動生成してみた
はじめに
シロクは「N organic」や「FAS」などのブランドを展開する化粧品会社です。顧客体験の向上とマーケティング効果の最大化のために、日々多様なデータが活用されています。
各ブランドの成長に伴い、データに基づく意思決定の重要性が増しており、複数の事業部からデータチームへのレポート作成や分析依頼が増加しています。その一方で、以下のような課題が顕在化してきています。
- 分析依頼の増加によるリソースの低下
- 類似の分析やアウトプットの増加
- AI活用による効率化ニーズが高まり
- クエリの誤用によるリスクの拡大
ゴール
Slackで分析依頼を投げるだけで、Snowflake側でSQLを生成・実行し、結果をSlack上に返すプラットフォームを構築することで、これらの課題を解決を試みました。
これにより、Snowflakeにアクセスできない人でも、簡単にかつ正確な分析を提供することを実現できると考えました。
完成したアウトプット:Slackからの自動生成応
Snowflake Cortex Analystについて
Snowflake Cortex Analystは完全マネージド型のAIサービスです。構造化データに対して自然言語で質問できる対話型インターフェースを提供しており、ビジネスユーザーがSQLを書かずに、会話形式でデータを分析できる環境を実現します。
高精度なText-to-SQL変換を可能にするLLMを活用しており、Snowflake上のセキュリティやガバナンス(RBACなど)をそのまま活かせるのが特徴です。REST API経由で利用可能で、既存のアプリケーションやダッシュボードに柔軟に組み込むことができます。
Getting Started with Cortex Analyst: Augment BI with AIより引用
Cortex Analyst を導入することで、以下のような利点があります:
- 自然言語での質問により、非エンジニアでも柔軟にデータにアクセス可能
- 高精度なText-to-SQLにより、誤ったクエリの生成リスクを最小化
- 開発者はUIやUXを自由に設計できるため、自社アプリケーションと統合可能
- セキュリティやアクセス制御(RBAC)はSnowflakeの仕組みで一貫して保護
構成
今回は、Cortex Analystを呼び出す上で、AWSのリソースを活用しており、構成は全てTerraformで管理しました。
- Slackアプリの設定。
- SlackがAPI Gatewayを呼び出す(パス: /slack/events)
- API Gateway経由でLambdaを呼び出す。
- Lambdaがメッセージを処理し、SQSにリクエストを送信。
- LambdaがSQSからメッセージを受け取る。
- lambdaがSnowflake Cortex Agentを呼び出してSQLを生成・実行され、レスポンスを行う。
SQL自動生成のアーキテクチャ
ポイント
今回より正確にSQLを自動で生成するために、以下の3つの実装を試みました。
1. セマンティックモデルの構築
セマンティックモデルとは、データセットに関するメタ情報をYAML形式で定義・保存する仕組みです。各モデルにはテーブル構造やサンプル値、フィールドの説明、テーブル間のリレーションなどを記述し、Cortex Analystがデータマートを正しく解釈して精度の高いクエリを自動生成できるようにします。
name: fact_sirokshop_kpi
tables:
- name: FACT_SQL_AGENT_ORDERS
base_table:
database: DATA_PLATFORM_STG
schema: MART_SQL_AGENT
table: FACT_SQL_AGENT_ORDERS
time_dimensions:
- name: EXECUTED_DATE
expr: EXECUTED_DATE
data_type: DATE
sample_values:
- '2023-07-04'
description: Date on which the SQL agent order was executed.
synonyms:
- transaction_date
- event_date
facts:
- name: REVENUE
expr: REVENUE
data_type: FLOAT
sample_values:
- '100'
description: The total amount of revenue generated from the orders.
synonyms:
- sales
- profit
- gain
default_aggregation: 1
2. スキーマ構成
Snowflake Analystでは、膨大な数のデータマートを読み込んだり、複雑な結合を行うとクエリ精度が低下しやすくなる傾向がありました。そこで、AI専用のロールとスキーマを作成し、重要なKPIやユーザーによく利用されるデータのみを局所的に格納することで、不要な情報の学習を排除しています。
さらに、各テーブルあたりのカラム数を2〜5個に絞ることで、パフォーマンスと精度のバランスを最適化しました。各テーブルに対応するセマンティックモデルはInternal Stage上に、それぞれ以下のディレクトリ構成で管理しています。
MART_SQL_AGENT/
├─ Tables/
│ ├─ FACT_KPI_ORDERS
│ └─ FACT_KPI_PRODUCTS
├─ Stages/
│ └─ INTERNAL_STAGE/
│ ├─ FACT_KPI_ORDERS.yml
│ └─ FACT_KPI_PRODUCTS.yml
└─ README.md
3. サーバーサイドで非同期処理
Slackからの問い合わせリクエストを処理する際、SQSを使うことで、処理の安定性と拡張性を高めています。具体的には、Slack → API Gateway → Lambdaで受け取ったリクエストを、一度SQSに送信し、別のLambdaでSnowflakeへの問い合わせ処理を非同期で実行する構成です。これにより、重いクエリでもSlackへの即時応答を維持しつつ、処理失敗時の再試行やピーク時の処理分散も実現できます。
結果
生成したSQLの結果になります。いい感じにSQLが生成されていますね。
まとめ
Snowflake Cortex AnalystとAWSで、SlackからSQLを自動生成するプラットフォームを作成し、誰でも安全かつ高品質なデータ分析が可能となりました。今後は図の自動生成とデータの拡張によりさらなる業務効率化を図ります。
謝辞
本プロジェクトの立ち上げに際し、多大なるご支援と貴重なご助言を賜りましたSnowflake社の國下様、菅野様に心より感謝申し上げます。皆さまのお力添えがあってこそ、本システムの実現とスムーズな導入が可能となりました。今後ともご指導ご鞭撻のほど、よろしくお願いいたします。

「N organic」、「FAS」等の化粧品ブランドを展開している株式会社シロクのエンジニアブログです。 ECサイトを中心とした自社サービスの開発・運用を行っています。 sirok.jp/norganic
Discussion