Skip to Content
Docs04. 評価ユーザーシミュレータの設計
上級evaluationuser-simulator更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

ユーザーシミュレータの設計

この記事の目的

対話型 Agent の評価に「ユーザー役の LLM(ユーザーシミュレータ)」を使う際の、シミュレータの設計と信頼性の検証ができるようになります。1 往復の入出力では測れないマルチターン対話の品質を、人手を毎回介さずにスケールして評価できる状態がゴールです。

対象読者

  • 複数ターンの対話で成立する Agent(サポート・予約・相談など)を評価したいエンジニア
  • ユーザー役を LLM に任せたいが、その結果を信じてよいか不安なエンジニア

前提知識

本文

概要: 相手役と審判役は別コンポーネント

対象正本本記事
何を測るか(評価対象・採点)Agent 評価の基礎—
出力を採点する判定器(judge)LLM-as-a-Judge—
評価を動かす環境エージェント評価環境の構築—
ユーザー役 LLM の設計と検証本記事構成・暴走抑制・シナリオ・品質検証・盲点

対話評価には 2 つの LLM 役が登場します。**相手役(ユーザーシミュレータ)**は Agent と会話してタスクを進めさせる役、**審判役(judge)**は会話の結果を採点する役です。この 2 つは別コンポーネントで、本記事は相手役を扱います(審判役は LLM-as-a-Judge が正本)。公開ベンチマークでも、ユーザーシミュレータと会話させ、終了時の状態を検証する設計が使われています(τ-bench 等。エージェントベンチマークの全体像)。

シミュレータの構成

ユーザーシミュレータは、「もっともらしい人間」ではなく評価目的に沿った振る舞いを持たせて設計します。構成要素は次のとおりです。

  • ペルソナ: 誰か(初心者/熟練者、丁寧/ぶっきらぼう)。Agent が多様なユーザーに対応できるかを測ります
  • 目標(ゴール): このユーザーは何を達成したいか。評価は「その目標が達成されたか」で採点できます(エージェント評価環境の構築の終了状態検証)
  • 知識・持ち情報: ユーザーが最初から知っていること・持っている情報(予約番号など)。Agent が聞いたら答える、聞かれるまで出さない、を制御します
  • 忍耐度・振る舞い: どれくらいで諦めるか、要求をどれだけ小出しにするか。曖昧な依頼・情報の後出しといった実ユーザーの難しさを再現します
  • 口調: 表現の多様性。Agent が言い回しの揺れに頑健かを測ります

「情報を小出しにする」「曖昧に依頼する」といった意地悪さは、意図的に設計します。協力的すぎるシミュレータは、Agent を甘く評価します。

暴走の抑制: シミュレータを縛る

ユーザー役の LLM を自由にすると、評価にならない挙動をします。目標から逸れて雑談を始める、Agent の答えに何でも満足してしまう、逆に永遠に満足しない、といった暴走です。

  • 目標と終了条件で縛る: 「この情報が得られたら会話を終える」「これ以上は要求しない」を明示します。満足の基準をシミュレータ任せにしないことです
  • 持ち情報と発話を検証する: ユーザーが答えてよい情報を固定データとして与えます。プロンプトだけで事実の捏造を防げるとは限らないため、予約番号・選択肢など検証可能な項目はコードで照合し、違反した対話はシミュレータ失敗として分けます
  • ツール・行動を制限する: シミュレータにできることを、評価に必要な発話だけに絞ります
  • 公開ベンチマークの知見: τ-bench の原論文 Section 3 では、ユーザー役 LLM は初期シナリオと会話履歴から発話し、Agent のツール通信は見ません。ドメイン API・DB を操作するのは評価対象 Agent です。採点側は終了時の DB 状態と必要な回答内容を正解と照合します。「ユーザー役を API で制約する」仕組みではなく、相手役・業務環境・採点を分離した設計です

自分の評価でユーザー発話をより厳密に制約するなら、許容される選択肢や状態遷移をコード側で定義し、発話中の事実を検証します。自由文のすべてを機械検証できるわけではないため、抜き取りの人手確認も残します。初期状態を固定しても LLM の発話には揺らぎがあり、反復実行とシミュレータ失敗の集計が必要です。

シナリオ生成

シミュレータに与える「ペルソナ + 目標 + 持ち情報」の組がシナリオです。シナリオ集合の設計が、評価のカバレッジを決めます。

  • 分布を設計する: 正常系だけでなく、曖昧な依頼・情報不足・要求変更・拒否すべき依頼を混ぜます(Agent 評価の基礎の分布設計)
  • エッジケースを意図的に混入する: 「必要な情報を持っていないユーザー」「途中で気が変わるユーザー」など、Agent が詰まりやすいシナリオを明示的に作ります
  • 実ログから作る: 実際のユーザー対話ログから、代表的・困難なシナリオを抽出します(想像で作ると実態より簡単になります)

シミュレータ品質の検証

シミュレータ自身が信頼できるかを検証しないと、評価結果を信じられません。

  • 人間対話ログとの乖離を測る: シミュレータの生成する対話が、実際の人間の対話とどれだけ違うかを確認します。人間なら聞くことを聞かない、人間はしない発話をする、といった乖離があれば、評価は実態を代表しません
  • 既知の良し悪しで検定する: 明らかに良い Agent と悪い Agent をシミュレータで評価し、期待どおりの差が出るかを確認します。差が出ないなら、シミュレータが評価を弁別できていません
  • judge の検証と同じ規律: シミュレータも judge も「評価の道具」であり、道具自体を検証してから使うのが原則です(LLM-as-a-Judgeの judge 検証と同型)

落とし穴

実務での注意点

アンチパターン

  • 協力的すぎるシミュレータで評価する → Agent を甘く評価し、実ユーザーで崩れる → 情報の後出し・曖昧な依頼など意地悪さを意図的に設計する
  • シミュレータの満足基準を LLM 任せにする → 何でも満足する/永遠に満足しない暴走で評価にならない → 目標・終了条件・持ち情報を状態で縛る
  • シミュレータ自体を検証せずに使う → 実態と乖離した対話で測り、結果を誤信する → 人間ログとの乖離・既知の良し悪しでの弁別を確認する
  • シミュレータと Agent を同系モデルにする → 盲点を共有し、その弱点が評価で見えない → 別系統のモデルを使う
  • 1 つのシミュレータでスコアを上げ続ける → そのシミュレータへの過適合で実ユーザーに効かない → 実ユーザー検証を併用し、シミュレータを固定しすぎない

チェックリスト

  • シミュレータにペルソナ・目標・持ち情報・忍耐度・口調を設計している
  • 情報の後出し・曖昧な依頼など、意図的な難しさを組み込んでいる
  • 目標・終了条件・持ち情報を与え、検証可能な発話・状態遷移をコードで確認している
  • ユーザー役の出力、Agent のツール操作、終了状態の採点を区別し、シミュレータ失敗を別集計している
  • シナリオの分布(正常系・曖昧・情報不足・拒否すべき)を設計している
  • シミュレータの対話を人間ログと突き合わせ、乖離を確認した
  • 既知の良い/悪い Agent で、シミュレータが弁別できることを確認した
  • シミュレータと被評価 Agent が同系モデルによる盲点共有になっていない

関連トピック

参考資料

TODO・未確認事項

なし

エージェント評価環境の構築信頼度と較正(calibration)