レッスン7：評価とデバッグ——エージェントの「うまく動いた」をどう測るか

このレッスンで学ぶこと

エージェント評価が単純な LLM 評価より難しい理由を理解する
Task Success Rate を主要 KPI として設計できる
End-to-End 評価と Step-by-Step 評価の違いと使い分けを押さえる
トレース（実行履歴の構造化記録）の重要性を意識する
LLM-as-a-Judge の限界と使い方を整理する
本番運用でのモニタリングと回帰検知の発想を持つ

前のレッスンでは、複数エージェントを協調させるマルチエージェント設計を扱いました。本レッスンは、設計したエージェントが「うまく動いているか」を測る評価とデバッグを深掘りします。本コースの中で、最も実務に直結するレッスンです。「魔法のプロンプト」「無敵テンプレ」のような言説に振り回されず、自社のエージェントを継続的に磨き続ける運用視点を中心に置きます。

エージェント評価の難しさ

エージェント評価は、単純な LLM 評価（プロンプトに対する回答の評価）より難しい論点を多く含みます。

単一 LLM 評価との違い

観点	単一 LLM 評価	エージェント評価
評価対象	1 つの応答	複数ステップの実行軌跡
成功の定義	出力の質	タスクの達成
失敗パターン	誤答	誤答・誤行動・無限ループ・暴走・予期せぬ副作用
評価コスト	軽い	重い（複数 LLM 呼び出し、ツール実行を再現する必要）
再現性	比較的高い	環境依存で低い（ツールの状態が変わると結果も変わる）

「うまく動いた」の定義の難しさ

エージェントが「うまく動いた」と言える状態は、ユースケースで違います。

メール対応エージェント：「適切な下書きが作れた」「不適切な送信を防げた」
データレポートエージェント：「正しい数値が抽出できた」「グラフが見やすい」
リサーチエージェント：「情報が網羅的」「情報源が信頼できる」

複数の評価軸を同時に満たす必要があり、単一指標では測れません。

💡 ポイント 「エージェントの精度」と一言で言えるほどシンプルではないのが、エージェント評価の難しさです。「何をもって成功とするか」を設計するところから、評価設計は始まります。

Task Success Rate——主要 KPI

エージェント評価の最も基本的な指標が、Task Success Rate（タスク成功率）です。

定義

「エージェントに与えたタスクのうち、成功と判定された割合」。シンプルですが、設計次第で意味が大きく変わります。

設計の論点

成功の定義：何をもって「成功」とするか。完全自動完了か、人間の手直しが少なくて済んだか
評価セットの設計：代表的なタスクのサンプル集を作る（30〜100 件が現実的）
採点者：人間が採点するか、LLM-as-a-Judge を使うか、ハイブリッドか
更新頻度：評価セットは固定するのか、定期的に新ケースを追加するのか

評価セットの作り方

評価セットは、エージェント運用の基盤です。

代表性：本番で起きうるタスクの分布を反映する
網羅性：成功パターンだけでなく、失敗しやすいエッジケースを含める
継続性：新しいケースが見つかったら追加する。バージョン管理する
規模：小さく始めてもよい（30 件程度）。100 件に到達すると統計的にも安定する

📝 補足 「評価セットを作るのに時間がかかる」と感じる方も多いですが、評価セットなしのエージェント運用は、地図のない航海のようなものです。最初は雑でもよいので、まず作ることが大切です。運用しながら磨いていきます。

End-to-End 評価と Step-by-Step 評価

エージェントの評価には、大きく 2 つのアプローチがあります。

End-to-End 評価

タスク全体が成功したかどうかだけを見る
中間ステップは問わない
ビジネス価値に直結する指標

Step-by-Step 評価

各ステップ（Thought、Action、Observation）が正しかったかを評価
失敗原因の特定に強い
デバッグに直結

使い分け

場面	End-to-End	Step-by-Step
ビジネス報告	○	△
デバッグ	△	○
A/B 比較	○	○
回帰検知	○	○
改善箇所の特定	△	○

両方を並行して取るのが現実的です。「Task Success Rate（End-to-End）が下がった」と気づき、「どのステップで失敗したか（Step-by-Step）」を分析する、という流れです。

