第4章 評価とオブザーバビリティ

学習目標

• 課題・試行・採点器・トランスクリプト・結果を区別して、エージェント評価を設計します。
• 結果ベースの評価と軌跡評価を目的に応じて併用し、コード・モデル・人の採点器を組み合わせます。
• pass@kとpass^k、能力評価と回帰評価を運用条件に合わせて解釈します。
• トレースで失敗を段階ごとに分析し、最初の誤った判断を見つけます。
• 品質・安全性・コスト・レイテンシの指標をまとめ、デプロイの可否を判断します。

はじめに

新版のデプロイ前日、チームの評価ダッシュボードは緑色でした。応答品質スコアは4.1から4.5に上がり、エージェントは「処理が完了しました」と、より自信を持って言うようになりました。1週間後、サポート窓口には「完了と言われたのに何もできていない」という苦情が積み上がりました。評価はエージェントが何を言ったかを測り、何をしたかは測っていなかったのです。

エージェント評価が難しい理由は三つあります。同じ入力でも毎回結果が異なること、同じ目標への正しい経路が複数あること、結果が言葉ではなく世界の状態変化として現れることです。この章では、用語、結果と軌跡の採点、採点器の補正、反復実行の解釈を扱い、評価セットの管理、トレーシングによる失敗分析、指標に基づくデプロイ判断を整理します。

重要な概念

評価の基本用語

Anthropicの「Demystifying evals for AI agents」は、次の用語を使います。

最も重要な区別はトランスクリプトと結果です。トランスクリプトに「予約を完了しました」とあっても、結果に予約の行がなければ失敗です。

結果ベースの評価

結果ベースの評価は、エージェントが作った最終状態を採点します。Anthropicは、決まった手順を要求するより、結果を採点するほうが一般に適していると述べています。順序を強制すると、より効率的、または創造的な正しい解法まで減点されるからです。リサーチシステムの記事も、状態を変更するエージェントは、ターンごとの分析より最終状態の評価に集中するよう勧めています。

結果の定義には、想像以上に手間がかかります。ユーザーに残る成果物（回答、報告書ファイル）とシステム状態（台帳の行、設定）を、どちらも試行後の環境に残る結果として分けて記し、必須条件と望ましい条件を区別し、部分成功・判断保留・人への引き継ぎの数え方を定めます。禁止されたことが起きなかったかも結果の一部です。同記事は部分点も勧めています。4段階中3段階を終えたエージェントと、最初から失敗したエージェントを同じ0点にすると、改善が見えません。ただし、必須条件の違反は部分点と切り離して失敗とします。

軌跡評価

軌跡評価は、エージェントが通った経路、つまりツール呼び出しの順序と引数を見ます。結果だけではわからないことがある場合に使います。

Google ADKは二つの軸を扱います。tool_trajectory_avg_scoreはツール呼び出しの軌跡の完全一致を見て、デフォルト基準は1.0です。response_match_scoreは基準応答とのROUGE-1類似度を使い、デフォルト基準は0.8です。ROUGE-1は二つの文章で単語がどれだけ重なるかを測るため、表現が異なる正解を低く評価する場合があります。助詞や語尾が付く韓国語ではこの傾向が強まる可能性があるため、基準値はサンプルで確認してから使ってください。ADKは、LLM判定による意味一致、独自の基準表による応答品質とツール使用品質、根拠のない内容（ハルシネーション）と安全性の基準も提供します。トークン使用量やツール呼び出し数などの効率指標は値のみが報告され、合否は分けません。

三種類の採点器と組み合わせ

実務では併用します。データが変わったかはコード、報告書が有用かは基準表を使うモデル、その採点モデルが信頼できるかは人のサンプル評価で確認します。エージェントの種類によって重点も変わります。Anthropicの評価記事では、コーディングエージェントにはテスト合格などの決定的な採点が適し、調査エージェントには根拠性・網羅性・出典品質の基準表を専門家の判断で補正して使います。画面操作エージェントでは、実環境やサンドボックスでファイル・DB・注文などの意図した結果が生じたか確認します。

モデル採点器を信頼できるものにする

モデル採点器のスコアも、検証すべき測定値です。次の手順で補正します。

