ADK の評価セットでエージェントを手元で採点する — デプロイ先の選び方は公式資料で整理する

Google Cloud の Professional Agentic Architect では、試験ガイドの §4「Evaluating and deploying agentic workflows」が出題の約 22% を占める（2026 年 10 月時点の英語の試験ガイド）。評価の道具の例として、Google が Apache 2.0 で公開している Agent Development Kit（ADK）が名指しされている。そこで ADK の評価を手元の PC と手元のモデルで回し、何が見つかり、何が見逃されるかを確かめた。当サイトはこの試験を受験していない。

※本記事にはアフィリエイト広告（PR）が含まれます。

対象は、ADK のエージェントを手元の PC で書いて動かす — 出題の3割を占めるカスタムエージェントを Google Cloud なしで練習する（2026-10-21 公開） で動かした、ツール3つ（フィラメントの在庫・プリンターの状態・予約）を持つエージェントである。これに5問の評価セット（期待するツールの呼び出しと参考の答えを書いた JSON。ADK の用語では evalset）を書き、ADK Python v2.11.0 の CLI で評価した。さらに、わざと壊したエージェントを3つ用意した。確認を飛ばして予約するもの、毎回余分に在庫を呼ぶもの、状態のツールを外したものだ。壊れたものを評価が見つけられるかを確かめる陰性対照である。

先に結果を書く。この実行では、余分な呼び出しを見つけたのは既定の照合方法である EXACT だけだった。余分な呼び出しを許す IN_ORDER と ANY_ORDER は、「ツールを呼ばないのが正解」のあいさつで余分に呼んでも満点の 1.0 を付けた。状態のツールを外したエージェントは、状態のツールを使う3問のうち2問で EXACT を通った。呼び出しの名前と引数が期待と同じだったためで、照合は呼び出しが成功したかを見ていない。応答の照合に決まった文の組を入れて計算すると、意味が逆の文が 0.772、言い換えた文が 0.464 となり、逆の文の方が高い値になった。

後半では、§4.2 のデプロイ先の選び方（Agent Runtime・Cloud Run・GKE）と障害の切り分けを、公式資料の整理として書く。当サイトはデプロイしていない。また、手元の練習は試験の実技ラボの代わりにはならない。試験の全体像と準備の計画は Google Cloud の Professional Agentic Architect は何を証明する資格なのか — 11月の一般提供までに準備する4週間の全体設計（2026-10-19 公開） にまとめた。

試験ガイドの §4 が求めていること — 評価の4項目とデプロイの3項目

§4 は2つの節からなる。4.1「Evaluating agents in development and in production.」は開発中と本番での評価を、4.2「Deploying and scaling production workloads.」はデプロイと運用を扱う。4.1 の項目は次の4つで、英語は試験ガイドの書き出し、日本語はその要約である。

1. 「Creating test sets for agent evaluation」: 評価用のテストセットを作る。例に golden data（正解のデータ）、プロンプト、境界の例（edge cases）が挙がる
2. 「Creating continuous evaluation pipelines」: 決めた成功の基準で、エージェントのツールの実行を継続的に評価する仕組みを作る
3. 「Determining the appropriate evaluation framework and tooling」: 評価の枠組みと道具を選ぶ。例は ADK の評価の道具（evalset）、Agent Platform の Gen AI evaluation service、custom autoraters
4. 「Evaluating an agentic system against a golden dataset」: 正解のデータセットに照らして、応答と検索の質を評価する。例は ADK

ここでの Agent Platform は、Google Cloud の Gemini Enterprise Agent Platform を指す。4.2 の項目は3つある。用途・要件・費用からデプロイ先（Agent Runtime、Cloud Run、GKE）を選ぶこと、エージェントの障害（drift、ツール呼び出しの遅延、推論のループ、システムの障害）を切り分けること、性能・信頼性・費用の面で監視して最適化することだ。

この7項目のうち、本記事が手元の ADK で練習したのは 4.1 の1・3・4 の一部である。テストセットを書き、評価を回し、結果を読むところまでは、Google Cloud のアカウントなしでできた。

4.1 の2の継続的な評価は、手元の評価を CI（変更のたびにテストを自動で回す仕組み）などで繰り返し回す形でも組める。ADK の文書も、pytest で書いた評価を CI/CD のパイプラインに組み込めると書いている。ただし本記事では、その仕組みまでは組んでいない。一方、本番のトレースを採点する Agent Platform の Online monitors と、4.2 の多くは、デプロイしたエージェントと Google Cloud の観測の仕組みが前提になる。そこで以下では手元で回した範囲を先に書き、クラウドが要る範囲を後半に分けた。

