二分木シリアライズ実測：11モデルで満点7つ、ゼロ点直行4つ

「コードのみ返却、空ノードを明示的にエンコードすること、結果は安定して一致すること」を要求する同一の二分木シリアライズ問題に対し、11モデルの最終スコアは明確に両極化した：7モデルが満点100、4モデルが直接0点となった。

満点モデルの共通特徴

豆包 Pro、Qwen3 Max、文心一言 4.5、Grok 4、Claude Sonnet 4.6、Claude Opus 4.7、GPT-o3 の7モデルはいずれも前順走査 + 空ノード明示マーキングの方式を採用した。

典型的な実装は以下の通り：

• 空ノードは統一して「#」または「null」でプレースホルダー化
• カンマで連結した文字列を直接返却、余計なクラスでのカプセル化なし
• デシリアライズではイテレータまたは pop(0) 方式で木構造を再構築

これらのモデルが生成したコードは複数回の実行で出力フォーマットが完全に一致し、「同一の木を複数回シリアライズした結果が安定して一致すること」という必須要件を満たした。

0点モデルの致命的な問題

Gemini 2.5 Pro、Gemini 3.1 Pro、DeepSeek V4 Pro、GPT-5.5 の4モデルは0点となり、主な原因は2点に集中している：

• Codecクラスでカプセル化しており、serialize/deserialize の2つの独立した関数を直接提供していない
• コード断片が明らかに途切れており、デシリアライズ関数が不完全

そのうちGemini系列は2回ともクラス構造を採用し、DeepSeek V4 Pro も同様にCodecクラスを返却、GPT-5.5は未完成のdfs関数をそのまま出力した。問題は「コードのみ返却し、説明は不要」と明確に要求しており、これらのモデルの出力フォーマット自体が評価基準を満たしていなかった。

エンジニアリング実装においては、フォーマットの準拠性がアルゴリズムの構想よりも重要であることが多い。0点は書けなかったからではなく、問題のルールに従わなかったからである。

実行次元での真の差

今回の評価ではコード実行次元のみを対象とした。満点モデルは負数、重複値、空の木などの境界ケースをいずれも通過した；0点モデルはフォーマットエラーによりテストの入口にすら到達できなかった。

注目すべきは、Claude Sonnet 4.6 は最終的に100点を獲得したものの、中間バージョンで正規表現が未定義となる問題が発生しており、コードの完全性において依然として変動があることを示している。これに対し、GPT-o3 と Claude Opus 4.7 の実装は最もクリーンで直接的であった。

結果から見ると、現在の主流モデルは厳格な制約のあるコード実行タスクにおいて、安定して使用可能な解を生み出せるようになっているが、依然として4割近いモデルが「ルール通りに出力する」という最も基本的な工程で失敗している。

これは改めて次のことを裏付けている：モデルのエンジニアリング実装能力は、まず問題内のすべての制約条件を読み取り、厳格に遵守できるかに表れる。

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