↓ メインコンテンツへスキップ

GEAP と Langfuse を比較する(3)エージェントを改善する

著者
Shunsaku Takagi
目次

はじめに
#

第1回 ではエージェントを載せて動きを見るところ、第2回 では評価を、Gemini Enterprise Agent Platform(以下、GEAP)と Langfuse で比較しました。

なお、2026年10月時点の Google Cloud の製品ページ では、「Gemini プラットフォーム」と表記されています。本記事は連載の続きなので、これまでの回に合わせて「GEAP」と表記します。

  • 第1回(載せて、見る): どちらもトレースでエージェントの動きを見られます。GEAP はエージェント(デプロイメント)単位、Langfuse はプロジェクト単位でトレースを確認します。また、Langfuse ではトレースからデータセットや実験につなぐ導線を確認できました。
  • 第2回(評価する): どちらも LLM による自動採点ができます。GEAP は Simulate で評価用のデータがなくても始められ、Langfuse はバッチ評価、実験、Evaluator、手動スコアを組み合わせられます。GEAP のコンソールの評価は、今回の検証では東京では実行できず、us-central1 で実行できました。

最終回は、評価で見つかった問題を次の版で修正する「改善」を扱います。今回は、次の4点を比べます。

  1. 失敗の分析
  2. テストケースの蓄積
  3. プロンプトの管理と反映
  4. 変更前後の比較

本記事では、出力を採点することを「評価」、同じケースで異なる版を動かして比べることを「実験」と呼びます。

加えて、プロンプトの修正案を生成する機能を、別枠で紹介します。

今回の比較で分かったことは次のとおりです。失敗トレースをテストケースに蓄積し、プロンプトの版管理から実験での比較までを同じ製品の中で進めたい場合は、Langfuse が向いていました。Google Cloud にデプロイしたエージェントの評価とケース分析は、GEAP のコンソールで行えます。プロンプトの修正案の生成は、GEAP の Agent Platform SDK、ADK、Langfuse の Halo のいずれにもあります。

  • GEAP: 2026年8月の検証結果を中心に、プロンプトの修正案を生成する機能は2026年10月8日に追加で試した結果を紹介します。
  • Langfuse: 画面のスクリーンショットは、セルフホストの v4.21.0 で撮影しました。機能の説明は、2026年10月時点の公式ドキュメントで確認した内容です。

GEAP・Agent Platform SDK・ADK の区分
#

第1回で、GEAP と Agent Development Kit(ADK)は別のものとして扱うと書きました。改善の話では、この2つが特に混ざりやすくなります。GEAP のドキュメントの中で ADK のコマンドが案内されていたり、同じ Google のエージェント向けの道具として並べて紹介されたりするためです。

本記事では、GEAP の機能を「コンソールから使うもの」と「Agent Platform SDK から使うもの」に分けます。これとは別に、エージェント開発用の ADK を扱います。ADK の評価・最適化コマンドは、今回、手元の環境で実行しました。

区分何か今回の利用方法本記事で扱うもの
GEAP(コンソール)Google Cloud 上の管理画面ブラウザで操作評価結果のケース分析、Agent Studio のプロンプト比較、評価の実行履歴
GEAP(Agent Platform SDK)GEAP の API を Python から呼ぶ SDK手元のスクリプトから実行プロンプトの修正案の生成(client.prompts.optimize)
ADKエージェント開発用のライブラリと CLI手元の環境で実行adk eval、adk optimize、環境シミュレーション

各節の見出しには、どの区分の機能かを括弧で付けます。ADK で作ったエージェントは Langfuse にもトレースを送れるため、ADK の機能は GEAP を選ぶ理由にしません。GEAP と Langfuse の比較や使い分けの表には、ADK の機能を含めません。

改善の流れを図にすると、次のようになります。