1. 正確性・根拠性・語調などの次元を分け、それぞれに観察可能な基準と減点例を書きます。複数次元を一つの点数にまとめると、何が問題かわからなくなります。
2. 判断材料がなければ「判断不能（Unknown）」を選べるようにします。Anthropicは、これによって採点器のハルシネーションを減らせると説明しています。
3. 専門家が採点したサンプルを作り、採点器の判定との一致度を測ります。ずれた事例を読み、基準表を修正します。
4. 定期的に再サンプリングし、一致度が維持されるか確認します。

一般的なバイアスも点検してください。長い回答を高く評価する、比較の際に先に出た側を好む、採点モデルと同系統のモデルの回答を甘く評価する、といった傾向です。ペア比較なら順序を逆にして2回採点し、長さと無関係に基準を適用できるか事例で確認します。Anthropicのリサーチシステムでは、基準表（事実の正確性、引用の正確性、完全性、出典品質、ツール効率）を含む一つのプロンプトで一度呼び出し、0.0〜1.0のスコアと合否を一緒に出す採点が最も一貫し、人の判断に近い結果でした。一度に採点しても基準表の項目は分かれていた点に注目してください。

pass@kとpass^k

• pass@k：k回のうち少なくとも一度成功する可能性。人が複数候補から選べる、または再試行できる場合に意味があります。
• pass^k：k回の試行がすべて成功する確率。毎回一度で正解すべき運用条件の一貫性を測ります。

試行ごとの成功率をpとし、試行が独立だと仮定すると、pass@k = 1 − (1 − p)^k、pass^k = p^kです。同記事の例では、試行ごとに75%なら3回すべて成功する確率は0.75³、約42%です。kが増えるほどpass@kは100%に近づき、pass^kは0%に下がります。両者が大きく離れると「できるが、信頼はできない」状態です。実際の試行は同じ課題内で相関する場合が多いため、式は解釈の手掛かりとして使い、実値は反復実行で測ります。

能力評価と回帰評価

能力評価は「このエージェントは何が得意か」を問い、低い合格率から始めるべきです。回帰評価は「以前できたことが今もできるか」を問い、ほぼ100%の合格を保つべきです。能力評価で高い合格率に安定した課題は、回帰セットへ卒業させて継続実行します。

能力評価が解決可能な全課題に合格すると、飽和（saturation）です。飽和したセットでは改善が見えず、実際はよくなっていてもスコアが同じという錯覚が生じます。飽和したら難しい課題を新設して能力セットを更新し、既存の課題は回帰セットへ移して退行を監視します。回帰セットの判定も確率的な変動を考慮します。一度の失敗ですぐ警報を出すのではなく、反復実行と失敗の重大さで判定します。

評価セットを作る

最初から数百件を集める必要はありません。Anthropicは、実際の失敗から抽出した20〜50件で開始には十分だとし、リサーチシステムも実際の利用パターンを代表する約20件のクエリから始めました。初期は変更の効果が大きく、小さなセットでも差が見えます。ただし、小さな差でデプロイを決める場合は課題と試行を増やします（「さらに深く」参照）。よい課題の条件は次のとおりです。

1. あいまいでない：分野の専門家2人が同じ合否を判定できます。
2. 基準解がある：全採点器を通過すると確認した解答があり、課題と採点器自体の成立を示せます。
3. バランスがよい：行動すべき場合と、してはいけない場合を両方入れます。そうしなければ、何でも検索するなど一方に偏った最適化が生じます。
4. 実運用から生まれた：ユーザー報告と運用上の失敗を課題に変え、セットを現実につなぎます。

何度試行しても合格率0%の課題は、エージェントの能力不足より先に、課題や採点器の欠陥を疑うよう同記事は述べています。評価セットに合わせてプロンプトとツールを直すうちに、そのセットだけに適合する可能性があるため、開発用と検証用を分け、検証用は判断時だけ使います。

評価環境の隔離と再現

毎試行、きれいな環境から始める必要があります。前の試行のファイル、データ、履歴が次の試行を容易にすると、スコアは水増しされます。Anthropicは、以前の試行のGit履歴を読んで答えを探した例を警告として挙げます。反対に、共有リソース不足で試行が失敗すればスコアは過小になります。

