Text-to-SQL は当初は簡単に見えました。
平易な英語で質問すれば SQL が返り、クエリが走る。
小規模なセットアップでは、それで十分なことが多いです。何かおかしければ、誰かが気づいて直します。
事情が変わるのは、Text-to-SQL が共有 DB をまたぎ、多くのチームに使われ、実ビジネスやコンプライアンスに影響するようになったときです。その地点では、SQL は走るだけでは足りません。正しく、安全で、後から説明できる必要があります。
そこから、エンタープライズ級の Text-to-SQL はエンジニアリングの問題になります。
別々のチームが同じ問題に当たる
非常に異なるチームが、Text-to-SQL を実エンタープライズデータの前に置いた瞬間、同じ課題に当たりました。
-
OpenAI は社内データエージェントを作って、従業員が会社データに質問できるようにした経験を、日常運用で何が壊れたかとともに記しました。OpenAI Builds an Internal Data Agent
-
Google Cloud は、大きく雑然としたスキーマに対して Text-to-SQL を確実に動かすために追加する必要のあった実用テクニックを共有しました。Getting AI to write good SQL: Text-to-SQL techniques explained
-
Hex は、AI 機能を実ユーザーに出荷したときに本当に重要だったこと、そして足元の環境が変わり続けたことを振り返りました。Bitter lessons building AI products
-
Vercel は、本番でエージェントのツールの大半を最終的に削除した理由を説明しました — システムを推論しやすくするためです。We removed 80% of our agent's tools
別の製品、別のユーザー。しかし詳細に入ると、問題と修正のかたちはとても似てきます。
文脈: 最初にこじれた場所
ほぼ全員が同じところから始めました。
「とりあえずモデルにスキーマを渡そう」。
これはスキーマが大きくなり、結合が自明でなくなり、カラム名がデータの実利用を説明しなくなった瞬間に通用しなくなります。
OpenAI での問題は、スキーマだけでなく選択肢でした。内部エージェントは多くのツールと多くの経路を持っていました。強力ですが予測しづらく、何かおかしくなったときに理由を理解するのが難しい。修正はプロンプトの改善ではなく、削ること: 少ないツール、より明確なスコープ、より固定したステップ。
Google Cloud では、失敗は誤った結合と欠落したフィルタとして現れました。モデルが壊れていたわけではなく、推測していたのです。生の DDL はシグナルとして足りませんでした。スキーマテキストだけに頼るのをやめ、構造を加える方向に進みました — 明示的なテーブル関係、カラムのヒント、実クエリパターンを反映する例。
Vercel では、これが運用リスクとして現れました。ツールが多すぎると失敗モードも多すぎます。大半を削除しました。柔軟性は下がりましたが、推論しやすくなりました。
Hex では、曖昧な文脈がアナリストを混乱させました。実運用での指標定義をシステムが反映しないと、人は結果から誤った結論を引き出します。
これらすべてで、同じことが起きました。
システムに何もかも渡すと悪化し、 渡すものを減らし、その「少なさ」を非常に明確にすると、使いやすくなる。
実務上はこういう形になりました。
- 関連テーブルを事前選択する
- 許可される結合経路を定義する
- 可能な操作を制限する
- スキーマテキストだけでなく、実利用にクエリを接地する
評価: 「クエリが走った」がほとんど意味を失った地点
次の課題はもっと気づきにくいものでした。
悪いクエリの多くは失敗しませんでした。普通に走り、データを返し、ただ間違っていました。
Hex の手記にこれが明快に出ています。アナリストはもっともらしいが微妙にずれた結果を得ます。数回そうなった後、信頼は消えます。ユーザーが何でも二重チェックする必要を感じた瞬間、機能は役立たなくなります。
Google Cloud はシステム視点で同じ課題を語りました。実行の成功は、クエリが質問に合っているかを教えてくれません。フィルタの欠落や誤った結合は、意味を静かに変えてしまいます。
OpenAI では、文脈を絞った後でも、似た質問が別のクエリを生むことがあり、追加のチェックが要りました。その不整合自体が問題でした。
Vercel は非常に実用的な点に集中しました — 何かが壊れたとき、その理由を説明できるか？ 説明できない結果は、人が頼りにしません。
時とともに、チームは「走った」をゴールとみなさなくなりました。
代わりに、本番システムの経験者には見慣れたことをやり始めました。
- 構文だけでなくクエリの形を確認する
- 欠落したフィルタや疑わしい結合を見張る
- 「クリエイティブな」変動より再現可能な出力を選ぶ
- 生成された SQL を可視化し、人が推論できるようにする
ここで Text-to-SQL は手品ではなくなり、普通のソフトウェアに近い振る舞いを始めました。
ガバナンス: AI を他の DB ユーザーと同じく扱う
ここが多くの初期システムが飛ばした部分です。
実システムでは、SQL は機微データ、ビジネスロジック、規制ワークフローへのアクセスです。AI に SQL 生成を制限無しで許すことは、実質的に広い DB アクセスを与えることです。
どのチームも長くはその状態に留まりませんでした。
Vercel は、システムにできることを根こそぎ減らしました。能力が減ればリスクも減ります。
OpenAI は予測可能性に傾きました。エージェントは人が予期できる動き方をすべきで、驚かせるべきではない。
Google Cloud は制約をクエリの組み立て方そのものに埋め込みました — モデルがいつも「正しいこと」をしてくれると信じる代わりに。
Hex は透明性を非交渉条件にしました。ユーザーは SQL を見られ、結果がどう生じたかを理解できます。
実務上はとても退屈に見えます — そしてそれが良いことです。
- 既定は読み取り専用
- テーブルとカラムの明確な上限
- リスキー操作への追加チェック
- 誰が何を尋ね、実際に何が走ったかのログ
AI に特別ルールはありません。みんなと同じルールに従います。
別々の実装、同じかたち
製品名を無視して何が変わったかだけを見ると、かたちはほぼ同じです。
| 領域 | 何が変わったか |
|---|---|
| 文脈 | フルスキーマから、小さく明確な入力へ |
| 評価 | 「走る」から「これは本当に質問に答えているか」へ |
| ガバナンス | 暗黙の信頼から、明示的な上限とログへ |
巧みなプロンプトで誰も解きませんでした。より良いモデルを待った者もいません。皆、モデルの周りにエンジニアリング規律を置くことで解きました。
結び
エンタープライズ Text-to-SQL は、AI に SQL を書かせる話ではありません。何の SQL が許され、いつ受容され、結果を誰が所有するか、を決める話です。
別々のチームが別々の経路を取りましたが、皆同じ場所に辿り着きました — Text-to-SQL は、制約され、チェックされ、ガバナンスされたときだけスケールで機能する。
それは派手さを与えるものではありません。使えるようにするものです。