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

> eval のスコアが低いとき原因はエージェントとは限らない。Anthropic は Opus 4.5 の CORE-Bench を 42% から 95% へ変えた採点バグの見つけ方を公開している。

- Canonical: https://kuucorp.com/blog/agent-eval-transcript-review-grader-bug-smb/
- Date: 2026-10-22
- Last modified: 2026-10-22
- Publisher: Kuu株式会社 (https://kuucorp.com)

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

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

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

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

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

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

- 厳格すぎる採点: 期待値が「96.124991…」のとき「96.12」を不合格にした
- 曖昧な仕様: タスクが前提とするファイルパスが指示に書かれていなかった
- 再現できないタスク: 確率的な処理を含み、同じ答えを出せなかった

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

## トランスクリプトとは何で、どこを読むのか

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

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

1. 失敗は公正か: 何を間違えたのか、なぜ間違えたのかが読んで分かる
2. グレーダーは有効な解答を落としていないか: エージェントが正しく解いたのに不合格になっていないか
3. 試行の外に原因がないか: 前の試行の残骸や共有リソースが結果に影響していないか

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

## 採点バグはどんなパターンで現れるのか

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

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

| 兆候 | 疑う点 | 確認アクション |
|---|---|---|
| 多数試行しても合格率 0% | タスク自体の破損 | 参照解答で通るかを実行する |
| 正解に見える出力が不合格 | 完全一致など厳格すぎる採点 | 不合格の出力を目視する |
| 試行ごとに結果が揺れる | 共有状態・リソース制限 | 試行を毎回クリーンな環境で始める |
| 指示通りに動いたのに不合格 | 指示と採点基準の食い違い | 指示文と採点条件を突き合わせる |

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

## 小さなチームはどう運用に組み込むのか

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

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

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

採点方式の選び方は[評価基準の設計法](/blog/agent-eval-success-criteria-grading-method-design/)、試行回数の決め方は[pass@k 実践ガイド](/blog/agent-eval-multi-trial-sampling-smb/)も参照してほしい。

Kuu の[AI エージェント運用管理サービス（AI Ops）](https://kuucorp.com/services/ai-ops/)では、eval の立ち上げと、グレーダーの検証を含む継続運用を支援している。

## 参考

- [Demystifying evals for AI agents（Anthropic Engineering）](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
- [Define success criteria and build evaluations（Claude Platform Docs）](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)

## まとめ

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

評価の立ち上げから採点の検証まで、[Kuu への相談](https://kuucorp.com/services/ai-ops/)から始められる。