agent-evaluation

Claude Code エージェントの評価方法

エージェントシステムの評価には、従来のソフトウェアや標準的な言語モデルアプリケーションとは異なるアプローチが必要です。エージェントは動的に判断し、実行ごとに非決定的な動作をし、正解が一つとは限らないこともよくあります。効果的な評価では、実用的なフィードバックを提供しながら、こうした特性を考慮する必要があります。堅牢な評価フレームワークによって、継続的な改善を促し、リグレッションを検出し、コンテキストエンジニアリングの選択が意図した効果をもたらしていることを検証できます。

基本概念

エージェントの評価には、非決定性と複数の有効な経路を考慮した、結果重視のアプローチが必要です。多次元の評価基準では、事実の正確性、網羅性、引用の正確性、情報源の質、ツールの効率性など、さまざまな品質要素を捉えます。LLM による評価はスケーラブルな評価を可能にし、人による評価はエッジケースを検出します。

重要な点は、エージェントが目標に到達するために別の経路を見つける場合があることです。評価では、妥当なプロセスに従いながら、適切な結果を達成したかどうかを判断する必要があります。

パフォーマンスを左右する要因：95％という調査結果 BrowseComp 評価（ブラウジングエージェントが見つけにくい情報を探し出す能力をテストするもの）に関する研究では、パフォーマンスのばらつきの95％を次の3つの要因で説明できることが分かりました。

要因	説明されるばらつき	意味
トークン使用量	80%	トークンが多いほど、パフォーマンスが向上します
ツール呼び出し回数	~10%	探索を増やすと効果があります
モデルの選択	~5%	より優れたモデルは効率を大幅に高めます

Claude Code の開発における意味：

• トークン予算は重要です：現実的なトークン制約のもとで評価してください
• トークンの増加よりモデルのアップグレードが効果的です：モデルをアップグレードすると、トークン予算を増やすより大きな改善が得られます
• マルチエージェントによる検証：個別のコンテキストウィンドウを持つサブエージェントに作業を分散するアーキテクチャを検証できます

評価における課題

非決定性と複数の有効な経路

エージェントは、目標に到達するまでにまったく異なる有効な経路をたどることがあります。あるエージェントは3つの情報源を検索し、別のエージェントは10個を検索するかもしれません。同じ答えを見つけるために、異なるツールを使う場合もあります。特定の手順を確認する従来の評価では、この状況に対応できません。

解決策：重視すべきなのは、厳密な実行経路ではなく結果です。エージェントが妥当なプロセスを通じて適切な結果を達成したかどうかを評価します。

コンテキストに依存する失敗

エージェントの失敗は、微妙な形でコンテキストに依存することがよくあります。複雑なクエリには対応できても、単純なクエリでは失敗する場合があります。あるツールセットではうまく動作しても、別のツールセットでは失敗する場合もあります。コンテキストが蓄積する長時間のやり取りの後にのみ、失敗が現れることもあります。

解決策：評価では、複雑さの異なる幅広いケースを対象とし、個別のクエリだけでなく、長時間のやり取りもテストする必要があります。

複合的な品質の側面

エージェントの品質は単一の側面で決まるものではありません。事実の正確性、網羅性、一貫性、ツールの効率性、プロセスの質などが含まれます。エージェントは、正確性のスコアは高くても効率性が低い場合や、その逆の場合があります。

エージェントは、正確性のスコアは高くても効率性が低い場合があります。

解決策：評価基準では、ユースケースに応じた適切な重み付けで、複数の側面を捉える必要があります。

評価基準の設計

多次元ルーブリック

効果的なルーブリックでは、主要な評価軸を説明的なレベルで網羅します。

指示への準拠（重み：0.30）

• 優秀（1.0）：すべての指示に正確に従っている
• 良好（0.8）：結果に影響しない軽微な逸脱がある
• 許容範囲（0.6）：主要な指示には従っているが、軽微な指示を見落としている
• 不十分（0.3）：重要な指示を無視している
• 失敗（0.0）：タスクを根本的に誤解している

出力の完全性（重み：0.25）

• 優秀：要求されたすべての要素を十分に網羅している
• 良好：ほとんどの要素を網羅しており、軽微な不足がある
• 許容範囲：重要な要素を網羅しているが、一部不足がある
• 不十分：重要な要素が大きく欠けている
• 失敗：根本的な要素に対応していない

ツールの効率性（重み：0.20）

• 優秀：最適なツールを選択し、呼び出しを最小限に抑えている
• 良好：適切なツールを選択しており、軽微な非効率性がある
• 許容範囲：適切なツールを使用しているが、いくらか冗長性がある
• 不十分：不適切なツールを使っているか、呼び出しが過剰である
• 失敗：ツールを著しく誤用しているか、呼び出しが極端に過剰である

推論の質（重み：0.15）

• 優秀：一貫して明確かつ論理的に推論している
• 良好：概ね妥当な推論を行っており、軽微な不足がある
• 許容範囲：基本的な推論が行われている
• 不十分：推論が不明瞭または誤っている
• 失敗：推論が見られない

応答の一貫性（重み：0.10）

• 優秀：構成が整っており、理解しやすい
• 良好：概ね一貫しており、軽微な問題がある
• 許容範囲：理解できるが、さらに明確にできる
• 不十分：理解しにくい
• 失敗：一貫性がない

スコアリング方法

各評価軸を適切な重みで数値スコア（0.0～1.0）に換算します。重み付きの総合スコアを計算します。用途の要件に応じて合格基準を設定します（一般的な用途では通常0.7、重要な運用では0.85）。

評価手法

LLM による評価

LLM を使ってエージェントの出力を評価すると、優れた拡張性と一貫した判定が得られます。関心のある評価軸を捉える評価プロンプトを設計します。LLM による評価は大規模なテストセットにも対応でき、一貫した判定を提供します。重要なのは、関心のある評価軸を捉える効果的な評価プロンプトを設計することです。

明確なタスクの説明、エージェントの出力、正解データ（利用可能な場合）、レベルの説明を含む評価尺度を提示し、構造化された判定を求めます。

評価プロンプトのテンプレート：

You are evaluating the output of a Claude Code agent.

## Original Task
{task_description}

## Agent Output
{agent_output}

## Ground Truth (if available)
{expected_output}

## Evaluation Criteria
For each criterion, assess the output and provide:
1. Score (1-5)
2. Specific evidence supporting your score
3. One improvement suggestion

### Criteria
1. Instruction Following: Did the agent follow all instructions?
2. Completeness: Are all requested aspects covered?
3. Tool Efficiency: Were appropriate tools used efficiently?
4. Reasoning Quality: Is the reasoning clear and sound?
5. Response Coherence: Is the output well-structured?

Provide your evaluation as a structured assessment with scores and justifications.

思考の連鎖に関する要件：スコアを提示する前に、必ず根拠を示すよう求めます。スコアを先に提示する方法と比べ、これにより信頼性が15～25％向上することが研究で示されています。

人間による評価

人間による評価では、自動化では見落とされる点を検出できます。

• 通常とは異なるクエリに対する、捏造された回答
• 文脈の微妙な誤解
• 自動評価では見落とされるエッジケース
• トーンやアプローチに関する定性的な問題

Claude Code の開発では、ユーザーに次のように依頼します。

