YAML定義書には何を書くのか
では、その定義書には何を書くのか。田中氏が用意したretail_model.yamlは、Apache Ossie公式リポジトリのTPC-DS向けサンプルを土台にしたものだ。冒頭のversionは0.2.0.dev0。仕様がまだ策定途上であることが、バージョン番号にそのまま表れている。
ファイルの構成は大きく3つに分かれる。テーブルの所在とプライマリキー、各カラムの説明を記述するdatasets、テーブル間の結合を定義するrelationships、そして指標の計算式を書くmetricsである。SQLの方言も指定でき、この定義書ではANSI_SQLが使われている。
目を引くのはai_contextという欄だ。ここには自然言語でAIへの指示を書ける。田中氏の定義書には、「Salesまたはrevenueは常にSUM(ss_ext_sales_price)を意味し、SUM(ss_sales_price)ではない」という一文が明記されている。1ページ目で判別できなかった2つのカラムの正体もここで分かる。前者が単価、後者が数量と単価をかけた明細行の合計金額であり、売上として集計すべきは後者だ。
version: "0.2.0.dev0"
semantic_model:
- name: tpcds_retail_model
ai_context:
instructions: >
Use this semantic model for retail analytics queries.
Key rules:
- "Sales" or "revenue" always means SUM(ss_ext_sales_price), NOT SUM(ss_sales_price).
ss_sales_price is the unit price; ss_ext_sales_price is the extended (total line) amount.
- "Profit" means SUM(ss_net_profit).
- Always join fact table store_sales to dimension tables using the surrogate key relationships defined below.
# （中略：datasets、relationships の定義が続く）
metrics:
- name: total_sales
expression:
dialects:
- dialect: ANSI_SQL
expression: SUM(store_sales.ss_ext_sales_price)
description: Total sales revenue (extended price, not unit price)
- name: customer_lifetime_value
expression:
dialects:
- dialect: ANSI_SQL
expression: SUM(store_sales.ss_ext_sales_price) / COUNT(DISTINCT store_sales.ss_customer_sk)
description: Average total revenue per unique customer
ai_context:
synonyms:
- "CLV"
- "LTV"
- "customer value"
肝になるのはmetricsだ。売上合計だけでなく、LTVを「売上合計÷ユニーク顧客数」として式で明記する。従業員1人当たりの売上を表す店舗生産性のような指標も、同じ形式で定義されている。
そしてsynonyms、いわゆるシノニムの欄がある。CLVとLTVと顧客価値は同じ指標だと書いておけば、どの語で聞かれても同じ計算で答えが返る。指標の呼び名が部署ごとに違う現場ほど、この効き目は大きいだろう。
なお、仕様はまだ発展途上だ。田中氏は未収載の機能としてVerified Query、人間が正解と確認したクエリを検証用に保持する仕組みを挙げた。共通規格であるため、仕様の追加はGitHubやメーリングリスト上での公開議論を経て、正式な投票プロセスで決まっていく。投票に加わるコミッター権限は所属企業ではなく貢献によって得られる。
「プルリクエストやイシューなどで活発に議論されており、今後ますます発展していくことが楽しみです」という言葉どおり、いま仕様を読んでおくこと自体が議論への参加につながる段階にある。
自動化するなら実行層へ──SnowflakeのSemantic ViewsとCortex Analyst
最後に田中氏は、標準化の対象外であるセマンティックレイヤー側の実装例として、自社の取り組みを紹介した。Snowflakeでこの層に該当するのがSemantic Viewsである。
ポイントは、レイヤーを事前に登録しておける点だ。デモで見たようにプロンプトへ毎回定義を丸ごと入れる必要がなく、質問に必要な箇所だけが使われる。プロンプトが長くなるという先のトレードオフに対する答えがこれである。精度の評価機能も用意され、Verified Queryを使ってどの程度正確に答えられているかを測れる。
具体的なサービスとしてはCortex Analystが挙げられた。Apache Ossieにほぼ準拠したYAMLファイルをアップロードすればセマンティックモデルが登録され、それを基にレイヤーが構成される。田中氏が動画で示したデモでは、「商品カテゴリーごとの6月から8月までの売上トレンドを表示してください」という日本語の問いに対し、DDL全体を毎回送ることなく最適化されたSQLが生成された。データがSnowflakeの境界を離れず、既存のRBACと統合される点もフルマネージドサービスの利点として説明された。
田中氏が示した持ち帰りは2段階だった。まずApache Ossieの仕様を確認し、手元で試す。そのうえで、自力での運用が負担になるならセマンティックレイヤーを実装したツールで自動化・最適化を検討する。順序が逆でないことに意味がある。渡すべき「意味」を自分たちの言葉で書けているかどうかが先で、実行基盤の選択はその次だ。
「DDLだけでは不十分だということが、ご理解いただけたかと思います」。田中氏はそう締めくくった。自社のKPIの計算式が、いまどこに書かれているかを思い出せるだろうか。それが誰かの頭の中にしかないのなら、AIエージェントにも同じことが起きている。
Snowflakeからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
