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

374日前原文(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 Studio、 Cloud SQL Studio、 AlloyDB Studio、 Cloud Spanner Studio など、Google Cloud製品にtext-to-SQL機能が実装されていることを提案。
AlloyDB AI や Vertex 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 Studio、 Cloud SQL、 AlloyDB、 Spanner Studio、 AlloyDB 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でプロトタイプを作らせて、その後に彼らの作業を引き継いで、もっと効率的にするって感じ。いいところは、彼らのパフォーマンスが悪いバージョンが、俺のクエリの出力を検証するための参考になるってことだね。

└

自分が何をしているのか分からない人がサーバーに大きな影響を与えるクエリを書くことを可能にしている。少なくとも、俺がよく使う唯一のOLAP DB、Amazon Redshiftでは、ワークロード管理キューでその問題は解決済みだよ。そういうユーザーがリソースを消費しすぎないように制限できる。OLTP用のクエリについては、だいたいシンプルに保つようにしてる。リソースを消費する読み取りクエリには理由がある場合、強い一貫性が必要ないときはリードレプリカに行くことにしてる。

└

ランダムな人がサーバーに影響を与えることがあってはいけない。それがリードオンリーアクセスのリードレプリカの役割だよ。プロダクションDBサーバーは、ランダムなクエリや人による使用に開放されるべきじゃない。それはアプリが使うためのものだけだ。

最新のGeminiを搭載したGoogle AI Studioが驚くほどすごい、まさにゲームチェンジャーだよ。ClaudeやChatGPTのコーディングがまるで別の世代のものに見える。これらの変化が数週間や数ヶ月で来るなんて信じられない。先月、Claudeがどれだけ優れているか信じられなかったけど、今日、Google Geminiが私のツールキットにないとプログラミングを続けられるかどうか分からない。Gemini AI Studioはプログラミングにおいて大きな飛躍で、使っていると自分をつねってしまうほどだよ。

└

もっと多くの人が気づいていないのが本当に驚きだよ。Claudeは同じ複雑さの小さなものを一発で処理できるけど、モデルを本当に長くて複雑なユースケースに押し込むと、Geminiが圧倒的に優れている。コンテキスト処理がすごくて、コーディングエージェントとして使うだけじゃなくて、私はGeminiをかなり長い原稿（約85,000語）をベータリーダーとして使ってるんだけど、完璧にこなしてくれて、しっかりした人間のベータリーダーが数秒で提供するような高レベルのレポートを出してくれる。

└

これはGemini 2.5 Proを使うのとは別のものなの？もしそうじゃないなら、私の経験とは合わないな。最近、すごく質の低いコメントが多い、デザインもひどいTypeScriptをたくさんもらってるよ。

└

書かれたコードに変更を加えてもらうように頼んだんだけど、同じコードをどんどん出してきて、自己弁護のためにコメントを増やすばかりだった。3回目の試みで、自分でやった方が早かったなって気づいたよ。

└

仕事でGemini2.5 Proを使ってるけど、めっちゃ良いよ。ただ、個人用にはAPI経由でClaude 3.7 Sonnetを使ってるんだけど、アカウントにお金を追加して使ってるんだ。Geminiをプリペイドプランみたいに使う方法が見つからなかった。LLMに何百ユーロも請求されるのに、Googleにクレジットカードを渡す気にはなれないよ。

└

今日、Google Geminiが自分のツールキットにないとプログラミングを続けられるかどうかわからない。こんな発言に不安を感じている人、他にいる？勘違いしないでほしいけど、私たちはLLMバブルの中にいるんだ（AIバブルじゃなくて、実際にAIに興味がある企業はAGIに向かって進んでないから）。彼らはみんな、ちょっとした手を加えてLLMを商業化しようとしているだけ。最初の3回のGPTの進化のような進展は期待できないと思う。で、過剰に評価されていたバブルが崩れたら、バブルは本当に崩れるよ。利益を出してこの手のツールを運営するためにお金が残っていることを願った方がいいよ。さもないと、生成コーディングツールを使って失ったスキルを再学習するためにStackoverflowに戻ることになるからね。

└

あなたのコメントを見て試してみたけど、最初のプロンプトでGemini 2.5 Proが存在しないプラグインを作り出して、詳細な使用説明までついてきた。あんまり良いアイデアじゃないね。

└

それは与えるタスクの種類によると思う。TypeScriptやPythonを書くのはかなりうまくいくけど、私の経験では、シェルやもっと広い範囲のDevOpsにはちょっと物足りない感じ。

└

ごめん、なんかマーケティングの宣伝みたいに聞こえる。

└

Gemini AI Studioはプログラミングにおいてすごい飛躍だよ、使ってると自分をつねりたくなる。ここ3、4週間の間に、Geminiについての投稿があって、トップコメントかその一つがこんな感じのことばかり。毎回、Geminiの有料アカウントをキャンセルしたのが間違いだったか確認するために、数分間実験してるんだけど…AWS関連の質問に同じプロンプトをGemini Pro 2.5（無料）とClaude（有料）に送ってみたけど、やっぱりClaudeの方がまだ良いね。

└

まだどのLLMの宣伝者もこの明白な事実を認めてないね：新しいリリースは「ゲームチェンジャー」だって。つまり、前のリリースも「ゲームチェンジャー」って言ってたのが、今は「別の世紀のもの」になってるってこと。分かる？これが正確で真実な評価だとしたら、前も今も間違ってたってことになるよ。

一番重要な問題に関しては、これらのツールが最も役に立たないように思える。最も難しい問題領域には、心配しなければならないスキーマが一つだけじゃなくて、何百もあるからね。個人のブログやTODOリストトラッカーを立ち上げる必要があるなら、Googleなどがあなたを正確に目的地に導いてくれることに疑いはないよ。

└

それから、ビジネス用語やクエリの背後にある意図に曖昧さを加える必要があるね。ビジネスとその間に座るセマンティックレイヤーやオントロジーみたいなものがまだ必要だと思う。今のところ、その辺のことは自動化されてないし（でも、すべきだよね）。

スティーブン・ボイドの凸最適化に関する講義の中で、「もし最適化問題が計算上解決不可能なら、アルゴリズムを改善するために頑張るか、数週間バケーションに行って帰ってきたら、コンピュータが速くなって解決できるようになってるかもしれない」みたいなことを言ってた。今のLLMに関しては、これが実際に真実だと思う。もし俺が書いたクエリが一発で解決できなかったら、複雑なプロンプトを考えるのはやめて、来月まで棚上げにするよ。次の大きなOpenAI/Anthropic/Googleのモデルが大体それを解決してくれるから。

└

3つの長方形が並列駐車するコードペンのシミュレーションを書かせてみて。

└

このペース、遅くなったのかな？それとも私がストーリーについていけなくなっただけ？AIの革新が、パラダイムシフトから段階的な変化に変わってきてる気がする。

└

来月まで棚上げしておくと、次の大きなOpenAI/Anthropic/Googleのモデルがだいたいそれを圧倒するんだよね。LLMでコードを書くのに1ヶ月かかるって、約束された生産性の向上とは真逆だよね。

└

ここでは、コア機能が日々変わって、特定の言葉の使い方に依存してるんだよね。

「一発で解決」ってフレーズを救うのはもう遅い？それとも「AI」や「エージェント」みたいに手遅れなのかな？

└

なんでか分からないけど、「ワンショット」って見るたびに、誰かがウォッカやテキーラをガンガン飲んでるイメージが頭から離れないんだよね。

└

「クリプト」の名前のオーバーロードを思い出すな。ファンボーイたちが能力に嫉妬してるのが明らかだ。

記事では「LLMは特にクリエイティブライティングのようなタスクにおいて優れている」と書いてあるけど、これが実際にはAIの問題を示していると思う。作家は自分がクリエイティブライティングが得意だとは思わないだろうし、むしろLLMはクリエイティブライティングが下手だと思うはず。つまり、専門家にとっては、まだまだそのレベルには達していないってこと。でも、専門家じゃない人にとっては、信じられないくらい優れているんだよね。以前は全くできなかったことができるようになったから。

└

そうだね、でもなんでみんなHNでLLMが専門レベルでコーディングできるって言ってるの？

AIがSDKメソッドの幻覚を見なくなったときが、私にとってのゲームチェンジャーだろうな。よく「ニッチなY SDKで高度な概念Xをどうやってやるのか見せて」って聞くんだけど、自信満々の回答を出す一方で、90%の確率で存在しないSDKメソッドを提案してくるから、そのことで無駄に時間を浪費してるんだよね。

└

現在の解決法は、AIにコードが使っているSDKのドキュメントを提供することだよ。今のLLMはかなり大きなコンテキストウィンドウを持ってるから、たくさんのドキュメントを与えられるんだ。一部のツールは、複数ページのドキュメントをクロールして、LLM用にインデックス化することもできるよ。

└

LLMを持ってくると、いつもハルシネーションで「こんなAPIがあったらいいな」ってなるよね。もしその反対側にAPI自体をハルシネートするものがあれば、使うたびに自分自身を存在させるプログラムができるかも。

└

「callTheExactMethodINeed()はハルシネーションだったと思う。もう一度試してみてくれない？」って言ったら、謝って正しい答えをくれるんだ。変だよね。彼らがやってることに新しい名前が必要だと思う、だって考えてるわけじゃないから。

└

これらの幻覚のいくつかが、実際には彼らがアクセスできる同じ名前空間にあるカスタムコードのサンプルだったとしても驚かないよ、でもIPの問題で帰属できないんだろうね。

技術的な観点から見ると、これは素晴らしいニュースだと理解できる。でも、社会的な観点から見ると、全く良いニュースだとは思えない。ここ15年ほどで、エンジニア、特にソフトウェアエンジニアの給料が前例のないほど上がったんだ。これによって、普段はソフトウェアを職業として考えない人たちからの関心が高まったと思う。これは良い面も悪い面もあるよね。多くの人に新たな富をもたらしたけど、才能の質が薄まったかもしれない。それでも、ほとんどは良いことだったと思う。今、これらのAIツールからの画期的な効率性で、ソフトウェア職業の給料の栄光の日々は終わったと思う。これがなくなったら、普通の人たちがどこで経済的独立を達成できるの？サービス業では絶対無理だよね。ほんと悲しい。

└

所得格差を解決するための対策が必要だね。

└

財政的独立を達成するのに十分な収入を得ているソフトウェアエンジニアは、一般的にFAANGに雇われているか、（間接的に）お金を持て余しているベンチャーキャピタリストに雇われている。こんなにお金があふれている中で、働いている人たちに無駄な（あるいは場合によっては有害な）ソフトウェアを作らせずに、いくらかを流す方法を考えるのはちょっとした想像力があればできるよ。

└

AIの進展に関するこの感情がなぜあるのか、ちょっと気になる。高水準のプログラミング言語は、ソフトウェア職の価値を全く奪わなかったし、むしろもっと多くの人がソフトウェアを書くことを可能にした。ソフトウェアの量と複雑さは、専門家が必要な限界まで拡大していくよ。

└

技術的な観点から見ると、電気や電化が素晴らしいニュースだというのは理解できる。でも、社会的な観点から見ると、全然良いニュースだとは思えない。職を失った街灯点灯者のことを考えてみて。今は街灯が自動で点くの？街灯点灯は安定した仕事だと考えられていたのに！氷を切る人たちはどうなるの…本当に、やることが何もないわけじゃない — まだ直さなきゃいけない穴ぼこや、たたむべきTシャツ、治療すべき病気があるんだから。資源の不足で戦争が正当化されると信じ続ける人が多いってことは、技術の進歩が必要だってことを示してるよ。

└

こんな発言と、LLMを使ってコーディングしようとした経験がどうしても一致しない。実際に複雑なことがあると、意味不明な壊れたコードを吐き出して、場合によってはデバッグに長い時間がかかることもある。で、修正すると「あなたが言う通り、x y zに変更するね」って。もしあなたが経験豊富なシニア開発者じゃなかったら、これらのツールが生成するコードをデバッグしたり修正したりすることはできないよ。

└

誰でも高度なプログラミングができるようになることで、社会がもっと早く豊かになる方が、特権を持った少数のエリートが排除を通じて富を得るよりもいいよね。悲しいことじゃなくて、一般人がコンピュータを生産的に使うために起こった最高の出来事だと思う、検索エンジンの発明以来。

└

プログラマーはエンドユーザーのためにデジタル製品を作るべきじゃないの？これってただ速くするだけじゃん。雇われた人の視点みたいだね…結局、あなたがやってることが大きな世界にどう影響するか、そしてその世界があなたに何をしてくれるかを考える必要があるんだよ。それがあなたのエンドユーザー、つまり上司が考えてることだから。みんな、自分の小さなB2Bの世界（「私はXをする＝私はYを得る」）の中で泳ぐのが好きで、目の前のこと以外は考えないんだよね。

└

まだその盛り上がりには完全には乗れてないけど、実際にLLMが技術的解決策を民主化するのは、既存のプレイヤーにも新参者にも素晴らしいチャンスになると思う。LLMが進化すればするほど、技術自体の独自性は薄れていくよね。

└

AIは強力なプロンプトエンジニアリングスキルを持つ専門家をサポートできるけど、ユーザーが必要な専門知識を持っていない限り、本当に複雑なソリューションを作るのは難しいと思う。経験豊富な開発者にはこれらのツールは素晴らしいけど、ソフトウェアのバックグラウンドがない人にはほとんど魔法のように見える。でも、完全に理解していないソリューションを作るべきじゃないよ、それはメンテナンスの悪夢につながるから。

SQLデータアナリストとして何年も経験があるよ。ほとんどの役割は、小さなチームで大規模な数十億ドルのビジネスのために迅速なアドホック分析を作成することだった。例えば、あるデータベースはOracleのeビジネススイートだったんだけど、約20年前に設定されて、その後も改良が加えられてた。ATTR_000349857みたいに役立つ名前が付けられたフィールドを知っているのは、会社の中でほんの数人だけだった。みんな急なリクエストで忙しくて（時々レイオフもあったし）、データベースのドキュメントに時間をかける人はいなかった。これって「ビジネス特有の文脈を提供する」っていうトピックに当てはまるんじゃないかな。素晴らしい、じゃあそのクソみたいなことを理解して文書化する人を雇えばいいじゃん。でもそれは起こらないだろうね。他の役割もこのパターンに当てはまる、システムは違うけど急なニーズがあって、ビジネスとデータベースの両方を理解している人が常に不足してる。たまに「AIチーム」が「データ」を探しに来るけど、明確な目的もなく「利益を増やす」だけの無意味な会議を何度も重ねた後、静かに消えていく。SQLの例を引っ張ってきて調整するためにStack Overflowをよく使うんだけど、AIの話は盛り上がりすぎな感じがする。まずは「幻覚」とか「知性」とか、英語では別の意味を持つ言葉を再定義するのはやめた方がいいと思う。たぶん「高度なアルゴリズム」と呼んで、盛り上がりを止めた方がいいよ。それに、広告のためのユーザーデータの監視と抽出もね。ありがとう。

└

Oracle e-business suite [...] 約20年前に設定された > ATTR_000349857みたいに役立つ名前が付けられたフィールド > みんな忙しすぎた > 誰もデータベースの文書化に時間をかけなかった。ここでAIが役に立たないのは責められないよ、神の介入なしには解決できないことだから。

ハクソク