この記事はSnowflake Summit 2025で発表されたAI SQL のうち、いままでのSQL言語の考えから最も遠いところにありそうで大注目のAI_AGGについて試してみるというものです。

はじめに：AI SQLでできる事のイメージ

AI SQLはSQLにおける「様々な処理ステップ」をAI関数によって拡張するというものです。

AI_FILTERであればWHERE条件部分で使用します。従来であれば数値や文字列の「＝、＜、＞」といった完全一致、大小比較が前提で条件として成立していたところを、「良いコメントしているユーザーを抽出して」のような意味的な条件で絞ることができます。

AI SQLが効く簡単な例

従来のSQL

-- 満足度の高いコメントを残したユーザーを抽出する
-- ただし、この裏には「満足度をスコア化してsatisfaction列に書き込んでおく」
-- という事前準備が必要
SELECT username FROM review_comment
WHERE satisfaction > 8;

満足度を事前にスコア化してsatisfaction列に書き込んでおく、というのは従来の機械学習や生成AIの使い方で、このスコア付けが正しいか？あたりが生成AIモデルの能力として議論の的でした。そこができれば、満足度の高い人を捉えてアップセルに繋げる施策が事業に効いてきそうですね。

ただし事業側の事情はもう少し複雑です。ユーザーコメントはどんな形で集めているのか。ある時はフリーテキストで、ある時は「満足＞やや満足＞普通・・・」のような単語で（Google Formとかで取ったアンケートだとありがち）それぞれに対して同じ指標として使える「満足度：8」を付けられるのか。それぞれをやっぱり分析に使いたいのであれば、それぞれの満足度スコアを計算するデータ加工パイプラインを用意します。どれも満足度つもりで使うが、用途の違う満足度A、満足度B・・・がたくさん生み出されてしまうことでしょう。

さらには、せっかくスコア化した満足度ですが、8以上で切るのがいいのか、7も含めたほうがいいのか、正直言って誰もわかりません。スコア化して値を生み出すからには厳密なロジックに基づいているのがいいに決まってるのですが、使うほうに厳密さは意味がなかったりします。やりたいことは「満足度の高い人を見つけて！」でしかないのですから。

AI SQL（AI_FILTER）

-- 満足度の低いコメントを残したユーザーを抽出する
-- フリーテキストで集めたユーザーコメントを直接条件として使える
SELECT username FROM review_comment
WHERE AI_FILTER(CONCAT('The reviewer enjoyed the restaurant: ', comment));

事前のスコア算出パイプラインを一切やめることにしました！
事業側に生のコメントをリアルタイムに公開して、そのコメントに対して自然言語で問いかけた内容に意味的に合致する利用者を絞れるようにしました。スコア付け（つけた後のスコア=8を探す）のような再現性はないかもしれませんが、即効性に優れ、精度がまあまあであれば実用的に使えそうです。

スカラー関数としてのAI SQL

他にも分類、サマリ、コンプリート（会話として完結する表現を作文）、また従来からある表現も組み合わせると感情分析などもできます。これはいずれもある値に対して生成AIが一つの値を生成して返すスカラー型の関数として提供されています。

• 「おいしかったです。」という1つの値に対して「これはお礼の文章です。ポジティブ。」と言う値を返します。
• これは、「500円」という1つの値に対し、税込み価格を返す関数tax()を適用すると「550円」が返るのと全く同じ使い方をしています。
• 「おいしかったです」に対して、「満足度が高いならTrue、高くないならFalse」というロジックを与えて「True」を返すのが上述のAI_FILTERです。AI_FILETERでは戻り値がTrue/Falseになること を理解できれば、今までのSQLを置き換える際、使いどころにあまり悩むことなく適用していけると考えています。

一見新しい概念のAI SQLですが、こう考えておけば、既存のSQL結果の各行に対して1対1で何か返すことができる。何を返すか、その精度がどうか？は各関数や採用しているモデルによるので一旦置いておいて、これらの適用シーンや事前準備はおのずと決めていけるのではないでしょうか。