本記事の評価セットと境界の例は当サイトが作ったもので、試験の問題ではない。出題範囲の製品の名前の変遷（Agent Runtime は旧 Agent Engine、など）は、Agentic Architect の出題範囲の新しい製品を AI はどこまで知っているか — 試験ガイドの 28 項目を公式ドキュメントで照合した（2026-10-20 公開） で公式ドキュメントと照合した。

ADK の評価の仕組み — 評価セット・設定ファイル・4つの実行方法

ADK の評価は、正解を書いたファイルとエージェントの実際の動きを比べる仕組みだ。ADK の文書は、モデルが確率的に動くため、決まった合否を断定するテストはエージェントの評価に向かないことが多いと書く。そのため指標ごとに値を出し、しきい値と比べて合否を決める。本記事では ADK Python v2.11.0（2026 年 10 月 2 日公開）に版を固定した。adk.dev の文書は最新の版に合わせて更新されるので、既定値と挙動はこの版のコードで確かめたものを書く。

正解を書くファイルは2種類ある。テストファイル（拡張子 .test.json）は1つのセッションを持ち、単体テストに向く。一方の評価セットは複数の長いセッションを持てるので、複数ターンの会話を模擬する統合テストに向く。形式は同じで、ツールの呼び出しの正解は intermediate_data の tool_uses に、参考の答えは final_response に書く。

基準は設定ファイル（test_config.json）に書く。v2.11.0 のコードでは、CLI で設定ファイルを指定せずに評価セットのファイルを1つだけ渡すと、同じフォルダの test_config.json を読む。設定が見つからないときの値は、tool_trajectory_avg_score が 1.0、response_match_score が 0.8 だ。これは基準を書かないときに使われる値で、推奨値として示されたものではない。本記事の実行では既定に頼らず、設定ファイルに値を明示した。

実行方法は4つある。

評価の機能は追加の依存として入れる。pip で google-adk[eval] を入れていないと、CLI は「Eval module is not installed」と表示して止まった。この追加分は google-cloud-aiplatform[evaluation] などの Google Cloud の SDK も一緒に入れる。手元だけで評価する場合も同じである。ADK の導入と手元のモデルの設定は、ADK のエージェントを手元の PC で書いて動かす — 出題の3割を占めるカスタムエージェントを Google Cloud なしで練習する（2026-10-21 公開） に書いた。

指標は3つに分かれる — 手元だけで計算できるもの、判定役の LLM が要るもの、クラウドの評価サービスが要るもの

ADK の評価は「すべて手元で回せる」とも「Google Cloud が要る」とも、一括では言えない。v2.11.0 のコードで確かめると、指標は呼び出す先によって3つに分かれた。以下では、LLM に採点させるときの採点役のモデルを「判定役」と呼ぶ（ADK の設定名は judge_model）。

B 区分の判定役は、指定しなければ gemini-2.5-flash を呼ぶ。これは v2.11.0 のコードの既定値で、文書の例に出てくる gemini-flash-latest は既定値ではない。したがって既定のままなら、Google の API キーか Agent Platform の認証が要る。

文書の説明では、final_response_match_v2 と rubric_based の指標は、判定役を同じ入力で複数回呼んで多数決をとる。判定役を呼ぶ回数を決める num_samples の既定は 5 である。final_response_match_v2 はこれで問いごとに 1.0 か 0.0 を決める。

rubric_based の指標は、採点の観点ごとに 1.0 か 0.0 を決め、問いの値は観点の値をまとめたもの（rubric_based_final_response_quality_v1 と rubric_based_tool_use_quality_v1 では平均）になる。これに対して hallucinations_v1 の値は、応答の文のうち、裏付けがあるか判定の対象外とされた文の割合だ。

判定役を手元のモデルにする使い方は、公式文書では案内されていない。v2.11.0 のコードは判定役の名前を文字列から引くので、ollama_chat/ で始まる名前も形の上では受け付けるが、本記事では試していない。もう一つ、判定役が値を返せないと、その指標は NOT_EVALUATED になる。v2.11.0 のコードでは、CLI はこれを合否に入れず、pytest（AgentEvaluator）は失敗として報告する。CLI だけを見ていると、採点されなかったことに気づきにくい。

C 区分には、Google の API キーか Google Cloud のプロジェクトの認証が要る。ADK の文書は、指標の一覧のページでは「Google Cloud のプロジェクトが要る」と書き、評価の概要のページでは API キーかプロジェクトの認証と書いていて、表現が揃っていない。v2.11.0 のコードはどちらも受け付ける。本記事の実測では A 区分だけを使い、B と C は使っていない。

