なぜGemini-SQL2でも実務で勝てないのか、Claude Code開発者が教える軽量化と検証の重要性

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

結局、モデルが賢くなれば解決すると思っていた。

自然言語からSQLを書く「text-to-SQL」の領域。

モデルが進化すれば精度100%になるという期待があった。

しかし、今週出た複数の情報を統合すると、その常識は崩れた。

モデルの賢さは、もはや一番効かないレバーになりつつある。

重要なのは「賢さ」を外から借りるか、中で「最適化」するかだ。

自分の足元の「方言」を疑うことが、実務の分かれ目になる。

数字と事実で、この現実を直視する。

順位表の数字と「あなたのDB」は別の世界の話。

派手な数字から見ていく。

Gemini-SQL2が、text-to-SQLの代表的なベンチマークであるBIRDで、実行精度80.04%を記録した。

比較対象のGPT-5.5-xhighが約72.8%。

Claude Opus 4.6が約70.9%だ。

7〜9ポイント差をつけて、Geminiが頭ひとつ抜けている。

ベースはGemini 3.1 Proだ。

この実行精度は、生成したSQLを実際に動かして、結果が正解と一致するかを測る。

構文が合っているだけでは加点されない、厳しい指標だ。

80%という数字だけを見れば、SQL生成は解決したように見える。

しかし、この数字には落とし穴がある。

翌日に発表された調査データが、その冷や水を浴びせた。

既存のベンチマークのほとんどはSQLiteに偏っている。

モデルが「SQLの方言」をまたいで通用するかは、今まで測られていなかった。

新しい検証データでは、同じ質問、同じスキーマ、同じデータ内容のまま、SQL方言だけを16種類に展開した。

自然言語の質問1,534問を、方言ごとの正解SQLへ翻訳し、合計24,544クエリでテストした。

結果は明白だ。

「今のモデルは方言に対して汎用的ではない」。

特定のデータベースで成功しても、その性能は他の方言には転移しない。

SQLiteで満点に近いモデルも、PostgresやBigQueryに変えた瞬間に、もっともらしいが動かないクエリを吐き出す。

本番で使っているDBと、ベンチマークの世界は地続きではない。

一方で、モデルを「外から借りる」動きも加速している。

ある巨大テック企業は、Geminiのモデルへフルアクセスする権利を確保した。

目的は、Geminiをそのまま使うことではない。

「蒸留」だ。

Geminiが生成する高品質な回答と、その「思考プロセス」を教師データにする。

それを自社の軽量なモデルに学習させ、オンデバイスAIとして動かす。

強力なモデルの「脳」をコピーして、小さなモデルに移植する戦略だ。

これにより、クラウドに頼らず、デバイス内で高速に、かつ安価に「賢い回答」を引き出せるようになる。

さらに、Google Researchが発表したTurboQuantという技術が、この軽量化に拍車をかける。

AIが会話の文脈を覚えるためのメモリ、KVキャッシュを圧縮する。

メモリ消費量を6分の1に抑え、読み取り速度を8倍速くする。

従来の圧縮技術（量子化）には、圧縮設定を保存するための余分なデータが必要で、圧縮効果を相殺していた。

TurboQuantはこの「設定メモ」を極限まで削るアルゴリズムを採用している。

3ビットまで圧縮しても、精度を落とさずに運用できる。

「重くて高い」AIが、「軽くて安い」インフラへと変貌する。

しんたろー：
Gemini-SQL2の80%超え、一瞬驚いたがSQLite特化なら話は別だ。
Googleが手法を非公開にしているのも、裏で検証ループを回しているからだろう。
賢いモデルを選ぶより、自分のDB環境でいかに「実行検証」を自動化するかが、開発者の腕の見せ所だ。

Claude Codeで毎日コードを書いて分かった「検証」の真実。

僕は毎日、Claude Codeを使ってThreadPostの開発を進めている。

AIエージェントにSQLを書かせる場面は多い。

そこで痛感するのは、モデルのカタログスペックよりも、「自分のスタックとの相性」がいかに重要かということだ。

Claude Codeはローカル環境のファイルを読み、スキーマを理解しようとする。

しかし、僕が使っているDB固有の関数や、特殊なデータ型の扱いについては、時々「嘘」をつく。

それはClaudeがバカだからではない。

学習データに含まれる「一般的なSQL」の分布に、どうしても引きずられるからだ。

今回のニュースで示された「方言への不適合」は、実務開発者にとって最大の急所だ。

Postgres特有の書き方、Snowflake独自の構文。

これらを100%完璧に網羅しているモデルは、現時点で存在しない。

Gemini-SQL2がSQLiteで80%出したとしても、僕のPostgres環境で同じパフォーマンスが出る保証はない。

むしろ、性能は落ちる。

では、どうすれば勝てるのか。

答えは、モデルの外部に「実行検証ループ（Harness）」を構築することだ。

GoogleがGemini-SQL2で高い数字を出せた背景には、おそらく「生成したクエリが正しいか、実際に動かして確認し、エラーなら修正する」という仕組みがある。

これは僕がClaude Codeを使っていて恩恵を感じる部分でもある。

AIが書いたコードを、即座にターミナルで実行し、エラーが出たらそのログをAIにフィードバックする。

この「自己修正ループ」こそが、実務での精度を10%から90%へと引き上げる手段だ。

また、Appleが採用した「蒸留」というアプローチも、個人開発者やSaaS開発者にとって無視できない。