再現には試行条件の記録が必要です。モデルとバージョン、プロンプトとツール定義のバージョン、時刻や検索結果などの外部入力、模擬ツールか実接続かを残します。模擬ツールによる評価は速く安全ですが、実際のAPIのレイテンシ、エラー、データ変化を反映できないため、デプロイ前は実際に近い環境でも再確認します。

トレーシング

トレースは一つのワークフローの開始から終了までを表し、開始・終了時刻を持つ作業単位のスパンから成ります。スパンは親子関係でつながり、エージェント実行の下にモデル生成やツール呼び出しが付く木構造になります。

OpenAI Agents SDKはデフォルトでトレーシングが有効で、エージェント実行、LLM生成、関数ツール呼び出し、ガードレール、handoffをそれぞれスパンとして記録します。

公式ドキュメントには、OpenAI APIをゼロデータ保持（ZDR）ポリシーで使う組織は、このトレーシングを利用できないと記されています。機密データを扱うなら、構造は残し、入出力は除外またはマスクしてからエクスポートする処理器を構成してください。

MCPは、リクエストの_metaにあるtraceparent、tracestate、baggageをOpenTelemetryの追跡コンテキスト伝播用に予約しています。traceparentとtracestateはW3C Trace Context、baggageはW3C Baggage形式に従います。これにより、エージェントとMCPサーバーを一つの分散トレースにつなげられます。

何を記録するかは、答えたい問いから決めます。タスク・実行・段階・ツール呼び出しの識別子、並列分岐と引き継ぎのつながり、再試行と承認待ち、モデル・プロンプト・ツール・ポリシーのバージョンを残せば、「この失敗は、いつ、どの版のどの段階で始まったか」に答えられます。Anthropicは、運用環境に全体のトレーシングを付けつつ、個々の会話内容ではなくエージェントの判断パターンと相互作用の構造を観察したと述べています。観測データの収集範囲と保存期間も定めてください。

失敗を段階ごとに分析する

エージェントの失敗は通常、最後の段階で表面化しますが、始まりはそれ以前です。最初の日付の誤解が、3段階後に誤った予約として現れる、といった形です。最後の症状だけを直すと原因が残り、別の形で再発します。分析は次の順で行います。

1. 失敗したトランスクリプトを集め、結果（何が間違ったか）で分類します。
2. 各記録を最初から読み、最初の誤った判断を見つけます。
3. その判断を段階ごとに分類します：目標解釈、計画、検索・ツール選択、引数生成、ツール結果の解釈、検証、応答。
4. 原因をモデル・プロンプト・ツール設計・外部環境・ポリシーのいずれかと仮定します。
5. 一度に一要素だけを変え、同じ課題を再実行して仮定を確認します。

評価指標でデプロイを判断する

平均スコア一つで判断すると、重要な退行が隠れます。デプロイ判断表は、次の層で構成します。

自動評価は防御の一層にすぎません。Anthropicはこれをスイスチーズモデルにたとえています。自動評価は実利用とずれると誤った自信を与え、運用監視は事後に知らせ、ユーザーフィードバックは少なく偏り、人によるトランスクリプトのレビューには時間がかかります。どの層も完璧ではないため、重ねて互いの穴を補ってください。

さらに深く

スコアが動いたときに先に疑うこと

スコアが急落・急上昇したら、エージェントより先に測定を疑います。下がったなら、硬直した採点器が別の正解を失敗としていないか、外部環境（API応答、検索結果）が変わっていないかを確認します。不自然に上がったなら、試行間で痕跡が漏れていないか、評価セットが学習やプロンプト修正時に露出していないかを確認します。変化がなければ飽和を疑います。どちらに動いても、トランスクリプトを直接読みます。Anthropicは、多数の試行の記録と採点を読むことが、採点器の正常動作と失敗判定の公平性を確認する方法だと強調しています。リサーチシステムの試験者は、初期エージェントが権威ある出典よりも検索上位のコンテンツファームを選ぶ傾向を見つけました。これは自動採点だけでは見えにくい問題です。

サンプルサイズも見ます。25課題で4ポイントの差は、1課題の偶然の成否によるものかもしれません。同じ課題を複数回試し、版間で同じ課題セットを使い、反復実行の変動幅を上回る差か確認してから結論を出します。

対話型エージェントの評価

