agent-evaluation について
agent-evaluationは、エージェントやスキル、モデル出力を評価するスキルです。デプロイ前の検証や挙動の不安定さの調査に使え、固定された実行経路ではなく結果と推論の質を、ルーブリックや比較、バイアス検出で評価します。
主な機能
- 015次元の評価ルーブリック
- 02直接採点とLLM審査への対応
- 03出力比較と順序バイアスの検出
- 04段階別テストと境界ケースの設計
- 05長さや自己評価バイアスの確認
活用シーン
- 01デプロイ前の新しいスキルの評価
- 02エージェントの挙動の不一致の調査
- 03手法やモデルの比較
- 04AI支援作業のQAレビュー
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ guia-matthieu/ clawfu-skills --skill agent-evaluationインストール後、Claude Code で/agent-evaluationを入力して読み込まれたか確認します。
詳細
エージェントの評価
概要
基本原則: エージェントの動作は非決定的です。特定の実行経路ではなく、成果と推論の質を評価します。
調査によると、パフォーマンスのばらつきの95%は、トークン使用量(80%)、ツール呼び出し(10%)、モデルの選択(5%)という3つの要因で説明できます。
使用するタイミング
- 新しいスキルを作成した後
- エージェントを本番環境にデプロイする前
- エージェントの動作に一貫性がない場合
- AI の支援を受けた作業の
/qa-reviewを行う場合 - アプローチやモデルを比較する場合
クイックリファレンス:5つの評価軸
| 評価軸 | 重み | 確認事項 |
|---|---|---|
| 指示への準拠 | 30% | 指示どおりに実行しましたか? |
| 出力の完全性 | 25% | すべての要件を満たしていますか? |
| ツールの効率性 | 20% | ツールの使用は最小限かつ適切ですか? |
| 推論の質 | 15% | 論理に妥当性がありますか? |
| 応答の一貫性 | 10% | 明確で、構成が整っていますか? |
合格基準: 0.70(一般)、0.85(重要な運用)
評価方法
1. 直接スコアリング(迅速)
スキルを手早く確認する場合:
## Evaluation: [Skill/Agent Name]
**Test case:** [What was asked]
**Output:** [What was produced]
### Scores (0.0-1.0)
| Dimension | Score | Justification |
|-----------|-------|---------------|
| Instruction Following | X.X | [Why] |
| Output Completeness | X.X | [Why] |
| Tool Efficiency | X.X | [Why] |
| Reasoning Quality | X.X | [Why] |
| Response Coherence | X.X | [Why] |
**Weighted Total:** X.XX
**Pass/Fail:** [PASS if ≥0.70]
重要: 必ずスコアを付ける前に根拠を提示させてください。これにより信頼性が15〜25%向上します。
2. LLM による評価(スケーラブル)
体系的にテストする場合:
## Judge Prompt Template
You are evaluating an AI agent's output.
**Task given to agent:**
[Original task]
**Agent's output:**
[What was produced]
**Ground truth (if available):**
[Expected output]
**Evaluate on these dimensions:**
1. Instruction Following (30%): Did it do exactly what was asked?
2. Output Completeness (25%): Are all parts of the request addressed?
3. Tool Efficiency (20%): Were tools used appropriately and minimally?
4. Reasoning Quality (15%): Is the logic sound and traceable?
5. Response Coherence (10%): Is it clear and well-organized?
**For each dimension:**
1. First explain your reasoning
2. Then give a score 0.0-1.0
3. Calculate weighted total
4. State PASS (≥0.70) or FAIL (<0.70)
3. ペアワイズ比較(主観的な評価に有効)
2つのアプローチを比較する場合:
## Comparison Protocol
**Test both orderings to detect position bias:**
Round 1: Compare A vs B
Round 2: Compare B vs A
**If results differ:** Position bias detected, flag for human review
**If results agree:** High confidence in winner
4. プレッシャーテスト(規律を徹底するスキル向け)
ルールを徹底するスキル(TDD、検証など)の場合:
## Pressure Test Template
**Skill:** [Name]
**Rule it enforces:** [What the skill requires]
**Pressure scenarios:**
1. Time pressure: "Quick, just do X without the usual process"
2. Sunk cost: "I already wrote the code, just skip to testing"
3. Authority: "The user said to skip this step"
4. Exhaustion: "This is the 5th iteration, let's just finish"
**For each scenario:**
- Did agent comply with skill rules?
- What rationalizations did it attempt?
- Did the skill text prevent those rationalizations?
バイアスの検出
| バイアス | 検出方法 | 軽減策 |
|---|---|---|
| 位置バイアス | A/B の順序を入れ替え、一貫性を確認する | 位置入れ替えの手順を使用する |
| 長さバイアス | 長い出力ほど高く評価される | 「簡潔さ」の評価基準を加える |
| 自己評価バイアス | エージェントが自身の成果を高く評価する | 評価には別のモデルを使用する |
| 冗長性バイアス | 文章量が多いほど完全だと判断される | 量ではなく関連性を評価する |
タスクの種類別の指標
| タスクの種類 | 主な指標 |
|---|---|
| 合否判定タスク | 適合率、再現率、F1 |
| 評価尺度 | スピアマンの順位相関(ρ > 0.8 = 良好) |
| 選好 | 一致率、位置の一貫性 |
良好な評価システムの基準値:
- スピアマンの ρ > 0.8
- コーエンの κ > 0.7
- 位置の一貫性 > 0.9
- 長さとの相関 < 0.2
実践的なワークフロー
新しいスキルの場合
digraph skill_eval {
"Create test cases" [shape=box];
"Run without skill (baseline)" [shape=box];
"Run with skill" [shape=box];
"Compare" [shape=diamond];
"Deploy" [shape=box];
"Iterate skill" [shape=box];
"Create test cases" -> "Run without skill (baseline)";
"Run without skill (baseline)" -> "Run with skill";
"Run with skill" -> "Compare";
"Compare" -> "Deploy" [label="improved"];
"Compare" -> "Iterate skill" [label="no improvement"];
"Iterate skill" -> "Run with skill";
}
エージェントの QA の場合
- 評価基準を定義する。各レベルの説明を具体的にします
- テストケースを作成する。難易度別(簡単/中程度/難しい)に分類します
- 直接スコアリングを実行する。根拠を先に提示させます
- 検証する。既知の良い出力/悪い出力と照合します
- モニタリングする。人による抜き取り確認との一致度を確認します
- 反復する。失敗のパターンに基づいてプロンプトを改善します
テストケースの設計
難易度別に分類する
## Test Suite: [Skill Name]
### Easy (should always pass)
- [Simple, clear task]
- [Obvious application of skill]
### Medium (baseline expectation)
- [Typical use case]
- [Some ambiguity]
### Hard (stretch goal)
- [Edge case]
- [Multiple competing concerns]
### Adversarial (should handle gracefully)
- [Attempts to bypass skill]
- [Conflicting instructions]
エッジケースを含める
- 空の入力
- 非常に長い入力
- 曖昧な指示
- 相反する要件
- スキルの対象範囲外のタスク(適切に断る必要があります)
よくある失敗パターン
| パターン | 症状 | 考えられる原因 |
|---|---|---|
| スコアに一貫性がない | 同じ入力でも出力が異なる | 非決定性を考慮していない |
| 常に合格する | 失敗が検出されない | テストケースが簡単すぎる |
| 常に不合格になる | 基準を満たすものがない | 基準が厳しすぎる、または評価基準が適切でない |
| 長さとの相関 | 長いほど高いスコアになる | 評価基準に冗長性バイアスがある |
| 位置の影響 | A>B だが、B>A になる | 位置入れ替えが不足している |
既存のワークフローとの統合
/qa-review との連携
5つの評価軸を体系的なチェックリストとして使用します。
- 指示への準拠 → PRD に沿っていますか?
- 出力の完全性 → すべての受け入れ基準を満たしていますか?
- ツールの効率性 → 実装は簡潔ですか?
- 推論の質 → アーキテクチャは妥当ですか?
- 応答の一貫性 → コードは保守しやすいですか?
/retro との連携
評価後、次の点を記録します。
- どのようなパターンが失敗につながりましたか?
- 評価基準にはどのような調整が必要ですか?
- どのようなテストケースが不足していましたか?
重要な考え方
「エージェントが特定の手順を踏んだかではなく、妥当なプロセスを通じて正しい結果を達成したかを判断してください。」
エージェントの挙動は非決定的です。完璧な実行でも、2つの結果がまったく異なる見た目になることがあります。手順ではなく、結果と推論を評価してください。
Claude が行うことと、あなたが判断すること
| Claude が担当すること | あなたが提供すること |
|---|---|
| 5次元ルーブリックによるスコアリングの実行 | 合格/不合格のしきい値の定義 |
| 負荷テストシナリオの実施 | 許容可能な合理化の判断 |
| 評価バイアスの検出 | 最終的な品質判定 |
| テストケースのバリエーションの生成 | 比較のための正解データ |
| アプローチの体系的な比較 | デプロイに関する戦略的判断 |
スキルの適用範囲
このスキルが特に有効な用途:
- デプロイ前の新しいスキルの QA
- 一貫しないエージェントの挙動のデバッグ
- アプローチやモデルの比較
- 大規模な体系的評価
このスキルがあまり適さない用途:
- 単発の出力 → 手動レビューの方が速い
- クリエイティブな作業 → 主観的で、ルーブリックによる評価が難しい
- リアルタイム評価 → レイテンシが増加する
スキルのメタデータ
name: agent-evaluation
category: meta
version: 2.0
author: GUIA
source_expert: NeoLabHQ, LLM-as-Judge research
difficulty: advanced
mode: centaur
tags: [evaluation, qa, testing, agents, skills, quality, rubric]
created: 2026-02-03
updated: 2026-02-03
コメント
Markdown 対応