「自然言語から SQL への変換」の問題点と、コンピュータがそれを解決する方法

Computer はお客様のビジネス特有のデータを理解し、現実世界の用語を適切なフィールドにマッピングし、即座に正確な回答を提供します。推測やアナリストを待つ間の時間浪費はもう不要です。毎回、明確で会話形式のインサイトをお届けします。

–

営業 VP から Slack メッセージが届く：「当社の予測案件のうち、過去2週間で何の活動もなかったにもかかわらず、今四半期中に成約予定とマークされている案件はどれか？」

単純な質問です。しかし答えを得るにはデータアナリストが必要です：各案件が最後に手付かずだったのはいつか？ 近く成約予定なのはどれか？ 何か変化はあったか？ メールや電話、会議の記録と照合し、全てをまとめて確認した方がいい。

「（早くても）2時間後にようやく回答が届いた頃には、レビュー会議はすでに始まっていて、あなたは裏付けの取れない数字を手に会議室に入ることになる。――その結末がどれほど悲惨か、私たちは皆よく知っている。」

約束された理想 ― そして現実とのギャップ

ここ数年、「自然言語からSQLへ（Natural Language to SQL）」というソリューションは、データアクセスを民主化すると期待されてきました。英語で普通に質問するだけで、数秒後には答えが返ってくる――私たちはそう聞かされてきました。

技術自体は、表面的には目覚ましい進化を遂げました。しかし、実運用の現場では問題が繰り返し発生しました。SQLは文法的に正しい。クエリもエラーなく実行される。それでも、返ってくる答えが間違っているのです。

なぜでしょうか？ VP から届いたあの Slack メッセージを思い出してください。「コミット期限が近づいている案件はどれか？」と質問するとします。しかし、あなたのシステムではその項目は「Commit Date」ではなく「Break Date」という名前で保存されています。その結果、ツールは「commit_date」を探し、見つからず、代わりに誤った項目 ―― たとえば「close_date」や「created_date」―― を返してしまいます。

このようなケースは、どの組織にも数十はあり、多いところでは数百、数千にも及びます。「Commit Date」が「Break Date」として保存されている。「Health Score」が「CS_Health_Index」になっている。「Priority Tier」が「Cust_Priority_Level」と呼ばれている。さらに、データが複数のツールに分散していると、問題は一層深刻になります。サポートチケットでは「Urgent / High / Medium / Low」、CRMでは「P0 / P1 / P2 / P3」、プロジェクト管理ツールでは「Critical / Important / Normal」。

結果として、モデルは“推測”するしかなくなります。それらしく聞こえるフィールド名を探し、正しそうに見えるSQLを生成するのです。

これは、汎用 LLM が高度な SQL 構文を生成できたとしても、実際のビジネスや、現実の（時に雑然とし、しばしば分断された）データセットの微妙なニュアンスを理解するのが難しいからです。スキーマドキュメントがあったとしても、モデルが見ているのは「ある時点の静的な情報」に過ぎず、「生きたシステム」ではありません。更新を動的に取得したり、カスタムフィールドと標準オブジェクトの関係性を理解したりすることはできないのです。

だからこそ、私たちは Computer を、まったく異なる発想で構築しました。

データインテリジェンスの3つのレイヤー

このようなデータを本当に使いやすくするには、相互に連携した3つのレイヤーが必要です。

1. 第1のレイヤーは「構文（Syntax）」 – これは、自然言語をSQLに変換することを指します。汎用 LLM や多くの Text-to-SQL ツールが担っているのがこの部分で、実際、ここはかなり得意です。しかし、前述の理由から、構文だけでは「見た目は立派だが、間違った答えを返すクエリ」が生まれてしまいます。

多くの分析ツールは、いまだにこのレイヤーで止まっています。

2. 第2のレイヤーは「スキーマ（Schema）」 – これは、クエリを実際のデータ構造に照らして検証することを意味します。これにより、ハルシネーションや実行時エラーを防ぐことができます。

この課題に取り組み始めているツールもいくつか登場しています。ただし、これは必要条件ではあるものの、十分条件ではありません。スキーマ検証が完璧でも、「そのデータが何を意味するのか」を理解できるとは限らないのです。

3. それを可能にするのが、第3のレイヤー「セマンティクス（Semantics）」 – ここでは、ビジネス文脈、データ同士の関係性、そして意味そのものを理解します。このレイヤーに到達して初めて、カスタムフィールドが“理解可能”になります。「Break Date」が「コミット日」として解釈され、「高優先度」が異なるソフトウェア間でも正しく対応づけられ、複数オブジェクトにまたがるクエリも、推測による JOIN ではなく、実際の関係性を辿るようになります。

Computer は、この3つすべてのレイヤーを最大限に活用しています。

Computer が正しく答えられる理由

Computer AirSync は、重要なコンテキストデータを保持したまま、組織内のあらゆるデータを Computer Memory（権限管理に対応したナレッジグラフ）へと取り込み、標準化します。そのため、Computerは「Break Date」を見た瞬間に、それが「コミット期限」を意味していると理解します。さらに（Computerは学習を止めないため）CRM上の「P0」が、サポートチケットでは「緊急（urgent）」に相当することも学習していきます。

Computer に質問すると、統合済みのスキーマを使って、リアルタイムで検証が行われます。どのテーブルが存在し、どのカラムを持ち、どのような関係性にあるのかを、Computer は正確に把握しています。「この改善施策に紐づくチケットは？」と尋ねれば、オブジェクト間の関係を理解した上で、JOIN を自動的に実行します。

そして結果はどうなるか。Computer は、会話形式で、正確かつ先回りして答えを返します。21 件のチケットが提示され、要点が整理された見やすい一覧が表示され、さらに、今後顕在化しそうなトレンドに関する追加の文脈や分析の提案まで得られます。

CSVをアップロードする必要はありません。アナリストを待つ必要もありません。危険なハルシネーションに悩まされることもありません。ただ質問する。そして、答えが返ってくる。それだけです。

会話型アナリティクスは、すでに現実になった

会話型アナリティクスの時代は、もう始まっています。私たちは Computer のセマンティックレイヤーを完成させました。だからこそ、データアナリストに時間やリソースを割いたり、「このツールは本当に正しい情報を返しているのか？」と疑ったりする必要はもうありません。

Computer を使えば、プロダクトマネージャーは「この改善施策に紐づくチケットをすべて表示して」と尋ねるだけで、部門横断の依存関係を即座に把握できます。営業リーダーは、パイプラインレビューの場で「前四半期における、米国エンタープライズチームの100万ドル超の商談を教えて」と質問できます。カスタマーサクセスチームは、解約リスクを特定し、エンゲージメントの傾向について自然言語で問いかけることができます。

なぜなら、データを本当に活用することは、SQLやテーブル、JOIN の話ではないからです。

それは、質問と答え、そして意思決定の話です。「誰か教えてくれない？」を「これが、あなたが知るべきことです」へと変えること。それを、即座に。会話のように。正確に。

Computer は、すでにその準備ができています。

のチームが全力でサポートします。ぜひ無料デモをご予約ください。新しい一歩を、今ここから。