試験ガイドの「custom autoraters」については、同じ名前の製品やページが見当たらなかった（確認した範囲）。中身に当たるのは、判定役のモデルを自分で設定・調整することや、採点の観点を自分で書くことだと考えられる。ADK では judge_model と rubrics、Agent Platform では judge model の設定（判定役へのシステム指示、応答の入れ替えで判定役の偏りを減らす、複数回採点する、調整済みのモデルを使う）と、自分で書く static rubrics がそれにあたる。Agent Platform には、判定役の採点を人の評価と照らし合わせて確かめる手順（Evaluate a judge model）もある。Agent Platform の複数回の採点は sampling_count という設定で、1〜32 から選べ、既定は 4 だ。ADK の num_samples（既定 5）とは別の設定なので、混同しないようにしたい。

どの指標で何を見るかを決めるのは、評価を回す前の設計の仕事だ。LLM アプリケーションの評価を作り、運用しながら改善していく考え方は、次の一冊にまとまっている。

LLMアプリケーション評価駆動開発 継続的に改善し運用していくための実践知

¥3,960 （2026/09/22 14:35時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

ツール呼び出しの照合 — EXACT・IN_ORDER・ANY_ORDER は余分な呼び出しの扱いが違う

tool_trajectory_avg_score の照合には3種類ある。既定の EXACT は、期待と実際の呼び出しが過不足なく一致することを求める。名前・引数・順序・個数のどれかが違えば失敗で、引数は値の完全一致で比べる。IN_ORDER は、期待の呼び出しが同じ順序で現れればよく、間に他の呼び出しがあってもよい。ANY_ORDER は順序も問わず、同じく余分な呼び出しを許す。

値の付け方は単純だ。1ターンごとに一致すれば 1.0、しなければ 0.0 で、ケースの値はターンの平均になる。2ターン中1ターンだけ外れると 0.5 になり、しきい値 1.0 を下回る。引数を無視して名前だけを比べる ignore_args という設定もあるが、これは v2.11.0 のコードにある設定で、指標の一覧のページには説明が無い。

見落としやすいのは、期待する呼び出しが空のときである。v2.11.0 のコードでは、期待が空なら IN_ORDER と ANY_ORDER は、どんな呼び出しがあっても通る。つまり「ツールを呼ばないのが正解」の境界の例は、EXACT で評価しないと余分な呼び出しを見逃す。照合の値はモデルの出力ではなく比較の規則だけで決まるので、実行の前に次の表のように正解を固定できる。

表の最後の行だけは期待が空で、それ以外の行の期待は「ツール T1 を引数 a で、次に T2 を引数 b で呼ぶ」である。余分な呼び出しと同じ呼び出しの2回目を見つけられるのは、EXACT の側だけ（ignore_args を付けても同じ）だと分かる。逆に、引数の値だけが違う呼び出しは、ignore_args を付けると見逃す。

実測の条件 — ツール3つのエージェントに5問の評価セットを書き、3つの壊し方を用意した

評価したのは、ADK のエージェントを手元の PC で書いて動かす — 出題の3割を占めるカスタムエージェントを Google Cloud なしで練習する（2026-10-21 公開） で動かしたエージェントである。ツールは、フィラメントの在庫を返す get_spool_stock、プリンターの状態を返す get_printer_status、プリンターを予約する reserve_printer の3つ。指示（英語）には、「予約の前にそのプリンターの状態を確かめ、次にその素材の在庫を確かめ、空いていて在庫があるときだけ予約する」という決まりを書いた。在庫とプリンターのデータは、実験用の架空の値だ。

実行環境もこの記事のとおりで、Windows 11、RTX 5070 Ti、Ollama 0.40.2（Windows 版）の gemma4:12B を、ADK から LiteLLM 経由で LiteLlm(model=”ollama_chat/gemma4:12B”) として呼んだ。ただし、評価の機能（google-adk[eval]）を入れたときに LiteLLM の版が 1.85.7 に下がり、評価はこの版で回した。gemma4:12B は、Ollama の表示で thinking（思考の部分を出す機能）が既定で有効なモデルである。ADK の文書は、Ollama では ollama ではなく ollama_chat を指定するよう注意しており、ollama ではツール呼び出しが止まらなくなったり前の文脈を無視したりすることがあると書く。Python は 3.13 の venv で、ADK v2.11.0 の要件（3.10 以上）に入っている。

評価セットの5問は次のとおりである。

1問分（q3）の中身を抜粋する。ADK のクラス（EvalSet・EvalCase・Invocation・IntermediateData）で作ったファイルから、空の項目と作成時刻の項目を省いた。