• エッジケースについて、エージェントの出力を手動で確認する
• 複雑さの各レベルから体系的にサンプルを抽出する
• プロンプトの改善に役立てるため、失敗のパターンを追跡する

最終成果物の評価

成果物（ファイル、設定、コード）を生成するコマンドについては、プロセスではなく最終出力を評価します。

• 生成されたコードは動作するか？
• 設定は有効か？
• 出力は要件を満たしているか？

テストセットの設計

サンプルの選定 開発中は小規模なサンプルから始めます。エージェント開発の初期段階では、改善の余地が大きく残されているため、変更が大きな影響をもたらします。小規模なテストセットでも、大きな効果を明らかにできます。

実際の使用パターンからサンプルを抽出します。既知のエッジケースを追加します。複雑さの各レベルを網羅するようにします。

複雑さによる層別化 テストセットでは、複雑さの各レベルを網羅する必要があります。単純（ツール呼び出しが1回）、中程度（複数回のツール呼び出し）、複雑（多数のツール呼び出し、大きな曖昧さ）、非常に複雑（長時間のやり取り、深い推論）です。

コンテキストエンジニアリングの評価

プロンプトのバリエーションをテストする

Claude Code のプロンプトを調整する際は、体系的に評価します。

1. ベースライン：現在のプロンプトをテストケースで実行します
2. バリエーション：変更したプロンプトを同じケースで実行します
3. 比較：品質スコア、トークン使用量、効率を測定します
4. 分析：どの変更がどの評価項目を改善したかを特定します

コンテキスト戦略をテストする

コンテキストエンジニアリングの選択は、体系的な評価を通じて検証する必要があります。同じテストセットで、異なるコンテキスト戦略を使ってエージェントを実行します。品質スコア、トークン使用量、効率の指標を比較します。

劣化テスト

異なるコンテキストサイズでエージェントを実行し、コンテキストの劣化がパフォーマンスに与える影響をテストします。コンテキストが問題になり始めるパフォーマンスの急落点を特定します。安全に運用できる上限を定めます。

高度な評価：LLM-as-Judge

重要な洞察：LLM-as-a-Judge は単一の手法ではなく、それぞれ異なる評価状況に適したアプローチ群です。適切なアプローチを選び、既知のバイアスを緩和することが、このスキルで身につける中心的な能力です。

評価の分類体系

評価アプローチは、信頼性の特性が異なる2つの主要なカテゴリに分けられます。

直接スコアリング：単一の LLM が、定められた尺度で1つの応答を評価します。

• 最適な用途：客観的な基準（事実の正確性、指示への準拠、有害性）
• 信頼性：基準が明確に定義されている場合は中程度から高い
• 失敗パターン：スコアの調整のずれ、尺度の解釈の不一致

ペアワイズ比較：LLM が2つの応答を比較し、より優れた方を選びます。

• 最適な用途：主観的な好み（トーン、スタイル、説得力）
• 信頼性：好みの評価では直接スコアリングより高い
• 失敗パターン：提示順序のバイアス、長さのバイアス

MT-Bench 論文（Zheng ほか、2023）の研究では、好みに基づく評価において、ペアワイズ比較は直接スコアリングよりも人間の評価者との一致度が高い一方、明確な正解がある客観的な基準には直接スコアリングが適切であることが示されています。

バイアスの全体像

LLM の評価者には、積極的に緩和すべき体系的なバイアスがあります。

提示順序のバイアス：ペアワイズ比較では、最初に提示された応答が優先されます。緩和策：提示順序を入れ替えて2回評価し、多数決または一貫性チェックを使います。

長さのバイアス：品質にかかわらず、長い応答ほど高く評価されます。緩和策：長さを考慮しないよう明示的に指示し、長さで正規化したスコアリングを行います。

自己評価バイアス：モデルは自身の出力を高く評価します。緩和策：生成と評価で異なるモデルを使用するか、この制約を明示します。

冗長性のバイアス：不要な場合でも、詳しい説明ほど高く評価されます。緩和策：無関係な詳細を減点する、基準ごとのルーブリックを使います。

権威性のバイアス：正確性にかかわらず、自信に満ちた断定的な口調が高く評価されます。緩和策：根拠の引用とファクトチェックの層を必須にします。

指標の選択フレームワーク

評価タスクの構造に基づいて指標を選びます。

タスクの種類	主な指標	副次的な指標
二値分類（合格／不合格）	再現率、適合率、F1	Cohen の κ
順序尺度（1～5の評価）	Spearman の ρ、Kendall の τ	Cohen の κ（重み付き）
ペアワイズの選好	一致率、提示順序の一貫性	信頼度のキャリブレーション
マルチラベル	Macro-F1、Micro-F1	ラベルごとの適合率／再現率

重要な洞察は、絶対的な一致度の高さよりも、体系的な不一致のパターンのほうが重要だということです。特定の基準で人間と一貫して異なる評価をする評価者は、ランダムなノイズがある評価者よりも問題です。

評価指標のリファレンス

分類指標（合格／不合格タスク）

適合率：合格と判定された回答のうち、実際に合格していた割合です。

• 偽陽性が大きな損失につながる場合に使用します

再現率：実際に合格していた回答のうち、合格と特定できた割合です。

• 偽陰性が大きな損失につながる場合に使用します

F1 スコア：適合率と再現率の調和平均です。

• バランスの取れた単一の指標で要約する場合に使用します

一致度指標（人間の判断との比較）

Cohen のカッパ係数：偶然による一致を調整した一致度です。

• 0.8：ほぼ完全な一致

• 0.6～0.8：かなり高い一致
• 0.4～0.6：中程度の一致
• < 0.4：低い一致から不十分な一致

相関指標（順序尺度スコア）

スピアマンの順位相関係数：順位間の相関です。

• 0.9：非常に強い相関

• 0.7～0.9：強い相関
• 0.5～0.7：中程度の相関
• < 0.5：弱い相関

優れた評価システムの指標

指標	良好	許容範囲	懸念あり
スピアマンの順位相関係数	> 0.8	0.6～0.8	< 0.6
Cohen のカッパ係数	> 0.7	0.5～0.7	< 0.5
順位の一貫性	> 0.9	0.8～0.9	< 0.8
長さとスコアの相関	< 0.2	0.2～0.4	> 0.4

評価アプローチ

直接スコアリングの実装

直接スコアリングには、明確な基準、調整済みの尺度、構造化された出力形式の3つの要素が必要です。

基準の定義パターン：

Criterion: [Name]
Description: [What this criterion measures]
Weight: [Relative importance, 0-1]

尺度の調整：

• 1～3の尺度：中立の選択肢を含む二値尺度で、認知負荷が最も低くなります
• 1～5の尺度：標準的なリッカート尺度で、細かさと信頼性のバランスに優れています
• 1～10の尺度：細かさは高いものの調整が難しいため、詳細な評価基準がある場合に限って使用します

直接スコアリング用のプロンプト構成：

You are an expert evaluator assessing response quality.

## Task
Evaluate the following response against each criterion.

## Original Prompt
{prompt}

## Response to Evaluate
{response}

## Criteria
{for each criterion: name, description, weight}

## Instructions
For each criterion:
1. Find specific evidence in the response
2. Score according to the rubric (1-{max} scale)
3. Justify your score with evidence
4. Suggest one specific improvement

