【ITニュース解説】The benchmark that disproved its own result

最近、とある記事がAIモデルの能力について興味深い主張をしていた。それは、2年前のコーディングに特化したAIモデルが、新しい汎用AIモデルよりも、プログラミングコードではないけれど構造化されたテキスト（JSONやYAMLのような形式）の編集において、ルールをより正確に守るというものだった。汎用モデルは「親切に聞こえる」ように最適化されているため、ルールを「提案」のように扱うことが多いが、コーディングモデルは「ルールこそが重要」だと捉える、というのがその主張の根拠だった。しかし、その記事には具体的な測定結果が一切示されていなかった。

通常、データのない主張はそこで検証を終えることが多い。だが、この主張は「コーディングに特化したモデルは、汎用モデルよりも構造的なルールを確実に守る」という、具体的で検証可能な内容だったため、筆者は自らテストを行うことにした。

テストの準備として、すでに手元にあった二つのAIモデルを用いた。一つはqwen3-coder-30bというコーディングに特化したモデル、もう一つはqwen3:8bという汎用モデルだ。後者の汎用モデルを選ぶ際には、AIへの指示の形式を決定する「チャットテンプレート」が正しく設定されていることを確認した。これは、テンプレートが適切でないと、モデルの性能が黙って低下し、誤った結果を導く可能性があるためだ。 テストの内容は、JSONの修正、YAMLのヘッダー情報（フロントマター）の処理、CSVデータの整形、Dockerログからの情報抽出、Markdown形式のテーブル作成という5種類のタスクを用意した。AIモデルの出力は確率的な性質を持つため、各タスクを3回ずつ、合計30回の実行を行った。 評価の際には、出力が期待通りの形式と内容になっているかを厳しくチェックした。単なる部分文字列の一致ではなく、完全に同じであるか、あるいはデータをパース（解析）して内容を比較する方式を採用した。これは、過去に曖昧なテスト方法で誤った「成功」が検出された経験があったからだ。また、モデルの「思考モード」はオフにし、出力の確率的なバラつきを抑えるための「温度」設定もデフォルトのままにした。これは、特定の精度を狙った調整ではなく、普段使いにおけるモデルの振る舞いを確認するためだ。

テスト実行前に、評価システム自体にバグがないかを確認する「自己テスト」を実施した。これは、評価する側のロジックが間違っていれば、そこから得られるすべての数値は意味をなさないため、非常に重要な工程だ。すると、YAMLタスクのチェッカーでバグが見つかった。 このタスクでは、モデルがYAMLのヘッダーに新しいキーを追加する際、既存のキーを変更しないことを確認していた。その既存のキーの中に、2026-07-01という日付フィールドがあった。YAMLのパーサーは、引用符で囲まれていないISO形式の日付を、文字列ではなく日付オブジェクトとして読み込む。しかし、チェッカーはこの日付オブジェクトを、文字列である"2026-07-01"と比較していたため、常に不一致と判断される状態だった。 このバグは、モデルが完全に正しい出力をしたとしても、チェッカーが「失敗」と判定してしまうものだった。幸い、これはテスト実行前に発見され、日付オブジェクトを文字列に変換して比較するように修正された。この経験は、評価ロジック自体も疑い、厳しくチェックするという「敵対的な規律」の重要性を示している。テストの基盤となるコードも、他のコードと同様にレビューされにくいが、信頼性の確保には不可欠なのだ。

修正された評価システムでテストを再実行すると、最初の結果は、元の記事の主張を「裏付ける」ように見えた。合計30回の実行で、コーディングモデルが汎用モデルよりも良い成績を示したのだ。 特にDockerログ抽出タスクでは、コーディングモデルが3回中3回成功したのに対し、汎用モデルは3回中0回しか成功しなかった。他の4つのタスクでは両モデルとも完璧な成績だった。この結果は非常に明確で、まるで元の記事が主張した「構造的ルール遵守能力の差」をそのまま示しているかのようだった。成功と失敗が綺麗に分かれ、予測された方向に一致していた。

しかし、この「明確な発見」こそが、実はバグを内包していたのだ。 テストシステムは、単に合否を記録するだけでなく、モデルの生出力をそのまま保存するように設計されていた。そのため、汎用モデルが失敗したDockerログ抽出タスクの生出力を詳しく確認することができた。 確認すると、汎用モデルが生成したJSONは、有効で構造も正しく、必要な情報もきちんと含まれていた。何が問題だったかというと、抽出されたメッセージフィールドに"ERROR "というログレベルの単語が含まれていたことだった。一方、コーディングモデルの出力と、あらかじめ設定されていた「期待される正解」では、この"ERROR "という単語はメッセージから取り除かれていたのだ。 AIへの指示文（プロンプト）は、「各ERROR行を{timestamp, service, message}の形式で抽出せよ」とだけ書かれていた。"ERROR"という単語がメッセージフィールドに含めるべきか、それともメタデータとして除外すべきか、については明確に指示していなかったのだ。 つまり、汎用モデルは"ERROR"を含めてメッセージを解釈し、コーディングモデルは"ERROR"を除外して解釈していた。どちらの解釈も、与えられた曖昧な指示文からすれば妥当なものであり、汎用モデルが「理解に失敗した」わけではなかった。単に、指示の曖昧さによって、チェッカーが一方の解釈を誤りと判断していただけだった。

この事実が判明したため、指示文を明確にする修正を行った。「メッセージフィールドには、ERRORという単語自体ではなく、ERRORレベルの単語の後に続くテキストのみを含めること」という一文をプロンプトに追加し、全30タスクを再び実行した。 その結果、Dockerログ抽出タスクにおいても汎用モデルが3回中3回成功し、両モデル間の性能差は完全に消滅した。最初のテストで見られた顕著な差は、モデルの能力差ではなく、プロンプトの曖昧さとそれに対する評価システムの解釈のずれによって生じたものだったのだ。

この一連の検証から得られる教訓は非常に重要だ。 まず、「仮説を裏付ける結果が出たときこそ、注意深く疑うべきである」という点だ。人間は、自分が信じていることや期待している結果が出ると、それをすぐに「正しい」と受け入れがちだ。逆に、仮説を否定する結果が出ると、どこかに間違いがないかと徹底的に検証しようとする傾向がある。しかし今回のように、仮説を裏付けた結果の中にこそバグが潜んでいる可能性があるのだ。 そのため、どんな結果が出たとしても、その裏にある生の出力を確認するという習慣が不可欠だ。この習慣がなければ、今回の検証は「テストの結果、元の記事は正しかった」という結論で終わり、誰もその誤りに気づかなかっただろう。 また、今回の結果は、元の記事の主張が「完全に間違っていた」ことを示すものではない、という点も重要だ。元の記事は、もっと古い小規模なコーディングモデルと、より新しい大規模な汎用モデルを比較しており、今回テストしたモデルとは条件が異なっていた。今回のテストで分かったのは、「現代の比較的性能の高い二つのモデル間で、明確な指示が与えられれば、構造的ルール遵守能力に差はない」ということだけだ。 さらに、検証の過程で得られた重要なデータ、特に「バグを含んでいた最初の実行結果」が、上書きによって失われてしまったことも教訓となる。最終的に正しいとされる結果だけでなく、私たちを再考させ、多くの発見をもたらした「間違った」結果こそが、保存しておくべき価値のあるデータだったのだ。この経験は、開発や検証の記録方法にも重要な示唆を与えている。