{
    "invocation_id": "q3_reserve_ok-1",
    "user_content": {
        "parts": [{"text": "p1 で PLA を使って刷りたいです。空いていれば予約してください。"}],
        "role": "user"
    },
    "final_response": {
        "parts": [{"text": "p1は空いていてPLAの在庫もあるため、p1をPLAで予約しました。"}],
        "role": "model"
    },
    "intermediate_data": {
        "tool_uses": [
            {"args": {"printer_id": "p1"}, "name": "get_printer_status"},
            {"args": {"material": "PLA"}, "name": "get_spool_stock"},
            {"args": {"printer_id": "p1", "material": "PLA"}, "name": "reserve_printer"}
        ]
    }
}

設定ファイルは、EXACT の場合に次の内容にした。IN_ORDER と ANY_ORDER の版は match_type だけが違う。

{
    "criteria": {
        "tool_trajectory_avg_score": {
            "threshold": 1.0,
            "match_type": "EXACT"
        },
        "response_match_score": 0.8
    }
}

効率の4指標は設定に書いていない。書くと検証エラーになり、v2.11.0 のコードは「criteria から外すこと。毎回自動で報告される」という趣旨の文を返す。実際、書かなくても毎回 INFORMATIONAL の状態で出た。実行は、エージェントのフォルダの親で、環境変数 PYTHONUTF8=1 を付けて adk eval workshop_agent 〈評価セットのファイル〉 –config_file_path 〈設定ファイル〉 –print_detailed_results の形で打った。

壊したエージェントは次の3つで、環境変数 WORKSHOP_VARIANT で切り替えた。

• 確認を飛ばす（skip_checks）: 予約を頼まれたら、状態と在庫を確かめずに reserve_printer を直接呼ぶ指示に替えた
• 毎回余分に在庫を呼ぶ（always_stock）: 元の指示に「どのメッセージでも、まず PLA の在庫を get_spool_stock で呼ぶ」を足した
• 状態のツールを外す（no_status_tool）: 指示は元のまま、get_printer_status をツールの一覧から外した

実行の回数は、壊した3つが各1回、正常なエージェントが2回である。IN_ORDER・ANY_ORDER・EXACT＋ignore_args の値は、CLI が保存した同じ呼び出しを ADK の TrajectoryEvaluator で採点し直したもので、照合の種類ごとにエージェントを動かし直してはいない。

ここで評価したのはツール3つの小さなエージェントだが、試験ガイドの §3・§4 は複数のエージェントの組み立てと運用まで含む。ADK と A2A でマルチエージェントを組み、堅牢に運用する設計を扱う一冊を挙げておく。

現場で役立つ マルチエージェントAI設計入門 Google A2A×ADKで実現する堅牢な運用システム（翔泳社・書籍）

¥4,180 （2026/10/13 12:10時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

結果 — 壊したエージェントを見つけるかどうかは照合の種類で変わった

表の値は、各実行の5問のうち、その照合で 1.0 になった問いの数である。最終判定は CLI が EXACT の設定で出したもので、応答の照合（しきい値 0.8）も合否に入る。

壊したエージェントの主な問いの呼び出しは次のとおりだった。

確認を飛ばした予約は、どの照合でも見つかった

確認を飛ばしたエージェントは、q3 と q4 で予約のツールだけを呼んだ。期待の呼び出しが欠けているので、どの照合の種類でも 0.0 になり、見逃しは無かった。q4 では在庫が0本の TPU で予約を呼び、ツールの側が「no spool in stock」と返して断った。今回のツールが自分で断る作りだったので実害は無かったが、評価が見つけたのは「確かめずに予約を呼んだ」という呼び出しの列の違いである。

余分な呼び出しを見つけたのは EXACT だけだった

毎回余分に在庫を呼ぶエージェントは、EXACT では5問すべてで失敗した。これに対して、IN_ORDER は5問中4問、ANY_ORDER は5問すべてを通した。あいさつの q5 は「ツールを呼ばないのが正解」なのに在庫を1回呼んだが、IN_ORDER と ANY_ORDER は 1.0 を付けた。照合の種類を説明した節の表の、最後の行と同じ結果である。

q3 では、余分な PLA の在庫の呼び出しが状態の確認より先に来た。そのため順序を見る IN_ORDER では失敗し、順序を問わない ANY_ORDER では通った。ここでモデルは、状態を確かめた後に在庫をもう一度確かめずに予約している。指示の「状態→在庫→予約」の順序は崩れていたが、ANY_ORDER ではそれも分からない。

正常なエージェントも、最終判定はほとんど通らなかった

