音声AIエージェントは正答率だけで選んでよいのか——50シナリオ・20システムの評価が示したもの

音声AIエージェントは「用件を処理できたか」だけで選ぶと不足します。ServiceNowが公開した評価フレームワークEVAでは、評価された20システムのすべてで、精度が高い構成は会話体験が悪く、その逆も成立するというトレードオフが観測されました。正答率と会話の質は、別々に測る必要があります。

EVAは何をどう測ったのか（一次資料の実測値）

ServiceNowのServiceNow-AIチームが2026年3月24日にHugging Faceブログで公開した記事で、音声エージェント評価フレームワーク「EVA（Evaluating Voice Agents）」が発表されました。ブログ本文に記載されている構成と数値は次のとおりです。

項目	数値	条件
評価シナリオ数	50シナリオ	航空会社（airline）1ドメインのみ、英語のみ
エージェントが呼び出せるツール数	15ツール	同じ航空会社ドメインのシナリオ群に紐づくAPI
評価された音声エージェント構成数	20システム	商用（プロプライエタリ）とオープンソースの両方を含む
1シナリオあたりの試行回数	k = 3	pass@k（3回中1回でも成功）と pass^k（3回すべて成功）の両方を報告
主要評価指標	2種（EVA-A / EVA-X）	上記50シナリオ×20システムの評価に適用
フレームワークの構成要素	5構成要素	ユーザーシミュレータ／音声エージェント／ツール実行部／検証器／メトリクス群によるbot-to-bot音声アーキテクチャ。条件の記載なし

2種のスコアの中身は分かれています。EVA-Aはタスク完了・忠実性・発話の正確さ、つまり「用件を正しく処理できたか」。EVA-Xは簡潔さ・会話の進行・ターンテイキング、つまり「会話として気持ちよく成立したか」です。同じ通話を、達成と体験という別々のものさしで採点する設計になっています。

（出典：ServiceNow（ServiceNow-AI チーム。中核執筆者として Tara Bogavelli、Gabrielle Gauthier Melançon、Katrina Stankiewicz ほかを明記）、2026-03-24、https://huggingface.co/blog/ServiceNow-AI/eva）

ここで先に明記しておきます。この記事はServiceNow社自身による発表であり、同社はEVAフレームワーク本体（サイト・GitHubリポジトリ・Hugging Faceデータセット）の提供者です。評価の枠組みを作った側が、その枠組みで測った結果を紹介している構図になります。数字そのものは検証可能な形で公開されていますが、「何を測る価値がある指標とみなすか」という設計判断そのものが提供者側にある点は、読む側が織り込む必要があります。

「精度と体験のトレードオフ」という不都合な結果

EVAの報告で最も重いのは、20システムのすべてで精度と体験のトレードオフが観測されたという点です。精度の高いエージェントは会話体験が悪く、会話体験の良いエージェントは精度が落ちる。両立できた構成は示されていません。

直感的には理解しやすい結果です。用件を確実に処理しようとすれば、確認の復唱が増え、聞き直しが増え、発話が長くなります。逆に会話をテンポよく進めようとすれば、確認を省き、聞き取れた前提で先に進むことになります。人間のオペレーターが日々やっている調整を、現在の音声エージェントはまだうまくやれていない、と読めます。

中小企業の側から見ると、これは「デモで気持ちよく喋るエージェントほど疑え」という警告でもあります。ベンダーのデモは会話体験を見せる場です。EVA-X側だけが良い構成を、EVA-A側も良いはずだと錯覚したまま導入すると、実運用で予約内容の取り違えや聞き漏らしが出ます。

pass@k と pass^k を分けて見る意味

EVAは1シナリオあたり3回試行し、pass@k（3回中1回でも成功）と pass^k（3回すべて成功）の両方を報告しています。この2つを分けることが、実務では効きます。

pass@k は「うまくいくことがある」を測る指標です。デモで見せられるのはたいていこちら側です
pass^k は「毎回うまくいく」を測る指標です。電話の一次対応で本当に必要なのはこちらです
3回中1回失敗するエージェントは、月100件の入電なら約33件を落とす計算になります（記事に実測の入電件数はなく、これは考え方の説明です）

顧客対応の自動化を検討する際の考え方はAIで顧客対応をどこまで任せられるのかでも整理していますが、音声はテキストと違って「聞き返し」のコストが人間側にかかります。1回で通らない体験の悪さは、テキストチャットより重く効きます。

中小企業が自社で真似できる評価手順

EVAそのものを動かすには商用APIへのアクセスが必要で、レイテンシ計測もインフラ環境によって変動します。中小企業がフレームワークをそのまま導入する話ではありません。ただし、考え方は自社の選定にそのまま移植できます。