## Output Format
Respond with structured JSON containing scores, justifications, and summary.

思考の連鎖の要件：すべてのスコアリング用プロンプトで、スコアより先に根拠を示すよう求める必要があります。研究によると、この方法により、スコアを先に示すアプローチと比べて信頼性が15～25％向上します。

ペアワイズ比較の実装

ペアワイズ比較は、好みに基づく評価では本質的に信頼性が高い方法ですが、バイアスを軽減する対策が必要です。

提示位置バイアスの軽減プロトコル：

1. 1回目：回答Aを先に、回答Bを後に提示します
2. 2回目：回答Bを先に、回答Aを後に提示します
3. 一貫性の確認：結果が一致しない場合は、信頼度を下げて引き分けを返します
4. 最終判定：一貫して勝った回答を、平均信頼度とともに示します

ペアワイズ比較用のプロンプト構成：

You are an expert evaluator comparing two AI responses.

## Critical Instructions
- Do NOT prefer responses because they are longer
- Do NOT prefer responses based on position (first vs second)
- Focus ONLY on quality according to the specified criteria
- Ties are acceptable when responses are genuinely equivalent

## Original Prompt
{prompt}

## Response A
{response_a}

## Response B
{response_b}

## Comparison Criteria
{criteria list}

## Instructions
1. Analyze each response independently first
2. Compare them on each criterion
3. Determine overall winner with confidence level

## Output Format
JSON with per-criterion comparison, overall winner, confidence (0-1), and reasoning.

信頼度の調整：信頼度スコアには、提示位置による一貫性を反映させる必要があります。

• 2回の結果が一致する場合：信頼度 = 個々の信頼度の平均
• 2回の結果が一致しない場合：信頼度 = 0.5、判定 = 引き分け

評価基準の作成

明確に定義された評価基準を使用すると、自由形式のスコアリングと比べて評価のばらつきを40～60％抑えられます。

評価基準の構成要素

1. レベルの説明：各スコアレベルの明確な境界
2. 特性：各レベルを定義する観察可能な特徴
3. 例：各レベルを代表する出力（可能な場合）
4. 境界事例：曖昧な状況での指針
5. スコアリングのガイドライン：一貫して適用するための一般原則

厳格さの調整

• 寛容：合格スコアの基準を低く設定し、反復的な改善を促す場合に適しています
• バランス型：本番環境で一般的に求められる、公平な基準です
• 厳格：高い基準を設け、安全性が特に重要な評価や、重大な結果を伴う評価に適しています

ドメインへの適応

評価基準では、ドメイン固有の用語を使用する必要があります。

• 「コードの読みやすさ」の評価基準では、変数、関数、コメントに言及します。
• ドキュメントの評価基準では、明瞭さ、正確さ、完全性を基準にします
• 分析の評価基準では、深さ、正確さ、実用性を重視します

実践的な指針

評価パイプラインの設計

本番環境で使用する評価システムには、複数の層が必要です。

┌─────────────────────────────────────────────────┐
│                 Evaluation Pipeline              │
├─────────────────────────────────────────────────┤
│                                                   │
│  Input: Response + Prompt + Context               │
│           │                                       │
│           ▼                                       │
│  ┌─────────────────────┐                         │
│  │   Criteria Loader   │ ◄── Rubrics, weights    │
│  └──────────┬──────────┘                         │
│             │                                     │
│             ▼                                     │
│  ┌─────────────────────┐                         │
│  │   Primary Scorer    │ ◄── Direct or Pairwise  │
│  └──────────┬──────────┘                         │
│             │                                     │
│             ▼                                     │
│  ┌─────────────────────┐                         │
│  │   Bias Mitigation   │ ◄── Position swap, etc. │
│  └──────────┬──────────┘                         │
│             │                                     │
│             ▼                                     │
│  ┌─────────────────────┐                         │
│  │ Confidence Scoring  │ ◄── Calibration         │
│  └──────────┬──────────┘                         │
│             │                                     │
│             ▼                                     │
│  Output: Scores + Justifications + Confidence     │
│                                                   │
└─────────────────────────────────────────────────┘

評価における落とし穴の回避

アンチパターン：根拠なしのスコア付け

• 問題：スコアの根拠が不明確で、デバッグや改善が難しくなります
• 解決策：スコアを付ける前に、必ず証拠に基づく説明を求めます

アンチパターン：1 回限りのペアワイズ比較

• 問題：位置バイアスによって結果が歪みます
• 解決策：必ず提示位置を入れ替えて、一貫性を確認します

アンチパターン：過剰に詰め込まれた評価基準

• 問題：複数の項目を測定する評価基準は信頼性に欠けます
• 解決策：1 つの評価基準につき、測定可能な側面を 1 つだけにします

アンチパターン：エッジケースに関するガイダンスの不足

• 問題：評価者ごとに、曖昧なケースへの対応が一貫しません
• 解決策：明確なガイダンスとともに、エッジケースを評価基準に含めます

アンチパターン：確信度の調整を無視する

• 問題：確信度の低い誤った判断より、確信度の高い誤った判断のほうが問題です
• 解決策：提示位置の一貫性と証拠の強さに応じて、確信度を調整します

判断フレームワーク：直接評価とペアワイズ比較

次の判断ツリーを使用します。

Is there an objective ground truth?
├── Yes → Direct Scoring
│   └── Examples: factual accuracy, instruction following, format compliance
│
└── No → Is it a preference or quality judgment?
    ├── Yes → Pairwise Comparison
    │   └── Examples: tone, style, persuasiveness, creativity
    │
    └── No → Consider reference-based evaluation
        └── Examples: summarization (compare to source), translation (compare to reference)

評価のスケーリング

大量の評価を行う場合：

1. LLM の評価者パネル（PoLL）：複数のモデルを評価者として使用し、投票を集約します

   • 個々のモデルのバイアスを軽減します
   • コストは高くなりますが、重大な意思決定では信頼性が高まります

2. 階層型評価：高速で安価なモデルをスクリーニングに使い、エッジケースには高価なモデルを使います

   • 大量の評価を費用対効果よく行えます
   • スクリーニングのしきい値を調整する必要があります

3. 人間参加型：明確なケースは自動評価し、確信度が低いケースは人間がレビューします

   • 重要なアプリケーションで最も高い信頼性が得られます
   • 自動評価を改善するためのフィードバックループを設計します

例

例 1：正確性の直接評価

入力：

Prompt: "What causes seasons on Earth?"
Response: "Seasons are caused by Earth's tilted axis. As Earth orbits the Sun, 
different hemispheres receive more direct sunlight at different times of year."
Criterion: Factual Accuracy (weight: 1.0)
Scale: 1-5

出力：

{
  "criterion": "Factual Accuracy",
  "score": 5,
  "evidence": [
    "Correctly identifies axial tilt as primary cause",
    "Correctly explains differential sunlight by hemisphere",
    "No factual errors present"
  ],
  "justification": "Response accurately explains the cause of seasons with correct 
scientific reasoning. Both the axial tilt and its effect on sunlight distribution 
are correctly described.",
  "improvement": "Could add the specific tilt angle (23.5°) for completeness."
}

例 2：提示位置を入れ替えたペアワイズ比較

入力：