相談エージェントのように複数ターンで働くエージェントには、単一ターン評価では捉えられない失敗が多くあります。ユーザーが途中で依頼を変えたり、前の発言を後で覆したりする場合です。Anthropicは、こうしたエージェントの成功を、状態検査、ターン数制限、語調と品質の基準表採点を組み合わせた多次元で捉え、別のLLMにユーザーを模倣させる方法を紹介しています。Google ADKも、AIモデルがユーザー発言を動的に作って会話シナリオを試すユーザーシミュレーションと、複数ターン評価基準を提供します。会話が毎回変わるため、シミュレーションでは基準軌跡との完全一致や基準応答との比較には対応せず、複数ターンの課題成功や軌跡品質などの基準に対応すると記しています。模擬ユーザーの品質も測る必要があります。協力的すぎるシミュレーターでは、実際より簡単な試験になります。

運用から回帰事例を作る

評価セットが固定されると、実利用から徐々に離れます。運用で失敗、人への引き継ぎ、手戻りが起きた事例を定期的に抽出し、個人情報を消して再構成した後、基準解と採点器を付けて回帰セットへ入れてください。その際、入力分布の変化（新種のリクエスト増加）と性能低下（同種の失敗増加）を区別します。前者は能力セットを広げる兆候、後者は回帰を修正する兆候です。

実務の場面

もみじレンタル：「完了」と言うエージェント

家電レンタル会社「もみじレンタル」の解約相談エージェントは、解約の受け付けと製品回収の訪問予約を行います。新版はLLM採点による応対品質が5点満点で4.1から4.5へ上がりました。しかしデプロイ前のサンプル点検で、相談記録200件を予約台帳と照合すると、「返却予約が完了しました」と言った会話の6%に実際の予約がなく、2%には同じ日に2件の予約がありました。

トレースを最初から読むと、最初の誤った判断が見えました。予約なしのケースでは、予約ツールが「来週の火曜日」などの相対日付を拒否し、ツール実行エラー（isError、第2章）を返したのに、エージェントが無視して完了と言っていました。重複のケースは、タイムアウト後に同じリクエストを再送したものでした。

チームは初めに、採点プロンプトに「根拠のない完了宣言を減点」と加える案を考えましたが、却下しました。採点器は依然として会話だけを見て、状態は測れないからです。代わりに、結果採点器をコードで作りました。予約の実在、顧客の指定日との一致、重複の有無を台帳で確認し、状態と合わない完了宣言は他の点数と無関係に致命的失敗としました。語調は従来のモデル採点器で継続評価し、結果採点と分けました。予約ツールはISO形式の日付だけを受け付け、タイムアウト後は先に予約を照会するようエラーメッセージを修正しました。再構成した失敗30件は回帰セットへ入れました。

次の版は、応対品質4.4、結果基準の成功率99%でデプロイされました。チームは評価原則の一行目に、「完了宣言」と「台帳の状態」を別々に測ると記しました。

トネリコリサーチ：流暢な文章と弱い根拠

産業調査会社「トネリコリサーチ」の報告書エージェントの新版は、分量が増え、文章が滑らかになり、モデル採点器のスコアが大幅に上がりました。しかし社内研究員2人が20本のサンプルを読むと、引用した出典が主張を裏付けていない文が旧版より増えていました。

チームは一つのスコアをやめ、次元を分けました。主張単位の根拠性（各文の引用元の該当箇所がその主張を支えるか）、網羅性、出典品質、文章品質です。根拠性の採点器には「根拠不足で判断不能」を選べるようにしました。さらにサンプルを40本に増やし、研究員2人が採点して採点器との一致度を測り、一致度が低い根拠性基準には減点例を加えて2回修正しました。

デプロイ判断表は、必須合格（根拠のない主張2%以下、禁止出典の引用0件）、比較指標（課題別成功率、pass^3）、運用制約（報告書あたりのコストが旧版の1.3倍以下）で構成しました。新版は文章品質で勝りましたが、根拠性に引っかかりデプロイできませんでした。最初に誤った段階は「出典要約を主張と照合せず執筆へ進む」でした。執筆前に主張と根拠文を対応付ける段階を入れた次の版は、すべての層を通過しました。

採用しなかった案は「四次元のスコアを平均し、従来より高ければデプロイ」でした。平均すると、文章品質の大幅な改善が根拠性の退行を覆い隠すからです。

