AI Agentの品質はどう測る？6つの評価軸とObservabilityの4領域を整理

📚 参考書籍

※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。

####『ゼロから触ってわかった！AI Agent Observability入門― MLflow・Databricksで実践するAIエージェントの評価・監視・安全性・説明可能性』
本書は、AI Agentを「作って動かす」だけでなく、その品質をどう観測し、どう評価し、どう守り、どう説明可能にするかを体系的に学ぶための入門書です。
https://link.amazon/B04VaTlR3

####『ゼロから触ってわかった！Databricks Agent Engineering実務入門 ～AI Gatewayでつなぎ、Agent Skillsで標準化・量産し、MLflowで運用する ～』
AI Gatewayでつなぎ、Agent Skillsで企業の仕事を標準化し、Pipeline Factoryで量産し、MLflowで評価・改善する。
その一連のライフサイクルを、データパイプライン開発という具体的な題材を通して理解することが本書のゴールです。
https://link.amazon/B03g0YUiI

####『ゼロから触ってわかった！AI Gateway入門 ― LiteLLMで学ぶ、LLM・AIエージェント・MCPを安全につなぐための基礎知識』
https://link.amazon/B07CHz9OB

AI Agentの品質はどう測る？6つの評価軸とObservabilityの4領域を整理

1-3 AI Agent品質をどう分解するか

AI Agentの品質は、「良い回答だったか」「悪い回答だったか」という一つの尺度だけでは十分に評価できません。

たとえば、回答内容そのものは正しくても、ユーザーの質問に十分答えていない場合があります。反対に、質問には的確に答えていても、RAGで取得した根拠に含まれていない情報をLLMが付け加えていることもあります。また、Toolを利用するAgentでは、回答文が自然であっても、実際のTaskを完了できていない可能性があります。

そのため、AI Agentの品質を複数の観点に分解して考える必要があります。

Correctness（正確性）：回答は正しいか

Correctness（正確性）は、Agentの回答内容が正しいかを評価する観点です。

たとえば、「有給休暇は年間何日付与されますか」という質問に対して、期待される回答と一致しているかを確認します。

正解となる回答や事実があらかじめ分かっている場合には、それらとAgentの回答を比較することで評価できます。

ただし、文章表現は異なっていても意味として正しいことがあります。そのため、単純な文字列一致だけではなく、後ほど扱うLLM Judgeなどを使った意味的な評価が必要になる場合もあります。

Relevance（関連性）：質問に答えているか

Relevance（関連性）は、回答がユーザーの質問や意図に関連しているかを評価する観点です。

Correctness（正確性）とRelevance（関連性）は似ていますが、同じものではありません。

たとえば、ユーザーが「東京支店の営業時間」を質問しているのに、Agentが「大阪支店は9時から営業しています」と回答した場合、大阪支店についての情報自体は正しいかもしれません。しかし、ユーザーの質問には答えていないため、Relevance（関連性）は低いと判断できます。

このように、正しい情報であることと、質問に対して適切な情報であることは分けて評価する必要があります。

Groundedness：根拠に基づいているか

Groundedness（根拠に基づいているか）は、Agentの回答が与えられたEvidenceやContextに裏付けられているかを評価します。

RAG Agentでは特に重要な品質指標です。

たとえば、Retrieverが取得した社内規程には「申請期限は5営業日前」としか書かれていないにもかかわらず、Agentが「緊急時には前日でも申請可能です」と回答した場合、その追加情報が事実として正しい可能性があったとしても、取得した根拠からは裏付けられていません。

Groundedness（根拠に基づいているか）を見ることで、LLMが与えられた情報から逸脱して回答していないかを確認できます。

Task Success：目的を達成できたか

AI Agentでは、文章の品質だけでなく、ユーザーの目的を達成できたかも重要です。

たとえば、「来週月曜日の会議を予約してください」という依頼に対して、Agentが「予約しました」と自然な文章を返しても、実際にはCalendar Toolの実行が失敗していれば、Taskは成功していません。

Toolを利用するAgentでは、Toolの選択、引数、実行結果などを含めて、最終的にユーザーの目的が達成されたかを評価します。

Safety：安全に動作したか

Safetyは、Agentが危険・不適切な回答や操作を行っていないかを評価する観点です。

たとえば、アクセスしてはいけない情報を回答していないか、不正な指示によって禁止されたToolを実行していないか、業務上のPolicyに違反する操作を行っていないかなどを確認します。

高いCorrectness（正確性）を持つAgentであっても、安全性に問題があれば本番環境で安心して利用することはできません。

性能：実用的な速度と安定性を備えているか

品質には、LatencyやErrorといった性能面も含まれます。

回答が正しくても、毎回長時間待たされるAgentではユーザー体験が低下します。また、不要なLLM CallやTool Callを繰り返していれば、LatencyだけでなくCostも増加します。