巨大なモデルをAPIで叩き続けるのは、コスト面でもレイテンシ面でも限界がある。

GeminiやGPT-4oのような「先生」に、自分たちの特定のタスクを解かせる。

その回答パターンをLlama 3やGemmaのような軽量モデルに学習させる。

こうして出来上がった「特化型モデル」は、汎用モデルよりも速く、安く、僕らの環境に最適化された動きをする。

TurboQuantのような軽量化技術も、この流れを加速させる。

メモリ要件が6分の1になれば、今まで高価なGPUサーバーが必要だったオンプレミス環境でも、高度なAIが動くようになる。

「社内データを外に出したくない」というクライアントの要望に応えつつ、高速なレスポンスを実現できる。

僕らが今投資すべきは、最新モデルのAPIを叩くコードを書くことではない。

「いかにモデルを自分たちの環境に最適化し、検証し、軽量化して届けるか」という実行基盤の構築だ。

しんたろー：
Claude CodeでSQL生成をミスった時、エラーログをそのままClaudeに投げ返すと、次で正解を出す。
この「泥臭いループ」をシステムに組み込めるかどうかが、プロダクトの質を分ける。
AI開発の主戦場は「プロンプトエンジニアリング」から「パイプラインエンジニアリング」に移った。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

で、僕らの開発にどう影響するの？

この「モデルの巨大化から、推論の最適化へ」というシフト。

僕ら開発者が明日から意識すべきアクションは、大きく分けて4つある。

これをやるかやらないかで、1年後の開発効率とコストに差が出る。

第一に、「独自の評価セット」を持つことだ。

ベンチマークの数字を追いかけるのはやめる。

自分たちが使っているPostgresやBigQueryのスキーマから、50問程度の「絶対に正解してほしい質問とSQLのペア」を自作する。

新しいモデルが出た時、APIを差し替える前に、まずその50問を解かせてみる。

そこで出る数字こそが、あなたにとっての「真の性能」だ。

第二に、「実行検証ハネス（Harness）」の実装だ。

AIにSQLを生成させたら、そのままユーザーに返してはいけない。

一度、サンドボックス環境のDBで実行し、エラーが出ないか、結果の型が期待通りかを確認する。

エラーが出た場合は、その内容を再度モデルに送り、自動で修正させるルーチンを組む。

この「検証ループ」を組み込むだけで、実務上の精度は飛躍的に向上する。

第三に、「蒸留」によるコストダウンの検討だ。

特定の定型タスクであれば、GPT-4oを使う必要はない。

GPT-4oに1,000件の高品質なサンプルを作らせ、それを軽量なオープンソースモデルに学習させる。

これでAPIコストを10分の1以下に抑えつつ、同等の精度を確保できる可能性がある。

特に、頻繁に呼び出されるSQL生成などの機能には、このアプローチが有効だ。

第四に、「オンプレミス・エッジ化」への備えだ。

TurboQuantのような技術により、AIはますます「軽く」なる。

「AIはクラウドで動かすもの」という固定観念を捨てる。

ローカルのMacや、社内の安価なサーバーでAIを動かす構成は、現実的な選択肢だ。

メモリ効率化の知識を持っておくことは、将来的にインフラコストを最適化する武器になる。

モデルのカタログスペックに一喜一憂するのは卒業だ。

「賢さ」はコモディティ化し、誰でも手に入るようになった。

差がつくのは、その賢さをいかに「自分のドメイン」に引き寄せ、「検証」し、「軽量化」して実装できるかだ。

しんたろー：
TurboQuantでメモリ6分の1は、メモリ市場へのインパクトも大きい。
高いGPUが買えなくても、工夫次第で勝てる余地が広がったのは、1人SaaS開発者には朗報だ。
効率化が進むと、もっと多くの場所でAIが使われるようになる。

FAQ

Q1: BIRDベンチマークで高スコアのモデルを使っているのに、なぜ本番のPostgresで失敗するのか？

A1: BIRD等の主要ベンチマークはSQLiteを前提としており、PostgresやBigQuery特有のデータ型、関数、構文の差異が考慮されていないためです。モデルは学習データ内のSQLiteの分布に強く引きずられます。解決策は、モデルの差し替えではなく、自社DBの方言に特化したFew-shotプロンプトの作成や、生成されたSQLを一度実行してエラーをフィードバックする「実行検証ループ（Harness）」を実装することです。

Q2: TurboQuantを使うと、モデルの精度は落ちないのか？

A2: TurboQuantは、従来の量子化で問題となっていた「量子化定数（設定値）」のオーバーヘッドを削減するアルゴリズムを採用しています。これにより、3ビット程度の高圧縮率でも精度を維持したままKVキャッシュを削減可能です。用途に応じて適切な量子化レベルの検証は必要です。特にRAGや長文コンテキストを扱う場合、メモリ不足による性能低下を防ぐための武器になります。

Q3: Appleのように「蒸留」でモデルを作るのは個人開発者にも可能か？

A3: 理論上は可能です。GeminiやGPT-4oのような高性能モデルに複雑なタスクを解かせ、その「思考プロセス（Chain of Thought）」と「出力結果」をペアにしてデータセット化し、Llama 3やGemmaのような軽量モデルをファインチューニング（蒸留）します。これにより、APIコストを抑えつつ、特定のタスクに特化した高速なオンデバイスAIを構築できます。