11モデルが同じSQL定着率問題に挑戦：9社が0点、DeepSeekとGrokのみ66.7点

YZ Index v6のコード実行テストにおいて、この「SQL：月次定着率Cohort」という問題は、11モデルの真の実力差をはっきりと露呈させた。最終結果は残酷で、9モデルが0点となり、DeepSeek V4 ProとGrok 4だけが66.7点を獲得した。

主要な失敗パターン：CTEを書いている途中で中断

豆包 Pro、Qwen3 Max、Claude Sonnet 4.6、文心一言 4.5、Gemini 2.5 Pro、Gemini 3.1 Pro、Claude Opus 4.7、GPT-5.5、GPT-o3 の9モデルの回答は、ほぼすべて同じ箇所で詰まっている——WITH文を書いている途中で突然途切れたり、SELECTで最初の2列しか書けなかったりしている。典型例として、豆包 Pro の month_offset_map は3行だけUNIONして終わり、Qwen3 Max の active_months の GROUP BY は e.u まで書いて止まっている。

こうした「半製品」は実際のエンジニアリングではエラーになる。これらは論理的な方向性が間違っているのではなく、完全で実行可能なSQLを組み立てることすらできていない。

日付計算とcohort分離における体系的な混乱

書き終えられたモデルでも、2つの重要なポイントで失敗しているケースが多い。1つはcohort_monthの精確なフィルタリング、もう1つはmonth_offsetの正しい生成だ。

Claude シリーズと GPT シリーズは EXTRACT(YEAR FROM ...) の減算を繰り返し使用しているが、年をまたぐシナリオを適切に処理できていない。Gemini 2.5 Pro は DATE_PART でオフセットを計算しているが、最終的に active_month を 0/1/2 の3つの固定オフセットに正しくマッピングできていない。文心一言は DATEDIFF(MONTH...) のような近似的な書き方を直接使っており、エンジニアリングの厳密さが明らかに欠けている。

比較すると、DeepSeek V4 Pro と Grok 4 のソリューションには細かな問題はあるものの、少なくとも「まず2025-01のcohortを見つけ、次に3つのオフセットをCROSS JOINし、最後にLEFT JOINで集計する」という正しい骨組みを完成させている。これが両者が66.7点を獲得できた根本的な理由である。

0点となったのは問題が難しすぎたからではなく、モデルが「考えを完全に実行可能なSQLに翻訳する」という段階で集団的に機能不全に陥ったからだ。

なぜ2社しか合格できなかったのか？

DeepSeek V4 Pro の書き方は、cohortのフィルタリングとオフセット生成を完全に分離し、CROSS JOIN で 0/1/2 の3行を強制的に生成し、LEFT JOIN で retained_users を集計しており、最もクリーンな思考だ。Grok 4 は TIMESTAMPDIFF の書き方がやや冗長ではあるが、同様に cohort_users + user_activity のダブルCTE構造を完成させている。

その他のモデルは、DATE_TRUNC に過度に依存しながらも HAVING フィルタを適切に処理できなかったり、オフセット計算式に注力するあまり「3行の固定オフセットを出力しなければならない」という最も基本的な要件を見落としていたりする。

エンジニアリング実装への直接的な示唆

実際のデータウェアハウスのシナリオにおいて、定着率分析は最も一般的な分析ニーズの1つだ。この問題が露呈させた問題は、モデルがSQLを理解していないということではなく、「出力行数の精確な制御 + 複数ステップのCTE + 日付オフセット」というニーズが発生したとき、現状の大半のモデルはまだ「SQLっぽく見えるものは書けるが、実行できない」段階にあるということだ。

AI支援によるSQL作成に依存するチームにとって、これは人手によるレビューを必ず残す必要があることを意味する。特にcohort分析、定着率、ファネルのような複数ステップの集計シナリオでは。

YZ Indexのコード実行という評価軸が本質的に測定しているのは、モデルが「SQLを理解しているかどうか」ではなく、「一度で正しく実行可能なSQLを提出できるかどうか」だ。今回のテストが示した答えは、現時点でそれを実現できているのはごく一部のみ、ということだ。

データソース：YZ Index | Run #122 | 元データを確認