「6月の売上」は答えられるのに、「顧客LTV」では間違える
「SQLってAIでどうやって作ればいいんですか」。ほんの2、3か月前、エンジニアからそう尋ねられたことがあるという。そう明かしたのは、SnowflakeでLead Developer Advocateを務める田中翔氏だ。tshoというハンドルで活動し、AI/MLとデータ領域の登壇やデモ開発を担当している。
問いを裏返せば、正しいテーブル定義さえ渡せばLLMは正しいSQLを書いてくれるのか、ということになる。田中氏は小売業を模したベンチマーク用データベースであるTPC-DSを使い、この前提を検証した。投げた質問は3つ。「6月の売上合計は？」「ブランド別売上は？」「顧客LTVは？」である。
結果は2勝1敗に分かれた。前の2問は、DDLだけを渡した場合でも正しいSQLが生成された。テーブル定義には外部キー制約が書かれており、どのテーブルをどう結合すべきかはそこから推論できるためだ。ところが3問目の顧客LTV（ライフタイムバリュー）で、生成されたSQLは誤った計算をした。
理由は単純である。LTVは「売上÷ユニーク顧客数」で求めるという計算ルールが、DDLのどこにも書かれていないからだ。「LLMは知らないわけですから。知らないことを分かってほしいというのは、やはり難しい」と田中氏は言う。
同じ問題は、カラム名の解釈でも起きる。田中氏が挙げたのは、TPC-DSの売上テーブルにあるss_sales_priceとss_ext_sales_priceという2つのカラムだ。どちらが実際の「売上」を指すのか、DDLからは判別できない。
これは架空の例ではない。「カラムの継ぎ足しを重ねていて、2つ以上に売上とついたカラムがあり、どちらが今使いたい売上に関するカラムなのか？ ということがよくありました」。田中氏は事業会社にいた当時の実感をそう振り返る。更新を重ねるうちに、どちらが正しい売上を表すのか誰にも分からなくなる。多くの読者が心当たりのある光景だろう。
田中氏は原因をこう一般化した。DDLはデータの「形」のみを定義するもので、「意味」、すなわちビジネスルールや計算式は定義しない。同義語も、社内固有のKPIの算出ロジックも、そこには存在しない。
つまりこれは、LLMの性能の問題ではない。モデルに与えるコンテキストが欠けているという設計の問題である。だとすれば、欠けている「意味」をどう記述して渡すかが論点になる。
意味を規格化する動き──Open Semantic InterchangeからApache Ossieへ
その「意味」の記述形式を、企業をまたいで共通化しようという動きが進んでいる。2025年にSnowflakeが提唱したOpen Semantic Interchange（OSI）である。GitHub上のリポジトリは2025年11月に公開され、Apache 2.0ライセンスのもとで仕様策定が進む。当初の創業パートナーから、現在は50社以上へと参加が広がった。
参加企業の顔ぶれは、データ基盤とBIの主要プレイヤーをほぼ横断している。Salesforce、dbt Labs、ThoughtSpot、Mistral AI、BlackRock、Atlan、Sigma、Hexなどが名を連ねる。掲げる原則は3つで、定義のための統一言語をつくる「標準化」、シームレスなデータ変換を促す「相互運用性」、データニーズの変化にモデルを適応させる「拡張性」だ。
そして7月、このOSIがApache Software Foundationのインキュベータープロジェクトに採用された。同時に名称がApache Ossie（Incubating）へと変わっている。OSIという略称がオープンソースの世界で別のプロジェクトと重なるため、混同を避けるための改名だという。
実務上の注意点として、田中氏は表記の混在を挙げた。改名は完了しているものの、ドキュメントやWeb上には旧OSI表記の名残がまだある。「Apacheの下に入っているので、そこと間違えないようにしてください」。調べる際は、仕様はGitHubのapache/ossie、最新情報はApache Ossie公式サイトを起点にするのが確実だ。