Prompt: "Explain machine learning to a beginner"
Response A: [Technical explanation with jargon]
Response B: [Simple analogy-based explanation]
Criteria: ["clarity", "accessibility"]

1 回目の評価（A が先）：

{ "winner": "B", "confidence": 0.8 }

2 回目の評価（B が先）：

{ "winner": "A", "confidence": 0.6 }

（注：B が先頭の位置にあったため、勝者は A です）

2 回目の評価結果の対応付け：

{ "winner": "B", "confidence": 0.6 }

最終結果：

{
  "winner": "B",
  "confidence": 0.7,
  "positionConsistency": {
    "consistent": true,
    "firstPassWinner": "B",
    "secondPassWinner": "B"
  }
}

例 3：評価基準の生成

入力：

criterionName: "Code Readability"
criterionDescription: "How easy the code is to understand and maintain"
domain: "software engineering"
scale: "1-5"
strictness: "balanced"

出力（抜粋）：

{
  "levels": [
    {
      "score": 1,
      "label": "Poor",
      "description": "Code is difficult to understand without significant effort",
      "characteristics": [
        "No meaningful variable or function names",
        "No comments or documentation",
        "Deeply nested or convoluted logic"
      ]
    },
    {
      "score": 3,
      "label": "Adequate",
      "description": "Code is understandable with some effort",
      "characteristics": [
        "Most variables have meaningful names",
        "Basic comments present for complex sections",
        "Logic is followable but could be cleaner"
      ]
    },
    {
      "score": 5,
      "label": "Excellent",
      "description": "Code is immediately clear and maintainable",
      "characteristics": [
        "All names are descriptive and consistent",
        "Comprehensive documentation",
        "Clean, modular structure"
      ]
    }
  ],
  "edgeCases": [
    {
      "situation": "Code is well-structured but uses domain-specific abbreviations",
      "guidance": "Score based on readability for domain experts, not general audience"
    }
  ]
}

反復的な改善ワークフロー

1. 弱点を特定する：評価を使って、エージェントが苦手とする箇所を見つけます
2. 原因を仮定する：プロンプト、コンテキスト、例のどれに問題があるかを考えます
3. プロンプトを変更する：仮説に基づいて、的を絞った変更を加えます
4. 再評価する：変更したプロンプトで同じテストケースを実行します
5. 比較する：変更によって、対象の評価項目が改善したか確認します
6. デグレードを確認する：ほかの評価項目が悪化していないか確認します
7. 反復する：品質がしきい値を満たすまで繰り返します

ガイドライン

1. スコアを付ける前に、必ず説明を求める — 思考過程を段階的に示すよう促すプロンプトにより、信頼性が 15～25% 向上します

2. ペアワイズ比較では、必ず提示位置を入れ替える — 1 回限りの比較では、位置バイアスによって結果が歪みます

3. 尺度の細かさを評価基準の具体性に合わせる — レベルごとの詳細な説明なしに 1～10 の尺度を使わないでください

4. 客観的な評価基準と主観的な評価基準を分ける — 客観的な項目には直接評価を、主観的な項目にはペアワイズ比較を使います

5. 確信度スコアを含める — 提示位置の一貫性と証拠の強さに応じて調整します

6. エッジケースを明確に定義する — 曖昧な状況は、評価のばらつきが最も大きくなる原因です

7. ドメイン固有の評価基準を使う — 汎用的な評価基準では、汎用的で（有用性の低い）評価になります

8. 人間による判断と照合する — 自動評価が有用なのは、人間による評価と相関する場合に限られます

9. 体系的なバイアスを監視する — 評価基準や応答の種類ごとに、不一致のパターンを追跡します

10. 反復を前提に設計する — 評価システムは、フィードバックループによって改善されます

例：Claude Code コマンドの評価

/refactor コマンドを作成し、その品質を評価したいとします。

テストケース：

1. 簡単：単一ファイル内の変数名を変更する
2. 中程度：既存のコードから関数を抽出する
3. 複雑：クラスをリファクタリングして、新しいデザインパターンを適用する
4. 非常に複雑：モジュールの依存関係を再構成する

評価基準：

• 正確性：リファクタリング後のコードは動作しますか？
• 完全性：該当する箇所はすべて更新されていますか？
• スタイル：プロジェクトの規約に従っていますか？
• 効率性：不要な変更は避けられていますか？

評価プロンプト：

Evaluate this refactoring output:

Original Code:
{original}

Refactored Code:
{refactored}

Request:
{user_request}

Score 1-5 on each dimension with evidence:
1. Correctness: Does the code still work correctly?
2. Completeness: Were all relevant instances updated?
3. Style: Does it follow the project's coding patterns?
4. Efficiency: Were only necessary changes made?

Provide scores with specific evidence from the code.

反復： 評価の結果、コマンドが対象箇所を頻繁に見落としていることが分かった場合：

1. 「コードベース全体を検索して、該当する箇所をすべて見つける」という明示的な指示を追加します
2. 同じテストケースで再評価します
3. 完全性のスコアを比較します
4. 正確性が低下していないことを確認します

LLM 評価におけるバイアス軽減手法

このリファレンスでは、LLM-as-a-Judge システムで知られているバイアスを軽減するための具体的な手法を詳しく説明します。

位置バイアス

問題

ペア比較では、LLM は特定の位置にある回答を一貫して好む傾向があります。研究では、次のことが示されています。

• GPT には軽度の先頭位置バイアスがあり、同点の場合、先頭の回答が約 55％の割合で好まれます
• Claude にも同様の傾向が見られます
• 小型モデルでは、バイアスがより強く現れることがよくあります

軽減策：位置入れ替えプロトコル

async def position_swap_comparison(response_a, response_b, prompt, criteria):
    # Pass 1: Original order
    result_ab = await compare(response_a, response_b, prompt, criteria)
    
    # Pass 2: Swapped order
    result_ba = await compare(response_b, response_a, prompt, criteria)
    
    # Map second result (A in second position → B in first)
    result_ba_mapped = {
        'winner': {'A': 'B', 'B': 'A', 'TIE': 'TIE'}[result_ba['winner']],
        'confidence': result_ba['confidence']
    }
    
    # Consistency check
    if result_ab['winner'] == result_ba_mapped['winner']:
        return {
            'winner': result_ab['winner'],
            'confidence': (result_ab['confidence'] + result_ba_mapped['confidence']) / 2,
            'position_consistent': True
        }
    else:
        # Disagreement indicates position bias was a factor
        return {
            'winner': 'TIE',
            'confidence': 0.5,
            'position_consistent': False,
            'bias_detected': True
        }

代替策：複数のシャッフル

信頼性を高めるには、複数の位置順を使用します。

async def multi_shuffle_comparison(response_a, response_b, prompt, criteria, n_shuffles=3):
    results = []
    for i in range(n_shuffles):
        if i % 2 == 0:
            r = await compare(response_a, response_b, prompt, criteria)
        else:
            r = await compare(response_b, response_a, prompt, criteria)
            r['winner'] = {'A': 'B', 'B': 'A', 'TIE': 'TIE'}[r['winner']]
        results.append(r)
    
    # Majority vote
    winners = [r['winner'] for r in results]
    final_winner = max(set(winners), key=winners.count)
    agreement = winners.count(final_winner) / len(winners)
    
    return {
        'winner': final_winner,
        'confidence': agreement,
        'n_shuffles': n_shuffles
    }

