GEAP と Langfuse を比較する（2）エージェントを評価する

はじめに

#

第1回では、Gemini Enterprise Agent Platform（以下、GEAP）にエージェントを載せ、ダッシュボードとトレースで動きを見るところまでを Langfuse と比較しました。第2回は、エージェントの応答やツールの使い方、会話全体の達成度に点を付ける「評価」を扱います。

• GEAP: 2026年8月に Agent Development Kit（ADK）で作った単一エージェントを使い、コンソールで実際に評価した結果を紹介します。
• Langfuse: 画面のスクリーンショットは v4.21.0 で撮影しました。機能の説明は、2026年10月1日時点の公式ドキュメントで確認した内容です。Cloud とセルフホストで条件が違う機能は、その箇所で補足します。

各節では、GEAP の機能を紹介したあとに「Langfuse では」として、対応する Langfuse の機能を並べます。評価の結果を改善につなげる流れは第3回で扱います。

評価におけるデプロイリージョンの制限

#

GEAP では、エージェントのデプロイ先リージョンによって、コンソールから使える評価機能が変わります。東京（asia-northeast1）と us-central1 の両方にデプロイして確認した結果が次の表です。

東京にデプロイしたエージェントのセッション画面からワンクリック評価を実行すると、次のエラーになりました。

Unsupported region for Vertex Evaluation Service: asia-northeast1

東京にデプロイしたエージェントで Simulate を実行した場合は、推論の段階で次のエラーになり、スコアは1件も付きませんでした。

Failed to complete agent scraping ...
valid location ID is `us-central1`

画面には No metric scores to aggregate という集計のエラーだけが表示され、ケースごとの原因は出ません。上のエラーは、Cloud Storage に出力された評価結果の JSON で確認したものです。

同じエージェントでも Playground やトレースは東京で問題なく動くため、評価を実行するまで気づきにくい点に注意が必要です。今回の検証では us-central1 でのみ実行できたので、コンソールからの評価も使う場合は、機能ごとの対応リージョンを事前に確認してください。

なお、今回参照した Gen AI Evaluation Service の対応ロケーション一覧 には、東京（asia-northeast1）は掲載されていませんでした。評価 API の直接呼び出しは、今回は確認していません。

Langfuse では（デプロイ先による制限との対比）

#

デプロイ先による制限という点では、Langfuse の管理画面で設定する LLM-as-a-Judge は、保存されたトレースやオブザベーションを対象に、プロジェクトに登録した LLM 接続（例: Vertex AI の Gemini）を使って採点します。エージェントのデプロイ先を Langfuse の評価機能に合わせる必要はありませんが、採点用の LLM がどのリージョンで処理するかは、トレースの保存先とは別に確認する必要があります。

Langfuse Cloud には、公式ドキュメント のとおり、EU・US・Japan のデータリージョンと、HIPAA 対応の US リージョンがあります。セルフホストなら置き場所を自分で決められます。

GEAP の3つの評価

#

GEAP のコンソールからエージェントを評価する方法として、今回は次の3つを試しました。違いは、何を・いつ採点するかです。

今回使った事前定義の指標では、ルーブリック（合否を判断する基準の一覧）に沿って LLM が採点します。指標は、マルチターンのタスク成功率、ツール使用の品質、ハルシネーションなど、Google Cloud があらかじめ用意しているものから選べます。

独自の基準で採点したい場合は、LLM に採点させるカスタム LLM 指標や、Python 関数で採点するカスタムコード指標を作成できます。

ワンクリック評価: 既存のトレースを選んで採点する

#

ワンクリック評価は、トレースの詳細画面の「評価」から、すでに記録されているトレースを採点する機能です。評価したいトレースと指標、結果の保存先（Cloud Storage）を指定して実行します。

以降のスコアは、少数のケースを使った機能確認の結果であり、エージェント全体の品質を示すものではありません。また、画面に表示された集計値は、ルーブリックの合格数から計算した値と一致しましたが、公式の集計仕様は確認していません。

今回は3件のトレースを「エージェント ツールの使用品質」で採点しました。3件のうち、画像について質問したケースではツール呼び出しがなく、採点エラーになりました。採点できたのは残りの2件です。

ケースごとの Pass 3/4 のような数字は、ルーブリックのうち何件を満たしたかを表すもので、テスト全体の合否ではありません。画面上の全体スコアは88%で、採点できた2件のルーブリックの合格数を合計した 7/8（87.5%）と一致しました。

ケースを開くと、トレースのタイムラインと並んで、ルーブリックごとの合否と理由が表示されます。下の例では、ツールの選び方や引数は合格している一方、天気を取得できずに依頼を満たしていない点が不合格になっています。

Langfuse では（ワンクリック評価との対比）

#

ワンクリック評価のように、記録済みのデータを選んで採点する方法として、Langfuse にはバッチ評価 があります。トレース一覧で対象の行を選んで「Evaluate」から Evaluator を実行すると、結果が該当するオブザベーション（LLM 呼び出しやツール呼び出しなど、トレース内の個々の処理）にスコアとして付きます。LLM-as-a-Judge で使うには、Evaluator 側で Langfuse v4 preview を有効にする必要があります。

Evaluator は、LLM で採点する LLM-as-a-Judge か、Python / TypeScript で書くコード評価器のどちらかです。LLM-as-a-Judge は登録した LLM 接続を使い、コード評価器 はコード実行基盤を使って採点します。セルフホストでコード評価器を使うには、別途設定が必要です。設定画面では、既存のオブザベーションを使って評価器の動作をテストできます。ルールに基づく自動採点については、後述のオンラインモニターの節で説明します。

