# 評価基準の設計法——グレーディング手法の選び方

> AIエージェントのeval精度は評価基準の設計で決まる。完全一致・コサイン類似度・ROUGE-L・LLM採点の4手法を8つの基準軸にどう対応させるか、Claude公式ドキュメントに基づき解説する。

- Canonical: https://kuucorp.com/blog/agent-eval-success-criteria-grading-method-design/
- Date: 2026-09-07
- Last modified: 2026-09-07
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
「evalを回しているのにスコアが安定しない」というチームの多くは、グレーダーの実装より前に問題を抱えている。評価基準そのものが曖昧で、何を測っているかが定義されていないケースだ。Anthropicの公式ドキュメントは、評価基準の設計とグレーディング手法の選定を分けて考えるよう明確に示している。

## 評価基準はなぜ「精度が高い」だけでは足りないか

> 評価基準はSpecific・Measurable・Achievable・Relevantの4条件を満たす必要があり、倫理性のような曖昧な観点も数値化できます。

Anthropicのガイドラインは、評価基準を**Specific（具体的）・Measurable（測定可能）・Achievable（達成可能）・Relevant（関連性がある）**の4条件で設計するよう求めている。「精度の高い応答」のような抽象的な目標は基準にならない。「感情分類の正解率」のように具体化し、「1万トライアル中トキシシティが検出される割合を0.1%未満に抑える」のように、一見数値化しづらい安全性のような観点も定量的な閾値に落とし込む。目標値は業界ベンチマークや過去の実験結果、専門知識を根拠に設定する。

## 評価基準はどう分類すればよいか

> ドキュメントはタスク忠実度・一貫性・関連性・トーン・プライバシー・文脈活用・レイテンシ・コストの8軸を提示し、多くの用途で複数軸の同時評価が必要だとしています。

公式ドキュメントは評価基準を8つのカテゴリに整理する。**タスク忠実度**（本来のタスクをどれだけ正確にこなすか）、**一貫性**（似た入力に対する応答の意味的な安定性）、**関連性と一貫した構成**（ユーザーの問いにどれだけ的確に答えるか）、**トーンとスタイル**（想定する話し方への一致度）、**プライバシー保護**（機微情報の扱い）、**文脈活用**（与えられたコンテキストをどれだけ使いこなすか）、**レイテンシ**、**コスト**である。多くの業務では単一軸ではなく複数軸を同時に評価する必要があり、カスタマーサポート用エージェントならタスク忠実度とトーン、文書処理エージェントならタスク忠実度とプライバシー保護を組み合わせるといった設計になる。

## グレーディング手法はどう選べばよいか

> 完全一致・コサイン類似度・ROUGE-L・LLM採点の4手法を基準の性質に応じて使い分けると、自動化率を保ったまま精度を確保できます。

基準の性質とグレーディング手法を対応させることが、eval設計の核になる。**タスク忠実度**のように正解が明確なカテゴリ分類（感情分析の positive/negative/neutral など）には完全一致（文字列比較）が向く。**一貫性**のように言い換えた入力間の意味的な近さを測るにはコサイン類似度（文埋め込みベースのSBERT等）を使う。**関連性と構成**のような要約タスクの評価にはROUGE-L（最長共通部分列に基づくF1スコア）が実用的だ。**トーンとスタイル**のように主観的な質を測る場合はLLMに1〜5段階のLikert評価をさせ、評価対象と異なるモデルを採点役に使うのが公式の推奨である。**プライバシー保護**のように機微情報の有無を判定する場合はLLMによる二値分類、**文脈活用**のように順序性のある品質を測る場合はLLMによる順序尺度評価が適する。ドキュメントは「少数の高品質な人手採点より、シグナルがやや弱くても自動グレーディングされた質問を大量に用意する方がよい」と明言しており、可能な限り自動化できる手法を優先すべきだ。

## 中小企業はどこから着手すべきか

> まず1〜2軸に絞り、完全一致など機械的に判定できる基準から着手し、主観的な軸は段階的にLLM採点へ広げるのが現実的です。

複数のグレーディング手法を一度に揃える必要はない。まず自社の業務で最も外してはいけない基準を1〜2軸に絞り、完全一致や正規表現など機械的に判定できるものから着手する。コードでのグレーダー実装に不安がある場合は、[Claude ConsoleのEvaluateタブ](/blog/claude-console-evaluate-no-code-eval-smb/)で人手による5段階採点から始め、評価軸ごとの判断基準を明文化する作業を先に済ませておくとよい。基準が固まった段階で、[20タスクから始めるeval設計](/blog/agent-eval-minimum-viable-setup/)の手順に沿ってコードベースグレーダーへ移行し、主観的な軸だけLLM採点を組み込む。[エージェントガバナンス](/glossary/agent-governance/)の観点でも、どの基準をどの手法で採点しているかを文書化しておくことが、後からグレーダーの妥当性を検証する際の土台になる。

Kuuの[AIエージェント運用管理サービス（AI Ops）](https://kuucorp.com/services/ai-ops/)では、評価基準の設計からグレーダー実装までを一貫して支援している。

## 参考

- [Define success criteria and build evaluations（Claude Platform Docs）](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)
- [Evaluate prompts in the developer console（Claude by Anthropic）](https://claude.com/blog/evaluate-prompts)

## まとめ

evalスコアが安定しない原因の多くは、グレーダーの実装ではなく評価基準の設計にある。SMART条件で基準を具体化し、タスク忠実度・一貫性・関連性・トーン・プライバシー・文脈活用・レイテンシ・コストの8軸から自社業務に必要なものを選び、完全一致・コサイン類似度・ROUGE-L・LLM採点という4つの手法を基準の性質に応じて割り当てる——この順序で設計すれば、少ない工数でも意味のあるeval基盤を組める。評価基準の設計から相談したい場合は、Kuuの[AI Ops](https://kuucorp.com/services/ai-ops/)まで問い合わせてほしい。