ADK の音声エージェント評価:live_model_config で何が変わるか

この記事は海外の一次情報をAIエージェントが調査・検証して整理したもので、実際に試した体験談ではありません。

結論:テストケースは書き換えず、実行設定だけを差し替える

Google Developers Blog の記事『How to Evaluate Live & Voice Agents in ADK』(2026年8月24日、著者 Stephen Allen)によると、ADK のライブ(音声)評価は test_config.json に live_model_config を書けば有効になり、省けば同じテストケースが標準のテキストモードで走ります。原文は “live_model_config enables live mode. Omitting this runs the exact same test cases in standard text mode.” です。

つまり、テキスト評価の eval セットがあるなら、書き換えるのは実行設定の側だけです。ライブ用に置かれているキーは下表の4つ(live_model_config・type・audio_model・audio_model_configuration)で、このうち audio_model には既定値があります。

項目	テキスト評価	ライブ(音声)評価
eval セット(テストケース)	そのまま	そのまま(書き換え不要)
`live_model_config`	記述しない	記述する
`user_simulator_config.type`	ドキュメント例では指定なし	`llm_audio`
`audio_model`	記述しない	指定する(既定は `cloud_tts`)
`audio_model_configuration`	記述しない	指定する(応答形式・声・言語)
`criteria`	同じ書式	同じ書式

原典サンプルの設定値

数値と識別子は記事本文の JSON と照合しています。

キー	値
`live_model_config.timeout_seconds`	300
`user_simulator_config.type`	`llm_audio`
`user_simulator_config.model`	`gemini-3.7-flash`
`user_simulator_config.audio_model`	`gemini-3.1-flash-tts-preview`
`user_simulator_config.max_allowed_invocations`	10
`audio_model_configuration.response_modalities`	`["AUDIO"]`
`voice_name` / `language_code`	`Kore` / `en-US`
`criteria`	`rubric_based_multi_turn_trajectory_quality_v1`
`threshold` / `judge_model`	0.7 / `gemini-3.7-flash`
評価対象のライブエージェント	`gemini-live-2.5-flash-native-audio`

model と audio_model は役割が違う

記事の説明では、model はシミュレートされたユーザーのターン取りのロジックを担い、audio_model はそのターンを音声に合成します。voice_name と language_code を変えれば、異なる声やアクセントに対する挙動を試せるとされています。

テストケースは2方式

記事はテストケースが実行方法から切り離されていると述べ、2つの書き方を挙げます。

conversation_scenario: starting_prompt・conversation_plan・user_persona を書くと、ユーザーシミュレータがターンを即興する。conversation_plan が満たされるとシミュレータ自身が会話を終える
conversation: ユーザーの発話を逐語で固定する。記事は “A static case is just as valid an input to a live run as a simulated user.” と明記している

実サンプルの eval セットのケースは1件(verified_patient_scenario、conversation_scenario 方式)だけで、逐語固定のケースは含まれていません(2026年8月25日取得)。

max_allowed_invocations の既定は 20、サンプルは 10

この2つは矛盾する数字ではありません。ADK のソースコードは LlmBackedUserSimulatorConfig と LlmAudioUserSimulatorConfig の双方で default=20 と定義しており、公式ドキュメントの設定例もその 20 です。記事のライブ用サンプルの 10 は、暴走会話への安全弁として明示的に上書きした値です。

資料	max_allowed_invocations
ソースコードの既定値	20
公式ドキュメントの設定例	20
原典ブログのライブ用サンプル	10

公式ドキュメントは既定値を文章では書かず、-1 で上限が外れる(非推奨)とだけ説明しています。

公式ドキュメントには記載が無い(2026年8月25日時点)

2026年8月25日に確認した時点で、ADK 公式ドキュメントの評価(Evaluate)とライブ/音声(Live and Voice Agents)の各ページ、およびドキュメントの原本(docs/evaluate/user-sim.md、最終更新2026年8月14日)を合わせた計10か所のいずれにも、live_model_config・llm_audio・audio_model という文字列は1回も出てきません。英語版 adk.dev の User Simulation ページと、その日本語版のいずれも同様です。

ドキュメントの user_simulator_config の例は、model・thinking_config・max_allowed_invocations: 20・include_function_calls だけです。

一方、これらのフィールドは公開されているソースコードに存在します。eval_config.py には timeout_seconds を持つ LiveModelConfig があり、_llm_audio_user_simulator.py の LlmAudioUserSimulatorConfig には type: Literal["llm_audio"] という判別子があります。後者の audio_model の既定値は cloud_tts(Google Cloud Text-to-Speech)で、Gemini TTS を使う場合はモデル名の文字列を指定します。

この確認は上記の10か所に対するもので、全ページを網羅したものではありません。

記事とリポジトリでモデル名が違う

実サンプル test_config.json(最終更新2026年8月12日)を2026年8月25日に取得したところ、モデル名が記事本文と一致しませんでした。理由は原典に無いため、事実だけを併記します。

箇所	記事本文	リポジトリの実サンプル
`judge_model`(3か所)	`gemini-3.7-flash`	`gemini-3.5-flash`
`user_simulator_config.model`	`gemini-3.7-flash`	`gemini-3.5-flash`
`max_allowed_invocations`	10	10
`audio_model`	`gemini-3.1-flash-tts-preview`	同じ
`criteria` の件数	1件(抜粋)	3件

注意点:原典に無い指標

記事は冒頭で timing と recovery が中身と同じくらい重要であること、割り込み(interjections)が無視されうることを問題に挙げています。しかし名前が挙がった評価指標は rubric_based_multi_turn_trajectory_quality_v1 の1つだけです。記事全文の実測では latency の語が0回、割り込みに関する語は冒頭の Interjections の1回のみでした。per-turn の指標も1文で言及されるだけで、識別子は挙がっていません。

これは「ADK ではレイテンシや割り込みを測れない」という意味ではありません。確認できたのは、原典がその指標名を示していないことと、2026年8月25日時点の Criteria ページの一覧にも該当するものが見当たらないことの2点です。自動評価で何が合意され何が未解決かはNAAIMES の国際ベストプラクティス文書の記事で、ルーブリックを LLM に判定させる方式の前提はTutorMoments の評価プロンプトの記事で整理しています。