正常なエージェントは、2回ともツールの呼び出しが5問すべてで期待どおりだった。それでも最終判定で通ったのは、1回目が5問中0問、2回目が5問中1問である。原因は応答の照合で、しきい値 0.8 に届かなかった。CLI は最初に通過と失敗の件数の要約（Eval Run Summary）を出し、続けてケースごとの指標の状態・値・しきい値を出す。指標のどれかが FAILED ならケースは失敗なので、ツールの呼び出しが正しくても、応答の照合だけでケース全体が失敗になる。

結果は、エージェントのフォルダの中の .adk/eval_history/ に、拡張子 .evalset_result.json のファイルとして保存された。ケースごとの項目名は final_eval_status、overall_eval_metric_results、eval_metric_result_per_invocation などで、状態は名前ではなく数値（1 が PASSED、2 が FAILED、4 が INFORMATIONAL）で入っていた。

ツールを外したのに通った問い — 照合は呼び出しが成功したかを見ていない

状態のツールを外したエージェントは、それでも指示に書かれた get_printer_status を呼ぼうとした。ADK はこれに「Invoking get_printer_status() failed as no tool with that name is available.」というエラーを返した。ところが、q2 と q4 は EXACT で 1.0 になった。呼び出しの名前と引数が期待と同じだったからだ。

tool_trajectory_avg_score が比べるのは、v2.11.0 のコードでは呼び出しの名前と引数だけである。ツールが実在したか、呼び出しが成功したか、何が返ったかは見ていない。q3 だけは、状態と在庫を呼んだ後に予約を呼ばなかったので、どの照合でも 0.0 になった。答えの文は「状態を確認できない」と正しく断っていた。エージェントの振る舞いとしては妥当だったが、ツールの呼び出しの照合だけを見ると、2問は「期待どおり」と判定される。

このエージェントの最終判定は5問すべて FAILED だった。ただし、EXACT を通った4問が落ちた理由は応答の照合が 0.8 に届かなかったことで、正常なエージェントも同じ理由で落ちている。つまり、ツールが無いことを評価が見つけたわけではない。

このような壊れ方を捕まえるには、呼び出しの列とは別のところを見る必要がある。答えの意味を見る B 区分の指標（final_response_match_v2 や rubric_based_tool_use_quality_v1）が見つけるかは、本記事では試していないので分からない。評価とは別に、エージェントに渡すツールの一覧そのものをテストで確かめておく方法もある。本番では、後で書く観測の画面がツールごとのエラー率を出す。

応答の照合は文字の重なりを数え、意味の正しさを見ていない

response_match_score は、参考の答えとの ROUGE-1 の F 値である。ADK の文書の ROUGE-1 の説明は英語の単語を前提にしているが、v2.11.0 のコードは日本語を文字単位で数える。日本語の応答では、この指標は文字の重なりを測っていると読む必要がある。

さらに、v2.11.0 の response_match_score は、答えのすべての部分の文字をつないで比べる。思考の部分（thought）も除かない。この実行では gemma4:12B が英語の推論の文を思考の部分として返すことがあり、それも参考の答えと比べられて値が下がった。当サイトが同じ ADK の計算の関数で、思考の部分を除いて計算し直した値と並べる。

0.8 以上になったのは、ADK の値では 25 件中1件、思考の部分を除くと 25 件中6件だった。25 件は5回の実行×5問である。6件の内訳は、毎回余分に在庫を呼ぶエージェントが2件、状態のツールを外したエージェントが1件、正常の2回目が2件、確認を飛ばしたエージェントが1件だ。思考の部分を除いても、参考の答えと言い回しが違うだけで値は下がる。

では、文字の重なりは意味の正しさとどれだけ合うのか。モデルを使わず、ADK の計算の関数に決まった文の組を入れて確かめた。

意味が逆の文が 0.772 で、正しい内容を言い換えた文の 0.464 より高い。文字の重なりは意味の正しさを表さない。この指標が役に立つのは、答えの言い回しがほぼ決まっていて、変更の前後で崩れていないかを見る回帰テストだろう。意味が合うかを見たいなら B 区分の final_response_match_v2 があるが、判定役の LLM が要り、本記事では試していない。

効率の指標と所要時間 — 推論の回数の増加はループの兆候として読む

効率の4指標は、値を報告するだけで、ケースを合格にも不合格にもしない。状態は常に INFORMATIONAL だ。トークン数は、モデルの側が使用量を返さないと n/a になると文書にあるが、この実行では手元のモデルでも値が出た。正常の2回目では、トークン数が 926〜2,033（あいさつの q5 だけは 448）だった。

