[Google ADK] 作業映像の評価をEvaluationで効率的に実行する
この記事は ADK Advent Calendar 2025/12/14担当分の記事です。
BrainPad AAA(ブレインパッドエーキューブ)の辻と申します、よろしくお願いします。
データ活用を支援するBrainPadが2025年3月にAIエージェントサービスに特化した子会社BrainPad AAAを設立しまして、そこで代表取締役 CEOを務めさせていただいています。
はじめに
2025年は様々なAIエージェントが搭載されたサービスが登場しました。Zendeskのようにチケットを一次対応してくれるものから、営業代行してくれるものまで様々なサービスが出てきた印象です。
ただ、それらのサービスの多くはその出力結果に関する品質の全てをユーザーに委ねている側面があるのもまた事実ではないでしょうか。
今後、AIエージェントサービスがビジネスで本当に普及していく上では、サービサー側がある程度、意思決定に資する情報に対する品質を担保したり、出力品質を保証する必要が出てくると考えています。
でなければ、それぞれのエンドユーザー企業が最新の生成AIのAPIを利用して自分たち(実際には個々の従業員が)で品質管理すればいいだけになってしまうので。。。
しかし、従業員による評価に頼るAIエージェントの利用方法には根本的な課題があります。
- 評価者の経験や判断基準のばらつき
- 疲労や時間制約による判断精度の低下
- コストが処理量に対して線形に増大
生成AIやAIエージェントをビジネスで人に依存しない形で利用するには、これらの問題に向き合う必要が出てきます。
本記事では、Google ADK(Agent Development Kit)のEvaluation機能の概念と、作業動画の評価を自動ベンチマークする考え方について説明していきます。
ADKのEvaluation機能によって評価・フィードバックを自動化することにより、評価の一貫性、スケーラビリティ、継続的改善のサイクルを実現する方法を探ります。
Google ADK Evaluationとは
Google ADK(Agent Development Kit)のEvaluation機能は、AIエージェントの性能を体系的に評価するフレームワークです[1]。テストケースの定義、評価関数のカスタマイズ、自動評価の実行、結果のレポート生成を統合的に提供してくれます。
素晴らしい!!
なぜ自動評価が必要か
BrainPad AAAが展開しているAIエージェントサービスCOROKOには、現場で撮影された作業動画から業務プロセスを解析して作業手順書やマニュアルを作成する機能があります。
製造現場での組み立て作業、物流センターでのピッキング作業、建設現場での安全確認——こうした「暗黙知」として個人に蓄積されている業務ノウハウやプロセスを、マルチモーダルAIエージェントにより形式知化していきます。
このようなサービスでは、「右手で部品Aを持ち、左手で部品Bを組み付ける」といった作業手順の事実性を正確に判定する必要があるのですが、先ほども述べたように、これらの要素を人間がいちいち評価・判断し続けることには大きな限界があります。
動画1本あたり10分の確認が必要だとすれば、1日1000本の処理には160時間(20人日)の評価工数がかかります。これではAIエージェントによる効率化の意味が失われます。
生成AIやAIエージェントを導入したはいいものの、ハルシネーションが発生していないかの確認に多くの時間が割かれるというのは皆さんも経験があるのではないでしょうか?
評価の一貫性の価値
評価の一貫性こそが、自動評価の最大の価値です。
「右手でドライバーを持っている」という事実の判定は、カメラアングル、照明、作業者の体格、背景の複雑さなど、多くの要因で変わります。ある評価者は「明確に持っている」と判断し、別の評価者は「持っているように見えるが確信はない」と判断するかもしれません。
自動評価は、同じ評価基準を一貫して適用し、判定の再現性を保証します。
また、ユーザーが求めるのは「生成AIのため誤りがある可能性があります」という免責ではなく、「標準的な作業環境で精度92%、手元が影になる条件では精度85%」といった具体的な性能指標です。
さらに言えば、せっかくAIエージェントを利用するのだから、インタラクティブに「何が明確になればより判断の精度を上げられるか」「断定するにはどんな情報(コンテキスト)を提供すればいいか」ユーザーに伝わるようになるべきなのかもしれません。
MMMU[2]やSWE-Bench[3]などの汎用ベンチマークは、AIモデルの一般的な能力を測るには有用ですが、「レゴブロックの組み立てにおける右手と左手の使い分け」や「配線作業での色別の識別精度」のようなドメイン特化タスクは含まれません。
自社ドメインのベンチマークを構築することで、ユーザーの関心に直接応える性能情報を提供でき、信頼性の高いサービス設計が可能になります。
ADK Evaluation Criteriaに基づく評価設計
Google ADKは、評価基準(Evaluation Criteria)を体系的に設計するためのフレームワークを提供しています[4]。これには、ルーブリック(Rubric) と呼ばれる採点基準の定義が含まれます。
ルーブリックは、評価対象の出力品質を複数のレベルに分類する基準です。作業手順の事実性評価では、以下のようなルーブリックを設計できます。
ADKが提供する評価Criteria
Google ADKは、エージェントの品質を評価するための複数のクライテリア(評価基準)を標準で提供しています。
安全性を評価するhallucinations_v1やAIエージェントのツール呼び出しが想定通りかを確かめるtool_trajectory_avg_scoreなど複数の評価軸が用意されています。
主要Criteriaの比較
使い分けをもう少しだけ比較表にして記載しておくと、以下のように整理できます。
| クライテリア | 手法 | 参照必要 | LLM使用 | 用途 |
|---|---|---|---|---|
response_match_score |
ROUGE-1類似度 | ✅ | ❌ | 回答の表面的一致度 |
tool_trajectory_avg_score |
ツール呼び出し順序比較 | ✅ | ❌ | ワークフロー検証 |
final_response_match_v2 |
意味的等価性判定 | ✅ | ✅ | セマンティックな正確性 |
rubric_based_final_response_quality_v1 |
ルーブリック評価 | ❌ | ✅ | 品質の多面的評価 |
さらなる詳細は、以下で確認できます。
COROKOが採用しているCriteria
作業動画の解析という特性上、我々のサービスではルーブリックベースのLLM-as-Judge評価(rubric_based_final_response_quality_v1)を採用しています。
作業説明は自由記述形式であり、表面的な文字列一致では品質を測れない 「正確性」「詳細度」「時系列把握」 など複数の観点からの評価が必要だからです。
*作業動画での動作解析は原理的にはリファレンスを用意して正解データと不正解データを明確に用意することは可能ではあります。
複数軸の平均スコアが総合評価となり、例えば「物体識別は高精度(平均3.92)だが、動作識別に課題あり(平均2.68)」といった分析が可能になります。
↓こちらのCOROKOのデモ画面のように作業動画の内容が分割されてAIエージェントが自動記述してくれるというのは作業手順書を作成する側からすると大変嬉しいことだと思います。

