世界を動かす技術を、日本語で。

AIに良いSQLを書かせる方法

2025年5月17日原文(cloud.google.com)

概要

  • SQL はデータ駆動型意思決定の中核であり、 Gemini は自然言語からSQLを生成することで生産性向上を実現。
  • Google Cloud の多くの製品で text-to-SQL 機能が利用可能。
  • 現実の課題として、 ビジネス文脈の理解ユーザー意図の把握SQL方言の違い に対応する必要がある。
  • 最新のLLM技術 と補完的な手法で、精度や使いやすさを継続的に改善。
  • 本記事では Google Cloudのtext-to-SQLエージェントの内部技術 と課題解決アプローチを解説。

Google CloudにおけるText-to-SQL技術の進化と課題

Text-to-SQLの概要とGeminiによる革新

  • 組織 は迅速かつ正確なデータ分析に依存し、 SQL がデータアクセスの基盤であることを確認。
  • Gemini を活用することで、自然言語から直接SQLを生成し、 開発者・アナリストの生産性向上非技術者のデータ活用 を促進すること。
  • BigQuery StudioCloud SQL StudioAlloyDB StudioCloud Spanner Studio など、Google Cloud製品にtext-to-SQL機能が実装されていることを提案。
  • AlloyDB AIVertex AI を通じて、Geminiモデルへの直接アクセスも可能であることを強調。
  • 大規模言語モデル(LLM) の進化により、text-to-SQL分野が大きく前進していることを確認。

Text-to-SQL技術の課題

  • ビジネス特有の文脈提供 が必要であり、スキーマやデータの意味をモデルに適切に伝えることが困難であることを認識。
  • ユーザー意図の理解 が難しく、曖昧な質問に対してLLMが誤ったSQLを生成するリスクがあることを確認。
  • SQL方言の違い や複雑な仕様に対応するため、LLM単体では限界があることを認識。

課題へのアプローチ

  • スキーマ・データ・ビジネス概念の理解
    • セマンティック類似性によるデータセット・テーブル・カラムのインテリジェントな検索・ランキングを行うこと。
    • ビジネス固有の例を使ったインコンテキストラーニングを適用すること。
    • データリンクやサンプリング、セマンティックレイヤーの活用で複雑なデータ構造と日常言語の橋渡しを行うこと。
    • 利用パターン分析やクエリ履歴の活用で文脈を補強すること。
  • ユーザー意図の把握
    • LLMによる曖昧さの解消(ディスアンビギュエーション)を実施すること。
    • エンティティ解決やSQL対応型ファウンデーションモデルを利用すること。
  • LLM生成の限界克服
    • セルフコンシステンシー(複数案生成と最良案選択)を実施すること。
    • バリデーションやリライティングで生成SQLの正確性を担保すること。
    • 方言特化例を用いたインコンテキストラーニングやモデル微調整を行うこと。

主要技術の詳細

  • SQL対応LLMモデル
    • Geminiファミリーの強力なモデルを基盤とし、用途や方言に応じてバージョンや微調整モデルを組み合わせて活用すること。
  • ディスアンビギュエーション(曖昧さ解消)
    • 質問が曖昧な場合、LLMが追加質問を生成し、ユーザー意図を明確化すること。
    • スキーマ・データに基づき、質問が答えられるかを判定し、不足時はフォローアップ質問を作成すること。
  • 検索・インコンテキストラーニング
    • セマンティック検索等で関連データセット・テーブル・カラムを抽出し、追加コンテキストをモデルに提示すること。
    • スキーマ注釈や類似SQL例、ビジネスルール適用例、直近クエリなどをプロンプトに組み込むこと。
    • Geminiの長いコンテキストウィンドウ対応で、大規模スキーマや付加情報も処理可能にすること。
  • バリデーション・再プロンプト
    • 生成SQLのパースやドライラン等、AI外の手法で正確性を検証し、不備があればモデルに再入力すること。
    • モデルに誤り例と修正ガイダンスを与えることで、生成精度を高めること。
  • セルフコンシステンシー
    • 単一生成に頼らず、複数案を生成し、最良のSQLを選択することで精度向上を図ること。
    • 複数モデルが同意する案を選ぶことで、正答率向上を目指すこと。

評価と改善

  • 評価ベンチマーク
    • BIRD-benchなどの学術ベンチマークに加え、現実的なスキーマ・ワークロードをカバーする独自合成ベンチマークを開発すること。
    • SQLエンジンや方言、DDL/DML、管理系操作、複雑クエリなど多様なケースを網羅すること。
  • 評価指標と体制
    • ユーザー指標とオフライン評価指標を組み合わせ、人間評価と自動評価(LLM-as-a-judge)を併用すること。
    • 継続的な評価で新モデルやプロンプト手法の有効性を迅速に検証し、改善サイクルを回すこと。