長さバイアス

問題

LLM は品質にかかわらず、長い回答を高く評価する傾向があります。これは、次のように現れます。

• 冗長な回答が過大評価される
• 簡潔でありながら完全な回答が不当に低く評価される
• 水増しや繰り返しが加点される

軽減策：明示的なプロンプト指示

プロンプトに、長さバイアスを防ぐ指示を含めます。

CRITICAL EVALUATION GUIDELINES:
- Do NOT prefer responses because they are longer
- Concise, complete answers are as valuable as detailed ones
- Penalize unnecessary verbosity or repetition
- Focus on information density, not word count

軽減策：長さで正規化したスコアリング

def length_normalized_score(score, response_length, target_length=500):
    """Adjust score based on response length."""
    length_ratio = response_length / target_length
    
    if length_ratio > 2.0:
        # Penalize excessively long responses
        penalty = (length_ratio - 2.0) * 0.1
        return max(score - penalty, 1)
    elif length_ratio < 0.3:
        # Penalize excessively short responses
        penalty = (0.3 - length_ratio) * 0.5
        return max(score - penalty, 1)
    else:
        return score

軽減策：長さを独立した評価基準にする

長さが暗黙に加点されないよう、独立した明示的な評価基準にします。

criteria = [
    {"name": "Accuracy", "description": "Factual correctness", "weight": 0.4},
    {"name": "Completeness", "description": "Covers key points", "weight": 0.3},
    {"name": "Conciseness", "description": "No unnecessary content", "weight": 0.3}  # Explicit
]

自己強化バイアス

問題

モデルは、異なるモデルが生成した出力よりも、自身（または類似モデル）が生成した出力を高く評価します。

軽減策：異なるモデル間での評価

生成に使用したモデルとは異なるモデルファミリーを評価に使用します。

def get_evaluator_model(generator_model):
    """Select evaluator to avoid self-enhancement bias."""
    if 'gpt' in generator_model.lower():
        return 'claude-4-5-sonnet'
    elif 'claude' in generator_model.lower():
        return 'gpt-5.2'
    else:
        return 'gpt-5.2'  # Default

軽減策：ブラインド評価

評価の前に、回答からモデルの帰属情報を削除します。

def anonymize_response(response, model_name):
    """Remove model-identifying patterns."""
    patterns = [
        f"As {model_name}",
        "I am an AI",
        "I don't have personal opinions",
        # Model-specific patterns
    ]
    anonymized = response
    for pattern in patterns:
        anonymized = anonymized.replace(pattern, "[REDACTED]")
    return anonymized

冗長性バイアス

問題

追加の詳細が無関係または誤りであっても、詳しい説明は高く評価されます。

軽減策：関連性を重視したスコアリング

async def relevance_weighted_evaluation(response, prompt, criteria):
    # First, assess relevance of each segment
    relevance_scores = await assess_relevance(response, prompt)
    
    # Weight evaluation by relevance
    segments = split_into_segments(response)
    weighted_scores = []
    for segment, relevance in zip(segments, relevance_scores):
        if relevance > 0.5:  # Only count relevant segments
            score = await evaluate_segment(segment, prompt, criteria)
            weighted_scores.append(score * relevance)
    
    return sum(weighted_scores) / len(weighted_scores)

軽減策：冗長性の減点を含む評価基準

評価基準に、冗長性に対する明示的な減点を含めます。

rubric_levels = [
    {
        "score": 5,
        "description": "Complete and concise. All necessary information, nothing extraneous.",
        "characteristics": ["Every sentence adds value", "No repetition", "Appropriately scoped"]
    },
    {
        "score": 3,
        "description": "Complete but verbose. Contains unnecessary detail or repetition.",
        "characteristics": ["Main points covered", "Some tangents", "Could be more concise"]
    },
    # ... etc
]

権威性バイアス

問題

正確さにかかわらず、自信に満ちた権威的な語調は高く評価されます。

軽減策：根拠の提示を必須にする

主張には明示的な根拠を求めます。

For each claim in the response:
1. Identify whether it's a factual claim
2. Note if evidence or sources are provided
3. Score based on verifiability, not confidence

IMPORTANT: Confident claims without evidence should NOT receive higher scores than 
hedged claims with evidence.

軽減策：ファクトチェックのステップ

スコアリングの前に、ファクトチェックのステップを追加します。

async def fact_checked_evaluation(response, prompt, criteria):
    # Extract claims
    claims = await extract_claims(response)
    
    # Fact-check each claim
    fact_check_results = await asyncio.gather(*[
        verify_claim(claim) for claim in claims
    ])
    
    # Adjust score based on fact-check results
    accuracy_factor = sum(r['verified'] for r in fact_check_results) / len(fact_check_results)
    
    base_score = await evaluate(response, prompt, criteria)
    return base_score * (0.7 + 0.3 * accuracy_factor)  # At least 70% of score

バイアスの総合的な検出

本番環境で体系的なバイアスがないかを監視します。

class BiasMonitor:
    def __init__(self):
        self.evaluations = []
    
    def record(self, evaluation):
        self.evaluations.append(evaluation)
    
    def detect_position_bias(self):
        """Detect if first position wins more often than expected."""
        first_wins = sum(1 for e in self.evaluations if e['first_position_winner'])
        expected = len(self.evaluations) * 0.5
        z_score = (first_wins - expected) / (expected * 0.5) ** 0.5
        return {'bias_detected': abs(z_score) > 2, 'z_score': z_score}
    
    def detect_length_bias(self):
        """Detect if longer responses score higher."""
        from scipy.stats import spearmanr
        lengths = [e['response_length'] for e in self.evaluations]
        scores = [e['score'] for e in self.evaluations]
        corr, p_value = spearmanr(lengths, scores)
        return {'bias_detected': corr > 0.3 and p_value < 0.05, 'correlation': corr}

まとめの表

バイアス	主な軽減策	副次的な軽減策	検出方法
位置	位置の入れ替え	複数のシャッフル	一貫性チェック
長さ	明示的なプロンプト指示	長さの正規化	長さとスコアの相関
自己強化	異なるモデル間での評価	匿名化	モデル比較調査
冗長性	関連性の重視	評価基準による減点	関連性スコアリング
権威性	根拠の提示を必須にする	ファクトチェックのステップ	確信度と正確性の相関

Claude Code 向け LLM-as-Judge の実装パターン

このリファレンスでは、開発中に Claude Code のコマンド、スキル、エージェントを評価するための実用的なプロンプトパターンとワークフローを紹介します。

パターン 1：構造化された評価ワークフロー

最も信頼性の高い評価では、懸念事項を分けた構造化ワークフローに従います。

Define Criteria → Gather Test Cases → Run Evaluation → Mitigate Bias → Interpret Results

ステップ 1：評価基準を定義する

評価の前に、明確な基準を設定します。再利用可能な形式で記録してください。

## Evaluation Criteria for [Command/Skill Name]

### Criterion 1: Instruction Following (weight: 0.30)
- **Description**: Does the output follow all explicit instructions?
- **1 (Poor)**: Ignores or misunderstands core instructions
- **3 (Adequate)**: Follows main instructions, misses some details
- **5 (Excellent)**: Follows all instructions precisely