なぜAI_AGGをとりあげるのか

AI_AGGは集計関数であり、スカラー関数とは扱いが異なります。従来の集計関数といえばSUM、AVG、MINなど分析者は誰でも知っているなじみ深いものです。

これがAI_AGGになることで、SQLで記述・表現できる範囲を大きく拡張し、さらにはデータから「集計結果」を得るのではなく、「直接的なインサイト（集計結果を解釈して言語化したもの）」を得られるものであり、AI SQLの中でも特異で極めて有益なものになると確信しています！昨年末ごろから充実してきたcortex関数群を触るようになって、Aggがあれば・・・と妄想してきた機能がついに現実に！

AI_AGGの使い方の基本

従来のSQL

-- 商品別の満足度（平均値）を並べて好評な製品を調べる。
-- ただし、この裏には「満足度をスコア化してsatisfaction列に書き込んでおく」
-- という事前準備が必要
SELECT product,avg(satisfaction) FROM review_comment
GROUP BY product;

先の例と同じように満足度列を扱いますが、今度は満足度の高いコメントそのものを抽出するのではなく、商品別の満足度を調べることにします。

AI SQL（AI_AGG）

-- 商品別の満足感に関するコメント解析し説明する文章を生成（実際には英語）
SELECT
   product,
   AI_AGG(comment,'商品の満足調査コメントです。
   満足度を判断し、満足度を根拠にどのようなプロモーションが効果的か考えてください。')  AS report
FROM review_comment
GROUP BY product;

このクエリの応答は以下のようになります。

注：2025年6月現在、AI SQLに対するプロンプトは基本的には英語が推奨され、応答も英語になります。

このコメントを人が導出するまでにどのような分析が必要でしょうか。

• 平均点が高ければAのような回答はできますが、スコア化する前の情報を知らないと冷めているレビューを考慮してプロモーションの工夫をすることはできません。
• 好みが分かれる商品は平均点では正しい理解ができず、最大/最小や値の分布といった他の集計も並べることでこのようなレポートが書けます。
• コメント件数が少ないものは例えばクレープのような手に持って食べる商品でリアルタイムにコメントしづらいなど事情があるかもしれません。それであれば食べ終わった直後を狙うコメント応募キャンペーンをやるような対策ができます。

これを一つの指示で全部やってくれるのがAI_AGGの能力です。対象列のすべての値を対象に、一つの答えを導いてくれています。感覚的には集計関数の動き通りなのですが、単一の値に縛られず色々な観点を持ってグループの特徴を捉えてくれるのはやってみて実感した驚きポイントでした。

AI_AGG実践

エクスチュアでは、顧客のマーケ支援を行うという立場ですので、Googleアナリティクス等のデータを用いて、ウェブサイトを来訪したある人がどのような振る舞いをしてコンバージョンに至ったかを分析するといったユースケースを考えてみました。

簡略化したサンプルデータ

同一のユーザーセッションが数日のうちに繰り返し発生しており、timestampは数分ずつ差があります。これはtraffic_sourceにあるようにウェブ検索や、SNS等での広告閲覧といったいろいろな経路からサイト来訪があることを模しており、最終的に「初回キャンペーン応募」と言うコンバージョンに至ったことを示しています。上記の例ではXで広告を見て気になってきてくれたのでしょう、数分後に改めてGoogle検索から来訪し、応募までしてくれたというデータになっています。

従来のSQL

これをセッションごとにグループ化して分析してみます。

-- 異色の集計関数、array_aggを使ってtraffic_sourceを横並びに変換
SELECT session_id, array_agg(traffic_source)
FROM ga4_event
-- 「初回キャンペーン応募」に至った人だけ抽出
WHERE session_id in (
    SELECT session_id
　FROM ga4_event
　WHERE event = '初回キャンペーン応募'
)
GROUP BY session_id;

array_aggとは文字列でも数値でも、集計前の各行のデータを配列として1フィールドに収める関数で、上記のような応答が得られます。

AI SQL以前であってもこれをさらにcortex LLMのcomplete関数のインプットとすることで、「x ⇒ googleときてコンバージョンに至ったようです」のような説明をしてくれることでしょう。本投稿の流れでいうところの、「スコア化」してきた部分とは、completeの手前までなので、このtraffic_sourceを時系列順に並べた配列にしておくというデータマート作成までを事前にやってきたのと言い換えられます。

AI SQL（AI_AGG）の例

ではそのarray_agg化という事前準備を省いて、AI_AGGに置き換えてみましょう。

-- 異色の集計関数、array_aggを使ってtraffic_sourceを横並びに変換
SELECT session_id
　　　, AI_AGG(traffic_source,'We are listing the traffic sources that led to conversions.
　　　  Please explain how the sources changed over time.') 
FROM ga4_event
-- 「初回キャンペーン応募」に至った人だけ抽出
WHERE session_id in (
    SELECT session_id
　FROM ga4_event
　WHERE event = '初回キャンペーン応募'
)
GROUP BY session_id;

現在のAI SQLでは英語プロンプトが推奨されています。応答も英語ですが、以下のようなものが実際に返ってきました。

細かくて読み取りづらいですが、あるセッションについての時系列の動きをちゃんと説明してくれています。例えばある1行についての説明を抜粋すると

Traffic Source Analysis Summary
After analyzing the provided data, I observed the following trends and patterns:

1. Dominance of Unknown Sources: The majority of traffic sources (24 out of 30) are listed as “”(not set)””, indicating that the source of the traffic is unknown or not tracked. This suggests that there may be a gap in tracking or reporting of traffic sources.
2. Twitter (t.co) Presence: Twitter (t.co) is the only identifiable traffic source, appearing three times in the dataset. This indicates that Twitter is a notable source of traffic, although its overall impact is limited compared to the unknown sources.
3. Google Emergence: Google appears twice in the dataset, indicating that it is a growing source of traffic. Although its presence is limited, it is a notable development, suggesting that search engine optimization (SEO) efforts may be paying off.
4. Lack of Diversity: The dataset lacks diversity in terms of traffic sources, with only two identifiable sources (Twitter and Google) and a large proportion of unknown sources.

Recommendations

1. Improve Tracking and Reporting: Efforts should be made to improve the tracking and reporting of traffic sources to reduce the number of unknown sources.
2. Optimize for Twitter: Given Twitter’s presence in the dataset, optimizing content and advertising efforts for Twitter may help increase traffic from this source.
3. Enhance SEO Efforts: Building on the emergence of Google as a traffic source, enhancing SEO efforts may help increase organic traffic from search engines.

By addressing these recommendations, it is possible to gain a better understanding of traffic sources and make data-driven decisions to optimize marketing efforts.”

（和訳）

トラフィックソース分析の概要

提供されたデータを分析した結果、以下のような傾向とパターンが見られました：

1. 不明なソースの優勢
   　30件中24件のトラフィックソースが「(not set)」と表示されており、トラフィックの出所が不明または追跡されていないことを示しています。これは、トラフィックソースの追跡またはレポートにギャップがある可能性を示唆しています。
2. Twitter（t.co）の存在感
   　Twitter（t.co）は、データセット内で唯一識別可能なトラフィックソースで、3回登場しています。これは、Twitterが注目すべきトラフィック源であることを示していますが、その影響力は不明なソースに比べて限定的です。
3. Googleの出現
   　Googleはデータセット内に2回登場しており、新たなトラフィック源として浮上していることがわかります。まだ数は少ないものの、これは検索エンジン最適化（SEO）の取り組みが成果を出し始めていることを示唆しています。
4. 多様性の欠如
   　このデータセットはトラフィックソースの多様性に欠けており、識別可能なソースはTwitterとGoogleの2つだけで、大部分は不明なソースに分類されています。

提案事項

1. トラッキングとレポートの改善
   　不明なソースの数を減らすために、トラフィックソースのトラッキングとレポート体制の強化が必要です。
2. Twitterの最適化
   　Twitterが一定の存在感を示していることから、コンテンツや広告施策をTwitter向けに最適化することで、さらなる流入増加が見込めます。
3. SEOの強化
   　Googleの出現を踏まえ、SEO施策をさらに強化することで、検索エンジンからのオーガニック流入を増やすことができるでしょう。

これらの提案に取り組むことで、トラフィックソースの把握が進み、データに基づいたマーケティングの最適化が可能になります。

( ..)φメモメモ

まず不明なソースを埋めろ！話はそれからだ！とご尤もな指摘をいただいてしまいました。でもちゃんとtwitterやgoogleから来てることも触れてくれています。

AI_AGG応用：WINDOW関数との組み合わせでマーケ分析に革命は起きるか？！

1つのSQLで集計値としてのAI応答を得られるなんて！AIの準備は整った！！！
あとはGROUP BYの使い方次第、SQL脳の出番です。何を対象に集計値を生み出すのか？が大きなカギになってきそうです。

上記のシナリオには穴があります。例えば、1人がECサイトで毎週1回商品を購入しているとします。人によっては月イチなので、集計の粒度としては、月別-人別ぐらいがよさそうですが、この毎週購入してる人については、同月中に商品Aの「興味～検索～購買」に至り、翌週は商品B、さらに翌週は商品Cと同月内にデータが存在します。月をまたいで検索していたかもしれません。

このようなときに有益なのがウィンドウ関数です。

ウィンドウ関数では、まずは「人単位のデータを時系列に並べたパーティション」を作ります。次にそのパーティション内で分析対象の塊を表すウィンドウを定義します。デフォルトではパーティション＝ウィンドウになりますが、1件ずつスライドするウィンドウフレームを定義してパーティション内のより柔軟な単位を集計対象として扱うことができます。

• パーティション定義：ユーザー別に時系列にソートしたデータセット
• フレーム定義　　　：商品を購入した時点から前1週間分をフレームとして定義
• 集計の実行　　　　：各フレームに対する集計関数の適用

商品Aの購入を起点に前1週間でどんな振る舞いをしていたか。商品Bの購入以前はどうか？という視点で、ユーザー別月別という固定の期間での分析ではなく、重要イベントの前後x日といった流動的な期間に発生したデータを分析対象にできます。

悲報：AI_SQLはウィンドウ関数呼び出しに非対応

SELECT
            :
     ,ROW_NUMBER() OVER (PARTITION BY e.user_pseudo_id ORDER BY event_timestamp ASC) AS rn
     ,AI_AGG(traffic_source,'We are listing the traffic sources that led to conversions.
                   Please explain how the sources changed over time.')
      OVER (PARTITION BY e.user_pseudo_id ORDER BY event_timestamp ASC) AS ai_summary
             :

だいぶ省略したウィンドウ関数の抜粋ですが、

とのことで、ウィンドウ関数を用いた高度な分析対象指定と、それぞれに対する「AI SQLによる説明」は今日の所はお預けとなりました、無念！！！

Snowflakeさん！

この機能は、単純GROUP BYした結果を対象にするだけでは、SQL側に任せる価値が低く、アナリストは慣れ親しんだPythonで書けば済むじゃん！となってしまうことが容易に想像つきます。

高度な集計を伴うウィンドウ関数では大量データに対する繰り返し処理を何度も行います。こういった最もヘビーな部分の実行こそをSnowflakeのパワフルなコンピュートに任せ、それをpython側に渡すことなくいつのまにか示唆が得られていることがAI SQLの最大の魅力だと思います。ぜひAI_AGGのウィンドウ関数呼び出しに対応をお願いしたいところです。