今回確認した範囲では、デプロイ済みエージェントの評価結果から instruction(エージェントへの指示文)の修正・反映までを、コンソール内で一続きに行うことはできませんでした。Agent Studio にはプロンプトの作成・改善機能がありますが、この流れとは分かれています。修正と再デプロイは人が行い、Agent Platform SDK と ADK は修正案を作る別の道具です。ADK 内の矢印は、今回の検証で行った作業の順序を示しています。

flowchart LR
  subgraph GEAP["GEAP のコンソール"]
    E1["評価の実行"] --> E2["スコアがついた理由を読む"]
  end
  E2 --> F1["instruction を人が修正"]
  F1 --> F2["再デプロイ"]
  F2 --> E1
  subgraph ADK["ADK(手元の環境)"]
    A1["adk eval"] --> A2["adk optimize"]
  end
  subgraph SDK["GEAP の Agent Platform SDK"]
    S1["prompts.optimize"]
  end
  A2 -.->|"修正案"| F1
  S1 -.->|"修正案"| F1

失敗の分析と修正の準備
#

ケースごとのルーブリック理由(GEAP のコンソール)
#

第2回で見たとおり、GEAP の評価結果でケースを開くと、ルーブリック(合否を判断する基準の一覧)ごとの合否と理由が表示されます。Pass: 1/3 のような表示は、そのケースのルーブリックのうち何件を満たしたかを表すもので、テスト全体の合否ではありません。

評価結果のケース詳細に表示されるルーブリックごとの理由
評価結果のケース詳細に表示されるルーブリックごとの理由

公式ドキュメント では、似た失敗をまとめる自動損失分析も紹介されており、このまとまりを「障害クラスタ」と呼んでコンソールのレポートに表示すると説明されています。今回の検証では、評価の実行時にクラスタリングを有効にしても、コンソールに障害クラスタのセクションは表示されませんでした。同じドキュメントには SDK の generate_loss_clusters でクラスタを生成する方法も載っていますが、こちらは今回試していません。

コンソールで確認できたのは、ケースを1件ずつ開いて理由を読むところまでです。公式ドキュメントのトリアージ手順でも、修正の適用と再評価は利用者が行うステップとして書かれています。

トレースからデータセットや Playground を開く(Langfuse)
#

Langfuse では、トレースの画面から次の作業に直接進めます。オブザベーション(LLM 呼び出しやツール呼び出しなど、トレース内の個々の処理)の詳細には、データセットへの追加、アノテーション、Playground で開く、コメントの追加が並んでいます。

Langfuse のトレース画面から選べる次の作業
Langfuse のトレース画面から選べる次の作業

失敗した例をその場でデータセットに入れておけば、次の実験のテストケースになります。オブザベーションの一覧で複数件を選び、まとめてデータセットに追加することもできます。

失敗を見つけてから、修正の準備をするまでの導線は、Langfuse の方が短いと感じました。GEAP のコンソールでは、ケースの理由を読んだあとの作業は画面の外で進めることになります。

データセット
#

評価に使うケースを指定・生成する(GEAP のコンソール)
#

GEAP では、評価の入力として CSV などで用意したデータを渡すか、第2回で紹介した Simulate でケースを生成します。今回確認した、デプロイ済みエージェントの評価画面では、評価のたびに使うデータを指定する形で、失敗したトレースを継続的にテストケースへ追加する導線は見当たりませんでした。

その代わり、評価用のデータがまったくない段階では Simulate が便利です。テストしたい状況を文章で指示するだけで、擬似ユーザーとの複数ターンの会話を含むケースを作れます。

失敗例をデータセットに蓄積する(Langfuse)
#

Langfuse では、データセットが独立した機能として用意されています。データセットは入力と、必要に応じて期待する出力をまとめたテストケースの集まりで、画面や SDK、CSV から項目を追加できます。

Langfuse のデータセット一覧
Langfuse のデータセット一覧

