評価スコアを疑う——トランスクリプト読解と採点バグ検出

eval を回したらスコアが 40% だった。エージェントが弱いのか、テストが壊れているのか。数字だけでは判別できない。評価を始めたばかりの小さなチームほど、この区別をつけないまま「モデルを替えよう」「プロンプトを足そう」と動いてしまう。

エージェント評価の最小構成を作った次の課題は、スコアを信じてよいかの検証だ。手段は一つで、トランスクリプトを読むことである。

なぜ eval スコアを額面通りに信じてはいけないのか

Anthropic は CORE-Bench で Opus 4.5 が 42% から 95% に変わった例を挙げ、低スコアの原因が採点側にあり得ると示しています。

Anthropic の評価ガイドは、この事例を次のように説明している。初期スコア 42% が、採点バグの修正と制約の少ない scaffold への変更で 95% になった。

原因として挙がっているのは次の3種類だ。

同ガイドは「評価スコアは、詳細とトランスクリプトを読むまで額面通りに受け取らない」という姿勢を示している。

トランスクリプトは出力・ツール呼び出し・推論・中間結果を含む1試行の完全な記録で、失敗が公正かどうかを判定する根拠になります。

エージェントの可観測性（トレース）を取っていれば、トランスクリプトはその1試行ぶんにあたる。読むときの観点は次の3つに絞れる。

ガイドは、失敗が公正に見えること自体を eval の健全性の目安にしている。何が悪かったのか読んで分からない失敗は、タスクか採点を疑う対象だ。

採点バグは「厳しすぎる合否基準」「曖昧な仕様」「試行間の状態共有」の3系統に分かれ、0% 合格はタスク破損の強いサインです。

ガイドが挙げる兆候を、確認アクションとともに整理する。

特に 0% は重要だ。ガイドは、フロンティアモデルで多数試行しても 0% なら、多くの場合エージェントではなくタスクが壊れていると述べている。また、Claude が過去の試行の git 履歴を見て有利になった例も報告されており、試行は毎回クリーンな状態から始める必要がある。

週1回、不合格トランスクリプトを数件読み、グレーダーかタスクの修正に回す運用が、少人数チームの現実的な最小手順です。

専任の評価担当がいなくても、次の流れなら回る。

各タスクに参照解答を用意し、解けることを先に確認する。ガイドは「2人のドメイン専門家が独立に同じ合否を出せるタスク」を良いタスクの基準としている
不合格の出力を、スコアの低い順に数件読む。グレーダーの誤判定が見つかれば、採点側を直す
完全一致で落ちるタスクは、正規化や許容範囲の導入を検討する。Anthropic のドキュメントも、主観的な品質には LLM による採点を使い、採点モデルは生成モデルと別にするのが基本としている
「起きるべき場合」と「起きてはいけない場合」の両方をテストする。ガイドは偏った eval が偏った最適化を生むと指摘している

採点方式の選び方は評価基準の設計法、試行回数の決め方はpass@k 実践ガイドも参照してほしい。

Kuu のAI エージェント運用管理サービス（AI Ops）では、eval の立ち上げと、グレーダーの検証を含む継続運用を支援している。

eval のスコアは、読んで初めて意味を持つ。低スコアを見たらモデルやプロンプトを変える前に、不合格のトランスクリプトを読み、グレーダー・仕様・試行環境のどれかが壊れていないかを確認する。参照解答で通ること、0% を破損のサインとして扱うこと、試行ごとに環境を初期化することが最低限の手順だ。

評価の立ち上げから採点の検証まで、Kuu への相談から始められる。