ADK の文書は、推論の回数が跳ね上がるのは、たいていエージェントがループしているか計画をやり直している兆候だと書く。正常の2回目と、毎回余分に在庫を呼ぶエージェントを比べる。

余分な在庫の呼び出しで、推論の回数は q1 と q5 で1回ずつ増えた。ツール呼び出しの回数は q3 を除く4問で1回ずつ増えている。ただし今回の壊し方はループではなく、指示に足した1回の余分な呼び出しなので、増え方も小さい。

文書は、推論の回数とトークン数は同じ入力と同じモデルなら決定的だとも書く。この実行では、正常の1回目と2回目で推論の回数は5問とも同じだったが、トークン数は問いごとに違った（q3 で 1,863 と 2,033）。文書の記述を確かめる実験ではなく、サンプリングの設定との関係も確かめていないので、どちらとも判断しない。

所要時間は1回の測定で、サーバーの負荷で動く。正常の q2 は、1回目が 26.776 秒、2回目が 16.453 秒だった。文書も、2つの数値ではなく複数回の分布を比べるよう書いている。推論のループへの歯止めとしては、RunConfig の max_llm_calls（推論の回数の上限）があり、v2.11.0 の既定は 500 である。

本番の評価は Agent Platform 側にある — 継続的な評価と drift

4.1 の2の「継続的な評価」は、2つの形で組める。1つは、手元の評価を CI などで繰り返し回す形だ。ADK の文書は、CI/CD のパイプラインや回帰テストには A 区分の tool_trajectory_avg_score と response_match_score を勧め、この2つは速く予測しやすく、頻繁な自動の確認に向くと書く。CLI の adk eval も、ビルドと検証の決まった手順に加えられるとしている。本記事の実行は条件ごとに CLI を打ったもので、こうした仕組みは組んでいない。もう1つが、本番のトレースを採点する Agent Platform の Online monitors で、こちらは Google Cloud の側にある。

Online monitors は、本番のエージェントの質を継続的に評価する仕組みだ。前提は、エージェントをデプロイしていること、プロジェクトで Cloud Trace が有効なこと、評価に要る OpenTelemetry の信号をエージェントが出していることの3つである。信号には、エージェントの名前や会話の ID などの属性と、入力と出力のメッセージ・システム指示・ツールの定義を記録する推論のイベントが含まれる。ADK では、環境変数 OTEL_SEMCONV_STABILITY_OPT_IN と OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT を設定してこれを出す。

評価はおおむね10分ごとに定期的に回る。条件に合うデータを Cloud Trace と Cloud Logging から取り出して採点し、結果を Cloud Logging に書き戻し、数値を Cloud Monitoring に送る。1回あたりの件数に上限を付けて評価の費用を抑える設定もある。

同じ側に Quality alerts があり、エージェントの性能が決めたしきい値を下回ると知らせる。試験ガイドの drift は、公式の説明では、利用者の振る舞いや外部のデータの変化によって、時間とともに観測できる性能の低下である。土台のモデルが同じでも起きる。手元でできるのは、同じ評価セットを版ごとに回して差を見るところまでだ。本番のトレースを定期的に採点する仕組みは手元には無い。

Gen AI evaluation service は、生成 AI のモデルを客観的に評価する道具をまとめたものだ。評価の方法には、プロンプトごとに合否の観点を作る adaptive rubrics（推奨とされる）、正解があるときの ROUGE や BLEU などの計算による指標、Python で自分で書く評価の関数などがある。エージェントについては、最終的な応答と、そこに至る経路（ツール呼び出しの列）の2つを評価する。

経路の指標には、完全一致の trajectory_exact_match のほか、順序一致、順不同、precision、recall、単一のツールがある。名前は ADK の照合の種類と似ているが、別の実装で、precision と recall は ADK の指標には無い。エージェントの評価を説明する2つのページ（Evaluate Gen AI agents と、GenAI Client の Evaluate agents）には、2026 年 10 月時点で Preview の表示がある。

もう一つの入口が、Optimize の下の Agent evaluation である。手元の ADK のエージェントを評価してプロンプトやツールの設定を素早く直す使い方と、デプロイしたエージェントの過去のトレースや合成のベンチマークで質を測る使い方の2つがある。ツール呼び出しに HTTP 503 のエラーや遅延をわざと入れる環境の模擬もあり、agents-cli の eval コマンドから使う流れも用意されている。本記事ではどれも試していない。

デプロイ先の選び方 — Agent Runtime・Cloud Run・GKE を公式資料で整理する

