― 業務要望に応えるために「設計とカスタマイズ開発」が不可欠な理由
生成AIの進化により、「自然言語からSQLを生成できる」という話をよく耳にするようになりました。
一見すると、
テーブル定義書をAIに渡せば、業務ユーザーの質問をそのままSQLに変換してくれる
ように思えます。
しかし、実際の業務システム開発の現場では、これは成り立ちません。
本記事では、通常の開発プロセスを例にしながら、
なぜ自然言語→SQLにはカスタマイズ開発が必要なのかを整理します。
よくある誤解：テーブル定義があればSQLは書ける？
まず、自然言語→SQLに対してよくある期待です。
- テーブル定義書がある
- カラム名も分かっている
- だから自然言語からSQLは自動生成できるはず
しかしこれは、プログラマの仕事を極端に単純化して捉えた考え方です。
通常の業務システム開発を振り返る
ここで、一度冷静に「普通の業務システム開発」を振り返ってみます。
プログラマに開発を依頼する場合、何を渡しますか？
多くの現場では、テーブル定義書だけを渡すことはありません。
一般的に必要になるのは、次のような成果物です。
- 要件定義書
- 機能一覧・機能概要
- 機能詳細設計書
- 画面遷移図
- 画面項目定義書
- コード定義書
- テーブル定義書
- 業務ルール・例外条件の整理資料
なぜここまで必要なのでしょうか。
理由：業務ロジックはテーブル定義に書かれていない
テーブル定義書に書かれているのは、あくまで 「データの形」 です。
一方、プログラマが実装するのは、
- どの機能で
- どの条件のときに
- どのデータを
- どの粒度で
- どのように集計・表示するか
という 業務ロジック です。
これは、
- 機能詳細設計書
- 画面設計
- 業務ルール定義
といった設計書を通じて初めて明確になります。
自然言語→SQLも、同じ構造を持っている
自然言語からSQLを生成する仕組みも、本質的には同じです。
ユーザーの質問例
「今月の部門別の在籍人数を知りたい」
この一文だけでは、SQLは決まりません。
- 「在籍」とは何を意味するのか
- 対象となる部門マスタはどれか
- 退職予定者は含めるのか
- 集計日は月初か月末か
- どの機能のデータを使うのか
これらは 業務設計で決めるべき内容 です。
自然言語→SQLは「業務モデルの実装」
つまり、自然言語→SQLとは、
自然言語を、業務で定義された機能・ルール・データ構造にマッピングし、
実行可能なSQLに落とし込むこと
です。
これは、
- 機能定義
- 用語定義
- ルール定義
- テーブル設計
を前提とした 業務モデルの実装 に他なりません。
なぜカスタマイズ開発が必要なのか
汎用的なAIは、
- テーブル構造
- SQL文法
は理解できます。
しかし、
- 「この会社における“在籍”の定義」
- 「この機能で使う正しいテーブル」
- 「この質問で許可される集計粒度」
といった 業務固有の判断基準 は、外から与えなければ分かりません。
そのため、
- 業務用語集
- 機能ごとの参照テーブル定義
- SQL生成ルール
- 想定質問パターン
といった カスタマイズ設計・実装 が必須になります。
まとめ
自然言語からSQLを生成する技術は、確かに強力です。
しかしそれは、
- 「設計を不要にする技術」ではなく
- 「設計を別の形で実装する技術」
です。
通常のシステム開発で
テーブル定義書だけでプログラマに業務ロジックを実装させないのと同じように、
自然言語→SQLでも 業務要望に応じたカスタマイズ開発が不可欠です。
生成AIは魔法ではありません。
業務を理解し、設計し、実装することの重要性は、むしろこれまで以上に高まっています。