### Criterion 2: Output Completeness (weight: 0.25)
- **Description**: Are all requested aspects covered?
- **1 (Poor)**: Major aspects missing
- **3 (Adequate)**: Core aspects covered with gaps
- **5 (Excellent)**: All aspects thoroughly addressed

### Criterion 3: Tool Efficiency (weight: 0.20)
- **Description**: Were appropriate tools used efficiently?
- **1 (Poor)**: Wrong tools or excessive redundant calls
- **3 (Adequate)**: Appropriate tools with some redundancy
- **5 (Excellent)**: Optimal tool selection, minimal calls

### Criterion 4: Reasoning Quality (weight: 0.15)
- **Description**: Is the reasoning clear and sound?
- **1 (Poor)**: No apparent reasoning or flawed logic
- **3 (Adequate)**: Basic reasoning present
- **5 (Excellent)**: Clear, logical reasoning throughout

### Criterion 5: Response Coherence (weight: 0.10)
- **Description**: Is the output well-structured and clear?
- **1 (Poor)**: Difficult to follow or incoherent
- **3 (Adequate)**: Understandable but could be clearer
- **5 (Excellent)**: Well-structured, easy to follow

ステップ 2：テストケースを作成する

複雑さのレベルごとにテストケースを構成します。

## Test Cases for /refactor Command

### Simple (Single Operation)
- **Input**: Rename variable `x` to `count` in a single file
- **Expected**: All instances renamed, code still runs
- **Complexity**: Low

### Medium (Multiple Operations)
- **Input**: Extract function from 20-line code block
- **Expected**: New function created, original call site updated, behavior preserved
- **Complexity**: Medium

### Complex (Cross-File Changes)
- **Input**: Refactor class to use Strategy pattern
- **Expected**: Interface created, implementations separated, all usages updated
- **Complexity**: High

### Edge Case
- **Input**: Refactor code with conflicting variable names in nested scopes
- **Expected**: Correct scoping preserved, no accidental shadowing
- **Complexity**: Edge case

ステップ 3：直接採点評価を実行する

単一の出力を評価するには、このプロンプトテンプレートを使用します。

You are evaluating the output of a Claude Code command.