バッチ評価とは別に、人が手動でスコアを付ける方法もあります。トレース画面から手動でスコアを入力し、そのトレースや個々のオブザベーションに紐づけられます。スコアは数値・カテゴリ・Boolean・テキストの型で定義できます。

複数人で確認したい場合は、トレースをアノテーションキュー（人手で評価する対象を並べた作業リスト）に入れて順番に採点できます。

Simulate: 擬似ユーザーとのやり取りを生成して採点する

#

Simulate（コンソールでは「セッションをシミュレート」）は、テストしたい状況を文章で指示するとシナリオを生成し、擬似ユーザーがデプロイ済みのエージェントと複数ターンのやり取りをして、その結果を採点する機能です。評価用のデータを用意していなくても始められます。評価はデプロイメントのダッシュボードにある「評価」から「新しい評価」を選んで開始します。

生成されたテストケースには、最初の発話と、擬似ユーザーがどう会話を進めるかの計画が入ります。ケースの追加はできますが、生成されたケースの編集はできません。

実行後は、ケースごとの結果が一覧で表示されます。各ケースには、やり取りのターン数や呼び出したツールと、指標ごとのスコアが並びます。今回は3件のケースを、3つのマルチターン指標で採点しました。そのうち「マルチターンのタスク成功率」の画面上の集計値は78%でした。この指標について3件分のルーブリックの合格数を合計すると 7/9（77.8%）となり、表示値と一致しました。

ケースを開くと、ターンごとのやり取り（ユーザーの発話、ツールの呼び出しと応答）と、指標ごとのルーブリックの合否と理由を確認できます。

Langfuse では（Simulate との対比）

#

Simulate に近い用途として、Langfuse ではデータセット（入力と、必要に応じて期待する出力などをまとめたテストケース）を使ってアプリを実行し、その結果を採点する実験が行えます。ただし、今回確認した公式ドキュメントには、擬似ユーザーとの複数ターンのやり取りを生成する製品機能の記載はありませんでした。一方、公式クックブックでは OpenEvals などの外部ライブラリと組み合わせる方法が紹介されています。

オンラインモニター: 本番のトレースを定期的に採点する

#

オンラインモニターは、エージェントの実行で記録されたトレースを定期的に採点する機能です。公式ドキュメント によると、モニターは通常10分ごとの評価ループで動き、1回のループは次の3段階で進みます。

1. クエリ: 設定したフィルタ条件に基づいて、Cloud Trace と Cloud Logging のデータをサンプリングする
2. 評価: 設定した指標で採点する
3. レポート: 結果を Cloud Logging に書き戻し、数値スコアを Cloud Monitoring にエクスポートする

サンプリングには、評価する割合（サンプリング率）と、1回の実行で採点する最大件数を設定します。各ループがどの期間のデータを対象にするかは、ドキュメントに記載がなく、今回は確認していません。

採点結果は、対象のトレースを開いたときの「評価」タブに、指標ごとのスコアと理由として表示されます。

今回確認したコンソールでは、採点対象はトレース単位でした。セッション単位やスパン単位で設定する項目は見当たりませんでした。10分ごとのループとサンプリングで動くため、Playground から送ったリクエストにすぐスコアが付くわけではありません。

また、公式ドキュメントでは、オンライン評価はプロジェクトレベルのサービスアカウント（Google Cloud がサービスの実行に使うアカウント）に依存すると説明されています。今回は、エージェントをデプロイしたプロジェクトで、このアカウント（PROJECT_NUMBER@cloudservices.gserviceaccount.com、PROJECT_NUMBER はプロジェクト番号）に roles/observability.viewAccessor と roles/observability.analyticsUser を付与しました。この2つが両方とも必須かどうかは確認していません。付与前は、トレースの取得時に observability.views.access の権限エラーでモニターが失敗しました。

Langfuse では（オンラインモニターとの対比）

#

オンラインモニターに近い使い方として、Langfuse では前述の Evaluator に実行条件（ルール）を設定すると、新しく記録されるオブザベーションに対して自動で実行し、継続的に採点できます。採点結果は、対象のオブザベーションにスコアとして紐づきます。

また、スコアの値に応じてアラートを設定できる Alerts という機能があります。公式ドキュメントでは、数値・カテゴリ・Boolean のスコアを条件にでき、通知先として Slack、Webhook、GitHub Actions を選べると説明されています。たとえばスコアの平均が閾値を下回ったときに通知できます。Langfuse Cloud の全プランと、セルフホストの v4 以降で使えます。

第2回の整理

#

おわりに

#

GEAP も Langfuse も、エージェントの応答を LLM で自動採点する仕組みと、本番のトレースを継続的に採点する仕組みを持っています。

今回比較した範囲での違いは、評価の進め方です。GEAP は、既存のトレースを選んで採点するワンクリック評価に加え、Simulate で擬似ユーザーとのやり取りを生成して採点できるため、評価用のデータがない段階からシナリオで始められます。Langfuse は、トレース一覧で選んだ既存のデータをバッチ評価で採点できます。データセットを使った実験と Evaluator による自動採点に加えて人が手動でスコアを付けることもでき、手動評価と Evaluator の結果を対象のトレースやオブザベーションにスコアとして残せます。

次回は、評価の結果を改善につなげる流れを比較します。

参考リンク

#

• エージェントを評価する（GEAP）
• Simulate agent behavior（GEAP）
• Continuous evaluation with online monitors（GEAP）
• Gen AI Evaluation Service の概要（GEAP）
• GEAP のロケーション
• Evaluation Overview（Langfuse）
• Scores（Langfuse）
• LLM-as-a-Judge（Langfuse）
• Code evaluators（Langfuse）
• Annotation Queues（Langfuse）
• Alerts（Langfuse）
• Evaluating Multi-Turn Conversations (Simulation)（Langfuse）