AIエージェントへ同じ依頼をしたのに、昨日は成功し、今日は途中で違うツールを呼び、もっともらしい誤回答を返した。担当者が何度かチャットして『だいたい動く』と判断しても、本番利用者の言い回しや例外条件では崩れます。この違和感は、確率的なシステムを従来の画面テストだけで評価しようとすると生まれます。
結論から言えば、AIエージェント評価では、現実のタスクを集め、同じ条件で複数回試行を実行し、最終成果と途中の実行履歴を複数の採点方法で採点します。単一の総合点を競うことが目的ではありません。どの種類の依頼に、どの失敗があり、変更後に何が良くなり何が壊れたかを再現可能にする仕組みが評価です。
最初に結論
AIエージェントの評価とは、代表的なタスク、実行条件、複数回の試行、期待結果、採点方法を固定し、最終回答・ツール操作・安全性・費用などを継続的に測る仕組みです。正解が一つの項目はコードで、説明品質はモデルまたは人で、重大な操作は実行結果とポリシーで採点し、開発時の能力評価とリリース時の回帰テストへ使い分けます。
この記事のポイント
- ・最終回答だけでなく、ツール呼び出し、データ参照、権限、失敗からの回復を含む実行履歴を評価する
- ・タスク、試行、採点方法、実行履歴、成果を分けると失敗原因を比較しやすい
- ・決定的な条件はコード、曖昧な品質はモデル、人の判断が基準になる項目は人手で採点する
- ・平均成功率だけでなく、一度でも解ける能力と、繰り返し安定して解ける信頼性を分けて見る
対象：AIエージェントや分析AIをPoCから本番へ進めたいが、デモの印象以外に品質判断の基準がない企画・開発・データ担当者
デモが成功しても本番品質とは限らない
通常のソフトウェアは同じ入力と状態なら同じ経路を通りやすい一方、LLMを含むエージェントは回答やツール選択が揺れます。また、利用者の言い換え、長い会話、権限不足、ツールエラーなど、成功までの経路が一つではありません。用意した正常系を一回通すだけでは、能力と安定性を区別できません。
もう一つの難しさは、最終文だけ合っていても過程が危険な場合があることです。分析AIが正しい売上を答えても、許可されていない顧客データを取得していたら合格にはできません。逆に、途中でクエリを修正して最終的に正しい結果へ回復したなら、不要に失敗扱いしない設計も必要です。成果と実行履歴を両方確認します。
評価を構成する5つの要素
用語を分けると、評価結果について『何を一回試し、何で判定したのか』を共有できます。組織やツールによって名称は異なりますが、次の区分を持つと設計しやすくなります。
| 要素 | 意味 | 分析AIの例 |
|---|---|---|
| タスク | エージェントへ解かせる仕事と初期状態 | 先月の売上を部門別に比較する |
| 試行 | タスクを一回実行した記録 | プロンプト、ツール呼び出し、回答、トークン、時間 |
| 採点方法 | 結果を判定する規則・評価者 | 数値一致、禁止列参照、説明の妥当性 |
| 実行履歴 | 途中の推論可能な行動履歴 | スキーマ検索、SQL、再試行、取得データ |
| 成果 | 環境に起きた最終結果 | 正しい表を返し、書込処理は行わなかった |
コード・モデル・人手の採点方法を組み合わせる
採点方式は、答えの性質に合わせます。すべてをLLMによる採点へ任せると、判定自体が揺れ、数字や権限違反を見逃す可能性があります。反対に文字列の完全一致だけでは、同じ意味の自然な説明を不合格にします。明確に計算できる条件からコード化し、残る曖昧さへモデルと人手を使います。
| 採点方法 | 向いている判定 | 長所 | 注意点 |
|---|---|---|---|
| コードベース | 数値、スキーマ、ツール、ポリシー、引用ID | 速く一貫し回帰テスト向き | 意味や説明品質は捉えにくい |
| モデルベース | 要約、根拠整合、指示遵守 | 自由文を規模化して評価できる | 判定モデルの偏りと揺れを校正する |
| 人手 | 専門判断、境界例、利用価値 | 現場の期待を最も直接反映できる | 費用が高く評価者間で差が出る |
評価データセットは現実の失敗から育てる
良い評価は大量の一般問題ではなく、自分たちのエージェントが本番で受けるタスクを代表します。最初は要件、利用者インタビュー、サポート履歴、手動テストから、重要かつ異なるタスクを集めます。正常系だけでなく、曖昧な依頼、不足情報、権限外、ツール停止、悪意ある入力も含めます。
各タスクには初期データ、利用可能なツールと権限、期待する成果、許容する回答、必須の根拠、禁止行動を記録します。モデル名やプロンプトだけでなく、ツールのバージョン、スキーマのスナップショット、時刻依存条件も固定または記録しないと、変化の原因を比較できません。
- 1. 重要な利用場面を分類する：頻度、失敗時の影響、難しさから代表タスクを選び、同じ型だけに偏らないようにします。
- 2. 期待と禁止を明文化する：正解、根拠、必要な確認質問、使ってよいデータ、絶対に行わない操作をタスクごとに定義します。
- 3. 実行環境を再現可能にする：テスト用データと権限を用意し、外部状態が変わる場合はスナップショットやモックで条件を管理します。
- 4. 複数試行を採点する：一回の偶然で決めず、必要なタスクは複数回実行して成功の分布と失敗型を確認します。
- 5. 本番の失敗を追加する：障害や低評価の会話を匿名化・再現し、修正後も残る回帰タスクへ変えます。
分析AIは数値だけでなく定義と根拠を採点する
『先月の売上は？』というタスクでは、最終数値の一致だけで合格にすると危険です。先月のタイムゾーン、売上の定義、取消や税の扱い、行レベルセキュリティが正しいかを確認します。偶然同じ数字になっても、誤ったテーブルや禁止列を参照した場合は別の採点方法で失敗にします。
分析結果の説明では、取得したデータから言える事実と、推測を分けているかも見ます。増減理由を聞かれ、データに原因を示す情報がなければ、不足を伝えて追加分析を提案するのが正解です。もっともらしい理由を創作する回答より、限界を明示する回答を高く評価します。
| 評価軸 | 確認例 | 採点方法例 |
|---|---|---|
| 数値・集計 | 期待値と許容誤差内か | SQLまたはコード |
| 意味 | 売上、期間、粒度の定義が合うか | 期待項目＋モデル＋人手 |
| 根拠 | 引用データが結論を支持するか | 参照ID検査＋モデル |
| 権限・プライバシー | 許可外の行・列を取得していないか | 実行ログとポリシールール |
| 不確実性 | 不足時に確認し、推測を区別したか | モデル用評価基準＋人手校正 |
| 操作安全性 | 読み取り依頼で書き込みツールを使わないか | ツール呼び出しのコード検査 |
pass@kとpass^kで能力と安定性を分ける
同じタスクを複数回実行すると、二つの異なる問いが生まれます。『複数回のうち一度でも成功できるか』は、エージェントに能力があるかを見る問いです。一般にpass@kは、k回の試行内で少なくとも一回成功する確率を表します。探索や研究のように再試行できる用途で参考になります。
『k回すべて成功できるか』は、繰り返し任せられるかを見る問いです。Anthropicの解説ではpass^kとして区別されています。利用者が毎朝同じレポートを作る、重要な操作を連続で行うといった用途では、一度の成功より連続成功が重要です。どちらか一つを万能なスコアにせず、製品の利用条件に合わせて報告します。
さらに平均値だけでは、頻度は低いが重大な権限違反が隠れます。安全性に関するタスクは別の合否条件とし、一件でもリリースを止める条件を事前に決めます。
能力評価、回帰評価、本番監視を分ける
開発中の能力評価は、エージェントがまだ解けない難しいタスクを含め、改善の余地を探します。回帰評価は、既に解けていたタスクがプロンプト、モデル、ツール変更で壊れていないかをリリースごとに確認します。同じデータセットを使える場合もありますが、合格基準と実行頻度が異なります。
本番監視では、事前データセットにない言い回し、外部ツールの遅延、データドリフト、利用者の満足を観測します。ただし、会話には個人情報や機密情報が含まれ得ます。評価用に保存する範囲、マスキング、保持期間、閲覧権限を決めてください。本番で見つけた失敗を安全に再現し、回帰評価へ戻す循環を作ります。
- 能力評価：新しい能力の限界と改善候補を探す
- 回帰評価：既知の成功をリリースの合否条件として守る
- 本番監視：未知の入力、データドリフト、実利用の価値を観測する
- 障害レビュー：失敗を再現可能なタスクへ変えて評価セットに戻す
スコアを上げるための評価にしない
評価データセットを何度も見ながらプロンプトを調整すると、その問題だけに適応して本番品質が上がらないことがあります。開発用と、調整に使わない検証用データを分け、タスクの言い換えや新しい実例で確かめます。また、モデルによる採点が好む文体へ最適化していないか、人手サンプルとの不一致を定期的に確認します。
評価は品質を証明する最終証明書でもありません。限られたタスクと環境で観測した証拠です。データセットが本番分布をどこまで代表するか、採点できないリスクは何かを記録し、権限、承認、レート制限、ロールバックなど実行時の防御と組み合わせます。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- Demystifying evals for AI agents — Anthropic（2026-01-09）（最終確認：2026-08-07）：タスク、試行、採点方法、実行履歴・成果、pass@k・pass^k、評価作成の実務を参照。
- Evals drive the next chapter of AI — OpenAI（2025-11-19）（最終確認：2026-08-07）：評価を能力測定、改善、リスク管理へ使う考え方を参照。
- Towards Best Practices for Automated Benchmark Evaluations — NIST（2026-01-30）（最終確認：2026-08-07）：自動ベンチマークの再現性、透明性、限界を扱う公的な推奨事項を参照。
- Evaluate Cortex Analyst accuracy — Snowflake（最終確認：2026-08-07）：自然言語分析システムの質問、SQL、結果、説明を評価する実装例を参照。
よくある質問
AIエージェントの正解が一つでない場合、どう評価しますか？
完全一致ではなく、必須要素、禁止事項、根拠、利用者にとっての成果を評価基準にします。明確な部分はコードで判定し、表現や説明は人の採点例で校正したモデルによる採点と人手レビューを組み合わせます。
LLM-as-a-Judgeだけで評価できますか？
それだけでは不十分です。自由文の評価には役立ちますが、数値、ツール呼び出し、権限違反はコードで直接確認できます。判定モデル自体の揺れや偏りもあるため、人が採点したサンプルとの一致を継続的に確かめます。
評価は何件あれば十分ですか？
用途とリスクで変わるため一律の件数はありません。まず重要な利用場面と重大な失敗型を小さく網羅し、同じ型を増やすより本番で見つかった新しい失敗を追加します。リリース判断ではタスク種別ごとの網羅範囲も併記します。
まとめと次の一歩
AIエージェント評価は単一スコアではなく、現実の仕事を再現し、最終結果・実行経路・安全性を失敗型ごとに比較する仕組みです。能力評価、回帰評価、本番監視は目的を分けます。