11個のAIが同一のSQL重複決済問題を解く：満点はわずか4個、7個は0点

同一のSQL問題で、11個のモデルの最終得点は二極化を示した：4個が100点、7個が0点。中核的な差異は、自己結合における重複排除ロジック、時間差計算関数の選択、およびstatus条件の配置位置に集中している。

満点回答の共通特徴

豆包Pro、Grok 4、Gemini 2.5 Pro、Gemini 3.1 Proの4つが正しく3点の要件を満たした：p1.id < p2.id でミラー重複を回避、status条件はJOIN ONまたはWHEREのどちらに置いてもよい、時間差計算が正確かつ方向も正しい。

豆包Proは TIMESTAMPDIFF(SECOND, p1.created_at, p2.created_at) <= 120 を使用し、MySQL方言に対応。Grok 4も同様にTIMESTAMPDIFFを採用し、すべての条件をON句に置き構造が明快。2つのGeminiはUNIX_TIMESTAMPで差分を取り、同様に120秒制限を満たしfirst_idがsecond_idより先になることを保証している。

0点回答の典型的なミス

7つの0点モデルは主に3種類のミスを犯した：

• p1.id < p2.id が欠落し、同一レコードペアが2回出力される（Qwen3 Max、Claude Sonnet 4.6、DeepSeek V4 Pro、Claude Opus 4.7、GPT-o3、GPT-5.5）；
• 時間関数の選択が誤っているか、方向が逆（文心一言4.5、DeepSeek V4 ProはEXTRACT(EPOCH FROM ...)を使用したがタイムゾーン処理がなく、一部の回答ではcreated_atの比較方向が混乱している）；
• クエリが不完全、またはstatus条件が欠落（文心一言4.5は直接打ち切られ、DeepSeekはstatusをWHEREに置いたがcreated_atの方向制限が欠落）。

これらのミスは実際の決済システムにおいて、重複アラートや見逃しを直接引き起こすため、エンジニアリングレベルの致命的問題と言える。

関数選択の背後にある方言の差異

満点モデルは明らかにSQL方言の適応をよく理解している。TIMESTAMPDIFFはMySQLの標準的な書き方で、UNIX_TIMESTAMPもMySQL環境では一般的だ。一方EXTRACT(EPOCH FROM ...)はPostgreSQLの構文で、MySQLでは直接エラーになる。7つの0点モデルのうち少なくとも4社が方言をまたいだ関数を混用しており、本番環境のSQL方言に対するモデルの感度が不足していることを示している。

エンジニアリング判断の真の差

今回のテストは、単に「SQLが書ける」ことと「本番運用可能なSQLが書ける」ことが別物であることを改めて証明した。正解は、ミラー除去、正確な時間窓、状態フィルタリングという3重の制約を同時に満たさなければならない。多くのモデルはそのうち1〜2項目で失敗しており、複数条件の自己結合処理における体系的な弱点を反映している。

4対7という得点の大差は、現在の大規模モデルがエンジニアリングSQL生成において、依然として「書ける」段階にあり「正しく書ける」段階には至っていないことを示している。

今後半年以内に、モデルが同様の多制約自己結合タスクでこのような高い失敗率を維持し続けるならば、決済リスク管理や注文の重複排除といった中核業務シーンは引き続き人手による審査に依存することになるだろう。

データ出典：YZ Index | Run #154 | 元データを表示