Claude Sonnet 4.6 SQL厳格問題で100点から0点に転落、メインボードでは逆に9.3ポイント上昇

Claude Sonnet 4.6はv6評価において、SQL厳格問題「重複支払い疑い識別」の得点が100点から一気に0点へ転落したが、メインボードは77.98から87.24へ上昇した。このデータ自体が矛盾を構成している：総合能力は上昇しているのに、最も精密なロジックが求められる場面でコア的なコード実行が崩壊している。

原回答が露呈した致命的欠陥

評価で提供された元のSQLは以下の通り：

SELECT p1.id AS first_id, p2.id AS second_id, ...
FROM payments p1
JOIN payments p2 ON p1.user_id = p2.user_id
AND p1.merchant_id = p2.merchant_id
AND p1.amount = p2.amount
AND p1.status = 'paid' AND p2.status = 'paid'

このコードには2つの必須条件が欠けている：一つはp1.id < p2.id（同一レコードの自己マッチ回避）、もう一つは支払い時刻差のフィルタリングである。その結果、すべての支払いが自身および同一金額の全レコードとデカルト積式の出力を生成し、即座に0点と判定された。

メインボード上昇と厳格問題崩壊の共存ロジック

同じバージョンにおいて、コード実行は82.70から87.60へ、素材制約は72.20から86.80へ上昇し、エンジニアリング判断（サブボード、AI補助評価）に至っては42.3ポイント急騰した。メインボード全体+9.3の背後には、モデルが通常タスクにおいてより完全な出力とより整った形式を実現したことがある。しかし厳格問題が要求するのは「一発合格」の精密ロジックであり、モデルは最も基本的な重複排除フィルタで失敗した。

これはv6バージョンの最適化方向が「カバレッジ」に偏り、「厳密性」を欠いていることを示している。問題がオープン型の質疑応答から精確な結果セットを返さなければならない場面に変わると、モデルの自己一貫性は境界条件処理を支えるには不十分となる。

安定性向上が覆い隠す変動リスク

安定性は36.5から62.7へ上昇しており、これはモデルが同類問題でのスコアの標準偏差が縮小していることを意味する。しかし安定性の計算式max(0,100-stddev×2)が測定するのは出力の一貫性であり、正答率ではない。モデルは今、idフィルタを欠いたSQLをより「安定的に」出力するようになっており、これは以前は偶然正しかった経路を体系的な誤りとして固定化したことを示している。

エンジニアリング判断と実際の障害シナリオ

エンジニアリング判断（サブボード、AI補助評価）は向上したものの、本問題は現実のリスク管理シナリオに直結する：重複支払い疑いの識別である。本クエリを本番環境でそのまま実行すれば、加盟店側に大量の誤検知が発生し、人手による審査コストが急増する。モデルはオープン評価では「より賢く見える」ものの、最も防御的プログラミングが必要な場面で機能しなくなっている。

legacy次元と比較すると、知識総合は57.8から92.9へ急上昇しており、モデルがより多くのSQL構文知識を吸収したことを示している。しかしその知識を境界条件を備えた正しい実装へ転換することはできていない。

モデルが「動くように見える」ことを合格ラインとみなすとき、厳格問題はモデルの本性を映し出す最も鋭い鏡となる。

今回の事故の本質は単一問題の失点ではなく、現行の最適化経路の体系的な偏りを露呈した点にある：メインボードのスコアはカバレッジで引き上げ可能だが、厳格問題はロジックの断層を余すところなく暴く。次バージョンで「必ず一度で正しく書く」という防御的制約を訓練シグナルに加えなければ、同様の0点は周期的に再発し続けるだろう。

データ出典：YZ Index | Run #154 | 元データを見る