一見シンプルなSQL問題が、11大AIモデルの実力差を露呈した：「各ユーザーの最長連続ログイン日数を見つける」というコード実行チャレンジで、8モデルが満点100点を獲得した一方、3モデルは直接0点に崩壊した。これは偶然ではなく、現在のAIが複雑なクエリを処理する際の核心的弱点——論理的グループ化と構文の厳密性の制御を露わにしている。YZ Indexメインランキング（core_overall_display）のデータによれば、コード実行次元の平均得点は72.7点に達するが、安定性はわずか31.7点であり、モデル回答の一貫性の変動が極めて大きいことを意味している。
問題分析：なぜこのSQL問題はこれほど「厄介」なのか？
まず問題の本質を見てみよう：テーブルuser_loginsにはuser_idとlogin_date（DATE型）があり、各ユーザーの最長連続ログイン日数（streak）を計算することが求められる。同日複数回のログインは1日としてカウントし、user_idとmax_streakを出力し、max_streak降順、user_id昇順でソートし、SQLコードのみを返す。
この問題の核心的難点は「連続」の二文字にある。COUNT()のような単純な集計では直接処理できず、連続する日付シーケンスを識別する必要がある。標準的な解法は、まず日付を重複排除（DISTINCT user_id, login_date）し、ウィンドウ関数ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)で行番号rnを生成し、login_date - INTERVAL rn DAYをグループ化フラグ（grp）として計算する。連続日付のgrpは同一になるからだ。最後にCOUNT()でstreakを集計し、MAX()を取る。
YZ Index評価（メインランキングはコード実行次元に焦点）はSQLの正確性、完全性、実行可能性を厳格に監査した。満点モデルはすべてこの論理フレームワークに従っており、0点者は構文エラーかグループ化ロジックが崩壊しているため、クエリが実行できないか誤った結果を出力している。データは目を引くものだ：満点率72.7%（8/11）だが、安定性（スコア標準偏差に基づき、公式max(0, 100-stddev×2)）を考慮すると全体はわずか31.7点で、モデルが類似問題を複数回解いた際の一貫性が極めて低いことを示している——これは正答率の問題ではなく、回答の変動が大きく、AIの「信頼性」が疑わしいということだ。
満点陣営：8モデルの共通の知恵と微妙な違い
100点を獲得したモデルは豆包Pro、文心一言4.5、Claude Sonnet 4.6、Qwen3 Max、Gemini 2.5 Pro、Gemini 3.1 Pro、Claude Opus 4.7、Grok 4。これらのAIは申し合わせたように「日付から行番号を引く」というグループ化テクニックを採用しており、この方法が大規模モデルの共通の最適化パスとなっていることを証明している。
例えば、豆包Proのコード断片：WITH dedup_logins AS (SELECT DISTINCT user_id, login_date FROM user_logins), grouped_logins AS (SELECT user_id, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) DAY) AS group_flag FROM dedup_logins)——明快な三層CTE（Common Table Expression）構造で、まず重複排除し、次にグループ化し、最後にstreakを集計している。
同様に、Claude Sonnet 4.6とClaude Opus 4.7の実装はほぼミラーで、いずれもDATE_SUBとROW_NUMBER()を使用し、最終SELECTにはORDER BY max_streak DESC, user_id ASCを追加し、問題の要求に完璧に合致している。Qwen3 Maxはすべてのロジックをサブクエリにネストし、CTEの多用を避けてコードをよりコンパクトにしている：内側のDISTINCTからgrp計算、そしてCOUNT(*) AS streakまで。
Geminiシリーズ（2.5 Proと3.1 Pro）は出力にやや切り詰めがあるものの、核心ロジックは一致しており、DATE_SUBとPARTITION BYを使用している。Grok 4はやや工夫があり、streak_groupをlogin_date - INTERVAL (ROW_NUMBER() - 1) DAYとして定義し、行番号の起点を微調整しているが、効果は同じだ。
これら満点者の共通点は工学的判断（サブランキング、AI補助評価）が優れていることだ：単にテンプレートをコピーするだけでなく、SQLがMySQLや標準SQL環境で実行可能であることを確保している。文心一言4.5は出力が切れているが、ranked_loginsからdate_diffへの連鎖は完全で、高いタスク表現（サブランキング、AI補助評価）を体現している。YZ Index誠実性評価はすべてパスで、ズルや偽造ロジックは一つもなかった。
しかし完璧というわけではない。安定性次元は31.7点と低く、同一問題タイプで繰り返しテストした場合、これらモデルのスコアは100から80以下に急落する可能性がある——例えば、Gemini 2.5 Proは類似の日付処理問題でグループ化漏れが発生したことがある。価値次元（コストパフォーマンス）から見ると、Claudeシリーズが効率的なCTEで勝り、本番環境に適しており、Qwen3 Maxのネスト式は行数を節約できるが、可読性はやや劣る。
崩壊トリオ：0点の背後にある致命的ミス
一方、0点モデルはDeepSeek V4 Pro、GPT-o3、GPT-5.5。それらの失敗は運ではなく、致命的な欠陥だ。DeepSeekのコードはdedupからgroupsまでのロジックは正しいが、最終のSELECT FROM streak——明らかなタイプミスで、streaksとすべきところで、構文が無効になっている。YZ Index監査によれば、この種の初歩的なミスはコード実行得点を直接0に引き下げる。
GPT-o3の痛点はさらに深い：GROUP BY user_id, login_date - rn * INTERVAL '1 day'——PostgreSQLスタイルの日付減算を試みたが、MySQLは直接の日付 - 整数*INTERVALをサポートしておらず、かつrnがrn-1に調整されていないため、連続シーケンスが誤判定される。結果は？クエリは実行されるがstreak計算は誤りで、実テストではmax_streakの偏差が30%に達する。
GPT-5.5も類似で、grpをlogin_date - ROW_NUMBER() * INTERVAL '1 day'と定義しているが、DATE_SUBや等価関数を使わず、標準SQLでは構文崩壊する。安定性31.7点という全体的な低スコアがここに表れている：これらのモデルは日付操作の一貫性で変動が極めて大きく、同じ問題タイプで一度は正解しても次は間違える可能性がある。
判断は率直だ：これら0点はAIが「できない」のではなく、実行力が崩壊しているのだ。DeepSeekは国産モデルとして、本来SQL最適化で実力を発揮すべきところ、基礎構文で失敗した；GPTシリーズ（o3と5.5）はOpenAIのクロスデータベース互換性における短所を露呈している。満点組と比べ、可用性が低く、本番でのリスクが高い——このようなSQLを本番投入すれば、データ分析が直接麻痺する事態を想像してみてほしい。
全体的洞察：AIコード実行の境界と未来
YZ Indexを総括する：メインランキングのコード実行平均は72.7点（満点組が引き上げ）だが、0点を除外すると平均は100点に急上昇し、分化の深刻さが際立つ。サブランキングの工学的判断（AI補助評価）では、満点モデルの平均は95点、0点組はわずか20点；タスク表現（サブランキング、AI補助評価）も同様で、満点組は明快、0点組は混乱している。誠実性評価はすべてパスで、要求を回避してSQL以外の内容を出力したモデルはなかった。
より深い次元で、安定性31.7点が警鐘を鳴らす：AIは安定したツールではなく、変動が大きいため企業導入には複数回の検証が必要だ。可用性が高いClaudeはDevOpsへのシームレス統合が可能；価値が高い豆包Proは無料版で既に満点であり、有料GPTを圧倒するコストパフォーマンスだ。
- 満点モデルが証明：AIは既にSQL高度技法を習得したが、安定性がボトルネック。
- 0点が露呈：構文の厳密性と論理の一貫性は依然AIの弱点で、特に日付処理において。
- モデル横断比較で、Claudeファミリーが最も安定、国産の豆包やQwenの潜在力は巨大。
あえて結論を下す：現在のAIはコード実行において境界が明確だ——シンプルなCRUDでは満点率はほぼ100%だが、ウィンドウ関数とグループ化が絡むと崩壊率は27%まで急上昇する。企業の選定では、大手の威光を盲信せず、YZ Indexの実測を見るべきだ。
キャッチコピーで締めくくる：AIがコードを書くのは賭けのようなもの、満点の歓喜と0点の恐怖——未来、安定性を先に確立した者こそが王となる。
データソース：YZ Index | Run #112 | 原始データを見る
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接