## Original Task
{paste the user's original request}

## Command Output
{paste the full command output including tool calls}

## Evaluation Criteria
{paste your criteria definitions from Step 1}

## Instructions
For each criterion:
1. Find specific evidence in the output that supports your assessment
2. Assign a score (1-5) based on the rubric levels
3. Write a 1-2 sentence justification citing the evidence
4. Suggest one specific improvement

IMPORTANT: Provide your justification BEFORE stating the score. This improves evaluation reliability.

## Output Format
For each criterion, respond with:

### [Criterion Name]
**Evidence**: [Quote or describe specific parts of the output]
**Justification**: [Explain how the evidence maps to the rubric level]
**Score**: [1-5]
**Improvement**: [One actionable suggestion]

### Overall Assessment
**Weighted Score**: [Calculate: sum of (score × weight)]
**Pass/Fail**: [Pass if weighted score ≥ 3.5]
**Summary**: [2-3 sentences summarizing strengths and weaknesses]

ステップ 4：比較における位置バイアスを軽減する

2 つのプロンプトのバリエーション（A と B）を比較する場合は、次の 2 パスのワークフローを使用します。

パス 1（A を先に提示）：

You are comparing two outputs from different prompt variants.

## Original Task
{task description}

## Output A (First Variant)
{output from prompt variant A}

## Output B (Second Variant)
{output from prompt variant B}

## Comparison Criteria
- Instruction Following
- Output Completeness
- Reasoning Quality

## Critical Instructions
- Do NOT prefer outputs because they are longer
- Do NOT prefer outputs based on their position (first vs second)
- Focus ONLY on quality differences
- TIE is acceptable when outputs are equivalent

## Analysis Process
1. Analyze Output A independently: [strengths, weaknesses]
2. Analyze Output B independently: [strengths, weaknesses]
3. Compare on each criterion
4. Determine winner with confidence (0-1)

## Output
Reasoning: [Explain why]
Winner: [A/B/TIE]
Confidence: [0.0-1.0]

パス 2（B を先に提示）： 同じプロンプトを使い、順序を入れ替えて繰り返します。出力 B を先に、出力 A を後に置きます。

結果の解釈：

• 両方のパスで一致 → 勝者が確定し、信頼度の平均を取ります
• パス間で不一致 → 結果は TIE となり、信頼度は 0.5 です（位置バイアスを検出）

パターン 2：階層型評価ワークフロー

複雑な評価には、階層的なアプローチを使用します。

Quick Screen (cheap model) → Detailed Evaluation (expensive model) → Human Review (edge cases)

ティア 1：簡易スクリーニング（Haiku を使用）

Rate this command output 0-10 for basic adequacy.

Task: {brief task description}
Output: {command output}

Quick assessment: Does this output reasonably address the task?
Score (0-10):
One-line reasoning:

判定ルール：スコア < 5 → 不合格、スコア ≥ 7 → 合格、スコア 5-7 → 詳細評価に進む

ティア 2：詳細評価（Opus を使用）

境界的なケースには、パターン 1 の直接採点プロンプト全体を使用します。

ティア 3：人によるレビュー

信頼度の低い自動評価（信頼度 < 0.6）は、手動レビューに回します。

## Human Review Request

**Automated Score**: 3.2/5 (Confidence: 0.45)
**Reason for Escalation**: Low confidence, evaluator disagreed across passes

### What to Review
1. Does the output actually complete the task?
2. Are the automated criterion scores reasonable?
3. What did the automation miss?

### Original Task
{task}

### Output
{output}

### Automated Assessment
{paste automated evaluation}

### Human Override
[ ] Agree with automation
[ ] Override to PASS - Reason: ___
[ ] Override to FAIL - Reason: ___

パターン 3：LLM 審査員パネル（PoLL）

重大な影響を伴う評価には、複数のモデルを使用します::

ワークフロー

1. 異なるプロンプトのフレーミングで、独立した評価を 3 回実行します：

   • 評価 1：標準的な基準のプロンプト
   • 評価 2：敵対的なフレーミング（「この出力の問題点を見つけてください」）
   • 評価 3：ユーザーの視点（「開発者は満足するでしょうか？」）

2. 結果を集約します：

   • 基準ごとのスコアの中央値を取ります（外れ値の影響を受けにくい）
   • 分散が大きい（std > 1.0）基準には、レビュー用のフラグを立てます
   • 全体の合格には、過半数の合意が必要です

複数審査員向けプロンプトのバリエーション

標準的なフレーミング：

Evaluate this output against the specified criteria. Be fair and balanced.

敵対的なフレーミング：

Your role is to find problems with this output. Be critical and thorough.
Look for: factual errors, missing requirements, inefficiencies, unclear explanations.

ユーザーの視点：

Imagine you're a developer who requested this task.
Would you be satisfied with this result? Would you need to redo any work?

一致度の分析

すべての審査員による評価の実行後、一貫性を確認します。

基準	審査員 1	審査員 2	審査員 3	中央値	標準偏差
指示への準拠	4	4	5	4	0.58
完全性	3	4	3	3	0.58
ツールの効率性	2	3	4	3	1.00 ⚠️

⚠️ ツールの効率性の分散が大きい場合、その基準の定義がより明確である必要があるか、出力の効率性に曖昧な特徴があることを示しています。

パターン 4：信頼度の調整

信頼度スコアは、実際の信頼性に合わせて調整する必要があります。

信頼度の要因

要因	高い信頼度	低い信頼度
順序の一貫性	両方のパスで一致	パス間で不一致
根拠の数	具体的な引用が 3 件以上	引用が曖昧、または存在しない
基準の一致度	すべての基準が一致	基準のスコアに大きなばらつきがある
エッジケースとの一致	既知のケースと類似	未知の状況

調整プロンプトの追加

評価プロンプトに次の内容を追加します。

## Confidence Assessment

After scoring, assess your confidence:

1. **Evidence Strength**: How specific was the evidence you cited?
   - Strong: Quoted exact passages, precise observations
   - Moderate: General observations, reasonable inferences
   - Weak: Vague impressions, assumptions

2. **Criterion Clarity**: How clear were the criterion boundaries?
   - Clear: Easy to map output to rubric levels
   - Ambiguous: Output fell between levels
   - Unclear: Rubric didn't fit this case

3. **Overall Confidence**: [0.0-1.0]
   - 0.9+: Very confident, clear evidence, obvious rubric fit
   - 0.7-0.9: Confident, good evidence, minor ambiguity
   - 0.5-0.7: Moderate confidence, some ambiguity
   - <0.5: Low confidence, significant uncertainty

Confidence: [score]
Confidence Reasoning: [explain what factors affected confidence]

パターン 5：構造化出力形式

分析しやすいように、一貫した出力構造を指定します。

評価出力テンプレート

## Evaluation Results

### Metadata
- **Evaluated**: [command/skill name]
- **Test Case**: [test case ID or description]
- **Evaluator**: [model used]
- **Timestamp**: [when evaluated]

### Criterion Scores

| Criterion | Score | Weight | Weighted | Confidence |
|-----------|-------|--------|----------|------------|
| Instruction Following | 4/5 | 0.30 | 1.20 | 0.85 |
| Output Completeness | 3/5 | 0.25 | 0.75 | 0.70 |
| Tool Efficiency | 5/5 | 0.20 | 1.00 | 0.90 |
| Reasoning Quality | 4/5 | 0.15 | 0.60 | 0.75 |
| Response Coherence | 4/5 | 0.10 | 0.40 | 0.80 |

### Summary
- **Overall Score**: 3.95/5.0
- **Pass Threshold**: 3.5/5.0
- **Result**: ✅ PASS

### Evidence Summary
- **Strengths**: [bullet points]
- **Weaknesses**: [bullet points]
- **Improvements**: [prioritized suggestions]

### Confidence Assessment
- **Overall Confidence**: 0.78
- **Flags**: [any concerns or caveats]

Claude Code 開発の評価ワークフロー

ワークフロー：新しいコマンドをテストする

1. 複雑さのレベルを幅広く網羅するテストケースを 5～10 件作成します
2. 各テストケースでコマンドを実行し、出力全体を取得します
3. すべての出力をティア 1 評価で簡易スクリーニングします
4. 失敗したケースと境界的なケースを詳細に評価します
5. 失敗のパターンを特定し、プロンプトの改善に役立てます
6. 見つかった具体的な弱点に基づいてプロンプトを反復改善します
7. 同じテストケースを再評価し、改善度を測定します

ワークフロー：プロンプトのバリエーションを比較する

1. プロンプトのバリエーションを作成します（例：指示の表現を変える）
2. 同一のテストケースで両方のバリエーションを実行します
3. 提示順を入れ替えてペアごとに比較します
4. 各バリエーションの勝率を計算します
5. 各バリエーションが、どのケースをより適切に処理するか分析します
6. 判断します：勝者を選ぶか、ハイブリッドを作成します

ワークフロー：回帰テスト

1. テストスイートを維持する：代表的なケースを用意します
2. 変更前：評価を実行し、ベースラインスコアを記録します
3. 変更後：評価を再実行します
4. 比較：回帰（スコアが 0.5 を超えて低下）にフラグを立てます
5. 調査：特定のケースで回帰が発生した理由を確認します
6. 採用または差し戻し：全体的な影響に基づいて判断します

ワークフロー：継続的な品質モニタリング

1. 本番環境での使用状況をサンプリングします（可能な場合）
2. サンプルに対して軽量な評価を実行します
3. 指標を時系列で追跡します：
   • 基準ごとの平均スコア
   • 失敗率
   • 低信頼度率
4. 品質低下に対してアラートを出します：ベースラインからのスコア低下が 10% を超えた場合
5. 定期的な詳細分析：毎月、ランダムサンプルに対して詳細な評価を実施します

避けるべきアンチパターン

❌ 根拠のないスコアリング

問題：スコアに根拠がなく、デバッグが困難です 解決策：スコアを付ける前に、必ず証拠を求めます

❌ 1 回だけのペア比較

問題：位置バイアスによって結果が歪みます 解決策：必ず位置を入れ替えて、一貫性を確認します

❌ 過剰な基準

問題：複数の要素を測定する基準は信頼性に欠けます 解決策：1 つの基準につき、測定可能な側面を 1 つにします

❌ エッジケースのガイダンス不足

問題：評価者が曖昧なケースを一貫性なく処理します 解決策：明確なガイダンスを添えて、ルーブリックにエッジケースを含めます

❌ 低信頼度を無視する

問題：不確かな評価に基づいて行動すると、誤った結論につながります 解決策：信頼度の低いケースは、人間によるレビューに回します

❌ 汎用的なルーブリック

問題：汎用的な基準では、曖昧で役に立たない評価になります 解決策：分野固有のルーブリックを作成します（コードコマンド、ドキュメントコマンド、分析コマンドなど）

評価失敗への対処

評価が失敗したり、信頼性の低い結果が出たりした場合は、次の復旧方法を使用します。

不正な出力の破棄

評価者が解析不能または不完全な出力を生成した場合：

1. 無効としてマークし、分析対象から除外します - 出力が正しくない場合、通常は思考プロセス中に幻覚が発生したことを意味します

2. 変更せずに最初のプロンプトを再試行します - 複数回再試行すると、1 回だけプロンプトを実行するよりも一貫性が高くなることがよくあります

3. それでも不正な出力が生成される場合は、人間によるレビューに回します： 「評価失敗、手動確認が必要」とマークし、後で確認できるようキューに入れます

検証チェックリスト

評価結果を信頼する前に、次の項目を確認します。

• すべての基準に有効範囲（1～5）のスコアがある
• 各スコアに、具体的な証拠を参照した根拠がある
• 信頼度スコアが提示されており、妥当である
• 根拠と割り当てられたスコアの間に矛盾がない
• 加重合計の計算が正しい

評価プロンプトの検証（メタ評価）

評価プロンプトを本番環境で使用する前に、既知のケースでテストします。

キャリブレーション用テストケース

品質レベルが既知の出力を少数用意します。

テストの種類	説明	期待スコア
良好と判明しているケース	明らかに優れた出力	4.5+ / 5.0
不良と判明しているケース	明らかに質の低い出力	< 2.5 / 5.0
境界ケース	境界線上のケース	3.0-3.5、詳細な説明付き

検証ワークフロー

1. 良好と判明しているケースのテスト：明らかに優れた出力を評価します

   • スコアが 4.0 未満 → ルーブリックが厳しすぎるか、証拠要件が不明確です

2. 不良と判明しているケースのテスト：明らかに質の低い出力を評価します

   • スコアが 3.0 を超える → ルーブリックが寛容すぎるか、基準が十分に具体的ではありません

3. 境界ケースのテスト：境界線上のケースを評価します

   • 詳細な説明を伴う中程度のスコア（3.0～3.5）になるはずです
   • 確信度の高い高スコア／低スコアになる場合 → 基準に細やかさが不足しています

4. 一貫性テスト：同じ評価を 3 回実行します

   • スコアの分散は 0.5 未満である必要があります
   • 分散がそれより大きい場合 → 基準の定義をより厳密にする必要があります

位置バイアスの検証

ペア比較を使用する前に、位置バイアスをテストします。

## Position Bias Test

Run this test with IDENTICAL outputs in both positions:

Test Case: [Same output text]
Position A: [Paste output]
Position B: [Paste identical output]

Expected Result: TIE with high confidence (>0.9)

If Result Shows Winner:
- Position bias detected
- Add stronger anti-bias instructions to prompt
- Re-test until TIE achieved consistently

評価プロンプトの反復改善

キャリブレーションテストが失敗した場合:

1. 失敗モードを特定する: 厳しすぎる? 緩すぎる? 一貫性がない?
2. 特定のルーブリックレベルを調整する: 例を追加し、境界を明確にする
3. キャリブレーションテストを再実行する: 4 つのテストすべてが成功する必要がある
4. 変更を文書化する: どの調整が信頼性を向上させたかを追跡する

LLM 評価のための指標選択ガイド

このリファレンスでは、さまざまな評価シナリオに適した指標を選択するためのガイダンスを提供します。

指標のカテゴリ

分類指標

二値評価または多クラス評価のタスク (合格/不合格、正しい/正しくない) に使用します。

適合率 (Precision)

Precision = True Positives / (True Positives + False Positives)

解釈: ジャッジが良好と判断したすべての回答のうち、実際に良好だったものの割合は?

使用する場面: 偽陽性のコストが高い場合 (例: 安全でないコンテンツの承認)

再現率 (Recall)

Recall = True Positives / (True Positives + False Negatives)

解釈: 実際に良好なすべての回答のうち、ジャッジが特定できたものの割合は?

使用する場面: 偽陰性のコストが高い場合 (例: フィルタリングで良好なコンテンツを見逃す)

F1 スコア

F1 = 2 * (Precision * Recall) / (Precision + Recall)

解釈: 適合率と再現率の調和平均

使用する場面: 両方の懸念のバランスを取る単一の数値が必要な場合

一致度指標

自動評価と人間の判断を比較するために使用します。

Cohen のカッパ (κ)

κ = (Observed Agreement - Expected Agreement) / (1 - Expected Agreement)

解釈: 偶然による一致を調整した一致度

• κ > 0.8: ほぼ完全な一致
• κ 0.6-0.8: 相当な一致
• κ 0.4-0.6: 中程度の一致
• κ < 0.4: やや低い〜低い一致

使用対象: 二値判断またはカテゴリ判断

重み付きカッパ

不一致の深刻度が重要となる順序尺度の場合:

解釈: 小さな不一致よりも大きな不一致をより大きく罰する

相関指標

順序尺度または連続値のスコアに使用します。

Spearman の順位相関 (ρ)

解釈: 絶対値ではなく、順位間の相関

• ρ > 0.9: 非常に強い相関
• ρ 0.7-0.9: 強い相関
• ρ 0.5-0.7: 中程度の相関
• ρ < 0.5: 弱い相関

使用する場面: 正確な値よりも順序が重要な場合

Kendall のタウ (τ)

解釈: Spearman に似ていますが、ペアごとの一致に基づく

使用する場面: 同順位の値が多い場合

Pearson 相関 (r)

解釈: スコア間の線形相関

使用する場面: 順序だけでなく正確なスコア値が重要な場合

ペアワイズ比較指標

一致率

Agreement = (Matching Decisions) / (Total Comparisons)

解釈: 一致の単純な割合

位置一貫性

Consistency = (Consistent across position swaps) / (Total comparisons)

解釈: 位置を入れ替えると判断がどのくらいの頻度で変わるか?

選択のデシジョンツリー

What type of evaluation task?
│
├── Binary classification (pass/fail)
│   └── Use: Precision, Recall, F1, Cohen's κ
│
├── Ordinal scale (1-5 rating)
│   ├── Comparing to human judgments?
│   │   └── Use: Spearman's ρ, Weighted κ
│   └── Comparing two automated judges?
│       └── Use: Kendall's τ, Spearman's ρ
│
├── Pairwise preference
│   └── Use: Agreement rate, Position consistency
│
└── Multi-label classification
    └── Use: Macro-F1, Micro-F1, Per-label metrics

ユースケース別の指標選択

ユースケース 1: 自動評価の検証

目標: 自動評価が人間の判断と相関することを確認する

推奨指標:

1. 主要: Spearman の ρ (順序尺度の場合) または Cohen の κ (カテゴリの場合)
2. 副次: 基準ごとの一致度
3. 診断: 体系的なエラーに関する混同行列

ユースケース 2: 2 つのモデルの比較

目標: どちらのモデルがより良い出力を生成するかを判断する

推奨指標:

1. 主要: 勝率 (ペアワイズ比較から)
2. 副次: 位置一貫性 (バイアスチェック)
3. 診断: 基準ごとの内訳

ユースケース 3: 品質モニタリング

目標: 経時的に評価品質を追跡する

推奨指標:

1. 主要: 人間によるスポットチェックとのローリング一致度
2. 副次: スコア分布の安定性
3. 診断: バイアス指標 (位置、長さ)

指標結果の解釈

優れた評価システムの指標

指標	良好	許容範囲	懸念あり
Spearman の ρ	> 0.8	0.6-0.8	< 0.6
Cohen の κ	> 0.7	0.5-0.7	< 0.5
位置一貫性	> 0.9	0.8-0.9	< 0.8
長さ相関	< 0.2	0.2-0.4	> 0.4

注意すべき兆候

1. 一致度は高いが相関は低い：キャリブレーションに問題がある可能性があります
2. 順位の一貫性が低い：順位バイアスが結果に影響している可能性があります
3. 長さとの相関が高い：長さバイアスによってスコアが過大になっている可能性があります
4. 基準ごとのばらつき：一部の基準が適切に定義されていない可能性があります

レポートテンプレート

## Evaluation System Metrics Report

### Human Agreement
- Spearman's ρ: 0.82 (p < 0.001)
- Cohen's κ: 0.74
- Sample size: 500 evaluations

### Bias Indicators
- Position consistency: 91%
- Length-score correlation: 0.12

### Per-Criterion Performance
| Criterion | Spearman's ρ | κ |
|-----------|--------------|---|
| Accuracy | 0.88 | 0.79 |
| Clarity | 0.76 | 0.68 |
| Completeness | 0.81 | 0.72 |

### Recommendations
- All metrics within acceptable ranges
- Monitor "Clarity" criterion - lower agreement may indicate need for rubric refinement