💡 ポイント End-to-End だけ見ていると、「タスク成功率は変わらないのに、コストが膨らんでいる」「失敗パターンの傾向が変わっている」などの兆候を見落とします。Step-by-Step の分析を組み合わせることで、運用の解像度が大きく上がります。

トレース——実行履歴の構造化記録

トレース（trace）は、エージェント 1 回の実行を構造化された形式で記録したものです。

トレースに含める情報

ユーザー入力
各ループの Thought
呼び出したツールと引数
ツールの実行結果
各ステップの所要時間
トークン消費量・コスト
最終出力

なぜトレースが重要か

デバッグ：失敗時に「どこで間違ったか」を追跡できる
コスト分析：どのステップでトークンを消費しているかが見える
A/B 比較：プロンプトを変えたとき、トレースを比較して効果を確認
回帰検知：本番運用中の異常を発見

トレースツール

主要な可観測性プラットフォームを 2026 年 6 月時点で挙げると：

LangSmith：LangChain ファミリーの公式。トレース・評価・デバッグを統合
LangFuse：OSS の可観測性プラットフォーム
Arize：エンタープライズ向け
Helicone：シンプルさを重視、初心者向けに採用しやすい

自前で実装するか、ツールを使うか

立ち上がり期：自前で簡易ロガーを作る選択肢もあり
本番運用：専用ツールを導入する方が運用効率がよい
規模拡大時：可観測性ツールを早めに導入する組織が、長期的にトラブル対応が速い

⚠️ 注意 「トレースは後で実装すればいい」と思っていると、本番でトラブルが起きたとき調査が困難になります。プロトタイプ段階から最低限のトレースを残す習慣を持つのが、本コースの推奨です。

LLM-as-a-Judge の限界と使い方

評価の自動化に活躍するのが、LLM-as-a-Judge（LLM を採点者に使う）です。

基本の使い方

エージェントの出力を別の LLM（高品質モデル）に渡す
「この出力は適切か？1〜5 でスコアを付けて」と問う
スコアを集計して、評価指標として使う

強み

スケーラブル：人間採点より圧倒的に速い、安価
一貫性：採点基準がブレない（プロンプトを固定すれば）
複数視点：同じ出力に対して複数の LLM の評価を取り、合意度を測れる

弱み

バイアス：特定の表現を好む、長文を高評価する傾向など
モデル更新で評価がブレる：採点用 LLM がアップデートされると、スコアが変わる
複雑なタスクで弱い：採点基準が複雑だと、LLM の判断が安定しない

実務での使い方

人間採点のサブセットを「ゴールデンセット」として保持
LLM-as-a-Judge のスコアが、ゴールデンセットの人間スコアと相関するかを定期確認
相関が下がったら、Judge のプロンプトを見直す、または採点用モデルを変える

💡 ポイント LLM-as-a-Judge は強力ですが、完全に人間採点を置き換えるものではありません。「人間採点をスケールするための補助」として位置づけ、定期的に人間採点とのズレをチェックする習慣が、長期運用の信頼性を保ちます。

A/B 比較とイテレーション

エージェントを改善するときの基本サイクルが、A/B 比較です。

基本フロー

現状版（バージョン A）と改善版（バージョン B）を用意
同じ評価セットで両方を実行
Task Success Rate、コスト、レイテンシなどを比較
B が A を上回るなら採用、下回るなら却下

改善の典型例

プロンプトの改良
新しいツールの追加・既存ツールの統合
パターンの変更（ReAct → Plan-and-Execute など）
reasoning モデルの導入位置の変更

注意点

一度に 1 つの変数だけ変える（複数同時だと原因切り分け不能）
評価セットを固定する（B のために新ケースを足すと不公平）
統計的有意性に注意（30 件で「効果あり」と判断すると、ノイズかもしれない）

📝 補足 A/B 比較は「魔法のプロンプト」探しに陥らないための重要な習慣です。「これが効くらしい」という SNS の言説に飛びついて即採用するのではなく、自社の評価セットで A/B 比較してから判断する文化を作るのが、本コースのスタンスです。

本番運用でのモニタリング