自社の想定シナリオを数十本、実際の応対内容から書き出す（EVAは50シナリオで構成されています）
エージェントに触らせる社内システム・予約システムの操作を洗い出す（EVAは15ツールを定義しています）
同じ台本で複数回、同じ質問を投げる（EVAはk=3で試行しています）
「用件が処理できたか」と「会話が快適だったか」を別々の欄で採点する（EVA-A／EVA-Xの分離に相当）
3回すべて成功した割合を、候補ベンダーごとに並べて比較する

評価軸を自社で持つこと自体の重要性はAI導入で自社の評価基準をどう作るかで扱っています。EVAが示したのは、その評価軸を音声では最低2本に割る必要がある、ということです。

なお、音声AIの比較では文字起こし（ASR）側の精度も別途効きます。この観点は音声の文字起こしをAIに任せる際の実務、および音声モデルを多軸で比較した音声AIの「人間らしさ」は40以上のモデル比較でどこまで測れたのかと併せて読むと、評価の全体像が見えます。

この評価が担保していないこと

EVAの限界は、著者自身がブログ内で列挙しています。日本の中小企業が読む場合、限界のほうが本文より重要です。

検証は航空会社という単一ドメイン・英語50シナリオのみで、他業種や日本語への一般化は担保されていません。日本語の敬語・曖昧な言い回し・方言が絡む応対で同じ順位になる保証はありません
評価にLLM-as-judge（判定を大規模言語モデルに行わせる方式）を用いており、判定モデル自体のバイアスが結果に混入することを著者が認めています
タスク完了の判定が二値で、部分的な達成（部分点）を捉えられません。「日付は取れたが便名を取り違えた」は、完全な失敗と同じ扱いになります
音声合成（TTS）が単一プロバイダのため、特定の音声認識（ASR）システムに系統的に有利に働く可能性があります
ユーザーシミュレータは言い淀み・ためらい・感情といった実際の人間の発話特性を十分に再現できていない可能性があります。実際の電話は、この「うまく喋れない人間」への対応がそのまま品質になります
実行には商用APIへのアクセスが必要で、レイテンシ計測はインフラ環境によって変動します

つまりEVAは「この順位のエージェントを買え」という表ではなく、「音声エージェントは2軸で、複数回、シナリオベースで測れ」という手順の提案として読むのが正確です。

TOEの読み筋

TOEでは、EVAフレームワークを用いた音声エージェントの評価は未実施です。以下は一次資料を読んだうえでの解釈であり、自社実測に基づく主張ではありません。

読み筋は3つです。

第一に、音声AIの提案を受けたら「pass^k相当の数字はありますか」と聞くのが、最も安く効く質問になります。3回中3回成功した割合を出せるベンダーは、自社で反復検証をしている可能性が高い。出せないベンダーは、デモの一発勝負を見せている可能性が高い。この質問はゼロコストで、相手の検証体制を測れます。

第二に、精度と体験のトレードオフが避けられないなら、どちらに寄せるかは業務側で先に決めるべきです。予約変更や金銭が絡む一次対応なら精度側、営業時間案内や在庫確認のような取り違えても被害が小さい用件なら体験側。同じ会社の中でも、用件ごとに別のエージェントを割り当てる設計はあり得ます。

第三に、日本語での検証が公開されていない以上、自社シナリオでの試行は代替不可能です。英語の航空会社ドメインで良かった構成が、日本語の受発注電話で同じ順位になるという根拠は、この一次資料からは得られません。導入前に自社台本での反復試行を回すこと自体が、現時点では最も確度の高い判断材料になります。

まとめ

ServiceNowのEVAは、航空会社1ドメイン・英語50シナリオ・15ツール・20システムを対象に、音声エージェントを精度（EVA-A）と会話体験（EVA-X）の2軸で評価したフレームワークです（出典：ServiceNow、2026-03-24）
評価された全構成で、精度が高いと体験が悪く、その逆も成立するトレードオフが観測され、両立した構成は示されていません
1シナリオあたりk=3で試行し、pass@k（3回中1回成功）とpass^k（3回すべて成功）を分けて報告しています。実務で必要なのは後者です
この記事はServiceNow社自身による発表であり、同社はEVAフレームワーク（サイト・GitHubリポジトリ・Hugging Faceデータセット）の提供者です
単一ドメイン・英語のみ、LLM-as-judgeのバイアス、タスク完了判定が二値、TTSが単一プロバイダといった限界を著者が明示しており、日本語の自社業務への一般化は担保されていません。TOEでもEVAによる評価は未実施です