そのため、Latency、Error Rate、Token Usage、Tool Call回数なども継続して確認する必要があります。

AI Agentの品質とは、単に「正しい回答を生成できること」ではありません。

Correctness（正確性）、Relevance（関連性）、Groundedness（根拠に基づいているか）、Task Success、Safety、性能といった複数の軸に品質を分解し、それぞれを観測・評価することが重要です。

このように品質を分解しておくことで、Agentの評価結果が悪かった場合にも、何を改善すべきなのかを具体的に特定できるようになります。

1-4 AI Agent Observabilityの4領域

AI Agentの可観測性を考える際には、単にTraceを取得できれば十分というわけではありません。

AI Agentは、LLMによる生成、Retrieverによる検索、Toolの実行、外部データへのアクセス、Policyに基づく判断など、複数の処理を組み合わせて動作します。そのため、何が起きたかだけでなく、その動作が妥当だったか、安全だったか、後から説明できるかまで含めて観測する必要があります。

本書では、AI Agent Observabilityを大きく4つの領域に整理します。

Execution Observability：何が起きたかを観測する

Execution Observabilityは、Agentが実際にどのような処理を行ったかを把握するための可観測性です。

対象には、次のような情報が含まれます。

• ユーザー入力
• Prompt
• LLM Call
• Retriever
• Tool Call
• Tool Argument
• Tool Result
• Final Answer
• Latency
• Error

たとえば、最終回答が不正確だった場合でも、実行経路を確認できれば、「Retrieverが誤った文書を取得したのか」「LLMがContextを正しく利用できなかったのか」「Tool Callが失敗したのか」といった原因を切り分けられます。

Execution Observabilityは、後述するQuality、Security、Explainabilityの土台となる領域です。

Quality Observability：動作や回答は妥当だったか

Quality Observabilityは、Agentの結果や動作が期待する品質を満たしているかを評価する領域です。

たとえば、次のような観点があります。

• Correctness（正確性）
• Relevance（関連性）
• Groundedness（根拠に基づいているか）
• Task Completion
• Tool Correctness（正確性）
• Argument Correctness（正確性）
• Step Efficiency
• Safety

ここで重要なのは、Execution ObservabilityとQuality Observabilityを混同しないことです。

TraceにTool Callが記録されていたとしても、そのTool選択が正しかったとは限りません。Traceは「何が起きたか」を示しますが、「それが良かったか悪かったか」を判断するには別の評価が必要です。

この評価を行う仕組みとして、本書では後ほどMLflowのScorerやLLM Judgeを扱います。

Security Observability：安全に実行されたか

Security Observabilityは、Agentが誰の権限で何へアクセスし、どのようなActionが許可または拒否されたのかを把握する領域です。

たとえば、次の情報が対象になります。

• Identity
• Authorization
• Resource
• Action
• Policy
• Allow / Deny
• Permission Denied
• Guardrail Fail
• Prompt Injection
• Security Event

Toolを利用するAgentでは、誤ったActionが生成される可能性だけでなく、本来アクセスしてはいけないResourceへアクセスしようとする可能性も考慮する必要があります。

そのため、「Agentが何をしたか」というExecution Traceに加えて、「その操作は許可されたものだったのか」というSecurity側の情報も関連付けて確認できることが重要です。

Explainability / Auditability：後から説明・検証できるか

Explainabilityは、Agentの処理や結果について、後から「なぜそうなったのか」を説明できる状態を作る領域です。

本書では、これをさらに次の観点に分けて考えます。

• Execution Explainability
• Evidence Explainability
• Decision Explainability
• Outcome Explainability

たとえば、「なぜこの回答になったのか」を確認するには、単に最終回答を見るだけでは足りません。

どのRetriever結果を利用したのか、どのTool Resultを参照したのか、どのPolicyが適用されたのか、最終的にどのActionが選ばれたのかといった情報を追跡できる必要があります。

ここで残すべきなのは、LLM内部の思考過程そのものではなく、外部から検証可能なEvidence、Action、Policy、Resultなどの判断証跡です。

また、これらの情報をTraceやSecurity Audit Log、Evaluation結果と関連付けることで、後から処理を再検証できるAuditabilityにもつながります。

4領域は独立ではなく連携している

この4領域は、それぞれ独立したものではありません。

Executionによって実行内容を記録し、Qualityによってその妥当性を評価し、Securityによって安全性を確認し、Explainabilityによってその結果を後から説明可能にします。

つまり、AI Agent Observabilityとは、単なるTracingではなく、

「何が起きたか」「それは良かったか」「安全だったか」「なぜそうなったか」を一連の情報として把握できる状態を作ること

と整理できます。

本書では、この4領域を基盤として、以降のTracing、Evaluation、Scorer、Guardrail、Audit、Production Monitoringを体系的に見ていきます。