evaluation

このスキルを使用する場面

エージェントシステム向けの評価フレームワークを構築します

エージェントシステム向けの評価フレームワークを構築する際に、このスキルを使用してください。

エージェントシステムの評価方法

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

使用する場面

次の場合に、このスキルを有効にしてください。

• エージェントのパフォーマンスを体系的にテストする
• コンテキストエンジニアリングの選択を検証する
• 経時的な改善を測定する
• デプロイ前にリグレッションを検出する
• エージェントのパイプラインに品質ゲートを構築する
• 異なるエージェント構成を比較する
• 本番システムを継続的に評価する

コアコンセプト

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

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

パフォーマンスを左右する要因：95％という知見 Anthropic の 2025 年 6 月のエンジニアリングレポートでは、BrowseComp の分析において、3 つの要因が分散の 95％を説明したと報告されています。これはその設定で報告された関連性であり、因果関係の保証や普遍的な評価ルールではありません。

要因	説明された分散	意味
トークン使用量	80％	トークンが多いほど、パフォーマンスが向上します
ツール呼び出しとモデルの選択	報告された分析における共同要因。個別の割合は示されていません	同じ予算のもとで比較します

この知見は、評価設計に大きな影響を与えます。

• トークン予算が重要です：無制限のリソースではなく、現実的なトークン予算でエージェントを評価します
• トークンの増加よりモデルのアップグレードが効果的です：レポートでは Sonnet 4 と Sonnet 3.7 が比較されています。この比較から推測するのではなく、現在のモデルを対象のタスクで測定します
• マルチエージェントの検証：この知見は、個別のコンテキストウィンドウを持つエージェント間で作業を分配するアーキテクチャを裏付けています

詳細なトピック

評価の課題

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

解決策は、エージェントが妥当なプロセスに従いながら、適切な成果を達成したかどうかを判定する、成果重視の評価です。

コンテキストに依存する失敗 エージェントの失敗は、微妙な形でコンテキストに依存することがよくあります。単純なクエリには成功しても、複雑なクエリでは失敗することがあります。あるツールセットではうまく動作しても、別のツールセットでは失敗することがあります。コンテキストが蓄積する長時間の対話の後に、初めて失敗が表面化することもあります。

評価では、単独のクエリだけでなく、複雑さの異なる幅広い状況を対象とし、長時間の対話もテストする必要があります。

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

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

評価ルーブリックの設計

多次元ルーブリック 効果的なルーブリックは、説明的なレベルを伴う主要な次元をカバーします。

事実の正確性: 主張がグラウンドトゥルースと一致する（excellent から failed まで）

完全性: 出力が要求された側面をカバーしている（excellent から failed まで）

引用の正確性: 引用が主張された情報源と一致する（excellent から failed まで）

情報源の品質: 適切な一次情報源を使用している（excellent から failed まで）

ツールの効率性: 適切なツールを妥当な回数使用している（excellent から failed まで）

ルーブリックのスコアリング 次元の評価を、適切な重み付けを伴う数値スコア（0.0 から 1.0）に変換します。重み付けされた総合スコアを計算します。ユースケースの要件に基づいて合格しきい値を決定します。

評価方法論

LLM-as-Judge LLM ベースの評価は、大規模なテストセットにスケールし、一貫した判断を提供します。鍵となるのは、関心のある次元を捉える効果的な評価プロンプトを設計することです。

明確なタスクの説明、エージェントの出力、グラウンドトゥルース（利用可能な場合）、レベル記述を伴う評価スケールを提供し、構造化された判断を要求します。

人間による評価 人間による評価は、自動化が見落とすものを捉えます。人間は、珍しいクエリに対するハルシネーションを起こした回答、システム障害、自動評価が見逃す微妙なバイアスに気づきます。

効果的な人間による評価は、エッジケースをカバーし、体系的にサンプリングし、パターンを追跡し、文脈に沿った理解を提供します。

最終状態の評価 永続的な状態を変更するエージェントの場合、最終状態の評価は、エージェントがどのようにそこに到達したかではなく、最終状態が期待に一致するかどうかに焦点を当てます。

テストセットの設計

サンプルの選択 開発中は小さなサンプルから始めます。エージェント開発の初期には、取り組みやすい改善点が豊富にあるため、変更は劇的な影響を与えます。小さなテストセットが大きな効果を明らかにします。

実際の利用パターンからサンプリングします。既知のエッジケースを追加します。複雑さのレベル全体にわたるカバレッジを確保します。

複雑さの階層化 テストセットは複雑さのレベルにまたがるべきです: 単純（単一のツール呼び出し）、中程度（複数のツール呼び出し）、複雑（多数のツール呼び出し、大きな曖昧さ）、および非常に複雑（長時間の対話、深い推論）。

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

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

