Text2SQL.ai × Supabase で「日本語で聞くだけでSQLが出てくる」を試してみた
Text2SQL.ai × Supabase で「日本語で聞くだけでSQLが出てくる」を試してみた
February 17, 2026
Text2SQL.ai × Supabase で「日本語で聞くだけでSQLが出てくる」を試してみた
SQLを書かなくていい世界、来てるかも
「先月のイベント一覧を見せて」——こんなふうに日本語で聞くだけで、AIがSQLクエリを自動生成して、データベースから結果を返してくれる。そんな「Text to SQL」の世界が、思っていた以上に実用レベルになってきています。
今回は Text2SQL.ai というサービスに、Supabase（PostgreSQL）上で運用している業務用データベースを実際につないで、どこまで使えるのかを検証してみました。
使ったもの
Text2SQL.ai：自然言語 → SQL自動生成のAIサービス
Supabase：PostgreSQLベースのBaaS。ダッシュボードからDB接続情報がサクッと取れる
対象DB：業務で使っているプロジェクト管理系のデータベース（イベント、グッズ、メンバーなど複数テーブルあり）
セットアップ：びっくりするほど簡単だった
正直、「外部ツールにDB接続するの面倒そうだな…」と思っていたのですが、拍子抜けするくらい簡単でした。
やったことはたった3ステップ
① Supabaseで接続情報を取得
Supabaseダッシュボードの Connect ボタンを押すと、Host・Port・Database・User・Passwordがまとめて表示されます。これをコピーするだけ。
② Text2SQL.aiでデータベースを登録
Text2SQL.aiにログインして、サイドバーの Configuration → Databases → Add Database からPostgreSQL接続を作成。Supabaseからコピーした情報を貼り付けて、SSLを有効にして、Test Connectionをポチッ。
③ スキーマを選択して完了
接続が成功するとテーブル構造が自動で取得されるので、使いたいスキーマ（今回はpublic）を選択して保存。これだけで準備完了です。
所要時間、体感で 5分くらい でした。
実際に試してみた
テスト1：「全部のイベントを表示して」
まずは一番シンプルなやつから。
日本語で「全部のイベントを表示して」と入力したところ、生成されたSQLは：
SELECT * FROM "events"
結果：✅ 完璧。 何の問題もなく、eventsテーブルの全レコードが返ってきました。
ちなみにText2SQL.aiは、SQLを生成した後にいきなり実行するのではなく、「このクエリでいいですか？」と確認してくれます。 ユーザーが「Run」を押して初めて実行される安全設計になっていて、ここは安心ポイントです。
テスト2：「全グッズの表示」
次に「全グッズの表示」と入力。こちらも問題なくグッズテーブルのデータが返ってきました。
結果：✅ 正常にSQL生成・実行。
テーブル名とカラム名から、どのテーブルを参照すべきかをちゃんと判断してくれています。
テスト3：「アクティブなユーザー」
さて、ここで少しひっかけ気味の質問を。「アクティブなユーザー」と聞いてみました。
結果：⚠️ 意図しないテーブルを参照してしまった。
このデータベースには member テーブルと m_member テーブルの両方が存在しており、AIは member テーブルを参照しました。しかし、本来参照してほしかったのは m_member テーブルの方でした。
これは テーブル名の曖昧さ が原因です。似たような名前のテーブルが複数あると、AIがどちらを選ぶべきか正しく判断できないことがあるわけですね。
わかったこと：精度はテーブル設計に大きく左右される
3つのテストを通じて感じたのは、Text2SQL.aiの精度は、データベースの「わかりやすさ」に直結する ということです。
うまくいくケース
テーブル名やカラム名が明確で、意味が推測しやすい
1対1の関係が明確（「イベント」→
eventsテーブル、のように迷いがない）シンプルなSELECT系のクエリ
注意が必要なケース
memberとm_memberのように似た名前のテーブルが共存しているカラム名が汎用的（
name,type,statusなど）で、複数テーブルに同じ名前があるビジネスロジック特有の意味（「アクティブ」の定義など）がスキーマから読み取れない
対策としてやるべきこと
ここは改善の余地があるところで、以下の対策が有効そうです。
テーブルやカラムにdescription（説明文）を追加する — Text2SQL.aiのSchema Viewerから設定できます。例えば「
m_memberはマスタテーブルで、こちらが正」と書いておくだけでAIの判断精度が上がります不要なテーブルをスキーマから除外する — 使わないテーブルは接続設定で除外しておくと、誤参照のリスクが減ります
クエリ実行前に生成SQLを目視確認する — Text2SQL.aiは確認ステップがあるので、ここでテーブル名をチェックする習慣をつけると安全です
セキュリティの話
業務用DBを外部サービスにつなぐとなると、セキュリティは当然気になります。
Text2SQL.aiの公式ドキュメントによると、接続情報は暗号化保存、データ本体ではなくスキーマ構造のみが保持されるとのこと。クエリ実行もアプリケーション本体とは分離されたサーバーで行われるようです。
とはいえ、念のため以下は守った方がよいでしょう。
読み取り専用のDBユーザー を作成して接続する（SELECT権限のみ）
Safe Mode（読み取り専用モード） を有効にしておく
可能なら 本番DBではなくレプリカや検証用DB を使う
まとめ：「SQLの民主化」は始まっている
今回の検証で感じたのは、Text to SQLは 「SQLが書ける人の生産性を上げるツール」であると同時に、「SQLが書けない人にデータアクセスを開放するツール」 でもあるということです。
たとえばこんな使い方が考えられます。
営業チームが自分で「今月の売上トップ10を教えて」とデータを引く
カスタマーサポートが「〇〇さんの注文履歴を見せて」で即座に情報を確認する
経営層が定例レポートを待たずに「今月のアクティブユーザー数は？」と自分でチェックする
エンジニアへの「ちょっとデータ出してもらえますか？」という依頼が減り、知りたい人が知りたいときにデータへアクセスできる世界。Text2SQL.aiとSupabaseの組み合わせで、その入り口はもう目の前にあります。
ただし、その精度を最大限に発揮するには、テーブル設計のわかりやすさとスキーマへの説明文追加がカギになります。ツールの導入と同時に、データベースの「読みやすさ」を整えていくことが、Text to SQL成功の近道だと感じました。
検証環境：Text2SQL.ai / Supabase (PostgreSQL) / 2026年2月
Text2SQL.ai × Supabase で「日本語で聞くだけでSQLが出てくる」を試してみた
SQLを書かなくていい世界、来てるかも
「先月のイベント一覧を見せて」——こんなふうに日本語で聞くだけで、AIがSQLクエリを自動生成して、データベースから結果を返してくれる。そんな「Text to SQL」の世界が、思っていた以上に実用レベルになってきています。
今回は Text2SQL.ai というサービスに、Supabase（PostgreSQL）上で運用している業務用データベースを実際につないで、どこまで使えるのかを検証してみました。
使ったもの
Text2SQL.ai：自然言語 → SQL自動生成のAIサービス
Supabase：PostgreSQLベースのBaaS。ダッシュボードからDB接続情報がサクッと取れる
対象DB：業務で使っているプロジェクト管理系のデータベース（イベント、グッズ、メンバーなど複数テーブルあり）
セットアップ：びっくりするほど簡単だった
正直、「外部ツールにDB接続するの面倒そうだな…」と思っていたのですが、拍子抜けするくらい簡単でした。
やったことはたった3ステップ
① Supabaseで接続情報を取得
Supabaseダッシュボードの Connect ボタンを押すと、Host・Port・Database・User・Passwordがまとめて表示されます。これをコピーするだけ。
② Text2SQL.aiでデータベースを登録
Text2SQL.aiにログインして、サイドバーの Configuration → Databases → Add Database からPostgreSQL接続を作成。Supabaseからコピーした情報を貼り付けて、SSLを有効にして、Test Connectionをポチッ。
③ スキーマを選択して完了
接続が成功するとテーブル構造が自動で取得されるので、使いたいスキーマ（今回はpublic）を選択して保存。これだけで準備完了です。
所要時間、体感で 5分くらい でした。
実際に試してみた
テスト1：「全部のイベントを表示して」
まずは一番シンプルなやつから。
日本語で「全部のイベントを表示して」と入力したところ、生成されたSQLは：
SELECT * FROM "events"
結果：✅ 完璧。 何の問題もなく、eventsテーブルの全レコードが返ってきました。
ちなみにText2SQL.aiは、SQLを生成した後にいきなり実行するのではなく、「このクエリでいいですか？」と確認してくれます。 ユーザーが「Run」を押して初めて実行される安全設計になっていて、ここは安心ポイントです。
テスト2：「全グッズの表示」
次に「全グッズの表示」と入力。こちらも問題なくグッズテーブルのデータが返ってきました。
結果：✅ 正常にSQL生成・実行。
テーブル名とカラム名から、どのテーブルを参照すべきかをちゃんと判断してくれています。
テスト3：「アクティブなユーザー」
さて、ここで少しひっかけ気味の質問を。「アクティブなユーザー」と聞いてみました。
結果：⚠️ 意図しないテーブルを参照してしまった。
このデータベースには member テーブルと m_member テーブルの両方が存在しており、AIは member テーブルを参照しました。しかし、本来参照してほしかったのは m_member テーブルの方でした。
これは テーブル名の曖昧さ が原因です。似たような名前のテーブルが複数あると、AIがどちらを選ぶべきか正しく判断できないことがあるわけですね。
わかったこと：精度はテーブル設計に大きく左右される
3つのテストを通じて感じたのは、Text2SQL.aiの精度は、データベースの「わかりやすさ」に直結する ということです。
うまくいくケース
テーブル名やカラム名が明確で、意味が推測しやすい
1対1の関係が明確（「イベント」→
eventsテーブル、のように迷いがない）シンプルなSELECT系のクエリ
注意が必要なケース
memberとm_memberのように似た名前のテーブルが共存しているカラム名が汎用的（
name,type,statusなど）で、複数テーブルに同じ名前があるビジネスロジック特有の意味（「アクティブ」の定義など）がスキーマから読み取れない
対策としてやるべきこと
ここは改善の余地があるところで、以下の対策が有効そうです。
テーブルやカラムにdescription（説明文）を追加する — Text2SQL.aiのSchema Viewerから設定できます。例えば「
m_memberはマスタテーブルで、こちらが正」と書いておくだけでAIの判断精度が上がります不要なテーブルをスキーマから除外する — 使わないテーブルは接続設定で除外しておくと、誤参照のリスクが減ります
クエリ実行前に生成SQLを目視確認する — Text2SQL.aiは確認ステップがあるので、ここでテーブル名をチェックする習慣をつけると安全です
セキュリティの話
業務用DBを外部サービスにつなぐとなると、セキュリティは当然気になります。
Text2SQL.aiの公式ドキュメントによると、接続情報は暗号化保存、データ本体ではなくスキーマ構造のみが保持されるとのこと。クエリ実行もアプリケーション本体とは分離されたサーバーで行われるようです。
とはいえ、念のため以下は守った方がよいでしょう。
読み取り専用のDBユーザー を作成して接続する（SELECT権限のみ）
Safe Mode（読み取り専用モード） を有効にしておく
可能なら 本番DBではなくレプリカや検証用DB を使う
まとめ：「SQLの民主化」は始まっている
今回の検証で感じたのは、Text to SQLは 「SQLが書ける人の生産性を上げるツール」であると同時に、「SQLが書けない人にデータアクセスを開放するツール」 でもあるということです。
たとえばこんな使い方が考えられます。
営業チームが自分で「今月の売上トップ10を教えて」とデータを引く
カスタマーサポートが「〇〇さんの注文履歴を見せて」で即座に情報を確認する
経営層が定例レポートを待たずに「今月のアクティブユーザー数は？」と自分でチェックする
エンジニアへの「ちょっとデータ出してもらえますか？」という依頼が減り、知りたい人が知りたいときにデータへアクセスできる世界。Text2SQL.aiとSupabaseの組み合わせで、その入り口はもう目の前にあります。
ただし、その精度を最大限に発揮するには、テーブル設計のわかりやすさとスキーマへの説明文追加がカギになります。ツールの導入と同時に、データベースの「読みやすさ」を整えていくことが、Text to SQL成功の近道だと感じました。
検証環境：Text2SQL.ai / Supabase (PostgreSQL) / 2026年2月
