NL2SQLのピッチには完璧に聞こえるバージョンがあります：ユーザーが自然言語で質問し、エージェントがSQLを生成し、データが返ってくる。画面が少なく、クエリが少なく、コードが少ない。シンプル。
そして5分後にもっと考えます。
デモで誰も話さない問題
スキーマは物事を説明するように設計されていません。 不可解なテーブル名、一貫性のないカラム名、追加の述語なしでは意味的に無効な技術的に有効な関係 — これらはエンタープライズデータベースでは普通のことです。バグではなく、ビジネス変更の蓄積された歴史です。しかし、意図を伝えるように設計されていないスキーマから意図を推論するようにモデルに求めると、モデルは何があっても試みます。諦めません。最善のクエリを生成し、自信を持って結果を返します。
モデルは決定論的ではありません。 同じデータベースに同じ質問を2回して、異なるSQLを得るかもしれません。モデルは確率を計算しており、コンテキストのわずかな変化が異なる出力を生み出します。エージェントが常に正しいクエリを生成するという保証をテストで達成することはできません。
ユーザーレビューはスケールしません。 「実行前にすべてのクエリを確認するだけ」は安全に聞こえます。しかし、ユーザーがデータモデルとSQLの両方の専門家であることを前提としています — 自然言語インターフェースを必要としなかった人々まさにその人たちです。また、認知的過負荷と確認バイアスの新しいクラスをもたらし、クエリの複雑さに圧倒されたユーザーが無効なクエリを調査するのではなく承認します。
そしてインジェクションがあります。 従来のSQL開発では、パラメータ化がインジェクションを解決しました。ユーザー入力はSQLの構造ではなく、パラメータを埋めていたからです。NL2SQLでは、モデルがSQL自体を生成します。プロンプト、スキーマコンテキスト、会話履歴、取得されたデータすべてが実行されるものに影響します。誰かがモデルが生成するものを変えるプロンプトを作成した場合、それはインジェクションです — パラメータレベルではなく、クエリ生成レベルで。そしてテーブルの削除（明らか、回復可能）とは異なり、NL2SQLインジェクションは目に見えるエラーなしに誤った結果を返すクエリを生成します。ビジネス上の意思決定が間違ったデータに基づいてなされます。
SQL MCP Serverが実際に解決すること
ここで記事は最も実践的に有用な点を述べます。エージェントに任意のスキーマアクセスを与えて最善を望むのではなく、SQL MCP ServerはData API builderの上に構築された厳選されたAPIサーフェスを公開します。
違いは重要です：エージェントはSQLを生成しません。事前定義された結果形式を返す名前付きエンドポイントを呼び出します。SQLは開発者によって一度書かれ、決定論的です。エージェントの非決定論は任意のクエリを構築することではなく、どのエンドポイントを呼び出すかを選択することに制限されます。
これは従来のアプリモデルでのSQLインジェクションに対してパラメータ化が行ったこと — 信頼できない入力から任意のクエリを構築する能力を削除すること — に類似しています。
正しい質問
記事は「NL2SQLを決して使うな」とは言っていません。それは言います：どこで適用し、何を公開するかについて慎重に考えてください。スコープされたスキーマと読み取り専用アクセスを持つ制御された環境での探索的分析には、NL2SQLで問題ないかもしれません。ビジネス上の意思決定が結果に依存する本番システムには、厳選されたAPIレイヤーが大幅に安全です。
正直に言うと：いくつかの問題は、自然言語からSQLよりも名前付きエンドポイントの背後にある構造化されたクエリで解決する方が本当に優れています。SQL MCP Serverはエージェントインターフェースを完全に放棄することなく、そのオプションを提供します。
元の投稿: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?