間違えやすいポイント

1. 「エージェントが完了と言ったから成功だ」 会話だけなら確実に見えますが、トランスクリプトは過程、結果は終了後の状態を記録します。状態を変えるエージェントは結果を検査します。
2. 「評価スコアが下がったから新モデルが悪い」 数字が明確なので結論を急ぎがちですが、硬直した採点器が別の正しい経路を失敗にした可能性があります。記録を読む前に結論を出してはいけません。
3. 「pass@kが高ければ運用に十分だ」 高い数字は見栄えがよくても、再試行や候補選択のない運用ではpass^kのほうが実体験に近くなります。
4. 「評価セットは数百件以上でないと意味がない」 大きいほど信頼できそうで開始を先送りしがちですが、初期は実際の失敗20〜50件でも大きな変化が見えます。まず代表性、バランス、明確さを見ます。
5. 「モデル採点器のスコアは客観的な数字だ」 自動で出るため客観的に見えますが、採点器も補正が必要な測定道具です。人のサンプル評価との一致度で検証します。
6. 「複数指標は平均して一つにすればよい」 報告は容易でも、平均は致命的な退行を隠します。必須合格条件は平均と分けます。
7. 「機密情報があればトレーシングを使えない」 危険に見えて全体を無効にしたくなりますが、構造を残し、入出力の収集を無効化またはマスクしてから出力できます。
8. 「合格率0%の課題はエージェントにできない仕事だ」 最も簡単な解釈ですが、課題や採点器の不具合を先に疑い、基準解で確認します。

ひと目でわかるまとめ

• トランスクリプトは過程の記録、結果は終了後の状態です。状態を変えるエージェントは結果で採点します。
• 軌跡検査は必須・禁止ルールと効率に限定し、全課題に完全一致を要求しません。
• コードは状態、モデルはニュアンス、人はモデル採点器の基準点を担います。
• モデル採点器では、次元の分離、判断不能の選択肢、専門家サンプルとの一致度を使います。
• pass@kは一度でも、pass^kは毎回です。独立を仮定した式は手掛かりにすぎません。
• 能力セットは低く始め、回帰セットはほぼ100%を保ちます。安定したら卒業させ、飽和したら更新します。
• 評価セットは実際の失敗20〜50件から始め、基準解、バランス、開発用・検証用の分離を備えます。
• 各試行はきれいな環境で始め、条件とバージョンを記録します。
• 失敗分析では最初の誤った判断を探し、一度に一要素だけを変えます。
• デプロイは、必須合格 → 比較指標 → 運用制約 → 判断保留の層で判断します。

公式ドキュメントで確認する

• Anthropic: Demystifying evals for AI agents — 用語、採点器の種類、pass@k・pass^k、能力・回帰評価、始め方
• Anthropic: How we built our multi-agent research system — 小規模評価セット、LLM採点、人の評価、運用トレーシング
• Google ADK: Why evaluate agents — 軌跡・応答の基準とデフォルト値、テストファイルと評価セット、ユーザーシミュレーション
• OpenAI Agents SDK: Tracing — デフォルトのスパン、無効化、統合とグループ、機密データ、処理器
• MCP 2026-07-28: Base protocol — _metaの追跡コンテキストキー
• Anthropic: Writing effective tools for agents — ツール評価指標と検証セット

セルフチェック

4-1. 予約を代行するエージェントを例に、トランスクリプトと結果（outcome）がそれぞれ何を記録するか説明してください。

4-2. 軌跡検査を設けるべき場合と設けるべきでない場合を一つずつ挙げ、理由を書いてください。

4-3. 試行ごとの成功率を0.9、試行は独立とします。pass@3とpass^3を計算し、二つの値の差が何を示すか説明してください。

4-4. モデル採点器を人の判断に合わせて補正する手順を、三段階で書いてください。

4-5. トレースとスパンの関係を説明し、一つのエージェント実行で生じるスパンの種類を三つ以上挙げてください。

4-6. 失敗したトランスクリプトで、最初の誤った判断と表面化した症状を区別すべき理由を説明してください。

4-7. 運用中のエージェントの新版に使うデプロイ判断表を設計してください。必須合格条件、比較指標、運用制約、判断保留条件を一つ以上ずつ書いてください。

実習課題