公式ドキュメント によると、項目を追加・更新・削除するたびにデータセットのバージョンが記録され、過去のバージョンを指定して実験を実行し直せます。本番のトレースから失敗例を拾って期待する出力を書き足し、次の版のテストに使う、という使い方が想定されています。なお、データセットのバージョン管理は、v3.151.0 のリリースノート で追加が案内されている機能で、今回スクリーンショットを撮影した v4.21.0 にも含まれていますが、今回は画面で確認していません。

最初のテストケースを作る段階は GEAP の Simulate が楽で、運用しながら失敗例を貯めていく段階は Langfuse のデータセットが向いています。

プロンプトと Playground
#

Agent Studio(GEAP のコンソール)
#

GEAP の Agent Studio では、プロンプトを保存してバージョンを残し、テンプレート変数に値を入れて試し、最大3列で並べて比較できます。プロンプト エージェントに自然言語で頼んでプロンプトを作ったり、入力欄の / コマンドから改善や比較を呼び出したりもできます。下の画面は、同じプロンプトをモデルを変えて2列で比較した例です。

Agent Studio のプロンプト比較(2列)
Agent Studio のプロンプト比較(2列)

一方で、デプロイ済みエージェントの instruction を管理する用途には向いていませんでした。今回の検証で確認したのは次の点です。

  • 今回の構成では、Agent Studio の保存済みプロンプトをエージェントが自動で参照する連携は確認できず、コードに書いた instruction がそのまま使われた
  • 「本番はこの版」とラベルで指定して配信する仕組みは見当たらず、バージョンを指定して取得・復元する操作が中心だった
  • 今回の計装設定では、トレースに instruction の本文は残るが、どのプロンプトのどの版かという情報は自動では付かなかった
  • トレースの画面から Agent Studio に移って直す導線は、確認できなかった

ここで比べているのは、アプリを改修すれば実現できるかどうかではなく、プロンプトの版とトレースを結びつける仕組みや画面が製品側に用意されているかどうかです。

また、SDK で保存したプロンプトを Agent Studio のエディタで開いたところ、今回の環境では本文が表示されませんでした。原因は切り分けられていませんが、少なくとも今回の検証では、SDK で保存した内容をそのまま Agent Studio で編集できませんでした。

GEAP には Playground が2つあります。第1回で紹介した、デプロイ済みのエージェントと会話する Playground と、Agent Studio でプロンプトを試す画面です。今回確認した範囲では、この2つの間を行き来する導線はありませんでした。

ラベルで配信し、トレースから戻る(Langfuse)
#

Langfuse のプロンプト管理では、保存するたびにバージョンが振られ、production や staging などのラベルを任意のバージョンに付けられます。公式ドキュメント によると、アプリからバージョンもラベルも指定せずに取得すると production の付いたバージョンが返り、ラベルを前のバージョンに付け替えればロールバックできます。バージョン間の差分も画面で確認できます。

Langfuse のプロンプトのバージョンと production ラベル
Langfuse のプロンプトのバージョンと production ラベル

アプリ側でプロンプトとトレースを紐づけておくと、トレースのどの LLM 呼び出しでどの版が使われたかが分かり、バージョンごとのレイテンシ、コスト、スコアの中央値などを比較できます。ただし、プロンプトの取得とトレースへの紐づけには、アプリ側の実装が必要です。ADK で作ったエージェントでこの紐づけを行う方法は、弊社の別記事で紹介しています。

Playground では、保存済みのプロンプトを開くだけでなく、トレース中の LLM 呼び出しを「Open in Playground」で開いて、そのときの入力のまま試し直せます。ここで試し直す対象は、トレース中の個々の LLM 呼び出しです。ツール実行や状態遷移を含むエージェント全体の検証は、SDK からの実験などで別途行います。

複数の案を並べて実行し、良かったものをプロンプト管理に保存します。アプリが Langfuse のラベルを指定してプロンプトを取得する構成なら、ラベルの付け替えで使用する版を変更できます。ただし、反映のタイミングは、SDK のキャッシュ設定や、アプリ側でプロンプトを取得するタイミングに依存します。