ここからは公式資料の整理で、当サイトはどこにもデプロイしていない。4.2 の1つめの項目は、用途・要件・費用からデプロイ先を選ぶことだ。Google Cloud の Architecture Center のページ（2026 年 4 月 21 日更新）は、選び方を次のように整理している。

言語の条件には注意が要る。2026 年 10 月 9 日更新の Agent Runtime の製品ページは、コンテナにできてランタイムの約束事に従うなら、どの言語・どの枠組みのエージェントもデプロイできると書く。Architecture Center の表は更新が古く、Python 以外には向かないという記述が残っている。表の「Python」は、Agent Runtime が Python しか受け付けないという意味には読まない。

Agent Runtime は、エージェントのデプロイ・運用・伸縮のためのフルマネージドの環境である。有料のサービスで、無償枠がある（金額は本記事では扱わない）。名前は変わってきており、API のリソース名は互換性のために ReasoningEngine のまま、ADK の CLI のサブコマンドも v2.11.0 では adk deploy agent_engine のままだ。

Cloud Run は、リクエストの量に応じてインスタンスを増減し、0 まで縮む。最大のリクエストタイムアウトは1時間で、長く動くエージェントの処理では制約になりうる。

Cloud Run の文書は、エージェントを動かすリソースの種類を次の4つに分けて、向く用途を書いている。

• Services: 利用者の量が変わる、要求駆動のエージェント。0 まで縮むという説明も、この文書では Services に付いている
• Jobs: 評価の一括実行のような、終わりまで走らせる処理
• Instances: 状態を持って常に動き続ける、単体のエージェント
• Worker pools: メッセージのキュー（Pub/Sub や Kafka など）から仕事を受けて裏で動く、エージェント群

デプロイは adk deploy cloud_run（Python では推奨）か gcloud run deploy で行う。Cloud Run と GKE の基本の違いは Cloud Digital Leader 完全攻略② — インフラ近代化・セキュリティ・運用の後半3領域（2026-06-24 公開） で整理した。

GKE は、デプロイを細かく制御したい場合や、オープンモデル（Open Models）を動かす場合の選択肢だと ADK の文書は書く。一方で Architecture Center は、その制御と引き換えに運用の負担と複雑さが大きくなると書く。デプロイは adk deploy gke か Kubernetes のマニフェストで行う。なお ADK のエージェントは、Google Cloud につながらない環境でもコンテナで動かせる。

補助として、Google のリポジトリにある agents-cli の文書（コーディングエージェント向けの手順書で、製品ドキュメントではない）も見た。agents-cli の文書では、3つとも本番の選択肢で、設定の手間は Agent Runtime が低く、GKE は Kubernetes の知識が要るぶん高いと整理している。

Agent Runtime・Cloud Run・GKE の選び分けは、Google Cloud 全体の設計の中で決まる。AI を組み込んだ構成を Google Cloud で設計する考え方は、次の一冊で通して読める。

Google Cloud設計完全ガイド AIを組み込んだ次世代アーキテクチャの考え方（日経BP・書籍）

¥3,960 （2026/10/13 12:11時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

障害の切り分けと監視 — 手元で見られるもの、クラウドで見るもの

4.2 の残りの2項目は、障害の切り分けと、性能・信頼性・費用の監視である。試験ガイドが例に挙げる語を、公式の説明と、手元とクラウドのどちらで見るかに分けた。

クラウドで観測するには、エージェントが OpenTelemetry の形式で Google Cloud Observability にデータを送る設定が要る。Agent Runtime では、環境変数 GOOGLE_CLOUD_AGENT_ENGINE_ENABLE_TELEMETRY でトレース・ログ・指標を有効にする。ただし、この変数だけではプロンプトと応答の中身は記録されない。中身も記録するには OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT も設定する。Online monitors で採点するには、この中身が要る。ADK の文書は、ある程度複雑なエージェントには、入力と出力だけの監視では足りないと書いている。

手元のモデルに特有のループの原因もある。先に書いたとおり、Ollama を ollama で指定するとツール呼び出しが止まらなくなることがあると、ADK の文書は注意している。この実行では ollama_chat を使い、推論の回数は多くても3回だった。推論の回数が急に増えたら、モデルの指定の書き方も疑う価値がある。

この実測で言えないこと

結果を読むときの限界をまとめる。