しかし、記載されているタイトルや説明内容を複数の観点で全て人間が(まして超忙しいベテランや現場監督者が!!)確認していくというのは非常に手間のかかることなので、このAIエージェントの出力の確認にかかる認知負荷と修正するための作業負荷をユーザーに確認してもらう前の自動評価でどれだけ潰せるかが非常に重要になってきます。
Ground Truthの重要性
評価を行うには、正解データ(Ground Truth) が不可欠です。
これは単なる「正解ラベル」ではなく、評価の基準そのものです。Ground Truthの品質が、評価システム全体の信頼性を左右するのでこのGround Truthと呼べるものをいかに効率よく収集できるかがサービスの品質を決めるとも言えると考えています。
Ground Truthの作成にはドメイン知識が要求されることが多いのもまた事実です。作業の熟練者が実際の動画と説明文を見て修正・承認してもらうことで質の高いGround Truthを構築できます。
一度作成すれば、何千回でも再利用できる資産になるため、以下にレビューをする側の認知負荷と作業負荷を下げながらGround Truthを蓄積していくかもサービスの品質を分ける点になり得ます。
Video Work Analysis Agent
ここからは、COROKOで採用しているAIエージェントを説明用に修正した作業映像解析エージェント「Video Work Analysis Agent」の設計と実装について説明しながらADKのEvaluation機能を実装していきます。
アーキテクチャ
本記事では、2種類のエージェントアーキテクチャを実装し、比較評価を行うアプローチを採用しました。
Agent A 前処理ありエージェント(preprocessed_analyzer)
設計思想としては、複雑なタスクを小さなサブタスクに分解し、段階的に処理することで精度向上を狙っているエージェントであり、サブエージェントを複数用意。
- Google ADKのSequentialAgentを使用して3つのサブエージェントを順次実行(本当は別にSequentialでなくてもいいのだが)
- 各サブエージェントが専門的な役割を担当
- 中間結果を次のエージェントに引き継ぐパイプライン構成
Agent B 直接解析エージェント(direct_analyzer)
設計思想としては、 Geminiなどのマルチモーダル推論能力を最大限活用し、シンプルかつ高速に処理するエージェント。
- 単一のAgentで映像から直接作業説明を生成
- 前処理のオーバーヘッドがなく高速
- LLMの推論能力に依存したエンドツーエンドアプローチ
ルーブリックの定義
ルーブリックは、評価設定ファイルである EvalConfig 内にリスト形式で定義されます。
具体的には、JSON形式のデータ構造として記述され、各ルーブリックには「一意のID」と「評価基準となるテキスト記述」を含める必要があります。
作成形式と構成要素
ルーブリックは以下のフィールドを持つオブジェクトとして定義します。
-
rubric_id- そのルーブリックを識別するための一意のID(例:
"conciseness","direction")
- そのルーブリックを識別するための一意のID(例:
-
rubric_content- ルーブリックの内容を格納するオブジェクト
-
text_property- エージェントの応答やツール使用が満たすべき具体的なルールや性質を記述したテキスト(例: "The agent's response is direct and to the point.")
記述例
以下は、EvalConfig ファイル内で rubric_based_final_response_quality_v1(最終応答の品質評価)のためにルーブリックを定義する際の記述例です。
{
"criteria": {
"rubric_based_final_response_quality_v1": {
"threshold": 0.8,
"judge_model_options": {
"judge_model": "gemini-2.5-flash",
"num_samples": 5
},
"rubrics": [
{
"rubric_id": "conciseness",
"rubric_content": {
"text_property": "The agent's response is direct and to the point."
}
},
{
"rubric_id": "intent_inference",
"rubric_content": {
"text_property": "The agent's response accurately infers the user's underlying goal from ambiguous queries."
}
}
]
}
}
}
テストケースの基本構造
Google ADKでは、エージェントの単体テスト的なシンプルなテストケースとして、*. test.jsonファイルを使用してエージェントの評価を行います。マルチターンのような長期的・結合テスト的な評価は、*.evalset.jsonを用意して検証を行います。
エージェントの比較結果
では、実際にAgent AとAgent Bをそれぞれ用意したテスト作業映像に対して推論させてみて結果を比較してみます。
採用したルーブリック
今回のエージェントの評価は、以下の4つの観点で構成されており、このルーブリックの平均点を複数のテストケースに通してみて結果を比較します。(今回は3つのテストケース)
① 正確性 (Accuracy) 「何をしたか」
- 作業の種類(組立・検査等)や対象物を正しく認識できているか、事実に基づいた記述ができているかの基本評価
② 詳細度 (Detail) 「どのようにしたか」
- 「右手か左手か」「どの位置で」といった、単なる動作以上の細かいニュアンスや空間情報を捉えられているかを評価
③ 時系列把握 (Chronology) 「いつ、どの順序か」
- 動作の開始・終了タイミングや、複数の工程の前後関係が正しく構成されているかを見ます。
④ 簡潔性 (Conciseness) 「読みやすいか」
- 情報の密度を保ちつつ、冗長な表現を避けて構造化されているかを評価します。
結果比較
3つのテストケースとしては、レゴブロックを持ち上げるような単純なテスト動画や部品を組み上げる動画などを用意して比較してみています。
| テストケース | Agent A (preprocessed_analyzer) | Agent B (direct_analyzer) | 差分 |
|---|---|---|---|
| case_001_simple_pickup | 3.5 | 3.4 | +0.1 |
| case_002_two_hand_assembly | 3.5 | 3.1 | +0.4 |
| case_003_rotation_work | 3.5 | 3.4 | +0.1 |
| 平均 | 3.5 | 3.3 | +0.2 |
結果としては、サブエージェントを用意して手の位置や作業内容を事前に構造化して作業説明をさせたAgent Aの方が好ましい結果を得ていることが確認できました。
今回はあくまで、ADKのEvaluation機能を説明するために実施したパターンに過ぎないので、テストケースを増やしたりエージェント側のアーキテクチャを変更したら同じような結果になるかは分かりません。
ただ、上記のような結果を得るために、人間が動画をいちいち確認しながら、「時系列的な順序は合っているか」、「右手でちゃんと部品を持ち上げているか」なんてことを評価しなくてよくなるというのは継続的なサービス品質の評価においては極めて重要です。
まとめ
AIエージェントサービスの成長にはAIエージェントの成果に対する評価の自動化が不可欠だと言えます。評価・検証されて基準をクリアしたものだけが、次の工程に渡される(顧客に届けられる/検収される)からです。
人間による評価は信頼性の基準を提供しますが、スケールさせるのが極めて困難であるため、ドメインに特化したベンチマークを構築し、継続的に性能をモニタリングすることで、サービスの信頼性を高め、サービスの価値そのものを決めることにつながります。
Google ADK自体がGoogle Cloudに最適化された形で発展しておりAgent Engineなどのマネージドサービスもすぐに利用できるため、BrainPad AAAではADKを軸にAIエージェント開発を進めていますが、その中でもこのEvaluationは、ドメイン特化ベンチマークを効率的に構築するためのカギとなっています。
ADK自体2週間に一度アップデートがあり、活発に発展しているAIエージェントフレームワークですが、Evaluation機能についてもさらなる発展にも期待しています。
おしまい
-
Google ADK Documentation: https://google.github.io/adk-docs/evaluate/ ↩︎
-
MMMU (Massive Multi-discipline Multimodal Understanding): https://mmmu-benchmark.github.io/ ↩︎
-
SWE-Bench (Software Engineering Benchmark): https://www.swebench.com/ ↩︎
-
Google ADK Evaluation Criteria: https://google.github.io/adk-docs/evaluate/criteria/ ↩︎
Discussion