最近、Text-to-SQL という技術が注目されています。複数のテーブルデータに対して自然言語で質問すると、その質問の回答に必要なデータの取得・集計などをしてくれる技術です。BI ツールの使い方や SQL の書き方に詳しくない人でもデータ分析できるという点で重要な技術です。
ただ、Text-to-SQL 自体やその周辺技術に関していろいろ思うところもあるので、つらつらと書いていきたいと思います。特に技術検証記事ではないポエムに近い内容ですが、ご容赦ください。
0. サマリー？
- Text-to-SQL がサポートしないデータ分析のプロセスや作業、ユーザー層は結構広いのでは？
- Text-to-SQL を実現するために必要なメタデータは、テーブル/カラムのビジネス名称や意味だけではなく、もっと多いのでは？
- Text-to-SQL が必要とするメタデータはどこで定義するのが良いのか？
1. Text-to-SQL がサポートするデータ分析の範囲
まず、Text-to-SQL がデータ分析のどの部分や領域をサポートしているのか or いないのかについて、個人的な考えを述べていきます。
1-1. 仮説立案とかデータ解釈とかアクション検討とか
データ分析、特に BI ツールが想定する分析の流れは、かなりシンプルにすると以下のようになると思っています。
- 分析仮説の検討
- よく言われる話ですが、目的なくデータを眺めていても迷走するので、現状のビジネス課題やその原因にまず当たり（＝仮説）を付けるということが必要になります。
- データの集計
- 立てた仮説が正しいか否かをデータという事実に基づいて把握するため、必要なデータを取得し、理解できるように集計します。
- 結果の解釈と仮説判定
- データの集計結果はただのデータの羅列（数字、文字の並び）でしかないので、そのデータを読み解いてビジネスとして何が起きているのかという意味付けをし、その上で最初に立てた分析仮説が正しいか判断します。
- 次のアクション検討
- 分析仮説が正しいと判断した場合、具体的なアクションを検討することになります。アクションを具体化するためにさらにデータを確認するということもあります。
- 分析仮説が正しくないと判断した場合、分析仮説の検討に戻り、ビジネス課題について別の原因などの仮説を立てて、再度データ分析を行います。
このうち、Text-to-SQL がサポートするのって、2. と 3. のかなり前半だけなのかなと思っています。
実際のデータ分析では 1. の分析仮説の立案でつまづくユーザーは結構多いですね（特に複数の業務からなる複雑なビジネスの場合）。ちゃんとした分析仮説を立てるまでデータを一切見るなという意見には個人的に反対なのですが、とはいえ何の当てもないとだらだらとデータを見てしまうことにもなるので重要なステップです。ただ、一般に言われる Text-to-SQL がサポートする範囲ではないですね。
また、3. の結果の解釈と仮説判定に関しては、集計結果から何が言えるかを説明してくれる Text-to-SQL はいくつかあります。ただし、
- 解釈するにも数値の計算や比較などが（事前に集計されていたとしても）必要だが、LLM ではまた部分的にしかできない
- （なぜか時系列的な傾向把握は結構できるので不思議ではあるのですが）
- 解釈が正しくても、当たり前で注目に値しないことと、注目すべきことの区別が難しい（区別するためのコンテキストを与える必要がある）
などがあり、個別対応が必要な領域かなと思います。
最後の 4. に関しても Text-to-SQL がサポートする範囲ではないですね。
以上の点で、Text-to-SQL は必要なピースの 1 つだと思っていますが、まだまだ乗り越えるハードルは多いよねと思っています。
1-2. データ集計に付随する作業
たまに、「Text-to-SQL でデータの集計や可視化ができれば BI ツールはいらないよね」みたいな意見を見かけることがあります。しかし、BI ツールって集計・可視化だけをサポートしている訳ではないんですよね。例えば、
- 集計/可視化結果の保存（データとして / クエリとしての両面）
- 集計/可視化結果の他のユーザーへの共有（アクセス許可など非機能面の話から、通知/コメント付与などのコミュニケーション機能まで多岐に渡る）
- 集計/可視化結果の自動更新やアラート
- Excel や PDF などへのエクスポート
- ユーザートラッキング分析（誰がどういう分析をしているか）
などなど挙げるとキリがないです。
このあたりがない中で、自然言語で質問して集計結果やチャートが返ってきますだけだと、従来の BI ユーザーには受け入れられづらいのではと思っています。
1-3. Text-to-SQL で救えるユーザー
そもそもとして Text-to-SQL で救えるユーザー層ってどのような人たちなのでしょうか。
あまりユーザーをステレオタイプで分類するのは好きではないのですが、今回は以下のように分類して考えてみます。
- 経営者
- 組織全体の経営状態や市場の動向といった非常に広い範囲のデータを俯瞰的に素早く確認したい人たちです。
- そのため、経営ダッシュボードなど比較的定型的で多角的、分かりやすいレポートを好みます。
- パワーユーザー
- 具体的な戦術や施策を検討するため、組織全体もしくは自分の部署の範囲のデータを試行錯誤しながら分析したい人たちです。
- そのため、分析軸や KPI も多岐に渡り、自由度の非常に高い複雑なアドホック分析ができることを重要視します。
- 定型分析ユーザー
- 自分の業務、もしくは自分のチームの業務遂行に責任を負っており、そのために必要なデータを確認したい人たちです。
- 分析が業務オペレーションの一環となっており、シンプルで対象を絞った定型レポートを好みます。
このように BI のユーザーを分類した場合、Text-to-SQL のメリットを享受できるユーザーは誰になるでしょうか。
まず、定型分析ユーザーは BI ツールや SQL を使いこなすのは一般的に難しいのですが、確認するレポートは定型が多いため、Text-to-SQL というより事前作成のダッシュボードの方が適していそうです。
また、経営者も経営ダッシュボードなど定型レポートを確認することが多いので、Text-to-SQL が適しているか疑問です。いろいろ深掘りする経営者もいるとは思いますが、自身は現場から距離があるため、それは配下のメンバーに任せた方がよいことも多いです。
パワーユーザーはアドホックな分析が多く、事前に作成された定型レポートだけでは満足しなことも多いため、Text-to-SQL がマッチしそうです。ただ、求められる複雑な分析に自然言語でデータ問い合わせをするのが適しているのか？代わりにしっかりと BI ツールや SQL の使い方を学んだほうが良いのか？は見極めが必要です。特に複雑な分析になると、
- 質問内容を正確に日本語で伝えるのが難しい
- 複雑な分析の結果が正しいかを担保 / 確認するのが難しい
というハードルをどう越えるかは大きな課題かなと感じています。（チャットベースだとシンプルな質問を何度か投げ、それらの結果を組み合わせて複雑な分析を実現するというアプローチもあるので、逆にチャンスかもしれないですが）
そう考えると Text-to-SQL がマッチするユーザーはアドホック分析をするけど、その中でも比較的にシンプルな分析をするユーザーということになるのではと思っています。
ちなみに、私の観測範囲だと、日本の BI ユーザーは定型分析ユーザーとパワーユーザーの中間の準パワーユーザーがボリュームゾーンのような気がしています。なので、実は Text-to-SQL は日本にこそ向いていたりして？とも思っています。
2. Text-to-SQL に必要なメタデータ
ここまでで、いろいろ Text-to-SQL について思うところを述べましたが、非技術者のユーザーがデータ分析できるようにする観点では避けては通れない技術なのは間違いないと思います。
Text-to-SQL を実現する大まかな流れは、すごくシンプル化すると以下になります。
- 質問に対して必要そうなテーブル/カラムをメタデータに基づいて見つける
- 質問に加え、必要と思われるテーブル/カラムの定義とメタデータを LLM に渡し、質問に答えるための SQL を生成する
- 生成された SQL 文を実行する
（テーブル数やカラム数が少なければ、1. をスキップして 2. で全テーブル/カラムの定義とメタデータを渡すという方法もありますが）
つまり「メタデータ」が Text-to-SQL の肝になります。
メタデータというとテーブル/カラムのビジネス名称や意味を思い浮かべる人が多いですが、メタデータはそれだけではありません。Text-to-SQL に必要なメタデータとして何があるか、以下で考えてみたいと思います。
（以下に挙げた以外にもまだまだいろいろあると思いますが、例として）
2-1. テーブル・カラムのビジネス名称・意味
これは言わずもがなですね。特にビジネス名称の方は類義語や別称なども必要になると思います。
2-2. 計算ロジック
計算を行う SQL 文を LLM に生成してもらうため、計算の方法（計算ロジック）もメタデータとして必要になります。
「売上金額合計」といった KPI は売上金額列の数値を合計すればよいんだなぐらいの推測は LLM でも十分できます。しかし、計算が複雑な KPI や組織に固有の KPI などは LLM が正しく推測できないため、KPI の集計ロジックをメタデータとして定義する必要があります。
また、テーブルをどう結合するのかという情報も必要なメタデータの1つです。外部キーが定義してあれば分かることも多いですが、
- 結合したいテーブルの間に２パターンの結合方法がある場合
- 非等価条件による結合や、何らかの都合で主キー/一意キーを参照しない結合の場合
は別途追加のメタデータが必要になることが多いですね。（データモデリングで解消できる部分も少なくないですが）
2-3. 分析方法や分析ノウハウ
Text-to-SQL をする上で一番肝になるのではないかと思っているメタデータがこれになります。
具体的には以下のような情報が例になると思います。
- こういう分析をするときは、このテーブル/カラムを見るべき
- （例）テーブルの売上金額に「税抜」と「税込」の２種類の項目があるが
- 財務会計の観点での分析であれば、税抜の方を使うべき
- 現金管理の観点での分析であれば、税込みを使うべき
- （例）テーブルの売上金額に「税抜」と「税込」の２種類の項目があるが
- この分析をするときはある条件のレコードは除外すべき
- （例）複数の店舗の売り上げの前期比較をしたい場合は、１年以内に開店した店舗は除外すべき
- 分析を始める際はまずこの粒度で集計しておくとよい
- （例）売上分析は週別×品目分類別に集計すると分かりやすい
- 分析する上ではこの観点も見ておいた方がよい
- （例）製造系で歩留まり率を見る場合は、それに伴う損失コストも見るべき
（これらの例は常に正しいというわけではなく、組織やビジネス環境によって変わってきます。）
これらの情報がないと、分析者は分析方法を十分理解した上で、SQL 文と同様の内容を日本語で事細かに記述する必要があるため、Text-to-SQL のメリットが十分に活かせません。
メタデータというとテーブル定義書やデータカタログで管理するというのがよくあります。一方、分析方法・分析ノウハウに関する情報はオンボーディング資料や教育資料などとして整理されていることが多いので、どう管理していくかは悩ましいなあと思っています。
2-4. セキュリティー
- このテーブル/カラムにはどのユーザーがアクセスしてよいか
- このテーブル/カラムはこの用途で使ってよいか
- 集計結果は誰に公開してよいか
といった情報も地味に必要になります。
3. メタデータってどこで持つべきなのか？
Text-to-SQL にはメタデータが重要という話を 2. で述べました。ところで、これらのメタデータはどこで管理した方がよいのでしょうか？
3-1. データカタログ
メタデータを管理するとなると、一番に候補に挙がるのがデータカタログツールかなと思います。ただ、Text-to-SQL がメタデータにアクセスできるようにするには、それ用の標準化されたインターフェースや MCP サーバーなどが出そろってくる必要があるかなと思います。
OpenMetadata などはメタデータを取得するための API を１つの売りにしていますし、メタデータを保存している DB のデータモデルも公開していたりします（オープンソースだから当たり前ですが）。
また、MCP サーバー対応のデータカタログについて軽く調べると、以下があるようです。
- Googleデータカタログ
- Unity Catalog（Databricks）
ただ、他のデータカタログ製品・サービスも追従するでしょうか？どちらかというと、データカタログ自体に Text-to-SQL の機能が埋め込まれるような気がします。ツールベンダーは他のツールのベースになるより、自分たちのツールを主役にしたいというビジネス上の動機がありますからね。
例えば、Alation などはもともとデータ問い合わせできる機能があるため、Text-to-SQL を組み込むのは容易かと思います（既にあるかもしれない）。ただ分析に必要な機能を一通りそろえてユーザーの人気を獲得できるかは微妙な気もします。1-2. で挙げた機能面に対して BI ツール以外が追い付こうとするのはなかなか辛いのではとも予想しています。
3-2. DB/DWH
DB/DWH が自身が保持するデータについてメタデータも保持するというアプローチもあるかと思います。もともと、多くの DB/DWH にはテーブルとカラムにコメントを付与する機能があり、これでメタデータの正データを管理しているプロジェクトや組織もいくつかあります。
ただ、DB/DWH となると、どうしてもテーブルやカラムのビジネス名称や意味が中心になりやすく、Text-to-SQL が必要とするメタデータをカバーできるのかという疑問があります。Snowflake Cortex Analystのセマンティックモデルなどは計算ロジック（KPI 集計や結合のロジック）を定義できるようにしていて、この課題を部分的に解決しています。
ただ、可視化やその他の機能（1-2. で述べた機能）という点ではこれからという状況かなと思います。
BI ツール
Text-to-SQL をBI ツールに組み込むというのが一番今までのやり方を変えないアプローチなのかなと思います。特に Text-to-SQL で作成したレポートを他のレポートと同様に修正したり、他のユーザーに共有できたりといったことができるのは大きな魅力かなと思っています。その点では、BI ツールでメタデータを管理するというのが自然な流れに見えるのは一面では正しいと思います。
BI ツールにはデータソースの物理データモデルとは別に分析しやすいように仮想的なデータモデルを持つ製品・サービスも多いです。そこでテーブル/カラムのビジネス名称や意味だけではなく、計算ロジックも定義することができます。
ただ、デメリットとしてその BI ツールでしか登録したメタデータを利用できないというデメリットがあります。実際、大きな組織になると 1 つの BI ツールに利用を集約させるというのはなかなか難しいものです。その際にそれぞれの BI ツールでメタデータを定義するというのは手間ですし、そもそも定義できるメタデータが BI ツールによって異なるでしょうから、より状況は複雑なのかなと思います。
Looker のようにセマンティックレイヤーでメタデータを提供し、他の BI ツールに提供できるものもありますが、この流れに追従する他 BI ベンダーはいるでしょうか。
また、DB/DWH やデータカタログで定義されたメタデータを BI ツールに取り込めるようになればよいのですが、BI ツールベンダーにはそのモチベーションは現時点ではあまりないと思います。実際、DB のテーブル/カラムに付与したコメントをBIツール上で表示できればいいなぁと思うことは多々るのですが、できるBIツールはそんなに多くはないですよね。これは技術的というよりビジネス的な問題（BI ツールベンダーにその機能を実装するビジネス的なメリットがない）なので悩ましいですね。
3-4. セマンティックレイヤー
複数の BI ツールの間、もしくは同じ BI ツールを使っていても異なるユーザーの間で集計値が異なるという話はよくあり、集計ロジックを共通化させるという動機からセマンティックレイヤーという技術が出てきています。
この技術が範囲を広げてメタデータを共通的に提供する基盤になるんじゃないかというのは、最近思っている期待です。
4. さいごに
ここまで、最近注目されている Text-to-SQL という技術について何となく考えていることをだらだらと書いてみました。
まず、Text-to-SQL はデータ分析のプロセスや作業、ユーザー層の全体をサポートしている訳ではないよねということを述べました。ただ、個人的には 1-1. で述べた「仮説の検討」と「結果の解釈と仮説判定」が LLM でできるのはという思いもあり、そういう取り組み事例もあるようなので、挑戦していきたいなと思っています。
また、Text-to-SQL を実現するにはテーブル/カラムのビジネス名称や意味だけではない、その他のメタデータも重要だよねという話をしました。実際、データマネジメントでメタデータ管理を行おうとすると、Text-to-SQL 以外でもビジネス名称や意味以外のメタデータにフォーカスが当たることが多いのですが、Text-to-SQL の普及はその流れを加速するのではないかなと思っています。
最後に、メタデータはどこで管理されるべきかということを考えていました。正直、ここは技術的にどうあるべきかというより、製品・サービスベンダーのビジネス力学が大きな影響を与えるところなので、悩ましいところですね。「どこにメタデータがあろうが関係なくて AI エージェントがアクセスできれば OK」みたいな可能性もあるといえばあるのですが、過去の遺産や慣習を捨ててそちらにシフトするかというと、個人的にはちょっと疑問に思ってます。