Text2SQLに取り組む中で得た知見

Text2SQLに取り組む中で得た知見 CONFIDENTIAL MUFG A I St u di o Yu to Kob ay a sh i 2025.11.07 © 2025 Japan Digital Design, Inc. 1

プロフィール • 証券系IT子会社にてキャリアをスタート • 2020年9月にJDDへJoin • 1度離任を経て再度2023年にJoin(計4年半所属) • 金融系SE/PM:7年 , DS5年 • 直近は産業検索RAGプロダクトのDSリード 小林優人 AI & Data Science Div. Senior Data Scientist CONFIDENTIAL © 2025 Japan Digital Design, Inc. 2

アジェンダ 1. Text2SQLとは 2. アプローチ 3. テーブル探索の考え方 4. データ理解とSQL修正の流れ 5. 精度向上施策 6. 今後の課題 CONFIDENTIAL © 2025 Japan Digital Design, Inc. 3

Text2SQLとは CONFIDENTIAL © 2025 Japan Digital Design, Inc. 4

質問 • データセット検索 • 自然言語で質問を入力 データセットの中から回答に 必要なデータセットを選択 ユーザー • 選択したデータセットから 必要なデータを検索・加工 データセット 検索 質問 LLM LLM データベース 回答 データ検索・加工 • 検索加工したデータで回答を生成 データ 検索・加工 LLM 回答 生成 LLM ユーザー Text2SQLとは • ユーザーが自然言語（日本語や英語）で入力した質問を、LLMが自動的にSQLクエリに変換する技術 • 専門知識がなくても容易に分析ができ、非エンジニア部門でもデータドリブンな意思決定が可能になる • 必要なデータを迅速に取得できるため、ビジネス部門の意思決定や仮説検証のスピード向上が期待できる。 CONFIDENTIAL © 2025 Japan Digital Design, Inc. 5

Text2SQLのアプローチ CONFIDENTIAL © 2025 Japan Digital Design, Inc. 6

1.指示理解 アプローチ 2.テーブル選定 人間がSQLを作成するうえでのフローをなぞって処理を用意。 1. 指示理解 - ユーザーの要望を正確に把握 2. テーブル選定 - テーブル一覧から利用するテーブルを判断 3. カラム確認 - ディスクリプションで利用可能なデータを確認 4. ユニーク値確認 - SQLで候補カラムの値を参照 5. SQL生成 - 実際のSQLを作成 3.カラム確認 4.ユニーク値の確認 5.SQL生成 CONFIDENTIAL © 2025 Japan Digital Design, Inc. 7

テーブル選定：説明文の活用が精度を左右する LLMが理解しやすい情報構造の設計 テーブル一覧 プロセス 依頼文「顧客の入出金情報を出したい」から、適切なテ ーブル（transaction_history）を判断させる。 テーブル名 説明 件数 customers 顧客マスタ。顧客の基本情報（名前、住所、登録日） 15,234 を保持 orders transaction_history LLMの得意分野 カラム名単体（例：「amount」「date」）よりも、テ ーブルディスクリプションやカラムディスクリプション の理解が得意。詳細な説明を提供することで精度が向上 実装のコツ テーブルディスクリプションやカラムディスクリプショ ンをLLMに生成させる。 DDLやサンプルレコードなどを活用するのがポイント 精度向上のポイント 「説明文の質 = テーブル選定の精度」。曖昧な説明では LLMも判断できない。 ✓ 注文情報。顧客が発注した商品注文の履歴 48,567 顧客の全ての入出金記録。日付・金額・取引種別を含 156,890 む payments 支払い処理情報。請求から実際の支払いまでの記録 52,341 accounts 顧客口座情報。銀行口座や残高管理 14,987 transaction_history - カラム定義 カラム名 型 説明 サンプル値 transaction_id INT 取引を一意に識別するID 10001 customer_id INT 顧客ID（customers表と関連） 5234 amount DECIMAL 取引金額。正：入金、負：出金 15000.00 transaction_date DATE 取引が発生した日付 2025-01-15 type VARCHAR 取引種別（deposit/withdrawal/transfer） deposit

データ理解とSQL生成 テーブル確定後のプロセス transaction_history - データ確認例 amount カラム（金額） データ確認 カラムのサンプル地、ユニーク値、統計値を確認し、デ ータの特性を把握。 条件補完 データの分布や値の特性を踏まえ、ユーザーの文脈に対 して最適な条件を設定する。 最小値 -50000.00 最大値 150000.00 平均値 12345.67 NULL率 0% type カラム（取引種別） ユニーク値： deposit withdrawal transfer 件数 SQL生成 確認したデータ特性を踏まえてSQLを生成。実行→エラ ー解析→修正のループも同時に回す。 人間がSQLをデバッグする際の思考プロセスをLLMに再 現させることで、単なる自動修正ではなく「なぜ修正が 必要か」を理解させる。 3 values transaction_date カラム（日付） 最古日付 2024-01-01 最新日付 2025-01-31 NULL率 0% customer_id カラム（顧客ID） ユニーク数 14,987 レコード数 156,890 NULL率 0%

精度向上施策 CONFIDENTIAL © 2025 Japan Digital Design, Inc. 10

