セマンティックビューとは
Snowflake の Semantic View は、データベース上にビジネスロジックを定義する新しい仕組みです。
これにより、テーブル間の関係性（RELATIONSHIPS）、分析軸（DIMENSIONS）、集計定義（FACTS・METRICS）を「意味付けしたレイヤー」として Snowflake 上に構築できます。
なぜ必要なのか
近年は、AIが発達し自然言語をスタートとしてクエリを生成したり、よりドキュメントの重要性が再認識されている時代です
ドキュメントがないと、そもそもAIは正しい回答を出すことができない
例えば、「A商品の2026年2月の売り上げを計算して」と命令するケースを考えるとします。
ここで、いくつか暗黙的な疑問があることを挙げていきます。
→「売り上げ」とは単純に「数×単価」なのか
→ キャンセル分はどうするのか
「暗黙値」というのは、AI活用における主な弊害といえます。
このようなビジネス概念を１つのビューにまとめてしまおうというのが、
「セマンティックビュー」になります。
以下の記事にも記載されていますが、セマンティックビューとdbtは親密な関係があり、
dbtを活用することで、便利にセマンティックビューを構築できますが、今回では、セマンティックビューの構築方法をメインにお話していきます。
この記事でも、セマンティックビューをより実務で活用する方法を記載しています。
DDLに詳細に書くではダメなのか？
個人的に最初に疑問に思ったことでした。
私自身、DDLによりそのオブジェクトがどんなものか、ドキュメントを細かく記載する上で、DDLに詳細に書いていましたが、調べてみると、AIを活用する上でメリットがあることがわかってきました。
セマンティックビューを追加することで、管理対象が増えることは、デメリットにもなりますが
将来のAI活用においては、恩恵を受けやすいため、実装を検討することをお勧めしたいと思います。
AI上でのメリット
セマンティックビューは、AIの橋渡しにもなります。
ドキュメントをDDLにまとめることで、AIがよりDDLの理解がしやすくなります。
そのため、自然言語で質問をした時に、より質の高い回答ができるようになります。
AI統合のメリット詳細
| メリット | 説明 |
|---|---|
| ✅ クエリ精度の向上 | ビジネス用語と技術用語の直接マッピング |
| ✅ ユーザビリティの向上 | 技術知識不要で自然な質問が可能 |
| ✅ AI開発コストの削減 | AIモデルの追加学習が不要 |
| ✅ プロンプトの簡素化 | 詳細な説明不要、シンプルな質問で対応 |
| ✅ ビジネスロジックの透明性 | メタデータでロジックが明示される |
セマンティックビューの構築
事前知識
以下で構成することができます。
CREATE <OR REPLACE> SEMANTIC VIEW <セマンティック名>
セマンティックビューを構築する方法は2通りあります。
・SQLベース
・YAML形式
どちらが良くて、どちらがダメという話ではなく、チームによって使い分けることを推奨します。
2つの観点から比較してみます。
1.開発・運用面の比較
| 項目 | SQLベース | YAML形式 | 優位性 |
|---|---|---|---|
| 学習コスト | 🟢 低い（標準SQL） | 🟡 中程度（YAML構文を学習） | SQL |
| 実装の容易さ | 🟢 簡単（CREATE VIEW） | 🟡 中程度（YAML作成+アップロード） | SQL |
| バージョン管理 | 🟢 DDLスクリプトで管理 | 🟢 YAMLファイルでGit管理 | 同等 |
| デプロイ方法 | 🟢 SQLスクリプト実行 | 🟡 ステージアップロード+参照設定 | SQL |
| 更新の即時反映 | 🟢 CREATE OR REPLACEで即座 | 🟡 ファイル再アップロード必要 | SQL |
| 権限管理 | 🟢 標準的なVIEW権限 | 🟡 ステージ権限+ビュー権限 | SQL |
| デバッグのしやすさ | 🟢 SQLで直接確認可能 | 🟡 YAMLパースエラーの確認が必要 | SQL |
2. 高度な機能の比較
| 機能 | SQL | YAML形式 | 優位性 |
|---|---|---|---|
| 自然言語クエリ（Cortex Analyst） | ⚠️ 基本的な対応のみ | ✅ 完全対応（同義語、集計ルール） | YAML |
| 複数テーブルの関係性定義 | ❌ JOINで暗黙的 | ✅ 明示的なリレーション定義 | YAML |
| 計算メジャーの定義 | ✅ SELECT句で定義 | ✅ measuresで定義 | 同等 |
| フィルター条件の事前定義 | ❌ WHERE句で毎回指定 | ✅ default_filtersで定義 | YAML |
| 時系列分析のサポート | ⚠️ SQLで実装 | ✅ time_dimensionsで構造化 | YAML |
| データセキュリティ | 🟢 Row Access Policyなど | 🟢 同様に適用可能 | 同等 |
より高度なAI活用ならYAML,初期段階についてはSQLベース
SQLベースでは、実装までにそこまでコストはかからないかと思います。
定義書を細かく管理しているチームであれば、なおさら実装コストは少ないと思います。
最後に
これから現場で非エンジニアでも、データに扱えることができる準備ができればと考えておりますので、
引き続き、精進できればと思います。
この記事が少しでもいいなと思いましたら、ぜひリアクション頂けますと幸いです。