今後の展望と利用案内

  • text-to-SQL技術の進化 により、Google Cloudユーザーや顧客環境で大きな改善を実感できることを提案。
  • BigQuery StudioCloud SQLAlloyDBSpanner StudioAlloyDB AI にてGemini text-to-SQLを体験・活用することを推奨。
  • 今後もtext-to-SQLソリューションの詳細解説を継続発信予定であることを告知。

Hackerたちの意見

短い答えは、セマンティックレイヤーを使うことだね。これが一番クリーンな方法で、正しいコンテキストを提供するのに最適な場所だし、人間をループに入れるのにもいい。人間が「月間アクティブユーザー」って何を意味するのかを検証したり、重要な指標を作ったりできるから、その定義をLLMがMAUを求められたときに使えるようになる。セマンティックレイヤーを使うことで、生のSQLじゃなくてJSONでクエリを書くという追加のメリットも得られるよ。LLMは数百行のSQLを書くよりも、小さなJSONを書く方がずっと一貫性があるしね。私たちはcubeを使ってるよ。これが一番のオープンソースのセマンティックレイヤーだけど、いくつかのクローズドソースの選択肢もある。私の前の会社が2021年にこれについての投稿を書いたんだけど、買収者がブログのホスティング代を払わなくなったみたいで、でもHNの投稿はまだ残ってるよ。

生のSQLじゃなくてJSONでクエリを書くという追加のメリットも得られるよ。ごめん、無理だわ。尻尾が犬を振ってるみたい。マジで、私のアカウント削除して履歴も消してくれない?

セマンティックレイヤーを構築する人がまだ必要だね。text2sqlとか似たようなものでやればいいんじゃない?

神様、JSONを書くことができるのに、クエリ用に設計された言語じゃなくていいの?何の利点があるの?抽象化レイヤーを上げるなら、自然言語をくれよ。たくさんのものが限られた自然言語の文法をSQLに変換してくれるのに。JSONは俺に何をしてくれるの?

生のSQLの代わりにJSONでクエリを書くという追加の利点があるよ。君も生の英語じゃなくてJSONでコメントを書けばよかったのに。

生のSQLの代わりにJSONでクエリを書くという追加の利点があるよ。^ 子供たち、これがAIによる脳の腐敗ってやつだよ。

セマンティックレイヤーを使うのが精度を上げる最良の方法だと思う。AIにとってのチートシートみたいなもんだね。でも、JSONでクエリを表現しなきゃいけないやつは絶対に使わない。最良の実装はデータベースに直接統合されて、通常のSQLクエリの一部になるから、すべてのツールでも使えるんだ。Exasolのセマンティックレイヤーを使った経験から言うと、完全にシームレスな体験ができるよ。

セマンティックレイヤーは素晴らしいと思う。リレーショナルクエリを簡単に書けるように設計された構造化されたレイヤーにすべきだね。「構造化データ言語」とか「構造化クエリ言語」って呼べるかも。真面目な話、SQLにはいくつか不満があるけど(LINQの再配置はいいアイデアだと思う)、LLMがそれを扱えるようにするために別のレイヤーを発明する必要はないと思うよ。

実生活では、AIを使ってSQLを書くのは危険だと思う。何をしているか分からない人がサーバーに大きな影響を与えるクエリを書くことを許してしまうから。私の世界では、データベースはほとんどの開発者にとっては比較的大きいけど、巨大ではない。時々、クエリを微調整したいときに、AIにより良い解決策を提供するように挑戦してる。すでに最適化されたクエリを与えて、もっと良いのを求めるんだけど、より良い答えは一度ももらったことがない。AIが幻覚を見ていることもあるし、提案された変更が役に立たないこともあるから、まるでバカなオウムが売春宿で聞いたことを話しているみたい。1916年の敵の将校がよく通う戦争の売春宿ならいい情報だけど、今はそうじゃない。

いや、IMEのプログラマーは何も分からずにやっちゃって、問題が起きたら誰かや何かのせいにするんだよね。AIはそういうことが起きる頻度を増やしてるだけだよ :)

すでに最適化されたクエリを与えて、もっと良いのを求めるんだけど、より良い答えは一度ももらったことがない。私も同じ経験をしたよ。でも、最近はこの点で改善されてきているのを観察している。新しいLLMはずっと良いパフォーマンスを発揮しているし、時間が経つにつれてさらに良くなると思う。

俺がこの人たちに使ってる戦略は、AIでプロトタイプを作らせて、その後に彼らの作業を引き継いで、もっと効率的にするって感じ。いいところは、彼らのパフォーマンスが悪いバージョンが、俺のクエリの出力を検証するための参考になるってことだね。

Hacker Newsで議論の続きを見る