はじめに
最近、多くの企業でAI活用が急務となっています。なかでも重要なのは、自社のデータをAIに正しく理解させるための整備です。データそのものが存在しても、AIが意味を誤解してしまえば、十分に活用できません。
そこで注目されているのが「セマンティックモデル」です。Snowflakeにおいては「セマンティックビュー」と呼ばれ、この設計と準備こそがAI活用の成否を大きく左右します。言い換えれば、セマンティックビューをどれだけ適切に整備できるかが、AIを武器に変えるためのカギになるのです。
そこで今回は、Snowflakeのセマンティックビューの設定について、特にカラムの説明部分でいくつかのパターンを作成し、自然言語からSQLに変換する精度を検証してみました。
セマンティックビューとは
セマンティックビューは、AIがSQLを生成する際の「文脈定義」のようなものです。
例えば、ユーザーがAIに対して「8月の売上を教えて」と質問した場合に、正しい値を出力させるために以下の様なルールをAIが知っている必要があります。
- 「8月」＝「Date」カラムの"2025-08-01 ~ 2025-08-31"
- 「売上」＝「Sales_Amount」カラムの値
このようなルールを定義する場所がセマンティックビューとなります。
具体的な設定内容は以下の通りです。
Custom Instruction
自然言語をSQLに翻訳するときの「解釈ルール」「追加の前提・制約」「デフォルト動作」などを指定。GPTのシステムプロンプトの様なもの。
Table
元となるテーブルのディメンションやファクト（メジャー）に対して、説明やサンプル値を定義する。今回検証したのはこちらです。
Relation
ジョイン条件や多対一／一対多の構造を指定。AIが「どう結合すべきか」を明確にする。
Verified Queries
あらかじめ定義・検証されたSQLクエリをセマンティックビューに登録できる。このようなインプットがあったらこのクエリを実行して、のような指示。
検証内容
今回は設定項目が多く、出力に大きく影響すると考えられるTableをいくつかのパターンで作成し、それぞれに同じ質問を投げかけて出力の違いを比較することで検証しました。
使用データ
食料品の売り上げデータ
Tableの設定項目
Tableの各ディメンションやファクト、メトリクスには以下の項目を定義・設定できます。
- Expression（論理名）
- Name（物理名）
- Data type（データ型）
- Description（説明）
- Synonyms（類義語）
- 「AREA_NAME」というカラムに対する「エリア」「エリア名」など
そのカラムに関連するキーワード
- 「AREA_NAME」というカラムに対する「エリア」「エリア名」など
- Is enum（列挙型）
- Connect Cortex Search
- Cortex Searchと紐づける場合は選択
- Sample values（カラムのサンプル値）
今回は Description（説明） を変更して検証しました。それ以外の項目はすべて同じものを定義しております。
作成パターン
| No. | 設定内容 | 仮説 |
|---|---|---|
| 1 | 説明を記入しない（0 words） | 説明を記入しないとAIの精度が落ちるのではないか |
| 2 | 説明を記入（英語で 約30 words） | 1‐2文程度の説明が適切なのではないか |
| 3 | 説明を豊富に記入（英語で 約100 words） | 説明を必要以上に記入しすぎると、AIの精度が落ちるのではないか |
| 4 | 日本語カラム・日本語説明 | （セマンティックビューでは現状英語カラムしか対応していないので）元のテーブルを日本語カラムにして日本語で説明を書くとAIの精度が落ちるのではないか |
投げかける質問は以下です。
「多くの店舗で売れている商品の傾向を教えて」
結果と考察
先にネタバレになるのですが、AIの出力内容自体は、4つのパターンでほとんど差異がないという結果になりました。説明を書く・書かないに関わらず、AIはデータの中身まで見て結論を出してくれていました。
しかし、結論に至るまでの過程の部分、AIの思考プロセスをログで見てみると、それぞれ違った考え方で結論を導き出していたので、ここからはそこを解説していきます。
パターン① 説明なし（0 words）
AIによる考察
高カバー率商品の特徴：
必需品性: 日常的に消費される基本商品
価格適正性: ○○円前後の購入しやすい価格帯
ブランド認知: 消費者に広く認知された商品
季節性の低さ: 年間を通じて安定した需要
在庫リスクの低さ: 回転率が高く在庫負担が少ない
これらの傾向から、全店舗展開に適した商品は「日常的な必需品」「適正価格」「高い認知度」を兼ね備えた商品であることが分かります。
なるほど考察としては、確かにそうだろうなという結果になっています。
ログを見てみると、気になる点が２つありました。
まず、最初に必要なカラムを洗い出していたのですが
こちらの画像にある通り、売上店舗カバー率を一発で取得してくれました。
しかし説明を何も記入していないのに、なぜこのカラムが必要だと分かったのだろうと疑問が浮かびます。そこで詳しく見てみると、事前にSynonyms（類義語）に「売上店舗カバー率」という文言を入れておいたところから引っ張ってきていることが分かりました。
つまり、AIは 「多くの店舗で売れている商品」から「これは売上店舗カバー率のことを指しているな」と判断し、このカラムを取得したということになります。
率直に
え？結構頭良くない？すご。
と思いました。
一方で、以下の画像の様に、いらないカラムも全て取得していたりもして、ここでは余計に時間とクエリコストがかかってしまっているので、やはり説明はある程度記入する必要がありそうです。
パターン② 英語で簡潔な説明（約30 words）
AIによる考察
主な傾向
1.日用必需品の特性: 店舗カバレッジが高い商品は、水、お茶、炭酸飲料など日常的に消費される商品が中心
2.低価格・高頻度商品: 平均価格が比較的低く（○○円台）、消費頻度が高い商品が多い
3.ブランド商品の優位性: 上位商品には「」など有名ブランドが多数
4.基本食材の重要性: 乾麺（そば、うどん）や調味料など、料理の基本となる商品も高いカバレッジを示す
5.季節性の少なさ: 高カバレッジ商品は年間を通じて安定した需要がある商品が多い
この分析から、全店舗に対する売上店舗の割合が高い商品は、「日常必需品」「低価格」「高頻度消費」「有名ブランド」という特徴を持つ傾向があることがわかります。
このパターンは特筆すべきことはあまりないですが、不要なカラムは取得しておらず、一つ前のパターンと比較して効率的に結果を出していることが分かります。
パターン③ 英語で詳細な説明（約100 words）
AIによる考察
主要な傾向まとめ
生活必需品が中心：飲料、乾麺、調味料など日常的に消費される商品
低価格商品が優位：100円未満の商品が最も高いカバレッジを示す
飲料の圧倒的な存在感：特に低価格帯で飲料が多数を占める
基本食材の重要性：粉、農産乾物、水産乾物など料理の基本となる商品
安定需要商品：季節や嗜好に左右されにくい商品が高カバレッジを維持
これらの結果から、店舗カバレッジが高い商品は「日常的に必要で、価格が手頃で、どの店舗でも基本的に置いておくべき商品」という特徴を持つことがわかります。
このパターンでのAIの処理内容には、１つ特筆すべき点がありました。
実は今回元となっているテーブルのDate型のカラムは、日付型ではなく文字列型なのですが、WHERE句で期間指定をする際にちゃんと"YYYY年MM月DD日"の形で期間指定ができています。（つまり、日付の比較ではなくアルファベット順で疑似的に日付比較をしている）
他のパターンのモデルでは、まず最初にここで躓いており、以下の様な挙動を見せておりました。
最初にクエリを走らせる⇒結果が0件です⇒よく見てみると日付指定のフォーマットが違っておりました⇒修正して再度クエリを行います
そもそもアルファベットでの疑似比較ではなく、ちゃんと元テーブルを日付型で格納しろよという話ではあるのですが、、、
ただ、今回の検証では説明を詳細に記載したこのパターンが一番パフォーマンスが良く効率的に結論にたどり着いておりました。
パターン④ 日本語カラム・日本語説明
AIによる考察
2. 主要な傾向：
日用必需品の特徴：飲料、乾麺、調味料など日常的に消費される商品が高い店舗カバー率を示している
価格帯の特徴：店舗カバー率が高い商品は比較的手頃な価格帯（○○円程度）に集中
商品多様性：○○カテゴリが最も多くの商品数（品目）を持ち、幅広い選択肢を提供
3. 具体的な高カバー率商品例：割愛
4. ビジネス上の示唆：
店舗カバー率が高い商品は、消費者の日常的なニーズに応える基本商品
○○カテゴリは特に全店舗展開に適した商品群
価格帯は消費者にとって購入しやすい範囲に設定されている
この分析結果から、店舗カバー率が高い商品は「日常必需品」「手頃な価格」「安定した需要」という共通特徴を持っていることが分かります。
このパターンでも特徴的な挙動が見られました。
まず最初に必要なカラムを取得してクエリを走らせたのですが、エラーになり、その後に以下の様な思考をしています。
ここで、日本語の列名を使用していたため結果が0件になっている、と考えておりますが、AIが実行したクエリを私の方で確認したところ実際にはそうではありませんでした。
エラーの原因は、上記で記述した日付指定のフォーマット違いだったことで、日本語カラムであることは関係しておりません。ここでAIは勘違いをしていることになります。
このことから、元のテーブルを日本語カラムにしてしまうと、AIを混乱させてしまうことになり、結果としてエラー原因の特定に時間がかかってしまいました。
今回の検証では最終的な出力結果に大きな違いは生まれませんでしたが、やはり元のテーブルのカラム名も英語にしてセマンティックビューと合わせた方が良さそうです。
まとめ
今回の検証内容をまとめました。
| パターン | 回答時間 | 仮説 | 結果 | 結論 |
|---|---|---|---|---|
| 説明を記入しない（0 words） | 141.8秒 | 説明を記入しないとAIの精度が落ちるのではないか | 出力精度は大きくは下がらない。不要なカラムを選択したりと、クエリに無駄が発生。 | △ |
| 説明を記入（英語で 約30 words） | 102.6秒 | 1‐2文程度の説明が適切なのではないか | 出力精度は他とそれほど変わらない。 | ○ |
| 説明を豊富に記入（英語で 約100 words） | 75.2秒 | 説明を必要以上に記入しすぎると、AIの精度が落ちるのではないか | 出力精度は下がらない。クエリのミスが少なく、回答時間が短い。 | ◎ |
| 日本語カラム・日本語説明 | 119.6秒 | （セマンティックビューでは現状英語カラムしか対応していないので）元のテーブルを日本語カラムにして日本語で説明を書くとAIの精度が落ちるのではないか | 出力精度は大きくは下がらない。エラーの原因特定に無駄が発生 | △ |
まとめると、セマンティックビューのDescription（説明）では 「英語で100 Words程度の説明」 を設定するのがベストプラクティス だと分かりました。
Snowflakeで自然言語クエリを活かしたい方は、是非セマンティックビューを自分の手で試してみてください。新しい発見が必ずあるはずです。