SQL生成後の見直しフロー：自己チェック&修正 人間のレビュー・メンタリングプロセスをLLMで再現 → 見直しの観点（チェックリスト） 修正時の出力内容 WHERE句の精度 □ ユーザーの質問を完全に反映しているか □ 不要な条件がないか □ 条件の論理は正しいか（AND/OR） 修正内容 WHERE句にstatus='completed'を追加 データ単位の変換 □ ユーザーが求める単位は何か □ テーブルの粒度と一致しているか □ 集計が必要な場合、正しいか その他の確認 □ カラム名の存在確認 □ データ型の一致確認 □ NULLハンドリング 修正前: WHERE transaction_date >= '2023-01-01' 修正後: WHERE transaction_date >= '2023-01-01' AND status = 'completed' 修正の観点 WHERE句の精度向上 - ユーザー質問の完全性確保 修正の理由 「完了した取引」という要件を見落としていた。statusカラムのユニーク 値確認で'completed'の存在を確認。 修正内容 GROUP BY customer_id を追加し、顧客単位の集計に変更 修正前: SELECT transaction_date, amount FROM transactions 修正後: SELECT customer_id, SUM(amount) FROM transactions GROUP BY customer_id 修正の観点 データ単位の変換 - ユーザーが求める粒度への調整 修正の理由 ユーザーの質問「顧客ごとの売上合計は？」は顧客単位の集計を求めてい るが、テーブルは取引単位の粒度。GROUP BY で顧客単位に変換。

精度向上の工夫：テーブル形式 多様なカテゴリが混在する実務データの課題と解決策 対策：Wideフォーマット + ディスクリプション 課題：Longフォーマットの限界 ✗ 利用したデータには複数の日本語カテゴリが混在 ✓ カテゴリ値をカラム方向に配置し、全選択肢を一度に提示 ✗ 複数行に分散したデータでは、全ユニーク値の把握が困難 ✓ 時系列データを行方向に並べ、データ構造を明確化 ✗ 各値の定義や関係性が不明で、LLMの精度が大幅に低下 ✓ LLMが値の意味と関係性を正確に理解 実装例：日本語カテゴリが多い例 Longフォーマット（問題あり） year_month Wideフォーマット（改善） industry value year_month 製造業 卸売業 小売業 金融・保険業 情報通信業 2023-01 製造業 1,234 2023-01 1,234 567 890 2,100 1,800 2023-01 卸売業 567 2023-02 1,345 612 920 2,250 1,950 2023-01 小売業 890 2023-03 1,456 658 950 2,400 2,100 2023-02 製造業 1,345 2023-04 1,567 704 980 2,550 2,250 2023-02 卸売業 612 ✓ 産業がカラム方向に配置。時系列が行方向。全ユニーク値と時系列の関係が一目瞭然。LLMが正確に理解可能。 2023-02 小売業 920 2023-03 製造業 1,456 2023-03 卸売業 658 2023-03 小売業 950 ✗ 複数行に分散。産業が繰り返し出現。全ユニーク値と時系列の関係が不明。

精度向上の工夫：Wideフォーマットとlongフォーマットの使い分け 利用するデータや取得結果の使い方次第で最適なフォーマットを選択 Longフォーマット Wideフォーマット メリット メリット ✓ コンテキスト量を抑えることができる ✓ データの正規化が容易で運用しやすい ✓ デメリット デメリット ✕ 複数行に分散したデータ ✕ 全ユニーク値の把握が困難 ✕ 適用シーン 適用シーン カテゴリ数が少ない → レコード量が多い → 全選択肢を一度に提示 ✓ データ構造が明確でLLMも理解しやすい カラム数が増加しコンテキスト量を圧迫 ✕ スパースなデータになる可能性 ✕ 保守性が低下する LLMへの情報提供が目的 → カテゴリ別の比較分析 → 複数の日本語カテゴリ混在 → year_month industry value year_month 製造業 卸売業 小売業 2023-01 製造業 1,234 2023-01 1,234 567 890 2023-01 卸売業 567 2023-02 1,345 612 920 2023-02 製造業 1,345 産業がカラム方向に配置。時系列が行方向。 複数行に分散。産業が繰り返し出現。

今後の課題 CONFIDENTIAL © 2025 Japan Digital Design, Inc. 14

今後の課題：スケーラビリティと効率性の向上 大規模データベース環境での実運用を見据えた課題と解決策 課題1：コンテキスト量の節約 課題2：実行時間の問題 問題点 問題点 テーブルやカラムのディスクリプション、サンプル値、統計情報をコンテキストに 詰めていくことで、LLMへ送信するトークン数が急速に増加。大規模データベース （数百～数千テーブル）では、コンテキストサイズの制限に達する可能性が高い。 DBメタ情報（テーブル定義、カラム情報、ユニーク値、統計情報）の取得に時間が かかる。毎回のクエリ生成時にメタ情報を取得していると、全体の実行時間が大幅 に増加。特に大規模DBでは顕著。 解決策 解決策 ✓ 重要度ベースの情報フィルタリング ✓ DBメタ情報のキャッシング（Redis等） ✓ ユーザーの質問から関連テーブルを特定し、必要な情報のみを抽出 ✓ 定期的な更新スケジュール（差分更新） ✓ ベクトル化による類似度検索で、最適なテーブル・カラムを優先的に提供 ✓ 段階的な情報取得（初期段階では基本情報のみ） ✓ 段階的なコンテキスト構築（初期最小限 → 必要に応じて追加） ✓ 事前計算による統計情報の提供 期待される改善 期待される改善 → コンテキストサイズ：50～70%削減 → メタ情報取得時間：90%削減 → API呼び出しコスト：大幅削減 → 全体レイテンシ：50%削減 → 応答速度：向上 → スケーラビリティ：大幅向上

Thank you. CONFIDENTIAL © 2025 Japan Digital Design, Inc. 16