「来月の売上予測に必要なデータを抽出しておいて」
もし、この一言だけでデータベースから正確なデータ（CSV）が出力されるなら、データ抽出の作業は劇的に変わるでしょう。経営層やマーケティング担当者が、エンジニアの手を借りずに自ら必要なデータを取り出せるようになるかもしれません。
Text-to-SQL（普段私たちが話す言葉からデータベース操作言語であるSQLへの変換）は、大規模言語モデル（LLM）の登場以前から研究されてきた分野ですが、近年の生成AIの進化により、その実用性は飛躍的に向上しました。しかし、実際に業務への導入を検討する現場では、常に一つの「壁」に直面します。
「そのSQLは、本当に正しいのか？」
文法的に正しいSQLが生成されることと、ビジネスの目的に合った正しいデータが抽出されることは別問題です。単純なデータ抽出なら簡単ですが、実務で求められるのは、複数の表（テーブル）を結合し、特定の条件で絞り込み、日付や数値を正しく集計する複雑な処理です。
現在、AIモデルの世代交代は急速に進んでいます。GPT-4oなどの旧モデルから新たな標準となったGPT-5.2への移行、推論能力や自律的なタスク実行能力が飛躍的に向上したClaude Sonnet 4.6の登場、そして複数の専門家モデルを組み合わせた仕組み（MoEアーキテクチャ）を採用したLlamaの展開など、各モデルの性能は大きくアップデートされています。
本記事では、ビジネス実務での導入を判断するための厳格なベンチマーク（性能評価）結果を共有します。GPT-5.2、Claude Sonnet 4.6、そして無償で利用できるオープンソースのLlama 4を対象に、100本のテスト問題（単純な抽出から複雑な集計まで）を投げかけ、その「正答率」と「コスト」、そして「リスク」を実証データに基づき定量的に評価しました。
AIにデータ抽出を完全に任せるべきか、それともまだ人間が介在すべきか。最新モデルの検証結果から、実務適用のための論理的な判断材料を提供します。
Text-to-SQLの実務適用における「信頼性」の課題
多くのText-to-SQLツールやデモ動画では、「エラーが出ずにSQLが実行できた」という事実が高らかにアピールされます。しかし、データ分析の現場において、これは最低ラインに過ぎません。
なぜ「動くSQL」だけでは不十分なのか
想像してみてください。先月の解約率を計算するSQLをAIに生成させたとします。SQLはエラーなく実行され、「3.5%」という数字が返ってきました。しかし、実はAIが「解約日」ではなく「最終ログイン日」を参照していたとしたらどうでしょうか。
この「エラーが出ない間違い（サイレントエラー）」こそが、最大のリスクです。構文エラーなら修正できますが、論理エラーは人間の目視チェックがなければそのまま意思決定に使われてしまいます。お試し導入（PoC）の段階でプロジェクトが頓挫する要因として、もっともらしい誤りに対する現場の不信感が挙げられます。
ベンチマークの目的と評価スコープ
今回の検証では、単にSQLが生成できるかだけでなく、以下の3点を重点的に評価しました。
- Execution Accuracy（実行結果の正確性）: 生成されたSQLを実行した結果が、正解データと完全に一致するか。
- Schema Linking（データベース構造の認識力）: 類似した項目名や表の名前がある中で、適切なものを選択できるか。
- Complexity Handling（複雑性への耐性）: 複数の表を結合する処理が増え、複雑な条件が必要な場面でも論理を保てるか。
検証環境と評価プロトコル：公平な比較のために
比較結果の信頼性を担保するため、検証環境の透明性を確保します。今回は、一般的なEコマースサイトを模したデータベース構造（スキーマ）を使用しました。
使用データセットとスキーマの複雑性
検証には、以下の特徴を持つデータベース環境を構築しました。
- テーブル（表）数: 12（注文、注文詳細、商品、ユーザー、カテゴリ、在庫など）
- レコード（行）数: 各テーブル数万〜数十万件
- 曖昧性: 「作成日」と「更新日」、「定価」と「割引価格」など、文脈によって使い分けが必要な項目を意図的に配置。
比較対象モデル
現在、システム連携（API）経由で利用可能かつプログラミング性能に定評のある以下のモデルを選定しました。
※AIモデルの進化は非常に速いため、本検証では各系列の最新、または実務で推奨される安定版モデルを採用しています。
ChatGPT (OpenAI):
画像やテキストなど複数の情報を処理する性能と、推論速度のバランスが良いモデル。以前のバージョンから大幅にコストパフォーマンスが向上しており、多くの開発現場で標準的に利用されています。Claude (Anthropic):
プログラミングと論理推論において、ChatGPTを凌駕すると評されることもあるモデル。旧バージョンの提供終了に伴い、現在はより推論力が強化された最新のSonnetシリーズなどが推奨されており、本検証でもその高いコード生成能力を評価対象としています。Llama (Meta):
無償で公開されているオープンソースモデルの代表格。特に大規模なモデルは、有料の商用モデルに迫る性能を持ちながら、コストパフォーマンスと自社環境（オンプレミス）での運用の可能性を検証できるため採用しました。最新版では一度に処理できる文章量の拡張や日本語処理能力の向上が見られます。
プロンプト戦略
公平を期すため、各モデルには同一の前提条件（システムプロンプト）を与えました。ここでは、実務で一般的になりつつある「外部データを参照しつつ、いくつかの具体例を提示して指示を出す手法（RAGを用いたFew-shotプロンプティング）」を採用しています。具体的には、ユーザーの質問に関連する過去の正解SQL事例を3つ含めることで、モデルに「社内特有の書き方」を学習させています。
結果分析1：クエリ複雑度別の生成精度比較
100本のテスト問題を「Easy（単一の表・単純条件）」「Medium（複数の表の結合・集計）」「Hard（多重結合・高度な分析関数・複雑な絞り込み）」の3段階に分類し、各モデルの正答率を計測しました。
単純クエリ（SELECT/WHERE）での勝者
Easyカテゴリ（全30問）においては、全モデルが95%以上の正答率を記録しました。「ユーザーID 12345のメールアドレスを教えて」といった単純な指示であれば、どのモデルを選んでも実用レベルに達しています。ここでは利用コストの安いLlamaが有力な選択肢となります。
複雑クエリ（JOIN/GROUP BY/Window関数）での明暗
問題はMedium（40問）とHard（30問）です。ここで明確な差がつきました。
- Claude: Hardカテゴリでも78%の高い正答率を維持。特に、複雑な結合条件や、順位付けなどの高度な分析関数を用いた処理において、意図を正確に汲み取る能力が際立っていました。
- ChatGPT: Hardカテゴリで72%。非常に優秀ですが、時折、集計のまとまり（グループ化の基準）を取り違えるケースが見られました。
- Llama: Hardカテゴリでは45%まで低下。複雑な論理構造になると、途中で文脈を見失い、存在しない項目を参照する傾向が強まりました。
モデルごとの得意・不得意傾向
特筆すべきは、Claudeの「特定のデータベース言語への適応力」です。特定システム特有の日付操作や複雑なデータ型の扱いにおいて、他のモデルよりも正確な構文を生成しました。一方、ChatGPTは、曖昧な指示に対して「一般的な解釈」を適用して強引に答えを出す傾向があり、これが吉と出るか凶と出るかはケースバイケースです。
結果分析2：エラーパターンと「幻覚」の解剖
正答率の数字以上に重要なのが、「どのように間違えたか」という定性的な分析です。ビジネスリスクに直結するエラーパターンを比較します。
存在しないカラム・テーブルの捏造頻度（ハルシネーション）
最も危険なエラーです。データベースの構造情報として与えていない項目を、AIが勝手に作り出してSQLを生成してしまう現象（ハルシネーション）です。
- Llama: データベースの定義情報が長くなると（処理する文字数が増えると）、後半の定義を無視し、一般的な名称（例：
user_statusなど）を捏造するケースが散見されました。 - ChatGPT / Claude: どちらもハルシネーションは極めて稀ですが、ゼロではありません。特に、表同士を繋ぐ鍵となる項目が明示されていない場合、名前が似ているだけの無関係な項目で結合しようとする傾向があります。
意図とは異なる集計ロジックの適用
「実際の利用者数」を求めたいのに「延べ人数」を使ってしまう、あるいは売上集計で「キャンセル注文」を除外し忘れる、といった論理的なミスです。
これに関しては、AIへの指示の出し方（プロンプトエンジニアリング）への依存度が非常に高いことが分かりました。モデルの性能というよりは、「キャンセルは除外して」と明示的に指示するか、あるいはデータ定義書に「売上計算時はステータス=完了のみを対象とする」といったビジネスルールを記述しておくことで、どのモデルでも精度は大幅に向上します。
コスト対効果とレイテンシのトレードオフ
技術的に可能でも、経済的に見合わなければ導入はできません。1回のSQL生成にかかるコストと応答時間（レイテンシ）を試算します。
1クエリあたりの平均トークンコスト試算
実務的なデータベースの定義情報と具体例を含めると、AIに入力する情報量は容易に2,000〜3,000トークン（AIが処理する文字の単位）に達します。
- ChatGPT: 1回あたり約1.5円〜2.5円（※為替やプランによる）。1日1000回利用で月額数万円規模。
- Claude: ChatGPTと同等かやや安価なレンジ。
- Llama (自社運用): 利用料自体はゼロですが、AIを動かすためのサーバー維持費がかかります。利用回数が少ない場合は逆に割高になる可能性があります。
ユーザー体験を左右する生成速度
対話型の分析ツールとして実装する場合、応答時間は重要です。
- ChatGPT: 非常に高速。複雑なSQLでも平均2〜3秒で生成。
- Claude: やや遅れる傾向があり、平均4〜6秒。
「待てる」バッチ処理やレポート生成ならClaudeの精度を優先し、リアルタイムな対話ならChatGPTを選ぶ、という使い分けが現実的です。
結論：ユースケース別推奨モデルとアーキテクチャ
これまでの検証結果を踏まえ、現在の技術水準における最適な選定指針をまとめます。単一の「最強モデル」を探すのではなく、用途に応じたシステム構成（アーキテクチャ）を設計することが重要です。
社内BIツールへの組み込みなら「Human-in-the-loop」
非エンジニアが使うデータ可視化ツールなどに組み込む場合、Claudeを推奨します。多少の待ち時間があっても、複雑な集計ロジックを正確に再現する能力が不可欠だからです。ただし、AIが生成したSQLを即実行するのではなく、一度人間に「この条件で抽出しますか？」と自然言語で確認させるプロセス（Human-in-the-loop）を挟む画面設計が必須です。
アドホック分析支援なら「ChatGPT」
データアナリストやエンジニアが、その場限りの単発的なデータ分析（アドホック分析）の補助として使うならChatGPTが最適です。高速なレスポンスで試行錯誤のサイクルを回せる利点が、微細なエラーのリスクを上回ります。専門知識があれば、生成されたSQLの怪しい箇所を即座に見抜けるため、ハルシネーションのリスクも許容範囲内です。
精度向上のためのRAG/ファインチューニングの必要性
どのモデルを選ぶにせよ、事前知識を与えない状態（Zero-shot）で実務レベルの精度を出すのは困難です。以下のエンジニアリング投資が費用対効果を左右します。
- メタデータの整備: 表の定義だけでなく、項目の意味、よく使われる結合パターン、ビジネスルールを記述したドキュメントを外部データとして参照（RAG）させる。
- 具体例の蓄積: 「正しいSQL」と「ユーザーの質問」のペアを蓄積し、動的に指示文に挿入する仕組みを作る。
AIにSQLを書かせることは、もはや夢物語ではありません。しかし、それは適切な設計と運用によって初めて機能する「技術」です。この現実を直視した上で、自社のデータ基盤に最適なモデルを組み込んでください。
コメント