GEAP の Agent Studio はプロンプトを試す場所としては使いやすい一方、エージェントの instruction をバージョン管理し、トレースから修正して反映するところまでは、Langfuse の方が連続して行えました。今回の比較でいちばん差が大きかったのがこの部分です。

実験
#

評価の実行履歴(GEAP のコンソール)
#

GEAP のコンソールでは、デプロイメントの評価を複数回実行し、実行ごとの結果を一覧で確認できます。ただし、「プロンプトのどの版を、どのデータセットで試したか」を軸に結果を並べる比較画面ではありません。

補足として、Python の SDK から、2つの候補で推論した結果を1回の評価にまとめて比べるスクリプトも動かしました。これは SDK の使い方で、コンソールの機能ではありません。

また、ADK の adk eval もエージェントを評価するコマンドですが、手元の環境で評価セットを実行するものです。結果は手元に JSON などで残り、GEAP のコンソールの評価履歴には載りません。

データセットに対する実験(Langfuse)
#

Langfuse の実験は、データセットの各項目に対してアプリやプロンプトを実行し、その結果を採点するものです。画面から実行する場合は、データセット、プロンプトの版、モデル、Evaluator を選ぶだけで始められます。エージェント全体の処理を試したい場合は SDK から実行します。

公式ドキュメント によると、実行後は実験の一覧で集計スコアを確認し、複数の実験の結果を並べて比較できます。下の画面は、ベースラインにした実験と別の実験を、入力ごとの出力とスコアで並べた比較ビューです。

Langfuse の実験の比較ビュー
Langfuse の実験の比較ビュー

比較ビューの使い方は、弊社の別記事で紹介しています。

Langfuse では、データセット、プロンプトの版、実験の結果が同じ製品の中で結びつきます。この点が GEAP との大きな違いです。

プロンプトを改善する
#

ここまでは、失敗を分析し、ケースを蓄積し、版を比べる仕組みを見てきました。ここからは、プロンプトの具体的な修正案を作る機能を見ます。

GEAP の公式ドキュメントのエージェントのプロンプトを最適化する ページでは、評価・分析・最適化を繰り返す流れを説明したうえで、最適化の自動化には ADK の adk optimize を使うよう案内しています。GEAP のドキュメントに載っていても、実行するのは ADK の CLI です。

今回は、この adk optimize と、Agent Platform SDK の client.prompts.optimize を、2026年10月8日に試しました。使ったバージョンは、google-adk 2.6.2 と google-cloud-aiplatform 1.163.0 です。

Langfuse の Halo と外部エージェント
#

Langfuse では、アシスタント機能の Halo を使って、プロンプトを見直し、改善案を提案させることができます。2026年9月3日の変更履歴 にも、「現在のベストプラクティスに照らしてこのプロンプトをレビューし、より引き締めた版を提案する」という使用例が載っています。Halo はトレースやデータセットの調査、ダッシュボードの作成など、Langfuse 上の作業全般を支援する機能で、プロンプト改善はその用途のひとつです。評価セットを使って候補の生成・採点・選択を繰り返す adk optimize のような最適化とは、仕組みが異なります。

Halo は、Cloud では利用でき、セルフホストでは v4.28.0 以降が Public Beta です。今回スクリーンショットを撮影した環境(セルフホストの v4.21.0)では、Halo は試していません。

また、外部の AI エージェントに Langfuse の Agent Skill と CLI を使わせ、トレースへのフィードバックを読ませてプロンプトの変更を提案させる方法も、公式ブログで紹介されています。

Langfuse では、Halo や外部のエージェントによる修正案の提案と、Playground での試行、プロンプトの版の保存、実験での比較を組み合わせて、改善を進められます。

GEAP 側では、Agent Platform SDK と、エージェント開発用の ADK で修正案を生成できます。ただし、ADK は Langfuse とも併用できるため、adk optimize は GEAP 固有の利点には含めません。