開発時の評価とは別に、本番運用ではリアルタイムのモニタリングが必要です。

モニタリング対象

タスク件数・成功率：日次・週次・月次の推移
コスト：1 タスクあたり、月合計の API コスト
レイテンシ：応答時間の分布（平均・中央値・p95・p99）
失敗率と失敗原因：エラーログのカテゴリ別集計
ツール使用頻度：どのツールがどれだけ呼ばれているか

アラート設計

失敗率が閾値を超えたら通知（例：日次失敗率が 10% 超え）
コストが想定を超えたら緊急停止（暴走対策）
レイテンシが p95 で 30 秒超えたら確認

回帰検知

エージェントのバージョンアップや、依存モデルのアップデートで、突然性能が下がることがあります。

評価セットを毎日 1 回自動実行
スコアが前日比で大きく下がったら通知
「悪化したテストケース」を特定して原因分析

⚠️ 注意 モデルのアップデート（OpenAI・Anthropic・Google の各 LLM）は、エージェントの挙動を変えることがあります。「同じプロンプト・同じツールで結果が変わる」事例は珍しくありません。回帰検知の仕組みなしに本番運用するのは、リスクが高すぎます。

講師の現場メモ：「評価セットなしの 6 か月で何が起きたか」

私（高梨）が AI スタートアップで CTO だった頃の、ある社内プロジェクトの話です。あるエージェント（社内向けの定型業務処理）を、評価セットを作らずに「とりあえず動かして反応を見る」スタイルで運用していました。スピード重視の判断でした。

最初の 2 か月は順調でした。社員からのフィードバックも好評で、「思った以上に役立つ」「もっと活用したい」という声が増えていました。

3 か月目から、雲行きが変わりました。

「先週まで動いていた処理が、今週はエラーで止まる」
「同じ依頼でも、人によって結果が違うらしい」
「結果の精度が落ちている気がするが、定量的に証明できない」

社員からの報告は増えていましたが、私たちは「気のせいかも」「個別事例だろう」と片付けていました。評価セットがないため、定量的な変化を測れなかったのです。

5 か月目に、ようやく評価セットを 30 件作りました。試しに過去 3 か月分のエージェントバージョンに対して評価セットを実行すると、衝撃的な結果が出ました：

2 か月前：Task Success Rate 78%
1 か月前：Task Success Rate 65%
現在：Task Success Rate 52%

3 か月で精度が 26 ポイント下がっていたのです。原因は複合的でした：

内部で依存している LLM のバージョンが、自動更新で変わっていた
プロンプトに細かい修正を入れ続けた累積で、想定外の副作用が出ていた
社内文書（RAG の元データ）が更新され、検索精度が落ちていた

評価セットを作って以降は、毎日 1 回自動実行し、スコアが下がったらすぐ調査する運用に変えました。半年経った頃には Task Success Rate が 88% まで安定し、回帰も検知できるようになりました。

このときに学んだのが、「評価セットなしの運用は、地図のない航海」だということです。スピード重視で評価をスキップしたつもりが、結果的にスピードを大きく削っていました。本コースで「評価セットを最初に作る」を繰り返し強調するのは、この 26 ポイント下落の苦い記憶があるからです。

まとめ

このレッスンでは、以下のことを学びました。

エージェント評価は単一 LLM 評価より難しい（複数ステップ、複数失敗パターン、再現性低）
Task Success Rate を主要 KPI として、評価セット（30〜100 件）を設計する
End-to-End 評価でビジネス価値、Step-by-Step 評価でデバッグを並行して見る
トレース（実行履歴の構造化記録）は、デバッグ・コスト分析・回帰検知の基盤
LangSmith・LangFuse・Arize・Helicone などの可観測性ツールを早めに導入する
LLM-as-a-Judge は強力だが、人間採点とのズレを定期確認する
A/B 比較は「一度に 1 変数」「評価セット固定」「統計的有意性」に注意
本番運用ではモニタリング・アラート・回帰検知の仕組みが必須

次のレッスンでは、本コースの最終回として、自律性のレベル・Human-in-the-Loop・プロンプトインジェクション対策・業務適用のチェックリスト・コース修了後の学習方向を扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。