11モデルによる括弧マッチング同一問題テスト：7つが満点、4つが0点

主流11モデルが同じ括弧マッチングデバッグ問題に挑んだ結果、最終的に明確な二極化が見られた：7モデルが100点、4モデルが0点である。核心的な発見は、元のコードで本当に致命的なバグは、関数末尾の裸の「return」がNoneを返してしまい、明示的なTrueやlen(stack)==0を返さないことにあった。

元コードの真の問題点

問題で提供されたコードは、マッチング成功後に3つのif-continue構造を使い、最後に直接returnしていた。この書き方ではスタックが空のときNoneが返される。PythonではNoneは真偽判定でFalseとなるため、呼び出し側は期待外の結果を受け取ることになる。豆包 Pro、Qwen3 Max、文心一言4.5、Grok 4、DeepSeek V4 Pro、Claude Opus 4.7、GPT-5.5はいずれもこの問題を認識し、統一してreturn len(stack)==0に書き換えた。

これに対し、Gemini 2.5 Pro、Claude Sonnet 4.6、Gemini 3.1 Pro、GPT-o3の4モデルは、出力中にこの戻り値の修正を反映できなかったか、有効なコードを完成させられず、0点となった。

満点モデルの共通アプローチ

満点を獲得した7モデルはいずれも辞書マッピング方式でマッチングロジックを再構築した：

• mapping = {')':'(', '}':'{', ']':'['}を使用
• 左括弧をスタックに積み、右括弧でポップして比較
• 統一してlen(stack)==0を返す

この書き方は、元コードの3つの重複したifを1回のテーブル参照に簡略化すると同時に、元コードに欠けていた非括弧文字の処理も補った。GPT-5.5はさらにelse分岐を追加し、不正な文字に遭遇した際は直接Falseを返すようにしており、コードのロバスト性がより高い。

0点モデルが露呈した弱点

Claude Sonnet 4.6は元のロジックが「実際には正しい」と詳細に論証したが、修正コードは出力しなかった。GeminiシリーズとGPT-o3は出力スニペット内で最終的に実行可能なバージョンを完全に提示できなかった。0点モデルの共通の特徴は、分析段階に留まっているか、修正が不徹底で、Noneを返す問題と不正文字の両方を同時に解決できなかった点にある。

エンジニアリング判断の実際的意義

今回のテストは、コード実行の評価軸が正しい結果を書けるかどうかだけでなく、隠れた戻り値の型エラーを発見できるかどうかも問うものであることを改めて証明した。continueでreturn Falseをスキップする書き方は短期的には有効だが、保守性が低く、将来ロジックを追加する際に新たなバグを生みやすい。満点モデルはマッピングテーブルにより一度に判定することで、その後の保守リスクを大幅に低減した。

モデルが「動く」を「保守しやすく境界が明確」へと能動的にアップグレードできるようになって初めて、コード実行の合格ラインを真に越えたといえる。

今回の評価では、7モデルがこのラインを越え、4モデルは依然として表面的な分析に留まっている。安定性の評価軸については、今後同一モデルが同種のデバッグ問題に複数回答した際のスコアのばらつきを追跡していく予定だが、現時点で既に明確な分化が見られている。

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