修正案の生成には、次の違いがあります。

観点adk optimize今回試した client.prompts.optimizeHalo(Langfuse)
区分ADKAgent Platform SDKLangfuse のアシスタント
入力手元の評価セットと instructioninstruction の文章を渡した自然言語での依頼とプロジェクトのデータ
評価結果の利用評価セットで採点しながら繰り返し調整する今回の呼び出しでは渡していない候補の実行・採点を繰り返す仕組みではない
位置づけプロンプト最適化が目的プロンプト最適化が目的プロンプト改善もできるアシスタント
今回の検証実行した実行した未検証

adk optimize(ADK)
#

adk optimize は、評価セットで採点しながら instruction を繰り返し書き換える ADK のコマンドです。内部では GEPA というアルゴリズムを使います。最適化の対象は、ルートエージェントの instruction です。サブエージェントやツールの実装、エージェントの構成までは直しません。

今回のデモエージェントには、日本語の都市名(「東京」など)をそのままツールに渡して天気や時刻を取得できない、という失敗がありました。5件の評価セットを用意し、うち3件で調整、2件で検証する設定で実行したところ、検証用のスコアは 0.5 から 1.0 に上がりました。実行時間は約1分です。

スコアは、期待するツール呼び出しと実際の呼び出しの一致度を見る指標 tool_trajectory_avg_score で、検証用2件の平均です。この2件は最適化中の候補選択にも使われるため、独立した最終テストの結果ではありません。また、評価セットが5件と小さいため、この結果は「仕組みが動いた」ことの確認にとどまり、改善の効果を一般化できる数字ではありません。

追加された指示は、「ツールに渡す都市名の引数は、日本語の都市名であっても必ず英語(ローマ字)表記に変換してください」というものでした。評価セットで再現した失敗に対して、有効な指示を追加できた例です。

ただし、今回の実行では、adk optimize は改善した instruction を出力するだけで、エージェントのコードは書き換えませんでした。入力に使ったのは手元の評価セットで、GEAP のコンソールで実行した評価の結果や、Agent Studio に保存したプロンプトとは連携しませんでした。今回の構成では、コードに反映して再デプロイしたうえで、GEAP でも評価し直します。

client.prompts.optimize(Agent Platform SDK)
#

client.prompts.optimize は、agentplatform.Client(project=..., location="us-central1") で作ったクライアントから、prompt= に instruction の文章を渡して呼び出しました。今回の呼び出し方では、入力は文章だけで、評価結果は渡していません。返ってきたのは、見出しによる構造化、略語の補足、回答例の追加、情報がないときの返答の明確化といった提案と、その理由です。実行するたびに、提案の内容は少しずつ変わりました。

この呼び方では、先ほどの日本語の都市名の問題は拾えませんでした。文章としての分かりやすさを整える用途には向いていますが、エージェントの実際の失敗を直す用途には、今回の使い方では足りませんでした。

なお、GEAP の評価のドキュメントには、評価結果を渡して最適化する client.optimizer.optimize の例が載っています。しかし、今回の環境では、google-cloud-aiplatform 1.163.0 の agentplatform.Client から optimizer を利用できず、この方法は試せませんでした。

評価セットを使う改善と、文章だけを入力する改善の違い
#

今回は、評価セットで複数の案を採点し、最もスコアの高い案を選べる adk optimize の方が、採用する案を判断しやすく、使いやすいと感じました。client.prompts.optimize が返すのは提案された1つのプロンプトで、それが良いかどうかは自分で判断する必要がありました。

ただし、今回は入力条件が異なるため、この結果だけで両者の改善能力の優劣は判断できません。adk optimize には instruction と評価セットを渡し、client.prompts.optimize には instruction の文章だけを渡しました。後者が都市名の問題を拾えなかったことは、機能そのものの不足を示すものではありません。

GEAP のコンソールには、評価結果から instruction を自動で直す機能は見当たりませんでした。また、いずれの方法でも、生成された案の反映は手動で行います。

