11個のAIが同じSQL問題に回答：3つが直接0点、ClaudeとGPTはなぜ崩壊したのか

11個の主流AIモデルが同一のSQL集約クエリに対面した際、明確な実行格差が現れた。8つのモデルが実行可能なコードを出力して60点を獲得したのに対し、Claude Sonnet 4.6、Claude Opus 4.7、GPT-o3の3モデルは直接0点となり、問題は日付区間構文とMySQL方言の互換性に集中していた。

正解の共通特徴

60点を獲得したモデルは、概ね2種類の実行可能な書き方を採用していた。1つ目はMySQLネイティブのDATE_SUB関数で、例えば豆包Pro、文心一言4.5、Grok 4はいずれも以下を使用した：

created_at >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)

この書き方はMySQL 5.7/8.0環境で直接実行可能で、追加の変換を必要としない。2つ目は一部のモデルが採用したCURRENT_DATE - INTERVAL '90' DAY形式だが、引用符を除去するか方言を調整しないと通過できない。

0点モデルの致命的なミス

3つの0点モデルのSQLには、日付処理に系統的な偏差が見られた。Claude Sonnet 4.6とClaude Opus 4.7はいずれも以下のように記述した：

created_at >= CURRENT_DATE - INTERVAL '90 days'

シングルクォートで囲まれた'90 days'はMySQLでは不正な構文であり、実行時に直接エラーとなる。GPT-o3もCURRENT_DATE - INTERVAL '90 days'を使用しており、同様に標準的なMySQL環境では実行できない。

これらのモデルは、問題に暗示されたMySQLコンテキスト（テーブル構造とフィールド命名スタイルがMySQLの例によく見られる）を無視し、PostgreSQLやOracleの日付記述をそのまま持ち込んだため、実行段階で完全に失敗した。

実行次元における真の差異

コード実行の観点から見ると、60点モデルは構文が正しいだけでなく、すべての制約条件も満たしていた：amount IS NOT NULL、status='paid'のフィルタリング、total_amount降順+user_id昇順、LIMIT 10。0点モデルは論理的な考え方が類似していても、実行できないためすべての点数を失った。

注目すべきは、Gemini 2.5 ProとGemini 3.1 Proは同じ得点だが、Gemini 3.1 ProはCURDATE()を使用しており、MySQLとの互換性が高く、実際のデプロイ時により堅牢である点だ。

モデル能力の境界判断

Claudeシリーズは自然言語理解では通常リードしているが、正確な方言マッチングが必要なエンジニアリングコードタスクでは明らかな弱点が現れた。最新版のGPT-o3も、このSQL境界問題で失敗しており、コード実行訓練に方言の盲点が残っていることを示している。

対照的に、Qwen3 Max、DeepSeek V4 Pro、GPT-5.5などのモデルはSQL方言の適応においてより実用的で、出力結果は直接本番環境に投入できる。

コード実行の次元では、構文の互換性が「正しく見えること」よりも重要である。

今回のテストは、AIモデルのエンジニアリング価値が最終的にターゲットデータベース上で実際に動作できるかによって決まることを再び証明した。日付関数のわずかな差異が、0点と60点の差を直接決定している。

今後、モデルがエンジニアリングシーンで定着するためには、自然言語の記述だけに依存するのではなく、主流データベース方言の境界ケースをコアトレーニングに組み込まなければならない。

データソース：YZ Index | Run #122 | 元データを見る