劣化のテスト 異なるコンテキストサイズでエージェントを実行することで、コンテキストの劣化がパフォーマンスにどのように影響するかをテストします。コンテキストが問題となるパフォーマンスの崖を特定します。安全な運用限界を確立します。

継続的な評価

評価パイプライン エージェントの変更時に自動的に実行される評価パイプラインを構築します。結果を経時的に追跡します。バージョンを比較して、改善またはリグレッションを特定します。

本番環境のモニタリング 対話をサンプリングしてランダムに評価することで、本番環境で評価指標を追跡します。品質低下に対してアラートを設定します。傾向分析用のダッシュボードを維持します。

実践的なガイダンス

評価フレームワークの構築

1. ユースケースに関連する品質次元を定義する
2. 明確で実行可能なレベル記述を伴うルーブリックを作成する
3. 実際の利用パターンとエッジケースからテストセットを構築する
4. 自動評価パイプラインを実装する
5. 変更を加える前にベースライン指標を確立する
6. すべての重要な変更に対して評価を実行する
7. 傾向分析のために指標を経時的に追跡する
8. 自動評価を人間によるレビューで補完する

評価の落とし穴を避ける

特定のパスへの過剰適合: 特定のステップではなく、結果を評価します。 エッジケースの無視: 多様なテストシナリオを含めます。 単一指標への執着: 多次元ルーブリックを使用します。 コンテキスト効果の軽視: 現実的なコンテキストサイズでテストします。 人間による評価の省略: 自動評価は微妙な問題を見逃します。

例

例 1：簡単な評価

擬似コード：load_rubric、assess_dimension、weighted_average の実装を用意し、重みが非負で、合計が正であることを検証します。各ルーブリックの評価項目には、それぞれ独自の weight が設定されています。評価対象から除外した人手によるラベルを用いてモデルによる判定を調整し、評価対象のテキストは不活性なデータとして扱います。

def evaluate_agent_response(response, expected):
    rubric = load_rubric()
    scores = {}
    for dimension, config in rubric.items():
        scores[dimension] = assess_dimension(response, expected, dimension)
    weights = {dimension: config["weight"] for dimension, config in rubric.items()}
    overall = weighted_average(scores, weights)
    return {"passed": overall >= 0.7, "scores": scores}

例 2：テストセットの構成

包括的な評価を確実に行うため、テストセットには複数の複雑さのレベルを含める必要があります。

test_set = [
    {
        "name": "simple_lookup",
        "input": "What is the capital of France?",
        "expected": {"type": "fact", "answer": "Paris"},
        "complexity": "simple",
        "description": "Single tool call, factual lookup"
    },
    {
        "name": "medium_query",
        "input": "Compare the revenue of Apple and Microsoft last quarter",
        "complexity": "medium",
        "description": "Multiple tool calls, comparison logic"
    },
    {
        "name": "multi_step_reasoning",
        "input": "Analyze sales data from Q1-Q4 and create a summary report with trends",
        "complexity": "complex",
        "description": "Many tool calls, aggregation, analysis"
    },
    {
        "name": "research_synthesis",
        "input": "Research emerging AI technologies, evaluate their potential impact, and recommend adoption strategy",
        "complexity": "very_complex",
        "description": "Extended interaction, deep reasoning, synthesis"
    }
]

ガイドライン

1. 単一の指標ではなく、多次元のルーブリックを使用します
2. 特定の実行経路ではなく、結果を評価します
3. 簡単なものから複雑なものまで、さまざまな複雑さのレベルを網羅します
4. 現実的なコンテキストサイズと履歴を使ってテストします
5. リリース前だけでなく、継続的に評価を実行します
6. LLM による評価を人手によるレビューで補完します
7. 傾向を検出できるよう、指標を経時的に追跡します
8. ユースケースに基づいて、合格／不合格の明確な基準を設定します

統合

このスキルは、横断的な関心事として他のすべてのスキルと連携します。

• context-fundamentals - コンテキストの利用状況を評価します
• context-degradation - 劣化を検出します
• context-optimization - 最適化の効果を測定します
• multi-agent-patterns - 連携を評価します
• tool-design - ツールの有効性を評価します
• memory-systems - メモリの品質を評価します

参照資料

内部参照資料：

• Metrics Reference - 評価指標と実装の詳細

参照資料

内部スキル：

• 品質測定のため、他のすべてのスキルが評価と連携します

外部リソース：

• LLM 評価ベンチマーク
• エージェント評価に関する研究論文
• 本番環境での監視の実践

---

スキルのメタデータ

作成日：2025-12-20 最終更新日：2025-12-20 作成者：Agent Skills for Context Engineering Contributors バージョン：1.0.0

制限事項

• このスキルは、タスクが上記の説明にある対象範囲に明確に合致する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。