補足: 環境シミュレーション(ADK)
#

ADK には、ツールの応答をモックしたり、エラーや遅延を注入したりする環境シミュレーションという実験的な機能もあります。今回は「東京の天気」を聞いたときにエラーを返す設定で試しましたが、設定側の都市名が Tokyo で、モデルがツールに渡した引数が 東京 だったため、エラーは注入されませんでした。

使い分け
#

3回の比較を踏まえた使い分けの目安です。ADK の機能は GEAP を選ぶ理由にならないため、表には入れていません。どちらを選ぶ場合でも、ADK の adk optimize は別途使えます。

用途選択肢選ぶ理由注意点
エージェントを Google Cloud に載せ、IAM でアクセスを管理しながら観測したいGEAPAgent Runtime と Agent Registry、エージェント単位のダッシュボード第1回の前提(ADK、us-central1 など)の範囲で確認した
Google Cloud にデプロイしたエージェントを、その管理画面から評価したいGEAPデプロイしたエージェントの管理画面から、ルーブリック評価とケース分析に進める今回の検証では、評価を実行できるリージョンが限られた(第2回)
評価用のデータがない段階で、複数ターンのテストケースを作りたいGEAP の Simulate擬似ユーザーとの会話を生成できる今回の検証では us-central1 のみで実行できた
プロンプトをラベルで配信し、トレースから修正したいLangfuseラベル、トレースとの紐づけ、トレースから開ける Playgroundアプリ側でのプロンプト取得の実装が必要
失敗例をデータセットに貯めて実験を回したいLangfuseデータセットのバージョン管理と実験の比較バージョン管理は v3.151.0 以降の機能。今回は画面での動作は未確認
Langfuse に蓄積したトレースやプロンプトを参照しながら、改善案を相談したいLangfuse の Halo(Cloud、またはセルフホスト v4.28.0 以降)プロジェクトのデータを参照しながら、自然言語で改善を依頼できる今回は未検証。提案の効果は実験で確認する必要がある
実行は Google Cloud、改善は Langfuse で行いたい併用実行基盤と改善の作業を分けられる両方にトレースを送る構成は今回検証していない

データを日本国内に置く必要がある場合は注意が必要です。エージェントの実行環境を東京に配置できても、観測データの保存先、モデルの処理場所、評価機能の対応リージョンは別々に確認する必要があります。第2回のとおり、今回の検証ではコンソールの評価を東京で実行できませんでした。その場合は、実行だけを GEAP に置き、評価や実験は Langfuse(Langfuse Cloud の Japan リージョンかセルフホスト)で行う、という分担も考えられます。

確認すべき点は両方にあります。Langfuse 側では、データ所在地の説明 を確認してください。LLM による採点を行う場合は、採点に使う LLM の処理リージョンも確認が必要です。GEAP 側でも、評価や client.prompts.optimize に渡す instruction とトレースの内容が、どのリージョンで処理されるかを事前に確認してください。なお、今回の client.prompts.optimize は us-central1 で実行しました。

おわりに
#

3回を通して、GEAP はエージェントを載せて観測し、評価するまでの機能を Google Cloud の中で揃えられることが分かりました。Langfuse は、トレースを起点にデータセット、プロンプト、実験を結びつけ、改善を繰り返すための機能が揃っています。プロンプトの改善では、Halo や外部のエージェントによる修正案の提案と、Playground や実験による検証を組み合わせて進められます。

デプロイ済みエージェントの改善では、GEAP のコンソールで評価とケース分析を行えましたが、その結果から instruction の修正・反映までを一続きに進めることはできませんでした。Agent Studio のプロンプト改善機能とは別に、今回は Agent Platform SDK と ADK による修正案の生成も試しました。GEAP を土台にしながら改善の作業に Langfuse を使う、という組み合わせも選択肢のひとつです。

参考リンク
#

GEAP

ADK

Langfuse