• 実行は各条件1回、正常なエージェントだけ2回。数字は「この実行ではこうだった」というもので、一般化できない
• モデルは gemma4:12B の1つ、評価セットは5問で、どれも1ターン。複数ターンの会話や、複数のエージェントが受け渡すワークフローは試していない
• 使ったのは手元だけで計算する A 区分の指標だけ。判定役の LLM を使う B 区分と、クラウドの評価サービスを使う C 区分は試していない。ツールが無いことや意味が逆の答えを、それらが見つけるかは分からない
• IN_ORDER・ANY_ORDER・EXACT＋ignore_args の値は採点し直したもの。照合の種類ごとにエージェントを動かし直してはいない
• 思考の部分を除いた値は当サイトの再計算で、ADK にそういう設定があるわけではない。思考の部分が出る条件も特定していない
• 所要時間は1回ずつの測定で、比べるには回数が足りない
• 継続的な評価の仕組みは組んでいない。評価は条件ごとに CLI を打って回しただけで、CI での繰り返しの実行も Online monitors も使っていない
• デプロイしていない。§4.2 は公式資料の整理で、料金は Agent Runtime が有料で無償枠があること以外は確かめていない
• 評価セットは当サイトが作ったもので、試験の問題ではない。当サイトは受験しておらず、手元の練習は試験の実技ラボの代わりにならない

まとめ — ADK の評価は照合の種類を選ぶところから

• ADK の評価は、指標によって手元だけで計算できるもの（A）、判定役の LLM が要るもの（B、既定は gemini-2.5-flash）、Google のクラウドの評価サービスが要るもの（C）に分かれる。公式文書の範囲で、Google の API を使わずに手元で回せるのは A 区分だ
• ツール呼び出しの照合は、既定の EXACT だけが余分な呼び出しを見つけた。IN_ORDER と ANY_ORDER は、ツールを呼ばないのが正解の問いで余分に呼んでも 1.0 を付けた。境界の例は EXACT で評価する
• 照合は呼び出しの名前と引数だけを比べ、成功したかは見ない。状態のツールを外しても、状態のツールを使う3問のうち2問は EXACT で通った
• 応答の照合は文字の重なりで、v2.11.0 では思考の部分も比べる。意味が逆の文（0.772）が言い換え（0.464）より高かった
• 継続的な評価は、手元の評価を CI などで回す形でも組める（本記事では組んでいない）。本番のトレースを採点する Online monitors とデプロイ先の選択は Google Cloud の側にあり、本記事では公式資料で整理した

ADK の評価を試験の準備に使うなら、まず照合の種類と、境界の例をどう書くかを自分で決めてから評価セットを書くのがよい。何を不合格とするかを先に決めておかないと、機械が出す合否から読み取れることは少ない。合否を機械に任せるための出力と不合格の条件の書き方は、設計をコードで書かせて、確認まで機械に回させる（2026-09-17 公開） でも扱った。そのうえで、壊したエージェントを1つ用意して評価にかけると、その評価セットが何を見逃すかが具体的に分かる。

参照

• Professional Agentic Architect 試験ガイド（英語、PDF）
• ADK ドキュメント「Why evaluate agents」
• ADK ドキュメント「Evaluation Criteria」
• ADK Python v2.11.0 のリリース（GitHub）
• ADK v2.11.0 のソース: trajectory_evaluator.py（ツール呼び出しの照合）
• ADK v2.11.0 のソース: final_response_match_v1.py（ROUGE-1 の計算）
• ADK v2.11.0 のソース: eval_config.py（既定の基準）
• ADK v2.11.0 のソース: eval_metrics.py（照合の種類・判定役の既定）
• ADK ドキュメント「Ollama model host for ADK agents」
• ADK ドキュメント「Deploying Your Agent」
• ADK ドキュメント「Deploy to Agent Runtime」
• ADK ドキュメント「Deploy to Cloud Run」
• ADK ドキュメント「Deploy to Google Kubernetes Engine (GKE)」
• ADK ドキュメント「Observability for agents」
• ADK ドキュメント「Agent activity traces」
• ADK ドキュメント「Agent activity logging」
• Agent Platform「Gen AI evaluation service overview」
• Agent Platform「Configure a judge model」
• Agent Platform「Evaluate a judge model」
• Agent Platform「Define your evaluation metrics」
• Agent Platform「Evaluate Gen AI agents」
• Agent Platform「Evaluate generative AI agents using the GenAI Client in Agent Platform SDK」
• Agent Platform「Agent evaluation」
• Agent Platform「Continuous evaluation with online monitors」
• Agent Platform「Configure quality alerts」
• Agent Platform「Observability overview」
• Agent Platform「Agent Runtime」
• Agent Runtime「Set up tracing」
• Agent Runtime「Set up logging」
• Cloud Architecture Center「Choose your agentic AI architecture components」
• Cloud Run「Host AI agents on Cloud Run resources」
• google/agents-cli のデプロイ用スキル文書（SKILL.md）

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.