プロジェクトへ戻る

社内・開発中

NL2SQL品質改善

自然言語の質問を、セキュリティ・資産データを検索するSQLへ変換する社内サービスの品質改善です。

利用者の普段の質問を、業務用PostgreSQLを検索するSQLへ変換する社内サービスです。OMNIGuardで始めた改善を、成果が評価された後は別の製品領域へも広げました。約600テーブルの既存画面・ログ・SQLから正解条件を復元し、回答例、基本指示、評価質問を設計しました。

期間
2026.06 - 2026.08
担当範囲
業務SQL分析 · プロンプト設計 · 評価
プロジェクト
LSware社内プロジェクト
リポジトリ
非公開リポジトリ

回答例を増やす前に、製品の正解を復元する

クラロンエックスは、利用者が普段の言葉で質問すると、セキュリティ製品や社内資産の情報を検索して返すサービスです。データベースの構造を知らない利用者にも、現在の設置状況や最新履歴に沿った答えを返す必要がありました。

LSwareでは、まずOMNIGuardの製品領域を対象に回答例を追加する仕事を任されました。初期成果が評価され、同じ改善手順を別の製品領域へも広げました。回答例は利用者の質問と正解SQLを一組にしてAIへ見せる資料ですが、対象は十分に文書化されていない約600テーブルの業務DBで、どのテーブルと条件が正解なのかを示す資料も揃っていませんでした。

最初はどこから正解を決めればよいのか戸惑いました。SQLが実行できても、削除済みの情報や古い履歴を選べば利用者には誤答になるため、例を増やす前に製品の動作から正解条件を復元する必要がありました。

回答を確かめる流れ

曖昧な質問を、確認できる検索結果へ変えるまで

  1. 01

    利用者の質問

    同じ意味でも異なる言い方

  2. 02

    業務ルール

    ログ・DDL・既存SQLから確認

  3. 03

    AIへの指示と見本

    基本指示+回答例

  4. 04

    生成されたSQL

    文法と業務上の意味を確認

  5. 05

    実行と人の確認

    PostgreSQLの結果まで確認

正解SQLを、共通ルールと質問別パターンの二層に分ける

生成SQLは実行できても、削除済みデータや古い履歴を選べば業務上は誤答になります。

約600テーブルの中で、削除除外・最新履歴・読み取り専用のような条件は多くの質問に共通し、JOINや集計は質問ごとに変わりました。

共通条件はシステムプロンプトへ、質問固有のJOINと集計は回答例へ分けました。AIは質問候補を作る用途に限定し、正解SQLは既存画面・ログ・実行結果で人が確認しました。

  • 既存画面から削除・期間・最新状態の条件を復元しました。
  • 社内類似作業の30〜40件規模に対し、質問–SQLの回答例約176件とホールドアウト評価80問を作成しました。
  • 共通ルールを除いた構成と併用構成を同じ基準で比較しました。

共通ルールなしでは基準充足率が約30〜40%でしたが、ルールと例を併用すると定義した80問すべてで期待SQL基準を満たしました。

例の数より、再利用するルールと質問ごとのパターンの境界が品質を左右しました。

DDLの外にある業務ルールを、実行ログから探す

約600テーブルの中には似た名前の現在・履歴テーブルや、宣言された関係だけでは用途を判断できない構造がありました。DDLだけでは、実際の画面がどの条件でデータを選ぶかを確定できませんでした。

必要なログは社内Linux環境にあり、当初は私の担当アカウントにアクセス権がありませんでした。また、内部のテーブル名やSQL本文を外部資料へ出すことはできませんでした。

調査目的と範囲を上長へ説明してアクセス権を受けた後、画面操作とそのとき記録されるDBログを対応づけ、DDL・既存SQLと交差確認する方法を選びました。

  • 特定の画面操作と発生したクエリを対応づけて記録しました。
  • 現在・履歴、論理削除、製品設置判定の条件を抽出しました。
  • 確認した根拠をデータモデルガイドと引き継ぎ文書へ整理しました。

復元した規則はシステムプロンプト、回答例、評価基準の根拠として使いました。内部ログそのものは公開せず、ポートフォリオには調査方法と確認できた規則の種類だけを記載しています。

文書が足りない環境では、理想的な構造を推測する前に、実際の動作から確認可能な根拠を集める必要がありました。

質問–SQL回答例を約176件整備し、回答例から分離したホールドアウト評価80問すべてで期待SQLの基準を満たしました。

社内プロジェクトのため、リポジトリ、SQL、プロンプト、評価データは非公開です。

文書がないときは理想モデルを推測するより、ログと実際の動作から根拠を集めるようになりました。例を増やす前に、エラー分類と評価基準を作るようにもなりました。

80/80は、限定した社内製品範囲と評価セットでの結果です。他の顧客スキーマや、あらゆる自然言語質問に対する一般的な精度を示すものではありません。

  • 回答例と評価質問の意味的な近さを監査し、より厳しい条件で再評価
  • 別ドメインで同じ手順が再現するか検証
  • 実行成功率・意味エラー・レイテンシ・コストを必要に応じて測定